Ryan Dahl: Node JS

> Async/await was a terrible idea for fixing JavaScript's lack of proper blocked threading that is currently being bolted onto every language. As fun as it is to hate on JavaScript, it's really interesting to go back and watch Ryan Dahl's talk introducing Node.js to the world ( [VIDEO] ). He's pretty ambivalent about it being JavaScript. His main goal was to find an abstraction around the epoll() I/O event loop that didn't make him want to tear his eyes out, and he tried a bunch of other stuff first.

And it keeps being polished and improved to the point it's almost not a turd, and now has types sort of, and much better engines, and now there are ARM machines that are literally designed to run it faster, and now most of your actual PC applications are written in it. But honestly it's kind of refreshing to see the original node.js presentation, where using javascript is sort of a side-note. He wanted to use callback-heavy language and JS fit the bill [VIDEO]

> One of those environments is a GUI which is naturally a good application for async. The other is not. Backend web development is still largely input -> process -> output. Node is just shoehorning JS in, and pretending that JavaScript's weaknesses are strengths. Until you need to perform two or more IO operations at the same time (e.g. more than one of: database query, Redis query, HTTP request, file operation, etc). Then it becomes: input -> Promise.all (or Promise.race, or Promise.allSettled, or Promise.any) -> output. If you watch Ryan Dahl's original presentation introducing Node, you'll see that JS was explicitly chosen because of its asynchronous nature — it wasn't shoehorned in: [VIDEO] > Not sure what you mean. There are a bunch of ways to run PHP Node doesn't require an upstream CGI server at all. There's a server built-in to the Node binary: [LINK]