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!
I think part of the trick is that each unit of scrolling takes you quite far down the animation sequence (so scrolling doesn't feel like a long effort)
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.
Part of the smoothness here is that scrolling the text is 1:1 once you get down to the sections with colored headers. It demonstrates that it's possible to make a page look fancy like that without "breaking" your intuition of what scrolling "should be."
JS animations obviously don't take the place of video/audio media that you'd play/scrub through.
Hey I'm the author of the lib, exactly, I don't really "highjack" the body scroll, I'm only controlling the background animations with it, while keeping most of the body content scroll naturally with the page.
It's not so much about playing/slowing/speeding up an animation or video. It's about moving forward and backward through an "experience," as much as I dislike the overuse of that word. I'd suggest it's a natural evolution of the scroll behavior.
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!
I cannot believe this is real, it was so well done. It felt like creativity of the internet from the early 2000s met the polished design standards of today.
Hey I'm the author of the lib, I think this is my favorite comment about the landing page I read so far. I've started learning web development with Flash in the 2000s, so this hits home. Thank you!
Wow, that homepage was one of the more complex and layer filled interactive animations that I ever seen running so smoothly on a mobile browser. Those FPS feel like a Doom 2016 on a beefy PC.
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 responds to the scrolling, leaving agency to the user, instead of hijacking scrolling, that steal agency from the user, that some web sites do. It's so much better of a solution and friendly to accessibility.
I love it, but... Going to this page https://animejs.com/documentation/scope/ with ublock origin enabled in my Firefox (136.0.3) immediately crashes the tab. Which certainly made for a funny experience right after scrolling through the very impressive intro animation.
Just joining in with the “Wow, this is amazing” crowd. I usually detest websites that dink with scrolling to animate content in and out of view, except for well designed long form narrative content; but this is slick.
A challenge to all the “10x-ed my productivity” LLManiacs: how long to recreate this landing page using nothing but prompts (and how much $$ for a how-to course :)
A challenge to the “the’re gonna take our jobs” LLMongers: git gud, its possible. this is living proof.
I can't speak to what it's like to actually work with this, but I really like the API design and docs. This feels really well thought out. Looking through the timer docs for example, it took just a minute or so to understand what the timer API can do and how to do it. This gives me a lot of confidence to try out the library.
As others have said, beautiful work on the lander. It looks and performs beautifully.
This is insane. API looks great, landing page is the best thing I've ever seen and just so feature rich. I wish I had a way to use this in my primary application.
Probably a dumb question but.. Is the 3d exploding diagram model of the engine here just a visual metaphor for a complex system working in sync with itself? Or actually created using the toolkit? I flipped through the API and everything appears to be lower-level animation support, but intro gives the impression that it's CAD-like.
I'm interested in creating animated technical diagrams. I'm looking for something high level that would allow rapid progress on prototyping a diagram. Perhaps vaguely analogous to manim, but either native JS or producing lightweight assets that can be hosted in a web page. Does anyone have any suggestions?
This is INCREDIBLE. What! I could spend hours just playing around with the hecking documentation pages. EVERYTHING is so well thought out AND presented. I'm in awe.
The one thing I'm missing is the brag page. Knowing GSAP I'd really like to see why it would be better. It doesn't have to be a fair comparison. Greensock can then say why they'd still be better.
But as we do have options it would be nice to see where they match and where they differ.
If you read the source of both and spend 5 minutes on the issues of each and you will see that GSAP is a dated turd with more layers of cruft than photoshop and they still can’t do ESM or Typescript right even though they charge money for important features.
AnimeJS is S-tier, up there with Pixi in quality, albeit smaller scope. V3 was a bit rough but v4 has been baking for a long time.
The performance, code quality, ease of use, size, everything is worse in GSAP.
The only issue I found with it was when checking the responsive layout example, I tried to resize my browser window and then the scroll was reset to top :(
Handling resize is a different beast than being responsive. Working for every viewport dimension under the sun is not the same thing as gracefully handling an animation while the viewport size changes - the latter is much more challenging.
I agree, I was not even expecting it to handle the resize well. I just thought the landing page wanted me to resize my window to test responsiveness (before I noticed that the animation itself changes the content area size).
That being said, when resizing a window, the scrollbar should not reset/jump to top. At the very least, it should revert to what it was when going back to full size.
Bravo, been looking forward to this but AnimeJs v3 has just been so solid for so long honestly you did amazing on v3 that v4 is just icing on top; excited to try this out on my next project.
async/await + animation (ie- with AnimeJS) is highly underrated.
And mad props for skipping the now dying trend of refactoring entire codebase to TypeScript :)
It could just be me running a CPU that's too old or an unconventional browser (Microsoft Edge), but the website is extremely laggy (less than 1 update per second) and the tab immediately starts using 80% of my CPU with fans blaring. Got an 8th gen Intel i7 if it matters.
It's a laptop GPU - there's the integrated Intel UHD Graphics 620 card and the dedicated NVIDIA GeForce MX150. Both are pretty old (6-7 years?) but are capable of running most 3D games so I was a bit surprised.
EDIT: P.S. What might help debug is that I have hardware acceleration enabled in the browser, but the GPU is not doing any work on the animejs homepage. For e.g. YouTube, the GPU does a lot of work so I've verified hardware accel works.
I feel like web tech is getting a lot more mature and reliable. Just my personal vibe-read, but JS libs on the whole seem to be getting to be consistently hitting higher quality bars.
That's what I came here to ask too. This looks wonderful, but I'm already using Motion quite a bit. I'm also using React and am unsure how well Anime.js pairs with that while Motion has a first party react library.
In any case, like everyone else here, I'm very impressed with OP's site and documentation. Very slick!
Ah, I looked at the examples but I guess I missed this. Thanks!
So it basically works outside of react land — you can animate your component but it’s applied after react renders it. It’s nice to see an example and that it works, but I suppose it does mean there are certain things it’s unable to do, such as animating on component removal (Motion does this by adding a wrapper component that detects when its children are removed, I suppose it’s not something you can achieve without special react specific support)
Ooh, this reminds me a lot of MooTools' optional FX package back in the early aughts. I've still got it in a couple places because it's been difficult to replace.
the website is just a blank black page for me no matter how long I wait. clearly that's not what it's supposed to be going by the other comments, so that's a bit disappointing.
I remember using the same library few years ago for a stagger effect. Glad to see it's still alive and doing even better. The intro experience was beautifully crafted. It has me convinced to add an use to my projects
Love that the source is in Javascript, with type annotations. The compiled files in the /lib folder are also much smaller than I expected. I will likely be using this.
just as others mentioned, the whole landing page and the docs page is really nice work. It was loading well and the final scroll to bottom :). Thanks for the library and the work put in.
Quite impressive, and the showcase of breaking changes on the git repo gives the impression this release comes with a much nicer API than the previous one.
this is amazing, in my experience I haven't found much utility for visualization heavy UX. Like professionally.
I have spun up landing pages and things for things I've monetized. The crypto crowd loves it. But I don't put that stuff on my resume
What do you all use snazzy UX for?
I do find creating and expressing myself this way to be fulfilling though. Which is good enough, I just never considered myself doing it for the art and art communities. Websites aren’t really consumed that way.
Devs, please don't use this. it is unusable for me when browsing in a VM with a pretty snappy internet connection. The only other site that has compute/graphics resource issues for me is Netflix (its competition Prime, Youtube,etc.. have no issues, so i can only presume bad software dev decisions).
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 shipped over the wire, or, at the very least, I can't readily conceptualize how that would be implemented.
I feel it's totally within scope for an animation-focused library to expect clients to have GPU hardware acceleration. The fact you're running in an isolated environment, and haven't configured it to be able to use your host machine's GPU (which is possible!), feels niche enough to me to write off.