## Live Web Component Migration In our Web-based development environment Lively4, we aim to bring the development experience of Lively Kernel to plain development with HTML elements. Developing tools and applications with Web Components introduces abstractions on the HTML level but imposes challenges to make the experience of developing Web Component live and explorative. ### Object Mutation and HTML Element Migration To achieve short feedback loops and preserve the context during development, we need to avoid full page reloads. We therefore have to update the system behavior and state depending on the code changes at run-time. The mutation of shared Meta-structures (as shown in figure @fig:BouncingBallDynamicSystem) is not suitable for developing Web Components, because the state and behavior of Web Components depends on the HTML element structure in the shadow DOM. Different to editing a method's source code in a class, the editing of the element structure of a template affects not only one object that can be mutated, but it affects several object structures as shown in figure @fig:TemplateAndInstances. Editing a template itself represents changing many HTML elements at once. Even further, as shown in figure @fig:TemplateAndInstances, this template might have been used in multiple places (all usages of the new custom HTML element) and every element has copies of that template's element structure in its own shadow root. This means even if we could mutate the template's HTML elements in a perfect way, we would have only affected the appearance of new instances, which is not satisfying in live programming. Our solution is to migrate all existing instances. It is not enough to mutate the linked template element (A), but we have to deal with each instance individually (B). To achieve this, we replace each element with a new instance and migrate all persisted state from the previous instance to it. By default we keep the custom style, properties and child nodes, but elements can specify additional migration behavior by implementing a `livelyMigrate` method. The approach has the downside of breaking existing references, which will be a problem when we replace internal components that are used and referenced by other components. We plan to address this issue in future work, by either automatically forcing a migration of components that use the component under development, or combining mutation and migration in away that we keep the old instance, but replace the private properties and element in the shadow DOM of the component. ### Different Kinds of Feedback in the System Even though a Lively Kernel-like development experience can give feedback of the behavior in a running system, not all behavior has immediate feedback. Figure @fig:SoapBubble exemplifies such kinds of feedback in a simulation of a soap bubble. The bubble extends the balls behavior in several ways. It will burst after a time has passed (A), the user touched it (B), or it collides with the ground (D). When it collides with another bubble, the bubbles will be combined into a new and bigger one (C). All this behavior is explorable at run-time, but may need some interaction, waiting or manual setup. The environment can only support the developer in not having to perform those interaction-, waiting- and setup-tasks over and over again. Record and replay techniques [@Mcdirmid2013ULP] can automate those repetitive task and make the feedback immediate, but it is the developer's task to invoke the desired behavior. In Lively4, we strive to support programming at run-time as much as possible, not to immediately give feedback to every line a programmer typed, but to provide programmer with the freedom to explore and adapt the running tools and applications as needed.