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.
> 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.
> 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.
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.
> 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.
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.
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.
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.
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.
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.
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
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.
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!)
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.
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
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.
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.
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
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..
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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:
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.
139 comments
[ 6.6 ms ] story [ 184 ms ] threadI personally can’t wait for the Layout API, which will allow alternative solutions to compete with the CSS layout mechanisms, without the performance penalty.
Not knowing anything about the velocity of the effort, I look at that and can imagine this being years from general availability.
From my point of view I can start thinking about putting ChromeOS developer instead of Web developer on my skill list.
> 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.
UI is complex? Who knew!
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!
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.
Seems there is for parts of it already
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..
It's 2021 and people still do div and javascript hell to implement these things.
There's even a color picker in native html now.
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.
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.
tl;dr they'll get it in the next patch
[0]https://lion-web.netlify.app/components/interaction/switch/o...
"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.
And? That's what all the "native" web inputs are as well.
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
I wouldn't hold my breath though.
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!)
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...
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.
It's extremely unlikely that most developers will use this directly.
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.
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 :-/
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?
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.
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.
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
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.
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.
And the ecosystem even more so.
I'm asking about the bad parts.
Note that I personally use 100% Typescript.
And if the Web's application layer is not HTML, CSS or Javascript, then what is it?
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 hope in the future something like Gemini takes off, so we can stop stepping on each other's feet.
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..
Hahahahaha, good one!
https://news.ycombinator.com/newsguidelines.html
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.
CSS Houdini is a way to get performance out of complex and custom layout or animations.
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.
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.
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.
Is that the underlying tech being new and slow, or the specific implementations using it on the gallery?
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
Prediction: that “but...” is going to be ignored way too much.
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)
Slowly integrating flexbox and grid in my work but I'm not in a hurry.
https://css-tricks.com/snippets/css/complete-guide-grid/ https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_La...
Still waiting to use it on a commercial project.
https://mattperry.is/writing-code/animation-worklet-4-missin...
Used to implement things like CSS3 rounded corners and other decorations https://github.com/lojjic/PIE