> 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.
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).
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?
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.
I really liked the video last month about webrender, which really looked like the future of rendering web content. It sounds like this Houdini stuff would not work so well with a webrender type infrastructure? That would be a real shame and sounds like short sighted thinking in this proposal.
That's right; Houdini does not work well with WebRender. It's designed for the traditional browser architecture.
The CSS Compositing API is basically creating a separate tiny DOM that runs on its own thread because the main thread is supposedly too slow. (It has event handling and everything!) This is counterproductive in my view: it's just poorly reinventing the DOM we already have. If you want to multithread the rendering engine, multithread the rendering engine. Let's not introduce a new tiny multithreaded part off to the side that badly replicates 1% of the functionality of the DOM; that's not a nice way to treat Web authors.
I suspect that most of the advantage of this API in practice would be that it's a thread for the main content to play in that ads can't get to. Until the ads start using it, and then we're back to square one. If the main thread is getting hogged by ads or whatever, let's fix that problem (perhaps via off main thread iframes and off main thread layout). The Web will always be worse than native unless we fix that, no matter how many hacks we pile on top of it.
1. Not supporting any features that trigger a layout recalculation is a pretty major drawback, I'd say. The complaint I hear most about CSS is that it's actually terrible for layouts, and while flex is a step in the right direction it still has a long way to go.
2. Houdini is specifically proposed to address the issue of browsers not implementing specs quickly enough. Now they'll have yet another spec to implement, and it's intended to "just work" in all the browsers, except it'll depend on what version of the spec the various browsers have implemented, taking us right back to square one.
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.