Slashdot Mirror
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?
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?
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.
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.
The only upside of Javascript is that it is available everywhere. (and kinda functionaly-sh)
Everything else about that language is horrible.
I barely tolerate it inside the browser, most of the time thanks to NoScript, not even that.
So why the hell should I start putting this nonsense on servers?
On servers I typically use C++ if I can, Java is the clients demands it, Haskell if I feel playful (Yesod is really great), Common Lisp if I feel like experimenting (Hunchentoot is interesting), Python if I feel lazy and just want to get the job done fast.
I was aware that the state of Javascript development is pitiful, but the recent incident where the pulling of a simple String-padding library crashed hundreds of other projects outdid even my worst fears.
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.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
"...pretty, working, and half-way reliable products that make us money..."
Now that's a honest business person!
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.
Just cruising through this digital world at 33 1/3 rpm...
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.
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?...
http://rareformnewmedia.com/
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.
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.
Silence is a state of mime.
Code lasts a surprising amount of time compared to the mindset of the mainstream programmer. You know, the payroll stuff running on mainframes, embedded stuff running everywhere, that sort of thing. The short timespans we see on the "consumer" side, moreso on "web" and "apps" and "cloud" and other buzzwords. In fact, html5 is all about moving on from previously working stuff and "upgrading" to the latest fad. That's why it's branded a "living standard".
Anyhow, php and mysql are rotten pieces of crap and so is wordpress, of necessity since it's built on top of crap. node.js has the same problem. So you can stuff your wildly inefficient stack "in the cloud" so you can throw resources at your room-heater software with "web-scale" wild abandon. "Oh yeah, future proofing, baby!" Well, no.
Me, I make sure most of the html is of the old-and-working, not the "living (only in the latest nightly browsers)" kind, meaning I still stick to mostly html4 and css, and generate both on the pre-deployment server. Meaning most content is served statically, and can be pre-compressed. That scales wonderfully. The little dynamic stuff what's left after that, eh, we can deal with it. This is very old school, but I've yet to see the whippersnappers on the web-lawn manage to do better by throwing more code and more stack layers, even more stacks, requiring more resources, at the problem. It really doesn't matter what flavour they pick, as they keep on picking the suckiest, ickiest flavours. Like, oh, php, mysql, and node.js. Migrate from shit to crap? Maybe the other steaming heap of manure will stink less? Geeze, I don't know. Why don't you try and find out? I'm sure it'll be a worthwhile experience! Don't forget your complimentary family-sized bottle of turd polish.
A lot of people are spewing a lot of well-founded hate at the node platform, but the comments are missing a lot of substance.
Node is just ok. What it is amazing at is doing lots of asynchronous IO, and has some libraries that make this pretty easy (i.e.: async). When all you need to do is read files and hit APIs and write files it's great.
Now node has a lot of shortcomings. For one, it's really not that fast when doing actual processing. If you need to do any kind of remotely complex calculations, including things like html template rendering (handlebars), data structure transformations or even like zipping/unzipping, it's slow as a dog. And since data calculations aren't IO, async operations actually start to slow you down. AND, unless you explicitly do things in an async manner, your whole node process will lock up and only that one task will execute, which can cause all kinds of latency issues with your app.
One can argue that ruby, etc suffer from the same fate and that's why you have multiple processes running. But because of node's async nature, if you are using a web framework like express, each process will potentially be handling multiple clients. And process that's processing will cause those clients to get slower responses and any crash will kill all of those clients.
There is also the mess that is npm, where it becomes very easy to have a 700MB dependency directory which SUCKS to deploy to multiple servers.
That's just my experience as a node Dev for the past 18 months.
...spike
Ewwwwww, coconut...
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.
Comment removed based on user account deletion
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.
Love sees no species.
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.
lucm, indeed.
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?
You don't need to.
Both have correct Ruby syntax.
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?
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.
We suffer more in our imagination than in reality. - Seneca
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.
"First they came for the slanderers and i said nothing."
Look back on the hype cycle of MongoDB and NoSQL: it was all the rage three years ago, now it's a fountain of regret. The same will happen with Node.
I don't know if aspiring to PHP levels of maintainability/readability is a high ambition. Also, when the question is 'should I migrate from php', a sentiment that suggests 'about as good as php' doesn't seem to be a ringing endorsement.
XML is like violence. If it doesn't solve the problem, use more.
Node is very good for processes that hit a database and/or file-system with "simple" manipulation. You will have to think asynchronously, and you will want to learn promises. Where it shines is when you have a lot of simple things to do during a method, and you can do those things concurrently. It's great for squeezing out every last ounce of CPU/core capacity - which can be priced at a premium if you are on "the cloud".
For web-hosting, you can use something like Express, and implement it with clustering to scale out to your server's capacity with regard to CPUs/cores. This gets very clunky, very fast, much more so than PHP or even ASP.MVC. It seems like a solution looking for a problem. I'd avoid it.
One of the better implementations I've seen of Node is in AWS. You can upload a Node package to their Lambda service, and trigger based upon a schedule, S3 (file) event or an inbound web call (via API gateway). It pretty much scales "auto-magically". But there are limitations. You have some utilities like Ghostscript available, but you are mostly limited to the version they have on their server images. You can include your own executables (by building them in an EC2 instance), but this increases your package size, load time, etc. If you want to use Node for a website, I'd probably limit Node's use to webservices (AJAX) for hitting the database and business logic; and drive your site's UI using a client-side engine (Angular, react, etc.). You can use it very effectively for back-end processes thumbnail generation, email notifications, etc.).
For "quick & dirty" websites, I'd probably avoid Node, unless you are going to drink the "cloud Kool-Aid" (especially with AWS Lambda); then Node might be a fit if you are going to craft custom sites where scalability and cost management are significant considerations.
I gotta remember that one. Seems to be a apropos description of several projects at work.
CUR ALLOC 20195.....5804M
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.
Jeremy Lee | Orinoco
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.
Yeah. I think most strongly typed languages can do that perfectly fine. C++11, for instance, does it pretty well.
Because when you need to get the page built and back to the user in 10ms, you control path through the program must be explicit and direct, both for the normal control flow, and the error path
And because the alternative to single-threading is multi-threading, and that sounds like a great abstraction until you realize how much time is lost acquiring and releasing locks, and performing context switches. And you see your code complexity balloon because you have to deal with all the cross-thread synchronization. And it's hard to test.
The alternative to single-threading is a system which can interrupt the current page build with the _next_ page build (multithreading!) and that almost always makes things worse.
Node.js responds to server overload by rejecting page requests because it's busy - something the outer load balancer can deal with in milliseconds. (You have a load balancer, right?) Multithreaded programs respond to overloads by slowing down, running out of stack space and crashing. If you're running a real-world web app with thousands of users, one of those is worse.
Jeremy Lee | Orinoco
You really should upgrade to perl 4. Perl 5 has a lot of nice ideas but comes with a lot of nonsense where they tried to make it object oriented and modular which you don't need, so stay away from that.
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!
Gosh, thanks. That must be why the other ships call me Meatfucker -- GCU Grey Area (Eccentric)
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
How about replacing it by a less-assed LAMP stack? You know, the answer to a broken wheel is not to sit down and reinvent the wheel. Generally, it is faster, cheaper and smarter to simply get a proper wheel.
I've refactored projects, both successfully and with failure. This is one area where the old estimate rule-of-thumb (take your best guess, double it, then increase the order of magnitude by one, i.e. replace hours by days, days by weeks, weeks by months, etc.) is so absolutely true. If you have a working pipeline, no matter how bad it works, you will dramatically underestimate the effort it takes to rebuild that pipeline on a different technology.
Sometimes it is worth the effort. Typically, not. Replacing wordpress with something non-broken is probably ten times faster and easier than reinventing the whole thing.
Assorted stuff I do sometimes: Lemuria.org
As a sysadmin (devops?), I don't have anything against the language per-se, but so far, I haven't been impressed with the packaging and deployment options. Maybe I'm not doing it right (quite possibly), but so far I'm not especially impressed with npm and pm2. I find they're both a bit opaque and don't feel very natural to me - I don't feel like I have proper control over them - it feels like they're doing 'clever' things on my behalf which I'd rather do myself.
None of that is a reason to avoid node.js, but it's not a glowing endorsement for it either. Ultimately this shit has to run in production, and that means people like me have to deploy it. That means we want 'clean' and reliable, repeatable (etc) ways to get things onto boxes. It feels like the node.js world is about as ready for production as Ruby, Python etc. All possible, but none very friendly.
Java, for all its faults is actually pretty easy - you can have multiple versions of the language, libraries and application quite easily. Perl's weirdly pretty easy too (although in truth, multiple language versions would be fairly painful). PHP is really easy, so long as you want it in Apache web server (but again, multiple versions is hard).
Agreed. a PHP Programmer calling Ruby a mess is just deluded or plain stupid.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
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.
Well that's not really a big selling point. In the last couple of years I've worked on Java and Python projects that used WebSockets, RTC, AMQP, NoSQL databases, etc. Not only are these protocols well supported but in both cases you get a much richer and more robust platform to work on.
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?
And this is frankly misleading. Yes there's lots of Javascript code around, bit it's primarily on the client side. One of the biggest issues I've seen with node.js is the number of people who have only ever coded Javascript UIs, but who think that with node.js they can put "Server-side developer" on their CVs. It doesn't work that way. Backend development is an entirely different proposition.
There's actually not a lot in Ruby that you can't modify at runtime. You can't break variable assignment, and I don't think you can erase the concept of class inheritance, but most other components are up for grabs. It's perhaps not quite as flexible as Lisp or Smalltalk, but there's definitely no shortage of hanging rope. Metaprogramming Ruby was an enlightening look at how this can be put to practical use. Personally, I think that "monkey patching" is grounds for "developer punching", but there are a great many tools which improperly used make superlative footguns.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.