Why I think Node.JS is a terrible platform
dev.hasenj.org
dev.hasenj.org
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.
Try it yourself: var a = [] + {}; var b = {} + [];
Miraculously they are same (but only because the list is empty, string concat order matters obviously)! The only time that wat can ever happen is a case that would never exist in any actual code. The Dom is full of wat but I still havent seen any legitimate cases in js itself.
See[1min 23s] https://www.destroyallsoftware.com/talks/wat
And yes, developing under node is not the same as developing for the browser where you need to use the lowest common denominator, which usually is IE6.
I'd say that the issue is the "omg node.js" crowd that promoted it as the hammer for every issues that may pop out. It isn't. But this doesn't mean that it is completely useless.
> I don't claim that the behavior is intuitive, or appropriate for some cases. But the lack of RTFM isn't excusable either.
You failed the read test. Twice. The first was the manual itself.
> please explain how is this issue somehow elevated by node when it is a part of language standard
You failed the read test. For the third time. Please indicate the part where I claim that node elevates the issue vs. standard ECMAScript behavior. I said something about the node vs browser runtimes. This is a totally different beast.
> This is a gotcha of a language. It uses + operator that does something completely differently than what it usually does on almost any other language with similar syntax. It's the definition of counter-intuitive.
The only gotcha is the coercion that some regard as dark magic vs statically typed languages vs the operators themselves. The "+" and "-" operators in JavaScript: "+" for summing Numbers or String concatenation, "-" for subtracting a Number from another Number (which basically makes it a strict arithmetic operator, you know, stuff for Numbers).
Besides:
- PHP uses the + and - as strictly arithmetic operators (it has the . operator for string concatenation), while summing up two strings equals int(0) since (int) 'foo' === 0: http://php.net/manual/en/language.operators.arithmetic.php
- C (and to some extent C++) uses the + and - as strictly arithmetic operators: invalid operands to binary + (have ‘char ’ and ‘char ’)
- Java uses the + the same way as JavaScript: http://docs.oracle.com/javase/tutorial/java/nutsandbolts/ops...
What other language with "similar syntax"? D?
It is said that API is UX for programmers. Well this is UX for a computer language. And JS fails at it. Big time. And this isn't the only stumbling rock (see global variables, == operator, semi-colon insertion, etc.).
My point was that developing under Node.js is same as developing under a browser only the lowest common denominator changes to V8.
Edit: I'm pretty sure + operator in Ruby concatenates two arrays.
Couldn't agree more. But that's the standard. At some point I hoped that the ES5 'use strict' would fix all of this SNAFU, but it didn't.
However, not even once I tried to sum [] + [] or {} + {} till that "wat" video. Funny, but unrealistic, therefore: close, but no cigar. One could operate the "World's safest table saw", but the common sense tells us that usually finger vs. saw => saw wins. Safer tools are desirable, but it's up to the craftsman to use them properly.
> the lowest common denominator changes to V8
V8 is pretty much on par with its competition with the ES5 adoption, therefore we can hardly talk about a lowest common denominator that's actually low. The only thing that I actually missed in V8 vs. the Mozilla engines is the support for E4X (which most runtimes don't support anyway).
http://kangax.github.com/es5-compat-table/ - even if IE6 and IE7 are gone from the traffic stats, IE8 is there to stay with the XP users. Some of us still don't have the possibility to just drop those users as long as the analytic data shows a fair share of legacy users.
Ruby isn't part of the "similar syntax" family. The '==' operator isn't recommended in JS (and PHP). In fact, jslint yells at you if you use it. That's why '===' exists. The semi-colon insertion is one of the big failures on the "allowed" part. Wish that never happened. But any developer that doesn't try to adhere to some hipster JavaScript coding style uses the semi-colon at the end of the statement.
That would be threads.
From wikipedia:
>In computer science, concurrency is a property of systems in which several computations are executing simultaneously, and potentially interacting with each other. The computations may be executing on multiple cores in the same chip, preemptively time-shared threads on the same processor, or executed on physically separated processors. A number of mathematical models have been developed for general concurrent computation including Petri nets, process calculi, the Parallel Random Access Machine model, the Actor model and the Reo Coordination Language.
You can certainly build the actor model on the backs of threads.
Why not? A thread allows for two parts of the program to be running concurrently. Whether or not they run in parallel is orthogonal. Why don't you think they allow for concurrency?
A few citations to back myself up:
Concurrent Haskell is all about adding threads to Haskell: http://www.haskell.org/ghc/docs/latest/html/libraries/base/C....
The Java tutorials on concurrency all use threads: http://docs.oracle.com/javase/tutorial/essential/concurrency....
The Scheme manual uses threads for concurrency: http://sisc-scheme.org/manual/html/ch06.html.
The Oz language also uses threads for concurrency: http://www.mozart-oz.org/home/doc/tutorial/node8.html.
So who's wrong here? The world leading academics behind Haskell, Scheme and Oz? The industrialists and pragmatists behind Java? Or little old you?
The reality is that threads were created only to allow for concurrency. They were then re-used to allow for parallelism when we had multi-processors and then multi-cores.
Edit: does this guy work at Google? Unbelieveable.
Parallelism is just a new buzz word for people who have just discovered that threads\processes exist and they can have multiple things running at the same time. They just removed the shared state cause they don't want to have to deal with the headaches of concurrent programming.
Parallelism is simultaneity. Parallelism can be deterministic.
Concurrency is by definition, non-determinism. Concurrency does not, by any means, necessitate or mean simultaneity.
And I quote, "In computer science, unbounded nondeterminism or unbounded indeterminacy is a property of concurrency by which the amount of delay in servicing a request can become unbounded as a result of arbitration of contention for shared resources while still guaranteeing that the request will eventually be serviced. Unbounded nondeterminism became an important issue in the development of the denotational semantics of concurrency, and later became part of research into the theoretical concept of hypercomputation."
If you haven't even read the wiki page, what have you read about concurrency exactly? Are you just making it up as you go along? Is confabulation about topics subject to factual review a habit for you?
Unfortunately can does not mean always will. For example, lock-free algorithms do not have any contention, ergo we can have concurrency without running into unbounded non-determinism. Please try to actually understand what you're talking about before being so rude to people. Copying and pasting the first thing you find on Google is no substitute for learning and careful research.
For that matter, what little of deterministic concurrency exists (FP interleaving, coroutines), it is only the palest imitation of true concurrency and how it gets used in practice for which one can SAFELY assume that useful and meaningful concurrency DOES IN FACT constitute non-determinism which also happens to be an apt way to summarize and contrast the subject with parallelism.
The best way to demonstrate deterministic concurrency would probably be: http://en.wikipedia.org/wiki/Very_long_instruction_word
But for the purposes of anybody on here, that's mostly irrelevant.
> Concurrency is by definition, non-determinism.
The fact is that you are wrong: coroutines are a form of deterministic concurrency. They're also very useful.
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.
Really?
I'm not familiar with Erlang, but have you tried Go? Concurrency fits seamlessly into the language.
Perhaps you are confusing my definition of "sequential" with yours. I tend to use "sequential" as the opposite of "concurrent" like I have another, orthogonal, axis for "serial"/"parallel". So you can be serial/concurrent (Node.js is close to this. So is a 4.4BSD OS without any SMP support). And you can be sequential/parallel (GPUs is my preferred example).
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.
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.
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)
You are never 'finished' writing, code requires almost perpetual maintenance and improvement. (Unless the project is a total failure or you are DJB.)
I'm sorry, but if you are only good in JS, or PHP, the very first thing you should do is become good with some better tools.
Yes, it is possible to write working code in any language and platform, but languages and platform still matter and have a cost you will pay during the lifetime of your application, in security, reliability, scalability and maintainability.
> I'm sorry, but if you are only good in JS, or PHP, the very first thing you should do is become good with some better tools.
And I don't know what the hell is wrong with you, that you assume that you are the wisest of all men and know what is wrong with everything and what to use in any situation and what I know and what I do and what I should do...
> and have a cost you will pay during the lifetime of your application, in security, reliability, scalability and maintainability.
So thanks for this lesson. I swear I will spread the word, but before I will go and worship JS/PHP, as the little, stupid fanboy I am. (fyi that's called the language of sarcasm)
As I said: Don't go around and "insult" programming languages, because most of them have their right to exist and nobody forces you to use something you don't like, nor anybody else. Most programmer choose to use node.js and if they fail it's not necessarily the fault of the "tool" (though it can be), but also the fault of the programmer in question, by choosing a "tool" which didn't fit. I mean: You wouldn't try to put a screw in the wall with a hammer. Am I right?
Unless you're talking about getting a working prototype up-and-running, I could not disagree with this more. Classic "all I have is a hammer so everything looks like a nail" sentiment. Make your tool choice based on the problem you're solving.
- 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.
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.
http://alexott.net/en/fp/books/#sec7
and tuts
The online version is free, but I bought the book. It's worth it.
>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.
Technologies don't become popular on technical merits alone. Haskell fails at psychology.
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!
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.
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.
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++.
Actually, it's more like, "Write your web apps in Python/Clojure/Go/Java/Scala/Haskell/Erlang/C++/C/Common Lisp/Racket which all have better concurrency and async mechanisms than Node.js"
I was mentioning SFS/sfslite more as exemplars of clean ways to abstract asynchronicity than recommending C++ for web app development.
But you don't learn something like that if you don't learn to code without jQuery and npm packages.
"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.
- 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.
The loss does not come from JS or coffeescript, it comes from everything being done with callback (whether nested or not).
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.)
- 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.
* 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.
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.
Quote of the year!
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?
That seems to be the basic reasoning at work 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).
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.
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.
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?
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
...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.
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.
And I was trying to figure out where the code was coming from in passport. The only tool for that was "grep emit". That's ridiculous.
The problem went a level deeper, but that's irrelevant to the task at hand -- I was overriding the prototype (as per the passport example) and yet my code wasn't being called, and there was some order of execution issue going on with how the initialization was interacting with express, which is when I decided to scrap the code and rethink the implementation.
And for multiple reasons, I'm rethinking that implementation in Scala instead. :)
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.
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
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.
Stretching my head around everything-is-async was not rewarding. Just because it's different, doesn't mean it's good.
[1]: http://community.schemewiki.org/?call-with-current-continuat...
But I still feel really conflicted about Javascript.
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?
It was hyped here in HN, a community which should (in theory) have a very strong BS filter. So it's very natural that most people here would think that this hype is perfectly reasonable.
If it was hyped by some corporate giant like Oracle or Microsoft, I would probably scorn at it from the start.
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.
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.
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.
If node.js works for you, then I'd argue that Go would work even better for you.
If you don't mind losing some of the expressiveness of python/ruby, then surely you wouldn't mind transitioning from python/ruby to Go. And, what's more, Go is much better suited for large and complex programs than Node.js.
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.
There is simply no justification to use Node.js for anything.
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.
That's like saying "assembly isn't going away, because it's the language of the CPU". Of course assembly isn't going away, but other than the Kernel and device drivers, there's not much reason to use it else where.
Coroutines are a much better way to write performant network services. In Go, when a goroutine blocks on I/O, it yields execution to other goroutines. You, the programmer, never think about it, because the platform handles it for you.
Assembly largely has gone away. It used to be that all serious PC apps were written in asm. Eventually though, C compilers and RAM improved enough to not require that. Today the only things written in asm tend to the absolute lowest-level system routines and a few hand-tuned loops.
But you might also be interested to know that MS embeds the web server in the kernel using async IO (http.sys) and that the WinHTTP client library runs async as well.
Coroutines are a much better way to write performant network services.
I agree native coroutines or CPS would better. There are better choices of development language than Javascript, too.
But it's not the tool, it's the hand and the attitude that wields the tool that determines the quality of the result.
Not only that but, unlike Node.js, Go (and Erlang) actually do scale to multiple CPUs and don't make your whole app crawl to a halt if you got some bit of code somewhere that is CPU bound.
This fantasy that Node.js supposedly scales because it is async is so laughable I don't understand how anyone ever took it seriously.
I just made it go away -- started using gevent. You can make it go away also by using an actor based language like Erlang.
If we were in the 90s you'd probably would have said C++ is not going away so that's what all web services should be written in.
> thread context switches are expensive.
Green thread context switches are pretty cheap and Erlang's processes are very light weight. I was running with 100K processes at one point all with long polling (comet style) connections. That's very cheap.
> It just is what it is: inevitable.
Yap but that wasn't his argument. I don't see (even in general) how inevitability of something turns that something into a good thing.
Actually, I work on some C++ web services today (but I wouldn't advise everyone do that :-)
Erlang's processes are very light weight
Yeah, Erlang is great that way.
I don't see (even in general) how inevitability of something turns that something into a good thing.
In this case it's inevitable precisely because there are application domains where the use of V8 Javascript is a big advantage (say you want to leverage the same code base on the client side). There are other domains where the use of the single-thread async model is a big win, particularly when a runtime environment can support you by eliminating inadvertently-blocking calls. These domains were overlapping for some capable implementers, so I think Node.js was inevitable for that reason.
That doesn't mean it's a terrible system if it doesn't turn out to be a great replacement for your favorite PHP framework.
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.
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.
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.
-> is much shorter.
Even when they don't, it's easy to find. There are both websocket and socket.io implementations available for gevent for instance.
Why isn't anybody whining about how terrible this is when writing client side Javascript?
On the server, you can do whatever you want, and you're free to choose something better.
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..
No comment on the callbacks - I suppose you don't have to use them if you don't want to.
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?
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.
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)
Javascript performance has come a long way since the days of IE6.
Saying that node.js is more difficult to work with than Python is just a matter of perspective isn't it?
Like any technology, in the hands of individuals that know what they are doing it is really not any more difficult than anything else.
For me personally, the fragmented Python community was what scared me to Node.Js in the first place. This was year's ago now, so perhaps Python has gotten better at that, but from a getting started point of view Node.js was and still is pretty easy, at the time the only thing that compared in Python in terms of ease of use was CherryPy, but It was not stable enough at the time for me to feel comfortable staying with Python for the one library that was not production ready.
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.
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.
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.
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 //