Houdini: Maybe the Most Exciting Development in CSS
smashingmagazine.com
Houdini: Maybe the Most Exciting Development in CSS
1–10 of 63 posts
Re: Houdini: Maybe the Most Exciting Development in CSS
#2Very interesting, and oddly reminiscent of the shift from fixed-function to programmable graphics APIs, right down to the restricted "worklets" being sort-of-analogous to shader programs.
I do wonder whether "as performant as native CSS features" is setting up unrealistic expectations. Same ballpark, maybe, but I'd have thought native will always be easier for browser vendors to optimize, even leaving aside the language/runtime differences (C++/Rust versus JS/WASM).
Re: Houdini: Maybe the Most Exciting Development in CSS
#3Very interesting, and oddly reminiscent of the shift from fixed-function to programmable graphics APIs, right down to the restricted "worklets" being sort-of-analogous to shader programs. I do wonder whether "as performant as native CSS features" is setting up unrealistic expectations. Same ballpark, maybe, but I'd have thought native will always be easier for browser vendors to optimize, even leaving aside the langu…
> Same ballpark, maybe, but I'd have thought native will always be easier for browser vendors to optimize
It will be. And things like the CSS Paint API are based on APIs that are poor matches for GPUs (but are easy for browsers of today to implement). I expect that those who are looking for Houdini for performance reasons will end up quite disappointed.
More broadly, I have seen the "replace the native implementation with a JavaScript implementation for better performance" idea tried many times, and I can't think of a single time it's actually worked.
Re: Houdini: Maybe the Most Exciting Development in CSS
#4> This subset will only include properties that can be read or set without forcing the rendering engine to recalculate layout or style (for example, transform, opacity, scroll offset).
I'm frankly skeptical of most of Houdini, but I'm especially not happy with this one. This is baking the limitations of current browser engines into the platform for all time. The provided justification seems pretty flimsy to me, because effort that goes into this (which is something that native has no concept of, for good reason) could instead go into fixing the problems that make it seem like this is necessary.
Re: Houdini: Maybe the Most Exciting Development in CSS
#5Very interesting, and oddly reminiscent of the shift from fixed-function to programmable graphics APIs, right down to the restricted "worklets" being sort-of-analogous to shader programs. I do wonder whether "as performant as native CSS features" is setting up unrealistic expectations. Same ballpark, maybe, but I'd have thought native will always be easier for browser vendors to optimize, even leaving aside the langu…
> Same ballpark, maybe, but I'd have thought native will always be easier for browser vendors to optimize It will be. And things like the CSS Paint API are based on APIs that are poor matches for GPUs (but are easy for browsers of today to implement). I expect that those who are looking for Houdini for performance reasons will end up quite disappointed. More broadly, I have seen the "replace the native implementation…
I didn't get the impression from that article that "replace the native implementation with a JavaScript implementation for better performance" was the goal at all. Rather, the goal seems to be "move away from a situation where one holdout browser (traditionally IE, more recently Safari/iOS) could scupper a new feature completely, and toward one where holdouts are just slower if they don't support that feature natively". There have been lots of examples of that strategy working - jQuery/QSA, asm.js etc.
Is that a misleading impression? Does Houdini have another agenda not covered by the article?
Re: Houdini: Maybe the Most Exciting Development in CSS
#6Earlier quoted context omitted.
> Same ballpark, maybe, but I'd have thought native will always be easier for browser vendors to optimize It will be. And things like the CSS Paint API are based on APIs that are poor matches for GPUs (but are easy for browsers of today to implement). I expect that those who are looking for Houdini for performance reasons will end up quite disappointed. More broadly, I have seen the "replace the native implementation…
I didn't get the impression from that article that "replace the native implementation with a JavaScript implementation for better performance" was the goal at all. Rather, the goal seems to be "move away from a situation where one holdout browser (traditionally IE, more recently Safari/iOS) could scupper a new feature completely , and toward one where holdouts are just slower if they don't support that feature native…
That's a reasonable use case for Houdini, yes. But I also think that if that's the goal CSS Paint and CSS Compositing should be redesigned...
Re: Houdini: Maybe the Most Exciting Development in CSS
#7Earlier quoted context omitted.
> Same ballpark, maybe, but I'd have thought native will always be easier for browser vendors to optimize It will be. And things like the CSS Paint API are based on APIs that are poor matches for GPUs (but are easy for browsers of today to implement). I expect that those who are looking for Houdini for performance reasons will end up quite disappointed. More broadly, I have seen the "replace the native implementation…
I didn't get the impression from that article that "replace the native implementation with a JavaScript implementation for better performance" was the goal at all. Rather, the goal seems to be "move away from a situation where one holdout browser (traditionally IE, more recently Safari/iOS) could scupper a new feature completely , and toward one where holdouts are just slower if they don't support that feature native…
No, that is an accurate impression. The ultimate goal of Houdini is to give developers the tools to innovate; unlike the current situation were all innovation happens at the spec level, and devs have to wait (often years) for browser adoption.
Re: Houdini: Maybe the Most Exciting Development in CSS
#8Earlier quoted context omitted.
> Same ballpark, maybe, but I'd have thought native will always be easier for browser vendors to optimize It will be. And things like the CSS Paint API are based on APIs that are poor matches for GPUs (but are easy for browsers of today to implement). I expect that those who are looking for Houdini for performance reasons will end up quite disappointed. More broadly, I have seen the "replace the native implementation…
I didn't get the impression from that article that "replace the native implementation with a JavaScript implementation for better performance" was the goal at all. Rather, the goal seems to be "move away from a situation where one holdout browser (traditionally IE, more recently Safari/iOS) could scupper a new feature completely , and toward one where holdouts are just slower if they don't support that feature native…
That's accurate, and totally reasonable. If the web is going to move forward, there needs to be a certain acceptance that older browsers should work, but they don't deserve to work well.
And definitely not as well as the latest and greatest.
Re: Houdini: Maybe the Most Exciting Development in CSS
#9> This subset will only include properties that can be read or set without forcing the rendering engine to recalculate layout or style (for example, transform, opacity, scroll offset). I'm frankly skeptical of most of Houdini, but I'm especially not happy with this one. This is baking the limitations of current browser engines into the platform for all time. The provided justification seems pretty flimsy to me, becau…
Don't just complain about it on HN, tell the developers directly (via GitHub or otherwise).
Re: Houdini: Maybe the Most Exciting Development in CSS
#10Very interesting, and oddly reminiscent of the shift from fixed-function to programmable graphics APIs, right down to the restricted "worklets" being sort-of-analogous to shader programs. I do wonder whether "as performant as native CSS features" is setting up unrealistic expectations. Same ballpark, maybe, but I'd have thought native will always be easier for browser vendors to optimize, even leaving aside the langu…
> Same ballpark, maybe, but I'd have thought native will always be easier for browser vendors to optimize It will be. And things like the CSS Paint API are based on APIs that are poor matches for GPUs (but are easy for browsers of today to implement). I expect that those who are looking for Houdini for performance reasons will end up quite disappointed. More broadly, I have seen the "replace the native implementation…
The target market is for library/framework authors, especially those wishing to make polyfills for future layout algos that haven't been adopted by everyone else yet.