Because it looks like they are trying to appeal to people interested in European digital autonomy, but ISRG, the organization behind Let's Encrypt, is based in the US and has to comply with US sanctions.
The additional performance from the JIT is actually really small for most tasks. It should, ideally, be disabled by default. For your average JS you get <10% performance gain. Most of the cost is browser API, not JS, so the performance is underwhelming.
It’s only very heavy calculations that see a boost in performance. But, realistically, how many websites require this or currently use this today? <1%? Maybe <.1%?
This is pretty typical across JIT engines, too. PHP also sees only a slight increase in performance from the JIT. Because of the nature of PHP applications, most time is spend on the network and database. Only very CPU-heavy code sees a significant speed up.
That’s even the case for C#, which is why the dotnet runtime only conditionally JIT compiles code. Only hot path code is eligible for JIT compilation.
That is surely not the case for C#, contrary to most JVM implementations, on the CLR CIL is always jitted before execution since .NET 1.0, and this not taking into account AOT scenarios like NGEN (since .NET 1.0), and everything that came later as AOT toolchains.
The only .NET implementations that interpret CIL were the .NET Compact and Micro frameworks due to hardware limitations, nowadays mostly gone as .NET workloads, and alternative implementations like Mono.
You’re correct, where I got confused is the lazy per-method JIT and the tiers of JIT optimization. My understanding is that dotnet only compiles on first function call, or when it has to for things like generics. So, some code is never compiled if it’s never executed. And then, functions will be re-JIT at higher optimization levels under certain conditions later. You certainly know more about this than me, but yes I was wrong about conditional JIT.
I’ve done that long ago. In fact on iOS it’s simpler: since Apple doesn’t allow third party browsers to use the JIT, using any browser other than Safari will disable the JIT.
In synthetic benchmarks, there was a 40-80% reduction in performance when disabling the JIT. But in a simulated test on YouTube.com, the performance delta was only 6%.
This isn’t the best source as it’s a bit old, and it wasn’t just JIT that was disabled. But the core idea is the same: calculation-heavy code can see an improvement, but most code won’t. Why this matters is how people actually use JS on the web. It’s not for cryptography and such, it’s to manipulate the DOM.
We see a similar pattern: in synthetic benchmarks, the performance gain is large. But Wordpress, by far the largest PHP deployment in the wild, only saw ~3% performance gain. It again comes down to how PHP is used. It’s mostly HTML construction and database calls, neither of which will see any performance gain from a JIT. And, PHP has extensions, where most heavy code is moved to. Things like cryptography are done in PHP extensions, in C, where the JIT doesn’t matter. I’m more familiar with PHP, so I’ve known about the history of PHP not shipping a JIT due to the lackluster performance.
I'm glad I've already done that! I haven't seen any difference in performance like others mention though. Weird. The only override I've made is for a website which needs to run some client-side cryptography code and it would take ages without the JIT.
Fortunately I disabled js by default. Unfortunately, it breaks about 30% of the web. Including nvd.nist.gov, which shows a completely blank page without js enabled, even though with js it’s just a simple page with only static content.
The problem is that a lot of frontend web dev is driven by the React ecosystem which requires you to have SSR figured out for "no js on the client" to even partially work, which, if you ever tried to go all the way (e.g. RR v7 w/ full SSR) in a not-a-toy project, is not easy to set up and think about by any means, because your server has to be a js one at which point your entire server-side solution consist of node or node-like js server, postgres or mysql (with pooled connections through something like mysql2 and probably drizzle), something for caching like Redis, some complex process manager like pm2... i say complex because if you want to have a high performance fault tolerant gracefully restarting automatic new code deploying system ... and all of that with caching layer(s), Redis sending cache updates without you polling etc., you have to implement and test these yourself... Everything async and thinking in long term running processes and thinking about the async loop instead of a "php-like" model. Components being a potential source of memory leaks, thinking about components having to work on client and server environments, keeping SSR performance (in the sense of component rendering complexity) up etc.
This is not something just anyone is going to rush into. Bigger teams or js/ts evangelists will eventually arrive at that point if they're running something where no-js (really a side effect of seo goals) is important, but "normal people" will spend this time and engineering effort elsewhere.
I think the industry in general is moving past React, as now, and definitely in near future, the only thing that matters is ideas, the rest is for the LLMs to figure out, and so the "frameworks" are going to completely disappear from people's minds as "programming" essentially becomes "telling the AI what to do" and the AI writes asm or even binary. That is when, no JS, may become more viable again lol.
People, including me, resist it, but in the future "programming" is not going to be about writing code (or even checking it, we're way too slow and error-prone to do that), but about coming up with ideas of how to capture real world problems in an IT system, and how to solve those problems by existing (or novel) ways, picking the right tools for the job (say a statistician picking the fitting metric to capture some property of the system that will actually project meaningful observability improvements and not be "just a bunch of noise") and making the right architectural decisions in terms of correctness, performance, scope, taking into account deadlines and budget. And being the domain model glue. Everything else, all the nitty gritty we used to call programming, all the <insert a quadrillion of CS jargon keywords>, is going to be done by AI ... it's a mag 9.5 quake tsunami and it can't be stopped now.
This might completely wipe out things like React (which are largely made for humans writing the code, not for humans consuming the output of that code) faster than anyone thought possible.
Right, Anubis is a fair point, that has for sure been rising in recent months. Often when I get an Anubis page, I am reminded that I was doomscrolling and that I did not want to see the page that badly anyway, and I close the tab.
CloudFlare is a fair point though it depends on the threat level set by the website and how much CF doesn't like your browser fingerprint. In many cases it will just let you through without scripts.
I think my subjective feeling is in that ballpark, yes. There are of course many sites that are more like web apps that require js, but those are relatively trusted, I added exceptions for them long ago. For sites that I visit for the first time, I think more than half still work to some extent. Maybe they are slightly broken, but at least I can read the page. I’d say around 20–30% of the web even gets _better_, because you don’t get ads or cookiewalls. But then there are also many sites that just remain a blank page, not even showing a message that js is required. (And as the sibling comment points out, recently Anubis is also becoming more common; maybe in recent months it’s closer to 40–50% unusable.) When I hit that, often I am reminded that I wasn’t that interested anyway, and I close the tab. So maybe it’s more than 30% that breaks, and a more accurate statement would be “of the sites where I ended up reading a page, I had to opt in to js about 30% of the time”.
"Load-bearing" is maybe not the best example, but Claude uses these anthropomorphized decorative synonyms everywhere. Claude's structs don't have fields, they _carry_ them. Its programs don't log, they _narrate_. Its arguments are not provided on the command line, they _ride_ it. Its modules don't depend on other modules, they _sit_ on them, etc.
About half of the time, when a website doesn't work with js disabled, I realize that I didn't want to see the page that badly anyway, and I close the tab.
It doesn’t have to be espionage, it can be just operational risk. There is the case of Trump ordering sanctions against the International Criminal Court, and Microsoft blocking their accounts to comply (https://en.wikipedia.org/wiki/Executive_Order_14203). Or more recently, Trump deciding who gets access to Anthropic’s latest models. You can’t build a business on a vendor who may be forced to block you at any moment.
reply