Ryan Dahl: Original Node.js presentation

There is a sort of palpable energy in (Ryan Dahl) node.js original presentation. ▶ this video edit: +Ryan Dahl

i also asked this on twitter so just putting some replies here: - Doug Engelbart link - Twilio link - Stripe - "7 lines of code" - Netlify - link - Heroku - link and git push heroku master - Cloudflare - link - Node ( ▶ this video ) and Deno ( link ) - Firebase (reportedly) - link smaller companies/less impactful pitches that i still like - Redux link - Stackblitz link - Comm link - Mongodb link - Let's Encrypt link - Figwheel-Clojurescript link - Svelte link

I like the talk by Ryan Dahl, node.js inventor Original Node JS Presentation, 2009, ▶ this video In 2018 he gave a follow-up presentation "10 things I regret about node", but that presentation is more for experts.

Edit: here's the actual presentation, not just the slides: ▶ this video What's interesting about this talk is that Ryan doesn't even mention Javascript at all (other than briefly to say that NodeJS is built on it) until nearly 13 minutes into the presentation. And it's clear that he's using Javascript as a means to an end -- he's going with Javascript largely just because Javascript by default has a single threaded event loop that every JS programmer had to learn to work with it. So he brings up going with JS because JS programmers are used to callbacks already -- and then roughly 2 minutes later he immediately moves back to talking about I/O and request handling again. Very little of his presentation is about Javascript beyond an aside of "JS already does this and JS programmers are used to it, so we might as well go with that and try to copy JS conventions." He almost spends more time talking about common SQL libraries than he spends talking about JS.

The third slide of Ryan Dahl's 2009 JSConf.eu presentation ( ▶ this video ) covers most of the reasons for why it was made: "I/O needs to be done differently". Evented I/O via event loops wasn't really that much of a thing back then, and many server-side web frameworks were simply sitting idle whilst waiting on I/O. Node changed this, and thereby enabled a kind of concurrency that was easy to achieve and there by default, often without the programmer really realizing it, because they didn't have to do anything too special to get it done other than write JavaScript with callbacks. I don't think JavaScript was really the point of it. (EDIT: but JavaScript having functions as a first-class citizen, and closures, makes it a very good candidate for something that leverages event loops for this kind of thing)

See also - post on original nodejs presentation: link (was a surprisingly large number of dead links on hn regarding this one). I believe this is a copy of the video: ▶ this video

Ahh.... lovely, thank you. So what I'm referring to as "asynchronous javascript" is technically a colloquialism used to describe the event-driven callback-y nature of the code. I'm not sure I'm still against referring to javascript as asynchronous or at least as having asynchronous methods for the purposes shorthand and quick communication. Consider the code (or paste it into a chrome console) function _done(){ console.log(arguments) } var db = window.openDatabase("dbfoo", 1, "test db", 5e6) db.transaction(function(tx){ tx.executeSql('CREATE TABLE t1(a, b PRIMARY KEY);', _done, _done) }) console.log("i happen before the line above me") Notice how the lines of code complete out of order. I think it's really useful to think of that as asynchronous code. It appears I'm using async as a term interchangeably with non-blocking... which may not be correct. So it may be the case that my nomenclature is off, but I'm sure I got that from somewhere. Perhaps a lot of people were referring to node as async in the early days, I'm re-watching this: ▶ this video now, but it doesn't look like Ryan Dahl uses the term async. Anyways, looks like I'll have to train myself to use the right word for it. Thanks for pointing that out without making me feel dumb or being all insulting and internet-y. :) I really appreciate that. EDIT: Hmmm... additionally, to be fair: it appears that some agree that it is OK to refer to parts of javascript as async link so it might not be perfectly accurate, but it isn't