I've learned a lot over 10 years as a software engineer and thought it was about time I had a place to write up all this hard-earned knowledge. So I created a docs site, for myself!
I gradually realised that, as a "personal" docs site, it needn't be limited to just software notes. I could write whatever I like on this thing. Why not recipes? Sheet music? Or language study notes? The MDX format makes it easy to express anything I want, the source and output are available from any device, and it all gets indexed for search, so it's quite compelling versus basic solutions like Apple Notes.
So over the last month, I've been filling it out with articles to show the full potential of such a resource. I feel like we could all find a use for a personal docs site!
A very good thought! Deno and Bun have this formidable funding for sure, but Node.js is still innovating. Things like type-stripping and require(esm) come to mind. I think as long as big companies use it for Electron, Node.js will continue to get investment. Even if the investment were to dry up, experience teaches us that old tools die hard.
I would hope that interoperability goes up. The React Native community are closing in on support for Node-API, and with that maybe we can start sharing native code between desktop and mobile. The WinterCG effort is also going well.
As for canaries, I think sustainability is the main thing to look at. What is the surface area of this tool, how much expertise and effort does it take to maintain it, and who is invested in its survival? The more we can share common implementations like Intl and Temporal, the easier it is for smaller players to keep up. And of course, the more the big players try to diverge (looking at you, Chrome), the harder it gets.
Could be to draw upon the existing JavaScript ecosystem, or could just be because JavaScript is the language the dev knows best! I feel really nerfed when I have to move from JavaScript to other languages, personally, even if I can get things done in C++ and other languages.
Thank you very much, really appreciate it! There's a respectable article on engines (https://en.wikipedia.org/wiki/List_of_JavaScript_engines), but indeed, no article on runtimes. I did feel that they were under-discussed compared to engines, though, with most analysis focusing on browsers and Node-alikes, so wanted to add something to the literature.
Very cool, though when I was qualifying the scope for "the last decade", I was doing it by creation date rather than usage date, so I think I get a pass on this one!
There's a whole section on PhoneGap/Cordova, where, ignoring creation date, even most of the milestone years are outside the "the last decade" timeframe. It's a very strange decision, and leads to things like gjs only being mentioned as an afterthought, which exemplifies the major blind spot that people who came out of the NPM world have for the use of JS in stuff like Firefox (which was doing Electron before Electron) and Gnome (if you've used Gnome in the last 10 years, you've seen JS in action on the desktop). The best explanation for this is that the latter two are so successful at doing what they aim to accomplish that people don't even know it's there, and when things are more about getting things done than they are about hype, then the hype crowd of course fixates on the hyped stuff instead (no matter how short-lived or obviously-doomed-from-the-start).
I've heard nothing but high praise for GraalJS, yeah. I wonder whether it'd make any sense inside mobile apps – not due to any feature in mind, but simply out of interest because that's more the area I'm using JavaScript. The first-class interop with Java would be great for Android, though I wonder how cheap its interop with iOS (C-family languages) would be.
That said, one thing I've heard a lot from NativeScript TSC members building on top of QuickJS is that QuickJS has staggeringly low overhead for calling C functions. In fact, I was shown benchmarks in which it calls native functions faster than JS functions (perhaps it's easier to optimise because JS functions have complications like closure capture to worry about). I imagine this has conceptual overlap with how V8's Fast API works.
Oh right, thanks for the insight. Wondering how to rephrase it. Did AWS at least create it, or fund it?
rquickjs looks like a good one to include in the article. I've just edited it into the polyglot engines section (I think I've got a mix of engines and runtimes in there at this point anyway).
AWS created it and it is still under their name but under the labs thing which means it is a "side project". Unsure how I would phrase it, but just wanted to acknowledge the community and businesses that are building it (maybe stewardship?)
I'm not familiar with the term "context tracking", and management of the event loop is a bit lower level than I normally go, but I do know several runtimes use libuv (https://libuv.org) to handle asynchronous I/O, the same as Node.js (which it was created for).
I'm sure there will be JavaScript runtimes out there using some of Rust's asynchronous schedulers like tokio (https://docs.rs/tokio/latest/tokio/), too, but I wouldn't be surprised if a large number of them just do things bespoke.
