Edge Conf 3 Notes

Published on
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

  • http://www.w3.org/TR/wai-aria/

  • 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 (eg. 'touchmove' — Wilson (https://twitter.com/wilsonpage/status/446974904076...

  • 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