Addy Osmani’s talk about performance at the last FFConf had a small segment on serving brotli compressed assets, as opposed to gzip. The claims are that brotli produces smaller filesizes than gzip, so if you want to squeeze some extra performance out of your site, then just switch over and reap those rewards! The talk, however, was light on the implementation details. Well, I decided to take a look to see how easy the switch would be.
I’m not going to extol the virtues of encrypting your site and enabling HTTP/2. The advantages should be pretty obvious by now. The real issue is that when you’ve got your site(s) and your clients’ site(s) encrypted, you’re left with local development versions of the sites which are now at odds with the live version. And it’s always best to mirror your dev and live environments as much as possible to avoid those last-minute deployment panics.
Welcome back, dear Internet traveller. I hope you’re sitting comfortably, because we’re going to cover a lot of ground in this part.
The general aim of our ‘game engine’ is to find a small set of common object onto which the rest of the game is built. It provides us with some reusable components which simply help us keep a clean and maintainable codebase and provide some naming conventions down the line.
A year or so ago, I came across this post by Keith Cirkel, How to Use npm as a Build Tool and it stuck with me. At the time I was transitioning to gulp from grunt both personally and for Clearleft projects. We had a discussion about the feasability of going full NPM and decided that using gulp was still the best for us. There are plenty of great reasons to use grunt or gulp and we will continue to do so at Clearleft, but for my personal site I decided to experiment with pure NPM.
In building my own, what I want to avoid is overly-generic code.