Comment by placebo | Hacker News Reader

Comment by placebo | Hacker News Reader

I 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 language sucks". I think there are a few reasons for this: 1) Even after all these years, I'm still passionate and excited at the ability to sculpt logic, regardless of the "material" I need to use. 2) A "keep it simple" approach - no way to overemphasise this. Know the advantages and limitations of the language and stick to what works. Keeping things simple should be like a fractal - existing at all levels of abstraction. 3) I'm very wary of hype. New, shiny and trendy does not necessarily mean better, especially when the hype is in conflict with keeping things simple. I find that when you understand the playing field, mark the areas to avoid and keep things as simple as possible, the elegance of the design and implementation usually makes the advantage of language X over Y insignificant, and I feel that blaming failure on the language used is like blaming a bad novel on the word processor used to write it.

The article doesn't appear to be blaming Javascript as a language, but rather the Node.js ecosystem as a server platform.

Not all tools are appropriate for all niches. The author made it clear they don't have an issue with Javascript as a whole or even with Node.js necessarily, but rather the use of Node.js as a major server platform or as a platform for large applications.

All of his arguments actually apply to all of javascript, and are not actually specific to node.js though.

But there is a good argument that your server components (or at least a good portion of them) should be built in a language that requires some more up front work because it makes maintenance easier down the line.

There is a good argument to be had on the same topic for the front end. Arguably more so.

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 to use in the browser.

Yes, these things _could_ technically apply to the browser, but it's not commonplace. In the node world, these are all things you deal with consistently.

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

Same goes for browserify. You can have lots of tiny modules and (watchify especially) is fast to re-build. And yeah perf of 'require' statements at run-time is a non-issue.

> it doesn't add any amount of code overhead per module

It's something like tens of bytes (minified), FWIW, for the closure that each module gets put into.

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

You are a lucky person if you have used so many languages and never missed a thing in a language you are using at the moment that is readily available in some other language you have used in the past and that would make everything so much simpler!

For example the OP got fed up with Python and switched to Node. Now he is fed up with Node and switching back. I can say that focusing on the downsides of the tool I am currently using and the upsides of the tool I am not using is a fairly common thought pattern for me too. Of course the way to combat it is to remember that it is very rare for some tool to be strictly superior to others and just focus on the task at hand.

Choice is a very dangerous thing. When reading the book "Coders at work" I was struck by how primitive some of the old computing environments were. But that did not stop those people from doing amazing things with them. I now think that was partially to their advantage because they were freed from choosing the language/framework and so could concentrate on doing, you know, actual stuff.

Keeping it simple works wonders but you can't do it alone. A language with a culture of making things complex so as to achieve some standard of perfection, and/or with many developers simply not knowing how to stay out of trouble and not being able to tell what's fragile and what's trustworthy, will make it harder to "keep it simple."

I agree that when programming mostly alone one can get by very nicely in any reasonably popular language since its popularity necessarily means that it's workable in the areas where it's typically used. I disagree that languages can not get in your way if you know what you're doing once you're not doing it alone.

I didn't get the impression he hated the language or even the node.js ecosystem. Love or hate for languages have no real place in production. I work at a place with 5000 employees and I sometimes work with technologies I'm not fond of because they are the right choice for the job.

Things like long term support, stability and security rate in how mature different technologies are for production. Considering a lot of the problems the author ran into with node.js aren't secret, I think he might actually have liked it quite a bit to go on to try it in production for a full year.

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

> But novelists don't have deadlines and when the novel is done

I hate to "well actually" you :) , but a great number of authors have contracts that demand one or two novels a year over a fixed period of time. I know Iain Banks did with his publisher, he mentioned it at a one of his readings of a new but yet unpublished novel I was lucky to attend back in 2007'ish.

> they usually don't take reader requests to change this or that part of the story.

Even well known authors are reigned in by their editors and proof readers, and sometimes things have to be changed.

> (btw, your 'I' key is about to break; you should replace it asap).

haha - touché, point taken :-)

Deadlines seem like a great excuse for compromising quality. Sure, life is complicated, the boss is demanding, the mortgage has to be paid, the children need to be supported etc. etc. but compromising quality and enthusiasm (they usually are correlated) because of the "terror" of a deadline will just leave you at the mercy of the next "terror", only this time you'll even have even less enthusiasm to fix the spaghetti. Doesn't sound like an enjoyable existence.

Of course, very few people have the privilege of never having to compromise, but it's never black or white and there are many more degrees of freedom to choose the path with more quality than are implied.

>"The advantages and limitations", what works and what doesn't, "areas to avoid" are precisely the point of that kind of review.

The "area to avoid" in the review is Node.js and considering that large and impressive projects have been written in it, it seems that this is another case of throwing the baby out with the bathwater.

No language is good enough to make a boring job pleasurable[1]; no language[2] is bad enough to ruin the pleasure of interesting job.

[1]: At least, not for long.

[2]: created in the past thirty/forty years

C++ is 30 years old and it certainly has made interesting projects horrible.

It's more like hundreds of thousands of writing teams from different cultures and levels of experience sprung up to write collaborative epics in Latin because it had suddenly become cool to do so while bringing the language to the modern world by inventing a new vocabulary and arguing on the correct pronunciation of everything.

Reply on news.ycombinator.com