![TemplateAndInstances](../figures/template_and_instances.png "Web Components: the new elements in (B) are defined in (A), but at run-time the template is copied and the structure is redundant (C).") ## Development at Run-Time with Web Components The Lively Kernel development environment provides an explorative Smalltalk-like development experience, but excels only when working on content created with the Morphic framework. Web Components can provide similar (or better) abstractions as Morphic, but does not lend itself to be developed at run-time. ### Lively Kernel Development Experience Lively Kernel is best described as a Smalltalk-like development experience in the browser. It provides its own Morphic UI framework [@Maloney1995DLM, @Maloney2001IMS] with a rendering abstraction over HTML, SVG, and CSS. Every graphical object (morph) can be directly modified through drag and drop, copied, resized, customized with a style editor and scripted with an object editor. The morph and its connected objects can then be stored in a shared repository, where they can be reused and modified by others [@Lincke2012LPC]. The development experience of graphical tools and applications feels direct and immediate. It allows both, to evolve tools and applications while using them and share adaptations in a direct and informal way [@Lincke2014ETC]. Since in Lively Kernel morphs are JavaScript objects and only rendered as HTML, they maintain their own data structures. Therefore, the underlying HTML can always be discarded and rendered again. That means a world of morphs can be serialized as an object graph. This is a very powerful and general mechanism, but it does not play nicely with the way Web browser treat content. The browser usually does not wait for the full content to be delivered, but starts rendering as soon as the first HTML elements arrive. In contrast, in Lively Kernel, the browser has to wait until all serialized content is transmitted and all referenced JavaScript files are loaded. Then the objects are first deserialized and then rendered to HTML, after which the browser can start displaying them. Because Lively Kernel's Morphic is implemented on the JavaScript object level, it maintains its own graphical composition hierarchy and therefore provides an abstraction over HTML. Through an indirection, each morph is rendered to several HTML or SVG elements, making the Morphic tree structure leaner than the structure of HTML elements in the browser, hiding unnecessary implementation details form the Morphic user. Since Lively Kernel provides a Smalltalk-like development experience, the degree of liveliness a developer experiences can provide, depends on the program domain. The example in figure @fig:BouncingBallDynamicSystem show the simulation of ball (A). While working on the simulation source code (B) to modify or add new behavior, such as letting the ball bounce (C), the developer gets continuous feedback, because the new behavior is patched into the Meta-objects (D). Such a feedback loop is present in most scenarios of live programming. As this example shows, it is not always necessary to have framework or language support that will provide or enforce such a loop. Often times such feedback can be achieved through developers best practices, especially when the domain inherently contains a feedback loop. Even though Smalltalk-like approaches support the editing objects (E), they only updates the object state (F), but do not propagate the changes back the source code of classes (G). Lively Kernel deals with this problem by adding the behavior to objects and persist those changes by storing and loading objects with depended objects. However, Lively Kernel limits this programming experience to their own specific objects in their own world (Morphic framework). Because of this, there is a gap between the development experience of Morphic code and objects and code underneath that abstraction. By building tools that work on the level of HTML elements, but allow for the same explorative direct manipulation and live feedback during development, we hope to close that gap. ### Web Components in Modern Browsers Even though HTML elements can provide a similar substrate for live development, they lack the abstraction mechanism when working with JavaScript objects provided. Even though CSS (cascading style sheets) allows for separating the style from content to some degree, it is not possible separate a bunch of elements and their code into a new widget. Such an abstraction mechanism in plain HTML is missing: with ongoing development of new Web standards, Web Components bring the ability to compact several HTML elements into one. Before that, all kinds of abstraction had to happen on the side of programming languages that eventually generated HTML, be it on the client or on the server-side. Even though CSS can be used to separate some aspects of style ways, the delivered HTML files contain the presentation structures and code mixed with the content. Web Components are a technology that will not remove the implementation details encoded in HTML applications completely from the content, but encapsulates them into their own components. Web Components are a symbiosis of several new browser technologies, that are still in the process of standardization:^[https://www.w3.org/standards/techs/components, as of 2017-08-09.] - HTML Imports (Draft 2016-02-25) - HTML Templates (Standard 2014-03-18) - Custom Elements (Draft 2016-10-13) - Shadow DOM (Draft 2017-02-13) Together, they allow users to define custom HTML tags. The definition uses an HTML template that has to be imported before being used in an HTML file. The new element can further use other HTML elements that will be hidden in its shadow DOM for the user of the new tag. Web Components are supported in most modern Web browsers and can be emulated using polyfills^[https://www.webcomponents.org/]. Different from the workflow of Lively Kernel, developing with Web Components is by default a typical edit and reload cycle. Web Components force this style of development further, since registering elements can not be undone or overridden. The abstraction mechanism provided by Web Components is only present on a source code level. As the name *HTML Templates* already suggests, the HTML elements in the template are copied on each usage of that new element. Even though the shadow DOM with its shadow root marks the separation between the custom HTML element and its implementation, its implementation is just a copy of the templates elements in the shadow root. Making the elements in the shadow root forming normal child nodes in the bigger tree allows the browser's event processing and rendering to work as usual. This is different to the property lookup in JavaScript objects, where the abstraction of having some properties or methods defined in a prototype is still kept at run-time. Changing those properties or methods at run-time will change the behavior of all objects inheriting from that object, without having to modify each object again.