Seems reasonable to implement a portion of an open spec for niche use cases like this.

Every browser takes several gigs of ram once you have more than a couple tabs open. I’m in the niche looking to trade off some functionality to gain some efficiency.

A browser which implements a subset of the specs that major browsers implement is still part of the open web.

A browser which implements unique functionality breaks away from the open web.

Python was an example of my point, but I was thinking even more along the lines of any scripting language that employs pre-processors, so the code inlining works.

Much like PHP does with open and closing tags, in the early days of Web development, I remember doing websites with Dreamweaver that way.

How'd you feel about a client-side PHP subset?

> Python was an example of my point, but I was thinking even more along the lines of any scripting language that employs pre-processors, so the code inlining works

I’m sorry, I’m not really understanding what you mean here.

> client-side PHP subset

I’d dislike it for the same reasons as before.

Php was made to and evolved largely for generating HTML on a server. Not to have snappy, non blocking, event driven user interfaces.

And since PHP is not a standardized the same way JavaScript is, any browser may or may not implement it the same was as another.

We’d be back in the early 2000s world of browsers incompatibilities.

What would native browser support for php give you vs a wasm implementation of it?

Python has await/async; what else do you need for non-blocking, snappy, event-driven UI?

JavaScript didn’t always have async await.

The implementation details also affect runtime performance.

JavaScript rarely blocks execution, it’s what makes it snappy.

For example, Python blocks by default, unless you run your inside a Python async wrapper like asyncio.