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.

Good, so you have something concrete to share with the developers before they make that mistake: https://github.com/w3c/css-houdini-drafts

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.