A serious problem with Node was the callback pyramid of doom.<p>This means deeply nested callbacks such that the indentation wanders steeply to the right. When you do loops or have exceptions programming got very confusing. In effect you have to do a continuation passing transform. It's not difficult but the results are utterly unreadable. For example a simple for loop could be transformed into recursive function because this way it is easier to keep state between callbacks. It's a nightmare.<p>What I found surprising in the early years of Node that some people in the mailing list had a «Real programmers don't use Pascal» attitude.<p>Bruno Jouhier's developed streamline to simplify and automate the continuation passing transform. One could almost program in a «blocking» style. I found his work really amazing. However for that Bruno got attacked in the mailing list.<p>Then Marcel Laverdet developed fibers. A different and equivalent way to solve the callback pyramid are fibers, coroutines and generators. This way we don't need the continuation passing transform. But the reception in the mailing list was at best only lukewarm. Anyway, the developers of Meteor saw the potential and decided to base the server side of the platform on fibers.<p>And now JavaScript has generators and async/await. And lo and behold: with these official solutions the hard core programmers swayed and accepted «Pascal».<p>In my opinion, Ryan Dahl has missed an opportunity. Node was by large not ready and finished when he left. He should have tried to convince the community to find a solution for the callback hell.<p>I think I understand people like him. They are always on the lookout for fresh ideas.
Many are forgetting the initial reason node.js became popular. Consider the popular server-side landscape before node.js. It was dominated by Java, Python, etc. The primary way these ecosystems handle concurrency is OS-level threading. There was nothing else in the popular languages. Each language had some niche library that did non-blocking I/O (Twisted for Python, Netty for Java), but these all had a critical flaw, which is the rest of the ecosystem didn't support it. Basically every library, almost all existing code used the threading model. And when you mix threaded libraries with a non-blocking I/O server, it completely falls apart because the threaded code blocks.<p>Then came node.js. Look at the ecosystem it came into. JS itself has very little standard library, and nothing for I/O. It has a highly optimized VM supported by the resources of Google. It's a language known by many developers. node.js took this well developed clean slate and built a non-blocking I/O server on top of it. It offered a concurrency model on the server side that's completely new to many developers, an alternative to the traditional threading model everyone knew. Since server-side JS didn't exist yet, it forced all libraries to be written in this non-blocking way. Every package in NPM is written to support the core design of node.js which is non-blocking I/O. And it was exciting to many developers, it was a reason to rewrite everything in this new way.
> That said, I think Node is not the best system to build a massive server web. I would definitely use Go for that. And honestly, that's basically the reason why I left Node. It was the realization that: oh, actually, this is not the best server side system ever.<p>Really interesting. I can imagine others would refuse to give up on the thing they'd worked so hard on. But Dahl has the self-awareness to just step back and say "huh, guess this isn't so great after all".<p>Huge props to the guy.
Ryan is so smart. I like the way he thinks. This blog post [1] is still one of favorites.<p>[1]: <a href="http://tinyclouds.org/rant.html" rel="nofollow">http://tinyclouds.org/rant.html</a>
"And then, you know, maybe little servers to... maybe little development servers, and here and there, maybe some real servers serving live traffic. Node can be useful, or it can be the right choice for it. But if you're building a massively distributed DNS server, I would not choose Node."
-Ryan
I find it interesting that he ended up at Google Brain working on deep learning research after writing Node. There seems to be a trend in the industry of taking people who are exceptional in one area and putting them on AI problems (e.g. Chris Lattner). I wonder how effective that cross pollination is.
Pretty cool how he took a very unusual career/personal route to become such an important figure in the programming world. Good reminder for a parent like me that getting your kids into a "top" school isn't a must to succeed.
I was always curious why Ryan Dahl left the community. He finally answered that question; not the way I thought he would though:<p>"I think Node is not the best system to build a massive server web. I would definitely use Go for that. And honestly, that's basically the reason why I left Node."<p>Go may be an excellent choice for massive non-web servers, I don't have enough experience in it to say. For the product I work on, though, Node.js is the way to go. It's the best framework that allows us to use the same exact code on the server and on the client to create a fast progressive site.
Given free choice I'd use Elixir, but working with Node and Python at work have to say that for async web services to my surprise I prefer Node more and I def. like Yarn more as package manager.
I can't help but feel like Google gently encouraged him to promote Go over Node. Or that being told by coworkers (goworkers?) for years-on-end that Go is better than Node has had an effect. Especially considering he talks about green threads like he's not quite sure what he's talking about. At any rate, there are many innovations where the creators weren't fully aware of their impact and eventually come to hate their own designs, so no love lost there.
It seems weird to me to have an interview with Ryan Dahl today, August 31st, without talking about the political struggle the Node Foundation has been going through over the past week. <a href="http://www.zdnet.com/article/after-governance-breakdown-node-js-leaders-fight-for-its-survival/" rel="nofollow">http://www.zdnet.com/article/after-governance-breakdown-node...</a>
There's an audio version for the lazy like me (it's a podcast)<p><a href="https://api.soundcloud.com/tracks/340298200/download?client_id=cUa40O3Jg3Emvp6Tv4U6ymYYO50NUGpJ" rel="nofollow">https://api.soundcloud.com/tracks/340298200/download?client_...</a>
A lot of people talk about callback hell. For me, the biggest issue of Callbacks is that you don't have a single point to catch thrown errors. We need finer control than a global catch-all handler.
In this thread: people who don't use Node.js making wild presumptions about how it works. Callback hell? Been a few years since that's been a problem.
<i>this new paradigm of model view controller</i><p>New... in the 1970s <a href="https://en.wikipedia.org/wiki/Model–view–controller#History" rel="nofollow">https://en.wikipedia.org/wiki/Model–view–controller#History</a><p>It boggles the mind how little "web devs" know about the history of the field. No wonder they keep reinventing the wheel.