MelbJS held an event last Wednesday, and the turnout was amazing in spite of the dreary weather. If I recall rightly, it was the biggest turnout for this event to date.

It must have been the impressive line up of speakers:  there were full presentations by Neil Jenkins, James A Rosen, and Ryan Seddon, and a couple of lightning talks by Tommy-Carlos Williams and Mark Brown. In this post I’m going to cover a couple of talks that I found interesting.

Optimising Javascript

Neil Jenkins spoke about the following ‘hacks for speed’ when it comes to optimising your Javascript:

  • Seek to reduce bandwidth consumption as the number one priority
  • Javascript is fast enough for all tasks apart large data processing jobs
  • Minification + concatenation
  • Modular selective loading of assets
  • Only initial ones upfront, and preload subsequent modules if predicted the user is about to need them
  • Parallel loading of assets
  • Cache everything
  • Doing away with a RESTful API. Blasphemy, you say? Indeed, doing away with a RESTful API is going against the grain of the current mantra, but he does make a good point, and provide a good alternative solution. Too much to discuss here – probably warrants another post in itself.
  • Transmit only deltas when loading lists of data, using a sequence number

I have previously written a review of some rather advanced optimisation strategies employed by the developers of the Financial Times app, and I think Neil’s hacks should be stepping stones – the basics upon which the advanced strategies can be built. (Note that there is some overlap, of course.)

Ember and Angular in production

The other interesting thing to see was that there was a talk both about EmberJs and AngularJs on the same night. Further to that, both of them were about rather large mature applications that have had to face scalability problems, and have had to solve them.

Some interesting points made in James’ talk was that EmberJs is very hard to use because the core framework was (and still is) in a state of flux; however, at the same time, they saw the need to keep the framework up-to-date. Ultimately they were unable to do so completely, but are in a state of limbo, employing some trickery to allow existing parts of the app to remain written in the old way, but newer parts to use the new way for the newer version of the framework.

Another thing worth noting is their deployment process, which boils down to uploading every single asset except for the index.html file, then making sure all of them can be hit successfully, before uploading index.html as the final piece of the puzzle. Because all of the files that have changed have different names (file names are suffixed with the first several characters of their MD5 hash – both Zendesk and Fastmail use this technique), it allows the old index.html to continue operating, business as usual, linking to the old set of assets. I found this quite an interesting deployment technique, although only a Javascript single-page application could apply it.

Ryan Seddon started with a spiel on why he chose to use AngularJs, having started out by prototyping in Backbone, Ember, and Angular. He discarded Backbone because he had to write a lot of boilerplate code to accomplish rather simple tasks. He discarded Ember because the framework was in a state of flux. He decided to go with Angular because he was able to become productive in it rather quickly, and its emphasis on testing.

I related to this, because it mirrors my own experience with these frameworks when I was evaluating them December last year. I really liked the ideas behind Ember, but I simply couldn’t get them to work, because all the stuff written about it online was for the older versions of Ember, which was subject to breaking changes. Since this, EmberJs has released 1.0.0 release candidates, and have been assured that apart from EmberData, the rest of its API is stable; I intend to give it another shot soon.

Ryan then went on to elaborate on various tips and tricks he used in production for Angular. A lot of this is also mentioned in the “Performance” section in the Brian Ford’s article on Huge Angular Apps, plus some things to avoid (e.g. HTML5 form validation), and some things to use (template caching, dumb ng-repeats, ng-includes to clean up views).

CSS Block, Element, Modifier

While nothing to do with AngularJs, Ryan also mentioned his use of BEM (Block, Element, Modifier), for his CSS. This is a technique I had not come across myself before, and a quick look at it reveals enough for me to revisit my critique of the CSS selectors in the Financial Times app. For more on CSS BEM, see a quick overview of the technique, or Smashing’s in depth look at it.

MelbJS goes from strength to strength each month. I look forward to the next one. You’ll find video recordings of the talks here:

This post was originally posted at MelbJS June 2013 Summary

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s