Server-Side Javascript: Back With a Vengeance - Page 3
The Cloud. Of Course, the Cloud!
No article on server trends could ignore the famous cloud. How does javascript work in virtualised computing environments? With a suitable engine, you can certainly set up an environment manually using amazon EC2, google app engine, or similar cloud hosts. However, you can do it easier than that with some of the other solutions around. Joyent took a big bet on Javascript when it acquired Reasonably Smart earlier this year; the host now offers a dead-simple runway to host Javascript scaleably. Aptana, the company behind the Jaxer platform described above, does likewise.
Something's Going on Here
Before we get too excited about this trend, I should make one thing clear. Conspicuous by their absence are the real-world server-side Javascript apps. There don't appear to be many sites running Javascript in the server at this time. Probably the most popular site powered by Javascript is EtherPad, the real-time collaborative notepad from AppJet, the company acquired by Google last week. This is a cautionary example, because AppJet launched as a cloud-based server-side Javascript framework before dropping it to concentrate on Etherpad. Aptana has also announced they are pulling back on Jaxer due to difficulties monetising it. Maybe this is more of a statement about cloud hosting revenue models than server-side Javascript, but it's worth asking how other attempts to propagate server-side Javascript will fare.
One of the critical success factors will be a comprehensive standard API; it's a prerequisite to a vibrant ecosystem of interoperable components, and with a range of engines to run on. We now have the seeds of that with commonJS. Another factor is best practices for using the language; again, we've already discovered much of that as a side benefit of the Ajax revolution. Frameworks like Node, which build on Javascript's unique characteristics, are building on those to establish best practices for server-side Javascript. Reuse of both knowledge and practices will give Javascript its best chance yet to stand up as a viable alternative to the usual server-side suspects.
Although Javascript is a far better language than was previously assumed, its syntax still has plenty of quirks. If we restrict ourselves to the subset of Javascript found in all the major browsers today - and arguably it makes sense to do so - it's arguably lacking certain features of other server-side languages. Those other languages are free to evolve autonomously; in contrast, Javascript's fate is heavily determined by standards bodies, browser manufacturers, and the patterns around how users upgrade their browser.
In this sense, the language's strength - shipping with every browser - is also an Achilles' Heel. That said, the language may well prove "good enough". The benefits of "one language all the way down" may outweigh the cost in many cases. The will is stronger than ever to make server-side Javascript a reality, and it's translating into a visible surge of activity in the web community. There's the promise of code reuse and the possibility of cutting in half the number of programming languages involved in building a typical web application.
Many smart developers have gravitated towards Javascript in recent years, as a means of producing world-class front-end apps. The attention has progressed our understanding of the language. Should server-side Javascript go mainstream, a third wave of Javascript developers will be joining the community and enriching the ecosystem.
Photo by Dmitry Baranovskiy
Share
Facebook
Comments
Subscribe to comments for this post OR Subscribe to comments for all ReadWriteWeb posts
The usage of server-side js is quite confusing to me, actually.
@kurs, it really isn't that confusing. here are two examples (two i happen to use pretty frequently)
rhino: http://www.mozilla.org/rhino/, a javascript engine on top of java to do server-side javascript (great for adding a scripting feature into java applications)
couchdb: http://couchdb.apache.org (one of the no-sql databases, uses javascript as its query language, its really awesome)
MS did have jscript and asp classic back before the .net days and it can still be used now but not sure you would want too.
The world needs one of the big players to invest in it before it gets taken seriously. Maybe Mozilla could do it.
other popular tech like PHP and ROR where made popular by their ease of use and their low cost to host.
The main problem I see for any new web dev platform is its a crowded market and developers already have the tools and communities based around them.
I'm glad no one brought up BroadVision. Oh, wait, I just did.
Agree with kurs, yeah...this hurts my head.
If they can make it as simple as using jQuery, I wouldn't fear this unknown quite so much.
It's useless to hope that this just goes away and we can use our current language/tech of choice. 10 years from now, the stuff we'll be doing will make the stuff we're doing today seem like the stuff from 10 years ago. That is, of course, if Google hasn't obviated the need for anybody else to do anything on the web except for blink a picture with their implant cam and think a message and a URL to tell the world where it can be microwaved to their frontal lobes.
Cheers,
Byron
Server-side Java Scripting, is really difficult. I was working on a project on the same and I was completely confused. Didn't work good for me.
I started following the Node and CommonJS Google Groups recently and am very impressed with the energy going on behind both efforts. There are some really smart people making sound decisions about how to structure the projects. I think server-side JavaScript has a bright future, but there is some evolution that naturally has to take place before it becomes commonplace.
Posted by: segdeha.com
|
December 17, 2009 10:50 PM
In the 21st century, application development really shouldn't require anything but the bare minimum of server-side programming: just enough to fetch, validate and save data. Most of that stuff people currently spend time programming (in whatever language) can and should be automated. eg http://www.mgateway.com/ewdDemo.html for an example of what I mean.
I think the author forgot to mention one important server-side JavaScript app - The Opera browser.
Opera Unite, which is essentially a web/application server in Opera, uses JavaScript as its scripting language. This could lead to more momentum on server-side JS, as Unite has a relatively large user-base already - most Opera users update frequently.
While it's not a solution for hosting big websites, it does do a very impressive job of allowing people to share files, stream audio, or even play online games with each other, with the server being their own PC.
Prototypal inheritance is nice. So is lambda programming. Oh - and so is evented, non-blocking I/O.
node.js === WIN!
http://blip.tv/file/2899135
Another solution for Server Side JavaScript is AppEngineJS:
www.appenginejs.org
based on Narwhal/CommonJS.
I wonder if anyone else remembers PowerDynamo?
http://www.sybase.com/detail?id=44609
Server-side JavaScript way before its time.
Nice post !
You missed the Wakanda SSJS Project presented at the Ajax Experience and the JSConf.eu 2009 ;-)
It is providing most of the technologies you quoted :
- SquirrelFish Extreme engine
- some CommonJS API (like Module),
- a native JavaScript database (NoSQL)
- a REST Data Services in JSON format,
- JSON-RPC server & client
But true that it's not yet downloadable
(coming for 1st quarter 2010... )
http://www.wakandasoftware.com
To go along with Darren... Back around 2000, I coded JScript in classic ASP to great effect. At the time, it was fun to try something 'different'. I was delighted to discover its 'prototype' object along with other dynamic and object-oriented(ish) features. We eventually had it handling a data access layer in a very generic/dynamic manner. Not sure something like that is even possible in VBScript. Pity it didn't catch on, but with very few code examples available (relative to vbscript) it's not surprising.
Arguing that Javascript on the server side is a good choice because the language is widely used in the browser, is phallic. We developers don't have the option of which language we would like to use client-side. Or we use Javascript or we use nothing [that is as available as Javascript is].
The server side, on the other hand, give us that choice. Static or dynamic, compiled or interpreted, etc etc. I once read that Javascript is Scheme done wrong. It is a language similar to many others and to no other at the same time, with a name that suggests resemblance with Java, but which only shares some keywords.
But then, there's market for everything.
I agree that a standard API is needed. Personally, I don't want to have to keep up with several different forks or we'll be back to the JavaScript vs. ECMAScript days.
As far as server-side interpreters, is Rhino pretty much the big dog or are their other alternatives worth looking into at this time?
I've been using Mozilla Rhino on top of a servlet by Java Jetty for quite a while now. It's been wonderful to work with.
* Much like the post says: We now only deal with one language for both server and client side. JavaScript isn't a bad language choice, though it does feel limited by the standards consortium (want: Implicit return values, Ruby-style "method_missing", some others)
* We originally developed our sites on Ruby on Rails. Even with a mongrel cluster on our server (we have a slice on slicehost.com), we achieved an output of 20 dynamically generated pages per second. Our Jetty+Rhino server serves 100 pages per second using the resources of 2 RoR instances. (Java's still a memory hog, yes)
* It has the "all in memory" benefit of RoR. If you have a "var adder = 0;" and every access to a page does "adder += 1;", then it'll keep going up.
* Using Rhino's "Scopes", we're able to run multiple sites in their own javascript scopes within the same Java jetty service. This means javascript running within site A can't access site B or the "parent" process (which manages all the sites). It's comparable to a JS version of Google App Engine. (I currently have 11 sites running in a single instance)
* Thanks to Rhino's Java Connector - All of Java's libraries are available. (Though we usually make JS-like interfaces for them). We have a wonderfully easy SQL API, Sockets, even an implementation of XMLHttpRequest.
Cons:
* When a code fault happens, Rhino isn't as clear with the debug as we'd like it to be. "Exception with line 0 in " - But they're working on it.
* The libraries available for java typically seem to be more annoying to use than, say, those used by RoR.
* No way to determine total memory use of a single scope. If this was doable, I'd make a JS-on-Rhino version of Google Apps and sell or give out scopes for use.
....
I've shared it with a few people outside of my small team who quite like (and now use) it, and wouldn't mind open sourcing it, but I built it to use, not to manage as an OS project :D.
One serious problem has not been mentioned (unless I missed it!): the existing JS libraries all presume a DOM .. a window element.
I think all the popular libraries will have to be refactored into two parts: a base layer w/o DOM, and a browser layer built on top of it, using the DOM. And possibly grow a third part: the server-side.
Some libraries work nicely on both sides: templates for example can work both on both sides nicely.
Anyway, w/o tricks like env.js, its not easy to run jQuery on the server. Yet.
Jaxer, although now unsupported by aptana, has serverside dom and plenty of examples showing things like building dom serverside with jquery instead of templating engine.
It'd be nice if opera picked up the 'js on the server with a DOM' as none of the commonJS environments are doing much around that (env.js is a very shallow implementation, doesn't give you a serverside canvas object to build graphics with, for example)
there is good stuff coming. for sure.
Another project your forgot to talk about is APE (http://www.ape-project.org/). A Comet server powered by SSJS with a full non-blocking I/O API ;)
Actually, WebCrossing has had server side JS since about 1998 when it embedded the actual ECMAScript source code into its base application. It is still running and available.
To reply to Owen about the DOM requirement of JS libraries, I must say that it's true lot of famous libraries where made upon the assumption they only need to work in Browser environments..
But things are changing, since the last JavaScript conference talked about SSJS, frameworks like qooxdoo, and ajax.org are working to be usabale into CommonJS server-side environments.
There is also small but very useful JavaScript libraries which doesn't need the DOM like JSON, JSONPath, XML for Script, or JavaScrypt.
Some High level frameworks like YUI, Dojo, or ExtJS, are so modularized that some of there components should be easily made Server Side compliant (date manipulation, language utils, datasources...)
It is one thing to use an inefficient language and let the client pay for it (requiring more power/performance for processing). It is quite another thing to use an inefficient language on the server and pay for it yourself (with higher CPU/RAM requirements for purchasing host, or lower efficiency for data center, or higher cost/work with cloud services). If cloud computing picks up, people will care more about efficient because they have to pay for CPU cycles. Today, they don't for client side CPU cycles.
Re: Owen and Alexandre:
Dojo has had support for non DOM based environments since Dojo 0.1.0 was released.... in fact it had support (back then -- which was early 2005 IIRC) for the adobesvg, browser, jsc, rhino, spidermonkey, svg and wsh (yes windows script host) environments.
-Karl
GLUEscript (formely known as wxJavaScript) makes it possible to use JavaScript on the server and to create desktop applications (with wxWidgets). GLUEscript tries to turn JavaScript into a general purpose language ...
Re: Mehrdad
JavaScript engines have been highly optimized last years and if you compare to other technologies used on server-side to provide web applications (like PHP, Java, or ruby), you'll see that JavaScript can potentially beat them in performances.
Here's an interesting benchmark provided by Sitepoint benchmarcking persevere (based on rhino, so with an additionnal Java layer) vs PHP :
http://www.sitepen.com/blog/2009/04/20/javascriptdb-perseveres-new-high-performance-storage-engine/
Please note also that JavaScript starts using bytecode caching and compilers (cf SFX and v8)
The server had been using PHP4 since the code update, now it's using php5. Let me know if this fixed the preferences problems some of you have been having. And everyone here at the project wishes everyone a happy holidays and new year!
I will definitely spread the word, my friends who are more into this thing would love this, thanks for the post.