React Simple Animate – UI Animation Made Simple(react-simple-animate.now.sh)
react-simple-animate.now.sh
React Simple Animate – UI Animation Made Simple
https://react-simple-animate.now.sh/
49 comments
Your library claims to be 'dual license' but your license file is empty.
Just my personal opinion, but it's unlikely anyone will pay for this given the amount of free alternatives, and it's unlikely anyone will use it in OSS projects because there is a paid tier.
Just my personal opinion, but it's unlikely anyone will pay for this given the amount of free alternatives, and it's unlikely anyone will use it in OSS projects because there is a paid tier.
One reason why I might choose this paid library instead of a free alternative: it's made with TypeScript, and that means no fiddling with outdated type definitions (fixing and submitting updated types to DefinitelyTyped, talking the owner of the library to adopt types, etc) and no using a library without typings. That alone is worth at least a hour of my time.
I checked the first two React animation libraries I could think of, and they’re both written in TypeScript and MIT-licensed:
https://github.com/react-spring/react-spring
https://github.com/Popmotion/popmotion/tree/master/packages/...
https://github.com/react-spring/react-spring
https://github.com/Popmotion/popmotion/tree/master/packages/...
Those are both very good libraries and I did a lot of research on them before deciding to write SPHO. I'm planning to write an article on my findings but I can pretty much guarantee you that SPHO will save you many hours over those libraries.
The funny thing is that even doing a proper investigation of the different libraries will easily take you over an hour.
The funny thing is that even doing a proper investigation of the different libraries will easily take you over an hour.
The fact is the OSS alternatives do have high quality type defs so there's no trade off to be had here.
Like I said before, it's just my opinion, but I'd take a library with thousands of stars and a group of people maintaining it over something unknown and paid any day. If you think it's a good idea to pay for this, more power to you.
Like I said before, it's just my opinion, but I'd take a library with thousands of stars and a group of people maintaining it over something unknown and paid any day. If you think it's a good idea to pay for this, more power to you.
Licensing information is now available.
> My philosophy is different though that I want to make it absolutely dead simple to make UIs animate organically vs being a feature-filled animation library.
Is OP's library not trying to be dead simple?
Is OP's library not trying to be dead simple?
I think they sacrificed some simplicity for flexibility. e.g. having two different APIs (Component one and Hooks one) vs just one. That decision alone will have a very large cost initially and over time in working with the library.
I think hooks are cool, but this proliferation of two APIs when using/authoring libraries is concerning to me.
I think hooks are cool, but this proliferation of two APIs when using/authoring libraries is concerning to me.
Why would anyone pay for your non-free software when there are hundreds of great alternatives?
Gonna write more on this but short answer is that developers time isn't free. If using React SPHO saves literally one hour in all the time you're using it (could be years) vs these other alternatives then you're already ahead.
And I tried to design it so that it saves you and your team a lot more than an hour.
And I tried to design it so that it saves you and your team a lot more than an hour.
I would pay if I found the library better than the free alternatives. Specifically, I would pay if the library allowed me to reach my goals faster: simple, well-designed, not doing too many things and well documented and maintained are the key factors.
One reason for paying is to ensure that the library is maintained: too many people out there assume that labor is free.
I would not pay for anything that isn't open source, though, because I do not want to become fully dependent on something that might disappear.
One reason for paying is to ensure that the library is maintained: too many people out there assume that labor is free.
I would not pay for anything that isn't open source, though, because I do not want to become fully dependent on something that might disappear.
Because OP has an incentive to continue supporting his library
Will have a closer look later today. It's always a pleasure to find useful libs written in TS, thank you!
Thank you too :) feedback welcome
This looks promising, animations in React are a bit of a mess right now.
React-motion requires a PhD to figure out, and I'd rather stick pins in my eyes than use Transition Group.
I have had some moderate success with Popmotion, although I've also seen performance issues when staggering lists (likely down to my implementation rather than the library, but still).
React-motion requires a PhD to figure out, and I'd rather stick pins in my eyes than use Transition Group.
I have had some moderate success with Popmotion, although I've also seen performance issues when staggering lists (likely down to my implementation rather than the library, but still).
Try react-spring. It has a Hook-first API now, which is quite good. It's much less confusing, IMHO: https://www.react-spring.io/
I totally agree with you. This is why I built React SPHO (https://github.com/ismailman/react-spho). It handles animating auto, animating elements coming in or going out, etc. All the basic stuff you want to do (and some of the sophisticated stuff too) becomes super easy to accomplish.
If you have an example I can take a look at, I can investigate. The only performance issue I know of is when we unmount components in a PoseGroup when others are animating.
Thanks for your kind words! I built this because I want to solve simple animation in a simple way. In fact, there is no way I can compete with those big animation libraries out there, they offer tons of feature. React Simple Animat is more like a little tool to help on a simple animation task and require as less learning as possible.
I usually just animate with refs. When a React component root or its DOM children require complicated animations I will not allow them to update as per normal, just initially mount them and then animate via direct DOM manipulation.
>I'd rather stick pins in my eyes than use Transition Group
Why not? In combination with styled components it covers pretty much all my animation needs. The only thing missing is stagger for lists and maybe some way to integrate FLIP into it.
Why not? In combination with styled components it covers pretty much all my animation needs. The only thing missing is stagger for lists and maybe some way to integrate FLIP into it.
Pretty much because of staggering
I mean, stagger is trivial to implement with styled components, I only mentioned it because it's not out-of-box. Also what solution are you using that has stagger? I don't see it in pose docs, are you using popmotion-pure?
There's something about OSS that fails to do (or i'm not sure if it's OSS job): Teach how things work under the hood.
Normally, it's beneficial 100x times when a OSS project tells how things work in a concise manner.
In that way, it made sense for both users (they actually want to contribute back if they figure out how things work).
One failure example is Next.JS. You never understand how things work under the hood without digging source code.
Normally, it's beneficial 100x times when a OSS project tells how things work in a concise manner.
In that way, it made sense for both users (they actually want to contribute back if they figure out how things work).
One failure example is Next.JS. You never understand how things work under the hood without digging source code.
I get not wanting to push source maps to every client but it would be awesome if your browser requested them when you opened the console and if it became common practice to include them with your shipped website.
This is exactly how it works, and by default production build of create-react-app produces source maps.
I am more than happy to share how to build it. I will write a blog on it soon.
How is that possible that Svelte already has cool animations out of the box, but the react ecosystem still struggles?
Eg. how could you animate a component which gets replaced to a whole different part of the DOM-tree in react?
Eg. how could you animate a component which gets replaced to a whole different part of the DOM-tree in react?
It's kinda counterintuitive to have an element called <Animation />.
What happens if I render it two times in a row before it's done animating?
It's not an element, it's a component.
That may sound pedantic but the distinction is important.
React components aren't a "virtual DOM", they are a "component tree" that gets synced to the DOM. A component may or may not correspond to one or more elements in the DOM and it may wrap other components.
Thinking of "rendering" a component as "syncing the DOM" seems to be a common misunderstanding, especially when it comes to performance concerns (because manipulating the DOM unnecessarily is bad).
That may sound pedantic but the distinction is important.
React components aren't a "virtual DOM", they are a "component tree" that gets synced to the DOM. A component may or may not correspond to one or more elements in the DOM and it may wrap other components.
Thinking of "rendering" a component as "syncing the DOM" seems to be a common misunderstanding, especially when it comes to performance concerns (because manipulating the DOM unnecessarily is bad).
You do render it twice. For example, when toggling the `play` property. It looks like the component will adjust smoothly.
been using https://www.react-spring.io/ with https://github.com/d3/d3-ease to good affect
starting to look as simple as QML :p (https://qmlbook.github.io/ch05-fluid/fluid.html#animations)
I tend to avoid software that has "quick", "simple" or "easy" in their name. More often than not they are neither of those things :D. All jokes aside, congrats on getting this out!
thanks, buddy, take a look it's actually not that bad, cause the library itself its only 2kb. it can't get too complicated :)
Thanks so much sharing praveenscience.
No <blink>? Weak!
someone should check the grammar on the homepage.
Maybe English isn't their first language?
yea its true :(
sorry about my English :( I will try to correct them
Here's the one that I've been working on recently: https://github.com/ismailman/react-spho
My philosophy is different though that I want to make it absolutely dead simple to make UIs animate organically vs being a feature-filled animation library. I think React-SPHO is actually the easiest to use animation library for React available as most things you want to do "just work" and anybody reading the code using the library knows exactly what's going on without having to read any documentation so ramp-up for basic use cases is effectively instant.