Tag Archives: tween.js

tween.js mega changes

Yesterday I had my every-two-months lucky day in which I could sit down and work on tween.js, and DID I GET THINGS DONE!!!

The first thing I did was to get rid of the minified version. Since the build process wasn’t fully automated, I often forgot to produce and check-in that minified version, and people who used it would get all sorts of weird errors that I didn’t see (specially in Safari and iOS, as the polyfills we added would be in the uncompressed version, but not on the minified, sigh!).

Then I started using semantic-release as my invaluable helper for producing releases. Each time a push to the git repository happens, another service (Travis) runs a battery of tests to make sure nothing is broken. If the tests pass, semantic-release will get in action and (probably not in this order):

  • determine what’s the next “semver” for the package. This is a function of the type of commit you made (a bug fix, a new feature, docs, chore…). Important / breaking commits will cause bumps in the first digit, etc. (I suggest you read more on semver if you’re interested). The type of commit is specified by having the commit message follow a certain syntax. E.g. a feature will be feat: implement feature A
  • tag the commit with the version. E.g. v16.0.1. I believe this is what bower people use and desperately need, and I never provided because I don’t use bower and so didn’t notice.
  • create a github release changelog thingie in github. These go to the releases page in github
  • publish the new version of the package to npm

I think semantic-release can do so much more than this, but just having all these steps performed for me is A W E S O M E. So once I established this “infrastructure” I could go on and fix many other long-standing issues and also merge PRs and address questions.

Since we don’t have to produce a minified version, I got rid of gulp which is what I was using it for. Installing tween.js with npm is now very very lean because I also added an .npmignore and so it just essentially installs the code of the library only. Your trees will not include the examples anymore. Not that it was incredibly big but every byte counts to some people, it seems 😛

I also added jshint (for code correctness) and jscs (for code style) verification as part of the test suite. This was something that would put me off reviewing PRs… and specially explaining to people that it was not OK to change the whole whitespace in the file, or that they should respect the existing guidelines (even if it’s in the contributing file that very few read). So the rules are now there, and everyone has to abide to them, or the tests don’t pass and so the PRs are not accepted.

Interestingly, I added these steps using the advice in Kate Hudson’s talk from Nordic.js front-end automation with npm scripts, where she showed how you don’t actually need a task runner–I recommend you to watch it! Or check out her reading list on the topic.

Next up was dealing with a ton of sorta old and sometimes outdated PRs that had been lying in the guts of github for months. As I explained in my previous tween.js post, something had happened and I hadn’t even seen the notifications for these.

I prioritised FIXES first. Many people are coming up with some novel ideas and features, and I’m grateful for that, but I decided to focus on accuracy and robustness for now. Some aspects of the code are a bit obscure and I am not sure I understand them well, mostly because I just merged them in when someone proposed them, and now I’m paying the price when strange edge case errors are reported.

Of course, I’m still not done by any means, because there was a massive backlog and the day only has so many hours, and I’d like to do human things such as sleeping, etc.

This is brings us to this interesting paradox: many people use tween.js, including big agencies who charge a bunch for their projects, but only a very few submit code or respond to my pleas for help. Maintaining a JS library has become way more demanding over the years. Back in 2011 people didn’t care about npm, bower, tags and releases and what not, so working on tween.js was way more simple and less time consuming. I could have just put a zip file on a website, and people would be happy with that, for all that is worth.

But since I changed roles at Mozilla I am travelling a lot more, and it literally devours your time. I am not complaining about that, but I need quiet time to sit and get heads down on code, and I’m not having much of that lately. Mozilla supports me working on tween.js but I do have my own work duties which take priority. All my coding time is happening during working hours, and when I’m off work I like to enjoy my free time doing things such as being outdoors or just talking to people face to face, not via a bug tracker. Or despair about the list of issues and PRs growing and me not having time to even acknowledge them 😩

But before totally blaming open source for its toxicness, I decided to own this a little bit myself, and totally revamped the README file to make it a bit more welcoming and clear (I took heavy inspiration from Express). I have also filed some bugs and tagged them as help needed or good first bug respectively. If you enjoyed tween.js and want to give back by contributing to these bugs, you’d gain extra points of awesomeness.

People like roadmaps, so this is what I’d like to see next:

  • Review all pending bugs and PRs and resolve or close them.
  • Fix the things that have to be fixed and ensure all code is tested and clear before adding new features, because it is getting to a point where it is unwieldy and scary to even look at a diff (what even does this thing do!?). Hopefully the new automation will help here, and we can focus on logic and not on chores!
  • Divert all new feature ideas to the future ES6/ES2015/ESWHATEVER version of tween where everything will be super modular and you should be able to use parts of it as you need and hack other types of tweening engines as you see fit.

This is it for now. Thanks for reading, and happy tweening!

tween.js: what’s next?

tween.js is terribly popular despite being overwhelmingly simple and underpowered compared to other more awesome and batteries-included animation toolkits as CreateJS.

Yet it’s only me being the maintainer… or, let’s face it, the bottleneck, as I’ve been terribly busy with other matters these last months. I feel like I’m doing a disservice to the community by letting it stagnate, and that’s awful.

I’m sorry.

But I also need to be realistic that I just don’t have the time to maintain it.

The fact that it is under my “name” in github (github.com/sole/tween.js) doesn’t make it any more inviting for other people to feel a sense of ownership either, and I always felt bad when people said “tween.js by sole” because there has been a ton more of contributions by very talented people, and I never wanted to take their credit.

So I’ve decided to move tween.js to its own organisation to reflect the fact that it is a community project, not just sole’s project. Starting today, github.com/sole/tween.js is no longer the home of tween.js—it is github.com/tweenjs/tween.js.

It goes without saying that I am looking for people who want to actively contribute to tween.js. Ping me if you’re interested. Fame, glory, and my and the community’s eternal gratitude as perks.

The other good thing of moving to an organisation is that we can now have related projects living under the same roof. For example, a potential ES6-based version of tween.js.

I also found yesterday that for some reason I hadn’t got new issue notifications from github for the last two or three months, so there was a bunch of new issues waiting on me to take action. I am sorry about this too, and will try to reply as fast as I can.

Thanks to everyone who uses tween.js or contributes to it!

Meanwhile, in Mozlandia…

Almost every employee and a good amount of volunteers flew into Portland past week for a sort of “coincidental work week” which also included a few common events, the “All hands”. Since it was held in Portland, home to “Portlandia“, someone started calling this week “Mozlandia” and the name stuck.

I knew it was going to be chaotic and busy and so I not only didn’t make any effort to meet with non-Mozilla-related Portlanders, but actively avoided that. When the day has been all about socialising from breakfast to afternoon, the last thing you want is to speak to more people. Also, I am not sure how to put this, but the fact that I visit some acquaintance’s town doesn’t mean that I am under any obligation to meet them. Sometimes people get angry that I didn’t tell them I was visiting and that’s not cool :-(

Continue reading

tween.js r14

tween.js r14 is really more of a “cleaning house” revision than anything else. No new features have been added, but the library should be a little bit more usable now and lead by example by using better code examples that aim to be efficient JS and CSS wise:

  • Include license header on the minified files too (hyandell)
  • Make examples more efficient by using requestAnimationFrame‘s own timer instead of calling Date.now again (Robert Eisele)
  • Make it explicit that you can install tween.js with npm and bower (sole)

As usual, you can download it/clone from github or install with npm:

npm install tween.js

And as a “new thing”, although it was always here, installing via bower is also possible:

bower install tween.js

You can also read more instructions and code samples on getting the library.

Cheers to whoever told me you could install any package using git with bower. I believe it was the magnificent Edna Piranha! So thanks Edna!

tween.js r13

tween.js r13 is a much expected update (I hope) that brings three little pieces of joy:

  • New onStop callback added, by colinsullivan
  • Fix _reversed yoyo flag bug, by deanm
  • And last but not least, the initial version of docs/user guide, by sole

And also available via npm:

npm install tween.js

While writing the docs I found myself wanting to show how to use custom functions, so I also wrote another example that demonstrates this. And wrote a few custom functions plus some functions to generate functions. It’s all so meta and I love it.

In future releases I’d like to start clearing out the list of issues—some issues are there for years and I’m not even sure how applicable they are, and at least they should be reconsidered.

Most specially I want to make things more robust and cohesive build/user experience-wise. Things such as integrating with travis to make sure the tests are run when a PR is submitted, make examples accessible/visible easily and also enable access to the examples source code in an easier way–I had this notion of maybe preparing some interactive editor sort of demo so people can play with tween.js without even downloading the library or going to codepen or jsfiddle or similar. Maybe moving all examples to that style too. I still have to think about that, but suggestions are welcome. Working example suggestions are even more welcome.

Also–if you think you can improve the documentation, feel free to go ahead and send patches. SEND ALL THE PATCHES, AND THANK YOU.