[HN Gopher] CSS Houdini
___________________________________________________________________
CSS Houdini
Author : mvolfik
Score : 200 points
Date : 2021-05-12 16:06 UTC (6 hours ago)
(HTM) web link (developer.mozilla.org)
(TXT) w3m dump (developer.mozilla.org)
| [deleted]
| SirHound wrote:
| 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...
| seumars wrote:
| 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...
| ihuman wrote:
| 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.
| seumars wrote:
| That's the point
| msoad wrote:
| 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.
| ______- wrote:
| 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>
| slver wrote:
| Please, RTFA before commenting next time.
| Zren wrote:
| Heh, a wild Tabs mixed with Spaces appears in the second example.
| dalmo3 wrote:
| Can't wait for css-illusions.com!
| mintone wrote:
| 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.
| snow_mac wrote:
| 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.
| msoad wrote:
| What's super nice about these APIs is that everything is
| happening off the main thread.
| bshimmin wrote:
| I can't wait to do JS-in-CSS-in-JS!
| _Microft wrote:
| ... running in the sandbox of a browser in a VM and getting
| streamed to your local PC from a super-computer in the cloud.
| fallat wrote:
| Aren't we in a _Mighty_ exciting time!
| jrochkind1 wrote:
| 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.
| ihuman wrote:
| 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)
| jrochkind1 wrote:
| 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!)
| junon wrote:
| This seems groundbreaking, honestly. This is only going to help
| bridge desktop and web applications.
| wnevets wrote:
| https://houdini.how/ has some neat examples of what you can do
| with Houdini
| snow_mac wrote:
| From that, https://paintlets.herokuapp.com/ amazing. SO COOL
| erichurkman wrote:
| 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?
| r-k-jo wrote:
| here is a cool example using d3.js to render the earth using
| Houdini https://observablehq.com/@fil/hello-paintworklet
| [deleted]
| zodzedzi wrote:
| 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?
| dragonwriter wrote:
| > 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.
| o_____________o wrote:
| 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)
| qwertox wrote:
| How does one create the layout? By playing a round of Tetris?
| grishka wrote:
| 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.
| sidpatil wrote:
| Everything that's old is new again:
| https://en.wikipedia.org/wiki/JavaScript_Style_Sheets
| yuchi wrote:
| 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...
| macando wrote:
| 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.
| pjmlp wrote:
| Not surprising, given that is yet another API being pushed by
| Chrome.
| croes wrote:
| Bad name to google because of SideFX Houdini.
| bpierre wrote:
| 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.
| Rapzid wrote:
| 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.
| pjmlp wrote:
| 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.
| hexo wrote:
| But, why?
| jrochkind1 wrote:
| 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...
| mst wrote:
| 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.
| d--b wrote:
| My question exactly
| netghost wrote:
| 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.
| ryanwhitney wrote:
| Looks like this would finally allow managing pseudo-classes via
| JavaScript? What a world.
| vagrantJin wrote:
| 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.
| afavour wrote:
| > Sounds like a lot of work to display a bloody list.
|
| UI is complex? Who knew!
| dheera wrote:
| 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.
| dmitriid wrote:
| There's now an attempt being made to start an exploration
| into this: https://open-ui.org
|
| I wouldn't hold my breath though.
| city41 wrote:
| 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.
| Guest19023892 wrote:
| 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.
| city41 wrote:
| 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.
| dheera wrote:
| 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.
| sabellito wrote:
| 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.
| dheera wrote:
| Maybe they could just start by providing all the Android
| layout XML components as native in HTML6?
| spockz wrote:
| 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...
| dheera wrote:
| 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.
| madeofpalk wrote:
| > but under the hood they are div hell and css hell.
|
| And? That's what all the "native" web inputs are as well.
| [deleted]
| no_wizard wrote:
| 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
| smhmd wrote:
| https://www.youtube.com/watch?v=1W79T2ibd5Y
| croes wrote:
| Sounds like possible security and privacy nightmare for users
| jrochkind1 wrote:
| If <ul> meets the needs of your application, there's no reason
| you'd have to do more work than that.
| brianzelip wrote:
| Masonry is a <ul>.
| madeofpalk wrote:
| 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!
| Rapzid wrote:
| > 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..
| holtalanm wrote:
| > 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.
| the_other wrote:
| Will there be a JS polyfill for Houdini?
| akiselev wrote:
| 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.
| maxov wrote:
| 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.
| bayesian_horse wrote:
| 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.
| maxov wrote:
| 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.
| silon42 wrote:
| Sometimes I find that disabling CSS in umatrix in addition to
| Javascript improves the site...
| [deleted]
| etaioinshrdlu wrote:
| 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?)
| ihuman wrote:
| Chrome already supports some of it
| https://ishoudinireadyyet.com/
| n0us wrote:
| But when can we extend JavaScript with CSS?
| inopinatus wrote:
| When we finally accept that the experiment with non-Turing-
| complete layout has failed, and bring back DSSSL.
| axiosgunnar wrote:
| 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.
| croes wrote:
| 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
| axiosgunnar wrote:
| 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?
| croes wrote:
| 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 Durrenmatt?
| croes wrote:
| 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.
| dang wrote:
| " _Please don 't sneer, including at the rest of the
| community._"
|
| https://news.ycombinator.com/newsguidelines.html
| NikolaNovak wrote:
| 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
| :-/
| axiosgunnar wrote:
| 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?
| joshum97 wrote:
| 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.
| moshmosh wrote:
| 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.
| dragonwriter wrote:
| > 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.
| axiosgunnar wrote:
| 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?
| moshmosh wrote:
| 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.
| matsemann wrote:
| 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.
| austincheney wrote:
| 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?
| kodah wrote:
| > 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.
| austincheney wrote:
| You are misusing the word simple. _Simple_ means fewer,
| which is quite different from _easy_ which means low
| effort, straight forward, or less learning.
| kodah wrote:
| 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.
| no_wizard wrote:
| 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
| no_wizard wrote:
| 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...
| smichel17 wrote:
| 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.
| Rapzid wrote:
| 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..
| arghwhat wrote:
| > Nevermind that humanity has experienced a quantum leap in
| productivity
|
| Hahahahaha, good one!
| jrochkind1 wrote:
| That's not even really what Houdini is about, it's not true
| that "CSS has become javascript".
| tankenmate wrote:
| JavaScript is built on some very good ideas and a few very bad
| ones. -- Douglas Crockford
|
| And the ecosystem even more so.
| slver wrote:
| I'm curious which are the bad ones.
| noman-land wrote:
| You're in luck cuz he wrote a whole book about it called
| JavaScript: The Good Parts. It's a good read.
| slver wrote:
| But I don't care about the good parts.
|
| I'm asking about the bad parts.
| noman-land wrote:
| 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.
| globular-toast wrote:
| 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.
| axiosgunnar wrote:
| 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.
| axiosgunnar wrote:
| 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.
| [deleted]
| dang wrote:
| 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)
___________________________________________________________________
(page generated 2021-05-12 23:00 UTC)