I guess I'm about the last person in the world to recognize this (cough Steve Yegge cough), but it really is starting to look like the next big server-side language is going to be JavaScript.
It's got a non-intimidating C-like syntax, has some powerful features (e.g. being able to use anonymous functions as closures), is garbage collected, and can run client side. And you've got three or four well-funded organizations full of smart people duking it out over who can make the fastest implementation.
The syntax is a bit ugly if you're used to something like Ruby. Comparing Express to Sinatra, I miss the block syntax and the implicit returns (although JS handles passing in multiple blocks quite elegantly).
Maybe what we'll see are a number of languages that compile down to JavaScript, sort of RJS on steroids.
Yeah coffee-script has both implicit returns and block syntax, amongst many other marvelous things. The Express examples in the GitHub README would look a lot nicer in coffee-script.
I will be adding some coffee-script examples soon. The source of coffee is very nasty though :S, and I am not a huge fan of source to source compilation for anything besides being a toy language
I wrote about this a few months ago: http://simonwillison.net/2009/Nov/23/node/ - it's exciting because it's asynchronous (like Ruby's EventMachine and Python's Twisted) but makes it almost impossible to screw up your event loop. JavaScript is an excellent fit for asynchronous programming.
http://transloadit.com/ is one startup that's using Node.js - it's particularly good for handling large file uploads since it can handle tens of thousands of them in parallel on a single server.
First, Mozilla, Apple, Google and Microsoft (and don't forget Opera) are in a high-stakes tournament to produce the fastest implementation. And three out of the four/five (CMIIR) are open source.
Second, the server uses the same language as the client. This isn't a big deal yet, but I'm sure within a month or two we'll start to see some web frameworks that take advantage of this. The obvious application is validation, where constraints from the Model and Controller layers could automatically bubble up into the View layer and out to the client.
But it could be more subtle. You could have a data-access layer written in JavaScript that when run on the server pulls from the database, and when run on the client pulls it over a REST interface. You could do jQuery-style DOM manipulation on the server for the initial page state, serialize it to HTML to pass to the client, and then do further manipulations on the client using the same code base. So there's a lot of code sharing across where you currently have a pretty sharp dividing line.
writing the same language server and client is obviously easier (fewer context shifts, smaller code base, etc).
It's also asynchronous (non-blocking) so you can run thousands of connections out of a single thread (instead of RoR's silly 1-connection per process model).
You can multithread RoR on JRuby, but you still won't get anywhere near the performance of event-driven I/O. But, you need to think differently about how you build your app, right from the get-go.
Seriously though: JavaScript is a great language, but I'd prefer a sub-dialect to smooth the syntax over a bit. It is not-at-all DSL friendly and, frankly, Express' route syntax looks like shit when stacked up against Sinatra or even bottle.py
It's obviously relative to other commonly used web frameworks (like django, rails, asp.net, etc) - in that perspective it's indeed ultra high performance.
Compared to raw assembler dsp, sure, it totally sucks :)
Let me preface this with the fact that I am a huge Node.js/V8 fan and have actually written an FFI interface for Node.js (that shamefully needs some updating). I am also a huge Ruby on Rails fan, so I'm not some kind of performance-obsessed VLIW-assembly-coding uber-nerd.
I had a feeling I'd get down-moded for questioning "de jour" on HN. Let's deconstruct this hyperbole. Ultra is a prefix from Latin that means "beyond." Is it really BEYOND high performance?
Frameworks like Django and Rails focus on features and ease of use over performance. They are not high performance, they are high productivity. I truly believe that the developers of this new framework are focused on high performance, but they are still relying on an VM environment that is still 1/3rd to 1/5th the performance of C. How is this going beyond high performance?
I suppose all of this is nitpicking someone's marketing speak, but let's get real about what performance is. It would be nice to be spoken to by other engineers like an adult with a brain, instead of bullshit like "ultra high performance." This is the irrational kind of stuff that causes framework and language holy wars.
"SQL is slow."
"Rails can't scale."
"Dynamic languages can never be fast."
"Java uses up all your memory."
Bravo, this type of hyperbole has made non-expert comparisons impossible in so many other industries, let's try and prevent it from completely encompassing computer science.
haha :) touche` pardon my crappy use of the english language. I will replace my lame use of "ultra high performance" with "Focused on high performance" as that is the end goal of course.
That being said of course it will never be as fast as C[++] or erlang that is just a given
It's got a non-intimidating C-like syntax, has some powerful features (e.g. being able to use anonymous functions as closures), is garbage collected, and can run client side. And you've got three or four well-funded organizations full of smart people duking it out over who can make the fastest implementation.
The syntax is a bit ugly if you're used to something like Ruby. Comparing Express to Sinatra, I miss the block syntax and the implicit returns (although JS handles passing in multiple blocks quite elegantly).
Maybe what we'll see are a number of languages that compile down to JavaScript, sort of RJS on steroids.