<<

Web User Implementation Technologies: An Underview

Antero Taivalsaari1, Tommi Mikkonen2, Kari Systa¨3 and Cesare Pautasso4 1Nokia Technologies, Tampere, Finland 2Department of Computer Science, University of Helsinki, Helsinki, Finland 3Tampere University of Technology, Tampere, Finland 4Software Institute, Faculty of Informatics, USI, Lugano, Switzerland

Keywords: Web User Interfaces, Web Programming, Web Rendering, Single Page Web Applications, Architectures.

Abstract: Over the years, the has evolved from a document distribution environment into a rich de- velopment platform that can run compelling, full-fledged software applications. However, the programming capabilities of the – designed originally for relatively simple scripting tasks – have evolved or- ganically in a rather haphazard fashion. Consequently, there are many ways to build applications on the Web today. Depending on one’s viewpoint, current standards-compatible web browsers support three, four or even five built-in application rendering and programming models. In this paper, we provide an ”underview” of the built-in client-side web application UI implementation technologies, i.e., a summary of those rendering mod- els that are built into the standards-compatible web browser out-of-the-box. While the dominance of the base HTML/CSS/JS technologies cannot be ignored, we foresee and WebGL gaining popularity as the world moves towards more complex and even richer web applications, including systems supporting virtual and augmented reality.

1 INTRODUCTION input modalities of the devices, valuable content has moved gradually from mobile devices to the cloud, The World Wide Web has become such an integral thus reducing the original role of the mobile apps con- part of the human society that it is often forgotten that siderably. the Web did not even exist thirty years ago. The orig- Interestingly, the programming capabilities of the inal design sketches related to the World Wide Web Web have largely been an afterthought – designed date back to the late 1980s. The first web browser originally for relatively simple scripting tasks. Due prototype for the NeXT computer was completed by to different needs and motivations, there are many Tim Berners-Lee in December 1990. The first version ways to make software run on the Web – many more of the web browser was released in Febru- than people generally realize. Furthermore, over the ary 1993, followed by the first commercially suc- years these programming capabilities have evolved in cessful browser – Navigator – in late 1994. a rather haphazard fashion. Consequently, there are Widespread commercial use of the Web took off in the various ways to build applications on the Web. With- late 1990s (Berners-Lee and Fischetti, 2000) when the out considering any extensions, frameworks and add- web browser became the most commonly used com- on libraries, depending on one’s viewpoint, the Web puter program, sparking a revolution that has trans- browser natively supports three, four or five different formed not only commerce but communication, social built-in application rendering and development mod- life and politics as well. els. Thousands of libraries and frameworks have then In desktop computers, today nearly all the impor- been implemented on top of these built-in models. tant tasks are performed using the web browser. Even Furthermore, in addition to architectures that par- mobile applications can be viewed merely as ”mirrors tition applications more coarsely between server and into the cloud” (Charland and Leroux, 2011). While client side components (Gallidabino and Pautasso, native mobile apps still offer UI frameworks and wid- 2017), it is increasingly possible to fine-tune the ap- gets that are better suited to the limited screen size and plication logic by moving code flexibly between the

127

Taivalsaari, A., Mikkonen, T., Systä, K. and Pautasso, . Web User Interface Implementation Technologies: An Underview. DOI: 10.5220/0006885401270136 In Proceedings of the 14th International Conference on Web Information Systems and Technologies (WEBIST 2018), pages 127-136 ISBN: 978-989-758-324-7 Copyright © 2018 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved WEBIST 2018 - 14th International Conference on Web Information Systems and Technologies client and the server (Meijer, 2007). In this context, 2 EVOLUTION OF THE WEB the rendering capabilities of the web browser are cru- BROWSER AS AN cial in creating the presentation layer of the applica- tions. APPLICATION PLATFORM In this paper, we provide a comparison of the built-in client-side web application architectures, i.e., Over the past twenty-five years, the World Wide Web the programming capabilities that the web browsers has evolved from its humble origins as a document provide out-of-the-box before any additional libraries sharing system to a massively popular ap- are loaded. This is a topic that has received surpris- plication and content distribution environment – in ingly little attention in the literature. While there are short, the most powerful information dissemination countless papers on specific web development tech- environment in the history of humankind. This evo- nologies, and hundreds of libraries have been devel- lution has not taken place in a fortnight; it has not oped on top of the browser, there are few if any followed a carefully designed master plan either. Al- papers comparing the built-in user interface devel- though the World Wide Web Consortium (W3C) has opment models offered by the browser itself. The seemingly been in charge of the evolution of the Web, choice between these alternative development mod- in practice the evolution has been driven largely by els has a significant impact on the overall architecture dominant web browser vendors: , , and structure of the resulting web applications. The Apple, and (to a lesser degree) . Over choices are made more difficult by the fact that the the years, these companies have had divergent, often web browser offers a number of overlapping features misaligned business interests. While browser compat- to accomplish even basic tasks, reflecting the histori- ibility has improved significantly in recent years, the cal, organic evolution of the web browser as an appli- browser landscape is still truly a mosaic or cornucopia cation platform. of features, reflecting organic evolution – or a tug of This paper is motivated by the recent trend to- war – between different vendors over time. ward simpler, more basic approaches in web devel- Before delving into more technical topics, let us opment. According to recent studies, the vast major- briefly revisit the evolution of the web browser as a ity (up to 86%) of web developers feel that the Web software platform (Taivalsaari et al., 2008; Taivalsaari and JavaScript ecosystems have become far too com- and Mikkonen, 2011; Anttonen et al., 2011). plex (http://stateofjs.com/). There is a movement to Classic Web. In the early life of the Web, web go back to the roots of web application development pages were truly pages, i.e., page-structured docu- by building directly upon what the web browser can ments that contained primarily text with interspersed provide without the added layers introduced by vari- images, without or any interactive con- ous libraries and frameworks. The recent ”zero - tent. Navigation between pages was based on sim- work manifesto” crystallizes this desire for simplicity ple , and a new web page was loaded from (Bitworking.org, 2014). However, even the ”vanilla” the web server each time the user clicked on a link. browser offers a cornucopia of choices when it comes There was no need for asynchronous network com- to application development. munication between the browser and the web server. This paper is an extended version of an earlier For reading user input some pages were presented as conference paper (Taivalsaari et al., 2017). The ex- forms, with simple textual fields and the possibility to tensions over the earlier work include extended back- use basic widgets such as buttons and radio buttons. ground and motivation, more detailed description of These types of ”classic web” pages were characteris- the different technologies, together with sample code, tic of the early life of the Web in the early 1990s. and a more elaborated discussion on the broader ar- Hybrid Web. With the introduction of DHTML chitectural implications. – the combination of HTML, Cascading Style Sheets The structure of this paper is as follows. In Sec- (CSS), the JavaScript language (Flanagan, 2011), and tion 2, we provide an overview on the evolution of the (DOM) – it became pos- the web browser as an application platform. In Sec- sible to create interactive web pages with built-in sup- tion 3, we dive into the built-in user interface de- port for more advanced and animation. The velopment and rendering models offered by modern JavaScript language, introduced in Netscape Naviga- web browsers: (1) DOM, (2) Canvas, (3) WebGL, (4) version 2.0B almost as an afterthought in Decem- SVG, and (5) Web Components. In Section 4, we ber 1995, made it possible to build animated interac- provide a comparison, followed by a broader archi- tive content by scripting directly the web browser. tectural discussion in Section 5. Finally, Section 6 In the second phase, web pages became increas- concludes the paper. ingly interactive. Web pages started containing - mated graphics and plug-in components that allowed

128 Web User Interface Implementation Technologies: An Underview

richer, more interactive content to be displayed. This one user interface element at a time, rather than re- phase coincided with the commercial takeoff of the quiring the entire page to be updated each and every Web during the dot-com boom of the late 1990s when time something changed. Although was primar- companies realized that they could create commer- ily a specific technique rather than a complete devel- cially valuable web sites by displaying advertisements opment model or platform, it fueled further interest or by selling merchandise and services over the Web. in building ”Web 2.0” applications that could run in Plug-in components such as , RealPlayer, a standard web browser. This also increased the de- Quicktime and Shockwave were introduced to make mand for a full-fledged that it possible to web pages with visually en- could be used directly from inside the web browser in- ticing, interactive multimedia, allowing advanced an- stead of relying on any external plug-in components. imations, movie clips and audio tracks to be inserted After the introduction of Ajax and the concept of in web pages. Single Page Applications (SPAs) (Jadhav et al., 2015), In this phase, the Web started moving in direc- the number of web development frameworks on top tions that were unforeseen by its original designer, of the web browser has exploded. Today, there are with web sites behaving more like multimedia presen- over 1,300 officially listed JavaScript libraries (see tations rather than static pages. Content mashups and http://www.javascripting.com/). web site cross-linking became popular and communi- Server-Side JavaScript. The use of client-side cation protocols between the browser and the server web development technologies has spread also to became increasingly advanced (Daniel and Matera, other domains. For instance, after the introduction of 2014). Navigation was no longer based solely on hy- Google V8 high-performance JavaScript engine, the perlinks. For instance, Flash apps supported drag- use of the JavaScript language has quickly spread into and-drop and direct clicking/events on various types server-side development as well. As a result, .js of objects, whereas originally no support for such fea- (://nodejs.org/) has become a vast ecosystem of tures existed in browsers. its own. In fact, the (Node ) The Web as an Application Platform. In the ecosystem has been growing even faster in recent early 2000s, the concept of Software as a Service years than the client-side JavaScript ecosystem. Ac- (SaaS) emerged. Salesforce.com pioneered the use cording to npmjs.com, there are more than 700,000 of the Web as a Customer Relationship Manage- NPM packages at the time of this writing. ment (CRM) application platform in the early 2000s, As already mentioned earlier, in this paper we demonstrating and validating the use of the Web and shall focus only on client-side technologies and only the web browser as a viable target platform for busi- on those technologies that have been included na- ness applications. At that point, people realized that tively in standards-compatible web browsers. We feel the ability to offer software applications seamlessly that this is an area that is surprisingly poorly covered over the Web and then perform instant worldwide by existing research. software updates could offer unsurpassed business Non-Standard Development Models and Ar- benefits. chitectures. For the sake of completeness, it should As a result of these observed benefits, people be mentioned that over the years web browsers have started to build web sites that behave much like desk- supported various additional client-side rendering and top applications, for example, by allowing web pages development models. For instance, Java applets were to be updated partially, rather than requiring the entire an early attempt to include Java language and Java page to be refreshed. Such systems often eschewed virtual machine (JVM) support directly in a web link-based navigation and utilized direct manipulation browser. However, because of the immaturity of techniques (e.g., drag and drop features) borrowed the technology (e.g., inadequate performance of early from desktop-style applications instead. Interest in JVMs) and resistance by some vendors, applets never the use of the browser as an application platform was became an officially supported browser feature. reinforced by the introduction of Ajax (Asynchronous In the late 2000s, so called Rich Internet Applica- JavaScript and XML) (Holdener, 2008). The key idea tion (RIA) platforms such as Adobe AIR or Microsoft in Ajax was to use asynchronous network communi- Silverlight were very much in vogue. RIA systems cation between the client and the server to decouple were an attempt to reintroduce alternative program- user interface updates from network requests. This ming languages and libraries in the context of the Web made it possible to build web sites that do not neces- in the of browser plug-in components that each sarily block when interacting with the server and thus provided a complete platform runtime. For a compre- behave much like desktop applications, for example, hensive overview of RIA systems, refer to Castelyn’s by allowing web pages to be updated asynchronously survey (Casteleyn et al., 2014). However, just as it

129 WEBIST 2018 - 14th International Conference on Web Information Systems and Technologies

was predicted in (Taivalsaari and Mikkonen, 2011), underlying development model. The DOM-based ap- the RIA phenomenon turned out to be rather short- proach is by far the most popular and most deeply lived. The same seems to be true also of various at- ingrained, but the other technologies deserve a fair tempts to support native code execution directly from glimpse as well. within the web browser. For instance, Google’s Na- Below we will dive more deeply into each technol- tive Client offers a sandbox for running compiled C ogy. We will start with the DOM, Canvas and WebGL and C++ code in the browser, but it has not become models, because these three technologies can be re- very popular. Mozilla’s classic NPAPI (Netscape Plu- garded more distinctly as three separate technologies. gin Application Programming Interface) – introduced We will then examine SVG and Web Components, originally in 1995 by Netscape – has recently been which introduce their own programming models but removed from all the major browsers; for instance, which are closely coupled with the underlying DOM stopped supporting it in 2015. Al- architecture at the implementation level. though there are some interesting ongoing efforts in this area – such as the W3C WebAssembly effort 3.1 DOM / DHTML (http://webassembly.org/), it is now increasingly dif- ficult to extend the programming capabilities of the In web parlance, the Document Object Model (DOM) web browser without modifying the source code of is a platform-neutral API that allows programs and the browser itself. scripts to dynamically access and update the content, structure and style of web documents. Document Ob- ject Model is the foundation for Dynamic HTML – the combination of HTML, CSS, and JavaScript – 3 CLIENT-SIDE WEB USER that allows web documents to be created and manip- INTERFACE RENDERING ulated using a combination of declarative and imper- TECHNOLOGIES ative development styles. Logically, the DOM can be viewed as an attribute that represents the con- tents of the web page that is currently displayed by As summarized above, the history of the Web has un- the web browser. Programmatic interfaces are pro- dergone a number of evolutionary phases, reflecting vided for manipulating the contents of the DOM tree the document-oriented – as opposed to application- from HTML, CSS and JavaScript. oriented – origins of the Web. Nearly all the appli- In the web browser, the DOM serves as the foun- cation development capabilities of the Web have been dation for a retained (automatically managed) graph- an afterthought, and have emerged as a result of di- ics architecture. In such a system, the application de- vergent technical needs and business interests instead veloper has no direct, immediate control over render- of careful planning and coordination. ing. Rather, all the drawing is performed indirectly As a result of the browser evolution that has oc- by manipulating the DOM tree by adding, removing curred in the past two decades, today’s web browsers and modifying its nodes; the browser will then decide support a mishmash of complementary, partially over- how to optimally lay out and render the display after lapping rendering and development models. These each change. include the dominant ”holy trinity” of HTML, CSS Over the years, the capabilities of the DOM have and JavaScript, and its underlying Document Object evolved significantly. The evolution of the DOM Model (DOM) rendering architecture. They also in- has been described in a number of sources, includ- clude the Canvas 2D Context API as well as WebGL. ing Flanagan’s JavaScript ”bible” (Flanagan, 2011). Additionally, there are important technologies such In this paper we will not go into details, but it is use- as Scalable (SVG) and Web Compo- ful to provide a summary since this evolution partially nents that complement the basic DOM architecture. explains why the browser offers such a cornucopia of The choice between the rendering architectures overlapping functionality. can have significant implications on the structure of DOM Level 1 specification – published in 1998 client-side web applications. Effectively, all of the • technologies mentioned above introduce their own – defines the core HTML (and XML) document distinct programming models and approaches that the models. It specifies the basic functionality for developers (and development frameworks built on top document navigation. of these base technologies) are expected to use. Fur- DOM Level 2 specification – published in 2000 thermore, all of them have varying levels of frame- • – defines the stylesheet object model, and pro- work, and tool support available to simplify vides methods for manipulating the style infor- the actual application development work on top of the mation attached to a document. It also enables

130 Web User Interface Implementation Technologies: An Underview

traversals on the document and provides support (https://www.w3.org/TR/2dcontext/). It is a low- for XML namespaces. Furthermore, it defines level, imperative API that does not provide any the event model for web documents, including the built-in or advanced event handling event listener and event flow, capturing, bubbling, capabilities. It that regard, Canvas offers much and cancellation functionality. lower level graphics support than the DOM or SVG DOM Level 3 specification – released as a num- that will automatically manage and (re)render • ber of separate documents in 2001-2004 – defines complex graphics elements. document loading and saving capabilities, as well Canvas objects are drawn in immediate mode. as provides document validation support. In ad- This means that once a shape such as a rectangle is dition, it also addresses document views and for- drawn using Canvas API calls, the data structure rep- matting, and specifies the keyboard events and resenting the rectangle is immediately forgotten by event groups, and how to handle them. the system. If the position of the rectangle needs to be changed, the entire scene needs to be repainted, in- DOM Level 4 specification refers to a ”living doc- • cluding any objects that might have been invalidated ument” that is kept up to date with the latest de- (covered) by the rectangle. In the equivalent DOM or cisions of the WHATWG/DOM working group SVG case, one could simply change the position at- (https://dom.spec.whatwg.org/). tributes of the rectangle, and the browser would then DOM attributes can be manipulated from HTML, automatically determine how to optimally re-render CSS, JavaScript, and to some extent also XML code. all the affected objects. As a result, a number of entirely different develop- The code snippet below provides a minimal ex- ment styles are possible, ranging from purely impera- ample of Canvas API usage. In this example, we tive usage to a combination of declarative styles using first instantiate a 2D canvas graphics context of size HTML and CSS. For instance, it is possible to create 100x100 after declaring the corresponding HTML el- impressive 2D/3D using the CSS anima- ement. We then imperatively draw a full circle with a tion capabilities without writing a single line of im- 40 pixel radius in the middle of the canvas using the perative JavaScript code. Canvas 2D Context JavaScript API.

Below is a ”classic” DHTML example that de- fines a text paragraph and an input button in HTML. The input button definition includes an onclick event handler function that – when clicked – hides the text var c = document.getElementById(”myCanvas”); paragraph by changing its visibility style attribute to var ctx = c.getContext(”2d”); ctx.beginPath(); ’hidden’. ctx.arc(50,50,40,0,2 Math . PI ) ; ctx.stroke(); ∗

This is a piece of text.

ing HTML and JavaScript code. In real-world ex- amples, it would be a good practice to keep declara- tive HTML (and CSS) code and imperative JavaScript In practice, very few developers nowadays use code in separate files. We will discuss programming the raw, low-level DOM interfaces directly. The style implications later in Section 4. DOM and DHTML serve as the foundation for an The event handling capabilities of the Can- extremely rich library and tool ecosystem that has vas API are minimal. A limited form of event emerged on top of the base technologies. The manip- handling is supported by the Canvas API with ulation of DOM attributes is usually performed using hit regions (https://developer.mozilla.org/en- higher-level convenience functions provided by pop- US/docs/Web/API/Canvas API/Tutorial/Hit regions ular JavaScript / CSS libraries and frameworks. and ). Conceptually, Canvas is a low level API upon 3.2 Canvas which a higher-level rendering engine might be built. Although canvas elements are created in the browser The Canvas (officially known as the Canvas as subelements in the DOM, it is entirely possible to 2D Context API) is an HTML5 feature that create just one large , and then per- enables dynamic, scriptable rendering of two- form all the application rendering and event handling dimensional (2D) shapes and images inside that element. There are JavaScript libraries

131 WEBIST 2018 - 14th International Conference on Web Information Systems and Technologies

that add event handling and scene graph capabilities Just like the Canvas API discussed above, the to the canvas element. For instance, with Paper.js WebGL API is a rather low-level API that does not (http://paperjs.org/) or Fabric.js (http://fabricjs.com/) automatically manage rendering or support high-level libraries, it is possible to paint a canvas in layers, and events. From the application developer’s viewpoint, then recreate specific layers, instead of having to re- the WebGL API may in fact be too cumbersome to paint the entire scene manually each time. Thus, the use directly without utility libraries. For instance, set- Canvas API can be used as a full-fledged application ting up typical view transformation (e.g., for rendering model of its own. view frustum), loading scene graphs and 3D objects The Canvas element was was initially introduced in the popular industry formats can be very tedious by Apple in 2004 for use inside their own Mac OS and requires writing a lot of source code. X WebKit component in order to support applications Given the verbosity of definitions, we such as Dashboard widgets in the browser. In do not provide any code samples here. However, 2005, the Canvas element was adopted in version 1.8 there are excellent WebGL examples on the Web. of browsers and Opera in 2006. The Canvas For instance, the following link contains a great API was later standardized by the Web Hypertext Ap- example of an animated, rotating, textured cube plication Technology Working Group (WHATWG). with lighting effects: http://www.sw-engineering- The adoption of the Canvas API was hindered by candies.com/snippets/webgl/hello-world/. Apple’s intellectual property claims over this API. Because of the complexity and the low level na- From a technical viewpoint, adoption was also slowed ture of the raw WebGL APIs, many JavaScript conve- down by the fact that the Canvas API expressiveness nience libraries have been built or ported onto WebGL is significantly more limited than the well-established, in order to facilitate development. Examples of such mature immediate-mode graphics APIs that were libraries include A-Frame, BabylonJS, three.js, , available in mainstream operating systems already a OSG.JS, CopperLicht and GLGE. decade or two earlier. Microsoft’s DirectX API – originally introduced in Windows 95 – is a good ex- 3.4 SVG ample of a substantially more comprehensive API. (SVG) is an XML-based 3.3 WebGL vector image format for two-dimensional graphics with support for interactivity, affine transformations WebGL (http://www.khronos.org/webgl/) is a cross- and animation. The SVG Specification (W3C, 2011) platform web standard for hardware accelerated 3D is an published by the World Wide graphics API developed by , Mozilla, Web Consortium (W3C) originally in 2001. Although and a consortium of other companies including Ap- bitmap images were supported since the early days of ple, Google and Opera. The main feature that WebGL the Web (the tag was introduced in the Mosaic brings to the Web is the ability to display 3D graph- browser in 1992), vector graphics support came much ics natively in the web browser without any plug-in later via SVG. components. WebGL is based on OpenGL ES 2.0 The code snippet below provides a simple exam- (http://www.khronos.org/opengles), and it leverages ple of an SVG object definition that renders an auto- the OpenGL shading language GLSL. A comprehen- matically scaling, graphical W3C logo to the screen sive JavaScript API is provided to open up OpenGL (https://dev.w3.org/SVG/tools/svgweb/samples/svg- programming capabilities to JavaScript . files/w3c.svg). In a nutshell, WebGL provides a JavaScript API

for rendering interactive, immediate-mode 3D (and − − − − − Processing Unit (GPU) accelerated usage of physics − − − − − − − − − − WebGL applications consist of control code written in JavaScript and shader code that is typically executed on a GPU. While SVG was originally just a vector image for- WebGL is widely supported in modern desktop mat, SVG support has been integrated closely with the browsers. However, its availability, performance and web browser to provide comprehensive means for cre- usability is dependent on various factors such as the ating interactive, resolution-independent content for GPU supporting it. the Web. Just like with the HTML DOM, SVG images

132 Web User Interface Implementation Technologies: An Underview

can be manipulated using DOM APIs via HTML, context of the Web, considering its tight integration CSS and JavaScript code. This makes it possible to within the DOM and its ability to embed HTML snip- create shapes such as lines, Bezier/elliptical curves, pets as a foreign Object, SVG is much more than just polygons, paths and text and images that be resized, an image format. Together with event handling capa- rescaled and rotated programmatically using a set of bilities, affine transformations, gradient support, clip- built-in affine transformation and matrix functions. ping, masking and composition features, SVG can be The code sample below serves as an example of used as the basis for a full-fledged, standalone graph- interactive SVG that defines a circle object that is ca- ical application architecture or windowing system. pable of changing its size in response to mouse input.

Web Components (https://www.w3.org/TR/#tr Web Components) are a set of features added to the HTML −− and DOM specifications to enable the creation of function circle c l i c k ( e v t ) var circle = evt.target; { reusable widgets or components in web documents var currentRadius = circle.getAttribute(”r”); and applications. The intention behind Web Compo- if (currentRadius == 100) circle.setAttribute(”r”,{ currentRadius 2) ; nents is to bring component-based software engineer- e l s e ∗ } circle.setAttribute(”r”,{ currentRadius 0 . 5 ) ; ing principles to the World Wide Web, including the ∗ } interoperability of higher-level HTML elements, en- capsulation, information hiding and the general abil- ity to create reusable, higher-level UI components that An important motivation for Web Components is the fundamentally brittle nature of the Document Ob- As illustrated in the example, the SVG scene ject Model. The brittleness comes from the global graph enables event handlers to be associated with ob- nature of elements in the DOM created by HTML, jects, so a circle object may respond to an onClick CSS and JavaScript code. For example, when you use event or other events. To get the same functionality a new HTML id or class in your web application with canvas, one would have to implement the code or page, there is no easy way to find out if it will to manually match the coordinates of the mouse click conflict with an existing name already used by the with the coordinates of the drawn circle in order to page earlier. Subtle bugs creep up, style selectors can determine whether it was clicked. suddenly go out of control, and performance can suf- Just like with the HTML DOM, SVG support in fer, especially when attempting to combine code writ- the web browser is based on a retained (managed) ten by multiple authors (Mikkonen and Taivalsaari, graphics architecture. Inside the browser, each SVG 2008). Over the years various tools and libraries have shape is represented as an object in a scene graph that been invented to circumvent the issues, but the funda- is rendered to the display automatically by the web mental brittleness issues remain. The other important browser. When the attributes of an SVG object are motivation is the fixed nature of the standard set of changed, the browser will calculate the most optimal HTML elements. Web Components make it possible way to re-render the scene, including the other objects to extend the basic set of components and support dy- that may have been impacted by the change. namically downloadable components across different In the earlier days of the Web, SVG was the only web pages or applications. means to implement a scalable, ”” graphics Web Components are built on top of a concept system, which is why the SVG DOM API was used known as the Shadow DOM. In technical terms, as the foundation for graphics implementation, e.g., the Shadow DOM introduces the concept of parallel in the original web programming ”shadow” subtrees in the Document Object Model. system (Taivalsaari et al., 2008). The following These subtrees can be viewed conceptually as ”ice- link provides a reference to a more comprehensive, bergs” that expose only their tip while the imple- ”Lively-like” example of an SVG-based application mentation details remain invisible (and inaccessible) that includes interactive capabilities (image rescal- under the surface. Unlike regular branches in the ing and rotation based on mouse events) as well: DOM tree, shadow trees provide support for scoped https://dev.w3.org/SVG/tools/svgweb/samples/svg- styles and DOM encapsulation, thus obeying the well- files/photos.svg/. known separation of concerns and modularity princi- In general, it is important to summarize that in the ples that encourage strong decoupling between public

133 WEBIST 2018 - 14th International Conference on Web Information Systems and Technologies

interfaces and implementation details (Parnas, 1972). Table 1: Comparison of Built-In Client-Side Rendering Utilizing the Shadow DOM, the can bun- Technologies. dle CSS with HTML markup, hide implementation DOM / Canvas WebGL SVG Web Compo- DHTML nents details, and create self-contained reusable compo- Year of In- 1998 2004 2011 2001 2011 troduction nents in vanilla JavaScript without exposing the im- Development Declarative Imperative Imperative Declarative Declarative Paradigm and imper- and im- and im- plementation details or having to follow awkward ative perative perative Rendering Retained Immediate Immediate Retained Retained naming conventions to ensure unique naming. Architecture (explicit (explicit repainting repainting At the technical level, a shadow DOM tree is just required) required) Information No No No No (except Yes (Shadow a normal DOM tree with two differences: 1) how it is Hiding when creating DOM encap- multiple SVG sulation and created and used, and 2) how it behaves in relation to images) scoped styles) Primary Us- Documents 2D graph- 3D/2D graph- 2D image ren- Web appli- the rest of the web page. Normally, the programmer age Domain and forms ics (e.g., in ics especially dering cations and games) in games and graphical user creates DOM nodes and appends those nodes as chil- VR/AR interfaces Popularity Ubiquitous Popular in Limited Popular in Growing dren of another element. With shadow DOM, the pro- specific use specific use grammer creates a scoped DOM tree that is attached cases cases Technology Mature Mature Mature Mature Emerging to the element but that is separate from its actual chil- Maturity (standard- ization dren. The element it is attached to is its shadow host. underway) Abstraction Medium Very low Low Medium High Anything that the programmer adds to the shadow Level Ease of Low to Low Medium Low to high High tree becomes local to the hosting element, including Code Reuse medium (shaders) (high as an image format) the