Category Archives: Projects

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!

A three.js npm template

rotating demo cube

I can’t imagine dropping a series of <script> tags on a page to build a minimally complex website anymore. I’ve got used to browserify and so I can’t go back to building my fancy 3D thingies like it was 2012 all over again.

So I made this minimal template that sets the bare minimum you might need to build a three.js powered site using browserify via gulp. That lets you use any other npm-based modules and libraries you want! So your code should not be messy and/or a tremendously big file with everything tucked on it.

There’s also some extra help like a file watcher… and not much more, really.

Do let me know if you use it for something cool… or if you can/want to help on this issue! 😀


For the project I’m working on I’m building web components that sometimes require other components to build their UI. For example, the theremin-ui uses the slider. So they will try to load and register the component before creating instances of it. It worked fine when there was only one level of dependencies, but then I put all of the components on the same document, to let the user choose an instrument from the collection of Web Audio instruments, and I got an error from the browser complaining about… something:

NotSupportedError: Operation is not supported

I traced it down to the register() call, and I figured that I was registering an element twice. So I made safeRegisterElement, a one-function module I’m using now instead of directly calling document.registerElement:

var safeRegisterElement = require('safe-register-element');

// safeRegisterElement(type, prototype);
// e.g.:
safeRegisterElement('custom-name', customElementPrototype);

All my custom element modules have a register method that uses safeRegisterElement internally (this lets you register the element with whatever name you want to use).

In npm:
And sources:

“The disconnected ensemble”, at JSConf.Budapest

Here I am in Budapest (for the first time ever 😮)! I’m back in the hotel after having a quick dinner on my own. I didn’t join the party because I had a massive headache and also I was getting so sleepy, no coffee could fight that (also probably the two things were related). But once I started wandering towards my hotel I found myself feeling so much better, and stumbled upon a cosy nice place and ended up stopping there for some food.

When I came back from the speakers’ dinner yesterday, I practiced setting up all my stuff and going through the demos again, which are in fact ran on real, physical devices, i.e. phones.

Continue reading

Running a web server on the front-end

The introduction of TCP sockets support in Firefox OS made it possible to run a web server from the front-end, and all is written in JavaScript. Think of having something similar to express.js… but running on a browser (because after all, Firefox OS is a superturbocharged browser).

Again, JS server superstar Justin d’Archangelo wrote an implementation of a web server that works on Firefox OS. It’s called fxos-web-server and it includes a few examples you can run.

None of the examples particularly fit my use case–I want to serve static content from a phone to other phones, but the examples were a bit more contrived. So I decided to build a simpler proof-of-concept example: catserver, a web server that served a simple page with full screen Animated GIFs of cats:

Continue reading