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.
Aside from that, I'm sure this is all controllable in the framework, but there are maddening 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.
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.
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.
The whole codebase is a mess and so damn slow that this is not usable at all (see https://aaron-mueller.de/blog/bestof-lively). 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.)
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.
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).
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. )
The common usage of the term does make that come to mind. However, kernel just means the central part of things. The bottom-most layer in computing. Relevant for your definition, a whole sector of operating systems are microkernel-based: almost everything in Linux/BSD are merely user-mode processes for such systems, running on a tiny kernel.
For instance, the basic runtime management modules that the Erlang VM starts as its first application is also called the kernel: http://erlang.org/doc/man/kernel_app.html
(Erlang can be described as a special-purpose OS in many ways, so it makes sense.)
Yes. They say the same about browsers, too, which is why secure browsers have a "kernel" that mediates everything. Additionally, in High-Performance Computing, the highly-optimized routines that do much of the work are often called kernels. It's a very overloaded term.
I'm not sure I'm parsing your comment correctly; it seems you're asserting that Linux and BSD kernels are microkernels?
That is most certainly not the case. There are very many features in the Linux kernel that are not typically in a microkernel, including and not limited to networking, fliesystems, and capability systems.
The point is that people using Linux/BSD consider those "kernel" functions while microkernel-based OS's (eg QNX, MINIX 3) have same stuff running as isolated, user-mode processes. To them, a kernel is a component with a dozen or so function calls that facilitates and restricts operation of user-mode stuff. All the real functionality are just apps running in processes. Another tie-in to BSD is that fact that both QNX and MINIX 3 pull NetBSD code into their systems... in user-mode processes.
So, the point is that a "kernel" thing to people exposed to Linux/BSD isn't kernel to others. The usage is often based on perception with only consistency between all usages is that what they call kernel is at the core of their system. And for OS's, often the most privileged as it runs in kernel mode.
Aside from that, I'm sure this is all controllable in the framework, but there are maddening 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.
[1] http://lively-kernel.org/repository/webwerkstatt/sandbox/san...