3 ms·

I feel like wasm is the way out of that. Keep the legacy standards but move them to an open source wasm implementation that’s shared by all the browsers. This w

by Joeri 4y ago

I feel like wasm is the way out of that. Keep the legacy standards but move them to an open source wasm implementation that’s shared by all the browsers. This way making a new browser could be done without dealing with the mass of legacy and we might see the chromium monoculture broken.

pjmlp 4y ago
Dream on, WASM still hasn't a solid story for a GC after all these years, multi-threading isn't a given across all workloads, any new browser that doesn't run existing Web is worthless for the majority of consumers. Everyone that helped Chrome and Electron apps to be widespread, don't have anyone but themselves to thank for.
samwillis 4y ago
That's literally the opposite of what WASM is good for. The browser platform is incredible because it doesn't break backward comparability, and has a very wide set of features to allow you to do 90% of what you want, but at an (occasional) cost of performance for the 1% of cases. WASM is there for that 1%. Figma is a good example, JS+SVG+Canvas+DOM would be too slow for their use case so they built a WASM renderer. But that renderer is limited in functionality to exactly what they need, that is where they gain there performance improvement. Not by being able to magically solve problems the browser devs haven't been able to. It just a case of having a simpler renderer. That's where WASM shines (for rendering), allowing you to simplify to gain speed improvements. It's exactly the same with using JS+Canvas for performance critical drawing where the DOM is too slow. Use a simpler toolkit. Running a whole browser in WASM will always be slower, and doing what you suggest would just result in a single implementation "monoculture" anyway. (On the monoculture comment, there isn't one, Safari is massive because of Apples block of other engines on iOS. Loose that block then there may well be a monoculture)
SirHound 4y ago
WASM comes with no standard library which is bad enough for replacing JS but a killer for CSS.

by Joeri 4y ago

pjmlp 4y ago

Dream on, WASM still hasn't a solid story for a GC after all these years, multi-threading isn't a given across all workloads, any new browser that doesn't run existing Web is worthless for the majority of consumers. Everyone that helped Chrome and Electron apps to be widespread, don't have anyone but themselves to thank for.

samwillis 4y ago

That's literally the opposite of what WASM is good for. The browser platform is incredible because it doesn't break backward comparability, and has a very wide set of features to allow you to do 90% of what you want, but at an (occasional) cost of performance for the 1% of cases. WASM is there for that 1%. Figma is a good example, JS+SVG+Canvas+DOM would be too slow for their use case so they built a WASM renderer. But that renderer is limited in functionality to exactly what they need, that is where they gain there performance improvement. Not by being able to magically solve problems the browser devs haven't been able to. It just a case of having a simpler renderer. That's where WASM shines (for rendering), allowing you to simplify to gain speed improvements. It's exactly the same with using JS+Canvas for performance critical drawing where the DOM is too slow. Use a simpler toolkit. Running a whole browser in WASM will always be slower, and doing what you suggest would just result in a single implementation "monoculture" anyway. (On the monoculture comment, there isn't one, Safari is massive because of Apples block of other engines on iOS. Loose that block then there may well be a monoculture)

SirHound 4y ago

WASM comes with no standard library which is bad enough for replacing JS but a killer for CSS.