The past week I attended the 2013 Fluent conference in beautiful San Francisco (it was seriously awesome weather almost the entire time, compared to the unseasonably cold and temperamental Chicago). The tagline for the conference is “Javascript & Beyond” and is put on by O’Reilly. I went in with the goal of trying to find the interesting talks and learn more about new technologies (not frameworks) and techniques for writing better Javascript (both individually and with a team). Overall, I feel like I was pretty successful achieving this goal, seemingly being in the most discussed talks almost every session (I did miss a few) and I got to hear about some of the new things coming such as ECMAScript 6 (the next basis of Javascript), Web Components (this stuff is crazy), additional tools in Chrome/ium. There were also a good set of talks about techniques to improve your own and your team’s code (Javascript focused but most of the ideas are pretty universal).
In terms of upcoming web technologies, the biggest (for me) is the stuff associated
with the web components talk. The idea of the ShadowDOM to allow for strong
HTML encapsulation (basically iFrames without all the suck) and the advent of HTML
imports. The ShadowDOM stuff allows for HTML+CSS+JS snippets to be placed in a
sort of self contained DOM that controls output. This encapsulates the namespace
and styles so that overarching parent class selectors and large DOM queries in JS
can be avoided. This allows for the creation of custom elements, meaning you can
associate a template of a ShadowDOM action to a single HTML element such as
<slide> then rendering the internal markup within a custom system as a slide.
The markup at the root looks the same, but in the end, the browser will render this
element as an encapsulated ShadowDOM. Along with HTML imports, you can then load
all of these custom elements from anywhere (different files or from CDN repositories
of common element types, such as different types of inputs, presentation markup,
etc.).
The talk that I got the most out of was the first workshop that was about improving performance in serving and rendering web sites. The major point made in the presentation is that the magic barrier aimed for is to serve a MVP (minimum viable page) in under 1000ms (1 second). For the presenter (a googler) this is targetted at all devices and circumstances. This means that low bandwidth and slow mobile data are included. He broke down the overhead for the various connection styles (3G, 4G, and desktop) showing the large cost of the allotted 1000ms. Along with rendering time, there is not much time for the initial file load, forcing you to asynchronously load everything that isn’t critical and inline everything that is (for the initial page load, everything else loads async and will enhance the page progressively). The part that really got me was how thorough and well designed the process needs to be to achieve this 1000ms limit on slower devices. He then showed the drawing rates as well, about how the browser renders frames and ways to try and detect when a lost frame occurs (meaning that there is higher priority execution that is blocking the rendering from occurring). There are tools in Chrome to help detect these and try to help eliminate them (the Chrome DevTools were shown a few times and look like they are going some neat places). Overall, there is a lot of ways to try and enhance the speed of an application for both loading and continuous execution.
There were also a number of interesting talks about team building and Javascript
tools/strategies. I will probably write up more in depth about them in the future.
One that I found interesting (and a bit controversial) is a talk about how browser
versions are dead and development should use feature detection to disable or
polyfill differences between each browser. I agreed with this concept that rather
than shame or disable entire browsers due to lack of effort, development should just
handle the conditional whether a browser supports that specific feature at the
feature level, i.e. if a <video> tag is used and the browser doesn’t support
that, handle the issue based on that and not that the browser is IE8 and just give
a landing page making them feel bad. More granular support for features is a must
for the web to advance. This can be helped a lot by Modernizr which does
feature detection and gives ways to detect and allow for a developer to easily
handle the support or alternative to support a feature.
Overall the conference was interesting, there are a multitude of things I found interesting and will probably continue to follow up on. Hopefully I will be proactive in wrapping my head more around the various things and writing about the things I learn… hopefully.