Odd state? It certainly is... but it is only what... a year or two old now?
It seems to me that what is missing is a clear winner. Sure, competition from a number of different fronts is really great, but I think what made Java tick for a long time was JBoss and Spring. For Ruby, it is Rails. I'm sure Python has Django and others.
Clearly lots of people are working on it, but a powerhouse framework for NodeJS just hasn't surfaced quite yet. The OP's mention of security being bolted on as an afterthought really is something that makes me shudder. I can't imagine building a large scale public facing system without method level access control. I fear a whole new generation of injection type attacks against NodeJS frameworks.
While it is fun to play with all the shiny new NodeJS toys, I don't see why sticking with tried and true on the backend (take your pick of Python / Ruby / Java) is such a big deal. A lot of the cool features that are being touted in the NodeJS frameworks have been already done elsewhere for much longer.
For me, I've really successfully used NodeJS in one area where it really shines... scraping web pages... but that is simply because working with a jquery-like interface to the DOM, on the server side, is amazing.
In the end, it seems like if you're bootstrapping a company / product (like many of us here are) and trying to pick what to use for your base platform, the obvious choice is building features instead of building frameworks. This means you stick with the tried and true and hope that in the future, the shiny new toys mature a bit more before you go down that path.
After years of working with Django, I choose Node because of an abundance of developers with experience in Javascript, an environment free of context shifts when moving between languages, and code portable to the front and back end of the stack. Python is much "shinier" to me, but I think Node will make my company more competitive.
> A lot of the cool features that are being touted in the NodeJS frameworks have been already done elsewhere for much longer.
Are you including Derby.js and Meteor.js in this? The main example the article uses is the way these frameworks seamlessly sync to your datastore and other clients, and the server is running the same code so you don't have to write almost any boilerplate to do this.
This seems like a unique property of running javascript on server and browser, and I don't know of anything in Python/Ruby/Java that even tries to do this. It seems like it would inevitably be more complicated and require duplication of code. Unless you had a framework that compiled your model and view code from one of these languages to or from javascript (which I've always thought would be cool but now seems like a worse solution than Meteor or Derby)
Node.JS is a decent platform for developing on, if you know the caveats. You have to be very careful with the modules and frameworks you use -- as mentioned in the article, maturity of modules varies.
I know people that have had issues with socket.io and skipped it (and node.js) for their production needs. That said, my aha, gotta be careful, moment was when I was setting up a quick test, picked one of the http-digest auth modules, and had a bug -- actually a completely incorrect digest auth implementation (basic auth was fine). This was the second node.js module implementing digest auth that I used that had a bug that relatively simple testing would have found. (The other bug was around the caching/lifecycle of nonces.)
I plan on going back and submitting patches for both of these modules, but the lack of basic testing in two cases of a well known (and documented) feature reminded me that the platform is still in transition. (This is just one example of some issues I've run into)
Why I say you have to be careful? For the downsides, there are definite upsides. I needed a simple test https server w/ a rest API and serving a static file -- total lines of code, about 25. A great boon to prototyping.
Like any new framework, evaluate it in consideration with your needs.
To draw an analogy, whether server-side/client-side JavaScript frameworks will become the next RoR is like guessing whether Facebook will ever be able to monetize the way people think it might. It seems like it should be possible, but it doesn't seem like there's an obvious way forward. </bad-analogy>
I love JavaScript (in the weird way everyone who "loves" JS, loves JS), but I'm skeptical the next big web framework will be written in it. I want to believe, but it just doesn't feel right yet. I hope it will and I can't wait for the "ah ha" that makes it feel right. But it doesn't yet.
While I think Meteor and Derby are moving more in the right direction than Express, I think if any of these frameworks want to be the Rails of JS, they need to play on the strengths of Node much more. Node really shines when it has to serve a ton of small data, rather than render CPU-intensive templates on the server-side. Express treats Node as if it were Ruby or Python too much.
I feel like Meteor is completely missing the point when they do things like use fibers. To be the go-to Node framework, it's going to have to move much more client-side, but still make it easier to build an app than something like Restify.
I don't see much oddity. Express + socket.io is the current canonical setup, both are production-ready, deployed at hundreds of businesses. Derby, socketstream and such are just experiments right now.
once again no mention of a framework I love for node and that is http://railwayjs.com/ it is pretty railsy, built on top of express, and has the ability to leverage the socket abilities all with an orm and fully structured framework
It just 2-3 years old and it does amazing work. I don't wanna talk about frameworks(noders hate frameworks) and modules.
Node's API is changing but everyone is happy with that.
Why I love Node is because, It's JavaScript and the evented model.
Some times back I do not agree with the moves done by Ryan (Node Creator).
But Now Node Core team is lead by isaacs who is a cool guy and listen to the community.
Node Frameworks may be in Odd state. But not the Node itself.
You could potentially narrow it down a little bit by taking Express out of the equation. As far as I know, Express doesn't play on the browser. You could use Express to serve static content or a blog or an API but you would need to supplement it with something like Backbone or Ember on the client to build something like gmail or trello.
And while you could use Meteor (or, I'm sure, Derby) for a static website, that's obviously not what it's designed for. I've never tried it, though. I'm sure it would be a real beautiful experience.
My favourite is Locomotive.js [1] (extends express.js) simply because it doesn't try to do too much, it just gives you a solid base and you're free to use whatever parts you need.
Another that shows promise is Flatiron.js [2], but I haven't had a chance to play with it yet.
Geddy (http://geddyjs.org/) also looks promising. MVC, generators, etc - RoR-ish. Haven't done more than play around with it, but it seems fairly comfortable. That said, also young and light on docs right now (though they have a decent intro tutorial).
It seems to me that what is missing is a clear winner. Sure, competition from a number of different fronts is really great, but I think what made Java tick for a long time was JBoss and Spring. For Ruby, it is Rails. I'm sure Python has Django and others.
Clearly lots of people are working on it, but a powerhouse framework for NodeJS just hasn't surfaced quite yet. The OP's mention of security being bolted on as an afterthought really is something that makes me shudder. I can't imagine building a large scale public facing system without method level access control. I fear a whole new generation of injection type attacks against NodeJS frameworks.
While it is fun to play with all the shiny new NodeJS toys, I don't see why sticking with tried and true on the backend (take your pick of Python / Ruby / Java) is such a big deal. A lot of the cool features that are being touted in the NodeJS frameworks have been already done elsewhere for much longer.
For me, I've really successfully used NodeJS in one area where it really shines... scraping web pages... but that is simply because working with a jquery-like interface to the DOM, on the server side, is amazing.
In the end, it seems like if you're bootstrapping a company / product (like many of us here are) and trying to pick what to use for your base platform, the obvious choice is building features instead of building frameworks. This means you stick with the tried and true and hope that in the future, the shiny new toys mature a bit more before you go down that path.