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.
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.
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.
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 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.
> 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 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.
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.
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.
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).
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.
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?
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.
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).
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!
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.