CSS Houdini | Hacker News Reader

CSS Houdini

developer.mozilla.org

315 pointsmvolfik134 comments

> With Houdini you could invent your own masonry, grid, or regions implementation, but doing so is not necessarily the best idea.

Prediction: that “but...” is going to be ignored way too much.

On that note, masonry layout is finally coming to CSS:

https://drafts.csswg.org/css-grid-3/

https://github.com/w3c/csswg-drafts/issues/4650

(Think Pinterest layout with ltr ordering, which is extremely problematic in pure CSS)

How does one create the layout? By playing a round of Tetris?

Yes but the down button is stuck so you can only go left or right and only a little bit.

I think the css grid got too complicated to fit in my brain. I mean not just the usage and the details, that ship has sailed a long time ago anyway. These days, I can't keep in my mind even what it is capable of and how to approach my layout problems. Perhaps embarrassing for a web developer of my experience, or maybe we really need better tools (not just standards!) for layout.

I still use float and positioning, it works fine.

Slowly integrating flexbox and grid in my work but I'm not in a hurry.

Personally, I find it easy to use (definitely more predictable for me than flexbox). Grid layout is pretty straightforward and it is easy to understand what to expect. For complicated layouts you can just use the grid-template-areas, so you have a visual representation of your grid in your css directly.

https://css-tricks.com/snippets/css/complete-guide-grid/ https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_La...

I was already contemplating how I'll use these APIs to make Android's three layouts (LinearLayout, FrameLayout, RelativeLayout) to finally stop fighting with the browser to get it to put things where I want them.

CSS is too powerful. It gives people the ability to intentionally create ugly web pages, with unappealing colors and fonts, and layouts I don’t like.

The synchronicity of this showing up on the HN front page at the same time as Google moving Docs to canvas-based rendering (https://news.ycombinator.com/item?id=27129858) is kind of funny.

More seriously, this looks really cool, and I do actually wonder if it could ease some of the problems Google is looking to solve by using canvas-based rendering, although I'm not super familiar with the challenges of rich-text editing. It would be much more preferable for me (and I think for most developers and users) if web apps still used the DOM to render text boxes, and you could hook into the rendering and layout engine for more complex operations. The layout and painting hooks offered by Houdini seem very useful for this.

The one issue is I'm not sure how text selection works here - the order of elements in selection is already kind of obtuse for more complicated layouts, and this adds even more configurations. I don't know if the APIs offer some sort of ability to control the order of selection or if that's somehow a feature of the box model.

In Google Docs they value consistency of the rendering output over performance, while complex documents might even see some performance benefits.

CSS Houdini is a way to get performance out of complex and custom layout or animations.

I might be misinterpreting, but are you saying the two are mutually exclusive? Google Docs does need custom layout and rendering which may be tough/finicky to implement with the existing css layout, as well as consistency.

Why do you assume canvas will have bad performance? Sheets moved to canvas from HTML, and got a massive perf boost.

It's not totally mutually exclusive. But canvas operations aren't hardware accelerated, and rendering of HTML potentially is.

It's still possible to make the DOM complicated enough that moving to canvas has performance advantages. I don't know the details, but I'm guessing that is achieved by skipping updates the browser would usually make.

Webgl is tho. But even in 2d context api, you have bigger control over how your content is being printed than in html. Which means that a lot of operations that DOM performs unnecessarily in the context of Google docs can be simply discarded.

Yes, which is why in general, DOM rendering is faster, while in special cases, with a lot of manual optimization, canvas rendering is more performant.

My guess is that this comes down to browser support. A canvas based solution probably has pretty wide support today while these new CSS features will be subject to the long tail of browser versions.

Some past threads:

CSS Houdini Experiments - https://news.ycombinator.com/item?id=21628921 - Nov 2019 (14 comments)

CSS Houdini Interactive Introduction - https://news.ycombinator.com/item?id=20548183 - July 2019 (28 comments)

Houdini: Maybe the Most Exciting Development in CSS - https://news.ycombinator.com/item?id=11357794 - March 2016 (62 comments)

Houdini and the Extensible Web - https://news.ycombinator.com/item?id=9533423 - May 2015 (1 comment)

https://houdini.how/ has some neat examples of what you can do with Houdini

From that, https://paintlets.herokuapp.com/ amazing. SO COOL

Scrolling on that page is incredibly janky (Chrome/mac).

Is that the underlying tech being new and slow, or the specific implementations using it on the gallery?

here is a cool example using d3.js to render the earth using Houdini https://observablehq.com/@fil/hello-paintworklet

I created a Fractal Demo using Houdini that is featured on houdini.how:

https://github.com/ConradSollitt/css-houdini-fractals

It's similar to rendering with canvas. houdini.how is a Chrome Labs Site from Google and allows authors to submit demos. I would recommend creating a demo on it for any developer that wants to try Houdini.

https://github.com/GoogleChromeLabs/houdini.how

I feel like I work on a different web.

> Note: With great power comes great responsibility! With Houdini you could invent your own masonry, grid, or regions implementation, but doing so is not necessarily the best idea. The CSS Working group does a lot of work to ensure every feature is performant, handles all edge cases, and considers security, privacy, and accessibility.

Sounds like a lot of work to display a bloody list.

https://www.youtube.com/watch?v=1W79T2ibd5Y

Sounds like possible security and privacy nightmare for users

> Sounds like a lot of work to display a bloody list.

UI is complex? Who knew!

If <ul> meets the needs of your application, there's no reason you'd have to do more work than that.

Masonry is a <ul>.

My understanding is that these Houdini features are aimed more at big library/framework authors. It's not for "every day users".

It's more expected that you'll use things that use Houdini under the hood as an implementation detail.

A new layout mode (like CSS Grid) isn't available yet? This allows someone to write a polyfill for it. That's neat!

> A new layout mode (like CSS Grid) isn't available yet? This allows someone to write a polyfill for it. That's neat!

this was my first thought, too. We have polyfills for js features that don't yet exist in a lot of browsers, but polyfills for css are either very complicated or just don't exist in some cases.

Will there be a JS polyfill for Houdini?

Probably not a practical one, for the same reasons that discourage CSS polyfills. I think this feature is aimed not at developers who have to support legacy browsers but those who want to use newer CSS standards in self updating browsers without having to wait for the laggards. Safari is (was?) often criticized for being very slow to implement adopted CSS standards so that might have been the impetus. Once Houdini Paint/Layout/Animation APIs lands and enough clients update, devs can switch to Houdini and use any new/experimental CSS standards that has an open source implementation.

https://github.com/GoogleChromeLabs/css-paint-polyfill

Seems there is for parts of it already

> A new layout mode (like CSS Grid) isn't available yet? This allows someone to write a polyfill for it. That's neat!

Hopefully this won't be used as an excuse for new standards proposals to never move forward and/or browser teams to slow-roll implementing new standards natively..

I constantly wonder why so much work on CSS and absolutely zero work on implementing basic primitives like <input type="slider" min="0" max="1000" step="10"> and <input type="toggle"> and <tabviewpager><tab></tab><tab></tab></tabviewpager> and <input pinchzoom="true" src="foo.jpg"> and other utterly basic UI elements with full support for swipe gestures.

It's 2021 and people still do div and javascript hell to implement these things.

There are primitives like that, such as https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

There's even a color picker in native html now.

Oh cool! maybe they are finally getting with the beat.

What about spinners, pull to refresh and other things ... would be nice to standardize all of these such that they display with your system's native widgets. The code for those CSS spinners is horrifying spaghetti code whereas I should be able to just do <spinner> and get an Android native spinner on Android and an iOS native spinner on iOS.

input types like range were introduced in 2014, here's a tutorial from then: https://css-tricks.com/datalists-different-input-types/

I think I get the point you're trying to make, and I find it difficult that someone could make a list of all the things that "should be in by default" vs providing the building blocks.

Maybe they could just start by providing all the Android layout XML components as native in HTML6?

your response suggests that you think that the list needs to be 100% consistent with the shape of reality at all times, but the reality of it is that standards are fluid things and they are developed and honed iteratively in response to the pressures that gave rise to their existence in the first place. it's less about trying to make sure to accommodate every last possibility, and more about making sure to provide a reasonably fundamental and useful set of resources that can be used in union to build the more complex ones. the map of absolute choices is not the terrain of contextual variation and nuance, and there's no reason to ever expect a 100% concordance because a 1:1 map is basically equivalent to directly experiencing noumena and seeing past qualia, and that's just not usually a thing that is, by definition, directly apprehended, but rather indirectly inferred from the phenomena that result from interpreting it.

tl;dr they'll get it in the next patch

Most of these inputs are very limited though. For example, range only allows one handle, so it doesn't work in most instances. For example, you might want a slider for a range of prices ($10-20), sizes (TVs that are 32-40"), or dates (products released between 2010-2013). It doesn't work in these situations, which is disappointing because they seem like the most basic use cases.

It's a start at least. And I also find hardly anyone ever uses them because they want their UI to match. I still like that I can quickly whip up form validation and some controls with just html.

Have you seen lion[0]? It is a stylable/white label set of web components. It also has a switch/toggle.

[0]https://lion-web.netlify.app/components/interaction/switch/o...

Yeah, I mean there are lots of web components out there, but under the hood they are div hell and css hell.

"npm i --save @lion/input-amount"

This isn't directed at you, but I shouldn't have to use npm to build a webpage. Also, building web components out of css/div hell severely impacts performance when you have a long scrollable list of them.

And most of these web components might look nice but they don't support native touch/swipe gestures in exactly the same way that the OS does.

I tried the Lion tabs component on my phone and I can't swipe between tabs. Probably the most utterly basic UI gesture. Fail.

> but under the hood they are div hell and css hell.

And? That's what all the "native" web inputs are as well.

It’s not, and hasn’t been since at least ES6 and the engine normalization’s that came with that leap (DOM APIs got normalized in that transition across browsers)

Web components is one way to add re-usable functionality naked into modern browsers. There is also a slew of new elements nobody seems to use for no good reason like: picture, figure, section, article, main, header, footer, the new input types, details and I’m sure I’m missing more.

Why does this industry think it’s okay to just be well educated with JS but doesn’t care that developers also know CSS and HTML just as well, I’ll never know

There's now an attempt being made to start an exploration into this: https://open-ui.org

I wouldn't hold my breath though.

Implementation status of the different APIs: https://ishoudinireadyyet.com/

I personally can’t wait for the Layout API, which will allow alternative solutions to compete with the CSS layout mechanisms, without the performance penalty.

Under consideration with FireFox and only a couple in dev with Safari..

Not knowing anything about the velocity of the effort, I look at that and can imagine this being years from general availability.

Depends pretty much how Firefox keeps being relevant, and how Safari or iOS are relevant to customer base in some countries.

From my point of view I can start thinking about putting ChromeOS developer instead of Web developer on my skill list.

Everything that's old is new again: https://en.wikipedia.org/wiki/JavaScript_Style_Sheets

It was also new some time ago with Internet Explorer https://stackoverflow.com/questions/26339276/what-is-behavio...

Used to implement things like CSS3 rounded corners and other decorations https://github.com/lojjic/PIE

What's super nice about these APIs is that everything is happening off the main thread.

I can't wait to do JS-in-CSS-in-JS!

... running in the sandbox of a browser in a VM and getting streamed to your local PC from a super-computer in the cloud.

Aren't we in a Mighty exciting time!

The Houdini APIs are not really about "JS in CSS". They are about extending CSS features (like adding new features to CSS, new keywords or what have you) by providing a JS implementation at runtime.

But you can use it to write JS in CSS and then eval it (although you probably shouldn't) https://css-houdini.rocks/js-in-css (only works in Chrome)

OK, good point! And neat demo, thanks! I guess if you can add features to CSS, you can add a feature to have evaluatable JS! And that is a pretty neat demo.

It is not the main targeted use case of Houdini though! (And I'm gonna go out on a limb and say the Houdini devs would say it's a bad idea as more than a cool toy!)

Looks like this would finally allow managing pseudo-classes via JavaScript? What a world.

I've heard about Houdini 3 years ago and am really surprised it hasn't taken off and became mainstream yet.

Still waiting to use it on a commercial project.

Not surprising, given that is yet another API being pushed by Chrome.

To be clear, it looks like this is on a standards track and going to be implemented natively by browsers? (and already is behind feature flags?)

Chrome already supports some of it https://ishoudinireadyyet.com/

Certainly some of these APIs look to offer extensibility but the Animation Worklet as it currently stands doesn’t come close to offering the kind of extensibility you’d expect in this area:

https://mattperry.is/writing-code/animation-worklet-4-missin...

Copying from another thread:

Houdini seems mostly abandoned. The feature page [1] lists multiple sub-proposals that have "No signal" even from the Chrome team. All mentions of Houdini I can find on developers.google.com are from 2018. I can't find anything about Houdini integration with WebAssembly, which is what I'd expect if development was ongoing.

Overall, I'm seeing everything I would expect to see in the timeline where Mozilla has no intention of ever implementing Houdini, and Google has decided it's not worth pursuing beyond what's already implemented.

[1]: https://ishoudinireadyyet.com/

I love this evolution and would have been a lifesaver 10 years ago. Currently, not so groundbreaking but still interesting.

What I really don’t understand is why they still insist on global namespace polluting APIs. It was ok-ish with CSS Animations’ names, it broke any real project with custom elements (want to have 2 different versions of the same element? Good luck) and then this…

They really don’t care about actual folks trying to incrementally upgrade applications or developing composite applications. All of this requires a level of coordination that is prohibitive to have in enough complex projects…

Odi ed amo…

> Catullus 85 is a poem by the Roman poet Catullus for his lover Lesbia.

> Ōdī et amō. Quārē id faciam fortasse requīris.

> Nesciŏ, sed fierī sentiō et excrucior.

> I hate and I love. Why I do this, perhaps you ask.

> I know not, but I feel it happening and I am tortured.

This is really cool. I like the random background example or the ripple effect example in the video tutorial. I bet someone will compose a library of effects leveraging Houdini that will allow UI developers to greatly enhance their UI.

Things that we could only really do in Flash, like cool animations with transitions could become even more possible and easier to build with Houdini.

The table rounding is a really cool idea. I could see us combining a bunch of concepts to build really fast and performant designs that are cutting edge.

But, why?

My question exactly

This lets you provide an implementation for a CSS feature that is perhaps not yet implemented by browsers, or maybe never will be.

You could always do this with Javascript, and some people have been. See: https://philipwalton.github.io/polyfill/

But this lets you do it in a less hacky, and especially, more performant way.

The author of that JS CSS polyfill library above actually wrote in 2016 how that approach was proving a bad idea, and the right way to do this was the houdini API... I guess we've been waiting for it since 2016? This is the first I had heard of it. https://philipwalton.com/articles/the-dark-side-of-polyfilli...

Plus, something people often forget is that the features required to polyfill and the features required to produce a proof-of-concept/prototype are really quite similar.

Enabling JS devs to experiment with things up front before they go to the standards track and the effort of full browser implementations will have a lot of cool advantages, I hope.

So that you can implement new layout algorithms, gradient generation and such in user space.

It's extremely unlikely that most developers will use this directly.

why use uppercase?

I found this repo on github which have a list of haudini resources. https://github.com/CSSHoudini/awesome-css-houdini

So if I disable javascript by default for websites (say, in uBlock Origin), but I don't disable CSS, will there now still be unrestricted javascript allowed to run under the guise of CSS?

Definitely not unrestricted, but it won't run in the first place and you'll end up with a broken page. You need to first load the worklets from JS that runs in the context of the page itself.

Thanks, that was helpful.

But when can we extend JavaScript with CSS?

When we finally accept that the experiment with non-Turing-complete layout has failed, and bring back DSSSL.

Can't wait for css-illusions.com!

Hey dalmo3. You replied to a question I asked a while ago but I can't reply directly to you there. (https://news.ycombinator.com/item?id=24486487). Thank you for that reply. I solved exactly what you asked for. My email is in my profile if you want to know more.

Oh wow that's great! Looks like it ticks all boxes, and more. Really wish you succeed in making the web a better place.

I'd love to try the platform from a consumer standpoint, though - maybe add a demo page? I'm not a creator, so not sure about signing up for that free trial.

Do the transcripts go well with (instrumental) music? It'd be great to have this for the online bass lessons I just started. :D

lmao

This seems groundbreaking, honestly. This is only going to help bridge desktop and web applications.

Sometimes I find that disabling CSS in umatrix in addition to Javascript improves the site...

Heh, a wild Tabs mixed with Spaces appears in the second example.

Bad name to google because of SideFX Houdini.

It isn't a product, it's the name of an API.

Doesn't matter if you try to google something. You will get lots of results for SideFX Houdini and the other way around.

100% agree, getting real tired of all this name reuse

especially in situations like this where both are vaguely graphics related

But does this only work with FireFox? If so, the web is splintering again.

Everybody get prepared for the predictable onslaught of Hackernews purists who are all about to faint after reading that CSS has become the next prey of the devil - Javascript.

Nevermind that humanity has experienced a quantum leap in productivity and e-commerce that has given generations of entrepreneurs wealth and every consumer on the planet unprecedented quality of life thanks to the Web, and that Web being made possible precisely because the developer-friendly, move fast and break things route that Javascript has taken from day one.

But because there is a new Javascript framework coming out every day (I'm surprised competition is seen in a negative light, on HN out of all places), because it's easy to learn (and we all like to gatekeep a bit, don't we?) and because it's not a "real" language (since you cannot shoot yourself in the foot with a use-after-free), Javascript has become the prime target of ivory tower grumbling.

I think I agree with most things except easy to learn... Every time I want to get back into programming, the complexity of javascriot frameworks, the infinite variety of ephemeral choices, bounces me right out.

Of all programming languages now and past, javascript as it is used today (as opposed plain language) would not be my first choice for "easy to learn". I feel there's huge effective gatekeeping with it but that's just an outsiders perspective :-/

I choose to ignore the frameworks for that very reason. This line of thought makes me far less employable but then why would I want to work a job I hate only to drown in weak unnecessary abstractions and all the defects and poor scale that come from that?

I agree that frameworks might be a challenge. I would consider learning full-blown frameworks (e.g. React) pretty much like learning a new language, especially since JSX is a new syntax (albeit it's pretty much HTML).

Regarding React, I consider the "hooks" coding style to be INCREDIBLY ergonomic and have been wondering sometimes if React-like "hooks" could be used elsewhere, esp in other programming languages. Or does that only make sense with UIs?

I think React hooks would fit nicely anywhere you need incremental computation, and a compiler is the first thing that comes to mind. They’re made for efficiently updating the output (DOM) in response to small changes in the input (sum of past user actions). If you can format your problem like that, based on a component structure, a similar API might be a good fit.

Hooks are class-declaration except your properties and methods are read FIFO in declaration order, rather than by a lookup table. Unless you really like the FIFO part of it, OO languages all have that already.

But what I meant that I liked about hooks is the "automatic rerender" in React, the reason this feature is called "hooks". I'm not sure simply declaring a method on a class would be the same?

If you operate under the same restrictions as React (single-threaded, you must call a setter method to modify properties rather than accessing them directly, code outside your class is responsible for deciding whether to call its "render" method) then yes, it's the same. Change any of those and it gets harder in basically the same way it would for Hooks if any of those changed.

> Hooks are class-declaration except your properties and methods are read FIFO in declaration order, rather than by a lookup table.

React Hooks are equivalent to React class components all of whose state management is done through setState, but with the difference you describe. Personally, I find hooks more natural than classes whose state management is done exclusively through setState, but that’s obviously a big YMMV.

> I think I agree with most things except easy to learn... Every time I want to get back into programming, the complexity of javascriot frameworks, the infinite variety of ephemeral choices, bounces me right out.

The Javascript ecosystem is dismal. It's very disparate and there's a million ways to do one simple task, compounding that is that things that sound like simple tasks, like rendering a page, are actually not.

If you want a place to start, where the ecosystem is fairly beginner friendly and consolidated, checkout Vue and Nuxt.js. I recently explored every possible frontend for Go that I could find: desktop, web, or otherwise. The fact is that HTML, JS, and CSS still produce the best experience for the end user. Vue and Nuxt made it really easy to produce a hybrid Server Side Rendered and Client Side Rendered (aka Universal) app with still a significant amount of effort, but with that effort directly improving my UI rather than my build environment or configuration.

I think this is true when you just constantly reach for frameworks.

It’s fine to do so, but knowing the core primitives of the language and the DOM can get you very far without having to reach into a bucket of libraries from npm.

As for bundling, there was and will always be tools, people like to think it was just throwing script tags onto a page before npm and the modern packaging ecosystem happened but that’s not really true. At the heigh of jQuerys popularity there were (and are) entire CDNs devoted to serving it and its plugins (which many evolved to serve all kinds of different pre-packed JS bundles) as was a myriad of concatenation tools that even pre-existed before nodejs

I remember namespacing and dynamic loading tools too. I can’t remember their names anymore but this is not a new thing.

It’s always been volume and choice. It’s much bigger today than it was back then but it’s always been this way as far as I can remember

You are misusing the word simple. Simple means fewer, which is quite different from easy which means low effort, straight forward, or less learning.

I definitely meant simple. To the average newcomer to Javascript, what they're familiar with is server side rendering. An HTML page is sent from the server, the markup is rendered, and bam - a page.

Now, go tell this newcomer that you don't actually need a server to serve multiple web pages, it can just serve one! Client side rendering with a client side router is a pretty far departure from what even experienced programmers know about the world.

Now, go tell this newcomer that you can absolutely still render components from the server without redrawing the whole page. They'll enjoy this until they run into the limits and constructs of SSR. Again, a pretty far departure from send a whole page.

Now, go tell this newcomer you can do both at once, and that often it's beneficial to do so. You have taken what was a very simple task and made it quite complex.

It's nothing compared to Python, I feel. I'm trying to get up to date there now, and just this week two different runtimes were announced. There are X different projects for type checking. Django isn't hot anymore, so there's now all kinds of smaller libraries to piece together instead. To get going you have to start messing with pyenv (not to be confused with pyvenv which is deprecated), venvs etc. The official tutorials leave much to be desired, lots of newer language features aren't even mentioned, and the docs act like a reference (which is understandable) but a bad learning tool, if you're lucky and not just being pointed to a technical PEP. Like, I know it has a syntax for decorators, but the only mention of that in the official docs I stumbled upon was the syntax definition of the language.

Of all languages I've had to learn in my professional career, Python has been the hardest. Not because it's a hard language, but because I have to hunt for what to actually learn.

That's not even really what Houdini is about, it's not true that "CSS has become javascript".

JavaScript is built on some very good ideas and a few very bad ones. -- Douglas Crockford

And the ecosystem even more so.

I’m curious which are the bad ones.

You're in luck cuz he wrote a whole book about it called JavaScript: The Good Parts. It's a good read.

But I don't care about the good parts.

I'm asking about the bad parts.

I guess I should have been more clear that he talks about the bad parts in the book in order to tell you what not to do.

I find automatic type coercion to be the worst one. Everything else is fine.

Javascript's combination of default global scoping and automatic instantiation of variables is another bug bear. It's too easy to unintentionally shadow a variable or in combination with automatic type coercion get bugs that are really hard to track down.

What does javascript have to do with e-commerce? It's not even an essential part of the web. I used noscript for years and only stopped because developers got lazy and stopped doing things properly. Unprecedented quality of life thanks to javascript? Get a grip. It's not even an easy language to learn.

Unprecedented quality of life leaps were possible because of 100% user experience focused websites. The user wants popup menus and other interactive elements, they are objectively, measurably better (check out any UX research website). And Javascript is the way to enable all of that functionality.

To explain it differently: UX is all about minor details that can be the entire difference between a github repo with one star from a buddy and an IPO with fuck you money for everyone involved. So things like "why does the website have to reload completely" are a no-brainer, Javascript is a must.

Note that I personally use 100% Typescript.

A quantum leap has only very minor effects. Yes we are producing more but are we really productive? And last but not least, the web had positive and negative effects but the web isn't html, css or JavaScript

This is like saying "electricity also had negative effects because it's used for meme-y things like Christmas tree lightning or controversial stuff like Bitcoin mining". Yeah, fine, but literally our entire modern way of life is based on electricity. I wouldn't go as far as saying our entire way of life is based on the Web, but the Web definitely plays a huge role. Even if you want to ignore the Web personally, if you go out to buy bread, the bakery probably ordered the inventory via a website, so thanks to the Web.

And if the Web's application layer is not HTML, CSS or Javascript, then what is it?

The negative side effects of our technology including electricity led to environmental pollution, species extinction and climate change. How this will turn out for mankind is not certain. This could just be the calm before the storm for mankind. And the greatest benefit of the web is not at the user level, but below. Control and measurement signals do not need HTML, TCP and UDP are sufficient. All the APIs also deliver mainly text in the form of Json and the like. Apart from that, the technology may have improved for developers, but as a user the web pages were faster, slimmer, more informative 10-15 years ago. Today there is a lot of click bait and dark patterns. If you are looking for information off the mainstream ( I don't mean news but technical information) the data is mostly hard to find. Much is also simply gone because the links are dead, without Archive.org it would be even worse. "The net doesn't forget"? Bullshit. It forgets many things, but it remembers concert pictures of Beyonce.

And don't forget, this whole web paved the path for mass surveillance. "Your Scientists Were So Preoccupied With Whether Or Not They Could, They Didn’t Stop To Think If They Should". This is also true for developers. Have you ever read The Physicists by Friedrich Dürrenmatt?

Houdini is amazing, especially because it does all its work in worklets (not the main thread)

To that I say: Houdini isn’t the enemy here. Some gripes about performance will be had for bad implementations but at the core CSS is still the foundation.

My core problem is that progressive enhancement or graceful degradation[0]

This of course is a symptom of bad industry practice and bad developer habits, that’s where I have a serious issue with our industry.

Houdini though? It’s the right technology for the job IMO

[0]: https://www.w3.org/wiki/Graceful_degradation_versus_progress...

I don't mind JavaScript and the expanding functionality of browsers. I do mind that there is no clear separation of "web site" and "web app". When it comes to the later, these new apis are great. But when web sites (ie, primarily documents) start using these features, as a user I feel they almost always make my experience worse.

I hope in the future something like Gemini takes off, so we can stop stepping on each other's feet.

Terrible websites have always existed though. Maybe now there will be new ways to make bad sites, but I can't imagine on the whole the experience of the web will get worse..

People will just not visit sites with a bad experience if they have alternatives. Market forces and all that.

This will likely be a headache for developers more than a problem for end users..

> Nevermind that humanity has experienced a quantum leap in productivity

Hahahahaha, good one!

"Please don't sneer, including at the rest of the community."

https://news.ycombinator.com/newsguidelines.html

I have always striven to insulate decoration (CSS) from functionality (JS). Now the two have blended and we end up with madness like:

    <script>.element{color:red}</script>

Please, RTFA before commenting next time.

I thought writing css in camel case and dealing with media queries in css-in-js was bad enough, but the boilerplate the CSS Paint API introduces just to access variables is absolutely atrocious:

  <style>
    textarea {
      --checkerboard-spacing: 10;
      --checkerboard-size: 32;
      background-image: paint(checkerboard);
    }
  </style>

  <script>
    CSS.paintWorklet.addModule('checkerboard.js');
  </script>

  // checkerboard.js
  class CheckerboardPainter {
    paint(ctx, geom, properties) {
      const size = parseInt(properties.get('--checkerboard-size').toString());
    }
  }

  registerPaint('checkerboard', CheckerboardPainter);

More escape acts here: https://developers.google.com/web/updates/2018/01/paintapi#p...

The proper way to read the value is actually a bit more code that `parseInt`. You should be using the Parser API's `CSSNumericValue.parse`.

Realistically these are things that can make look nice by utility functions.

The value of being able to paint using Canvas APIs off the main thread for super custom components is really high. In all other platforms like iOS and Qt you can take over painting if you want to. It's nice that we will be able to do this in web too.

For that example, you can drop the toString(), because it's already a string. I think it's a string by default because that css variable is untyped. You can define the type with @property in css, or CSS.registerProperty in Javascript. Then you just need to call properties.get('--checkerboard-size').value, and drop the parseInt. Unfortunately, this solution also adds more boilerplate.

That’s the point

Reply on news.ycombinator.com