Earlier quoted context omitted.
I'm well aware of promises, thank you. I'm also well aware that there's very little difference in reality between a promise-based style of coding and a callback one. You still lose stack continuity, it's still much harder to chain operations that hop stacks, it's still a nightmare to debug compared to stack-based programming, etc. If you've ever actually implemented a promise it's even easier to see how little promis…
First of all, I have absolutely implemented promises from scratch, and it IS trivial. However, "callback hell" is a reference to writing code with deeply nested callbacks, particularly with manual error handling at each level, both of which promises completely negate. If you want to change the topic from "callback hell" to debugging across stacks, then we can do that. There was some work with "domains," since moved t…
Interview with Ryan Dahl, Creator of Node.js
171–180 of 235 posts
Re: Interview with Ryan Dahl, Creator of Node.js
#172Earlier quoted context omitted.
You're getting a lot of pedantic replies, but your post is spot on. At the time it arrived, asynchronous operations were close to impossible in PHP, very difficult and awkward in .NET, and very uncommon in Java. In Node it not only was possible, it was impossible (without going to great efforts) to do otherwise. People have a short memory, but at the time getting single to double digits of requests per second on a be…
> People have a short memory, but at the time getting single to double digits of requests per second on a beefy server was entirely typical. Umm, what? It was not a challenge to get to double digits of requests per second on a beefy server in 2008, at least not in any popular language (including PHP and Ruby). It was (and still is) easy to scale requests of "blocking IO" languages by spawning additional threads at th…
Re: Interview with Ryan Dahl, Creator of Node.js
#173Many 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,…
I think the other parts of it are: 1) many people wanted to write server-side Javascript, 2) people did not want to use Java, and the concurrency stories for PHP, Ruby, and Python were (and still are) really crummy.
Re: Interview with Ryan Dahl, Creator of Node.js
#174Earlier quoted context omitted.
If you need "offline mode" why not just write a native app? It will be far better in every way - looks, performance, battery drain, you name it.
Because not every news website and blog needs an app. I think everybody is tired of seeing the "Install our app" banners for every website you visit.
Re: Interview with Ryan Dahl, Creator of Node.js
#175Earlier quoted context omitted.
Node.js brings callback hell to the serverside world of threads and we're supposed to be grateful? It's like you don't know the history of computing. Callback-based code was the original programming model in UNIX dating back decades! Threaded code came about because it's far easier to write it than callback-based code. The ONLY reason to do callback-based code is for performance reasons: for network-IO-heavy apps the…
I should definitely make a macro at this point: Callback paradigm has not been used in node development for 3-4 years at this point. return someHttpCall() .then(response => someOtherHttpCall(response)) // Do 2 async operations in Parallel: .then(response => Promise.join( someCacheThing(response), someDBThing(response) )) .spread((cacheResponse, dbResponse) => sendBackToClient()); This isn't callback hell. Without cre…
https://pouchdb.com/2015/05/18/we-have-a-problem-with-promis...
If we're trying to show the simplicity of modern nodejs code with non-blocking I/O, I would suggest we lead with examples like:
const foo = await queryFooObject(id); await writeToFile(foo);
True, there's still plenty of value in promises, especially for things like:
await Promise.all(severalParallelQueries);
Re: Interview with Ryan Dahl, Creator of Node.js
#176Earlier quoted context omitted.
You're getting a lot of pedantic replies, but your post is spot on. At the time it arrived, asynchronous operations were close to impossible in PHP, very difficult and awkward in .NET, and very uncommon in Java. In Node it not only was possible, it was impossible (without going to great efforts) to do otherwise. People have a short memory, but at the time getting single to double digits of requests per second on a be…
> People have a short memory, but at the time getting single to double digits of requests per second on a beefy server was entirely typical. Umm, what? It was not a challenge to get to double digits of requests per second on a beefy server in 2008, at least not in any popular language (including PHP and Ruby). It was (and still is) easy to scale requests of "blocking IO" languages by spawning additional threads at th…
A completely standard developer on .NET or PHP in 2008 was building pages that rendered at less than 10 requests per second. This is experience, not a guess, given that my role was improving the performance of those disasters. A completely average developer on node was building pages that was 10x to 100x better performance.
Secondly, simply spawning threads is laughably non scalable.
Re: Interview with Ryan Dahl, Creator of Node.js
#177Earlier quoted context omitted.
> People have a short memory, but at the time getting single to double digits of requests per second on a beefy server was entirely typical. Umm, what? It was not a challenge to get to double digits of requests per second on a beefy server in 2008, at least not in any popular language (including PHP and Ruby). It was (and still is) easy to scale requests of "blocking IO" languages by spawning additional threads at th…
I said entirely typical , not that it was a dick-sized "challenge". A completely standard developer on .NET or PHP in 2008 was building pages that rendered at less than 10 requests per second. This is experience, not a guess, given that my role was improving the performance of those disasters. A completely average developer on node was building pages that was 10x to 100x better performance. Secondly, simply spawning…
I ask because in 2008 I was only about 3 years into professional web development, and even I knew about stuff like the C10K problem[1] and that I/O Completion ports were apparently one of the few things that Unix people admired about Windows.
Re: Interview with Ryan Dahl, Creator of Node.js
#178this new paradigm of model view controller New... in the 1970s https://en.wikipedia.org/wiki/Model–view–controller#History It boggles the mind how little "web devs" know about the history of the field. No wonder they keep reinventing the wheel.
Maybe he's talking about when it got popular, not when it was literally invented...but I guess you can just be pedantic and miss the point.
Re: Interview with Ryan Dahl, Creator of Node.js
#179Earlier quoted context omitted.
I agree that we regularly fail to learn from history. However, it's worth recognizing that trying to learn from history can be incredibly challenging. There's a mountains of research to filter through. Sometimes you discover a relevant document, only to find out it's not readily available or that you have to pay an exorbitant amount of money for access. You might pay a lot of money for something that doesn't even end…
A good example - I have no idea why unix filesystems are like that, and after some idle googling I still don't know. Can't even figure out where to start to find the history of those decisions. Certainly am finding what kind of stuff goes where.
[1] http://lists.busybox.net/pipermail/busybox/2010-December/074...