This is wrong. The underlying runtimes, HTML/CSS/ES implementations got much better, they constantly fight incoherences that old timers remember and at the same time add new powerful features.
Mostly, because they were designed and implemented in a way that cemented them in place.
Is HTML the right abstraction for UI toolkit? If not, can we ever move towards an alternative that is? Maybe via wasm, IDK. Or css? Where we can never change the legacy (body has a margin, select is untylable) only add new, alternatives next to it (flex, datalist).
JavaScript is the only option, but it's fundamental design (weak typing, no parallelism, make it a poor choice for anything of scale. Which is why anything large or complex gets built in other languages that transpile, or that are somewhat available (wasm, webgl) as alternative.
Point being: yes, it is improving. So fast that an oldtimer like me cannot keep up. But all that improvement is tethered to foundations that are wholly unsuitable for what we want to use it for.
But many of yhose foundations are wrong.
Mostly, because they were designed and implemented in a way that cemented them in place.
Is HTML the right abstraction for UI toolkit? If not, can we ever move towards an alternative that is? Maybe via wasm, IDK. Or css? Where we can never change the legacy (body has a margin, select is untylable) only add new, alternatives next to it (flex, datalist).
JavaScript is the only option, but it's fundamental design (weak typing, no parallelism, make it a poor choice for anything of scale. Which is why anything large or complex gets built in other languages that transpile, or that are somewhat available (wasm, webgl) as alternative.
Point being: yes, it is improving. So fast that an oldtimer like me cannot keep up. But all that improvement is tethered to foundations that are wholly unsuitable for what we want to use it for.