[eikenberry]

I don't think any programming language would help with the huge surface area present in a modern browser. What really needs to happen is that the web browser needs to be obsoleted by something simpler and better. Something that at least has the chance of being reasonably secure.

[sylware]

Yep, this is what I was implying with the restoration of noscript/basic (x)html. Nearly all online services can be provided with noscript/basic (x)html, like many were before being broken by script kiddies and nasty business men who needed to do business at all cost (aka breaking simple and stable in time protocols which were having the job done). Those last are nasty pieces of work, and are seriously toxic for humanity as a whole.

That said, I gave some thoughts of that thing which would be simpler and stable in time: a light javascript engine with very basic OS functions, and I mean very basic (namely _NOT_ google AMP).

Namely, a dynamic viewport into a "framebuffer" surface 10bits RGB, and very, _VERY_, few "acceleration objects" (i18n text shapper/video decoder/blitter/network/etc), fully event based with support of multi-threading (explicit locking only, and very basic sync primitives). Namely RIP CSS and 99.99% of the insanity which became the "scripted DOM". On low-end hardware, this may be too slow to render, so this would have to be tested, we are talking heavy R&D with an outcome being very likely a failure.

I was lurking on quickjs from Mr. Bellard friends (ffmpeg/qemu/tinycc/etc) while giving some thoughs about this.

There is some kind of alternative beyond restoring noscript/basic (x)html portals (with proper network protection, ofc) though: regulation on the network protocols of critical services: namely regulated publishing of versioned (but very stable in time), straight to the point, simpler to parse than basic (x)html, noscript, rigorously defined protocols, basically a RFC (txt format), easily and readily availably on internet ("HTTP curl" would download it, and search engines would index this document and list it).

For instance, in my city there is a public service of electric bikes, the network protocol should be public (with the features I did describe above) to allow all past/present/future/small/big/etc platforms to work, instead of _ONLY_ google and apple apps (or their web engines... which is no better). For instance HTTP with a very simple json based format.

The main threats are those guys... you know those who would push over-complicated and badly defined network protocols and delirious dependencies (ultra complex parser? gigantic script engine?)

[sylware]

For the "frame buffer" surface, I was actually thinking 64bits per pixel, 16bits per components ARGB (aka completely overkill for a good and long time in theory).

[nineteen999]

People want "one big program" that can do everything on the web. Doesn't matter that it's a stupid idea. We still want it.

[sylware]

They never have wanted that, they were forced into that, it was decided for them by big tech.

That said, you perfectly can have a big program, actually one window with tabs (chromebooks), handling various network protocols (URLs are nice, irc:// etc), or system interaction.