10 ms·

Houdini: Maybe the Most Exciting Development in CSS

159 points by mattiemass 11y ago

mrec 11y ago
Very 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).
- pcwalton 11y ago
  > 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.
  - mrec 11y ago
    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?
    - pcwalton 11y ago
      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...
    - philipwalton 11y ago
      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.
    - michaelchisari 11y ago
      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.
  - madeofpalk 11y ago
    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.
- bfgeek 11y ago
  Most things should be within the same ballpark. The trouble is at the moment that CSS polyfills are an order of magnitude (or two) off native performance. Example: Current CSS layout polyfills (like grid, regions etc) suffer from this. Where you will see performance improvements is when developers create more expressive layouts/paints/etc. For example you can implement a grid layout with a bunch of nested flexboxes. You could also do it with the CSS Layout API. Because by using the CSS Layout API requires fewer divs, and maybe no N^2 layout passes, chances are it'll be faster. But this really gets at the point of Houdini is to inform browsers/specs what is important. If a grid/masonary polyfill becomes widely used, then it will help inform CSS work.
pcwalton 11y ago
> 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.
- ZenoArrow 11y ago
  Don't just complain about it on HN, tell the developers directly (via GitHub or otherwise).
  - cloverich 11y ago
    A fair point, but pointing out a perceived flaw on Hackernews often leads to good discussion, and is sometimes followed by the authors themselves. I can see both sides of it, but I'd personally like to start it here then carry it over to filing an issue afterwards (if it still feels it has merit).
    - ZenoArrow 11y ago
      Okay, let's start the discussion here. The premise is that the design decisions being made for Houdini now will hold back CSS functionality in the long run. Two questions: 1. What is an example of a new stylesheet feature that couldn't be implemented with Houdini in its current design? 2. Why will the current decisions being made on the Houdini APIs hold back further evolution of these APIs? In other words, why can't we go with a MVP and evolve as required?
      - pcwalton 11y ago
        The Paint API is a poor match for GPUs, so we're going to encourage people to write poorly performing features with the API as designed. The compositing API is overly tailored to existing browser engine details. It's forcing complexity onto Web developers when the problem should be solved at the engine level. Having to do all the compositing logic in a worker is terribly inconvenient anyway. If main thread animations are untenable due to random main thread jank, let's fix that instead of adding difficult-to-use workarounds. We're not doing the Web any favors when competing against native by saying "you can get native performance, but only if you contort your program". An "MVP" that is poorly designed is not an "MVP". There are designs that are flawed due to not having enough features; this is a reasonable candidate for an MVP. But there are also designs that are flawed due to fundamental design problems. Releasing these kinds of designs onto the Web is not releasing an MVP; it's making another mistake.
yugai 11y ago
I think it's not very exciting at all. Browser support for Houdini will be a new issue in the future if they manage to release anything.
- debacle 11y ago
  XKCD 927.
  - kearneyandy 11y ago
    https://xkcd.com/927/ https://xkcd.com/927/ For the lazy
Zardoz84 11y ago
Great! But sadly, I must keep working with IE8 compatibility. Government related clients update at glacial speed...
- michaelbuddy 11y ago
  Government contractor here on site at somewhat large gov't facility, we're fully updated to IE11 on Win 7 now. Before that, we had a lot of people on IE9. Microsoft support end dates are darn helpful. Kicks people into gear.
  - JoblessWonder 11y ago
    Yeah... Microsoft standing firm on support dates and actively encouraging people to upgrade seems to have really made a huge difference. I'm sure it also makes them a pretty penny to maintain support contracts for entities that refuse to upgrade past the official EOL.
    - gtjrossi 11y ago
      Microsoft engineer here. I would assert we want people upgraded more than anybody else on the planet. Our extended support contracts were designed to be cost prohibitive to encourage this point and were nowhere near a money-making venture. The engineering matrix (cost) for a fix across old versions was insane: IE6, 7, 8, 10, 10 touch; 32bit, 64bit, ARM; Windows XP, Vista, 7, 8, Server, Mobile, etc.; 5.5/7/8/9/10 browser document modes; etc. A "single" fix often meant weeks of porting work for engineers after the initial fix was written. Note that the Jan 12, 2016 End of Support date means there are no more security updates, non-security updates, free or paid assisted support options, or online technical content updates. https://support.microsoft.com/en-us/lifecycle#gp/Microsoft-Internet-Explorer https://support.microsoft.com/en-us/lifecycle#gp/Microsoft-I...
wheaties 11y ago
Quick question, what's to stop someone from reimplementing, say "float: right" to also spin up a banner ad? That is, this sounds great in principal but much like Microsoft's Tay taught us, the internet is full of *-holes.
- adrusi 11y ago
  Well that's already possible now just by reading the CSSOM and patching new things into the DOM like how the article described the current state of affairs. If you just want to shunt another banner ad in there, that's not something that will hurt performance too much.
- codingdave 11y ago
  I'd expect that anyone who has access to the page/app enough to extend CSS to spin up ads would also have enough access to the app/page to just put ads on it anyway, in much easier ways.
- talmand 11y ago
  I'm not sure I understand the question. Are you suggesting that someone might use this tech to bypass adblockers by integrating ads into a CSS property? Or is it something else?
debacle 11y ago
Seems like a band-aid for CSS, which needs to go away. Styling the DOM in the fashion we have been for the last 15+ years needs to end. JavaScript has evolved, but we still need to use LESS and SASS and Modernizr and other tools. CSS doesn't need abstractions. It needs to be replaced.
- davidkpiano 11y ago
  It does not need to be replaced, and it's highly impractical for it to be replaced since it's such a core part of all web browsers that's not going away anytime soon. Are you suggesting we style with JavaScript?
  - debacle 11y ago
    Flash was also once a core part of the web browsing experience. CSS is a big warty blob, and a relic of the "semantic web." "Styling with JavaScript" is probably too verbose of a solution, but it's one option.
    - talmand 11y ago
      I'd be curious how styling with Javascript would work. Almost every example I've ever seen of such ideas comes down to actually just writing CSS in Javascript. Which is just silly.
      - debacle 11y ago
        Right. We need a better solution. Actual inheritance would be a good step.
    - pcwalton 11y ago
      And you're going to have much worse performance. CSS is actually not slow for what it does.
    - mindcrime 11y ago
      CSS has almost nothing to do with the semantic web. It has been associated with the use of "semantic markup", but those two things are only weakly related.
romaniv 11y ago
Maybe we should just transpile Flash into ASM.js and be done with it. And yes, I am being sarcastic here. I understand the motivation underpinning such projects, but the approach of introducing yet another complicated API with dubious cross-browser support is not something that will move the web forward in a meaningful way.
msoad 11y ago
What we need is a "strict mode" HTML. Number of APIs available to web platform is getting out of hand. Using ES6 module system we can clean up the web API landscape. Here is the idea: you declare your document to be in strict mode: <!DOCTYPE strict> In this mode you don't have access to any API unless you import it. You need to import CSS layout systems like regular box model or basic APIs like query selector. You also need to import each html element you use. This way browsers don't have to take into account every possible CSS property or html element when doing layout or painting. After we got that, then you can import your own implementation of standard modules that is written using APIs introduced by Houdini Here is an example: import "html/div" import "css/flex" import "dom/query"
- pcwalton 11y ago
  > After we got that, then you can import your own implementation of standard modules that is written using APIs introduced by Houdini Reinventing the platform using JavaScript in that way is not going to be good for performance. At least right now, until at the very least shared memory multithreading is available. I also want to call attention to this: > This way browsers don't have to take into account every possible CSS property or html element when doing layout or painting. But in order to get good performance we want to take every possible CSS property into account. Performance is about being able to make simplifying assumptions (especially on the GPU, where state changes are costly). We want to make global optimizations based on the contents of the whole page instead of having everything painted using programmatic APIs, which are black boxes to us.
colordrops 11y ago
Currently, custom web components don't have a way to add styling hooks specific to the component, so solutions include hacks to pipe styles into the guts of the web component, or use pre-defined attributes to style the component, just like the late 90s. Perhaps Houdini would provide a way to give custom web components first class css styling.
nine_k 11y ago
Behold the inexorable advance of the Atwood Law. Next step would be having an ability to entirely reprogram the layout engine in newly-performant JS. And then more and more, until we have built an entire OS (again).
- EvanPlaice 11y ago
  See HTML5 canvas. That's what Google Docs switched to so they could guarantee a consistent UI across different browser platforms. For the full OS implementation see NodeOS and Runtime.js. NodeOS is a V8 runtime built on top of a very minimal linux kernel. Runtime.js is a full OS implementation from scratch written entirely in Javascript.

159 points by mattiemass 11y ago

mrec 11y ago

Very 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).

pcwalton 11y ago
> 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.
- mrec 11y ago
  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?
  - pcwalton 11y ago
    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...
  - philipwalton 11y ago
    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.
  - michaelchisari 11y ago
    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.
- madeofpalk 11y ago
  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.
bfgeek 11y ago
Most things should be within the same ballpark. The trouble is at the moment that CSS polyfills are an order of magnitude (or two) off native performance. Example: Current CSS layout polyfills (like grid, regions etc) suffer from this. Where you will see performance improvements is when developers create more expressive layouts/paints/etc. For example you can implement a grid layout with a bunch of nested flexboxes. You could also do it with the CSS Layout API. Because by using the CSS Layout API requires fewer divs, and maybe no N^2 layout passes, chances are it'll be faster. But this really gets at the point of Houdini is to inform browsers/specs what is important. If a grid/masonary polyfill becomes widely used, then it will help inform CSS work.

pcwalton 11y ago

> 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.

ZenoArrow 11y ago
Don't just complain about it on HN, tell the developers directly (via GitHub or otherwise).
- cloverich 11y ago
  A fair point, but pointing out a perceived flaw on Hackernews often leads to good discussion, and is sometimes followed by the authors themselves. I can see both sides of it, but I'd personally like to start it here then carry it over to filing an issue afterwards (if it still feels it has merit).
  - ZenoArrow 11y ago
    Okay, let's start the discussion here. The premise is that the design decisions being made for Houdini now will hold back CSS functionality in the long run. Two questions: 1. What is an example of a new stylesheet feature that couldn't be implemented with Houdini in its current design? 2. Why will the current decisions being made on the Houdini APIs hold back further evolution of these APIs? In other words, why can't we go with a MVP and evolve as required?
    - pcwalton 11y ago
      The Paint API is a poor match for GPUs, so we're going to encourage people to write poorly performing features with the API as designed. The compositing API is overly tailored to existing browser engine details. It's forcing complexity onto Web developers when the problem should be solved at the engine level. Having to do all the compositing logic in a worker is terribly inconvenient anyway. If main thread animations are untenable due to random main thread jank, let's fix that instead of adding difficult-to-use workarounds. We're not doing the Web any favors when competing against native by saying "you can get native performance, but only if you contort your program". An "MVP" that is poorly designed is not an "MVP". There are designs that are flawed due to not having enough features; this is a reasonable candidate for an MVP. But there are also designs that are flawed due to fundamental design problems. Releasing these kinds of designs onto the Web is not releasing an MVP; it's making another mistake.

yugai 11y ago

I think it's not very exciting at all. Browser support for Houdini will be a new issue in the future if they manage to release anything.

debacle 11y ago
XKCD 927.
- kearneyandy 11y ago
  https://xkcd.com/927/ https://xkcd.com/927/ For the lazy

Zardoz84 11y ago

Great! But sadly, I must keep working with IE8 compatibility. Government related clients update at glacial speed...

michaelbuddy 11y ago
Government contractor here on site at somewhat large gov't facility, we're fully updated to IE11 on Win 7 now. Before that, we had a lot of people on IE9. Microsoft support end dates are darn helpful. Kicks people into gear.
- JoblessWonder 11y ago
  Yeah... Microsoft standing firm on support dates and actively encouraging people to upgrade seems to have really made a huge difference. I'm sure it also makes them a pretty penny to maintain support contracts for entities that refuse to upgrade past the official EOL.
  - gtjrossi 11y ago
    Microsoft engineer here. I would assert we want people upgraded more than anybody else on the planet. Our extended support contracts were designed to be cost prohibitive to encourage this point and were nowhere near a money-making venture. The engineering matrix (cost) for a fix across old versions was insane: IE6, 7, 8, 10, 10 touch; 32bit, 64bit, ARM; Windows XP, Vista, 7, 8, Server, Mobile, etc.; 5.5/7/8/9/10 browser document modes; etc. A "single" fix often meant weeks of porting work for engineers after the initial fix was written. Note that the Jan 12, 2016 End of Support date means there are no more security updates, non-security updates, free or paid assisted support options, or online technical content updates. https://support.microsoft.com/en-us/lifecycle#gp/Microsoft-Internet-Explorer https://support.microsoft.com/en-us/lifecycle#gp/Microsoft-I...

wheaties 11y ago

Quick question, what's to stop someone from reimplementing, say "float: right" to also spin up a banner ad? That is, this sounds great in principal but much like Microsoft's Tay taught us, the internet is full of *-holes.

adrusi 11y ago
Well that's already possible now just by reading the CSSOM and patching new things into the DOM like how the article described the current state of affairs. If you just want to shunt another banner ad in there, that's not something that will hurt performance too much.
codingdave 11y ago
I'd expect that anyone who has access to the page/app enough to extend CSS to spin up ads would also have enough access to the app/page to just put ads on it anyway, in much easier ways.
talmand 11y ago
I'm not sure I understand the question. Are you suggesting that someone might use this tech to bypass adblockers by integrating ads into a CSS property? Or is it something else?

debacle 11y ago

Seems like a band-aid for CSS, which needs to go away. Styling the DOM in the fashion we have been for the last 15+ years needs to end. JavaScript has evolved, but we still need to use LESS and SASS and Modernizr and other tools. CSS doesn't need abstractions. It needs to be replaced.

davidkpiano 11y ago
It does not need to be replaced, and it's highly impractical for it to be replaced since it's such a core part of all web browsers that's not going away anytime soon. Are you suggesting we style with JavaScript?
- debacle 11y ago
  Flash was also once a core part of the web browsing experience. CSS is a big warty blob, and a relic of the "semantic web." "Styling with JavaScript" is probably too verbose of a solution, but it's one option.
  - talmand 11y ago
    I'd be curious how styling with Javascript would work. Almost every example I've ever seen of such ideas comes down to actually just writing CSS in Javascript. Which is just silly.
    - debacle 11y ago
      Right. We need a better solution. Actual inheritance would be a good step.
  - pcwalton 11y ago
    And you're going to have much worse performance. CSS is actually not slow for what it does.
  - mindcrime 11y ago
    CSS has almost nothing to do with the semantic web. It has been associated with the use of "semantic markup", but those two things are only weakly related.

romaniv 11y ago

Maybe we should just transpile Flash into ASM.js and be done with it. And yes, I am being sarcastic here. I understand the motivation underpinning such projects, but the approach of introducing yet another complicated API with dubious cross-browser support is not something that will move the web forward in a meaningful way.

msoad 11y ago

What we need is a "strict mode" HTML. Number of APIs available to web platform is getting out of hand. Using ES6 module system we can clean up the web API landscape. Here is the idea: you declare your document to be in strict mode: <!DOCTYPE strict> In this mode you don't have access to any API unless you import it. You need to import CSS layout systems like regular box model or basic APIs like query selector. You also need to import each html element you use. This way browsers don't have to take into account every possible CSS property or html element when doing layout or painting. After we got that, then you can import your own implementation of standard modules that is written using APIs introduced by Houdini Here is an example: import "html/div" import "css/flex" import "dom/query"

pcwalton 11y ago
> After we got that, then you can import your own implementation of standard modules that is written using APIs introduced by Houdini Reinventing the platform using JavaScript in that way is not going to be good for performance. At least right now, until at the very least shared memory multithreading is available. I also want to call attention to this: > This way browsers don't have to take into account every possible CSS property or html element when doing layout or painting. But in order to get good performance we want to take every possible CSS property into account. Performance is about being able to make simplifying assumptions (especially on the GPU, where state changes are costly). We want to make global optimizations based on the contents of the whole page instead of having everything painted using programmatic APIs, which are black boxes to us.

colordrops 11y ago

Currently, custom web components don't have a way to add styling hooks specific to the component, so solutions include hacks to pipe styles into the guts of the web component, or use pre-defined attributes to style the component, just like the late 90s. Perhaps Houdini would provide a way to give custom web components first class css styling.

nine_k 11y ago

Behold the inexorable advance of the Atwood Law. Next step would be having an ability to entirely reprogram the layout engine in newly-performant JS. And then more and more, until we have built an entire OS (again).

EvanPlaice 11y ago
See HTML5 canvas. That's what Google Docs switched to so they could guarantee a consistent UI across different browser platforms. For the full OS implementation see NodeOS and Runtime.js. NodeOS is a V8 runtime built on top of a very minimal linux kernel. Runtime.js is a full OS implementation from scratch written entirely in Javascript.