And now that I'm past my surprise, I can evaluate. It looks like it's really not ready for production. There are all kinds of weird issues. For instance, in the webworkerstatt sandbox[1] (and I was using Chrome as they asked), the text box rendered far-right more than a page of scrolling was required. Upon refreshing the page, the text box was where it was supposed to be, but there was lots of additional empty space (empty content that cause scrollbars to be present) below and to the right of the application. Also in that app, positioning the cursor inside the textbox then clicking on the "car" (that cluster of ovals) causes text to be selected between the two points you just clicked.<p>Aside from that, I'm sure this is all controllable in the framework, but there are <i>maddening</i> design choices. They are intercepting right-clicks. They are by-default opening links in new windows. Every bit of text is in carat mode. The loading animation is rather annoying. With all of this, I'm not even going to look at what it's like to develop in the environment.<p>[1] <a href="http://lively-kernel.org/repository/webwerkstatt/sandbox/sandbox.xhtml" rel="nofollow">http://lively-kernel.org/repository/webwerkstatt/sandbox/san...</a>
It's pretty interesting how they use SVG to draw it all on-screen to emulate desktop UI's. That's basically how I did cross-platform in late 90's with OpenGL as my targets supported it. I also tried Java, which they [1] did too. That they reused Morphic was clever as most would've tried a vanilla interface framework. The use of SVG would seem to be both a strength and a weakness. Strength for reasons they outlined but weakeness in terms of speed and browser interactions. I saw both problems in the demo, with the latter being text highlighting when dragging a window.<p>So, I still push native apps and plugins over web where possible. This one is clever but I'd like to see some smooth demos. However, the WebGL standard might be a solution to this as I haven't heard anyone complain about it lagging on simple 2D operations. Maybe they try that out.<p>[1] <a href="http://www.svgopen.org/2008/papers/93-The_Lively_Kernel_Web_Application_Framework/" rel="nofollow">http://www.svgopen.org/2008/papers/93-The_Lively_Kernel_Web_...</a>
I've analyzed the codebase a couple of years ago (see <a href="https://aaron-mueller.de/projekte/lively" rel="nofollow">https://aaron-mueller.de/projekte/lively</a> and <a href="http://data.datenhalter.de/lively_analyse_morph.pdf" rel="nofollow">http://data.datenhalter.de/lively_analyse_morph.pdf</a> in german). It's basically a proof of concept to bring Squeak to the web. It was a hype back in 2007 because Dan Ingalls pushed this as a research project by SUN.<p>The whole codebase is a mess and so damn slow that this is not usable at all (see <a href="https://aaron-mueller.de/blog/bestof-lively" rel="nofollow">https://aaron-mueller.de/blog/bestof-lively</a>). The architecture however is pretty smart, but most of it are stolen from Squeak. So the projekt itself is not much more than a bad port of Squeak in spathetti JavaScript.
When I studied at HPI I had a course where we would hack on features for the Lively Kernel. I'm not sure how far they've come and if they got the performance problems solved. (Lively used to work at halfway acceptable speeds in Chrome and Safari only, but I'm not sure if this was because of Webkit or the JavaScript engine.)<p>I have to admit, I didn't like it much. I couldn't wrap my brain around why I should create a live coding environment which would be destroyed on a reload. Then it is only used as a fancy REPL.<p>For my day to day programming I prefer regular JavaScript or languages which compile to JavaScript.
The word kernel is so espoused to operating systems for me that seeing the nature of the project was surprising. In fact, I specifically expected to see some modified Linux kernel and was wondering if someone made use of some liveliness-guaranteed locking system of some sort. After the surprise, I thought about my personal definition of "kernel", and it turns out it's as outlined below (ones in parentheses would never be expected, but would be concessions after having been surprised, as I was with this article).<p>1: Linux Kernel. 2: BSD-derivative kernel. 3: Some other Unix kernel. 4: Some other OS kernel. ( 5: Maize seeds. 6: Some core part of other software. )