4 ms·

The question is not what to add, but what to take away. But I guess this notion due to Antoine de Saint-Exupéry is lost on CSS heads which brings us into the te

The question is not what to add, but what to take away. But I guess this notion due to Antoine de Saint-Exupéry is lost on CSS heads which brings us into the territory of another quote attributed to Upton Sinclair: "it's difficult to get a man to understand something, when his salary depends upon his not understanding it." By whom however I don't mean Chris Coyler even though his css-tricks.com when he was still running it certainly profited off CSS' let's say less-than-razor-sharp scope.

christophilus 4y ago
Taking anything away breaks backwards compatibility, so that’s a problem. I agree, though, that this means we should be really hesitant to keep piling on features.
- 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.
- sergiomattei 4y ago
  It’s different with CSS. It’s been so unreasonable and unergonomic for so many years, and for no reason whatsoever. Today I’m using PostCSS to get over these problems, but I wish I didn’t have to.

christophilus 4y ago

Taking anything away breaks backwards compatibility, so that’s a problem. I agree, though, that this means we should be really hesitant to keep piling on features.

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.
sergiomattei 4y ago
It’s different with CSS. It’s been so unreasonable and unergonomic for so many years, and for no reason whatsoever. Today I’m using PostCSS to get over these problems, but I wish I didn’t have to.