> no DOM access meant the only viable use cases were compute-heavy workloads like codecs and crypto,

no, it didn't mean that, because the overhead is not a deal breaker:

1) you don't have to do the glue code (libs can do it for you)

2) there's overhead due to glue, but the overhead is so small that WASM web frameworks easily can compete with fast JS frameworks in DOM heavy scenarios.

Source: Analysis of the creator of Leptos (a web framework based on WASM): https://www.youtube.com/watch?v=4KtotxNAwME

Could you expand a bit more?

What complexity?

interestingly, I have these options in Firefox

I think the above comment meant that he misses those Firefox options when he uses other applications.

I think this makes you implicitly are a part of this trend, because even less pro user software exists in Rust because of your decision

Seriously, that's a good point. I'll seriously consider my position when gccrs becomes a bit more mature.

Thanks for your reply.

are you implying that using Rust involves using MS products?

So Swift didn't turned out like they imagined and Rust is just the next best alternative to that failed vision using Swift.

So far this is the first and only shift

They were doing their own custom language before Swift.

didn't know

> The browser and libraries are all written in C++. (While our own memory-safe Jakt language is in heavy development, it’s not yet ready for use in Ladybird.)

https://awesomekling.github.io/Ladybird-a-new-cross-platform...

only thing I could find - has it been actually used in Ladybird after all?

No, they never completed or adopted their own language. It was back in the SerenityOS days, before the browser forked into its own project.

https://github.com/SerenityOS/jakt

Benefit: saves battery on OLED and goes easier on the OLEDs themselves

Oxymoron

last time I researched enums in TS for a project, they were a mess such that it was better not to use enums in the first place