Why I think Node.JS is a terrible platform

http://dev.hasenj.org/post/31042963934/nodejs-hate

by hasenj • 14 years ago

100 141 14 years ago

dev.hasenj.org

marshray7• 14 years ago

tl;dr: "Node.JS is a terrible platform [because] the async-style of programming is almost entirely inaccessible to my brain."

hasenj14• 14 years ago

Not only that, but also because there are better alternatives.

If there was no way to do scalable web services or provide things like websockets other than node.js, then my objection would be completely invalid.

syncerr• 14 years ago

I'm not sure that "Node.JS is a terrible platform [because] there are better alternatives." is any more valid.

marshray7• 14 years ago

Look at it this way:

Async event-driven programming is not going away, it's probably always going to be the most performant model because incoming packets translate into interrupts and kernel mode and thread context switches are expensive.

Javascript is not going away, and has become shockingly efficient with V8.

These are both forces of nature in their own respective domains. So somebody's gonna combine them to implement an async IO reactor system in Javascript. This is Node.js, which looks to me like a pretty decent implementation of the idea.

It may not be your cuppa tea, or the best way to implement every dynamic website. It just is what it is: inevitable.

peeters• 14 years ago

I've never jumped on the Node bandwagon either, because I detest Javascript, but...Shouldn't async-style programming be fairly familiar to Javascript developers? At least those who have ever made an AJAX app?

It seems like it was a paradigm shift for the author, but I wonder if it actually is for most people who Node is primarily targeted towards: those who like and regularly use Javascript.

hasenj14• 14 years ago

I'm actually quite familiar with JS and comfortable with writing callbacks on the client. It's very different from doing server and backend code.

On the client, you don't make too many calls to the server, and if you do, I'd consider that you're doing something wrong.

What I mean is, on the client side, if you need to make 10 calls to the server before you can display something, you're obviously doing it wrong.

So you can avoid a callback mess by simply making sane design decisions.

But on the server side, you have to make several calls to the DB, and thus, the callback hell is unavoidable.

rdtsc2• 14 years ago

I have been doing async-style programming for a while and still consider it terrible. I had to do it because at the time there were no better alternatives given my constraints. I could have told you then it was a bloody mess when evaluating it and I can tell you the same now. In other words it seems "accessible to brain" and a "better platform" can be independent.

qxcv• 14 years ago

It's not that async is hard, it's that callback-based frameworks like node.js force the programmer to structure their code in an entirely different (and more verbose!) way to what they would writing synchronous code. It doesn't help that the shortest way of declaring a function in Javascript is function(){...};

Look at coroutine-based frameworks like gevent if you want to see what easy async looks like. You'll still have to remember you're writing async code, but instead of do_lots_of_io(function(){wrap_up_afterwards();}); you can just do_lots_of_io();wrap_up_afterwards();. It makes code infinitely more readable.

mchahn• 14 years ago

> It doesn't help that the shortest way of declaring a function in Javascript is function(){...};

-> is much shorter.

cliftonk• 14 years ago

I've been using NodeJS in production for a few years, and I'd agree that is probably not the best way to write an application with many layers of business logic.

That said, it's wonderful for networking, child process management and handling subscription connections (via Socket.IO, etc).

Effective evented programming does have a radically different style, and many times it boils down to tastefully drawing the line between when to bind and trigger events vs when to pass functions as arguments.

hasenj14• 14 years ago

> I'd agree that is probably not the best way to write an application with many layers of business logic.

Exactly!

Which, to me, means that it doesn't scale well. (Scaling here refers to growing the size and complexity of the program - as opposed to handling an increasing number of concurrent connections).

And, given this point, why should anyone use it as a platform to build their product on?

tfb2• 14 years ago

Just today I devised a pretty solid method to build a fairly complex node.js app while keeping it simple, maintainable and scalable.

I like the way node kind of enforces modularity, but for something as complex as the backend (super-flexible api for a frontend dbms) required for my project, it would save a lot of time/effort/ugliness-of-code to have a few objects on the global scope while allowing individual parts to be split up into their own files; e.g., a few utility functions, String/Array.prototype functions, a socket.io instance, and a redis client instance, among other things.

And to make things manageable and more extensible all while minimizing duplicate code, I ended up using John Resig's "Simple Javascript Inheritance": http://ejohn.org/blog/simple-javascript-inheritance/. I like being able to simply call Class.extend({}) to create/extend any class with access to its "super" functions. Each class is contained within its own file, of course.

The method is pretty simple: 1) Organize and order the files like you would on a client (web browser) where "global" variables are allowed. 2) Use some program to concatenate the files in the correct order into a single node app.js file for testing or production.

I'm currently using a batch script (yes, I use Windows :P) that looks something like this:

  del app.js
  type global.js >> app.js
  type appBegin.js >> app.js
  type loggur.js >> app.js
  type classes\Class.js >> app.js
  type classes\Client.js >> app.js
  type get.js >> app.js
  type post.js >> app.js
  type set.js >> app.js
  type socketsOn.js >> app.js
  type appEnd.js >> app.js

Don't get me wrong, node's module system is used when it makes the most sense. But for what I need to do, this works perfectly. It doesn't promote spaghetti code the least bit; everything is easy to read and follow (could even call the code pretty!); it's 100% clear which objects are shared (especially since most files contain a single object or class); and as long as the method is used consistently, you get all the benefits of node/socket.io while maintaining cleanliness and scalability.

ebiester2• 14 years ago

What bothered me is that I couldn't find a way to find out what code had triggered an event, or what listener was attached where. So, suddenly you're getting an error in code and you can't figure out why it's even being called, because it was attached from one of eight libraries that you picked up as to not reinvent the wheel.

...and grep emit isn't an effective solution. :)

I put a question up at SO and never received a response. http://stackoverflow.com/questions/12215273/how-are-event-tr... -- the problem itself I finally worked through, but then I ran into another. And another. And while I know my fair share of JS, and have no problem with async programming, node.js still felt awkward after a month. So long as I was in my own code, I was fine, but reasoning about code I hadn't written was painful not because of the language, but because of the flow it took.

ricardobeat5• 14 years ago

Your question doesn't provide enough details for anyone to offer any insight, unless they've seen this exact error before.

From the error, I'd guess that you were trying to insert an email into an integer field. Check the db code in the event handlers, add some debugger calls (you can even step through code using node-inspector), done. There aren't magical solutions to application-specific errors.

irreverentbits• 14 years ago

WebSocket protocol is pretty easily implemented in pure Python; my co-founder and I did this just recently to support some of our game client functionality.

BarkMore• 14 years ago

Not only is the protocol easy to implement, some Python servers come with WebSocket support. Tornado (http://www.tornadoweb.org/documentation/websocket.html) and Autobahn (http://autobahn.ws/) are examples.

masklinn• 14 years ago

> Not only is the protocol easy to implement, some Python servers come with WebSocket support.

Even when they don't, it's easy to find. There are both websocket and socket.io implementations available for gevent for instance.

erichocean• 14 years ago

Out of curiosity, does your hand-rolled Python implementation actually pass this test suite? http://autobahn.ws/testsuite

exogen3• 14 years ago

"You lose expressiveness, you lose maintainability, you lose peace of mind"

Really, you found all that out after your experience...wait, what experience? You said yourself you failed to build a single simple app. So it seems to me you can only comment on expressiveness.

I'd love to read your review of, say, Haskell next. I have a feeling if you applied the same (lack of) rigor you demonstrated here, it would be double extra terrible. The point being, there's no substance here, but it confirms people's negative feelings about JavaScript, so they'll upvote it.

frio• 14 years ago

I assume you're getting downvoted for an aggressive tone, but I can't help but agree. "Lacking rigor" is a generous way of describing the article.

heretohelp6• 14 years ago

It's pretty easy to find alternatives to Node.js that are a lot more sound, a lot easier to work with, and a lot more performant if you need asynchronicity. You gain nothing save for the ability to use JS itself, for which the supposed benefits of sharing code are a total wash.

Node.js is async for people who don't actually know what they're doing, but are still willing to push an unnecessary boulder up the hill for the sake of a familiar language instead of learning how the industry's been handling async for the last few decades.

Node.js users "lack rigor", not this guy for questioning the ridiculousness of it all.

Go look at SFS/sfslite and its ilk to see how async is supposed to be done.

exogen3• 14 years ago

Do you mean this SFS? http://www.fs.net/

That appears to literally be the official website.

Sorry, but your post just sounds like "get off my lawn!" But good luck trying to convince everyone to write their web apps in C++.

bengillies• 14 years ago

> Node.js is async for people who don't actually know what they're doing

"Node.js is rubbish and if you like it and try to argue otherwise then, as I've already said, you don't know what you're doing so I can just ignore you."

Clever.

illicium• 14 years ago

Looks like the author got upset that he needed to learn a platform in order to use it.

Another issue is that JavaScript doesn't really lend itself to continuation passing style, leading to ugly nested callbacks. There are many libraries that make this more manageable, like async: https://github.com/caolan/async

hasenj14• 14 years ago

I'm upset because I invested a substantial amount of time without really reaping much of a reward (other than knowing to avoid it). I'm upset because there's a lot of unreasonable hype.

marshray7• 14 years ago

I find that stretching my head around a new and different paradigm is it's own reward. Everyone's different and has different goals.

If your goal is to implement dynamic web content as productively as possible, no one will fault you for sticking with what you already know and are comfortable with. But it's not valid to conclude that everything else is terrible if it doesn't improve the type of things that you do.

Personally, I've lost count of the number of times I'd wished a blocking API call was instead non-blocking. Do a survey of how many desktop Windows applications are able to exit gracefully while a File->Open dialog box is still open.

phildeschaine2• 14 years ago

> without really reaping much of a reward

So because you were unable to figure it out, no one else will ever have success with it?

> unreasonable hype

Welcome to the real world. Not everything that deserves accolades gets them. The things that are successful- they don't necessarily deserve it. Just look at top-40 music.

So anyway, your post is against the attention the framework has gotten, not the framework itself?

marshray7• 14 years ago

Awesome, thanks for the link.

I'd been experimenting with Node.js the other day and ended up reimplementing that 'async.series([...])' function.

Node-lazy is another module that looks very useful.

bunkat2• 14 years ago

Whenever I read something like this I always just tack on 'for me' to the end of the title. The article makes a lot more sense if you read it with this perspective. I always did the same thing when a developer would tell me something was too hard to do.

hasenj14• 14 years ago

That's sort of why I put the "I think" bit on the submission's title.

bunkat2• 14 years ago

Right, you think that Node.js is a terrible platform for you. I'm pretty sure that everyone here would agree with that statement. You really can't make any more general of a statement than that though given your limited experience.

omidmnz• 14 years ago

Nose.js is a great platform , but not for YOU needs. You don't like Node.js, so you won't like Twisted and Tornado in Python too. The thing you hate is not Node.js, but it is its approach. And the reason is, that it is not designed for YOUR needs. That's all.

hasenj14• 14 years ago

What is it designed for?

It's being hyped as a platform for writing scalable web applications. Not simple networking tools or little glue utilities, but large, complicated web apps that people have been using ruby and python to develop.

loucal• 14 years ago

from nodejs.org "Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices." That doesn't say to me "create large, complicated web apps with this". As a matter of fact, in my personal use node has showed its usefulness most when I am replacing small parts of my app that function slowly or poorly in some other way and moving toward a more modular approach.

zobzu• 14 years ago

to be honest, I think one of the key issues with "javascript" and "fast" in the same sentence. (yeah, this reply would be better beneath you, but HN says I can't reply to that guy.)

The reason why NoeJS is "fast" isn't JS. It's being event-driven. I also believe JS isn't as easy to work with as python by design, even thus there are zillions of JS coders. Most of the people indeed follow the hype, more than "wait, is this actually something I should use" (you also did follow the hype and got bitten by it, in fact)

oron• 14 years ago

The async nature of the language and platform is very easily managed with libs like https://github.com/caolan/async, I came from Django and to me, once I mastered the async nature and understood it, nodejs was a breath of fresh air.

tikhonj2• 14 years ago

I think that a much better alternative to Node than Python or Go is Haskell. Why? Well, for one, it makes writing asynchronous code very easy--you essentially get it for free. Haskell web servers perform very well while keeping the code readable.

However, ignoring performance, there are also all of Haskell's other advantages. The type system is great--you can do stuff like ensuring links within your app work using the type system. Haskell is also very good at embedding DSLs, which can make writing web-specific code much nicer. In my experience, Haskell code tends to be more concise and declarative than Go or Python, making it easier to read. And, crucially, you can program at a higher level of abstraction which makes it both easier to write and maintain relatively complicated code.

Now, admittedly, going from almost any other language to Haskell is quite a shift. For most programmers, learning Haskell will take a bit longer than learning yet another imperative language (e.g. Go). However, I think this is well worth it, and web apps are a particularly convenient field for it.

This[1] StackOverflow question and an associated paper[2] are very interesting to read about how a Haskell web server could work and have good performance.

[1] http://stackoverflow.com/questions/3847108/what-is-the-haske...

[2] http://community.haskell.org/~simonmar/papers/web-server-jfp...

It would also be useful to look at a Haskell web framework like Yesod[3], Snap[4] or Happstack[5]. I'm currently a little biased towards Yesod (which has, coincidentally, recently received commercial backing), but I think the choice of framework is largely a matter of preference.

[3] http://www.yesodweb.com/

[4] http://snapframework.com/

[5] http://happstack.com/

realrocker3• 14 years ago

Finally I am convinced about Haskell. I am giving it a shot: http://learnyouahaskell.com/chapters. Thanks :)

gtani• 14 years ago

There's lots of books, you can find RealWorld and Road to Logic online too (not sure if RtL is legit)

http://alexott.net/en/fp/books/#sec7

and tuts

http://www.haskell.org/haskellwiki/Learning_Haskell

http://www.haskell.org/haskellwiki/Category:Tutorials

SkyMarshal• 14 years ago

/second Haskell. If I could do everything in it I would (stuck with JVM for some things though). Ryan Dahl even looked at Haskell before choosing V8, said the language is ideal but hacking GHC was too complex:

>I was into Ruby for a while, I said, but eventually the VM just drove me insane, because it's just so slow, every time you try to make it faster you realize: "OK, I am just going to write this part in C" and every single line of Ruby that you add to your application, actually just slows down the server noticeably. And so eventually I just kind of ended up with this big C thing that I was kind of happy with, like OK I could write a web server with it and I could do file IO and so I had for a long time the idea of "I would have this kind of library that abstracted some part of the problem away and people can write it in C and they can write their little web servers.

People don't like writing stuff in C. Basically I want to put people in this non-blocking environment because it is the right way to design a server, it just kind of maneuvering around all the other pieces of the computer system and I would really like to do such a thing in Haskell or some sort of declarative language like this, where you could literally be purely functional when you receive events off of the socket, because all your side effects would happen on the event loop and you would just allow that to happen and then you kind of get a function call with some data and you would do whatever with that, make some call which would not have a side effect, you just write something to some buffer that would get flushed to the kernel and then you drop back down to the event loop.

Side effects would happen, everything would happen and then you get another call from that. But when you are receiving an event from the event loop you could be purely functional, you could really have nothing to do with anybody else and that is attractive. But you look in the GHC code and it's very hard and I am not such a good programmer and I gave up on that. And then V8 came out and it just kind of clicked. I am not a Javascript originally, have nothing to do with that really, but it just seams like a natural sort of thing once I started poking around VA.

1. http://www.infoq.com/interviews/node-ryan-dahl

zemo• 14 years ago

you're out of your skull if you really think that Haskell has a shot in this market. Node.js is popular because it's easy to learn. Haskell fails there. That's probably the most important factor for web frameworks. Remember the total fucking trainwreck that is Rails, and how popular that was (and still is)?

Technologies don't become popular on technical merits alone. Haskell fails at psychology.

tikhonj2• 14 years ago

I never said Haskell would become popular, I said it was the better alternative. I don't expect every web developer to drop what they're doing and pick up Haskell--but I do expect some of the best ones to do so :P. I honestly don't care that much about what most people are using anyhow.

You really shouldn't choose your technology just based on popularity. Sure, it's a metric. But I don't even think it's an important metric. So next time you start a company, think Haskell and ignore the peer pressure to choose something common :).

To me, popularity is not really a goal in and of itself. As long as something is the best to use, I'll use it even if it's not terribly widespread. Sure, popularity is nice and brings some benefits, but I'm never bound by it. After all, I use Linux too!

kombine• 14 years ago

Are there libraries similar to Socket.IO for Yesod framework?

ludicast• 14 years ago

I believe they are building sockjs, which is better than socket.io, in haskell so you should be able to use that someday soon.

megaman821• 14 years ago

I don't think Haskell will ever enjoy wide-spread adoption (although I wish it would happen). Haskell really does have the best constructs for parallelism. You have sparks, which can map to Haskell threads, which can map to OS threads. Using an evented system would be similar to using Haskell threads except Haskell can utilize more than one CPU core.

dynamichype• 14 years ago

This post shows exactly why "just use code to get things done" can be taken too far and why a solid theoretical background can be essential to growing as a programmer. The author bravely admits, "The async-style of programming is almost entirely inaccessible to my brain." There comes a point on the road to being a great coder where you can no longer really approach it as a craft; the theory and philosophy start to matter. A common plateau is the point where it becomes necessary to see the commonality between essentially the same computation being driven by different control approaches. I've seen many a competent procedural programmer be unable to write their first GUI app because they can't adjust to an event driven model or unable to make the most of SQL because of its semi-declarative nature. Coders need to see such mind expansion as an essential and fun part of the job.

phildeschaine2• 14 years ago

Node.js can be made to be plenty writeable and readable once you wrap your head around asynchronous programming. I'd write everything in my life in an asynchronous way if I could.

DigitalSea• 14 years ago

I encountered the same issue. I found the callback oriented programming style to be confusing and overly complex for the sake of a fast application. Although I managed to build something and still work with it, the uses for Node.JS are quite limited.

Want to build a realtime analytics platform? Node has you covered. Want to build a super lean and powerful server for an iPhone game? Node also has you covered. Want to build a web application that doesn't require anything realtime? Not so much.

Node serves a purpose for a lot of things, anything that requires a lot of connections and continuous streams of data it is a perfect fit, but nothing much else.

As for the Python remarks and websockets, I find Beaconpush does the job well: http://beaconpush.com/ - the server that drives Battlelog on Electronic Art's game Battlefield 3 is a python framework with websocket support, I believe it uses Beaconpush.

jasonkester• 14 years ago

I get the impression that a lot of people are trying to use Node for things it isn't particularly suited for. That being, 95% of the things you'd want to build on the web.

My take on Node is that it's what you use when you want to build an Etherpad. If your app will have 1000 people messing with one thing at once, with all their interactions propagating out everywhere instantly, you're going to want to use Node. If you're building a mmorpg-in-a-browser, you'll probably find Node will be a good fit.

If you're building a CRUD app, however, Node is likely the worst choice you can make in terms of productivity lost versus advantage gained. I mean sure you'll pull it off. But the kid who wrote the same thing in Rails will be on his third failed startup by the time you get your MVP launched.

There's probably a balance that you can strike for apps that "sorta" need Nodeishness. Use a standard, non-insanity-inducing stack for the bulk of the site, then keep a Node instance off in the corner to run the "App" bit that needs the realtime communication.

I think this message got lost somewhere along the way, and now we're seeing a lot of frustration from people using this cool, specific, technology for stuff that it's just plain not suited for.

msy• 14 years ago

I understand node is quite good at those scenarios but is there any real advantage over say Ruby/EventMachine or Python/Twisted or if you're serious about it scaling, Erlang/OTP? Evented systems are great for those scenarios but I can't work out if there's some secret sauce in Node I'm missing or whether there's a lot of excitement from people that don't realise there are mature solutions to those scenarios in other languages.

luriel6• 14 years ago

If anything Node is much more limited than the alternatives, both because of the language it uses, and because of limitations of the implementation, which basically (rather ugly hacks aside) doesn't scale at all beyond one core, and if any of your code turns out to be CPU bound, your performance goes right out of the window.

Go and Erlang are much better both in the concurrency models they provide and in their performance and scalability. Not to mention they are real languages carefully designed over many years by talented language designers, not the result of unfortunate accidents of history hacked up in two weeks like JavaScript.

b3tta2• 14 years ago

luriel wrote a nice answer, like a good, old hater would write. (You can't just go around and insult programming languages. They have feelings too, dude.)

is there any real advantage over I think that's the wrong way to choose a platform. Are you good in Ruby? Then use RoR. Are you good in JS? Then use node.js. Maybe RoR is a much better platform than node.js, maybe it's not. But I finished writing my framework/application 10 times, before you even typed RoR. :D Furthermore: You. Don't. Use. node.js. For. CPU heavy. tasks! Don't do it. For everything else I think it's a wonderful framework, if you want to write something I/O heavy.

btw: The strict asynchronous programming style, using JSs closures, is pretty much the same thing you would write in C (except for that you don't have closures). I recommend everyone to look at least once into https://github.com/joyent/libuv/ But unfortunately many "programmers" here won't do it, since C is stupid and for old farts. I mean: I can do anything in C# in a tenth of the time compared to you with C (http://programmers.stackexchange.com/q/164017)

thedufer• 14 years ago

There are a number of reasons. I work on one of the larger node apps out there, and its working great for us (admittedly, we use CoffeeScript, which eliminates half of the arguments made against node).

- Server/client sharing. This sounds like its not a big deal, but it is if you're writing an app for which node is a good choice. Our code is close to 50/50 client/server (maybe a little server-heavy), and the amount of shared code is fairly surprising. - Native JSON. All of the data that we send from our servers is JSON (with a few exceptions for errors). Mongo speaks JSON as well. Its extremely useful that all of our data is in the same format, including that going over the wire and that inside our code. - One language. I've used server-side Python before, and it is way easier to only have to think in one language, especially if you jump between server and client code often. - CPS. Everyone's hating on it, but its hard to see the advantages of it without working on a large project first. I was very skeptical when I started, but it really works well. Most people are immediately turned off by the amount of nesting involved, but a simple async library resolves this nicely. - Javascript. It has problems, but most of them are ways to shoot yourself. If you avoid shooting yourself, it really is a beautiful language.

The biggest problem with node is that the average programmer* probably can't grok CPS. Its honestly a lot harder than most code you'll see. That said, I can't imagine the codebase that I work with being less than an order of magnitude larger without it, so its well worth it.

*In my experience, the average programmer can't grok recursion or pointers, either.

burke• 14 years ago

I did build something extremely similar to an EtherPad using node.js a couple months ago for a toy project, and let me tell you, it would have been a lot easier with Go. We only went with node.js because of existing library support (google auth and the like).

BasDirks• 14 years ago

Another "mommy I quit because it's too hard for me" post. Why is that tolerated? He doesn't even present an interesting perspective on the technology. "I cannot build cool things with Lego, so Lego is terrible". Yeah awesome.

stickfigure• 14 years ago

I write applications professionally in Python, Javascript, and Java. While there is some overlap, I find each platform to have merit.

* I like Java for projects that I know are going to become big and complicated. When you have thousands of classes and multiple people working in a codebase, static typing is a godsend. I don't care if it involves a little more typing. As an added bonus, the JVM performs great.

* I like Node.js for small projects, especially ones with large concurrency needs. I recently did a project that involved being able to aggregate repeated barrages of several thousand requests with a finite deadline of a couple seconds. Node.js handled twice the throughput of Twisted or Tornado, and was considerably more stable. Gevent and coroutines would have been even slower.

* I like Python for stuff "in between". Rich libraries, blocking i/o, exceptions, and proper stacktraces. Even has halfway-decent IDE support (PyDev). Execution is slow by JVM standards but Python makes a great swiss army knife.

There's no perfect platform for all situations. Use the right tool for the right job - sometimes that's Node.js. There's a lot of overlap with Python, but not as much as you seem to think.

realrocker3• 14 years ago

I had the same experiences as you did because of jumping on the bandwagon. Hasen, when you opined "Node.js is a terrible platform", I thought you would also say something about the bad decisions we make because of it. This is how I made mine:

Day 1: Let's Node.js because everyone is doing it. In that context, no-sql databases gel very well with it, so let's do that.

Day 3: Whoaa! Prototype is already done. Great

Day 4: My databases entities are so thin, sql databases are so overrated. I don't need sql.

Day 6: Uh-Oh, I did not think of that database entity. Oh no, look, it has a relationship too.

Day 7: Frack, the no-sql CRUD operations code is damn mess.

Day 8: More relationships! "If I only had used sql". Sighs. Oh wait, look a node.js-mysql library. (Code Hustle). No no, it is still a mess. Well, it is still working so let's have a little patience.

Day 15: Why my code looks like a puke?

Day 20: Ok, I/O code is now like 7-8% of my complete project. Why did I go for Node.js again? This doesn't make sense. I am going on a vacation.

Day 27: First thing back from vacation, farewell Node.js. Let's go for Flask(python) + SqlAlchemy(oh I missed you so much) + Gunicorn + Gevent + Juggernaut(for websocket.Node.js, you found your rightful place).

I think the reason for such hype around Node.js is due to the rise of a new class of startups which are born with a "fail-fast" mentality. Node.js does help you to fail fast. But I think that it is a pessimistic view of idea and software development. Agreed that node.js removes the initial inertia to implement an idea, but I think that this is it's greatest failure. A little inertia can be good. It forces you to sit down and think hard about the architecture and the idea itself. It's same as a small group of lean mean soldiers can extract a defended fort from the enemy, but holding the fort would take a lot of strategic thinking, resources and more soldiers. I think it's time to get a bit optimistic about our own ability to do that. Well, unless, you never wanted to hold the fort. In that case, everything is just fine.

batista• 14 years ago

>Node.js does help you to fail fast.

Quote of the year!

PommeDeTerre• 14 years ago

I've seen many people and organizations run into problems like you describe. I don't mean to come off as insulting to you, but the only reason I can see a path like that being taken is out of complete ignorance.

At the beginning of your project, how did you ever think that it'd be a good idea to use JavaScript, Node.js and NoSQL? Yes, there may be a lot of hype around them, but after a brief analysis of them it's clear they're inferior to most other options that are already available.

I can completely understand JavaScript being used for browser-based scripting, where it's basically the only practical option. But why would anyone ever consider it for server-side development, given that so many better options are available?

The same goes for Node.js. Reading a brief introduction to it only serves to make Erlang and Go, among other options, look far more appealing.

And again, the same goes for NoSQL. Cursory investigation reveals that anything that can be done with a typical NoSQL database can be done with any capable relational DBMS, plus you at least get the option of using proper SQL queries if necessary.

So how can a month (or much longer, in some cases I've seen) be wasted on obviously-inferior technologies? Was it really not obvious at the very beginning that the outcome would be disastrous?

realrocker3• 14 years ago

The project started out as a minor one, but after a few successes it kind of snowballed. If I didn't had those earlier successes, I would have introspected about my decisions earlier. Unfortunately I got fooled into thinking otherwise. These small successes turned out to be red herrings. Also, it's hard not to give into mass hysteria and perhaps I wanted to taste the impracticability for myself. Thus, despite reading all about node.js, nosql and their horrors, I got greedy.

jarrett• 14 years ago

"I wasted a lot of time trying to learn node and do something useful with it (other than a dumb file server), but couldn’t. I just didn’t really know where to begin...The APIs might have been documented, but it wasn’t clear how to piece things together to make something useful."

I haven't had this problem myself. To me, piecing together different libraries in Node feels much the same as it does in any other language. You find the libraries via Google, you learn the APIs, and you write glue code to hook them in to your business logic. I'm not sure what would make Node at all different in this respect.

"The async-style of programming is almost entirely inaccessible to my brain."

I'm guessing you're referring to the mess of ultra-deep, nested callbacks that plagues many Node apps. If you just keep nesting callback after callback, then yes, your code will be ugly and unmaintainable. But there are solutions to this. Look into control flow libraries like Step.

"So what exactly is your excuse for choosing Node.JS as your backend platform?"

Here's my main reason. When building for the web, Node can sometimes be far more maintainable than many other platforms. That's because you can share code between client and server. Admittedly, the community hasn't yet settled on a best practice for implementing client-server code sharing. But folks have found ways to do it that work, and you can just pick one that feels good. Sharing code is a big maintainability improvement if you have a thick client that knows a lot about business logic.

jeswin• 14 years ago

You lose expressiveness, you lose maintainability, you lose peace of mind, and you get speed.

- I don't think my JS/CoffeeScript code is (significantly) less or more expressive and maintainable than the Python code I would have written. Use coffee if you want a whole bunch of language features, including some missing in Python. Oh, and a much cleaner way to write lambdas.

- Yes you need to understand async. It is of course, increasingly relevant with services and devices talking to each other. For example, in Microsoft's WinRT anything taking more than 50ms has to be async by design. After a while you might even wonder why async isn't the default way of doing most I/O.

- Flow control is hard in async, especially when you are getting started. But there are libraries which help, such as https://github.com/caolan/async.

- The library approach works for me and is a safer bet, but isn't the cleanest. If you are adventurous you could try iced-coffeescript, which introduces keywords to give you simpler code.

- Finally, you need to have a really good grip on JS.

hasenj14• 14 years ago

> I don't think my JS/CoffeeScript code is (significantly) less or more expressive and maintainable than the Python code I would have written

The loss does not come from JS or coffeescript, it comes from everything being done with callback (whether nested or not).

calibraxis• 14 years ago

Those wanting to succeed with node.js should listen more closely to the parent post. IcedCoffeeScript promises, "Say goodbye to callback pyramids; say adios to massive code rewrites when synchronization requirements change slightly. Say hello to clean, readable, maintainable control flow for network and asynchronous operations!" (http://maxtaco.github.com/coffee-script/)

Personally though, I haven't yet tried/loadtested it, so can't speak to its effectiveness.

In any case, simply using plain CoffeeScript + async + underscore, will greatly cut down on node.js's complexity. Sure, you still have some async callbacks when doing I/O like calling some service, but it's much less awful.

(I haven't yet evaluated ClojureScript.)

ak217• 14 years ago

Node.js actually has two problems that I think will be very major issues for it in the long run:

- it's based on JavaScript, which is a crappy language (despite how nice V8 is)

- (OP's point) the async style is horrible for readability, which puts a tremendous toll on productivity (though many will deny it).

There are libraries like async (https://github.com/caolan/async) and streamline (https://github.com/Sage/streamlinejs) which try to eliminate #2. They are band-aids: the language itself must support asynchronous execution without callbacks.

Node has many advantages that make it really nice - V8 is awesome because of an interesting case of technological path dependence; the standard library has a lot of modules that take great advantage of asynchronous I/O; the standard library is very high quality; the community is great - but I think the two issues above really leave room for another project to take the good parts and not the bad ones, and steal Node's thunder. It could be Go or Python (with some badly needed extra work on coroutines, concurrency, performance/adoption of pypy, etc), or something new.

jseban2• 14 years ago

Isn't client side Javascript programming also async event-driven in the exact same way as node?

Why isn't anybody whining about how terrible this is when writing client side Javascript?

Wilya• 14 years ago

Because when writing client side js, you don't have a choice.

On the server, you can do whatever you want, and you're free to choose something better.

jseban2• 14 years ago

Yeah but I've seen several people who tries node dismiss it on the grounds that this programming style is immensly complex and incomprehensible. In this guys words "The async-style of programming is almost entirely inaccessible to my brain".

I just find it contradicting then that every man and his dog seems to be able to whip up some client side Javascript which works in the same way..

chc2• 14 years ago

Japanese is a terrible language. I tried speaking it for a while, but I can just get my ideas across so much more easily in English. It's just easier. This must be because Japanese is terrible.

That seems to be the basic reasoning at work here.

hasenj14• 14 years ago

No, that's not the basic reasoning here.

And btw, I actually love the Japanese language, I find it more poetic and actually more expressive too, because you can nest expressions more easily than in English or even Arabic (my native language).

a_bonobo• 14 years ago

I second this - only two irregular verbs? Japanese is so nice (but sometimes too context-dependent)

chc2• 14 years ago

> No, that's not the basic reasoning here.

Then I don't know what was, because your point certainly seemed to be that you used Node and had a harder time reading and writing code with it than an environment that was more familiar to you, and therefore Node is terrible.

luriel6• 14 years ago

Node.js is one of the worst things to happen to the software industry in recent times, a whole generation of programmers are being taught the worst of all ways of doing concurrency, in a system that doesn't scale either in performance or project size and with one of the languages most plagued by pitfalls ever created.

JavaScript was already painful enough in the browser, why on earth anyone ever thought it was a good idea to use it on the server boggles the mind.

We will be paying the price of this misguided hyped fad for decades to come.

Of all the ways of doing concurrency, callbacks are by far the worst, Twisted was plagued by them and is the main reason why it failed, and that was with a much more sane and reasonable language like Python (stackless Python was a much better alternative and used a model similar to Go's CSP).

And the sad thing is that there are much better alternatives around with much more sound models and environments, Erlang and Go are the two obvious examples, and that is for the highly specialized situations where you have great concurrency needs, for any other problem anything else will be much better than Node.js, even PHP.

dmpk2k• 14 years ago

I think your definition of "worst" needs recalibration; the hyperboles really aren't improving the level of discourse.

ShirsenduK• 14 years ago

"JavaScript was already painful enough in the browser" only because its in a browser where standards are inexistent.

luriel6• 14 years ago

Yes, the lack of proper standards made it even worse, and yes, JavaScript has 'good parts', but JavaScript is still chockfull of wat: https://www.destroyallsoftware.com/talks/wat

Ygg23• 14 years ago

No JavaScript in all honesty was painful because the way it was designed (it was made in ten days). Equality operator ('==') is a cause of MAJOR headache and so is the global scoping, the bizzaro addition operator, etc.

See[1min 23s] https://www.destroyallsoftware.com/talks/wat

jahewson4• 14 years ago

> the worst of all ways of doing concurrency

That would be threads.

chrisbroadfoot• 14 years ago

You can't do concurrency with threads. I think you're confusing concurrency with parallelism.

jlouis2• 14 years ago

I agree that the Node.js model of concurrency is one of the weakest models out there. CPS is for the compiler writer, not for the programmer.

The underlying problem is that sequential languages do bad when you "bolt on" concurrency to them - unless said language is expressive enough to make it bearable (Haskell and some MLs come to mind). For all other language, you are just frankensteining your system.

The reactor-model, of which Twisted, Node.js and a couple of like systems are built around has one advantage: It is fairly easy to get going. It is by far the simplest model you can get bolted onto a system with relative ease. The crux of the problem is that we have a lot of sequentially oriented programmers who suddenly need to do full concurrency. This is the first attempt.

To a professional Erlang programmer like me, it does look rather odd that one would hail a reactor model as being anything decent to work with. There are other concurrent calculi out there, which may be better than what Erlang provides, but none of them worries about callbacks in the style of Node.

I have a hunch the kid must be dragged screaming into the concurrency shop.

hasenj14• 14 years ago

> The underlying problem is that sequential languages do bad when you "bolt on" concurrency to them - unless said language is expressive enough to make it bearable

Really?

I'm not familiar with Erlang, but have you tried Go? Concurrency fits seamlessly into the language.

dgudkov• 14 years ago

Offtop: Why clicking your link leads to downloading an application on Nexus7?

gothy• 14 years ago

Node is not for everybody. Node is not for everything.

2 hasenj: try using coffeescript to get expressiveness if you're coming from Python(like I do). You'll be much more comfortable with it. Especially when you're using it for both frontend and backend.

Node was a "why not?" choice for my last small inhouse realtime analytics. I could write it in python, but I've been writing LOTS of CoffeeScript recently so I've tried to go with node and redis. And it was a perfect fit for this task.

I'm pretty sure I wont use it for some complex business logic or number crunching. But that's not because I'm afraid to loose maintainability or peace of mind. It's because that would be just stupid, there is a lot of better tools for this. You should keep in mind whats your platform nature, whats it good for.

Every contending platform or language has it tradeoffs. I like ErlangVM features and philosophy, but I can't pass over the language weirdness. And VM speed sucks. And the community is much smaller. Nodejs is booming, you should agree on that.

Go is great, I'm planning to use it for my next "why not?" project. But it takes a lot of things you love in dynamic languages away. You choose between "program performance vs programmer performance". And again, the community and adoption is taking its first babysteps.

ricardobeat5• 14 years ago

Except that if you don't really know javascript, and hate cps, coffeescript won't make much of a difference.

protez• 14 years ago

Everything is terrible unless it fits. Period.

Tichy• 14 years ago

Funny, I think Python and JavaScript about even in the amount of syntactic sugar (programming shortcuts) they provide. They both have some little things that the other doesn't have, but overall there is nothing that makes me think python is preferable to JavaScript (except perhaps older and more mature libraries for server side code, don't know about that).

No comment on the callbacks - I suppose you don't have to use them if you don't want to.

olegp• 14 years ago

If you don't like callbacks, you can wait until generators become available or use the likes of fibers today.

I've implemented a number of synchronous CommonJS specs on top of Node using fibers (https://github.com/olegp/common-node), which allows me to use libraries written for RingoJS (e.g. https://github.com/olegp/stick) with Node.

All in all I'm very happy with the stack I've built - I get the performance and low memory usage of Node combined with the ease of development of RingoJS.

se852• 14 years ago

The entire post was an opinionated piece of crap based on the author's opinion that anything to do with callbacks are evil.

I couldn't help but see in the comments that the author states that avoiding callback hell in node.js is somehow different to using the same javascript design patterns in browser side javascript to avoid callback hell. What's the difference?

The author's problem is he doesn't understand JavaScript, so he never had a chance at properly understanding Node.Js and where it's strengths and weaknesses are let alone how to build something in such a way to ease developer pains associated with learning any new language.

arunoda• 14 years ago

People love NodeJS is because it's JavaScript and Async. If you don't like both you are not in the NodeJS boat.

But don't blame it. Everyone has their choices.

And NodeJS is not a general purpose stack and It never says it is like that.

When you need to do some nasty app with lot of IO and you don't need to learn erlang than NodeJs is for you.

Haters are always there! Who cares?

kehers• 14 years ago

"The async-style of programming is almost entirely inaccessible to my brain. Certainly not a fun way to write programs." does not equals to "a terrible platform"

captobvious• 14 years ago

Someone is making an effort to lower the threshold to my field of expertise, and make it available to a general public.

My livelihood depends on this!

We must divert our energies to repress and quell this enemy. Spread the fear, uncertainty and doubt!

// the node haters manifesto //

slajax• 14 years ago

People fear and inevitably hate what they can't understand especially when they fail to associate with it while others do so easily. OP should learn java script before learning "Node.JS".

aDemoUzer• 14 years ago

Python can do websocket: http://twistedmatrix.com/trac/export/29073/branches/websocke...

I too was interested in Node.js but I don't like the idea of using JavaScript - I simply prefer python for coding. I looked into it, found the counterpart of node.js in python and am happy with it.

Why I think Node.JS is a terrible platform

Related Stories