If the insight in the article is actually unique, it'll just get regurgitated by other writers and AIs a hundred times, maybe even with better visuals and diagrams and that'll be the article that gets all the clicks.

of course i can look it up, but you probably have a better insight than the slop i'll find off google.

thanks for the article. these days it's rare to see something so well researched and written while still being able to tell it was authored by a human. cheers

One of the regrettable quirks of our industry is the way we replicate theoretically language-neutral components separately in multiple language ecosystems and verticals. I wish we didn't a separate npm and cargo. I wish the polyglot runtimes you mention (especially Graal) would see more adoption. I wish we didn't have both Duktape and MicroPython. There's nothing language-specific about efficient garbage collection or compact bytecode or package dependency resolution.

I thought this article was highly informative and useful. Great job, and thanks!

And what about things like Adobe Photoshop, After Effects, Premiere, and Illustrator which can run Javascript using either Extendscript in older versions or V8 in modern versions.

https://developer.adobe.com/xd/uxp/uxp/versions/

https://developer.adobe.com/photoshop/uxp/2022/ps_reference/

Cool things coming in the pipeline!

I really appreciate such deep dives, though I admittedly knew some of them because I was also obsessed much like you with the edge/ js engine space but still I learned a lot

I really liked reading through the blog. Please, take your time, rest and create such beautiful masterpieces in the future too, I would be waiting for them patiently!

Have a nice day.

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).

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.

Unfortunately, I think the article's readability would suffer if every single link were followed by an [archive] tag. Wikipedia have a better setup for providing both an archive link and a live link, which unfortunately the newsletter format doesn't really lend itself to.

I think copying the links as-is into the Wayback Machine will generally do in a pinch – just a bit of a pain to find the right month to roll back to.

Not so much! Rhino was an effort to rewrite Netscape Navigator in Java, and I expect that if that rewrite had taken off, Java might've gained a foothold (though indeed, there were Java applets for a time).

There were also Flash apps, and of course there are some significant games based on WebAssembly and low-level graphics APIs.

But ultimately JavaScript works well for GUI because it is so dynamic, allowing you to be less rigid in how you architect things. And by being a scripting language, it's super quick to iterate on.

I did begin a section on WASM runtimes, so Pyodide would've been of interest, but I could see the scope was likely to grow too much if I got into WASM so I held back.

> Ejacs is based heavily on work by Brendan Eich (SpiderMonkey, Narcissus) and Norris Boyd (Mozilla Rhino).

I did mention all of these, at least!

But I did make sure to give Chakra a few mentions!

They wanted to remove a bunch of the badly-designed stuff from the language, but MicroSoft had just finished implementing Jscript complete with all those issues at great expense. They would rather have a language with issues than change their implementation, so the world got stuck with the issues and there's now too much code on the web to change without something drastic.

If you do want to leverage runtime-specific code you can isolate that code in separate modules, so if you ever do need to migrate off a particular runtime it's easier to identify/replace that code.

Ultimately it's all JavaScript, and since most of these runtimes are open source even if they're abandoned we might see community forks. Though even if your chosen runtime is completely without support, I don't see a migration off being an extremely urgent or difficult task for most projects.

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.

If you're moving from a $0.50 to a $1.00 chip due to the overhead of using the higher-level language and save just one $200,000/year dev in the development process, you'd have to sell 400,000 units before the $0.50 chip would save you any money.

Even if you are moving from a $0.50 chip to a $3.00 chip, you can probably still save a significant amount of money on a lot of projects when you put together all the dev-years saved.