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

It's not that bad, just don't write PHP with JS.

[Anonymous Coward]

I come from a strong C++/Java background and was drug into the Node/JS world kicking and screaming. It's still not my platform of choice but at least I don't despise it anymore. A few things:

1. Don't try to write PHP (or C++/Java/etc) with Javascript. You see a lot of people try to force Javascript into their way of programming and that's where a lot of the callback hell comes from. It's an event driven environment, just repeat that over and over.

2. Take the time to familiarize yourself with ES6/Promises/Rx before you start. Promises vs. Rx is almost a religious discussion but when you get down to it, both do the job. This helps a lot with callback hell.

3. After you've chanted it's an event driven environment often enough, start chanting everything is a stream.

3. Use eslint religiously. This will find a lot of the mistakes new programmers make, especially ones coming from other languages.

you have to be kidding ?

[joss]

I used node for a while, I should have known better, but it sure made a change. Not a good change, but definitely a change. I think this explains it pretty well: https://www.youtube.com/watch?...

Re:Absolutely not, and never will

[Anonymous Coward]

Use a transpiler then.

Write in a better language then compile to JavaScript / ECMAScript.

ECMAScript is probably one of the worlds WORST languages out there.

How about Coffee Script or TypeScript then transpile to JavaScript for deploying?

Yes and it is actually harder to maintain...

[undefinedreference]

There are more poorly-written libraries and more fragmentation in the Node.JS space than there is even in the PHP world. Beyond this, it's like developing on dev code. They've made major fundamental changes to Node in the last couple years that we've been using it that we have to almost completely rewrite our code every year or so to keep anywhere near current.

I wouldn't change. It feels like a flash in the pan tech, it's just that developers are available for it and development is pretty rapid if they use decent front-end libraries.

If I had it to do over again, we'd use front-end JS libraries with a more traditional server-side language that isn't like developing on quicksand where fundamental functionality changes require completely redesigning/developing your site code all the time.

Conflictng requirements

[lucm]

If you want to create new web applications quickly, especially ones where you rely on a REST design, node.js is fantastic. With express js you can build things with very few lines of code, and if you respect the REST spirit you won't feel like the asynchronous thing is a problem. Just find Promise-based libraries for your database layer and you'll find the whole thing very smooth. Although I find the default templating library (jade) totally unusable, which is why I usually use swig; that's something to keep in mind if you do a lot of server-side html generation (as opposed to single page apps).

As an added bonus, with a nginx/node combo you'll get better performance than with Apache/PHP and it's even easier to configure. (Although to be honest you could use nginx/fpm to get almost the same performance). Performance matters because it's easier to scale in a cost-effective way. You can start with a smaller host (like one of those $5 virtual machines on AWS) and provision as many of them as you need.

Unfortunately this beautiful agility comes at a cost: node is not a stable ecosystem and unless you're extremely diligent in managing your dependencies, there's no way you can expect the same code base to live for 10 years. Just like bower and other packagers, npm is great and solves a lot of problems, but it relies on houses of cards built upon houses of cards. Libraries hat depend on librairies are more nimble but at the end of the day you will be the one left with a pile of garbage once a few building blocks start to erode. And with npm it's totally normal to have core libraries built by one guy in his basement who doesn't maintain his masterpiece; you don't see it because each "npm install" does all the magic, but really it can be nerve-wracking when something goes wrong and you start digging for weird error messages caused by cross-dependencies in two underlying libraries you didn't know you were using. At least with PHP frameworks there's usually a somewhat structured community.

I don't pretend this is highly scientific but based on my experience, here's fhe difference between the same web application written in different programming languages:

-Asp.net takes 25% less code than j2ee
-PHP takes 50% less code than Asp.net
-Node takes 75% less code than PHP

However when it comes to long term maintenance:
-nothing comes even close to java in terms of stability. I will happily debug a war created in 2002 and figure out ways to work around old jdk issues.
-there is zero way to debug an Asp.net web application created with an old framework; just finding an IDE that will support it without trying to upgrade it (and failing at it) would prove nightmarish. And it keeps moving forward like this.
-I'd rather drink a tall glass of melted butter than debug something written in PHP3, especially with the bad mixes of html, includes and mysterious variables that may or may not come from another file.
-As for node, it's probably easier to rewrtie an app created two years ago than to try and fix it.

Maybe things will change; PHP is becoming more mature and at some point people will get fed up with the throw-away nature of node js and some stability will appear. Until then: for quick & dirty stuff node is the best, and for long term maintenance java is king. I don't see immense value in sticking with stuff like PHP, RoR or Asp.net, but to each his own.

Re:Have you migrated to qbasic?

[dgatwood]

See, I don't get all the hate towards JavaScript. From what I've seen, it's a perfectly usable language except for the lack of true classes, and even that flaw can be fairly easily worked around if you're a C programmer who did OO back before it was cool (function pointers).

What makes client-side JavaScript a nightmare is not the language, but rather the DOM, which is kind of a pain in any language. The biggest difference is that in other languages, most developers never have to deal with the DOM....

Re: Have you migrated to qbasic?

[Dracos]

No.

We don't like Node because Javascript is eccentric (read: benignly insane) in too many ways. If there was an alternative, that would be adopted in a heartbeat. Something with sensible types and type casting at least, preferably with a better, non-prototype object model.

Re:Have you migrated to qbasic?

[TheRaven64]

JavaScript has some nice features. It's a pure OO language, it has a simple prototype-based model with differential inheritance, but it also has a lot of ugly corner cases:

• 'Semicolon insertion' - the semicolon is optional anywhere that the parser can determine that one should be needed. This means that some things are either code blocks or object literals depending on how you line wrap your code.
• The only integer type is an IEEE double-precision floating point number. You can't represent a 64-bit integer without using a bignum library. Compare this with something like Smalltalk (an ancestor of JavaScript, with Self as the direct parent), where integers are either SmallInt or BigInt objects and are transparently promoted when they are no longer small enough to be hidden inside a pointer.
• Javascript has operators that work on objects, but no operator overloading. object + string, string + number, number + array are all well-defined in JavaScript. They won't throw type exceptions, but they will produce really unexpected results.
• The semantics of 'new' and 'this' binding are really weird. Any JavaScript function (which is actually a closure) can be either called directly or as an argument to the new operator. In the first case, the hidden 'this' parameter is the closure object. In the latter case, the 'this' argument is a new object whose prototype is set to a field in the function object. There are a few other subtleties.
• JavaScript is a pure imperative language. The execution model is that code is run as soon as it is read, which makes quick startup difficult. V8 cheats and just does brace matching when it encounters a function and lazily parses the function when it's first called, but other languages that have a more explicit declarative structure get this for free and have cleaner entry points (there's no equivalent of 'main()' in JavaScript).

That said, it's not significantly worse or better than most other mainstream programming languages.