Oh, please, not that Paypal story again. Their legacy system was written on platform/language X, then Z years later, they have written another in language Y, and surprisingly, Y is faster! For Z>=5, this is going to be true for most of X-Y pairs because people learn from their mistakes, people know more about the requirements and pitfalls of their domain after having built the first version, etc. etc.

Other than that, the article contains zero interesting information. Somebody had an uninformed opinion of Node.js, then changed that opinion because he heard some good stories, and now he convinces himself with funny arguments that he's right.

(I had too many upvotes recently anyway :) ).

Let me try to give a different perspective on NodeJS:

We've been building tools to work with Excel files. The hardest problems aren't related to writing code. It's all about finding files that use different combinations of Excel features from different versions of Excel (and files from external tools that read/write files). For example, if you start from Excel 2011/2013, you wouldn't know about the custom smart tags that were removed in Excel 2010. However, those records are still persisted (e.g. BrtWbFactoid in XLSB), so you would need to produce a file from Excel 2007 to actually reproduce the error.

For other people to discover errors in python or java libraries, they have to try it in some capacity. That either involves installing something foreign (which may be prohibited or undesirable) or submitting data to a third party (which is most likely forbidden).

A pure-JS in-browser solution can address both problems effectively. We have a cool little web demo which parses excel files in the web browser: http://oss.sheetjs.com/ No installation required. Files are processed in the web browser (HTML5). We've received reports from many organizations involving confidential data. Over time, we've built other tools to inspect features of files without requiring that people send us the original file, and this allowed us to test bugfixes without having to share files.

Now for the really cool part: NodeJS exposes some features like Buffers that make data processing competitive with python or other scripting languages. But since it uses the same code for parsing, fixes to the web version immediately benefit the NodeJS version. As a result, our server-side code (http://npm.im/xlsx and http://npm.im/xlsjs) benefits from the performance of V8 and from the exposure that a browser-based solution enables.

That is a pretty powerful example - things like data importing are things that I often end up needing to queue to process in the background. Offloading the heavy parts to the client is a really awesome alternate solution. I'll be saving this for the future for sure. Thank you!

Paypal developed the Node and Java code in parallel.

"Our first adopter of node.js in production wasn’t a minor application; it was our account overview page and one of the most trafficked apps on the website. We decided to go big, but we also mitigated that risk by building the equivalent Java application in parallel." -- https://www.paypal-engineering.com/2013/11/22/node-js-at-pay...

So, in this case Node wasn't being compared to a legacy system.

It was not ONLY the good stories, but the combination of things I listed. I work in the enterprise world, and the languages my company most often uses are Java and C#. I've been trying to push Python, but it has been difficult. Node has a lot of selling points which allow me to convince both management and other developers.

I'm nearing the end of my first large Node.js project. I may do a retrospective after, but TL;DR - it hasn't disappointed :)

What exactly is wrong with Java and C#? You can do amazing things with both. I'm a Python guy, and I constantly dislike the lack of static typing for back-end things in JS/Python.

I work with JS every day but used to work in C#, and I still miss it. But unless you're working on MS platforms it's just a huge pain to get it to work.

Which is why Golang has exploded recently: it gives you static typing security of Java with a coding workflow of an interpreted language.

What I personally find wrong with Java is the extreme verbosity of the language, the verbosity of maven (it's the only build system I've used for Java), the extreme memory consumption for little benefits and generally the Architect Astronaut mentality that is so easily associated with Java.

[0] http://www.joelonsoftware.com/articles/fog0000000018.html

> Which is why Golang has exploded recently: it gives you static typing security of Java with a coding workflow of an interpreted language.

Sure, it has similar static typing to Java, but it also has the same coding workflow as any other compiled environment, not the workflow of an interpreted environment.

I believe parent comment was probably alluding to compilation time. My experience with Go is that the compile times are usually close to zero seconds and this indeed makes it feel almost exactly like working with Python or JavaScript.

Parent may also have been thinking of Go's concision, which feels more like using a scripting language than using a class-based monstrosity like Java, and certain other features, such as type inference that make variable declaration as painless as weakly typed languages.

As far as verbose vs. concise (including the impact of type inference), I don't see Go as being much like a dynamically typed language. Sure, it is a bit lighter than Java, but for nontrivial code you still end up with plenty of type system related cruft -- a lot more than in Haskell, which is on of the few static languages which is anywhere close to dynamic languages in terms of being concise and having little of the empty type-related ritual that plagues most other static-typed languages.

Yes and yes, exactly.

I don't prefer the verbosity of Java; I do like C# pretty well - it certainly has its place, but Node.js also has its place. My current project is a proxy between a modern web app and a legacy Java system; Node.js was a much better choice than either C# or Java for this use case.

I'd be interested in an elaboration on why Node was a better choice than C# or Java. I don't mean that snarkily; I'm really interested. I work mostly in C# and actually feel pretty happy with it as a language (I've used Ruby and Java in other major projects, used to do a lot of my side hacking in Clojure, and I'm learning Haskell now). It's one of the more solid languages I feel that I've used, especially combined with LINQ and some other tools.

Also was wondering if you had heard of SignalR in .NET, and if you had, what your thoughts on it are? I don't know a ton about it. I've heard good things from other C# dev friends, but it seems to be aimed squarely at the real-time/near-real-time web arena

How would you compare working in C# (with async / Rx) to Node in terms of non-blocking design?

ASP.NET vNext should be compared to Node.js. In the end of the day Node.js is simply an implementation of the Reactor Pattern leveraging a third-party JIT and HTTP infrastructure + some package management. There is nothing magic about it.

I'm interested in this and how SignalR would fit into the picture.

I have a few projects at work I think I can squeeze SignalR, which should be interesting. I've heard good things from a few devs that I know of that have used it.

It's quite good we use it for notifications with ASP.NET. But consider Akka .NET port as well if it fits your tasks.

tl;dr

    Other people are using it.
    It's less verbose than Java.
    It has a package manager and libraries.
    It has a REPL.
    I stopped worrying and learned to love callback hell.
    I didn't have to learn another language.

tl;dr

    I like reading.

The author's experience are pretty typical for most newcomers to node (I help run a large JS meetup, so get to meet a lot of them). But I think what many people miss is that the functional programming and dynamic typing aspects of JS (two of the most maligned aspects) turn out to be surprisingly effective, often resulting in simpler, more concise code. Its a different mind-set from the statically typed OO paradigm, and the learning curve isn't exactly easy, but getting comfortable with functional programming and continuation passing style in general is a great skill for any programmer to have.

Do you have any easy-to-grok real world examples/libraries you would recommend? Genuinely curious and want to learn more. The JS code I end up writing is always in a more traditional object-oriented style but I'm usually not entirely satisfied with the end results.

Might also recommend Functional Javascript by Michael Fogus. He uses underscore.js, and avoids re-implementing classic functional patterns (map, reduce, filter, etc).

I understood a lot of functional concepts from Lisp before reading the book. There might be something else you need first if you've had no exposure to FP, But if your basic FP-fu is good, this is a really nice book to read.

Lo-dash is a good place to start: http://lodash.com/

The things that made Node.js big are npm, the community, and the fresh new frameworks - a story similar to Ruby on Rails. But I have to fess up that I miss C# and Java as their verbosity is actually an investment, not wasted time. I'm really excited about Ceylon although it seems very slow pacing - doesn't even support Java 8 yet. I've recently done some stuff in Groovy (self-contained single-file utilities that download their dependencies from Maven with no build process and dealing with binaries although Capsule seems to be solving this perfectly nowadays). Anyway, one has to consider Dart as well as it can spit out JavaScript for the client and still write everything in one (saner) language. I really don't see myself doing a relatively large project in Node.js.

The thing that changed my mind about Node (and Javascript in general) was the discovery of lo-dash and Immutable.

I really enjoy functional programming, and with those two libraries I feel like I'm writing in something approaching Clojure (but with less ceremony, faster startup times, a truly colossal user community/ecosystem, and less memory bloat). I never thought I'd say this about Javascript, but it clicks off more items on my dream-language list than anything else I've used (and I've used at least a dozen, across several paradigms).

It's honestly fun to write in JS these days (at least for me).

Heck yeah, be sure to also check out:

  - https://github.com/puffnfresh/bilby.js
  - https://github.com/fantasyland/fantasy-land
  - https://github.com/baconjs/bacon.js
  - https://github.com/kriskowal/frb
  - https://github.com/swannodette/mori
  - And essentially all things PureScript: https://github.com/purescript/purescript

PureScript was something I've never heard of. Took me a few clicks to see some code though: http://docs.purescript.org/en/latest/intro.html

The language looks good and it seems to be somewhat popular with more than 700 stars on GitHub. Thanks for the suggestion!

It's an absolute dream come true for Haskell-ers. Doing server-side in Haskell and client-side/small services in PureScript is... just wow. Anyone in the Colorado area, we have quite a few amazing FP folks here (e.g. Brian McKenna) and there is a PureScript meetup Oct 1st: http://www.meetup.com/Boulder-Haskell-Programmers/events/199...

Wow, thanks. I didn't know about fantasy-land and bilby. Hard core.

That stuff is definitely getting you pretty close to Clojure.

+1 for mori. Lovely Clojure goodness :)

Would you mind copy-pasting some example code? Ideally something similar to what you'd write in Clojure and solves some real-world problem? (The more code you can paste, the better.) I'm quite curious to see whether the claim is true about being able to write something approaching Clojure while solving real-world problems.

Okay: http://pastebin.com/r40TN3Ni

This is a small command-line program that I use to compute grades (I have larger stuff, of course, but this one is easy to follow).

There are important differences between Clojure and Javascript (cum lo-dash and Immutable). Perhaps the most important overall difference is that Javascript is never mandating immutability -- you have to watch carefully (and I'm probably screwing it up a few times in that code). In fact, I just noticed a bad example of mutating state when I pasted it. :( I also use imperative constructs from time to time, but I like that I can.

I originally wrote this code using JS's object system. I absolutely hated it (and I do understand prototypal inheritance quite well).

What's more important to me, is that actually writing the code feels "lispy." In that code, you'll see all the classics (especially as you move down): each, map, range, zip, and compose (my favorite). Lo-dash, of course, has many, many more.

Agreed. We have both clojure and node services in production here and the use cases for each technology is quite different.

The big Clojure use-case for me has been Java interop. Aside from that, I'm not sure I'd prefer it to node.

Of course, I have no idea what your use-cases look like . . .

I didn't mention that, but I totally agree. Maybe it's because of the lack of good OO support, but people don't freak out when you do functional programming in javascript.

For me it was the discovery of LiveScript.

You should look into it.

I think the author is in the "honeymoon" period.

Yeah, a repl, a package manager, and third party libraries are pretty standard for many languages. Even Lua has them. Non-blocking is nice, but the last one, I agree more on "the disadvantage is Javascript" than "but you only need to know one language!" I'm not a Javascript fan, speaking as someone who recently had to start developing in Javascript. I think it's a damn shame that this is the language that everyone picked to create the Web with.

Just an observation about these statistics: * Built almost twice as fast with fewer people * Written in 33% fewer lines of code * Constructed with 40% fewer files

When you choose a brand new language, the people doing the coding are ones willing to learn / try new things. This means you won't have dinosaurs working on your project.

Correlation vs Causation, yes.

I think people are herd animals. So when a few developers are using some new tool, they are off by themselves away from the herd and considered idiots or something. Then more and more start using that tool, and pretty soon the whole herd, or all of the cattle around you, are doing that, and then you change your mind.

I like using Node.js with ToffeeScript (which is a variant of CoffeeScript). I liked Node before most people realized how cool it was. I am also sort of into bash these days.

Down the line I would like to get into things like LiveScript and Nimrod.

And then down the line I would like to move on to some kind of system based on description logics that makes it convenient to integrate systems because programming languages and data can be translated to and from a common (DL-based) language that can be reasoned on.

If you replace language names with band names, this sounds just like an insufferable hipster riding a fixie in his skinny jeans talking about how he liked Node before it was cool.

That's the joke? Or were you serious?

Maybe I should have left out the part about liking Node before it was popular. The point was to try to give the idea that I had picked up on a trend before some other people. The reason I want to get credit for that is because I want people to use those other technologies that I like, so maybe someone reading that will think that I can select technologies that, if nothing else, might become popular in the future, and therefore decide to use the technologies I mentioned.

Also, I hate hipsters and have no friends and am about the farthest from a hipster you could ever be, BUT I _did_ have a "fixie" when I was a kid 30 years ago. That was because we were lower-middle class and my parents were cheap though.

Also, I did finally purchase a pair of skinny jeans on the direct advice of a lady friend last year. Despite having put on at least six pounds, they still just about fit. Pretty amazing actually. It is a little embarrassing wearing them outside, but if I am honest, they are my favorite jeans.

LOL.

What changed my mind about node.js was when I ran a demo program as a daemon and then forgot about it for months. And it never broke.

Despite the program being very poorly constructed (by myself, of course), it was still running reliably on the machine much much later. It's a simple websocket (faye/bayeux) demo that allows multiple users to edit a grid concurrently.

Plain version: http://faye.pp19dd.com/ - works on iphones and such, and a HAL 9000 babylon.js version: http://faye.pp19dd.com/index2.php (Instructions: click on squares, use mouse wheel and such to move camera.)

At some point in putting the program together, I realized that I could write modules that could work on both the client and the server without any modifications. IE: client, server data structure. Maybe I'm rusty these days, but mind was partly blown.

Is there something special about node's REPL I'm missing? Just about every language has one. IPython is pretty snazzy.

Articles like these often imply how node is infiltrating the same space that JAVA takes up. Java to the best of my knowledge does not have a repl.

Nothing special about it, but a REPL is almost a must for me. Python hooked me on them. (And I love IPython - especially IPython Notebook).

I have the impression that he didn't realize that Node had it and was surprised it did, not that the other languages don't typically have it yet Node does

There was a load error when I first clicked the link, resulting in a blank page. Was thinking "well played, punk".

Ha :)

I’ll admit I’ve always passionately disliked Javascript. I also have a strong preference for statically typed languages over dynamic, but always thought Javascript was the most unlikeable of the lot. Perhaps it is that I initially learnt it by osmosis, trying to get things working under both Netscape and early Internet Explorer browsers at the same time. Worrying if I put my curly brace on the same line or the following line, or if I forgot a semi-colon at some obscure, critical location.

But I’ve always been hesitant of dynamic languages in general, preferring statically typed for any codebase of significant size. The last decade has been a bit discouraging for me in this regard. First everybody was loving Ruby, then seemed that Python has overtook it in attention. And then Node.js came along and I really felt like Bromden with a pillow, looking for a way to smother the insanity.

(As an aside, I do quite like Ruby as a language, and writing Coffeescript - the wonderful lipstick for the pig that is javascript - has given me an appreciation for the indentation feature a’la Python.)

The number one problem to my mind with using dynamic languages for a large codebase is maintainability. Refactoring a compiled, statically typed language is so much easier. There is so many potential errors that the act of compiling and type checking eliminate for you that you don’t get with dynamic languages. The focus on huge amounts of unit tests always seemed like compensation for this. And refactoring code is so much easier. Add another parameter to a function, try and compile and you find all the places in the code you need to fix. Maintaining a sizeable amount of code, or code you haven’t looked at for a while is so much easier.

And I get the feeling the pendulum of opinion is starting to swing back in my direction. Running stuff in a web-browser is now a serious concern, and good hackers are working on ways to portably do good programming in anything but Javascript. From asm.js to Dart to PureScript and others.

Newer languages like Go and Rust are taking the nice features many have lauded in the last decade as the advantages of dynamic languages. Things like good package management, less boilerplate and such, and baking them into static languages. So my outlook is getting rosier.

Coming from an IIS, .NET, SQL Server background, the simplicity of full-stack javascript from mongo, to node, to angular cannot be overstated. Propagating a change from the front to the back end or vice versa is much easier and faster speaking the same language throughout.

Tools like yeoman, grunt, bower makes it that much more pleasant.

Libraries like expressjs, mongoose, passportjs, and many more can do a lot of the heavy lifting, taking away some of the pains of writing boilerplate.

All and all I'm a fan. I'd love to use angular against firebase only without a node server, but I can't justify the cost.

"JavaScript can be the native format of your data"

I don't think developers appreciate how amazing this feature is in a language.

Code should be a data-structure giving you all the benefits of data-structures including persistence.

Closer to homoiconicity, but not quite there.

Assuming you are talking about JSON, that isn't even close to homoiconicity. Even if it were, any JSON you send/receive over the wire still has to be encoded/decoded into JSON, taking you right back to square one just like with any other language consuming JSON.

Ya. Exactly. I like that term.

Not exactly at all. Homoiconicity is when your program can be represented as a data structure. Like, literally a data structure. JavaScript doesn't even come close to that.

I work in JS all the time, but was still a little skeptical of Node until I finally grasped the concept of Promises (the Bluebird library being my preference). It took the callback-driven, event loop system from a liability to a huge bonus - running operations in parallel is so simple now, and error handling is a breeze. Can't recommend it enough.

Now I'm spending my time writing view code that can run on both the server and client, allowing me to render the same stuff statically (for fast initial load and SEO) and dynamically on the client (for fast page changes).

The event loop argument is the least convincing one for me. Any other language with green-threads/coroutines/continuations/etc lets you write an event-loop system without needing to uglify your code with callbacks or promises.

Javascript is finally catching on to this with generators (yield statement) but it bugs me when people talk about callbacks as if they were a good thing.

Do you happen to have any example code? I've had some bad experiences with "callback hell," so it's interesting to see that there are ways to prevent it from becoming a problem.

One of my favourite parts of Bluebird is the 'Promisify' function. It allows you to take existing Node modules and use them as promises. Here's an example of interating over an array of files, only writing ones that don't already exist:

http://pastie.org/9559209

It's also one of the reasons that I've ended up liking CoffeeScript more - Promises have a lot of function() and return statements, CS makes that kind of code a lot cleaner. For instance, that JS could be this short in CS:

    Promise.filter files, (file) ->
        fs.existsAsync(file).then (doesExist) -> !doesExist
    .each (file) ->
        fs.writeFileAsync(file.filename,file.content)
    .then ->
        Promise.map files, (file) -> fs.readFileAsync(file,'UTF-8')
    .then (fileContents) ->
        console.log(fileContents);
        ###
        Will return:
        [
            "File 1 Content",
            "File 4 Content",
            "File 3 Content"
        ]
        ###
    .catch (err) ->
        # This will catch any and all errors that happened above.

For me, callback hell is a code smell - it means that I'm thinking imperatively and not, umm, eventedly. The general fix is to call something a component - give it a name and such, and have it fire some events that something else should listen to.

This article is literally counting the same reasons listed every time nodejs is mentioned, since it's inception.

Non-blocking, single-language, npm. What's new?

OK, but what's about Java's vert.x framework or some asynchronous web-container like undertow and CDI usage? Does that stuff are really so slow and painfull in compare with NodeJS? I don't think so.. I think that there is nothing bad with using "old" Java Enterprise Stack, as long as you are really sure what you are doing and you really know (not guess) what to use!

The biggest step forward for JS development is Meteor, hands down. For anything "appy", the productivity is just insanely good.

I wrote another comment explaining why I strongly disagree with you (and the Meteor thing) but after reading it I found it harsh and stuffed with negativity.

So yeah, I very much disagree with you, but hope I will be wrong and Meteor will be usable for more than a blog or prototype.

Just curious: I like Meteor but it does not seem appropriate for apps that need to have a huge number of concurrent users. The developer experience is sweet though.

What don't you like about Meteor?

curious, too. I spent the last months doing meteor exclusively, and compared to the usual node/RoR/php stuff on the server and angular/backbone/ember on the client, meteor is just superb IMO.

I'm trying to think of a single language of which this is not true. It's certainly not Java. That dude is drinking all your beer.

YANN (yet another node nut)

I wouldn't use Node for everything. I use Python more often, and also use some C#. I'd like to do more Clojure.

This is an idiotic thing to do.

- JS is difficult to maintain

- JS is difficult to statically analyze

- Callback hell is a stupid thing to voluntarily subject a team to

- JS is notoriously difficult to debug

- It's much harder to find "good" JS resources, but much easier to find "bad" or "mediocre" JS resources

Same goes for C and C++, pretty much exactly the same. Well, I have some bad news for you... :)

It's not because it's JS that we can fire the architect, SOLID principles (yes, they still are quite good practices), and abandon all sane project management.

Truth is, there's no silver bullet, it's always a trade-off, blah blah blah. In the end, I found it easier in JS than C to adapt the quality management of the project with it's criticity.

Yep, I have some slightly critic components which run in JS right now, and I'm OK with that.

Who cares about debugging, code correctness and maintenance when it's so "fun" to code in JS?

Am I the only one who is seriously tired of programming languages being compared to women?

I know you're probably well intentioned, but that and a number of other things in your post are pretty heavy on the stereotype side of things ("women = user friendly" and "put on a leash" are two other examples) and it's the kind of stuff that adds little bits of stress to my work day, which add up over time since there are plenty of guys who do stuff like that without really thinking or actively meaning harm.

You have some good points/language comparisons - could you phrase them in a way that doesn't create unnecessary implications?

The most attention grabbing part of your comment was when you quoted him as saying "women = user friendly" and "put on a leash". His actual comment contains "I'm old enough to marry and put on my leash", referring to himself.

I understand why you didn't like his comment, but that doesn't justify the misquote. That being said, if you couldn't read his comment well, I understand. His comment's hex color is almost matching the background.

The common trope when it comes to associating leashes and marriage is wives having their husbands on leashes (and googling bears this out). If you think that the statement in that post was actually meant to refer to something other than the common trope, I'd be curious why.

If you do think it refers to the common trope, I'm curious why you think "my" versus "a" makes a difference.

Regardless, the point of the quote marks in that parenthetical was to denote common tropes that appear in his comment, not to use his exact language. I'm sorry that their usage was confusing.

> If you think that the statement in that post was actually meant to refer to something other than the common trope, I'd be curious why

Nope, we're in agreement there.

> the point of the quote marks in that parenthetical was to denote common tropes that appear in his comment, not to use his exact language.

Exact language can be important, especially when quotes are being directly sequenced. In this case, sequencing two quotes with different subjects, while modifying the second quote to be more subject agnostic, is problematic.

> I'm sorry that their usage was confusing.

No worries, sounds like you didn't intentionally modify the quote to redefine the meaning at all.

I think he should have gone with "a leash" instead of "my leash". The latter sounds like one is looking for an animal to put on their leash.

"Note: This is just an humoristic comment, don't take it too seriously.."

I don't think you meant it in a mean way or serious way. The problem is that you are far from the first person to use these tired tropes, and it only takes so many "not too serious" comments before the pattern itself becomes the problem, not the individual comments.

Think of it like a speed bump - a single speed bump on your street isn't that big a thing, and isn't really a problem on its own. But if there was a speed bump every 5 feet along your street, that would get tiring fast - even though the basic concept of a speed bump isn't itself the problem, it's just the repetition that's the issue.

Despite the massive downvoting I will not delete the comment.

I have nothing to be shame of. I am not offending anyone. I am expressing an opinion (in a specific style) that I consider to add value and possibly help someone out there. It would certainly have helped me sometime ago when "adjusting" my career path and choosing a computer language to learn.

Don't take life so seriously that the world offends you.

This isn't about offense. It's about stress.

You're basically telling people to not be stressed out when they're biking and cars pass them too closely, because the car had a reason to be on the road. "The car needed to get to the hospital. You shouldn't get upset about being passed." The thing is, it doesn't matter if the car had a good reason to be going fast and passing in narrow sections of the road - it's still going to stress a bicyclist out to get passed closely, regardless of whether it was malicious, and regardless of whether there was a good reason for it.

> I am not offending anyone

I think that you are though. It might be a small bit of offence, but it all adds up: http://juliepagano.tumblr.com/post/46206589124/my-experience...

The analogy of "death by 1000 paper cuts" is really nice. The only problem is that "paper cuts" make part of everybody's life, you cannot avoid them. Anyway if you don't focus on them they will heal fast and make you stronger.

> (in a specific style)

Note that the style is what's irksome about the original comment, not the opinion. When you talk about the value of the opinion, and gloss over the style like this, I feel like you're failing to understand why people disliked your post.

I don't have to take something seriously to find it tiresome.

You're so far down a hole you don't even realize it.