
Houdini: Maybe the Most Exciting Development in CSS - mattiemass
https://www.smashingmagazine.com/2016/03/houdini-maybe-the-most-exciting-development-in-css-youve-never-heard-of/
======
pcwalton
> 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
Don't just complain about it on HN, tell the developers directly (via GitHub
or otherwise).

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

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

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

------
mrec
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
> 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
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?

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

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

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

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

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

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

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

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

~~~
err4nt
In my work doing frontend web development CSS is the primary language I use. I
don't use Less or SASS, I just write straightforward CSS.

The only limitation I've run up against as far as responsive styling goes was
that @media queries were always scoped to the browser's width/height, and I
figured I could build much more advanced layouts if I had a way of scoping
styles to individual elements. It turns out that's true, I have a plugin that
lets me do this, so between regular CSS and these extra 'element queries' I
have no issue styling anything I want. My plugin works down including IE8, so
there's nowhere I need to write CSS where I can't use it.

I'm not aware of how/why CSS needs to be fixed or replaced, it's a great
solution for what it does.

What do you propose instead of CSS? When you have well written HTML, it takes
surprisingly few CSS declarations to add a good style!

~~~
talmand
Most of the time when I see people complain about CSS it's because either they
don't know how CSS works, or they want it to do something it wasn't designed
to do in the first place.

Most of the time it's because they don't know how it works.

~~~
Bahamut
Lack of ability to nest rules in CSS makes it harder to organize styles. Not
being able to create mixins and such makes all too easy to have to copy-paste
and memorize cross-browser solutions & vendor specific rules for certain
browsers.

In short, there is a lot of inefficiency with the current system that
preprocessors help alleviate.

~~~
err4nt
Why do you need to nest things? The 'C' in CSS stands for 'cascading'.

Don't fear the cascade!

~~~
talmand
Well, it does clean up the code a bit, depending on your point of view. But it
wouldn't necessarily interfere with cascade.

It's just right now, because CSS doesn't support it, that SASS code gets
compiled into large selectors if you aren't careful.

~~~
kolme
It helps a little in the code organization, however, it creates new problems.

It makes deep nested code hard or impossible to reuse. It tightly couples
style and markup, so a change in the latter can break the former, etc.

So while it is a nice feature to have, I'd recommend using it scarcely and
with great care.

~~~
talmand
That's not a problem, that's not understanding how it works.

Any nested SCSS is impossible to reuse outside of its parent scope. If someone
is using nested SCSS and expecting to reuse that code elsewhere then they are
doing it wrong. It's the same problem that exists if one were to create a
class as a child of an ID and then expect to use that class outside of the
ID's scope.

------
yugai
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
XKCD 927.

~~~
kearneyandy
[https://xkcd.com/927/](https://xkcd.com/927/) For the lazy

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

~~~
michaelbuddy
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
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
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-I...](https://support.microsoft.com/en-
us/lifecycle#gp/Microsoft-Internet-Explorer)

