fronteers14 part 2

Written by Vincent Bruijn

In my rondup of day one of Fronteers Conference 2014 I tried to touch most speakers at least briefly. For day two I want to do the same. As said, Fronteers 2014 is a well organised conference and one of high quality: speakers from Twitter, Google and Etsy are part of the line up. In addition to that it is held in a beautiful venue and a good lunch is served!

Day two kicked off with a talk by Nicholas Gallagher, who works at Twitter, giving a presentation on a recently started and ongoing process uniforming Twitter’s UI infrastructure. A company like Twitter which has grown very fast in a few years, it appeared that the knowledge of the company’s front-end structure was spread among many (ex) employees, which made them recently decide to implement ways of collecting this in a central point. One of the solutions was writing documentation within code and running an extractor to build browsable docs for all co-workers. One other detail which I liked quite much was, next to a README file, having an OWNERS file in the UI element’s directory, to keep track of who is the technical owner and who worked on the code. A good talk gives a “universal” message wrapped in a personal story, and that was exactly what Gallagher did. The only downside to his talk was his slight monotonous way of talking, but that did not devaluate its contents.

Next off was Dave Olsen on Optimizing web performance. For me, nothing new was mentioned here: Google Pagespeed Insights, the 14+ rules by Steve Souders (who was part of the audience by the way),, Google Chrome’s devtools, etcetera. But that does not mean I disliked the talk. I think web performance is an important side of front-end development and cannot be stressed enough, especially for this audience. Besides, every front-end oriented conference should at least have one talk on web performance, in my opinion.

Having used SVG only for background images and logos, it was very valuable to me to listen to Sara Soueidan, who had quite a technical and dens talk on animating SVG with CSS and SMIL. She packed a lot of information in her 40 minutes, and kept everybody’s attention: it was very quiet during her talk, which usually means the audience pays attention. It was a roller coaster of a talk: with easy to understand examples set next to each other in split screen, pointing out ins and outs of using CSS and/or SMIL for animating SVG, she showed she really did a lot of research on the subject: this is a woman with expertise.

Paul Kinlan drew us a (not so far) future vision of the web: headless web apps (i.e. running while the browser has no focus), apps having a live cycle and developers having full control over their app stack. Most of this will hopefully be enabled and available in the near future in modern web browsers. Leaves us with the Android browser and IE8… For this, most of us know, we can use, but wouldn’t it be great to work the other way around? Enter Kinlans, based on the JSON data of, this site gives you an opportunity to work the other way round. Another tool Kinlan showed was a command line interface app to retrieve different views on the data. This helps in creating cross sections views on browser support of various features. A bit of statistics showed supporting browsers n - 1 gives you most opportunities in using newest features, but n - 2 is usually already good enough.

Meri Williams’s talk can be summarized to this: being inclusive is important! This applies as much as to the real world as to the web platform. We should care about accessibility as much as we care about all those other facets we pay attention to in web development. Why pay extra for making a site accessible? In advance to this, define “done” appropriately. We have already defined “done” covering does it work for mobile, IE8-9-10, etc. Why not add a11y to this? If we’re on to asterisk-first (mobile-first, offline-first, …), we should also act accessibility first.

Although I really like Kyle Simpsons ongoing series _You don’t know JS_, I quite disagreed with the core idea of his talk. Being mostly a team worker, I really do not see the added value of having your own modifications of a language, apart maybe from the macros he mentioned. Writing JavaScript while paying attention to the good parts is I think the best approach, writing your own language parser so that you can write your own variant of the ternery operator, is in my opinion, as said working on a team, not a good approach. Reading each others code will be very hard, because you will have to get a grasp of each other lingual annoyances, which is only a waste of time if you would agree on its best parts. I will keep reading his books, but will not implement his suggested ideas, although I do agree with the fact you should write your own tools.

Former Facebook and Instagram employee Pete Hunt set different testing strategies along a regular development lifecycle. The matrix comming from this was filled in by him, setting the ideal momentum within the development process to implement the specific testing strategy. This resulted in a normative table which could, in my opinion, be used as a guide line to set up a solid overall testing strategy for a project.

Disclaimer: I have not seen the presentation by Petro Salema up to the end. My verdict: it was a visionary and more of a meta presentation on development. Core ideas: dream big, think small. And usually: ideas with large implications can emerge from small insights.