1. 10

  2. 24

    Sorry, but this is a terribly bad post.

    At the beginning, it dismissively links to this post by Ryan Dahl: https://web.archive.org/web/20120124211502/https://plus.google.com/115094562986465477143/posts/Di6RwCNKCrf, which does address a lot of interesting things and has its fair share of criticism to Node, too.

    Then, it goes into a long rant on how these people don’t understand blocking, because long computations without cooperatively yielding block. Who knew? The NodeJS developers definitely did!

    I spent 2 conferences with Ryan, discussing the ebb webserver, an evented web server in Ruby. What he wanted was a programming environment that would run fully evented, fully cooperative, but came with batteries included and with the ease of scripting. His biggest problem was that almost all standard IO in Ruby blocks and that wasn’t working at some points. So, to move people over to ebb proper, he would have had to move a whole ecosystem. So, how to fix that problem short of designing a new programming language? Find a language that doesn’t have a standard notion of IO. There’s almost only one practical language that ever did this: JavaScript.

    And yes, the NodeJS developers know the model they built by heart, a thing this article absolutely doesn’t appreciate. The takeaway is: NodeJS is bad for writing Fibonacci servers. Thanks.

    The icing on the cake is the offhand dismissal of “Well, it’s JavaScript” and the usage of “Cancer” to describe something you don’t like.

    You might not like NodeJS, and NodeJS has its fair share problems, but from an engineering perspective, it was a genius move towards its stated goal. The subtle air in this post that the NodeJS people don’t know what they are doing is so far from reality…

    1. 7

      I can’t even tell which point the author misses more: Node, Node’s purpose or how evented servers work.

      Node has (and don’t laugh, I am not making this shit up) its own HTTP server, and that’s what you’re supposed use to serve production traffic. Yeah, that example above when I called http.createServer(), that’s the preferred setup.

      I don’t know where the author got that idea, but that was false in 2011 and it sure is false now. I would have a hard time finding a language/runtime that doesn’t include an HTTP server in the standard library. Everything’s cancer, I suppose.

      Additionally, sorry for being off-topic, but I just joined this community a few days ago after years of HN and boy is it refreshing to read the comments section over here. I’m definitely sticking around. Thanks for the thoughtful comment.

      1. 2

        omg that quote is just so ridiculous. Like… how else would you serve traffic? CGI? FastCGI? A mod_php style “solution”? Does anyone remember Mongrel2? :D

      2. 3

        If you have the chance to define a platform like Node, though, why not do I/O well, instead of saying, “well, callbacks?” The whole thing feels very incrementalist.

        1. 3

          I remember a talk Ryan Dahl gave in the early days of Node. When someone asked about callback hell (although I don’t think the term existed at the time), his answer was something like “well… you don’t have to use anonymous functions: you can also use global named ones, I guess?”. It sort of looked like it was the first time that thing had crossed his mind.

          I suppose that’s a limitation of taking advantage of the V8 runtime, though. There was very little that could be done

          1. 4

            IIRC, Ryan Dahl was going to do this better via promises, but then ripped it out to be standard JS.

          2. 3

            Sure, but that is much better criticism in 2 lines then the whole blog post. I could actually interact with it and put weights to what you say…

        2. 10

          Aside from being poorly written, this article tries to skewer event loops with the argument that CPU work will block your thread and prevent you from achieving high throughput. This doesn’t have to do with blocking vs non-blocking. Your CPU resources will be consumed regardless of the approach you take. The actual difference in throughput here is how many cores you can consume. Presumably if you were actually trying to achieve high throughput in production with node, you would have several node processes per machine and load balance your work across the different processes.

          I’m not a huge proponent of node, but this article is not good.

          1. 6

            This is a terrible article, and on top of that, can we all just agree that articles with obvious troll titles containing words like “dead” “cancer” and “evil” are probably not worth posting to begin with?

            1. 2

              while I agree that this particular article is deeply lacking, the title resonates with my professional sentiment about the node ecosystem. there is nothing wrong with calling out problematic patterns in the tech world via strong metaphor if they can be properly supported.

            2. 3

              This is more interesting to me as a distilled sample of a kind of trolling than for any technical content.

              1. 1

                But: wouldn’t a more thoughtful piece on the metastasization of software platforms be really interesting? I’ve often thought of this headline in the years since it came out but always forget what the article has to say itself. It seems like another line of inquiry, though still contentious, may have more to say.

                For instance, some languages/frameworks gather more small, hard-to-keep-up dependencies than others.

                And, I’m obliged to agree with an old colleague, that maintaining an event-driven application gets much harder as the team grows, compared to one where the runtime schedules threads/coroutines/etc. for you.

                1. [Comment removed by author]

                  Stories with similar links:

                  1. Node.js is Cancer (2011) via raymii 1 year ago | -1 points | 8 comments