The real pertinent reason to regulate and to get noscript/basic (x)html web portals (at least on "critical" online services) is that "javascript" requires a grotesquely and absurdely massive and complex web engine, including its SDK.

The only web engines today are blink/geeko, financed by google(vanguard/blackrock), and webkit financed by apple(vanguard/blackrock). They are all written using c++ which has also a grotesquely and absurdely massive and complex syntax, and better not have a look at the compilers... aka double the pain.

In other words: "javascript" = don't have "big tech" controlled software? no web for you!

hard truth: bazillions of online services can work perfectly without a "javacript"-able web engine (javascript alone is some work but several orders of magnitude less), namely basic (x)html forms can do wonders... and actually they were!! But web dev tantrums and planned obsolescence got involved.

The only way out of it is very strong regulation, and I am personally seeing lawyers to seek noscript/basic (x)html interoperability on "critical online services".

Quickjs exists, and serenity OS' browser (ladybird) show that js engines, and js-able browsers, are doable by developers outside giant corporations.

ladybird is c++ and I was carefull to include the issue of c++ too. Depending on the grotesque and absurd c++ syntax complexity which make any c++ compiler, even naive, out of reach for any real-life and reasonably-sized alternative is a mistake on the same level than the current web engines. I said "double the pain".

It would have been much more interesting to have ladybird written in plain and simple C (with the right compile-time and runtime function tables and NOT compiling with only gcc or clang). Maybe it is not too late to fix that.

That said the real core of the pb, is the "javascript-ed" web itself, bazillions (if not all) of critical online services should work with noscript/basic (x)html browsers.

QuickJS shows that the issue is actually the "javascript-ed" webengine and the c++ language, not solo "javascript".

> It would have been much more interesting to have ladybird written in plain and simple C (with the right compile-time and runtime function tables and NOT compiling with only gcc or clang). Maybe it is not too late to fix that.

Quite the opposite. The serenityOS people are implementing their own programming language, [jakt](https://github.com/SerenityOS/jakt), which currently compiles to C++, and they'll move the codebase progressively to it as they go. I personally doubt that the project could have moved so fast in just a few years if it had been using C instead of C++.