
![BouncingBallDynamicSystem](../figures/bouncing_ball_dynamic_system.png "Bouncing ball: when the domain lends itself to it, a programmer can develop some parts of an application with continuous feedback, just by editing code that will patched into the system.")


## Introduction

<!-- #LivelyKernel #DevelopmentAtRuntime #Silo -->
Lively Kernel [@Ingalls2016WAO] was one of the first Web-based development environments that explored new ways of interactively develop Web applications and active content directly in the browser [@Krahn2009LWD]. In this Smalltalk-like tooling environment, content and applications developed are written in a special way so that they can be modified and evolved while being used. Components not developed in Lively Kernel, such as the visualization library D3^[https://d3js.org/], could be used, but had to be specially wrapped to be integrated. This wrapping also resulted in a hard border that could not be crossed by the tools and the user interface of Lively Kernel, e.g. a user could not select or directly manipulate an element in a D3 visualization, because it is not part of the Morphic framework.  

\newpage

In the new Web-based development environment Lively4, we want to transfer Lively Kernel's explorative and live programming experience to a wider and more used model: plain HTML elements.
By building tools that work directly on HTML elements, we are not limited to work on applications and content created in our environment, but can explore and work with all kinds of external resources such as visualization libraries and text editors. Lively4, being a purely client-side development environment, needs just some server or service that serves files^[Lively4 uses a custom server for authentication and GitHub access, but it can also be run in principle from any HTML server or service].

Compared with a clean object composition hierarchy in the Morphic framework, however, a tree of HTML elements can be cluttered with content and presentation elements. To be able to use some kind of abstraction mechanism in the development of our own tools, we decided to use Web Components. 
Web Components is a new Web standard^[https://www.w3.org/standards/techs/components] that
enables developers to create custom HTML elements and better separate content from presentation could help express needed abstractions, that previously the Morphs provided. 
This abstraction mechanism makes Web Components an ideal building material for the new environment, but Web Components have a downside: They are not designed to be updated after they are used, rendering the basic implementation strategy of Smalltalk-like programming, which is modifying meta-objects at run-time, useless in this case. 

In this paper, we describe how we applied Web Components in Lively4 and enable modifying them at run-time, preserving the context [@Rein2016GIP] and giving immediate feedback by migrating all instances of the component under development.    

The remainder of the paper is structured as follows: in next section we present a Lively Kernel like development experience, which lacks the capability of directly on HTML elements. We present Web Components as a powerful abstraction mechanism, but which not suited to be worked on at run-time. In section 3, we present our approach of migrating instances of HTML elements instead of updating just single meta-objects. In section 4, based on our experience of developing all tools in Lively4 with Web Components, we discuss open problems, best practices and future work. Section 5 discusses related work and section 6 concludes our thoughts on this topic.

<!---

-->
