The biggest changes will be to the forms/pages themselves. The new page type (Referred to as Page17 for now) is significantly different than the existing page/form model.
Forward without Breakage
To facilitate both continuing to support older browsers and to allow existing IntraWeb projects to run in IntraWeb 17 with minimal changes, IntraWeb 17 will support both page types concurrently in a single project.
This allows the use of existing projects with minimal changes to the global areas and no changes (or very minimal) changes to existing pages. New pages can be created either as Page16 or Page17 allowing an existing application to take advantage of the new features on a page by page basis.
We also plan to evaluate the feasibility of a migration tool to assist in migrating pages from Page16 to Page17.
Page16 is the existing page type known to all IntraWeb users and is the same page type in use since at least as far back as IntraWeb 7. It has seen many updates and some core changes but the basic page type remains the same.
DFM –> HTML –> HTTP –> DOM (Browser) –> HTTP –> IntraWeb
Page17 pages instead use the following path:
DFM –> JSON –> HTTP –> TypeScript Library –> HTML –> DOM (Browser) –> WebSockets –> IntraWeb
No HTML, JS, or CSS is created on the server. Instead a JSON file containing a translated version of the DFM is used. JSON was chosen for a variety of reasons but other formats could easily be supported such as XML.
The JSON file is then translated into HTML and CSS by TypeScript running in the browser. This reduces the size of data transferred across the network and provides for easier manipulation both in the browser, and in response to requests from the server.
Sample IntraWeb Page JSON File
"Title": "IntraWeb 17 Test",
This is a very simple file however more extensive layouts and controls are being developed. Layouts such as stacks, grids, tiles and docks.
Page17 enables much easier modification of the DOM (Web page in browser) which makes it easier to perform live updates far beyond what AJAX can do. The second part of the problem is latency which is perceived as delay or sluggishness by the end user.
AJAX and other communication methods all need to go through HTTP. HTTP uses short lived connections though so to use it as a live communications channel is not viable. AJAX submits requests and waits for responses, but if the server wants to push something it has to wait for the client to check in. Each of these requests makes a new connection which even on a fast connection can take a fraction of a second – enough for the user to notice lag in responses. Heavy load on a server can also slow down connection response times because of the simple overhead of dealing with so many connection requests which cannot be cached.
WebSockets is a protocol which allows for persistent TCP connections via HTTP. WebSockets have been around for a while but usage has been hindered by varying degrees of support in browsers, but more importantly old or misconfigured proxies at the Internet Service Provider or Corporate level, effectively disabling WebSockets for many users.
As of 2017 however the situation for WebSockets has greatly improved and looks to continue increased support. WebSockets support may be an optional feature of Page17, but when used it will allow very responsive times for messages from the browser to the server and also allow the server to communicate with the browser without needing to wait for the browser to initiate communication.
This type of low lag communication channel enables higher speed events such as keypress events that can be used to process live keyboard input from the browser directly on the server. It also enables mouse movement tracking. These are just two simple examples.
This allows IntraWeb to produce applications that act nearly like a desktop application but without the security risks, no installation, and without the lag of a remote desktop session. Bandwidth used is very minimal because unlike a remote desktop sessions, raw meta data is being sent rather than scraped in bits and pieces and send along with images as remote desktop solutions must do.
Page16 as Page17
We may add an option to allow Page16 pages to be rendered using Page17 to gain rendering and speed improvements, but because of the translation layer most new functionality would not be available.