## Related Work

**Squeak/Smalltalk** [@Goldberg1984SIP; @Ingalls1997BFS] with its explorable world of objects and its Morphic framework [@Maloney2001IMS] already features a programming at run-time experience, that many systems are still not capable of today. Free from the security and design limitations of current Web browser technology, the developers have full control over all objects. All objects are persisted in an image, can be mutated and even replaced. Objects can `become` other objects, making object migration trivial. Since code can be changed and debugged at run-time, a live development experience can be achieved in case an application continuously uses the code under development. Different to our approach, the (UI) initialization code in Smalltalk is not continuously executed, giving no feedback when changing it.

<!--
  - `become` is what we need here, but due to security (and performance) limitations might never get... 
  - when in doubt let it tick: everything in `step` simulation has wonderful live feedback
  - but `initialize` method was always a feedback problem in Smalltalk
-->

**Lively Kernel** [@Ingalls2008LKS; @Krahn2009LWD; @Ingalls2016WAO] was used to continuously evolve itself in a self-supporting manner, experimenting with various approaches of providing a direct manipulation experience and live feedback. Even though it runs in the browser and can use all kinds of JavaScript libraries, its tools and workflow only excel when working on content created in and for Lively Kernel. Creating a similar experience but with a broader reach by targeting plain HTML is part of the motivation of this paper.

<!-- 
  - first version used SVG as a persistence format, but could not store the *model* 
  - but since JavaScript does not provide abstraction mechanisms, that allow to scope object graphs
  - and morphs know only one kind of parent child relationship
  - there are no private morphs that are used to be just an UI separated from other domain content... 
  - all child morphs are equal and the programmer has to come up with patterns or idioms to make such distinction  
-->

**Live programming** [@Victor2012LP; @Granger2012LTR; @Mcdirmid2007LUL] is a development experience that brings editing static source code and its dynamic behavior closer together. The implementation strategies to achieve immediate feedback while programming depends a lot on the application domain and restrictions of the used programming language. Implementing a feedback mechanism for editing code that expresses just a functional view is trivial, providing the same experience in an object-oriented world were objects and meta-objects live together, is much harder. Giving live feedback while imperatively constructing UIs is easier to achieve and often studied.
<!-- 
  - For live programming, one has to decide to throw away and update state. 
-->
In “it's alive!”, the approach is to separate “UI state from ordinary state, and the render code that builds UI state from ordinary code” [@Burckhardt2013IAC]. In our approach, we also take advantage of having different kinds of state: we treat HTML elements and attributes differently from JavaScript object state.
<!--  "upon code changes, we throw away the UI state, and then rebuild the UI state for the currently displayed page using the separated render code for that page." [@Burckhardt2013IAC] -->
In Lively Kernel and other environments, objects hold the model and the view is often thrown away and rendered again. In our approach we keep the elements defining the view and throw away the objects

<!-- #TODO Write

**Schema updates**

**Common Lisp Object System** (CLOS) 

- "CLOS is dynamic, meaning that not only the contents, but also the structure of its objects can be modified at runtime. CLOS supports changing class definitions on-the-fly (even when instances of the class in question already exist)" [Wikipedia:en/Common_Lisp_Object_System]

-->

**Cascading Tree Sheets** [@Benson2013CTS] address the problem of separating content and presentation, where Cascading Style Sheets (CSS) do not go far enough. This approach allows programmers to add HTML elements that are not part of the actual content, but needed for the presentation and UI later by inserting HTML elements and scripts based on CSS selectors. This approach is not suited for run-time development, because at run-time, the separation is not there any more. Web Components share a similar motivation, but preserve the separation between content and presentation elements even at run-time by keeping private elements hidden in each element's shadow DOM.