MelbJS June 2013 Summary

— 5 minute read

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

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.

Some highlights from the talks

Optimising Javascript

Neil Jenkins on hacks for speed

  • 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
  • do away with a RESTful API (0)
  • 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 these should be a stepping stone to them - these are the basics upon which the advanced strategies can be built on top of. (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 by James 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, and 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 is essentially to upload every single asset except for the index.html file, and make sure all of them can be hit successfully, before uploading that final piece of the puzzle. Because all of the files that have changed have different names (1), this 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, as only a Javascript signle-page application could apply this.

Ryan Seddon started with a spiel on why he chose to use AngularJs. He started out by prototyping in BackboneJs, EmberJs, and AngularJs. He discarded BackboneJs because he had to write a lot of boilerplate code to accomplish rather simple tasks. He discarded EmberJs because the framework was in a state of flux. He decided to go with AngularJs 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 EmberJs, but I simply couldn’t get them to work, because all the stuff written about it online was for the older versions of EmberJs, and mostly included breaking changes.(2)

He then went on to elaborate on various tips and tricks he used in production for AngularJs. The same as what is mentioned as the “Performance” section in the Brian Ford’s article on Huge Angular Apps; and to add to that some things to avoid (HTML5 form validation), 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, he 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.

More on CSS BEM:
Smashing’s in depth look at the technique
A quick overview of the technique

(0) 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.

(1) File names are suffixed with the first several characters of their MD5 hash. Noteworthy is that both Zendesk and Fastmail use this technique.

(2) 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.

Video recordings of the talk: