

The (Odd) State of Node.JS and its Frameworks - andrewmunsell
http://blog.andrewmunsell.com/post/29659423342/the-odd-state-of-node-js-and-its-frameworks

======
latchkey
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.

~~~
gcr
Pardon? NodeJS is almost four years old now.

~~~
latchkey
I wasn't referring to node directly. I'm talking about the frameworks that
have sprung up around it.

------
jmspring
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.

------
bialecki
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.

~~~
firefoxman1
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.

------
ricardobeat
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.

------
drunken_thor
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

~~~
andrewmunsell
I've never heard of Railway before-- I'll definitely take a look because it
actually looks pretty interesting.

------
arunoda
Odd State? No way?

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.

------
mcantelon
>They’re on version 3.0 and the framework is quite mature. But unlike Derby or
Meteor, it isn’t real time.

Express + Socket.io gives you realtime.

Example of the two of them working together:
<https://github.com/mcantelon/chatrooms/blob/master/app.js>

~~~
andypants
And socketstream can run on top of express as well.

------
jimmytucson
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.

------
jameswyse
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.

[1] <https://github.com/jaredhanson/locomotive> [2]
<https://github.com/flatiron>

------
cacois
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).

~~~
DTrejo
Geddy is 2 years old, not so young compared to most modules
(<https://github.com/mde/geddy/commits/master?page=25>).

------
bergie
Here's my take on the Node.js framework question:
<http://bergie.iki.fi/nodext/>

Not so much of a framework than a way of keeping code organized and
disabling/enabling different parts of an app as needed.

------
fpp
A short note on the express pro/cons:

It does come with a MVC example, but you can of course also use one of the
well known frameworks like Backbone, Spine, Knockout etc.

Idea here is lightweight and a solid foundation that allows broad usage.

------
trung_pham
Check out Yahoo Mojito.

