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

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?

[ShanghaiBill]

JS has become the absolute bane of the internet

JavaScript is a horrible language, as you can see. But PHP is also a horrible language. If you are writing a lot of JS for the client side, then node.js has the advantage that you only need to learn one horrible language.

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.

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.

I don't evev know what it is

[Hognoxious]

Nope. Can't be arsed. Even if I could, by the time I learn it it'll be obsolete & replaced by something with a retarded name like Cunt%% or something.

Much respect

[twistedcubic]

"...pretty, working, and half-way reliable products that make us money..."

Now that's a honest business person!

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.

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

[wbr1]

Yep, still running a Gopher server on AIX. The way god intended. Been looking at PERL 2, but me thinks it is the tower of Babel.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Ruby Community / Rails is hardly "a mess"

[KermodeBear]

I've had to learn some Ruby to support automated testing written in Ruby and Cucumber.

I hate Ruby.

Ruby feels like someone took Perl and intentionally made it even worse.

The syntax is awful. Pipes and hashes and at symbols everywhere. The documentation is not good. Many packages - I'm sorry, "gems," because we have to be cutesy - don't have documentation at all, not even in the source code. Typing? What's typing? Everything is an object! That's all the type you need, right? Curly braces? Pffft. Those are to passe. You need to close things with an 'end'. Methods with ? in the name? Sure, why not. It gets really fun when you're using that character as a method name and an operator.

I can forgive the anti-curly-brace thing, but everything else about the language feels like it was developed by an 8 year old watching bad hacker movies. So much language-specific crap that does utterly nothing to enhance readability or ease of development.

The day I never have to touch Ruby again will be a great day.

Re:Works fine

[Anonymous Coward]

All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident.
— Arthur Schopenhauer, German philosopher (1788 – 1860)

I can second that it works fine. I'll go further to say it doesn't just work well, it works!!! Sadly though, it does take a better programmer to excel in JS/NodeJS.

1) Yes, it's asynchronous and takes some getting used to. But so are real CPUs, or perhaps you didn't notice because of all the language abstraction.

2) Yes, it's loosely typed. But try passing an actual function as a parameter in a strongly typed language. Or get a function back as a return value. Better yet, get back a runtime specialized function as a return value.

3) Yes, it's single threaded. And what a God Send that is. You can have the net effect of threading libraries with thread/variable synchronization without any of the overhead. (If you learn how to program in an async environment. Which seems to be hard for some people.)

4) Yes, NodeJS uses callbacks. So learn Promises. You avoid callback hell and get extra cool features, like queueing Promises. (Oh, right. Promises are hard.) :-)

5) Forget about OO polymorphism. JS take polymorphism to a level that Java/PHP can't even dream about. What you need Java Aspects for is natively baked into JS. And it did that on day one, not seven generations later or with an addon. JS is a natural at Aspect Programming (as well as Functional Programming.) Which makes life simple to go from prototype to fully featured. Especially when you find out about "features" the week before deployment. (Hint: it's this feature that make integration testing easy.)

6) NodeJS along with PM2, gives you the advantages of Docker Containers without the complexity or overheard or wasted disk space (or the need for tooling.) And it doesn't have to run in privledged mode. Which is only important if you think security is important. :-) You can break down your API into single endpoints (or groups of endponts) and run them seperately in their own execution context. Change, replace, update, deploy services without downtime or affecting other services on the same NodeJS instance. THIS IS Micro Services!

7) NodeJS's module system let's you run several versions of the same package but only in the dependency tree where they're needed. Think of running several Java6 libraries in the same JVM execution context as several Java8 libraries, at the same time, with no possible conflicts. Blow your mind yet?

I could go on, but that's not the point I'm trying to make.

First they laughed that JS was a "toy" language. Now they're opposing it as a new platform. So when will it be seen as self-evident?

Slashdot quality has improved in leaps and bounds

[Qbertino]

David has shortened my Ask Slashdot significantly (no hurt feelings here what-so-ever), but the effort he put into his edited post is heart-warming and his preservation of the gist of my Node.js issue is spot on.

I've noticed that the quality of the editing work done on Slashdot ever since the newest crew took over is off the charts compared to everything before and I'd like to take the occasion to give a huge warm applause to the new crew and the work these guys are doing. You folks freakin' rock and I've never felt such pride in being a long-time slashdotter as I feel right now. I wish you a nice stream of revenue and happy times as the new herald of slashdot, you guys are off to a spectacular start in my book. BRAVO!

I'm actually going to point out to my geek buddies who've since abandoned slashdot (Whimps! :-) ) that now if ever is the time to return. Simply seeing slashdot soar to new heights is a pleasure in itself.

As for the discussion on my question - great input, folks.
And, btw., needs to be said after 17 years of slashdotting: You guys rock too. Of course. Naturally.

Javascript is going away

[phantomfive]

Javascript is approaching its peak as a programming language. The thing that will kill it is WebAssembly.

Soon, you will be able to write front-end code in any language you like, you won't need to use Javascript. And if you're not using Javascript on the front-end, there's really no reason to use it on the back end.

Re:Yes callback hell is a thing

[Jeremy Lee]

As pointed out, Promises are the primary solution to Node's "callback hell". People like to hate on the explicit value/error return separation, but that's merely a convention used by the top-level HTTP components, not actually baked into the language. It makes something explicit that is usually implicit.

The thing is, if you language has Exceptions and try/catch then you already have an implicit equivalent of the success/fail control split, and anyone trying to properly handle exceptions caused by their exceptions finds themselves merely in the circle of hell next door.

I've coded in node.js for a couple of years now, written some semi-big pieces of software to do real-time message passing/transaction processing stuff. It was fine. It's better than PHP, which I moved from. It's better than writing cgi-bin programs in C++, which is how I started. On of the big reasons to use node.js is it nicely integrates alternative protocols like WebSockets, RTC, AMPQ, so you can roll up a "web server plus other protocol" system that gets a lot of jobs done you just can't accomplish with PHP/Apache.

People love to hate on Javascript because they don't like admitting the language wars are over, and Javascript won. When you can walk into a room and ask "How many people have a compiler on them _right now_." and people answer "I've got at least two!" Try that with any other language. Compilers shipped, lines written, active users... JS wins on all metrics. It's not the "best" language, but then, what is?

A last note... node.js works especially well in 'cluster' situations, because to be honest, your average node.js process isn't terribly reliable. Individual node.js programs will crash on a weekly basis, thanks to funny net errors. In a cluster that doesn't matter, and in fact you WANT your 'nodes' to fail-fast rather than hang waiting for a deadlock. 'forever' restarts the errant script in seconds, but in those seconds your load-balancer should be handing the task off to another node. It's a paradox that to get a reliable cluster, you want your individual parts to be quite twitchy and explody., which node.js is.

Re:Yes callback hell is a thing

[erikkemperman]

It's a paradox that to get a reliable cluster, you want your individual parts to be quite twitchy and explody., which node.js is.

I think I get what you're saying, but somehow I don't expect this argument to convert any nonbelievers :-)

My personal favourite JS verdict is from Verity Stob, over at The Register,

CON: The most dysfunctional functional language. On top of all its well-known flaws that disrupt ordinary primitive programming, it lacks many allegedly must-have functional gewgaws. Its variables are mutable, its type holes are indubitable, its 'eagerness' unsuitable, its modules are inscrutable, tail recursion disputable, scoping inexcusable, and I'll stop there, with 'refutable' (to name but one) still in the bank, just because you were kind enough to beg me.

PRO: It's what you'll end up using.

Source: Learn you Func Prog on five minute quick!