[HN Gopher] Fluid Glass
___________________________________________________________________
Fluid Glass
Author : memalign
Score : 647 points
Date : 2025-09-30 05:15 UTC (4 days ago)
(HTM) web link (chiuhans111.github.io)
(TXT) w3m dump (chiuhans111.github.io)
| tt_dev wrote:
| Wow this is cool
| chipheat wrote:
| Source code: https://github.com/chiuhans111/fluidglass
| oatsandsugar wrote:
| Apple coding interview?
| drob518 wrote:
| Real LOL! Exactly.
| cluckindan wrote:
| Based on the patterns that appear when undisturbed, this seems to
| be based on a cellular automaton.
| jimmycleveland wrote:
| My guess is a reaction diffusion simulation
| fedsocpuppet wrote:
| 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
| dailyanchovy wrote:
| 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...
| marcodiego wrote:
| It would be cool the have it as my lock screen.
| wasting_time wrote:
| Why can't you?
| hardaker wrote:
| Do note you can click and drag on it too.
| adastra22 wrote:
| Annoyingly overrides swiping back to navigate on mobile.
| joeframbach wrote:
| 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.
| totallymike wrote:
| 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.
| fsckboy wrote:
| 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.
| handsclean wrote:
| 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?
| kenferry wrote:
| Well, that's because you don't use it I guess!
|
| I basically only swipe back. This aligns web pages with iOS
| nav stacks.
| yoz-y wrote:
| The only swiping gesture heresy is that on Android both
| sides go back.
| MattSayar wrote:
| Like many changes, you originally hate it, then you get
| used to it, then you hate when it changes again.
| russellbeattie wrote:
| 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.
| sgc wrote:
| 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.
| esafak wrote:
| Best viewed in Internet Explorer!
| ChrisMarshallNY wrote:
| IE6.
|
| Ah...memories...
| rezonant wrote:
| 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.
| LorenDB wrote:
| Works fine on Android.
| fsckboy wrote:
| on linux desktop, rolling the mouse over it makes things
| happen; clicking and dragging aren't different
| maelito wrote:
| Beautiful demo. I hope no IT company will ever think this is a
| good UI.
| mrandish wrote:
| Came here to post exactly this. Very nice demo though...
| ChrisMarshallNY wrote:
| Very much agree.
|
| I am not thrilled with the translucency of Liquid Glass (Apple
| systems 26).
| sipsi wrote:
| very nice at 240fps. i have similar demos coming later
| drob518 wrote:
| Looks really cool.
| nine_k wrote:
| Wet is the new hot.
| skgough wrote:
| 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?
| carabiner wrote:
| Aliasing on the grid.
| augzodia wrote:
| looks similar to some emergent patterns in reaction diffusion
| systems
| shakna wrote:
| Mine looks like a braille pad after leaving it for a bit, so it
| does collect into droplets for me.
| Velocifyer wrote:
| This website is running at >10 FPS at 100% GPU usage
| Rohansi wrote:
| On what hardware? Runs well on my Pixel 7a. It's likely just a
| fancy pixel shader (or few).
| rezonant wrote:
| Compaq Presario from 2003 running XP on Internet Explorer,
| why?
|
| Jokes aside my Pixel 8 Pro handles it just fine as well
| poly2it wrote:
| Many Pixels on this site apparently (me included). Is it a
| GrapheneOS thing or do people just prefer Google's hardware
| nowadays?
| Uehreka wrote:
| 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.
| Towaway69 wrote:
| 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!
| jeswin wrote:
| Not a very useful comment without mentioning the OS, browser,
| and hardware.
| thinkingemote wrote:
| 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 )
| senfiaj wrote:
| If I reduce the browser window size the FPS improves. Maybe
| that's why phones have higher FPS.
| senfiaj wrote:
| I think this depends on the screen resolution. If I reduce the
| browser window size the FPS improves.
| neurostimulant wrote:
| The cpu and gpu usage on firefox desktop seems to be twice as
| high as chrome when opening this demo.
| BHSPitMonkey wrote:
| 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.
| bitwize wrote:
| UI innovation and courage!
| zdc1 wrote:
| Waiting for someone with trypophobia to see this
| Y_Y wrote:
| No effect. I think because it doesn't look organic, and/or the
| size and arrangment of holes wasn't right.
| hilti wrote:
| Despite the liquid glass discussion ... I am absolutely impressed
| how smooth this runs on a phone.
| jonplackett wrote:
| Yeah was also expecting my phone to get very toasty but it did
| not. Great job!
| andai wrote:
| 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.
| xpe wrote:
| > 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.
| leloctai wrote:
| 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.
| bapak wrote:
| Tip: change the browser scale to 50% to double the demo's
| resolution
| senfiaj wrote:
| 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.
| aljarry wrote:
| It does use a ton of energy - with clock on 4k screen my M2
| macbook air CPU temperature went up 10degC in 10s and 20degC in
| 50s.
| westoque wrote:
| Refreshing that it's built using the vue framework vs the typical
| react.
| treyp wrote:
| 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.
| mattlondon wrote:
| Why does it even need anything here other than vanilla
| JavaScript? I don't see the need for a SPA framework.
| IshKebab wrote:
| 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.
| h4ch1 wrote:
| 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.
| DonHopkins wrote:
| Svelte's MUCH better than both : ^ )
|
| (You didn't say framework x had to be a different framework
| than Svelte! x)
| brazukadev wrote:
| Lit-html is better than all frameworks :)
| IshKebab wrote:
| 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!
| PaulHoule wrote:
| 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.
| chrismorgan wrote:
| 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.
| qoez wrote:
| Surprised this is using any vue/react framework. I expected
| just a plain webgl+shader without libraries codebase.
| nirui wrote:
| 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.
| DecentShoes wrote:
| It's cool that it responds to my phone's stylus hovering above
| the screen, not just when it's touching. Feels like magic.
| silversmith wrote:
| Isn't that magic called "mouse cursor emulation"?
| maartenscholl wrote:
| The meandering movement of the droplets around the sides remind
| me of the Gray-Scott reaction-diffusion system
| michelreij wrote:
| Very impressive. Thanks!
| aquir wrote:
| Imagine adding support for gyroscopes on phones and then you can
| make the water flow away when you rotate your device! Great work
| btw
| NuclearPM wrote:
| Full portfolio
| https://chiuhans111.github.io/portfolio2020/dist/index.html
| BrandoElFollito wrote:
| 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")
| Noxus3038 wrote:
| Didnt expect it to be this smooth
| Rodmine wrote:
| Most disgusting design trend. I hope the Vista look that has been
| re-popularized by Apple dies soon.
| zapzupnz wrote:
| 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.
| qwertytyyuu wrote:
| This is mesmerising
| esskay wrote:
| 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.
| tempodox wrote:
| 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.
| brookst wrote:
| 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.
| saurik wrote:
| 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.
| DaiPlusPlus wrote:
| > 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
| timeon wrote:
| > Windows Vista / Windows 7
|
| It was same ugly design. But bug fixes are natural for
| later versions.
| Aerbil313 wrote:
| 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.
| esskay wrote:
| 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.
| Fwirt wrote:
| "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.
| James_K wrote:
| The beading effect is very odd to me, as if surface tension is
| inverted.
| larodi wrote:
| the demoscene is alive and well, just not where u expect it to
| appear .)
| migueldeicaza wrote:
| Brilliant - I need this
| wvbdmp wrote:
| The abstract background is actually an analog clock. Nice touch.
| kogasa240p wrote:
| Doesn't work on Librewolf
| tones411 wrote:
| Took me way too long to realize I could touch to interact. Very
| cool!
| sodality2 wrote:
| 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!
| dtjohnnymonkey wrote:
| I would love to turn this into a screensaver of rain falling onto
| a window.
| s-macke wrote:
| Like this one?
|
| https://www.shadertoy.com/view/ltffzl
| Fabricio20 wrote:
| 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.
| ranger_danger wrote:
| 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.
| burnt-resistor wrote:
| Holy shit. That's indistinguishable from magic. Ran on an iPad
| Pro m4 so it might be cheating.
___________________________________________________________________
(page generated 2025-10-04 23:00 UTC)