This is the first time I haven’t hated scroll hijacking. That was actually really smooth.
Part of why it is less offensive is it's not actually hijacking our scrolling: https://news.ycombinator.com/item?id=43572887 Scroll hijacking is when I try to scroll normally but the page overrides my distance and velocity.
It definitely feels “heavy” on mobile Safari. The animation is buttery smooth, but the little space station thing doesn’t rotate as quickly as I feel it should based on my scroll velocity.
I feel like I’m alone in not liking it. The technical accomplishment is undeniably impressive, and the author deserves serious kudos for that, but I really wish websites wouldn’t do this sort of thing. It’s far less usable than just having some static tables.
It's clever, but honestly I don't care how smooth it is. Scrolling should simply scroll a view up or down a page. Not invoke animation. We already have established UX patterns for playing media, slowing it down, speeding it up, randomly seeking through it.
So what would you suggest to use to move the animation forward?
I understand that, I meant they made the choice to use power and resources on the client end when internet bandwidth is abundant and they can utilize server resources for cpu intensive workload. Design choices such as these are exclude anyone who can't afford decent hardware and are inefficient in terms of power/energy usage.
If they made the opposite choice then people would argue that they're not prioritizing bandwidth for those with poor internet connections like those living in rural areas or third-world countries. My gut says it's much more likely that clients have access to a discrete GPU than they do to broadband Internet. I also do not believe it would be possible to deliver the experience they're shipping with pre-rendered assets…
I can only speak from my experience, and it is bad. If there are enough people that like this, then of course this should be a good library to use. but I'm just expressing my experience and feedback that I usually don't expose my gpu and cheaper hardware has less gpu power. GPU also uses a lot of energy (did everyone stop caring about that?). Browsers are already using too much power. I've seen other services like netflix vs prime as I mentioned earlier where I'm getting the same bandwidth utilization but less performance because someone at netflix decided to not care about cpu/gpu usage. I'm just asking for devs to be considerate unless the target audience is clearly people who have lots of gpu and don't care about energy usage (like graphics editors,vfx workers,etc..)
Still waiting for the WYSIWYG GUI-base authoring tool for a web animation API. You know what artists - animators - generally don't like? Wading through docs and code to spin a square. It's been about a decade since the average of the various watersheds in the slow death of Flash, and we still don't have a replacement.
I honestly think it's https://godotengine.org/features/ , though I do think the GUI-only WYSIWYG creation flow hits a brick wall a little earlier than Flash did. Lots of content being made with it though! https://docs.godotengine.org/en/stable/tutorials/animation/i...
If you're being honest with yourself, not even close. Maybe if you Frankenstein Blender for asset creation and Godot/Unity for scripting, but it would be just as much of a monster as Shelley's.
Julian (the author) is a genius. v4 has been in the making for some time, but, boy, is it worth the wait! I have used v3 (I am using it on my landing page and even built a small game engine with it), but this version is on a whole new level. Congrats to the author! Keep up the good work!
> Julian (the author) is a genius. With proof! I have rarely been so impressed with a web tech.
It reminds me how I felt when I first saw the recursive GoL:
Still waiting for the WYSIWYG GUI-base authoring tool for a web animation API. You know what artists - animators - generally don't like? Wading through docs and code to spin a square. It's been about a decade since the average of the various watersheds in the slow death of Flash, and we still don't have a replacement.
Ooh, fun, reproducible on Firefox for Android. Crash signature [@ JS::Heap ::exposeToActiveJS ].
Not seeing this with 137.
I can reproduce it in 137 stable on Android and 138 Nightly on Linux from 2025-03-10 (I’m not normally so far out of date, there was a specific reason this time), but it requires the uBlock Origin extension to be enabled.