I've been involved in two separate projects where the backend tech stack choice was essentially "we'll just use Node". Both projects used Express, and it is pretty good, but almost everything else was different.

Both projects had (probably still have) a culture where if someone needed something, they'd first google for an npm, pick something, and just npm install that. Bleeding edge was viewed as a good thing. Kind of reminds me of the times when a new jQuery plugin was added for every little thing.

Soon, both projects will be using a large number of abandoned or obsolete npm packages which have been superseded by even more bleeding edge stuff.

Some day the dust will settle and preferred solutions will emerge for most things. But right now, man, it's a wild west.

t0: Yeah man, just use Grunt. t1: Oh no, nobody uses that, use Gulp. t2: Gulp??! Webpack!

Maybe Im being ignorant, but I don't remember even Rails being this crazy in its early heyday :)

If you grew up in it, it may not have seemed crazy. I played with rails 1, ignored 2, came in to a project with 3 RC1. loads of stuff breaking, but "they never do more than 3 RCs - we'll be fine before launch". I think we launched with RC5 (deadline was immovable). Felt to me like half the gems we needed were broken with Rails 3, and the answer was "just go fork it, fix some of these things, and use that". Felt fragile as hell, but the rest of the team acted like this just "how you roll" with Rails. I didn't expect that in something with a v3 on it, but perhaps because it was a major version bump it was more accepted?

I agree with all of the above. However, when a younger dev asks me which framework/language he/she should learn, my default response is: "If you're interested in employability, learn Node/JS. Practicality, go with Django/Python. Otherwise, Lisp (Clojure(script), Scheme, Common Lisp, hy)."

I'm surprised that Java isn't on here. I have seen piles and piles of Node jobs, and lots of Django positions (in the "cooler" corporate shops), but it seems like Java is still an outlandishly entrenched language, at least in giant companies. Do you think Node is better to learn for employability because every CS program in the country is churning out Java devs?

I think it's more the "JS" and less the "Node". If you're building a web application, for the most part, Javascript is part of the equation, especially as frontend dev has shifted from "write a few lines of html" to "render an application".

From there, Node isn't that big -- it's a few libraries for interacting with the system. The assorted framework stacks and whatever haven't really sorted themselves out yet.

From a technical standpoint, what Node does well is that it's basically async-IO-by-default, which is very nice for real world performance, whereas in most-every other environment I've worked with async-IO feels like an unwieldy addon where example code is hard to come by.

Java doesn't get much love. I've been looking for remote employment opportunities (I'm not based in the US), and a huge percentage of the postings I see are for Node.js and RoR. For Python shops it's almost always a requirement for Django experience.

Probably a bit of selection bias. Conservative companies are more likely to use Java, and less likely to offer remote working.

Well, I was speaking within the context of web applications, but I do think Java wins in the "business app" realm, which most younger people want nothing to do with.

Also, 3 to 5 years from now is where I'm aiming at (JS will be "stable but still cool").

I don't think Javascript will ever be stable the way Java is. It will probably end up close to where Python is today. It's not just matter of time, it's a matter of fundamental design choices in the language.

ASP.NET/C# is eminently employable, and ASP.NET MVC is not even bad. But given free reign, I will choose Django.

We use Django REST framework backend and node frontend so it'll solve the above except: forms, templates, sitemaps, clickjacking.

I think Node today can solve these 4 problems well enough.

You can shed more light on what you mean by "node frontend"?

My guess would be they have a Node app that serves the front end views (pages), but the data is gathered by making requests to the Django REST backend.

Yeah. Node is pretty much all about npm install this and that. I like pyramid but sometimes I do miss the battery included Django offers out of the box. Flask is my 3rd choice only because of the global, makes testing a bit hard.

We had to maintain a Pylons codebase that we never had the time to "port" to Pyramid (you know, rapidly growing startup, technical debt... then you get purchased by a big company and technical debt becomes a non-issue.) God, I hated a lot of that ecosystem. Lots of libraries that didn't work as promised (WebOb, WebTest, I'm looking at you) and upgrading them was impossible because newer versions broke Pylons.

All in all, I've always been a Django advocate. I know people hate the "batteries included" approach, but it guarantees that all parts work together well, and you'd be surprised how much of it is easily replaceable/removable. I've even used Django as a bare-bones router/request handler framework with great results.

I feel your pain. I used to work on a project started out with Pylons. But we got to give credit to Pylons & Pyramids folks. Despite being the least "famous" (well everyone has a different scale) these days, they still manage to pull in a lot of good code. Pyramid is my goto if I want to roll out everything on myself (once you know how to use things like tween it's really fantastic). I still can't get my mind around principal though. :{

I should go back to Django again, I started out with 0.90 when I first learned about MVC with Python.

> it guarantees that all parts work together well

Unless you need to extend or modify the behavior in an unsupported manner.

Django got much better since early 1.x versions, and gets better with every release, but I still find myself monkey-patching its internals (or copy-pasting classes with some minor changes) once in a few months.

RDBMS ORM : knex.js and bookshelf.js, way more usable than django orm.

forms : I gave up on form builders few years back, write them by hand

templates : EJS(prefer personally), Jade

authentication : passport.js, just works

file storage : node's fs module for local file's, aws node's sdk for s3

sessions : express-session with redis client and all

REST : express.js (supported by IBM, of all companies, heh), and restify, built over express

internationalization and localization : No idea, haven't had to do this one yet

caching : depends on the use-case, for request-response level caching, check out express middleware for the same, use ioredis for other things

logging : metalogger

mail : I mostly use a mandrill client, but I bet you'd find a few really good mailing implementations. You have an industry grade mail-server (haraka) in node world, so finding a mailing lib shouldn't be hard

sitemaps : Again, haven't needed them yet

RSS/ATOM feeds : haven't needed them yet

XSS : tackled by EJS, Jade etc templating engines

CSRF : express-csrf middleware ftw

clickjacking : helmet

SQL injection : knex.js

Secure connection and cookies : express + express-cookies middleware.

Finding each of these libs is a matter of 10-15 min of research, looking at number of downloads, frequency of downloads, contributors etc. And they just fit together really well.

You mostly don't need all the features you listed in all of your projects. Using node's libraries, with some effort, you can build a framework tailor-made for your project.

Hope that helps.

Yep. I'm going to get slammed on this but I love Django precisely because of the lack of choice. Just like Guido's "there is one way, and its the right way" mentality carried over from the core Python base, you see that same mentality it in Django itself. Sure, if you end up fighting too much against templates you can swap in jinja2, or an ORM in goes SQLAlchemy, but out of the box you have a pretty decent stack ready to use. It's the same reason why I like ASP.NET C# MVC. At this point, with all the NuGet packages, I can swap in any component I want basically, if I find the stock MS components lacking. Entity Framework not meeting my business needs? In goes NHibernate or Glass.Mapper.

I'm going to get a lot of hell for this since this is startup-land-latest-and-greatest-just-graduated-from-Stanford territory, but WebSphere and J2EE really got everything down for a god damn reliable infrastructure, REST or WSDL compatible, authentication/authorization via any provider you want ranging from Novell Netware to LDAP or AD, caching can be thrown in _every level_, if an appserver goes down, another node picks up the abandoned client sessions, you're getting high availability at just an absolutely remarkable level. Hate on maven (I've been down in the trenches with Scons and the GNU autotools set, you can get far worse) all you want but the ability to freeze and clone all of your dependencies into a local .m2 repository allows you to be 100% confident if an upgrade breaks functionality, regress & problem solved. I'm not even a J2EE advocate, more of a "please just work, I don't have the mental capacity to learn 60 packages + 15 workaround shims until all browsers are ES6 compatible.

I really like a lot of the options of node out there. Tons of packages are really useful and innovative (as opposed to Yet-another-templating-system). There are quite a few interactive projects that the v8 platform lends itself to, especially with socket.io, a lot more flexibility that didn't exist before. But between ReactJS, Flow, JSX (which confuses me even more when I context shift because I write C# with TypeScript), and 50 other packages out there, I'm completely lost.

From a managerial perspective, its going to be hell to maintain those projects 3 years down the line when all of your 22 year old engineers have moved onto their own startups/friends startups/across the country because their long-time-partner got into Harvard med/etc. You'll be left searching for someone with expertise in Jade, Express, Node, Mongoose, Nginx, Socket.io, JSX, [insert 10 other modules which will become critical to your architecture as time goes on]. It's great for the engineer who lands inherits that project on a 1099 capacity because they'll be able to bill whatever they want, but absolutely terrible in terms of long-term maintainability (and yes, I realize technical debt is often a "bond-offering" (heh) worth making in exchange for a faster MVP in some cases).

I think not, but Meteor or Keystone.js might get there some day.