JavaScript in the cloud

thanks to flowerhouse on flickr

The idea of running JavaScript on the server has been around for a while now (think Jaxer back in 2008), but it recently got a big boost with the featuring of Node.js at JSConf in November 2009. Node.js found immediate fame by demonstrating blinding performance as a web server, and by building on the hotly hyped V8 JavaScript engine Google bundled with Chrome.

I have a big interest in server-side JavaScript (SSJS) because I generally code in the browser and would enjoy being able to make things happen on a server without having to resort to another language. The ideal would be to take client-side code and run it unchanged on a server. The last step is pain-free application hosting – call it “Platform as a service” for want of a less boring name.

Over a year ago, Joyent bought Reasonably Smart, a cloud provider of SSJS, and subsequently transmuted it into Smart Platform, which runs on their distributed infrastructure. This followed the shining example of Heroku and Google App Engine, in that application deployment became a matter of pushing some new code to a Git repository online. For me, this was fantastically attractive, as I avoid touching servers as much as realistically possible. They came out with Smart Platform shortly before the demise of AppJet’s free service, which I had been happily trying for a while, as it did much the same thing.

Nearly a year on, and Smart Platform hasn’t really taken off, if Google Trends is anything to go by. And my ambitions to run my entire web estate on identical server-side and client-side code have rather fallen by the way-side. I am happy to see that Smart Platform now has a permanent full-time coder (@konobi), who is making Smart Platform play nicely with the CommonJS spec for server-side JS, but I don’t yet know when Joyent are going to drop a new release, or where they’re going with it.

Enter Node.js. The interest in Node.js has stayed high since its November launch, with developers building an assortment of frameworks and tools on top of it or with it, in effect legitimising it as a serious development environment for software running on a server.

Of significant interest to me is the jsdom project, which brings the browser environment to Node.js in a similar way to how Env.js brought it to Rhino (and Ruby). Env.js has supported jQuery since the get-go, and there are rumblings of jQuery support in Node.js via jsdom. Both these situations inspire joy as, if they pan out successfully, I’ll be able to use one methodology for writing and testing JavaScript applications, whether they run in the browser or on the server. Unfortunately, I’ve not seen Env.js working on any hosted platform (although Smart Platform may get it soon).

The number of cloud providers for Node.js has increased from 0 to 2 very recently: Heroku has announced a very experimental Node.js stack, and ElusiveHippo is in development, releasing accounts slowly. I should probably also mention that Ryan Dahl (who created Node.js) works for Joyent, so I wouldn’t be suprised if a Smart Platform-style service came out for Node.js.

Now then, if Coda starts supporting Git, or I start doing all my code editing in Bespin, I think with a bit of fairy-dust I’m going to have a pretty slick JavaScript-only setup fairly soon…

About these ads

8 Comments

  1. DE
    Posted May 4, 2010 at 9:37 pm | Permalink

    If Heroku like it, maybe I should look at Node.js.

    But remember, god never intended us to run javascript on the server. (Matthew 10:12)

  2. Posted May 5, 2010 at 7:46 am | Permalink

    As mentioned elsewhere, I’m not particularly keen on SSJS myself. However, the innovation is of course welcome, not least because it helps efforts like CommonJS gain traction.

    Regarding reuse of client-side code on the server, I’m not sure how realistic that really is. While working on chrjs, I realized that this is trickier than it first appears, even with proper modularization/encapsulation, as the requirements can be quite different.

    Since you mentioned jsdom and env.js, do you have any experience running JavaScript tests outside the browser (headless, via the command line)?

  3. fabus
    Posted August 12, 2010 at 5:23 pm | Permalink

    Did you have a look at couchdb and couchapp? A smooth way to build an entire database backed webapp using javascript only.

  4. Chris jacob
    Posted August 18, 2010 at 4:05 pm | Permalink

    Dude this article helped answer so many questions for me. Thank you!

    Have there been any recent developments in SSJS that you have seen lately?

    I’m interested after reading google’s spec for making AJAX content crawlable http://code.google.com/web/ajaxcrawling/docs/specification.html

    My app is hosted on Heroku… And their support guys don’t see a way of getting a “headless browser” available (required to serve HTML snapshots to googlebot after js on the page has been processed).

    I’m thinking SSJS might be a possibility – preferably having the same code base for the client side js and server side js.

    I haven’t played with Node.js, Johnson or Env.js … But might have a play soon… Hopefully Heroku hosting will be possible.

    Again thanks for the post.

    -Chris

    • Posted August 19, 2010 at 2:07 pm | Permalink

      Hi Chris, glad you got something out of the post.

      I’d not heard of Johnson before – here’s the project link: http://github.com/jbarnette/johnson

      I’m really hoping that I will wake up one day to find that someone has made a server-side JS with fully functional DOM.

      J.

      • Posted August 19, 2010 at 2:18 pm | Permalink

        FWIW, I just spoke with Mike, and he recommended I look into jsdom for my efforts at getting a minimal, pure-JavaScript testing framework – the expectation being that jsdom is now more mature than it used to be (in contrast, Envjs still seems very dependent on Rhino).
        It sounds promising, but I haven’t had time to dig into it yet.

      • Chris Jacob
        Posted August 22, 2010 at 11:47 pm | Permalink

        While it doesn’t really suit your requirements it’s (kinda) SSJS … HTMLUnit.

        You might be interested in my post re: an alternative to google’s #! for crawlable AJAX content…

        http://code.google.com/p/gwt-platform/issues/detail?id=1#c31

      • Posted August 25, 2010 at 12:52 pm | Permalink

        Hey, that’s a really good idea. In fact, I’ve done exactly what you propose – manually – each time I’ve turned a non-AJAZ site into an AJAZ site.


One Trackback/Pingback

  1. [...] it comes to servers. To avoid dealing with servers in any traditional sense, I have been keeping an eager eye on how things are going with server-side JavaScript, and the push-to-deploy type of application [...]

Follow

Get every new post delivered to your Inbox.