Ask Slashdot: Have You Migrated To Node.js?

A developer maintaining his company's "half-assed LAMP / WordPress stack pipeline for web and web application development" is considering something more scalable that could eventually be migrated into the cloud. Qbertino asks Slashdot: Have you moved from LAMP (PHP) to Node.js for custom product development and if so, what's your advice? What downsides of JS on the server and in Node.js have a real-world effect? Is callback hell really a thing? And what is the state of free and open-source Node products...? Is there any trend inside the Node.js camp on building a platform and CMS product that competes with the PHP camp whilst maintaining a sane architecture, or is it all just a ball of hype with a huge mess of its own growing in the background, Rails-style?
Condensing Qbertino's original submission: he wants to be able to quickly deliver "pretty, working, and half-way reliable products that make us money" -- and to build a durable pipeline. So leave your educated opinions in the comments. What did you experience moving to Node.js?

Comments

Yes callback hell is a thing

[Anonymous Coward]

It keeps me up at night with stress. I hate node.js and everything it stands for. It wasn't always like this though.

Re:Yes callback hell is a thing

[Anonymous Coward]

I looked at node.js because we needed something for an embedded linux project. reading up on it I saw the callback idiom and thought why would anyone want to do that to themselves?

Have you migrated to qbasic?

[Anonymous Coward]

Fuck no, it's a toy language that's being stretched way beyond its intent. JS has become the absolute bane of the internet, which now requires 2ghz machines to render ~~responsive~~ web pages, and the language has no place whatsoever on servers.

Re: Have you migrated to qbasic?

[ZeroWaiteState]

They don't like Node because it runs in a single thread and basically forces you to use async IO or risk blocking the thread which is serving incoming requests. On most frameworks you can just to kick the user request to a background thread and do your IO synchronously there. Problem is, thread per user doesn't scale for fairly high connection counts when you are IO bound (which most web apps are). However, doing async programming is hard, because the flow of control is inverted and doesn't really follow the flow of code on the page and because callbacks become hairy when you have to chain several async operations together (what happens if a call never returns, returns with exception, etc). How do you compose the results of several async operations when the results may come in our of order? JS, as a language, doesn't provide you the tools to compose those things easily. There are third party libraries which try to fix that, such as async.js, bluebird and promises API, or Rx. You have to use futures/observables/promises to compose async tasks or things get out of hand in a hurry.

Re:Have you migrated to qbasic?

[tomhath]

People who only know one language (usually Java, or sometimes Ruby) see every other language as a threat to their livelihood. They hate Javascript, SQL, Python, PHP - everything except the only one they know. The fact is, software development languages and techniques are constantly changing; even if you don't have a need for a new language you should learn it, if for no other reason than to expand how you think.

The real question

[JustAnotherOldGuy]

The real question is why, and what would be gained from doing so?

This would be a major project, is the return really going to be worth the investment of time and energy?

I think there is often a desire, rational or not, among programmers to want to redo things and make them "clean" (whatever that means) and more efficient. It's a laudable notion, but it's often outweighed by the amount of work required to re-code everything from scratch. I've rarely found it to be worth the time and effort, frankly.

My guess is that he'd be better off optimizing some of the choke points, or perhaps implementing one of the many existing development platforms. That may require some modification, but it would still probably be a better way to go about it. It's unlikely that his needs are so out-of-band or unusual that a standardized solution wouldn't work (again, even if it required some customization).

Wanting "Something potentially scalable and perhaps even ready for zero-fuss migration to an entirely cloud-based platform" sounds very buzz-wordy to me, and that's a red flag in my book.

Finally, the statement that "it's about correctly building a pipeline that won't be completely outdated in 10 years" seems to be pure wishful thinking.

Good luck with that- I doubt ANY development environment is going to survive for ten years. That's an eternity in the world of coding and development. Tools get outdated as capabilities and needs expand and mature. Hell, I doubt I'll even be using the same text editor in 10 years, let alone an entire development environment.

Node what?

[rhysweatherley]

I have yet to come across a problem in my career where googling it reveals Node.js as a recommended solution. Not all of us are building web apps, and frankly the web app people should probably stop and consider whether a proper application is what they really need.

There are two kinds of people

[RightwingNutjob]

1. Those who use real programming languages.
2. Those who are surprised when their shit breaks because someone on the other side of the internet sneezed.

Re:Javascript is going away

[phantomfive]

WebAssembly and Emscripten are really cool technologies though. But in no way a threat to JavaScript.

The reason Javascript is popular is because in the browser, it's the only option. Once WebAssembly is widespread, that will no longer be a reason to use Javascript. That is my reasoning for explaining why Javascript will no longer be popular.

Why do you think people will still use Javascript once they have other options?