Ask HN: Does Node dominate at new startups?
I had a long conversation with an engineering manager at a public tech company. He told me, basically, "Ruby is dying. Most new, funded startups in SF/SV are building in NodeJS if it's a web-based app (or a mobile back-end)."
Is there any validity to this? Is there any recent survey data on what startups are using (or maybe what YC companies use)?
26 comments
[ 4.7 ms ] story [ 80.8 ms ] threadThat being said, I work for a new, funded startup in SF, and our web stack is based on Node.
(We selected node.js for our startup.)
Without at least one very experienced Node.js dev on a team, the project has an extremely high likelihood of ballooning in complexity by the 3-4 week mark, quickly exceeding the 7-plus-or-minus-2 rule and becoming unmanageable. I've seen it happen multiple times. I've made it happen. It's pretty much unavoidable (unless the devs you have on your team are already senior-level with multiple other technologies, and even that isn't guaranteed to save you).
Node.js is powerful tech - it allows one to build featureful, highly scalable systems and do it damn fast; but it can also break your startup.
Sorry for the tangent, I know this doesn't exactly answer your question. I can't be the only one who's realized this though, so Node.js is probably not a default choice the way Ruby was. If you're looking for "new hotness" points, it seems like Go would be the best bet.
Ruby/Node is a pretty fair comparison as far as evaluating "backend server tech". While yes, Ruby is a language and Node is a runtime (thus perhaps making JRuby/Node a more apt comparison), Node.js is far enough removed from client-side Javascript in terms of libraries, knowledge required, etc that I find it pretty easy to compare the two. With Ruby, you find a web framework, supplement with libraries, and code yourself up an app. With Node.js, you do the exact same thing. Good enough for me.
Lot's of people dabble in it but to truly know how to not screw it up when building something bigger it takes patience, experimentation and serious effort.
This is somewhat compensated by the speed of development you have with such platforms and is a tradeoff.
Here's a few nuggets that will help you:
- Use promises instead of callbacks, specifically Q. Don't let anyone tell you the performance will hurt you - I guarantee that promise execution time is not your bottleneck.
- Use event listeners for things like kicking off email notifications.
- Use Mandrill for sending those emails.
- Use promises.
- MySQL is still good tech.
- Use Sequelize to make using MySQL/Postgres not hurt.
- Abstract into middleware when you can.
- Bogart > Express.
- Use promises.
- Use dependency injection (Omni-DI is a good library for this).
- Route handlers are for orchestration, not core business operations.
- Avoid for loops. Prefer Array methods like forEach, map, reduce, and filter.
- Use promises.
I plan on doing more writing about this sort of thing when I have time.
But I think the greater trend is one of polygot backends. Startups bringing several different languages onto the backend, when necessary to scale beyond the initial web app. This does involve a slow dispersal of mindshare away from Ruby/Rails. Things like: Node, Python, Go, Scala, Erlang, and so on.
ruby startup gets all the round A funding and big exits.
php startups become huge corporations.
I'll go back to what Steve Blank and others have said: most startups that fail (and most do), fail because they build a product nobody wants, not because of technical problems with the product. If you believe that is true (and I do), the tech stack really just isn't a very important decision at all. And I think that's especially true if you stick to anything even remotely close to mainstream: Node, Rails, Grails, Django, Flask/Pyramid/Pylons/Whatever-it's-called-now, Scala+Play, Java+Spring MVC, Whatever-Clojure-uses, etc.
Now, if you said you were building using Algol-68, SNOBOL, RPG/400 or MUMPS, then there might be a legitimate question regarding your ability to find and hire good developers, etc. But I'd still almost be willing to bet that "building a product nobody wants" would be more likely to be the culprit if the company failed, than the tech choice.
That said, we use Groovy and Grails here. Node is on my list of "things to play around with when I have some free time" but nothing I've heard yet gives me any reason to think that it's a "game changer". Feel free to convince me otherwise though.
I mean yes, there's the whole async thing (nothing new), but that's really only in pursuit of performance, and Go (way more performant) will catch up to Node's library selection within a few years.
All that said, I quite enjoy working with it: I find Javascript pleasant, and it's easy to create elegant solutions to the problems I encounter day to day. Finally, Node powers some absolutely fantastic front-end tooling (Bower, LESS, Gulp). Even if it's not powering your sever, I recommend it as part of the front-end workflow.
If there was a web framework for Ada, I'd be all over that ;)
The etc covers Go based servers nowadays. PHP backends are still fairly common, and maybe even Perl 5 is still used.