< PreviousChapter 3: Context50into plain HTML. An example of a VueJS-based HTML flavor for the UI Mask of the login dialog is:<form id=”login”> <label for=”un”>{{ $t(“username”) }}:</label> <input id=”un” name=”username” type=”text” v-model=”dataUsername”></input> <label for=”pw”>{{ $t(“password”) }}:</label> <input id=”pw” name=”password” type=”password” v-model=”dataPassword”></input> <input type=”submit” v-bind:value=”$t(‘login’)” v-on:click=”eventSubmitForm()”></input> </form>This example is using expression interpolation for Internationalization (I18N) of the texts behind the identifiers username, password, and login, bi-directional data binding for the two input fields onto the variables dataUsername and dataPass-word and uni-directional event binding for the action when submitting the form.3.3.2 Cascading Style-Sheets (CSS) for StyleThe Cascading Style-Sheets language (CSS, [Bos et al. 2011] [Schmitt 2010] [Hogan 2011] [Meyer 2011] [Weyl 2016]), during development time, declaratively attaches Style information to the User Interface (UI). It manifests itself, during run time, as the graphical properties of the Document Object Model (DOM, see subsection 3.3.3 on page 51). A simple style-sheet of a login dialog, in plain CSS, is:form#login { font-family: “TypoPRO Fira Sans”, sans-serif; margin: 10px; } form#login > label { font-size: 125%; color: #996633; } form#login > input[type=’submit’] { font-weight: bold; padding: 4px; }As plain CSS (of the current CSS Level 3, as of 2011) does not support nested selector syntax, custom properties (variables) and similar useful constructs, nowadays higher-level languages, like PostCSS, LESS or SASS/SCSS, are used. As the current browsers just support plain CSS during run time, these higher-level languages are “transpiled”, during build time, into plain CSS. An example of a PostCSS-based CSS flavor of the style-sheet for a login dialog is:Transpilation (shortening of “Transcompilation” and coinage of words “Trans-lation” and “Compilation”) is the Source-to-Source compilation process, which is very popular in the Web community.Web Technology Standards51form#login { font-family: var(--theme-font), sans-serif; margin: 10px; > label { font-size: 125%; color: var(--theme-color-fg); } > input[type=’submit’] { font-weight: bold; padding: 4px; } }This example is using nested selector syntax and the custom properties theme-font and theme-color-fg.3.3.3 Document Object Model (DOM) as Run-Time PlatformThe Document Object Model (DOM, [Wilson et al. 2000]) is the standardized run-time interface of the Web browser rendering engines. It holds all domain and technical information of the rendered Web page and is instantiated multiple times, once for each embedded <iframe>, Web browser tab or Web browser window.The DOM is primarily defined by its rendering capabilities (features) and the Application Programming Interface (API) to access and manipulate it. An example for accessing the username input field of a login form, in plain JavaScript/ECMAS-cript, is:let element = document.querySelectorAll( “form#login > input[name=’username’]”)[0] let username = element.valueAs the DOM is a run-time asset, there is no possibility to “transpile” higher-level fea-tures. However, there are so-called “polyfills,” JavaScript/ECMAScript libraries which patch the DOM during run time to add still missing functionality.3.3.4 JavaScript/ECMAScript for BehaviourAs the Document Object Model (DOM) manifests itself during run time, the behavior of a User Interface (UI) also requires a programming language. For this, JavaScript [Flanagan 2011] [Flanagan 2012] [Zakas 2016] [Brown 2016], also known under its standard ECMAScript [Terlson 2017], exists, which allows one to imperatively access and manipulate the DOM during run time. An example of subscribing to the “submit” Event of the submit button on the login form, is:JavaScript evolved from a niche language to one of the most wide-spread and successful program-ming languages within 20 years. Today it is no longer tied to the Web at all.Chapter 3: Context52var button = document.querySelectorAll( “form#” + id + “ > input[type=’submit’]”)[0] var self = this button.addEventListener(“submit”, function (event) { self.foo() [...] })JavaScript (as of ECMAScript 2017) has almost all constructs essential to modern Object-Oriented Programming and Functional Programming and the latest versions of all major Web browsers always closely follow the ECMAScript language stand-ardization.Nevertheless, there is always a noticeable gap in practice, because most Web browser major versions are tied to an underlying operating system major version (Microsoft Internet Explorer and Microsoft Edge to Windows, Apple Safari to macOS and iOS and Google Chrome to Android). As a consequence, one never can use the latest ECMAScript language version in a really portable way.Because of this, the latest standardized and proposed ECMAScript language features are usually “transpiled,” during build time, into the lowest common de-nominator ECMAScript 5 (as of 2009) by tools like Babel. The ECMAScript 2017 flavor of the above code snippets is:let button = document.querySelectorAll( `form#${id} > input[type=’submit’]`)[0] button.addEventListener(“submit”, (event) => { this.foo() [...] })This is using lexically scoped variables, string interpolation and this-aware “fat-arrow” functions.HTML5 Single-Page-Application (SPA) Approach533.4 HTML5 Single-Page-Application (SPA) ApproachSimple things should be simple, complex things should be possible. — Bo Leuf & Ward CunninghamThe Web in the 1990th originally was primarily about HyperMedia-based navigation between multiple Web pages of a network of distributed Web sites. Nowadays, the Web is also about applications, both ones with still the look and feel of Web sites, and ones with the look and feel of large Business Information Systems. Those applications usually follow a Rich-Client Architecture and have a Web Technologies based Front End.As the Document Object Model (DOM) in Web browsers is still targeting single Web pages, a new approach was invented: HTML5 Single-Page-Applications (SPA) [Hales 2012] [Scott 2015]. Here the User Interface (UI) of the application is techni-cally wrapped into a single Web page and treated by the Web browser as exactly such a single Web page during the entire run time of the UI.Those SPAs perform mandatory Dynamic User Interface Rendering, use man-datory Domain-Only Network Communication, might consume optional Server-Sent Events, are the result of Static Built-Time Artifact Bundling and are subject to On-The-Fly or On-Device Deployment.3.4.1 Dynamic User Interface RenderingAn HTML5 Single-Page-Application (SPA) renders its User Interface (UI) both autono-mously and dynamically during run time. This means, it incrementally renders its UI Fragments into the Document Object Model (DOM) with the help of on-the-fly generated or pre-built HyperText Markup Language (HTML) and Cascading Style Sheet (CSS). This is in great contrast to a regular Web page, comprised of statically pre-built “all-in-one” HTML and CSS. This Dynamic User Interface Rendering is what allows HTML5 SPAs to be extremely flexible and powerful.However, this approach also has some drawback, which has to be addressed. The most apparent drawback is the fact that all regular HyperLinks in HTML have to be processed via captured DOM events from within JavaScript/ECMAScript, as the Web browser usually should not leave the UI on any HyperLink clicks. At the same time, the back/forward-buttons of the Web browser would either also leave the ap-plication UI or lose their functionality during in-page navigation within the UI. This is usually mitigated by using HyperLinks based on URL hash fragment identifiers or by manipulating the Web browser history through the newer HTML5 Browser His-tory API.Additionally, as the Web page content is dynamically generated during run-time, traditional Search Engine Optimization (SEO) and User Analytics approaches Single-Page-Apps are Rich-Clients, based on Web Technologies.Chapter 3: Context54can no longer be used. This is usually mitigated by application “landing pages” and embedded analytics functionalities.Popular solutions for this aspect are the products Google Angular [Google 2010], Facebook React [Facebook 2013] and VueJS [You 2014].3.4.2 Domain-Only Network CommunicationWhile a regular Web page is loaded via the HyperText Transfer Protocol (HTTP) [Fielding & Reschke 2014] by the Web browser as primarily static content from the server, this changes for an HTML5 Single-Page-Applica-tion (SPA): the SPA itself is the primarily static content and loaded once during the Web page load-time, but afterward, Domain-Only Network Communication happens.In practice, this means that initially the SPA is loaded as a set of HTML/CSS con-tent and afterward, the domain data is transferred over HTTP or WebSocket in the popular JavaScript Object Notation (JSON) encoding. The advantage is good re-sponsiveness and reduced communication overhead during User Interface (UI) op-eration. The disadvantage is the significant initial code transfer during UI startup.Popular solutions for this approach are the communication encoding formats XML, JSON, CBOR, and MsgPack. A sample request in JSON for submitting the user-name and password for login might be:{ “username”: “foo”, “password”: “bar” }3.4.3 Server-Sent EventsIn parallel to the HTML5 SPA movement, the uni-directional request/response-based HTTP communication was complemented by the bi-directional message-based WebSockets communication. WebSockets allow the HTML5 Single-Page-Application (SPA) to open a persistent channel to its server, over which both the Domain-Only Network Communication and Server-Sent Events can happen. These additional Server-Sent Events allow the HTML5 SPA to instantly react to domain events sent by the server, usually as a consequence of a domain action re-quested by another instance of the same HTML5 SPA. This way HTML5 SPAs can pro-vide even near-real-time updates of domain information inside the User Interface.Popular solutions for this aspect are the products Socket.IO, Primus, GraphQL-Subscriptions, and GraphQL-IO. A sample framed message of GraphQL-IO in JSON over WebSockets, for the notification of a change in the currently logged in users, is:Although JSON is the most popular encod-ing, the binary protocols CBOR and MsgPack are more efficient.HTML5 Single-Page-Application (SPA) Approach55{ “fid”: 42, “rid”: null, “type”: “GRAPHQL-NOTIFY”, “data”: { “event”: “logged-in-users-changed”, “info”: { “users”: 7 } } } 3.4.4 Built-Time Artifact BundlingAn HTML5 Single-Page Application (SPA) consists of many artifacts: HTML masks, CSS style, JavaScript/ECMAScript functionality, the embedded graphical material in SVG, PNG, JPEG, GIF, WOFF, and TTF format, plus third-party libraries and their embedded material. Traditionally, all those artifacts were transferred into the Web browser via individual HTTP request/response communications. For the usually large number of artifacts, this further increased the already large initial load-time of the HTML5 SPA.To mitigate this issue, the artifacts are highly compressed and bundled during built-time. This usually reduces the HTML5 SPA size to about 20-30% of the original size, the number of HTTP requests to just about a dozen and this way reduces the overall initial load-time to just a few seconds.Popular solutions for this aspect are the products WebPack, Browserify, Fuse-Box, RollupJS, and Parcel. The source (src) and destination (dst) files of a WebPack-based bundling of a tiny application, for example, are (the 638KB of libraries are the extracted code of the 413MB of third-party material):$ ls -l src/ -rw-r--r-- 1 rse rse 512 Dec 31 2017 app.js -rw-r--r-- 1 rse rse 4640 Dec 31 2017 config.yaml -rw-r--r-- 1 rse rse 6377 Dec 31 2017 dexi.css -rw-r--r-- 1 rse rse 6313 Dec 31 2017 dexi.html -rw-r--r-- 1 rse rse 5608 Dec 31 2017 dexi.js -rw-r--r-- 1 rse rse 208 Dec 31 2017 dexi.yaml -rw-r--r-- 1 rse rse 17024 Dec 31 2017 icon.png $ du -sh node_modules 413M node_modules $ ls -l dst/ -rw-r--r-- 1 rse rse 5359 Dec 31 2017 app.css -rw-r--r-- 1 rse rse 17831 Dec 31 2017 app.js -rw-r--r-- 1 rse rse 463 Dec 31 2017 icon-16x16.png -rw-r--r-- 1 rse rse 970 Dec 31 2017 icon-32x32.png -rw-r--r-- 1 rse rse 33310 Dec 31 2017 icon.ico -rw-r--r-- 1 rse rse 2756 Dec 31 2017 index.html -rw-r--r-- 1 rse rse 35613 Dec 31 2017 lib.css -rw-r--r-- 1 rse rse 638170 Dec 31 2017 lib.js563.4.5 On-The-Fly Loading or On-Device DeploymentUsually, an HTML5 Single-Page-Application (SPA) is on-the-fly loaded into the Web browser on every usage. This way one benefits from both the high Rich User Interaction and the installation-free operation of an HTML5 SPA.Nevertheless, when using an HTML5 SPA on a mobile device, this popular approach can be nasty due to usually small-bandwidth mobile communication. To mitigate this issue, the HTML5 SPA can be wrapped into a native container application (which internally mainly just starts the browser engine of the underlying mobile operating system) and then directly deployed onto the mobile devices as a regular “App.” With this approach, the initial loading of the HTML5 SPA can be avoided at the cost of having an explicit installation and upgrade process again. Popular solutions for this aspect are the products Drifty Ionic, Apache Cordova (aka Adobe PhoneGap), Appcelerator Titanium, Facebook React Native, and Progress/Telerik NativeScript. The installation-free us-age of applications on the Web is a major ad-vantage in practice. Un-fortunately, it is often not acceptable on mobile devices.IIIPartRequirements, State of the Art and SolutionChapter 4RequirementsNext >