The best part is they don't try to do too much. Since you invoke them via code, not some all-in-one editor, that makes it much easier to go back to your code when you're done. I feel like that transition is most of the problem when dealing with other tooling (see Photoshop's "copy layer style as CSS").
So the idea was: you have your page -> you add debugging tools -> craft your animations -> remove the tools and animation still there.
Also, since project's resources are limited - we had to make those simple tools and then connect them to something more matured like https://github.com/legomushroom/mojs-timeline-editor (which is in the process right now). This way we are able to release MVP early and get feedback early while constantly improving the tools.
In any case, thank you for creating this and hope to see this project continue to grow.
You've done an amazing job creating an amazing library. One that I advertise every opportunity I get. Thank you!
I was doing a lot of animation work and there was a lack of animation tools I've got used to, so I've started to write modules myself. After a while, I noticed the system in what I've written so decided to release it.
As for maintaining part - it is heavily covered with unit and environmental tests, of course, it adds some overhead but ensures that your tool is robust and works in every browser.
It is a side project and we still expect more contributions from the community.
btw Great job with this project, I am going to use it for some ui elements in my projects, I especially love the twitter stars animation.
When you start an application, one of the two cards will handle that application.
I generally can't my browser with the high power card; probably because browser vendors don't want to sacrifice battery life all of the time for some fancy effects a small slice of the time.
But I'm no expert. Chrome seems to handle things better than Firefox, that's why I still have it.
The problems usually with the Chrome browser because it updates frequently and the Chromium team changes it a lot, so what was recently woking well might not work well right now. And problems like these are usually regard rendering performance and CSS transforms. So the issues you might see are related to the demos itself(not library) which were highly optimized for recent browsers' engines and those changed. I will revamp the demos shortly to keep them up to date.
Also, I often found that heavy animations work much better on mobile devices like iPhones than at my MacBook Pro mid 2012.
It works well in Firefox on my desktop from 2009 (with 4GB of DDR2) … Do you also have performance issues in Safari or Firefox ?
There's a lot of bikeshedding over terms in this field (especially in web development!), so calling something a framework vs a library vs a tool vs a package vs whatever else will eventually cause comment threads about it to be bogged down in debates on how it's not a "real framework" or that it's too big to be a tool, etc...
Calling it a "toolbelt" is a perfect word to me, and I really like it. To me it reads like a collection of "things" which can all be used together for some purpose.
Am I the only one who thinks we killed Flash and left a void which no one has filled yet it terms of animating with an intuitive UI?
How do you build a powerful tool and avoid that side effect? D3 is one example I can think of for a very powerful, yet constrained and focused tool (I would say opinionated but that word has lost all meaning).
ALSO: Very cool, well done.
Mo.js was released as a proof of concept a while back, but has matured into a similarly designed library with a much more precise focus on motion design. While GSAP didn't explicitly ever state it was for such a purpose, a significant number of designers use the library for exactly that in very large clients' animations.
As for the Pug and Stylus in that demo, you can view the compiled HTML or CSS within CodePen, it's in the little dropdown arrow in the top right corder of each box