

Tumult Hype 1.6's New Features - now with CSS Filter Effects - ryannielsen
http://tumult.com/hype/whats-new/1.6/

======
amanojaku
What techniques did you use to keep the runtime file size small?

~~~
tumultco
Blood, sweat, and tears :). It was part policy, I wanted to keep HYPE.js below
40 KB which is important to some markets (advertisers) and didn't want to slow
down the web.

My best recommendation is to always use Google Closure Compiler. By default it
doesn't work much better than other minifiers, but there's an
--compilation_level ADVANCED_OPTIMIZATIONS flag that can have a dramatic
result. To use this, it is likely you'll have to structure your code
differently and make sure exports work correctly, but we were able to take
reduce a further 50% with this one change. In this release, we also changed a
few other flags (in the code itself; there are no command line settings) which
we thought would be advantageous to our file and userbase.

We also do a lot of string replacements. I built a simple templating system
that glues files together and also can replace descriptive, programmer-
friendly, key names with single letter variables. Strings can weigh a lot. In
this release in particular, I also looked at the minified JS and examined
which strings could be partially combined. For example, "rotateY(0deg)" and
"rotateY(10deg)" could both have the "rotateY(" extracted and save some bytes.
It matters less if you're using gzip compression, but we can't guarantee that
among our users. The key is to make sure this doesn't make the code hard to
read or edit in the future, and only tackle the most significant changes.

Not quite related to the HYPE.js runtime, but we also focused on reducing the
entire export data size, including the JSON animation info. We again used a
lot of string substitution -- "startTime" and "duration" in code simply become
"s" and "d". With JSON, depending on the key name you might also not need
quotes around them, so for an animation object it could be {s:1.2,d:3}. The
quote characters can add up! There's lot of other things we did such as not
exporting the common/default values since we could figure this out if the key
does not exist, and being smart about element id's so they would not be some
long UUID.

