Thank you very much!

I totally agree on reinventing the wheel. I think our biggest tool towards that will be Node-API, which is the one low-level building block that JavaScript runtimes seem to agree on (and heck, I'm sure non-JavaScript engines could implement a decent chunk of Node-API). The Hermes team are currently interested in it (https://github.com/facebook/hermes/pull/1377#issuecomment-29...) for implementing heavy chunks of the ECMAScript spec like Intl and Temporal as plug-in features.

It's interesting that you bring up tooling like npm and Cargo, I've never thought of sharing those. Although I'm no great shakes at Rust, I really, really liked how Cargo did things (e.g. optional dependencies and rigid library structure) and it'd be incredible to have that for the JavaScript ecosystem.

Also do keep hearing nothing but great things about Graal, I think it's being slept on.

Just because he spent 1 year ???

The ROI can still be massive even if only a few people actually read it.

It just takes one person who read the article (or found it later via search) to get a huge ROI if it resonates just right.

A job opportunity, an invite to some event, a potential collaboration - the right reader can unlock all kinds of opportunities.

Maybe the ROI is something more personal than getting clicks?

Author here – the return on investment will be modest, no doubt. I started the newsletter in order to share any thoughts on various topics without having to please a social media algorithm to get seen. Winning a few new readers for my efforts is all I'm really looking!

As for the article getting regurgitated, I am not too worried. It is simply an awfully long, awfully dense article for any LLM to synthesise more than a handful of bullet points out of, so I think any derivative product is going to make for a far less engrossing read. Indeed, if you try asking ChatGPT about runtimes right now, you'll get a pathetically shallow and mainstream analysis.

There may well be clickbait articles spawned from this, but I'm optimistic that people will find the source and be able to tell in an instance that it's the Real McCoy.

> Did you consider things like JScript.NET? jsc.exe still comes with every Windows installation, and JScript still runs on IIS server (I have built a few things with it).

I've not heard of any of these, wow – very cool that it's still bundled with Windows. I suspect that most things related to JScript wouldn't fit the scope of "the last decade", though? I tended to focus on creation date when deciding what should be in scope.

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

Hmm, these may well qualify, you're right. Maybe I can add them to the addendum. I'd want to do a bit of research to understand their timeline and genealogy before including them, though. Wrists beginning to hurt for today now, though!

I do recall now that Adobe PDFs can run JavaScript. That would've been worth a mention for sure.

Thank you for the kind words! Glad to get this one out of the way so that I can do some less ambitious articles for a change. But hope to make them good in their own way, too!

Thank you! I'd tend to default to Expo if building a mobile app in JavaScript these days, but Capacitor, Tauri, and NativeScript are all good options too.

As for JavaScript runtimes, having seen Lynx (and some of the internal work NativeScript is doing), I'd like to see more engine-agnostic runtimes rather than coupling each runtime to one engine.

As for writing, I'd like to stick to more manageable topics in future so that I can write as a hobby rather than as daunting work. My previous "Frontend predictions for 2024" (https://buttondown.com/whatever_jamie/archive/frontend-predi...) was similarly thorough and took an exhausting rush to write up. But simpler articles like "Staying productive with chronic pain" (https://buttondown.com/whatever_jamie/archive/staying-produc...) were all possible to finish in a weekend.

There's probably a good story in Node-API, but I think I'd rather take on a research-light topic for a break first!

Apple has a JIT restriction because JIT introduces native code that was not present during app review, and app review is where they prohibit calling non-public APIs, at least historically.

Android doesn't have a JIT restriction. API restrictions are expected to be enforced at runtime, not through review time checks.

The other reploies seem to have answered it! I've never understood why iOS allows JIT inside WKWebView yet not inside bare JavaScriptCore. Maybe because WKWebView runs in its own separate process while a JavaScriptCore instance would run in-process? As for Android, guess Google are just a little more gung-ho?

> 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

Really appreciated, thanks! I do despaire that the ease of generating content with AI disincentivises (and discourages) authors from expending real effort, but there's a satisfying inflection point at which you can be sure you've written something that an LLM couldn't possibly have come up with.

It's fine to not like things, but what exactly is the point of your comment, other than being mean?