The text is appreciated, but too long. More importantly, there are no demos. That text is valuable but should be broken up into smaller sectional chunks, each associated with code and functional demos
The lack of a demo killed my interest nearly instantly; after hunting around and spending a few minutes and still nothing buried a level or two deeper, yeah I shook my head and moved on.
This is an animation library, you should have something on the first page right at the top, even if it's not a proper 'demo' (something to see/look at to get a sense of what this is capable of).
As someone who works with HTML and animation daily I greatly appreciated the detailed text. This isn't about what is made possible, it's about making it easier to structure larger and more complex applications that have significant animation.
Thanks, good to know it was of use. The concern you outline was very much the one I had in mind when developing Firmin—writing large, UI-intensive web applications where CSS transforms and transitions would be useful but too inflexible to use without some mediation through a JavaScript API layer.
Looks interesting but I can't figure out why there's no hosted demo. Hard to be inspired to think of a use case or want to play with it when I can't see a demo without pulling the code.
Just a lack of time, really. I actually wrote most of the library last summer, but then I quit my job and went back to university, whereupon my free time dropped precipitously. I'll see if I can rustle something up this evening.
I've been wanting something like this, thanks! It can be tedious to set up animations by hand in the CSS, and since animations have more to do with behavior than styling, it makes the code a lot cleaner.
A nice-to-have would be detecting the presence of common JS libraries, and falling back to jQuery/etc DOM-based animation on browsers that do not support CSS transitions.
Thanks, that's an interesting suggestion. I'll have to think a little about how it would work in practice—object detection is simple, but I'd need to make sure I could map the API well enough in each case for it to be worthwhile. If I did do that, it would probably be as an optional library (specified at build time), providing a fallback in the same way I intend to provide a fallback for browsers which don't provide an implementation of CSSMatrix. The other possibility would be to embed a minimal animation library like Émile [1], and just use that directly.
The other way of doing this would be to pull Firmin into more general DOM libraries as an alternative animation backend, and toggle between them based on runtime feature detection (for an example of how to do this, see [2]). A special case of that is doing it at the application level, in cases where the potential performance gains are vital; I mention an instance where I've actually done this in the article.
