41–50 of 75 posts
Somebody should start a "Vogue for Developers", so we can just stop pretending. Most of this article and most of this thread is about fashion, not technology. But that applies to a lot of topics on HN.
It's a little tiring to see some of the same old fallacies about Node repeated ad infinitum in this thread. I suspect a lot of the complaints stem from poor development practices or not understanding norms in JS. JS isn't without its flaws, but can we at least put a few fallacies to rest: > callback hell There's no reason to be in callback hell if you use an asynchronous control flow library and stick to the standard…
Such narratives usually get louder and louder, until they flip and all the former supporters of X suddenly proclaim "I can't keep quiet anymore, I must speak against X".
I've seen this too many times.
I like Node.JS, it's a good thing it exists, but no technology is perfect and we should be capable of honestly discussing the strengths and weaknesses of a given technology.
No comment on typing, if you can't bother to do basic research over whether what you say makes sense in real projects.
I'll just say that in 2014 proclaiming that your multicore application architecture is spawn() and fork() can only induce laughter in the presence of proven distributed computing algorithms that don't require every developer to use a roll-your-own message passing library and protocols.
“Why go to Facebook and do PHP when you can go to PayPal and do Node.js” Why choose the company you work for based on technology when you can choose the company you work for based on the company you will be working for?
It's a little tiring to see some of the same old fallacies about Node repeated ad infinitum in this thread. I suspect a lot of the complaints stem from poor development practices or not understanding norms in JS. JS isn't without its flaws, but can we at least put a few fallacies to rest: > callback hell There's no reason to be in callback hell if you use an asynchronous control flow library and stick to the standard…
But... if you're going to bolt on an "async" library, bolt on threading, and bolt on strict typing, why not use something that starts with that stuff? And ends up doing it better since it was actually created with that stuff in mind, instead of aftermarket bolt-ons? Saying that those things "fix" Node amounts to an admission that you shouldn't have started with Node in the first place.
a) A small core API instead of a sprawling standard class library
b) A highly composable export and require mechanism, better in some interesting ways than what exists in other systems (1)
c) The fastest growing and soon to be largest community repository of packages (2)
d) asynchronous by default stack and ecosystem.
With those things in hand, "bolting on" is a virtue and not a disadvantage. That Node is general-purpose - you can build cross-platform desktop applications, streaming servers, web applications, console utilities, etc - and does not impose its package opinions are major factors in its success.
1) http://blog.izs.me/post/1675072029/10-cool-things-you-probab...
[/me searching job postings for Node.js]
NOT!!!
But hey, the more developers jump ships to Node the more money I make. Look at the Cobol guys and their salaries.
These stories about switching to node are pretty funny: "I switched from a dump truck to a motorbike and now I can drive way faster!" Node.js isn't really faster than most other popular languages with an evented library, but if switching to Node involves scrapping years of enterprise cruft, then maybe it's worth it. By the way, enterprise adoption of Node is surely a sign that we need to jump ship. Glad I got out of…
OpenResty consistently handles 5 times more connections than Node.js, without requiring any of the continuation passing nonsense. As usual, popularity doesn't reflect upon quality at all -- Node.js is the Kim Kardashian of web frameworks.
If you're making an entire web application with a lot of front-end code that is already written in Javascript it is an added cost to also support C and Lua.
A lot of important development time can be retained by not having to write the same functionality in multiple languages.
A module can be written in Javascript and used on both the client AND the server.
Don't conflate mainstream media fashion with the sort of pragmatic convergence that has been a big part of driving the adoption of node.
"Raw speed" over everything else is the Yngwie Malmsteen of programming language metrics.
"Node.js programs are developed using JavaScript, this means that the silos that existed between frontend developers and backend developers are now broken down, and this results in significant efficiencies in the development process. With Node.js it’s possible to merge web and backend teams into one unit which makes things much more efficient."
It's a little tiring to see some of the same old fallacies about Node repeated ad infinitum in this thread. I suspect a lot of the complaints stem from poor development practices or not understanding norms in JS. JS isn't without its flaws, but can we at least put a few fallacies to rest: > callback hell There's no reason to be in callback hell if you use an asynchronous control flow library and stick to the standard…
It's a little tiring to see some of the same old fallacies about Node repeated ad infinitum in this thread. I suspect a lot of the complaints stem from poor development practices or not understanding norms in JS. JS isn't without its flaws, but can we at least put a few fallacies to rest: > callback hell There's no reason to be in callback hell if you use an asynchronous control flow library and stick to the standard…
> callback hell
It's great that there are better options out there for handling async programming, but at the end of the day you're still using callbacks for control flow. Having to partition out application logic across I/O events sucks, and picking a model where that is the only option is going to raise some objections. Especially when you have languages like Lua that use coroutines to manage the exact same performance guarantees without the code organization headaches.
> single-threaded
The complaint about single-threaded evented servers is that the performance of the whole system relies on you correctly answering the "will this piece of code perform extensive computation" question at every point in your program. That's not an impossible challenge, but I don't think it's an unreasonable one to complain about.
> lack of strict typing
No, strict typing won't make you a better developer, but it certainly will help save you from yourself. Again, writing extensive amounts of application code in a tool that comes just short of actively hindering correctness is an exercise in frustration. You shouldn't be surprised that people object to this.
I think it's great when people look at all of these issues and decide that Node is still valuable for their use case despite them. It seems like there are a lot of bandwagoneers who aren't making that kind of evaluation, and I think it's a good idea to keep hammering away on these downsides until they do.