7 ms·
The many JavaScript runtimes of the last decade
- LinguaBrowse 1y agoTook me over a year to finish writing this monster of an article. 4,000+ words, 200+ links, and lots of research covering countless JavaScript runtimes and engines. Please have a read! I guarantee you'll learn something new.
- n0n0n4t0r 1y agoI indeed did learn (a lot). Thank you sir for this monster:)
- kamikazeturtles 1y agoI always wondered if there is still an ROI for writing a well researched in depth article. 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.
- tommica 1y agoMaybe the ROI is something more personal than getting clicks?
- zero_shift 1y agoIt can be. But there is a certain existential dread, in the hours after sharing something, when you fear it might all have been toil in obscurity
- chistev 1y agoI feel this way.
- LinguaBrowse 1y agoI had some faith this time as I saw a good handful of readers opening the email just moments after I'd posted the newsletter out! And while I figured Hacker News would be a coin flip, for other sites that show link previews, I was optimistic that the cartoons would encourage a click, too. In a time where many writers are using soulless AI-generated poster images, just putting in a token effort to do something original goes a long way.
- LinguaBrowse 1y agoAuthor 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.
- jjkaczor 1y agoNaw - the internet enables "long-tail" content - but I say this as a person who occasionally writes VERY long "blog-posts" that are technically KB/how-to, magazine article length... Yes, AI will scrape it and regurgitate it - but over-time it will reach people who need to know - plus it is also helpful for oneself...
- simonw 1y agoThe 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.
- johnisgood 1y agoThis is very true, in life in general. You do a good deed on the street right before your interview, and lo and behold, the person you did the good deed to turns out to be your interviewer! These things (be it an article or a good deed) can definitely pay off.
- Tokumei-no-hito 1y agoit's interesting that a lot of innovation happened on mobile runtimes to deal with apples JIT restriction. what was that about and why didn't android have the constraint? 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
- toast0 1y agoApple 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.
- quotemstr 1y ago> 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. Another regrettable thing about our industry is the proliferation of locked-gate-in-an-open-field-tier security theater. Apple's PROT_EXEC restriction has zero security benefit: anything JIT-compiled code can do, interpreted code can do too. (In the same vein, macOS Santa (used by many a tech company to police programs runnable on Apple developer endpoints) doesn't restrict script launches at all. The interpreters that Apple ships with macOS have built-in FFIs like Python ctypes that enables programs launched using these interpreters to do anything a Mach-O binary can do.) While I respect the sweat and cleverness that went into making JS runtimes work efficiently while wearing Apple's no-PROT_EXEC hairshirt, none of this work ought to have been necessary. Imagine how much further ahead the industry would be if these big brains had focused on solving some other problem.
- LinguaBrowse 1y agoI totally agree that the lack of JIT has been a huge waste of human resources. NativeScript and React Native have had to move so many mountains to make viable software despite it.
- frankietaylr 1y agoFascinating read. Great work on the research. Where do you think it will go from here?
- LinguaBrowse 1y agoAs 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-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-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!
- quotemstr 1y agoThanks for putting in all this work. People should get more credit for writing good survey articles like yours. 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.
- LinguaBrowse 1y agoThank 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-2921070839 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.
- serhalp 1y ago> 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. FYI: https://thenewstack.io/vites-creator-on-a-unified-javascript-toolchain-and-vite https://thenewstack.io/vites-creator-on-a-unified-javascript...
- LinguaBrowse 1y agoI'm keeping my eye on Void0, yeah! If anyone can live up to such promises, it'll be them. They'll have a tough job getting sticky ecosystems like React Native to adopt, but hope to see them make a compelling case for their stack.
- nabwodahs 1y agoI'm relatively new to the JS/TS space and I'm building a mobile app that needs to run on both platforms. Also building a back end for it using Deno. I thought this article was highly informative and useful. Great job, and thanks!
- LinguaBrowse 1y agoThank 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.
- nabwodahs 1y ago[dead]
- leptons 1y agoDid 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). 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/xd/uxp/uxp/versions/ https://developer.adobe.com/photoshop/uxp/2022/ps_reference/ https://developer.adobe.com/photoshop/uxp/2022/ps_reference/
- LinguaBrowse 1y ago> 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.
- syrusakbary 1y agoThe article is awesome. Thanks for the mention to Wasmer and WinterJS. Cool things coming in the pipeline!
- pjmlp 1y agoIt was a very interesting read, thanks for the effort and sharing it with us.
- Imustaskforhelp 1y agoThis is the first time I have ever signed up for a newsletter and I did it without reading the HN comments or the fact that you wrote it or it took so long to write. 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.
- LinguaBrowse 1y agoThank 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!
- fud101 1y agodidn't read it, was too long and the parts i skimmed were dull.
- Neurrone 1y agoIncredible article. I never knew there were so many JavaScript runtimes out there, and that it was possible to run JavaScript on microcontrollers.
- Sytten 1y agoI would like to rectify that LLRT is mostly community contributed and one guy from AWS (Hi Richard!). There are many businesses using LLRT modules (I worked a lot on making it modular) and rquickjs. I am a maintainer of both and I wrote a couple of modules myself. There is no better JS runtime for Rust IMO, it is based on quickjs-ng (a fork of quickjs initially due to quickjs inactivity but not both projects are active and have diverged) with a lot of the major Node/WinterJS APIs.
- LinguaBrowse 1y agoOh 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).
- Sytten 1y agoAWS 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?)
- cat-whisperer 1y agoI'm curious, how do these new runtimes handle async context tracking? Do they all rely on Async Hooks or implement their own solutions?
- LinguaBrowse 1y agoI'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 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/ https://docs.rs/tokio/latest/tokio/), too, but I wouldn't be surprised if a large number of them just do things bespoke.
- reactordev 1y agoWhat!? No mention of bun?
- hyper57 1y agoBut Bun is mentioned three times?
- reactordev 1y agoThey should include the link to their site then: bun.com I used document.querySelector(“a”) and couldn’t find mention of it, upon reading it thoroughly, they do mention it. My fault.
- jonluca 1y agoYou ran javascript before doing a cmd+f? I guess you are the target audience for this article
- reactordev 1y agoYou assume it was me that opened the page on a desktop or something with a primitive keyboard. I asked my agent to summarize and provide me the list of links to see if it was there. The list did not list bun. The code it executed through my phantomjs mcp server was simply: document.querySelector(a);
- xnacly 1y agoWell i guess thats what you get for using mcp instead of just opening the article and reading it
- owebmaster 1y agoHow can you complain about the article after wrongly assessing it? That's next level AI slop
- sumeno 1y ago
- ottod 1y agoThis article deserves to be the basis of a Wikipedia page. It is so well written and full of references. Congratulations to the author.
- LinguaBrowse 1y agoThank you very much, really appreciate it! There's a respectable article on engines (https://en.wikipedia.org/wiki/List_of_JavaScript_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.
- NeutralForest 1y agoThanks for the article! Do you have a solution, if any, to maintain links green? Anytime I write something with lots of links, I'm always afraid that there's basically no way to retrieve the original page after some time.
- paulddraper 1y agoWeb archive and pray
- NeutralForest 1y agofair
- LinguaBrowse 1y agoThank you! It did cross my mind. I've archived a couple of the hard-won links in there that I had a feeling at great risk of rotting. But thankfully a lot of the links are to GitHub pages, so I'm not so worried about those. 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.
- weiliddat 1y agoI see a few mentions of QuickJS, but they all refer to the fork of Bellard's QuickJS https://bellard.org/quickjs/ https://bellard.org/quickjs/, which I think deserves a mention. It seems to be still active (last release 2025-04-26, GitHub mirror at https://github.com/bellard/quickjs https://github.com/bellard/quickjs shows some activity).
- LinguaBrowse 1y agoI had it in my head that quickjs-ng (https://github.com/quickjs-ng/quickjs https://github.com/quickjs-ng/quickjs) is now blessed as the official fork, with Bellard even making some contributions to it, but maybe I've got it wrong. Here's the latest (https://github.com/quickjs-ng/quickjs/discussions/258#discussioncomment-11276265 https://github.com/quickjs-ng/quickjs/discussions/258#discus...) clarifying the two forks, anyway.
- Sytten 1y agoBoth are active now and they are diverging. It is kinda sad but Bellard seems to want to do his own thing. PRs are traded sometimes but as time goes on they will become different projects, I did suggest a name change (https://github.com/quickjs-ng/quickjs/discussions/1119 https://github.com/quickjs-ng/quickjs/discussions/1119)
- weiliddat 1y agoCool thanks for the historical context
- williamcotton 1y agoSpeaking of QuickJS, how does it compare to embedded Lua? In performance, memory overhead, C API, startup time?
- LinguaBrowse 1y agoNo idea! The only benchmarks I'm aware of for QuickJS are against other JavaScript engines (https://bellard.org/quickjs/bench.html https://bellard.org/quickjs/bench.html). 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.
- laurencerowe 1y ago> For all the overlap in strategy, notable is the variety in engines underpinning all these runtimes. While Deno continues Node.js's tradition of using V8, we see Bun employing JavaScriptCore, WinterJS using SpiderMonkey, LLRT on QuickJS, and Cloudflare Workers on the tailor-made workerd. No longer is the backend solely a stage for Node.js and V8 – it's now fashionable to pick a runtime and engine optimised for the task. I don't think this is completely accurate. While Cloudflare's workerd is a tailor-made runtime (equivalent level to deno/node/bun/etc.) it uses the V8 engine. https://github.com/cloudflare/workerd/blob/main/docs/v8-updates.md https://github.com/cloudflare/workerd/blob/main/docs/v8-upda...
- vlovich123 1y agoThat is correct. It uses v8
- LinguaBrowse 1y agoDang, I misunderstood that, thanks! Fixed.
- LinguaBrowse 1y agoMy mistake, thank you for the correction! I've updated the article to avoid any future readers walking away with the wrong information.
- righthand 1y ago> Lastly, JavaScript continues to show its strength as a language for GUI programming, being employed in a variety of ways to develop native apps on mobile phones and Smart TVs, though with web view based apps still being the vogue on desktop. Really? I thought over the last decade we let other languages into the browser but Javascript was so amazing that no one uses the other languages. Javascript has had all this competition on the UI layer it’s amazing it came out #1. Am I reading the implication correctly?
- LinguaBrowse 1y ago> I thought over the last decade we let other languages into the browser 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.
- righthand 1y agoI was being sarcastic in my post. I find bragging about Javascript as a flourishing UI language omitting quite a bit about why.
- LinguaBrowse 1y agoEh, writing is hard!
- righthand 1y agoAnd how!
- breve 1y ago> JavaScript works well for GUI because it is so dynamic Amazon moved to WebAssembly for their Prime Video application for both higher and less variable performance: https://www.amazon.science/blog/how-prime-video-updates-its-app-for-more-than-8-000-device-types https://www.amazon.science/blog/how-prime-video-updates-its-... https://www.infoq.com/presentations/prime-video-rust/ https://www.infoq.com/presentations/prime-video-rust/
- karenbass 1y ago[dead]
- willquack 1y agoI had a good time being involved with a couple JavaScript runtimes which didn't make this list, most notably PythonMonkey [1] which embeds SpiderMonkey into Python and uses Python's event loop for its async stuff. Another interesting one was DCP which is sort of a pseudo js runtime that runs ontop of other js runtimes (including a custom sandboxed server-side runtime we made [3], but also any web browser), to provide cloud function like compute for js and wasm based workloads. Unrelated to the article, and already well known, is Pyodide which is a Python runtime in JS/WASM. I shoved Pyodide into DCP so people could run Python workloads in web browsers [4]. Crazy stuff... 1. https://pythonmonkey.io/ https://pythonmonkey.io/ 2. https://distributive.network/workers https://distributive.network/workers 3. https://gitlab.com/Distributed-Compute-Protocol/dcp-native https://gitlab.com/Distributed-Compute-Protocol/dcp-native 4. https://willpringle.ca/blog/dcp/pyodide-worktime/ https://willpringle.ca/blog/dcp/pyodide-worktime/
- LinguaBrowse 1y agoMy analysis on the polyglot runtimes was relatively shallow and I did anticipate I might disappoint, sorry! Thanks for the additions! 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.
- michaelsbradley 1y agoNo mention of Ejacs‽ https://github.com/emacsattic/ejacs https://github.com/emacsattic/ejacs
- LinguaBrowse 1y agoAt 17 years old, I think it's comfortably outside of the scope of the article I was focusing on (the last decade), but thanks for bringing it to my attention! > Ejacs is based heavily on work by Brendan Eich (SpiderMonkey, Narcissus) and Norris Boyd (Mozilla Rhino). I did mention all of these, at least!
- ksherlock 1y agoMissing^1: JScript from MicroSoft (circa 1996). Not only was it in Internet Explorer, it could also be used server side (ASP) and for scripting (WSH). Then there was JScript.NET (circa 2000)... 1. Not last decade but some of it's contemporaries are mentioned.
- LinguaBrowse 1y agoI deliberately scoped it to the last decade because I felt it would be very hard to dig up information from around 1996 – would be better for me to leave that period to folks who were active developers around that time and lived through it all. But I did make sure to give Chakra a few mentions!
- hajile 1y agoJscript was the most evil of all the JS implementations. It's the reason why MOST of the thing people hate about JS are still in the language. 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.
- timw4mail 1y agoMumbles about annoyances at hanging commas I bet JSON would allow hanging commas if not for Jscript.
- rorylaitila 1y agoGraalVM/GraalJS is one I am most impressed with. It 'just works' and I've been able to integrate it into my java web applications easily. I mostly use JS in java to run handlebars.js and test JS code library that we use both on the server and the client.
- LinguaBrowse 1y agoI'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.
- asn0 1y agoMissed Nombas ScriptEase, a 90’s-era commercial runtime most famous for allowing JavaScript to operate the James Webb Telescope. http://brent-noorda.com/nombas/us/index.htm http://brent-noorda.com/nombas/us/index.htm
- LinguaBrowse 1y agoVery 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!
- cxr 1y agoThere'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).
- dfee 1y agoThis article provides good insight on the boom, but leaves out any insight on the inevitable bust - not on JS per se, but the distinct runtimes. Deno and Bun seem to be two highly competitive runtimes, each VC backed and positioned against each other, but the fairly tale of multiple winners seems unlikely in a world that favors power laws. So then, how do others see these ecosystems surviving over the next decade? What are the canaries? And, how interoperable will our code be?
- nosefurhairdo 1y agoWinterCG is trying to help standardize web APIs to address these concerns. So one strategy when writing server-side js is to stick to standard APIs as much as possible. 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.
- LinguaBrowse 1y agoA 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.
- fatih-erikli-cg 1y ago[dead]
- Tom1380 1y agoWhy would someone use js on a microcontroller?
- LinguaBrowse 1y agoCould 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.
- hajile 1y agoFor the same reason someone would use Lua or MicroPython. 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.
- dehrmann 1y ago> Rhino There was a time when Java shipped with a JS interpreter, but not a JSON parser... unless you use the JS interpreter.
- podgorniy 1y agoBeautiful article. Thanks the author and whoever brought it to HN
- madisontony 1y ago[dead]
- hajile 1y agoThere's something special about the JS specs and test suite. There are very few languages where you can write/run the same piece of code across so many different runtimes without major issues.
- SahAssar 1y agoNo love for njs, the engine for running javascript inside of the nginx web server?