[General] King of Lively part II : LIE and CHEAT
Dan.Ingalls at Sun.com
Sun Nov 15 20:41:50 CET 2009
Great post, Owen!
>This is not specific, but fairly general. A strategy.
>I believe LK should join the rapid JS revolution: server side, client
>side, and communication between the two.
Yes, I agree.
But there is another revolution around collaboration, by which I mean
multiple users in the same space, that may be a closer match to LK's
strengths. We should definitely encourage both for now.
>Server Side: From the day of Steve Yegge's Rhino On Rails post, a
>flood of server side JS stunts have been flourishing.
>Aptana's Jaxer, with a DOM on the server side, and now Google App
>Engine supporting Rhino. Why is this happening? History. Us old-
>timers are used to desktop programming. But the *average* programmer
>is young and web centric. Proof? Look at Adobe's AIR which uses JS,
>CSS/HTML, DOM to create desktop apps! Yup .. migration of web tech to
>desk tech. And its pretty impressive.
Necessity is the mother of invention. By which I mean that the way for
us to make progress on the server side is to have a need for the server
side. Or, equally effective, a passion to pull of a cool demo on the
By the way, with regard to the DOM, Krzysztof's cool 1-week port of
that was originally done by Dan Amelang as a way to couple some
experimental graphics to LK. The code is in EmuDom.js.
>Client Side: Yes, script kiddies have used snippets to make pages
>horrid for years. But since the rise of brilliant JS practitioners
>(John Resig, Douglas Crockford, and more) .. including LK .. people
>recognize JS's power, simplicity, and sophistication. The Browser has
>made JS the dominant language, period. Its everywhere. With Doug's
>"JS the good parts" book, snobs like me have been converted. And
>Rhino being built into the Java release has made JS outside the
>browser popular. Flash is JS++. And more systems are becoming JS
>based daily. And with Chrome and other really fast JS implementations,
>performance is less and less an issue daily.
Yup. Indeed, the faster JS engines are making real the characterization
of JS as the assembly language of the Internet. It is just good enough,
and now just fast enough, to make it reasonable to compile lots of
our favorite languages to JS.
>Communication: This is the sleeper: JSON. XML was the ugly duckling
>for quite a while for client-server communication .. the X in AJAX.
>But now savvy programmers are sending JSON back & forth, needing no
>parsing .. eval the payload and you get a native JS data structure!
Absolutely. I have wanted to make this shift almost since we started.
I always thought the Smalltalk approach to serialization is nice, and
JSON is an even cleaner and more consistent job.
>Libraries: I might as well include these too. What is a JS library?
>A URL. You simply can't have easier deployment. And a HUGE number of
>libraries are being converted to JS. Processing, for example now has
>a ProcessingJS (Resig).
Yes. And this is something we need to press on. It would be so
easy to just go through our files and separate the kernel from the rest
and then crunch it into one or two simple files.
>So gone is PHP-XML-JS-Classpath and always forgetting which language
>you are using. JS has unified the whole client-server-communication
>life cycle. And it has turned deployment into HTTP. This is almost
>impossible to believe! I study Complex Adaptive Systems and this
>emergent phenomenon is hard even for me to believe! Prisoner's
>Dilemma heck, look at the JS ecology.
Well, it's not so amazing to me because we have a lot of pressure
going from smart people who know that it *can* be simple, and it
*can* be general, and they're all trying to figure out how to evolve
into a better world. And guess what? Enough smart people
with enough motivation will finally figure out how to, as you put it,
turn deployment into HTTP ;-).
>This unification is important. I built an early GAE web app, using
>Google Maps, their Big Tables, Django for the server, JS for the
>client, a bloody blend of XML and JSON, and so on. Painful!
This is just what I have been doing recently: using LK in the role of
Dojo to implement a couple of views in conventional HTML.
It was Steve Uhler who pushed for this, and Robert Krahn who
built the first demo -- check out...
It's just a sketch, but it shows three Lively Kernel worlds embedded
in HTML, and inter-operating so, eg, an HTML input can control
the time zone of a clock or the number of cylinders on the engine.
>So what does that have to do with LK? Strategy. I don't know how to
>do it, but building a part of the JS ecology/revolution above would be
>absfab. Downside: you'll now have to fit in with the rest of the
>crowd. That is often difficult, architecturally. How to avoid
>conflicts. How to factor LK so that it can be used with or without
So, as you see above, much of the work has been done already,
although, as with LK in general, only through proof of concept.
I agree with your strategy, plus I still want to include a couple of
other synergies (Caja and collaboration at least, plus some
high performance solution).
I've been feeling it's time to take it all apart and start over, but maybe
it's also time to put together a set of demos using what we have
to map out and demonstrate our place in the new world.
One demo I've been wanting to do (mentioned earlier) is a
truly performant port to O3D or JavaFX that can run in any
browser including (sigh) IE.
>But its the direction I would take. I'd get Resig and Crockford on
>the phone and chat strategy. I left Data Base out of the above but if
>you need to spin it for the New Sun (how's it going, btw), JS+JSON+DB
>is a great story. It certainly not hard to convince folks XML is
I think that including databases is relatively easy at this point.
Steve Uhler has been playing around with this, and you're absolutely
right that that's a big market, and one that I think is starved for
And with regard to your "how's it going", you can read the news
as well as I regarding the high order bit. For the LK project, it has
been rough, as I'm the only person remaining, though Robert,
Krzysztof and Steve will always lend a hand if I ask. That's what led
me to call for workers, and it has been great just to hear voices out
there. I think something big is coming, and I still want to play.
I agree absolutely about alignment with Crockford, Resig and,
looking forward, Mark Miller's work.
Again thanks for your strategic thoughts and your enthusiasm in general.
More information about the lively-kernel