The Lively Kernel Application Framework


The Lively Kernel is a fully interactive, "zero-installation" Web application framework and development environment written entirely in JavaScript. The rich user experience of applications built using the Lively Kernel is enabled by integrated programmatic access to arbitrary 2D graphics, and owed in no small part to its use of Scalable Vector Graphics and its bindings to the JavaScript language.

Lively Kernel runs in SVG-enabled Web browsers without installation or plug-in requirements; it offers a compact and extensible set of user interface components. As a result, it supports familiar desktop-style applications with the expected user interface functionality and direct manipulation capabilities; it enables application development and deployment in a Web browser with no installation or upgrades, using only existing Web technologies. In addition to its application execution capabilities, the Lively Kernel also functions as an integrated development environment (IDE). Thus, it is self-supporting and able to improve and extend itself dynamically. Lively Kernel is currently also one of the most comprehensive dynamic SVG frameworks available, and has become an important test case for SVG implementations in Web browsers.

The main component of the Lively Kernel is a user interface framework called Morphic, originally developed for the Self language, and later incorporated into the Squeak Smalltalk system ([Maloney95]). The Morphic framework consists of about 10,000 lines of uncompressed JavaScript code downloaded to the Web browser on Lively Kernel startup. The central goal of Morphic is to facilitate construction and editing of graphical objects, both programmatically and by direct, interactive manipulation. Morphic objects are editable, composable and animatable, Morphic also handles user input and manages underlying system resources such as fonts, gradients or images. Built-in mechanisms are provided for object scaling, rotation, object editing, as well as for defining user interface themes. Currently, visual editing tools are provided for only a subset of the elements defined in the SVG specification, however, our system could be easily extended to act as a complete SVG authoring tool.

The Morphic framework also provides a library of higher level user interface components, such as buttons, lists, menus, windows, etc., composed from the basic graphical objects, as well as a Model-View-Controller infrastructure for abstracting visual representation of data from application logic. The default configuration of the Lively Kernel offers a familiar desktop metaphor with multiple applications running concurrently, however, standalone applications are also supported.

The Morphic framework includes tools for development, modification and deployment of applications from within the Lively Kernel system itself. The tools include a class browser, an object inspector and a DOM inspector. The implementation of these tools relies on the reflective capabilities of JavaScript, and can therefore be used inside the Web browser without any external tools or IDEs. As a result, it is possible to, e.g., create new JavaScript classes, modify or delete existing methods, or change the value of any property in the system. Finally, it is possible to export and import objects or entire Web pages from within a running system and thus use the Lively Kernel as an authoring environment for both code and interactive graphics. The export mechanism currently uses our own implementation of the Distributed Authoring and Versioning (WebDAV) extensions built on top of the asynchronous HTTP networking support present in all modern browsers. Objects are serialized into valid SVG files with additional Lively Kernel-specific annotations necessary to reconstruct all the JavaScript objects on deserialization. The annotations are placed in a dedicated XML namespace, as a result, if a Lively Kernel runtime is not available at deserialization time or the user agent does not support JavaScript, the serialized file is rendered as a static screenshot of the application at the time of serialization.

Table of Contents

The Lively Kernel approach to Rich Internet Applications
Morphic User Interface Framework
A Lively Construction
Simple Editors
Editing text
Editing abstract data: widgets and Model-View-Controller (MVC) architecture
Editing source code: development tools
Implementing Morphic in SVG
The implementation of mapping: wrapping versus extending DOM elements
Unused specification features
SVG as a serialization format

The explosive growth of the Internet and growing interest in expanding interactive functionality and usability of Web applications has recently sparked a revival of sorts of graphical user interface (GUI) framework development. The cross-platform, standards-oriented nature of enabling technologies available in commercial Web browsers lowered the barrier of entry to the field of GUI framework development, and greatly reduced the dependence on operating system vendors and their software distribution and update channels. As a result, a variety of popular, actively developed Web-based GUI frameworks have sprung up, usually as main components of so called AJAX toolkits, which leverage the JavaScript language, dynamically updated Hypertext Markup Language (HTML) content and asynchronous requests for data in expressed in the Extensible Markup Language (XML) to provide rich user experience. Dojo ([Dojo], ExtJS ([ExtJS]) and Scriptaculous [Scriptaculous]) are excellent examples of such frameworks. On the other hand, vendors such as Adobe and Microsoft, recognize the limitations of technologies implemented by Web browsers, and promote proprietary frameworks based on external runtimes available as browser plug-ins, such as Adobe Flash, Adobe Flex and Microsoft Silverlight.

Naturally, currently available AJAX toolkits aim to reproduce the functionality and usability of a modern desktop GUI framework. This paper presents an alternative approach, a system that capitalizes on decades of GUI research and innovation outside the mainstream practice of GUI framework design. The renewed interest in GUI frameworks presents itself as a unique opportunity to advance the state of art and offer these results to wider audiences. The system's main intended improvement is a much higher level of dynamicity and malleability, offered equally to the programmer and to the interactive user. The system is called Lively Kernel, to emphasize both the intent to apply the notions of read-write Web to graphics programming, and focus on compactness, self-containment and comprehensibility to a single programmer.

Lively Kernel follows typical AJAX toolkits by using JavaScript as its implementation language. This choice is pragmatic, as JavaScript is the only programming language uniformly implemented in modern Web browsers, but it is also conductive to project goals, because the language is reasonably dynamic. However, Lively Kernel strays form the commonly followed path of using HTML. While existing AJAX toolkits achieve wonders by building on top of what was intended to be a text publishing format, the Scalable Vector Graphics (SVG, [SVG11]) standard addresses the shortcomings of HTML and is a much better foundation for interactive graphical applications on the Web.

This paper presents the SVG backend of the Lively Kernel. We have found the SVG standard to be a rich and expressive graphics substrate, and its implementations in widely available Web browsers demonstrate well the potential of our approach. While our current work is almost exclusively built on top of the SVG backend, we are equally interested in portability to other graphics substrates. In fact, an earlier version of our system provided a custom browser-like environment on top of the Java™ platform, using the Java2D APIs as its graphics subsystem and Rhino as its JavaScript execution engine.

Despite being based on a text markup format, Lively Kernel presents a traditional procedural application programmer's interface (API), which acts as a layer of abstraction over SVG and other graphics backends. The SVG backend itself does not rely on text markup and accesses the SVG implementation through its Document Object Model (DOM) interface. The resulting system is both compact (approximately 10,000 lines of code, including comments) and expressive. For instance, Lively Kernel is more than capable of implementing traditional desktop metaphors, as shown in Figure 1, “Lively Kernel desktop”. The system's code base is uniformly implemented in JavaScript, and relieves the programmer from the mental context switching required when inspecting and developing in a system implemented using multiple technologies and formats, as is typically the case in existing AJAX toolkits based on HTML, Cascading Stylesheets (CSS), JavaScript and auxiliary technologies.

The majority of the JavaScript classes defined by the Lively Kernel are related to a user interface framework called Morphic ([Maloney95]). The Morphic framework was developed originally for the Self language and system ([Self]), and later became popular as the user interface of the Squeak Smalltalk system ([Squeak]). Lively Kernel reimplements a sizable subset of the Morphic framework using technologies available in modern Web browsers.

Morphic achieves simplicity of programmatic and interactive access by consistently relying on a class of graphical objects called “morphs”, possessing some or all of the following properties:

  • A shape, or graphical appearance,

  • A set of submorphs, comprising the “scene graph” of the page or world,

  • A coordinate transformation that affects its shape and any submorphs,

  • An event handler for mouse and keyboard events,

  • An editor for changing its shape,

  • A layout manager for laying out its submorphs,

  • A stepping protocol for time-varying behavior,

  • A damage rectangle repainting protocol and double-buffered display mechanism (used when the underlying graphics substrate does not provide it).

Morphic defines several classes of morphs with special semantics. A WorldMorph captures the notion of an entire web page; its shape defines its background appearance, if any, and its submorphs comprise all the remaining content of the page. In contrast to typical web pages, however, multiple worlds can coexist in a single JavaScript execution context. Notionally, the user interacts with the contents of single world, and navigates between different worlds by clicking on LinkMorphs, representing connections between worlds.

A HandMorph is the Morphic generalization of a cursor; it can be used to pick up, move, and deposit other morphs, its shape may change to indicate different cursor states, and it is the source of user events in the architecture. In Lively Kernel, a Morphic world may have several hands active at the same time, corresponding to several collaborating users of that world (this functionality is not yet available in the current incarnation of the Lively Kernel, although, it has been demonstrated in the previously mentioned prototype based on the Java™ platform).

In many respects Lively Kernel can be viewed as an interactive editing environment for graphic and non-graphic information. The remainder of this section presents various aspects of the Morphic framework in terms of its editing capabilities.

Morphic supports interactive manipulation of morphs included in the framework, and, by extension, composite morphs assembled from the morphs already in existence. In contrast with the mostly static elements of typical Web pages, each morph in a Lively Kernel world can be picked up, moved, resized, rotated, duplicated and reshaped.

The sequence shown in Figure 2, “Construction through visual manipulation” illustrates the construction of a simple truck shape by concrete manipulation. In Figure 2, “Construction through visual manipulation” A we see a palette of useful shapes. In Figure 2, “Construction through visual manipulation” B, the rectangle has been copied, and extended in Figure 2, “Construction through visual manipulation” C. In Figure 2, “Construction through visual manipulation” D, the rectangle has been colored yellow, an ellipse has been copied, resized, and colored, and has been given a thick black border to resemble a tire, and a second copy has already been affixed to the bus. In Figure 2, “Construction through visual manipulation” E, the truck is complete, and Figure 2, “Construction through visual manipulation” F shows a family of trucks, copied and rotated from the new master, all operations that can be accomplished with simple gestures in the Lively Kernel's graphics editor.

Beyond the basic vocabulary of the underlying graphics support, the programmability of Morphic shapes provides an unlimited range of graphical idioms. Figure 3, “Extending the graphical vocabulary” shows a small snippet of JavaScript that draws a polygonal spiral. The code demonstrated in the figure produces not merely marks on the screen, but, rather, a fully active object that can be copied, scaled, and colored, as shown, and that could be set to spinning with one more line of code, such as

this.startStepping(50, “rotateBy”, 0.1); // 0.1 radians every 50 ms

An editable graphics environment would not be complete without support for editing text, and Lively Kernel comes with a rich text editor built into every TextMorph, the basic text container and unit of text manipulation. The Lively Kernel provides this functionality with three basic components:

  • A rich text model (Text, RunArray, TextEmphasis)

    TextEmphasis is an aggregate property, such as {style: 'bold', fontSize: 14}, together with a method for merging with other instances. RunArray is a compactly encoded array of TextEmphasis objects corresponding to every character of a Text. Most of the work is associated with slicing and concatenating these objects. An optimization allows efficient streaming through what is effectively a sparse structure. Text is nothing more than a String of characters with a matching RunArray of emphasis.

  • A text composition facility (Font, TextWord, TextLine, TextMorph)

    Text composition is merely a process of streaming through the text, noting exceptions when emphasis changes, and when the frame boundary or mouse location is encountered. TextLine and TextWord capture the state of this process, and allow efficient display and location of the individual characters.

  • A text editor (TextMorph, TextSelection)

    Once text has been composed, a text editor dispatches user events to manipulate the current selection and alter either the content or the emphasis of the selected text.

The totality of the text package in the Lively Kernel is approximately 2000 lines of JavaScript, including comments. Lists and menus are built from it in a further 400 lines.

The decision to tackle active text was a daunting one. Composition of text is the most complex module in the Lively Kernel. Access to font metrics is complex and browser-dependent, and character-by-character composition is a challenge even for the faster JavaScript implementations. That said, we consider the achievement of active WYSIWYG text, independent of native widgets, to be a breakthrough. In a context such as SVG, arbitrary text and graphics can now be freely mixed, interactive changes can be made through arbitrary coordinate transformations, all without concern for installation barriers or browser-specific text problems.

It should be noted here that many modern browsers, such as those derived from the Gecko rendering engine employed in the Firefox browser, contain a built-in rich text editor. One could argue that the resulting duplication of editing functionality in JavaScript is undesirable, however, the rich text editors are neither standardized nor easily integratable with SVG. The SVG specification allows integration of XHTML content through the <foreignobject> element, which can be manipulated, most notably using affine transforms, much like other SVG elements. However, the Gecko engine currently only supports editing HTML content, and not XHTML, and as of this writing, other browsers exhibit similar limitations. Even if XHTML editing were supported by all browsers, performing text editing in Lively Kernel results in more self contained code, and as a result, retains its character as a computing kernel.

The editing capabilities presented so far are related to editing SVG graphics, but Lively Kernel is capable of editing other kinds of structured data In particular, the Lively Kernel's widget set has been implemented with a Model-View separation along the lines of many Smalltalk systems, and, in this context, views forming a Lively Kernel widget can be regarded as editors for parts of a shared model. This architectural choice was influenced by experience with GUI-builder applications and the Fabrik visual programming system [Ingalls88]. Besides allowing for multiple views of a given model, the Model-View separation makes it easier to infer appropriate model structure from a given concrete assembly of UI components. It also turns out to provide a flexibility that is vital for migration of functionality between client and server where this is desired.

Figure 5, “An example MVC widget” shows a number of simple widgets arranged in a test panel. It is not much to look at as a picture, but if one runs the Lively Kernel from our site, one finds that the buttons, text boxes and lists are in groups that exhibit bidirectional coupling through their shared models. For instance the slider is hooked to a numerical model that is bidirectionally connected to one of the text views with a read/print converter.

We made the claim above that even a rudimentary assembly of widgets is the makings of open-ended computing. This should not surprise any of our readers, and we see in Figure 7, “Class browser in action” a piece of almost professional-looking software which is little more than an assembly of text boxes, lists, a clipping component, and the same slider shown in Figure 5, “An example MVC widget”, now doing service in (almost) vertical orientation as a scroll bar.

The Model-View separation can be applied to SVG data itself, as shown in Figure 6, “Built-in style editor”, demonstrating a simple style editor widget. A style editor can be invoked for every morph, and it can be considered a view observing parts of the SVG DOM as its model.

While visual editors are currently sufficient to control many aspects of visual appearance, other tools are necessary to modify the behavior of widgets and applications. Lively Kernel does currently not provide a full visual programming environment (although such an environment certainly lies within the interests of the project), but it does provide tools to directly edit the JavaScript code of running applications. Figure 7, “Class browser in action” presents a class browser inspecting an example clock widget. The class browser itself is obviously a fully functional widget, and, as shown, functions the same with arbitrary affine transformations applied to it. Saving edited code results in instantaneous updates to the clock's behavior. For instance, inserting a minus sign in the argument to the last call in the body of the method shown will cause the clock to start running backwards.

The code of function bodies presented to the programmer within the Lively Kernel can be simply obtained from many JavaScript implementations (using the toString() or toSource() methods of the Function object). However, such code is a result of decompilation, and does not include comments or custom formatting. Moreover, while new functions can be introduced and bound to existing object member names dynamically, such changes do not persist past the lifetime of the Lively Kernel instantiation.

Code persistence is implemented by a source code database, a component of the Lively Kernel. Currently the programmer can request interactively that function bodies be associated with the locations of their definitions in the source files used to instantiate the executing runtime. A fast scanner retrieves all the source files into the browser, locates all the method definitions and matches them with runtime function objects. When changes are made to a method definition, the source file containing the method is regenerated in the browser with the updated definition, and saved back to the server, subject to access control checks. Server-side code persistence is implemented using Lively Kernel's own implementation of the WebDAV protocol ([WebDAV], see the section called “SVG as a serialization format” for more details).

Thanks in no small part to the expressiveness and dynamicity of JavaScript and SVG, the Lively Kernel code base is compact, yet it provides an entire tool chain for graphics and application development and deployment, as well as for evolution of the system itself. Table 1, “Breakdown of the implementation code” demonstrates the lines of code used to implements various subsystems in a snapshot of Lively Kernel code base. Among those subsystems, Basic Graphics, Shape, Morphic Core Text and Editors directly depend on SVG. The remainder of this section concentrates on the dilemmas and solutions encountered while implementing the Lively Kernel SVG backend.

Lively Kernel takes a highly dynamic approach to interfacing with the SVG implementation. First of all, the entire SVG DOM tree is built dynamically on system load. The default entry point to the Lively Kernel runtime is a very simple static document defining only a single empty <svg> element, and all the SVG elements subsequently created by the system are its descendants. This element act as a canvas, on which the current WorldMorph displays itself. When a new world is entered, all the SVG elements used to represent it are (directly or indirectly) inserted into the DOM tree, and the old world's SVG elements are removed from it.

Lively Kernel uses an SVG <g> element to implement the HandMorph. As a result, the mouse cursor drawn by the windowing system is closely followed within the confines of the SVG canvas by a visual representation of the HandMorph, typically a small arrow shape. Such a choice may appear surprising, but it reflects the fact that multiple HandMorphs may interact with the same WorldMorph, and enables uniform handling of morphs residing in a world and morphs held by a HandMorph (in Morphic, morphs grabbed by a HandMorph are taken out of the world of residence). SVG supports changing and disabling the windowing system cursor entirely, and Lively Kernel provides programmatic bindings for this functionality.

The Morphic framework organizes visual objects on the screen using a tree of morphs. Each morph has a single owner morph and can act as a container for other morphs. The SVG backend of Lively Kernel naturally maps morphs onto SVG <g> elements. The semantics of <g> elements corresponds well to the semantics of Morphic, specifically, the nesting of <g> elements is a means of logical organization and does not imply visual containment, and submorphs are not necessarily visually contained inside their owner morphs, either. A morph's shape is represented by one of the basic SVG shape elements, such as <rect>, <ellipse>, or <path>.

Currently, Lively Kernel does not take advantage of the property inheritance mechanism of <g> elements provided by the SVG specification, and each basic shape element is required to specify the full set of its visual attributes. This feature of the SVG standard could be used to improve space utilization, or offer a mechanism to specify widget "skins".

The Lively Kernel SVG backend allocates a private <defs> element to every morph. The SVG specification designates <defs> elements as containers for elements that are not directly rendered on the screen, such as gradients or clip paths. These elements are typically referred to by URI attributes on other elements (the SVG standard makes extensive use of URI references to express relations between elements that are not captured by the DOM tree hierarchy). This design facilitates space optimizations through sharing of commonly used elements, however, Lively Kernel does not currently take advantage of it. Instead, all the elements in a morph's <defs> section are notionally owned by the morph, and the URIs of these elements are trivially derived from the URI of the morph's <g> element. As a result, every morph defines all the gradients it uses, even though a typical user interface uses only a handful of distinct gradient definitions that could be shared and applied to multiple visual elements. This may be perceived as a shortcoming of the current SVG backend, however, the presented technique does simplify certain implementation aspects, most notably copying and serialization of individual morphs. We envision that a future version of our system could implement gradient sharing, most likely through a uniform reference counting facility for all SVG elements referenced through URIs.

There are at least two general methods of implementing the mapping of abstract tree data structures, such as the morph tree defined by the Morphic API, to DOM trees. The first involves extending appropriate DOM elements so that they become morphs. This was the method originally used by the Lively Kernel SVG backend. Despite its conceptual simplicity, it required certain non-obvious implementation techniques. For instance, while all morphs were mapped to <g> elements, the converse was not deemed appropriate: not all <g> elements should be morphs. In order to satisfy this requirement, morph factory methods dynamically modified the inheritance chain of <g> elements intended to become morphs, by inserting a morph prototype object, defining the functionality shared by all morphs. Such modifications are not possible according to the ECMAScript language specification (an object's prototype is generally not accessible programmatically), although most JavaScript implementations recognize this problem as a language limitation, and make the object prototype accessible through a mutable __proto__ property that can be manipulated to obtain the desired inheritance behavior. Unfortunately, this approach eliminated the Opera browser from the list of potential Lively Kernel platforms, since its JavaScript engine does not implement __proto__.

Another minor inconvenience of this approach was that new morphs were instantiated using factory methods of the form MyMorph(), instead of explicit allocation syntax, as in new MyMorph(). A much more important limitation turned out to be the incompatibility with environments such as Batik ([Batik]), which support the __proto__ property but do not allow extension of host objects (i.e., objects created and managed outside of the JavaScript runtime, such as DOM objects, and merely exposed programmatically to JavaScript).

In the face of such limitations, the subsequent reimplementation of the Lively Kernel SVG backend uses a more conventional implementation technique based on wrappers. Morphs are implemented as regular, user-defined JavaScript objects furnished with a rawNode property, pointing to the host object representing the corresponding <g> element. Similarly, Shape objects wrap simple SVG shape elements referred to through their rawNode property. No new properties or methods are added to host objects, and many Morph and Shape methods simply delegate to the underlying rawNode. Unfortunately, the object identity of the Morph is now distinct from the identity of the underlying rawNode, which requires additional boilerplate code to map from Morphs to DOM objects. Interestingly, other than while debugging, it is currently never necessary to find a corresponding Morph given the DOM element that implements it, is due largely to the fact that Lively Kernel performs its own mouse event delivery. The wrapper technique itself is well known, in particular the Dojo toolkit [Dojo] uses a similar approach for its cross-platform graphics library dojo.gfx, and Lively Kernel even borrows its convention of naming the underlying DOM element rawNode.

Lively Kernel does not currently use several features of the SVG specification. Most notably, it does not use declarative animations, due both to lack of support in many browsers, and to our interest in portability of the implementation to other graphics backends. Instead, a simple imperative framework for scheduling and periodic invocation of user-supplied actions is provided. Document styling (through either CSS or Extensible Stylesheet Language (XSL) standards) is not currently used, either, although useful applications of styling can be envisioned. For instance, styling could be used to implement UI themes, i.e., sets of visually coherent presentation attributes that can be applied to a widget or application at the user's discretion. UI themes are already supported by Lively Kernel, although browser support for styling is not leveraged.

Another platform feature not used by Lively Kernel is mouse event delivery. Instead of registering event handlers on individual SVG elements, the HandMorph registers a single input event handler in the capture phase of DOM event delivery. The handler determines the morph that should receive the event based on the coordinates contained in the event object and and geometry information obtained by inspecting the morph tree. While Lively Kernel duplicates in JavaScript some of the mechanisms implemented natively by the DOM, event delivery is not usually performance-critical, and the resulting codebase is more easily portable to graphics backends not based on a DOM.

No authoring environment would be complete without a way to save the results to a persistent form, and Lively Kernel addresses this requirement by providing a simple WebDAV protocol client implemented in JavaScript. The client is built on top of asynchronous HTTP networking support present in all the modern browsers in form of the XmlHttpRequest object. Rather than use one of the several JavaScript frameworks, Lively Kernel provides its own XmlHttpRequest wrapper, which leverages the asynchronous model update notification mechanism used in other parts of the system. Naturally, the WebDAV protocol has to be implemented and enabled on the Web server hosting the Lively Kernel installation. Due to the single origin security policy implemented by web browsers (and in absence of server side proxies), the WebDAV client can only save files to the website from which the current runtime has been loaded.

Lively Kernel is able to save not only static JavaScript files and SVG documents, it can also save snapshots of its own active worlds. Such snapshots can later be loaded into a running Lively Kernel, and their contents manipulated as any other Lively Kernel object. Moreover, the snapshot files are active Web pages themselves, and, when loaded by a supported Web browser, instantiate a new Lively Kernel runtime and recreate the worlds contained therein. When the JavaScript runtime is not available (because JavaScript execution is disabled or the required JavaScript files cannot be found), the snapshot Web page is simply rendered as a static screenshot of the active world at the time the save operation was performed.

Saving and restoring Lively Kernel objects is supported in several different modes. A single morph can be saved into a Web page inside a fresh new world simply by selecting an item from its contextual menu and following on-screen dialogs. A Web page with a world of objects can be loaded into a new separate world, or its content merged into the current world. Currently these options are available through contextual menus of the standard Lively Kernel WebDAV-based file browser.

The format of the Web pages containing saved Lively Kernel worlds is that of SVG, extended with Lively Kernel-specific annotations. Those annotations contain enough state information to recreate JavaScript objects on page load (when the JavaScript runtime cannot be instantiated, the annotations are ignored and a static SVG image is rendered). Thus, Lively Kernel effectively implements JavaScript object serialization and deserialization to implement saving and restoring worlds. It is worth emphasizing that the serialization protocol is not orthogonal and does not perform reachability analysis on the object being serialized. This is a conscious choice, dictated both by the intent to avoid accidental serialization of large parts of the runtime, and the interest to promote Lively's MVC architecture. By design, when a morph is serialized, all its submorphs will be serialized, and all the object references inside the submorph tree will be saved and restored correctly. If the morph functions as a view and is connected to a model, the model will also be serialized. If other (non-graphical) views are connected to the model, the class names of these views and the details of their hookup into the model will also be saved. However, no other state will be saved or restored for non-graphical views. It is therefore the responsibility of the non-graphical views to store persistent state in the model, and non-conforming views will not be properly restored on deserialization. The above approach to serialization proved to be sufficient to serialize several complex widgets in the Lively Kernel distribution, however, a more expressive mechanism may be devised in the future to deal with larger applications.

Note that the project's interest in supporting multiple graphics backends does not invalidate the choice of SVG as the graphics component of the serialization format. Clearly, an entirely new, Lively Kernel-specific serialization format could be devised, but then, for every n graphics backends n translation mechanisms would be required. With SVG as the format choice, only n - 1 translation mechanisms are necessary.

The SVG standard is perfectly suited as a foundation for alternative Web programming environments, as the Lively Kernel project demonstrates. We hope that as the availability and performance of SVG implementations increases, so will the interest in light-weight, self-sustaining, Web-based graphics editors and integrated development environments. Lively Kernel, while currently only a prototype, shows that this is possible in a single, coherent framework.