Edge Conf 3 Notes

Published on 23rd March 2014

These are my notes of the brilliant Edge Conf 3. It was an incredible honour to be part of the discussion with so many people that I've respected and learned from for years. Unfortunately my laptop ran out of battery soon after lunch so these notes do not include some panels such as accessibility and future web.

You can also watch the videos on Youtube.

Web Components

View source was a good way to copy code, also OOCSS BEM jQuery etc, Web Components is a standardised way of making reusable code
Three parts:
Custom Elements
Everything is an element
Extendable video is=video-camera for example
Create a prototype object, register the element, can add methods
HTML Imports
Can import custom elements, with extensions etc
Shadow DOM
All browser elements tend to be made with Shadow DOM, it is the DOM inside the DOM.
Template element prevents it from being rendered until explicitly told to,
Mutation observers
Scoped
Microsoft involved in Mutation Observers
Microsoft are the proto-hipsters of web components
Polymer and X-Tags, use the same polyfill
To what extent do web components break performance by breaking parallel? — Yoav
Server rendered html is always faster
There is an async attribute that stops it from blocking
Much easier to reason about if you do block while loading other resources
Provides new tools without taking away any
Can minify many files into one
Can load simple components first then complicated components later
You can shoot yourself in the foot, or not
With complicated UIs you might be best to not go for a simple version first, otherwise the web app wont work
On a native app you see a static screenshot before it loads
Can be faster to heavily cache components locally
Some rendered server side some client side
CPU etc effect it
Polymer team are part of Blink, identifying common patterns for optimisation
Should the browsers not have solved everything that all frameworks are already doing?
A lot of room for opinionated ui
Cannot put a full set of breakpoints, will break other designs, not reusable enough
People are join to see how hard it is to make a select element accessible etc.
Before shadow dom, developers were not on the same level as browser vendors
Wont feel native enough if not developed by vendor
Dont we have a fundamentally problem that we cant make responsive design based on component instead of browser? - Jake
Very hard to do
Loops in rendering
Components should be about behaviour, not style
Scoped style helps
Had to drop decorators (html in css)
How do web components fit into CSP?
It is possible, chrome apps do it
Security in general?
Still have CORS
Should be fine, havent tried to break yet
iframes for security boundary, not shadow dom
Do web components encourage developers to break semantics?
I like semantics on a gut level — Nicole
ARIA roles
Developer maintenance is an advantage of semantics
Weve already abandoned semantics with presentations html
Repeating same mistakes, opportunity with new technology to stop making the mistakes
We are always going to make mistakes -Nicole
Knowingly develop against mistakes - Remy
Will we have loads of select boxes because everyone have different objectives?
Makes it far easier for teams dont have to worry about writing over other peoples selectors etc.
Styled scopes are kind of the child of OOCSS
Facebook engineering focus on predictability
Cannot predict dom without abstractions
Internalisation made easier by components at Facebook, including react
Down to developers to internationalise
Worried about dependancies
Most of polymer is polyfill
There should be competition between components so the most popular should be more accessible
Hard to be better than native ui controls
Drop in accessible components
Extending native ui elements is a big advantage, rather than creating from scratch
ARIA roles in shadow dom
ARIA is to get to native — Jeremy
Passing the buck to ARIA unless there is a concept of ARIA components - Jeremy
Make the primitives as accessible as possible
WAI-ARIA spec
In what use cases would you use polymer or x-tags over alternative component frameworks? — Andrew
Are the existence of polyfills going to help or hinder adoption in other browsers? — Andrew
What if every component brings in their own version of jQuery etc? — Remy
Dont want to return to dynamic drive
Different components can rely on same library without downloading multiple times
Be responsible.
Run it through a build system at Facebook
Polyfill should go down to 0

Developer Tools

Firefox dev tools:
WebGL shader editor
Visual transforms
Audio breakpoints
Chrome dev tools:
Screen mirror, type on keyboard to mobile
Flame chart visualisation of javascript profiler
Device emulation
Async call stacks, across XHR
IE12 Dev tools:
Network tool with nice waterfall
Memory profilers
UI responsiveness
Chrome dev tools on Firefox using Remote Debug
Brackets
Live HTML dev
Live CSS dev
NoFlo
Visual paradigm for writing javascript applications
TraceGL
Visual see which conditions failed
SpyJS
Run loops for events, identify how they map
Earhorn
Similar to light table
Show variables live updating in code
Heatmap of where code is most expensive
Adobe
GUI for css shape
Ember and react have nice plugins
Tools can help fill in gaps in knowledge
Trying to mimic Dreamweaver? Should dev tools become a full IDE?
There are things that the browser knows that you can only know by being the browser
The answer is both.
Brackets ties in more closely with browsers than the average IDE - NJ
You may not want to live in the browser all the time
The browser has a lot of information that is not exposed, perhaps it should be? — Kenneth Auchenberg (Remote Debug)
The responsibility of browser vendors is to expose it
Everything is exposed over a TCP socket
Should there be a standard protocol?
Often want to write non-browser code, such as server side so want an IDE for that
Lots of different workflows, command line etc
Solution is both kinds of tools
Need to learn each browser tool
The key sequences are same between firefox and chrome
Colours are the same
Vendors are trying to help make it easier
Should there be a unified tool or does it hurt diversity? — Shane (me)
Optimisation techniques that will work in one browser and not another
We have an obligation to tell you what our browser can do
I dont just want one tool, but as a developer I dont want to switch between multiple tools — Kenneth
Workflow shouldnt be too different, breakpoints etc
Standardise what everybody needs, but it is hard
Browser developers want to innovate first and standardise later
Should it go to W3C/WHATWG?
Need to agree on baseline
Discuss API details
Very hard to interface with dev tool
Start with JavaScript API instead of protocols
Experiments have to come before standards, should be debuggable but want to get in there and debug while browsers catch up with me — remy
Given all tools, who still use console.log as default? Most of audience
Dont have to navigate and interface to do it
debugger; is better if you dont know what youre looking for
Audience question - For mobile development I dont want to jump into dev tools, it interrupts flow of touch events etc so looking back at a snapshot of whats just happened is more useful. Thats why I dont use debugger.
There are lots of deprecated APIs, how can tools guide developers towards better code without running a specify profiler?
Splitting firefox dev tools into log and dev tools perhaps, would make a complete mess of the web console
Linting tools built into dev tools for deprecation and jank etc
Firefox OS has a float about all of that
Pre-processor?
Disclosure of bias, worked on firefox dev. Whats stopping every browser from allowing headless dev tools like phantom js? —Kyle
Whats stopping us? Nothing
What do you want from headless?
Spin up a chrome or firefox testing tool, like slimerjs
Chrome team using similar to test for regression, public but not standardised
Breakpoints aren't much help when debugging high frequency events
Phantom JS is not chrome but it is chrome from a few years ago minus some bits
For testing purposes you want to extract data from dev tools so should be part of the api
Could RemoteDebug help if there were headless browsers
With window.error being so flaky, would it be possible for browsers to ping an error to the server with an error
No error reporting when CORS broke
Metatag for error?
Where native is good, web should be better
CSP has logging
CORS isnt on window.error
Privacy issues
Contributing to dev tools should be easier, how can I get involved? Things like greasemonkey made it very easy to hack the page. — Remy
Chrome not good at that
Part of Blink source
Dont want people to fight for resources and break each other
Not a limit in firefox but breaks often
Custom extensions in angular
Greasemonkey script for dev tools
Better deployment or for self?
self
Low barrier of entry
Scriptable interface allows a way to mockup ideas for dev tool developers
Not advertised well enough
Big starting step to point to external dev tools

Build Tools

If youre anywhere near a build process, youre a software developer, deal with it
30k installs a day on grunt
Do we want 2.5k grunt plugins and gulp plugins and etc.
Building software is not new, the tools may be new but it isnt fundamentally new
Unix command line tools are changed together, grep doesnt need a sort plugin
Invariable in our language and tool of choice at the moment
Not browsers responsibility to give hooks into build process
I think it is a dreadful idea to standardise these things into css and html and js, it would be awful to have a transpolar for every tool out there — Kyle
Build processes there for a reason and will stay — Kyle
Bare bones is better
We dont have a good track record of bringing in ideas from other languages, often doesnt work well
Probably not the best idea to have native tools like coffee script etc
The good part of a tool is that if it doesnt make sense, you can throw it away. Once it has been in the browser it is there to stay.
Should CSS be optimised for being preprocessed
It is hard to define what should be standardised and what shouldnt
There can be a barrier to entry of putting Node.js in environment
Embedding Node.js runtime in JVM?
Node.js wont be the tool forever, standardise JavaScript and then any server side tool can use it
The rise of node lets front end developers have the power to tap into server side without learning another language
Huge dependance on npm, been some bumpiness to it
You can spin up your own npm instance
Are we relying too much on github?
What do government people say about relying on beta software?
Version is red herring
Only value in the eye of the author
Build tooling on front end is still very young
Standardising on task spec
These tools are useful but the wars distract from why we are doing a build process in the first place
Call existing tools instead of relying on wrappers: coffee instead of contrib-coffee
Just go for what is more familiar
Hard to build spec that will match architecture of all possible tools
Build tool discussion skips over the actually things done inside the build tools, instead arguing
Just write a script that repeats the small tools you use — Kyle
Unix files work with text but web scripts are not all text, need to be able to pass objects
Powershell has object passed between pipes
A major theme is sharing and getting into the community but flip side is I want to build the best app
Development stage plugins for browsers instead of recompiling sass etc?
What if we didnt have build process for dev at all?
Thats just moving the same stuff around, if Node isnt fast enough then use C
We are used to refreshing to see changes instead of compiling code like Java etc
Dont over do it, keep it clean and simple
5 minutes should be max for build script
File watching, serving files on the fly
Incremental recompile. Changing one sass file doesnt mean the whole directory should be recompiled.
If the browser understands sass or coffee script doesnt that make source better? We have source maps at the moment but shouldnt browsers understand the language? — Jake
It is still a build process if you have split it over the browser
Sass shouldnt go into browser until it is considered done
People got into web dev because it was so easy — Christian
Power tools for power users
Just use html css and js if that is all you need
Source code is not for the computer, it is for the developer, computers only care about 1s and 0s — Kyle
JavaScript is where it is now because we didnt let it hold ourselves back
Cannot recompile old code in 5 years if not standardised

Page Load Performance

Too many sites are too slow
We know how to make sites faster
Minimise Latency
Minimise round trips
Minimise blocking
There is a tension between how we build sites and the best way to get them to the browser to get the browser the load the page quickly or render quickly
Maximise the value of the first round trip
Browsers are doing a great job at performance
HTTP standard recommends we have 2 connections but many have 4,6 or even 8
Speculation
Preloader
Faster JS
New image formats
New Protocols
SPDY, HTTP2
We keep adding more to the pages including more render blocking requests
We can automate optimisation
We dont measure enough
Beyond which pages are slow, why are they slow
How do we fix it?
We dont have the tools yet to get there
We think of performance as a technical issue, it is not. It is UX.
We need to design for performance
Its just another constraint
Performance budget put forward but Tim Kadlec at Clearleft
We need better tools
We need to be careful about new technologies, we have http2 coming but we dont know what impacts it may come with
Are there still cases when mobile specific is best given that performance can be helped now on mobile
You can have separate teams but that is uncomfortable
The first 15k may be different on mobile or desktop
Responsive design is a compromise
FT still have separate mobile site and web app, but more of an organisational constraint than technical
The more things you support, the more compromises
When they shrunk YouTube they got new audiences
What does it take to deliver your initial experience?
The responsive websites are three times bigger
It is damn hard to build a fast site
Does concatting and spriting become an anti-pattern with http/2?
If we split them out they could cache individually
When do they become anti patterns?
You could argue spiriting already is an anti pattern, if you have to download all sprites when you need one icon etc.
HTTP/2 makes it more obvious
You can gradually pull down what individual pages need when not concatted
Can you detect which version of HTTP they are using?
SPDY will push to cache even if it is disabled
Mod_pagespeed is protocol aware
SPDY in IE11, Chrome, Firefox
What is the new golden metric? Or is there one?
We need to know when the above the fold content is in the browser
You are the one that knows what you care about
Measure everything
Generically measuring is difficult
Analytics, A/B testing etc are invisible to user
Try to target when user starts to see something
Page isnt ready at page unload but it is usable
Is there a golden metric? No.
Rise in large single page web apps
Instrument it
Possibly adding load event timing handlers to images etc
If using local storage is that causing another problem if they run out of space
IE11 has lazy load for images, should there be an attribute for main content?
postpone does the opposite
Do we new tools for single page apps
What role will front end optimisation tools play?
Try to avoid magic
Learn education process
A lot of companies are trying to take care of performance and security
Business will dictate it, it takes a lot of time