Interesting analysis. I just finished a year of using Node for implementing an HTTP API and a chat server, and found it to be actually pretty pleasant. I'm not chasing the latest and greatest things, there's no ES6, no ORM, and I'm on an older version of Node. But it works and has actually been quite stable! The things I've missed are static type checking at compile time, and execution speed (which is less of an issue when you're talking with databases all the time). I'd be happy to write in more detail if anyone has any questions, but I found I had the opposite experience of this author. The situation makes all the difference though.
After a year of using Node.js in production
191–200 of 248 posts
Re: After a year of using Node.js in production
#192I usually don't respond to anything which I feel is just another "language war" provocation, but whenever I see these type of reviews I'm mystified. I've developed in many languages and frameworks, both well known and lesser known - decades of client and server side of C/C++, Javascript, Lua, Java, Python, PHP, Perl, Lisp. Pascal (just to name a few) in projects of all sizes, and not once did I have the thought "this…
> I feel that blaming failure on the language used is like blaming a bad novel on the word processor used to write it.
Sure. If you're a good novelist you can write something great even on a keyboard with a broken 'e' key (btw, your 'I' key is about to break; you should replace it asap).
But novelists don't have deadlines and when the novel is done, they usually don't take reader requests to change this or that part of the story.
"The advantages and limitations", what works and what doesn't, "areas to avoid" are precisely the point of that kind of review.
Re: After a year of using Node.js in production
#193A year ago one of the reasons to leave Python was poor MongoDB & JSON support, 12 months later the same author complains about the lack of a decent SQL ORM library in js
while JS is far from perfect, his problem was he was a little bit ahead of time- babel, standard promises & sequelize solve most of the problems. I think Python is still superior for serverside, but JS isn't as bad as portrayed in this post, if you slowdown for a couple of weeks to learn how to use it properly (just like any other popular language or framework).
Re: After a year of using Node.js in production
#194Earlier quoted context omitted.
All of his arguments actually apply to all of javascript, and are not actually specific to node.js though.
Not really. These things aren't pain points in the browser the way they are in Node. I have never felt the need for an ORM in the browser. I have never dealt with client-side code that was using so many libraries I had to worry about whether exceptions would be handled via exceptions, or the first argument of the callback, or rejected promises. No one (at least, no one I know) is installing node modules like isArray…
Actually the only place you would install isArray is the browser...
Node has support for the built in isArray, and you only need that "micro module" if you want to support IE8
Re: After a year of using Node.js in production
#195I'm using NodeJS on a pretty big project. Things I like: * Async libraries make it easy to make things high performance. * I like Sequelize as an ORM, once I figured out how the async everything works. * The testing support is pretty good, both mocha and e2e testing using selenium * The angular-fullstack generator was really helpful for getting started and setting up the deploy to Heroku. * everything is open source.…
> * I like Sequelize as an ORM, once I figured out how the async everything works. Sequelize is painfully slow unfortunately, I don't mean a bit slow like most ORMs I mean really really slow. It shouldn't be used in production.
Not to mention it's flaky on even producing correct queries. Sequelize was hell for me and I'm glad to not be using it anymore.
Re: After a year of using Node.js in production
#196Earlier quoted context omitted.
> No one (at least, no one I know) is installing node modules like isArray to use in the browser. Erm, well, considering the adoption rate of Browserify and Webpack, I'm going to disagree with you there. Especially considering React's momentum practically requiring some form of module builder.
Startup speed is terrible with that approach, each browserified module adds like 10x more code as boilerplate than something like isArray implementation would take. Then every module dependency is resolved dynamically at runtime, which will also quickly become a performance problem even when you aren't using micromodules.
I haven't touched browserify, but with webpack what you said could not be more false...
Webpack doesn't bundle at runtime, it doesn't add any amount of code overhead per module that I can easily measure, and it doesn't trash startup speed.
Re: After a year of using Node.js in production
#197Now all of a sudden, having types and some standards to gather around doesn't sound like a bad idea anymore ;) I agree with one of the commenters: Lessons already learned by older engineers (who went through similar woes with other languages/tools) are being re-learned again and again. The software industry is in a sorry state. Unless you are a very disciplined team with a very strong sense of writing modular code, d…
I've worked in three million+ loc codebases, in PHP, Python and Java. I don't share your opinion that you need static types in these circumstances. You need discipline, modularity, and most importantly you need to have been blessed with gardeners and maintainers throughout the life of a project and not just after a mess has already taken hold.
Damn sorry I accidentally downvoted you on mobile... I really wish HN would fix that.
Re: After a year of using Node.js in production
#198Async-functions are the answer to all his problems. I generally agree on his conclusion though: Do small things, don't build big systems.
I hate that JS trys to be this OO-FP hybrid. Jack of all trades, master of none.
Re: After a year of using Node.js in production
#199Earlier quoted context omitted.
I'm still not all the way on board with promises - from the sounds of it this article says there is already a successor down the pipe. As you've pointed out some of these libraries make things behave a lot more similarly to other languages. And in such a case you may be better off just using one of them. However you're giving up on a lot of the power and benefits javascript provides, so of course you'd want to use so…
How is JavaScript so special with async and streams? JS lacks any syntax for async, so it's not on par with languages that do. What's special there? Same for streams: they're implementable in any language, and JS has no special capability there. Or am I unaware of something JS has that other languages lack (besides popularity)?
Personally I just like that things are async by default.
That means that if you are using a 3rd party library, it will be async from the start.
In something like python you need to work to get a fully async app, but in node you should file bugs if something blocks on IO.
Re: After a year of using Node.js in production
#200This article definitely matches with my experience. I did two not all too complicated projects on the side with Node.js and the the first steps where so easy that it completely convinced me to go with it.
After a while I tried to dig deeper and went to meetups to see whether I do things right as in a community accepted way and if I use the right tools and so on. Since then I refer to the Nodejs community as the most hipster programmer community I've ever seen. As soon as a framework was getting near a 1.0 version nobody wanted to use it anymore, experimental features were used in production code, it was horrifying.
For me that ended this endeavour, I just could not keep up with the pace. I always wondered if it would be different if I would have worked full-time on Nodejs projects.