# Reviews PX.2 2017 ## REVIEW 1 Overall evaluation: 2 (accept) The paper builds on previous work in the Lively Kernel environment. The contribution is an extension of Lively Kernel to directly support Web Components which provide a higher level of abstraction than HTML elements. The paper presents an approach based on migrating instances of HTML elements rather than of updating just single meta-objects and discusses open problems, best practices in developing applications based on this technique. The paper is well-written and clear. The problem is highly relevant and interesting for the target community. I think that the work can trigger interesting discussions at the workshop. I was a bit puzzled by the title of section 4 "Evaluation" which is more a "Discussion" than a proper evaluation. On the other hand, this issue made me think about a possible evaluation for this kind of work which could be an interesting topic for discussion at the workshop, too. ## REVIEW 2 Overall evaluation: 1 (weak accept) This paper introduces Lively4, a development environment that uses Web Components. Overall, I like the ideas behind this paper. I think Lively4 is a clear and relevant contribution. However, I feel that there is a lot of improvement that this paper could make to more clearly state its contribution. First, the relationship of Lively4 relative to the Lively Kernel and Morphic needs to be more clearly stated. Is Lively4 a branch of the Lively Kernel/Morphic? A replacement? Further, most of the paper focused on the fact that Lively4 is built on Web Components. However, there is little discussion on what the advantage of building on Web Components is. Can Lively4 do things that previous iterations of the Lively Kernel could not? Does it enable Lively4 to handle more objects? Does it allow Lively4 to work with more third-party JavaScript frameworks? The introduction mentions D3 as an example library that would need a wrapper to work with the Lively Kernel, so I was expecting the authors to mention whether D3 works with Lively4 natively. It would also help to have a more complete discussion of the technical and design challenges the authors faced when creating Lively 4 and how they overcame them. The "Evaluation in Lively4" section presents a few but does not discuss how the authors addressed them. For example, in section 4.2 ("Stale code" and Dangling Event Listeners) the authors write "After this, we established a best practice to use an event registering mechanism that allows us to clean up and unregister old listeners automatically." What is this best practice? Overall, I am excited about the work but I felt that the paper could have made its contributions much clearer. If the focus of the paper is on creating a live development environment for Web Components, the advantages of Web Components should be clearer to the reader. For example, the authors might show how by using Web Components, they managed to integrate third-party JavaScript frameworks (such as D3) into Lively4 applications with minimal overhead. As a minor note, there are many typos in this paper that should be corrected before any final submission. There are several places where there is a missing subject (for example, in at least 3 places in the paper, the authors write "allows to" when it should be "allows to"). The title of section 4.4 should likely be "Losing Object Identity", etc. ## REVIEW 3 Overall evaluation: 1 (weak accept) This paper aims to more fully realize a Smalltalk-like environment on the web, building upon Lively Kernel and the JavaScript Morphic framework. The authors frame the problem of making plain HTML elements live and explore the various technical constraints on updating HTML elements without reload. The author's proposed solution is to use the new WebComponents standard as an abstraction container, controlling the instantiation of each WebComponent using a template, and upon template change, automatically migrate the state of existing instances to new replacement instances, and automatically register and deregister listeners on old instances. This appears to mostly work, but must sometimes rely on custom migration code, but doesn't yet handle external JavaScript references. As an architectural solution to architectural problem, the idea seems appropriate, but not groundbreaking. The work does not attempt to contribute new ideas of liveness or new experiences, but rather work around architectural limitations of the web to support liveness in a technology stack not built for it. There is merit to this infrastructure work, but it is not the kind of work that explores new programming experiences. There are a few sentences with grammatical errors: "provides and explorative an Smalltalk-like development experience" "In out Web-based development environment Lively4" "allows to get feedback" "We take care to update some know JavaScript references" I'm also confused by what Figure 4 is trying to illustrate. What are all of the weird icons overlaid on the GitHub Sync window. Are they part of Lively4 or the GitHub Sync Window? ## REVIEW 4 Overall evaluation: 2 (accept) This work is interesting for this workshop because it explores how a new and still evolving web technology (Web-Components) interacts with an out-of-the-mainstream development style. The issues of Smalltalk-like live development are almost certainly unfamiliar and unconsidered by the developers of he Web Component standards. A significant contribution would be feedback to the Web-Component designers that might influence the Web Component design to be more hospitable to live development tools. From that perspective, the paper itself is lacking as a communication vehicle in that it may not provide enough depth about live development scenarios and requirements to motivate concern among the Web Component designers. I would also like to see this work related to modern JavaScript UI frameworks such as React, Angular, Ember, etc. Such frameworks generally have their own concept of a shadow DOM and it would be interesting to understand if usage of them presents similar problems of live development tools. ## Meta-review The reviewers of this work are appreciative of the technical aspects, and how these contribute to a new architectural solution. However there is a broad consensus that: - The work needs to be clearer in identifying its core contributions, and describe technical problems in a more familiar way by, for example, enumerating requirements and what effect they have on the design - Whilst the technical work is important, in the context of the PX workshop it's helpful to ground these in how the effect the developer's experience. Perhaps these open up new possibilities for interaction paradigms? Perhaps there is something to learn about the general architectural patterns for building live systems upon existing platforms? In order to have a generative conversation at the workshop, the authors should think how they are going to present the technical details at a level of abstraction that leaves room for a discussion of new possibilities for interaction and broader implications for design.