Steve does his thing, and goes in glorious directions, such as how we end up with a scriptable back end, how the JVM matters as a host for these things, SchemeScript, how defineProperty gets around the for .. in issues, “Who likes to write their own giant deterministic finite automata to do string matching? Heh. It’s weird â€” nobody raised their hand.”, obj = {run: function() { print(‘hi’) }}, RnR (Rhino’s not Ruby), “And Scala’s interesting because it actually takes a functional static type system and it layers… it merges it with Java’s object-oriented type system, to produce…. Frankenstein’s Monster.”, and man it just keeps going and going.

I have a feeling that server side JavaScript will become a compelling reality in the not too distant future, even despite the early false start of the overly eager Netscape folks. There’s no good reason why pages shouldn’t be built and updated on either side of the client-server divide using the same language… and even the same JS framework!

I propose, at the very least, a thin server-side presentation layer that can allow for the exchange and shared use of JavaScript templates (ala C# aspx code in front, or JSP), allowing updates to be used on both sides of the fence. The JavaScript presentation layer hosted on the server side can receive input through a narrow interface from a language layer more appropriate to the coding of complex business logic. Presentation logic should not be digging into databases and such, anyway, so enforcing a thin data transfer interface between business logic and server-side presentation logic implemented in JavaScript would make for a reasonable architecture. UI engineers typically want to work their stuff on both sides of the client-server divide – building pages on the server side, and updating them on the client side – but don’t typically want to go very deep into how business logic is implemented… or optimized.

re: server-side javascript… Adding more fuel to the momentum behind applications built from server-side javascript. Aptana’s got the Jaxer project going strong now. Jaxer is a open source Ajax server. It’s a very cool and powerful concept: Use the same engine that’s in browsers as the core for a server so that there’s a parity of environments on both sides. Jaxer uses Mozilla’s browser engine on the server-side to enable not just server-side javascript (via SpiderMonkey) but also server-side DOM manipulation, DB, filesystem, network access, server-sessions, etc… (and oh yeah, interfaces to Java via DWR and other means are in process too). It’s cool how you can just tell the script to runat=”server”, runat=”client”, runat=”both”, runat=”server-proxy”, etc… to write both client-side and server-side logic in the same page. Check Jaxer out at http://www.aptana.com/jaxer

Jaxer is very cool — and there are already JavaScript templating plugins for most major frameworks. It is simple to separate business logic and presentation, it’s just a matter of proper coding. I don’t see the need for “C# aspx code in front, or JSP” at all — bring on the powerful JS on server! Furthermore, I would be interested to see how Mascara will work serverside, to make the more complex programs even more manageable.