Comments on: Steve Yegge on Server Side JavaScript

By: holts

holts — Mon, 16 Jun 2008 22:45:02 +0000

…dynamic languages make a lot of sense for a large class of applications… especially on the web. Steve Yegge carries that torch better than anyone with his detailed perspectives.

By: ilazarte

ilazarte — Mon, 16 Jun 2008 19:23:36 +0000

1 million lines of a code.. a dubious honor.

By: doublerebel

doublerebel — Mon, 16 Jun 2008 19:17:26 +0000

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.

By: khakman2

khakman2 — Mon, 16 Jun 2008 16:30:47 +0000

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

By: uize

uize — Mon, 16 Jun 2008 09:55:03 +0000

Well, that was entertaining enough to keep me up till 3am.

By: uize

uize — Mon, 16 Jun 2008 08:49:50 +0000

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.