Server-Side Javascript

Loose notes from SXSW 2010 session Javascript: The Front and the Back of It, on using server-side Javascript to reduce the pain points of the few non-DRY areas left in MVC stacks.

Recommending an alternative to MVC

In between the front and the back end is the MIDDLE end. In b/w presentational JS (Jquery) and your back-end stack. This is the code that makes a Web 2.0 app snappy. Hasn’t gotten a lot of focus.

Old school architecture: Usually MVC:
Client -> Web -> Web server -> Controller/App logic -> View/Templates

To control the experience, we have to have a pretty thick/complex JS layer. You might even have a JS representation of MVC.

WordPress – Good CMS but if you try to optimize performance, you have no control over the markup that goes out to the browser (not in terms of what order JS loads in, for example).

The DRY principle (Do Not Repeat Yourself) (yeah yeah, from the Django world). This is hard to maintain when you add a javascript UI layer that needs to do form validation when your back-end can already do it. If a new rule is added, you need to update validation code in two places.

So we need a new mode: CVC: Clients, Views, Controllers. More decoupled and modular.

App (black box): Doesn’t know anything about the presentation model. Only understands state mode and data, with a JSON API. It’s a headless app.
UI Controllers -> Web Server -> View -> Web

So you write the code once and run it in both places (still not understanding how this is possible).
It’s possible because you actually write the view layer in Javascript.
Controllers request stuff from the app (black box).
Your app is a state-management machine. Sessions, everything starts in Javascript.

Clients: Everything is a client of everthing else. Decoupled, modular, scalable

Views: Templating, portable, DRY, platform agnostic, core web technology.

Even the controllers are written in Javascript. Javascript is the only language that is truly platform agnostic and ubiquitous.

NOT suggesting another framework. This is not a system that does anything automatically for you. These are reference implementations. Not suggesting that you ditch the whole architecture (ha ha). No – just take the view portion and decouple it into JS. MVC is good, but it does have problems. From a UI/architecture standpoint, this solves a common problem.

AM suggesting: It’s OK to rethink, go back and ask questions that no one is asking. JS can feel like a fish out of water, especially when it’s on the server.

How? node.js (wrapper around the V8 engine, which is also what’s in the Chrome browser). Installs in 5 minutes in Linux. JS environments are not executable, which is why they need a wrapper. Narwhal is wrapped around rhino. You can replace your web server with 20 lines of Javascript to get the node.js wrapper executing web requests. Also: JavascriptCore, SpiderMonkey, etc.

CommonJS (aka ServerJS). “Javascript on the server is a reality – it’s happening, but how do we formalize process like files, i/o, processes, networking”. CommonJS proposes standards for how all the wrappers above will interop with a server environment. This stuff is so new, it’s like the wild wild west. People want to adhere to standards but there aren’t standards yet.

His proposal: BikechainJS: V8 plus modules

CVC + Javascript = the power of UI architecture in teh hands of front-end engines.
HandlebarJS – templating language. No math, no methods. Very minimal. Gets its name from {} convention. Text/HTML templates use JSON for data input.

Just as Javascript is the only lang that can run everywhere, JSON is the only data format that can transfer everywhere. (Huhn???)

Application “state” selects templates. “Compiles” templates into JS.

Demo? – all written in server-side javascript

Leave a Reply

Your email address will not be published. Required fields are marked *