Refraction is not as expensive as people would led you to believe. That said, this demo is ran at a very low resolution. Probably because it doesn't take devicePixelRatio into account. On my phone that's 3.5 so more than 12 times less pixels than would be required if you want crisp UI.
I see where you're coming from, but "on a phone" hasn't been a valid qualifier for performance benchmarks for a long time. Phones and their GPUs are ridiculously powerful nowadays. We've been smoothly running 3D apps on GPUs with orders of magnitude less MFLOPS 20 years ago already. Apps and games with far more going on than blurry glassy alarm clock, albeit somewhat less beautiful. When I run Fluid Glass on a 10 year old laptop with an integrated GPU and move my cursor, I'm seeing less than 10 FPS. When will we finally start readjusting our expectations for "fast" software and stop blindly following Wirths law?
Partly because phones have smaller screen sizes. When I reduce the the browser window size the FPS improves. For full widow mode it's a bit lagging for me.
I noticed this pattern that a page with some text and images is often too demanding for my phone: it becomes impossible to scroll the page smoothly. We simply do not have the technology yet to handle text and images in a consistent way! But anything involving 3D graphics (or 4K video) will run just fine.
> We simply do not have the technology yet to handle text and images in a consistent way!
We actually have plenty of algorithms for laying out text and images very quickly. You can see this when scrolling complex PDFs or sizable books on e.g. Apple devices. Even a complex web page can be very responsive if it makes smart use of JS and async calls, etc.
Perhaps what you mean is that the complexity of current web apps running on browsers that handle arbitrary layout, computation (JS, WebAssembly), async calls (e.g. analytics), etc can be laggy on certain mobile devices? If so, yes. There are many possible culprits so to speak that lead to low frame rates.
I would phrase it this way: the combination of advertising interests, compute power, and economics have led us to a place where lots of people face laggy interfaces.
Overall, this isn’t a “technological” problem: think of technology as a set of constraints. People and their desires lead to various “design” decisions (some more evolved than designed).
See also Wirth’s Law. I don’t think it is particularly insightful, however. These kinds of laws feel more like the ironic complaints of an ennui fueled graybeard than attempts to make proactive change. From Wikipedia:
> Wirth's law is an adage on computer performance which states that software is getting slower more rapidly than hardware is becoming faster.
> The adage is named after Niklaus Wirth, a computer scientist who discussed it in his 1995 article "A Plea for Lean Software".
Note that some malicious and misguided right wingers are attacking and trying to subvert Wikipedia.
I’ll never understand this sentiment expressed online that Liquid Glass is bad design.
After reading how awful it is on HN, I upgraded to see it for myself. After some pondering it was obvious why Apple went with this design.
Today’s apps’ problem is every app has its own UI language, and users have to first learn that before being able to use an app. Apple recognized this. If you can’t see why it’s a problem, try to teach your mom or grandma how to use a new app.
To design a unified UI framework, you need a lot of things: common elements (e.g. date picker), typography (fonts, text styling), iconography (the same icon in every app for the Share button), etc. Both Apple annd Android vendors already have UI frameworks dictating these for native apps today.
The hard problem that remained unsolved until Liquid Glass is these UI toolkits can’t dictate a color for interactive elements, because every other app has its own, different color scheme. Any color you pick will inevitably look out of place in some apps. The answer here is, unsurprisingly, transparent elements.
But there is historically a huge issue with transparent elements, a hard problem where many previous attempts have failed: how can you make a transparent element (e.g a button) still be recognizable on various content?
Apple’s answer here works beautifully: make the controls appear floating an inch over the content, by mimicking the properties of the two most familiar physical transparent objects - water and glass.
“Today’s apps’ problem is every app has its own UI language, and users have to first learn that before being able to use an app.”
Liquid Glass is far from the first attempt at this. See “material design”. Apple has had UI guidelines for years now, and all of their apps were more or less as consistent as they are now after the transition. My complaint is that shiny effects aren’t necessary for UI consistency, and it slows older devices and consumes their already degraded battery capacity even faster. At least you can “reduce transparency”, but it actually makes the UI looks less transparent than it was before.
However, my biggest complaint is how half-baked it is. iOS 26 is riddled with bugs. As an example that is ridiculously easy to reproduce:
1) Enable “reduce transparency” in accessibility.
2) Open the Files app to any directory.
3) Enable dark mode. Congratulations, the directory name at the top of the screen is now illegible due to black text on a black background. The same bug is also present in Freeform, except it also makes the status bar illegible. They removed the backing UI element without refactoring the text, and nobody noticed. And unless they didn’t mention it in the release notes, it looks like they still haven’t fixed this in the 26.1 beta.
I never said Liquid Glass is bad design. I never even mentioned anything about individual elements, nor brought up anything about who it is bad for (and this is one of those occasions where no, it's not a "people aren't used to change" kind of things).
But to suggest the current implementation in iOS and macOS isn't problematic would mean you'd need to be incredibly unaware of basic accessibility needs of a significant portion of people, and right now both operating systems have made it significantly worse. That's not a design opinion, its fact.
It’s weird to complain about accessibility in macOS when it has such a huge amount of easily discoverable accessibility settings to handle just about every need… including the option to turn off liquid glass effect!
So you're saying its fine to go backwards on a11y as long as you dont remove some settings to switch to an afterthought that doesn't always have feature parity, and is often buggy with little care or thought being given to those who have a11y neds (As has already been explained above in another chain of this discussion)
Making everything illegible is necessary, so they can sell you a legible design as the next big revolution. Just not in one step. The return to legibility will be a multi part story with cliffhangers, betrayals and everything else it takes to keep you hooked and Apple in the news.
The designers on Liquid Glass are proud of it, and also disappointed that some of the design system did not make it into v1.0 code, so the reality is less legible than the designs indicated.
There is no designer in the world making bad designs as part of some conspiracy to enable their employer to launch improved designs several years later. There’s no company that operates that way.
Maybe legibility should be a ship condition on the first version of the code, not some final destination to eventually achieve. Or like, maybe they need to actually say that, when they claim this is the culmination of years of thought and effort, and that this is clearly the most amazing design ever, that they don't mean the thing they are actually pointing at.
> There is no designer in the world making bad designs as part of some conspiracy to enable their employer to launch improved designs several years later. There’s no company that operates that way.
It's even reactive, the clock went horizontal if you give it a wide enough viewport.
Damn this is good. It's like playing with oil without having to wash your hands afterwards, and there's no mom chasing to give you a beat for the oil money you've just wasted. And on top of that, it tells you time.
I have accidentally swipe-navigated far more times than I have ever purposefully swipe-navigated (zero times), so I am astounded to see someone who hasn't rage-disabled that misfeature upon installation of the OS.
I don't begrudge it being overridden here since this is a demo, but ever since, like, way early Opera era, swiping to navigate is muscle memory for me, and I prefer it both on desktop and mobile/tablet. Much simpler than reaching for the button.
Glad you have the ability to set your own preferences, but I’m pretty sure most people are happy with this. Do you by chance spend a lot of time reading PDFs while angry?
I don't use Android swipe gestures but I presume they would work in FF too. Nonetheless, we should avoid posting "it works in Chrome" as an answer to anything.
I have a deep-seated hatred for Chrome-only devs - not least of which is because it has contributed to the situation we are in, where Google is taking the "my way or the highway" approach to Chrome and adblockers, Android is locking us out of sideloaded apps, etc. Test at least in Chromium and FF as a bare minimum. Submit condescending bug reports to those stupid react components that break entire websites and nobody bothers to check, etc.
Except there's literally nothing a web page should be able to do to stop your back gestures from working, that's an OS and browser responsibility. If it isn't working it's the OS and/or browser's fault.
it's interesting that the drops tend to collect in straight lines. I wonder what's happening in the sim code to keep them from collecting into round droplets?
Interesting, this crashed my browser tab trying to load it! Run for all of 15s at about 1fps ;) I'm of course, not on a phone, but on my 9800X3D desktop, which promptly spiked usage to 100%! I wonder what APIs are not available on a desktop that this uses.
I kept getting "Driver Message (OpenGL, Performance, GL_CLOSE_PATH_NV, High): GPU stall due to ReadPixels", which for anyone familiar with OpenGL probably knows... usage of the glReadPixels function is typically frowned upon if at all possible, because moving framebuffer data out of the GPU and back into system memory can cause huge performance issues.
I'm not sure why they need to use this function, or if it's just not optimized enough to go without it.
In practice, it’s been written as plain JS with a tiny bit of gratuitous Vue and SCSS bolted on (see even how Vue’s onMounted and onBeforeUnmount are fed callbacks that just run the actual initOGL and destroy functions). It would have been easier and shorter to write without Vue and SCSS than with them! What’s currently spread across index.html, src/styles.scss, src/main.js and src/App.vue would have worked better all in index.html, or if you really wanted to, you could still split the CSS and JS into files src/styles.css and src/main.js.
The bulk of it is WebGL. Vue is doing very little here. Since it's a single static page rendering to canvas, it really doesn't need a framework like Vue or React.
I was using React at work and looking at the Vue manual which at first looked good to me because Vue has first-class lists, it fit my model of web applications better. Than I saw three.js and other things were people used React to render things that weren’t ordinary web apps and I realized I could draw anything I could imagine with React but not with Vue.
I like the idea of svelte but for apps that are small enough that svelte has a bundle size advantage the bundle size difference isn’t decisive (users won’t usually notice or care) and if your app is huge enough that the bundle size is a problem you have problems bigger than your choice of framework.
I helped port a Vue 2 project to Vue 3, and then I worked on a Vue 3 project we’ve slowly been rewriting in a greenfield Nuxt 3 project. Vue 2 and the options API were just difficult in all senses - even Vue3 with Options feels bad. I really enjoy 3 with the composition API, and I have always had a difficult time reasoning about React personally.
While I will continue to probably promote Vue where it makes sense, I’m honestly more inclined towards learning Svelte, HTMX, and other less arduous frameworks.
but seriously, I'm very interested to hear your gripes with Vue that were solved by react, since the latter feels much worse DX-wise than both Vue or Svelte, notwithstanding worse performance as well.
Vue 2 had really bad support for static typing. It's improved in Vue 3 but still not as good as React. TSX is especially good.
But the main issue is the automatic reactivity. It's difficult to reason about and leads to spaghetti code. We also had occasional issues where people would put objects in properties that had some tenuous link to a database object or something, and Vue recursively infects the entire object with getters and setters to make the reactivity work. Sometimes we didn't even notice but it makes everything way slower.
I haven't tried Svelte so I'll take your word for it!
Also this was 3 years ago so I may have misremembered some details. No nitpicking!
I really wish HN supported images so I could reply to this comment with the boy-crashes-bike-after-putting-a-stick-through-the-wheel meme it so richly deserves.
Its interesting that most comments appear to be running it on their phones. I wonder if most links on HN are viewed on phones primarily? Phones are generally newer than laptops and most developers will have the latest technology.
Developers especially with tech demos like this, use the latest tech to develop and don't care about supporting older devices. This attitude can sometimes bleed over into their work where they should care for users using older machines, but its expected for a look-at-the-shiny demonstration to other techies using top of the range hardware.
( I am seeing the same laggy effects on an older linux + firefox laptop with integrated graphics, unsurprisingly )
I happened to have just finished writing a thesis on such a combination. The size of the little droplets is determined by the chemical wavelength of the reaction-diffusion subsystem. There’s a nice video and a pdf here: https://maximzuriel.nl/dynamics-and-pattern-formation-in-act...
Vista, or rather Aero, never looked anything like this. It's glassy and translucent but that's where the similarity ends. The way the translucency itself is used is vastly different.
But also, yes, I agree. It didn't need to make a comeback. And even if it did, since iOS and macOS were already fairly translucent, it didn't need to be like this.
I just checked your profile and I'm impressed by your commitment to log in once a month, write some out of pocket comment and then not write anything else until the next month
Looks like something you'd expect to find as a countdown timer in the run up to this year's WWDC on their homepage. Very slick.
Source code: https://github.com/chiuhans111/fluidglass
Despite the liquid glass discussion … I am absolutely impressed how smooth this runs on a phone.
Refraction is not as expensive as people would led you to believe. That said, this demo is ran at a very low resolution. Probably because it doesn't take devicePixelRatio into account. On my phone that's 3.5 so more than 12 times less pixels than would be required if you want crisp UI.
Tip: change the browser scale to 50% to double the demo's resolution
I see where you're coming from, but "on a phone" hasn't been a valid qualifier for performance benchmarks for a long time. Phones and their GPUs are ridiculously powerful nowadays. We've been smoothly running 3D apps on GPUs with orders of magnitude less MFLOPS 20 years ago already. Apps and games with far more going on than blurry glassy alarm clock, albeit somewhat less beautiful. When I run Fluid Glass on a 10 year old laptop with an integrated GPU and move my cursor, I'm seeing less than 10 FPS. When will we finally start readjusting our expectations for "fast" software and stop blindly following Wirths law?
Partly because phones have smaller screen sizes. When I reduce the the browser window size the FPS improves. For full widow mode it's a bit lagging for me.
It does use a ton of energy - with clock on 4k screen my M2 macbook air CPU temperature went up 10°C in 10s and 20°C in 50s.
Yeah was also expecting my phone to get very toasty but it did not. Great job!
I noticed this pattern that a page with some text and images is often too demanding for my phone: it becomes impossible to scroll the page smoothly. We simply do not have the technology yet to handle text and images in a consistent way! But anything involving 3D graphics (or 4K video) will run just fine.
> We simply do not have the technology yet to handle text and images in a consistent way!
We actually have plenty of algorithms for laying out text and images very quickly. You can see this when scrolling complex PDFs or sizable books on e.g. Apple devices. Even a complex web page can be very responsive if it makes smart use of JS and async calls, etc.
Perhaps what you mean is that the complexity of current web apps running on browsers that handle arbitrary layout, computation (JS, WebAssembly), async calls (e.g. analytics), etc can be laggy on certain mobile devices? If so, yes. There are many possible culprits so to speak that lead to low frame rates.
I would phrase it this way: the combination of advertising interests, compute power, and economics have led us to a place where lots of people face laggy interfaces.
Overall, this isn’t a “technological” problem: think of technology as a set of constraints. People and their desires lead to various “design” decisions (some more evolved than designed).
See also Wirth’s Law. I don’t think it is particularly insightful, however. These kinds of laws feel more like the ironic complaints of an ennui fueled graybeard than attempts to make proactive change. From Wikipedia:
> Wirth's law is an adage on computer performance which states that software is getting slower more rapidly than hardware is becoming faster.
> The adage is named after Niklaus Wirth, a computer scientist who discussed it in his 1995 article "A Plea for Lean Software".
Note that some malicious and misguided right wingers are attacking and trying to subvert Wikipedia.
2d is more expensive than 3d to render. Video is hardware accelerated.
Cool concept, just please never ever do this in anything production, it's bad enough we've now got a mainline OS with such awful legibility.
I’ll never understand this sentiment expressed online that Liquid Glass is bad design.
After reading how awful it is on HN, I upgraded to see it for myself. After some pondering it was obvious why Apple went with this design.
Today’s apps’ problem is every app has its own UI language, and users have to first learn that before being able to use an app. Apple recognized this. If you can’t see why it’s a problem, try to teach your mom or grandma how to use a new app.
To design a unified UI framework, you need a lot of things: common elements (e.g. date picker), typography (fonts, text styling), iconography (the same icon in every app for the Share button), etc. Both Apple annd Android vendors already have UI frameworks dictating these for native apps today.
The hard problem that remained unsolved until Liquid Glass is these UI toolkits can’t dictate a color for interactive elements, because every other app has its own, different color scheme. Any color you pick will inevitably look out of place in some apps. The answer here is, unsurprisingly, transparent elements.
But there is historically a huge issue with transparent elements, a hard problem where many previous attempts have failed: how can you make a transparent element (e.g a button) still be recognizable on various content?
Apple’s answer here works beautifully: make the controls appear floating an inch over the content, by mimicking the properties of the two most familiar physical transparent objects - water and glass.
“Today’s apps’ problem is every app has its own UI language, and users have to first learn that before being able to use an app.”
Liquid Glass is far from the first attempt at this. See “material design”. Apple has had UI guidelines for years now, and all of their apps were more or less as consistent as they are now after the transition. My complaint is that shiny effects aren’t necessary for UI consistency, and it slows older devices and consumes their already degraded battery capacity even faster. At least you can “reduce transparency”, but it actually makes the UI looks less transparent than it was before.
However, my biggest complaint is how half-baked it is. iOS 26 is riddled with bugs. As an example that is ridiculously easy to reproduce: 1) Enable “reduce transparency” in accessibility. 2) Open the Files app to any directory. 3) Enable dark mode. Congratulations, the directory name at the top of the screen is now illegible due to black text on a black background. The same bug is also present in Freeform, except it also makes the status bar illegible. They removed the backing UI element without refactoring the text, and nobody noticed. And unless they didn’t mention it in the release notes, it looks like they still haven’t fixed this in the 26.1 beta.
I never said Liquid Glass is bad design. I never even mentioned anything about individual elements, nor brought up anything about who it is bad for (and this is one of those occasions where no, it's not a "people aren't used to change" kind of things).
But to suggest the current implementation in iOS and macOS isn't problematic would mean you'd need to be incredibly unaware of basic accessibility needs of a significant portion of people, and right now both operating systems have made it significantly worse. That's not a design opinion, its fact.
It’s weird to complain about accessibility in macOS when it has such a huge amount of easily discoverable accessibility settings to handle just about every need… including the option to turn off liquid glass effect!
So you're saying its fine to go backwards on a11y as long as you dont remove some settings to switch to an afterthought that doesn't always have feature parity, and is often buggy with little care or thought being given to those who have a11y neds (As has already been explained above in another chain of this discussion)
Making everything illegible is necessary, so they can sell you a legible design as the next big revolution. Just not in one step. The return to legibility will be a multi part story with cliffhangers, betrayals and everything else it takes to keep you hooked and Apple in the news.
The world isn’t that conspiratorial.
The designers on Liquid Glass are proud of it, and also disappointed that some of the design system did not make it into v1.0 code, so the reality is less legible than the designs indicated.
There is no designer in the world making bad designs as part of some conspiracy to enable their employer to launch improved designs several years later. There’s no company that operates that way.
Maybe legibility should be a ship condition on the first version of the code, not some final destination to eventually achieve. Or like, maybe they need to actually say that, when they claim this is the culmination of years of thought and effort, and that this is clearly the most amazing design ever, that they don't mean the thing they are actually pointing at.
> There is no designer in the world making bad designs as part of some conspiracy to enable their employer to launch improved designs several years later. There’s no company that operates that way.
New Coke / Coke Classic
Windows Vista / Windows 7
Office 2007 / Office 2010
> Windows Vista / Windows 7
It was same ugly design. But bug fixes are natural for later versions.
Apple coding interview?
Real LOL! Exactly.
It's even reactive, the clock went horizontal if you give it a wide enough viewport.
Damn this is good. It's like playing with oil without having to wash your hands afterwards, and there's no mom chasing to give you a beat for the oil money you've just wasted. And on top of that, it tells you time.
Do note you can click and drag on it too.
on linux desktop, rolling the mouse over it makes things happen; clicking and dragging aren't different
Annoyingly overrides swiping back to navigate on mobile.
I have accidentally swipe-navigated far more times than I have ever purposefully swipe-navigated (zero times), so I am astounded to see someone who hasn't rage-disabled that misfeature upon installation of the OS.
The only swiping gesture heresy is that on Android both sides go back.
I don't begrudge it being overridden here since this is a demo, but ever since, like, way early Opera era, swiping to navigate is muscle memory for me, and I prefer it both on desktop and mobile/tablet. Much simpler than reaching for the button.
i was never attracted to the gattaca UX, it's a UI pre-crime.
reaching is muscle memory for me. buttons i like because i know what i'm getting, and what i'm getting can be many different things as buttons allow.
Glad you have the ability to set your own preferences, but I’m pretty sure most people are happy with this. Do you by chance spend a lot of time reading PDFs while angry?
Well, that’s because you don’t use it I guess!
I basically only swipe back. This aligns web pages with iOS nav stacks.
Like many changes, you originally hate it, then you get used to it, then you hate when it changes again.
Works fine on Android.
No problem on Android/Chrome. Are you using an iPhone? If so, the annoyance should be aimed at Apple not the creator of this demo.
I don't use Android swipe gestures but I presume they would work in FF too. Nonetheless, we should avoid posting "it works in Chrome" as an answer to anything.
I have a deep-seated hatred for Chrome-only devs - not least of which is because it has contributed to the situation we are in, where Google is taking the "my way or the highway" approach to Chrome and adblockers, Android is locking us out of sideloaded apps, etc. Test at least in Chromium and FF as a bare minimum. Submit condescending bug reports to those stupid react components that break entire websites and nobody bothers to check, etc.
Except there's literally nothing a web page should be able to do to stop your back gestures from working, that's an OS and browser responsibility. If it isn't working it's the OS and/or browser's fault.
Best viewed in Internet Explorer!
IE6.
Ah…memories…
it's interesting that the drops tend to collect in straight lines. I wonder what's happening in the sim code to keep them from collecting into round droplets?
Mine looks like a braille pad after leaving it for a bit, so it does collect into droplets for me.
Aliasing on the grid.
looks similar to some emergent patterns in reaction diffusion systems
Full portfolio https://chiuhans111.github.io/portfolio2020/dist/index.html
The abstract background is actually an analog clock. Nice touch.
the demoscene is alive and well, just not where u expect it to appear .)
Interesting, this crashed my browser tab trying to load it! Run for all of 15s at about 1fps ;) I'm of course, not on a phone, but on my 9800X3D desktop, which promptly spiked usage to 100%! I wonder what APIs are not available on a desktop that this uses.
I kept getting "Driver Message (OpenGL, Performance, GL_CLOSE_PATH_NV, High): GPU stall due to ReadPixels", which for anyone familiar with OpenGL probably knows... usage of the glReadPixels function is typically frowned upon if at all possible, because moving framebuffer data out of the GPU and back into system memory can cause huge performance issues.
I'm not sure why they need to use this function, or if it's just not optimized enough to go without it.
It's cool that it responds to my phone's stylus hovering above the screen, not just when it's touching. Feels like magic.
Isn't that magic called "mouse cursor emulation"?
Beautiful demo. I hope no IT company will ever think this is a good UI.
Very much agree.
I am not thrilled with the translucency of Liquid Glass (Apple systems 26).
Came here to post exactly this. Very nice demo though...
I would love to turn this into a screensaver of rain falling onto a window.
Like this one?
https://www.shadertoy.com/view/ltffzl
The beading effect is very odd to me, as if surface tension is inverted.
Gets good performance on my iPhone 16, but terrible performance on my laptop in Brave?
I love that zooming controls the resolution live, so you can speed up and slow down the animation at will. Might be unintentional but it's fun!
Refreshing that it's built using the vue framework vs the typical react.
In practice, it’s been written as plain JS with a tiny bit of gratuitous Vue and SCSS bolted on (see even how Vue’s onMounted and onBeforeUnmount are fed callbacks that just run the actual initOGL and destroy functions). It would have been easier and shorter to write without Vue and SCSS than with them! What’s currently spread across index.html, src/styles.scss, src/main.js and src/App.vue would have worked better all in index.html, or if you really wanted to, you could still split the CSS and JS into files src/styles.css and src/main.js.
The bulk of it is WebGL. Vue is doing very little here. Since it's a single static page rendering to canvas, it really doesn't need a framework like Vue or React.
Why does it even need anything here other than vanilla JavaScript? I don't see the need for a SPA framework.
Why? React is much better than Vue in my experience. Vue 2 was so bad we ended up painfully porting an entire election app to react at a previous job.
I was using React at work and looking at the Vue manual which at first looked good to me because Vue has first-class lists, it fit my model of web applications better. Than I saw three.js and other things were people used React to render things that weren’t ordinary web apps and I realized I could draw anything I could imagine with React but not with Vue.
I like the idea of svelte but for apps that are small enough that svelte has a bundle size advantage the bundle size difference isn’t decisive (users won’t usually notice or care) and if your app is huge enough that the bundle size is a problem you have problems bigger than your choice of framework.
I helped port a Vue 2 project to Vue 3, and then I worked on a Vue 3 project we’ve slowly been rewriting in a greenfield Nuxt 3 project. Vue 2 and the options API were just difficult in all senses - even Vue3 with Options feels bad. I really enjoy 3 with the composition API, and I have always had a difficult time reasoning about React personally.
While I will continue to probably promote Vue where it makes sense, I’m honestly more inclined towards learning Svelte, HTMX, and other less arduous frameworks.
svelte's better than both : ^ )
(someone continue this with framework x)
but seriously, I'm very interested to hear your gripes with Vue that were solved by react, since the latter feels much worse DX-wise than both Vue or Svelte, notwithstanding worse performance as well.
Vue 2 had really bad support for static typing. It's improved in Vue 3 but still not as good as React. TSX is especially good.
But the main issue is the automatic reactivity. It's difficult to reason about and leads to spaghetti code. We also had occasional issues where people would put objects in properties that had some tenuous link to a database object or something, and Vue recursively infects the entire object with getters and setters to make the reactivity work. Sometimes we didn't even notice but it makes everything way slower.
I haven't tried Svelte so I'll take your word for it!
Also this was 3 years ago so I may have misremembered some details. No nitpicking!
Svelte's MUCH better than both : ^ )
(You didn't say framework x had to be a different framework than Svelte! x)
Lit-html is better than all frameworks :)
Surprised this is using any vue/react framework. I expected just a plain webgl+shader without libraries codebase.
[dead]
It's really nice. Really unreadable too but I know that's not the point (AI prompt "make sure this never makes its way into phones")
This website is running at >10 FPS at 100% GPU usage
I really wish HN supported images so I could reply to this comment with the boy-crashes-bike-after-putting-a-stick-through-the-wheel meme it so richly deserves.
Honestly, that's what makes HN so pleasant ;)
Meme-free-zone - here's hoping it stays that way.
Besides, describing a meme is just as good!
Its interesting that most comments appear to be running it on their phones. I wonder if most links on HN are viewed on phones primarily? Phones are generally newer than laptops and most developers will have the latest technology.
Developers especially with tech demos like this, use the latest tech to develop and don't care about supporting older devices. This attitude can sometimes bleed over into their work where they should care for users using older machines, but its expected for a look-at-the-shiny demonstration to other techies using top of the range hardware.
( I am seeing the same laggy effects on an older linux + firefox laptop with integrated graphics, unsurprisingly )
If I reduce the browser window size the FPS improves. Maybe that's why phones have higher FPS.
Not a very useful comment without mentioning the OS, browser, and hardware.
I think this depends on the screen resolution. If I reduce the browser window size the FPS improves.
On what hardware? Runs well on my Pixel 7a. It's likely just a fancy pixel shader (or few).
Compaq Presario from 2003 running XP on Internet Explorer, why?
Jokes aside my Pixel 8 Pro handles it just fine as well
Many Pixels on this site apparently (me included). Is it a GrapheneOS thing or do people just prefer Google's hardware nowadays?
The cpu and gpu usage on firefox desktop seems to be twice as high as chrome when opening this demo.
Imagine adding support for gyroscopes on phones and then you can make the water flow away when you rotate your device! Great work btw
It would be cool the have it as my lock screen.
Why can't you?
Didnt expect it to be this smooth
Took me way too long to realize I could touch to interact. Very cool!
Based on the patterns that appear when undisturbed, this seems to be based on a cellular automaton.
My guess is a reaction diffusion simulation
Yeah the code has a (somewhat rudimentary) fluid sim that's fed into reaction-diffusion. Pretty cool, don't think I've seen that combination before
I happened to have just finished writing a thesis on such a combination. The size of the little droplets is determined by the chemical wavelength of the reaction-diffusion subsystem. There’s a nice video and a pdf here: https://maximzuriel.nl/dynamics-and-pattern-formation-in-act...
Waiting for someone with trypophobia to see this
No effect. I think because it doesn't look organic, and/or the size and arrangment of holes wasn't right.
very nice at 240fps. i have similar demos coming later
Doesn't work on Librewolf
The meandering movement of the droplets around the sides remind me of the Gray-Scott reaction–diffusion system
Brilliant - I need this
UI innovation and courage!
This is mesmerising
Wet is the new hot.
Wow this is cool
Very impressive. Thanks!
Looks really cool.
Most disgusting design trend. I hope the Vista look that has been re-popularized by Apple dies soon.
Vista, or rather Aero, never looked anything like this. It's glassy and translucent but that's where the similarity ends. The way the translucency itself is used is vastly different.
But also, yes, I agree. It didn't need to make a comeback. And even if it did, since iOS and macOS were already fairly translucent, it didn't need to be like this.
Holy shit. That's indistinguishable from magic. Ran on an iPad Pro m4 so it might be cheating.
[dead]
[flagged]
"One of the design goals was when you saw it you wanted to lick it."
- Steve Jobs
It truly is a shame that HN won't let us post gifs.
I just checked your profile and I'm impressed by your commitment to log in once a month, write some out of pocket comment and then not write anything else until the next month
[dead]
Until someone makes it frosted, we are safe.
Hard lol to this