Notes from Edge Conf 2014 London

I was lucky enough to be invited to attend and speak at Edge Conf London 2014, an assembly of web development superheroes charged with discussing the future of web technology in front of a live audience. I’ve written up my main take-aways from the event.

Web Components

Web Components Panel at EdgeConf  3 Web Components Panel at EdgeConf 3

  • Web Components are the custom elements that you’ve always wanted. If you’re after a <google-map> tag, web components can give it to you.
  • The basics are registering a new element with the DOM, then you can do anything
  • Web components are imported with a HTML link element: <link import=”component.html”>
  • To make these components useful, you need to use the Shadow DOM – this is the DOM inside an element, which is already being used on the web: take a look inside Chrome’s dev tools at an <input type=”range”> element – tickers are <button> elements inside the <input>
  • There are no browsers that support this out of the box yet, so there are two polyfills that you can use: Polymer (Google) and X-Tags (Mozilla)
  • The Server/Client rendering trade-off is the concern at the moment. Any JS downloading in a web component will block rendering unless specified as async. You can also compress and minify web components and their resources, which is a necessary step to get anywhere near good performance. We’re adding new tools, but the old techniques still apply.
  • Responsive components, that have media queries related to their own size, aren’t possible because they could be influenced by the parent too, which will get the rendering engine into infinite loops.
  • On semantics and accessibility: they are still important, but with ARIA roles not caring what element they are on, you can make anything appear like anything, so the argument that web components are bad for semantics is kinda moot.
  • On SEO, the usual rules still apply, you’ve got to make your content accessible and not hide it, but the search bots will read web components
  • On styling, using scoped styles (a level 4 spec) works very well, as these will override at scope. However, using an object-oriented CSS approach makes this easier. It is, however, generally harder to make all of your CSS into OOCSS, which is more of a team/rigour problem.
  • In the end, you’re responsible for packaging and de-duplicating your resources. Web components will remove any duplicate files from the same origin, but it’s still very easy to import two versions of jQuery. You are responsible for that.

Bruce Lawson has another very good write-up on this session, and web components in general on his blog.

Developer Tooling

Developer Tooling Panel at Edge Conf 3 Developer Tooling Panel

  • Firefox’s in-built developer tooling has come a long way from Firebug, with new features like deep scoping of function variables, great memory profiling and visual descriptions of CSS transforms
  • Chrome’s dev tools will have a better call stack flame graph
  • Brackets does great in-line CSS editing and rendering
  • Remote Debug aims to solve the complex workflow issue, where a developer knows how to use Chrome’s dev tools, but not Firefox’s, and it will let you use Chrome’s tools with Firefox.
  • JS Promises aren’t in the dev tools sets yet. We need to experiment with the technology and then make tools. We can’t make tools for something that doesn’t exist yet
  • Use debugger; rather than console.log – you may as well use alert()
  • It would be great if we could inspect headless browsers with dev tools so that we can see what went on with a test
  • It was also noted that contributing to dev tools is harder than it could be. Remy Sharp suggested creating some kind of Greasemonkey scripting capability for dev tools

Build Tools

Build Process panel at Edge Conf 3 Build Process panel

  •  Building software is not new. The Unix make command is 37 years old.
  • We are trying to avoid a plugin apocalypse with grunt, gulp, bruch etc re-inventing the wheel
  • A big mention in this session of the Extensible Web Manifesto as a basis for how we should be developing these tools
  • There are things that belong in our build process, and things that belong in our browser. With Sass, variables should be in the browser, but minification and compilation should not.
  • As a community, we need to be responsible with what we put into the standards
  • Having NodeJS as a dependency is reasonable right now. However, we should standardise our tools on JavaScript, rather than on NodeJS. Node is a runtime, and it will be superseded eventually.
  • Use git, not github. Use the npm protocol, not npm. The basics are great, but we can’t rely on services like this
  • More tools fuel innovation. A single task spec as a way to describe tasks between the task runners would be great, but this is on hold as they currently can’t agree.
  • On Grunt/Gulp – use the tool you’re comfortable with, and make the most of it.
  • We are still in the early days of build tools. Being locked in to a certain tools for 5 years probably won’t hurt, because at least you’re using a build tool!

Page Load Performance

  • “Put it in the first 15KB for ultimate performance”. Load content first, then enhancements, then the leftovers, and you’ll get great performance
  • Use sitespeed.io and webpagetest for your synthetic testing
  • Looking at The Guardian – their branched loading model saves them 42% with their responsive site
  • There will still be times when an adaptive site, with proper redirects, will give you better performance. I can vouch for this: Yell.com on the desktop is around 700KB, the homepage on mobile is around 60KB.
  • HTTP2 will make spriting an anti-pattern, as it makes it easier to only download what you need. Remember, it’s only the network that needs the data in one file
  • If you own your site, instrument it. Target StartRenderTime, and use Window.performance for better timing. Look to improve the Page OnLoad Event.
  • Resource Priorities and timing APIs will arrive soon. You’re encouraged to use these in your Real User Monitoring (RUM) stats. Not many companies do this at the moment.
  • Finding out is a user is getting page jank is a hard problem as you’d have to hook into RequestAnimationFrame

Pointers and Interactions

I was on this panel, so I’ve not got any notes! Thankfully, Google were there to video it for everyone

Accessibility

Accessibility panel at EdgeConf 3 Accessibility Panel

  • For accessibility, complying to geo-specific regulations is important, but, complying with the law doesn’t make your website accessible
  • Are WCAG guidelines outdated? No, their values are still good, but there are more complex use cases since it was written. For example, gaming accessibility is about making visual cues auditory
  • Mechanical audits of a website don’t give you the full accessibility brief. It can give you ARIA roles, colour contrast, click regions and alt-text etc
  • Try the Chrome Accessibility Tools extension, and the SEE extension, to see your page though different eyes
  • If you want to know what it feels like to have a muscular problem, try using your mouse with you non-writing hand
  • Accessibility needs to be considered at the design stage – if done at the QA stage, you’ve missed the point

Future Web

Sadly, I wasn’t at the event for this, but here’s the video for you all to enjoy

Related Reading

I loved the conference, I’ve not learnt so much in a day in years! Here are some other write-ups from around the web:

Going jQuery-free

It’s 2014 and I’m feeling inspired to change my ways. In 2014, I want to go jQuery-free!

Before I get started, I want to clear the air and put in a big fat disclaimer about my opinions on jQuery. Here we go:

jQuery is an excellent library. It is the right answer for the vast majority of websites and developers and is still the best way to do cross-browser JavaScript. What I am against is the notion of that jQuery is the answer to all JavaScript problems.

Lovely, now that’s done, this is why I want to do it. Firstly, as lots of people know, jQuery is quite a weighty library considering what it does. Coming in at 32KB for version 2.x and around 40KB for the IE-compatible (gzipped and minified), it’s a significant chunk of page weight before you’ve even started using it. There are alternatives that support the majority of its functions in the same API, such as Zepto, but even that comes in at around 15KB for the most recent version, and can grow larger. The worst thing for me, is that I don’t use half of the library, all I really do is select elements, use event handlers and delegation, show/hide things and change CSS classes. So, I want a library of utility functions that only does these things.

Word to the wise, this is not a new notion, and follows on very nicely from the work that Remy Sharp has done in this area in his min.js library.

I’m going to write a series of posts as I attempt to separate myself from jQuery, and make my websites leaner and faster. The first of which will be on “what you think you need, and what you actually need” and give you ways to work out if this approach is for you, or if you should be sticking with jQuery. Next, I’ll cover the basics of what a minimalist jQuery library; and finally I’ll cover strategies for dealing with unsupported browsers.

Let me know if there’s anything in particular you want me to cover, and I’ll do my best to go over it for you.

I’m Hiring, Come and Work with Me

Update 4th Feb 2014: I’ve successfully recruited two new developers to fill these roles, thank you to everyone who has applied. I will update this page as roles become available.

I’m looking for two very talented developers to come and join me at hibu to work on yell.com. With over 22 million users a month, Yell.com holds a prominent position in the UK’s online industries. Over the coming months, we are looking to push the boundaries of our user interface to maintain and improve our usage and user satisfaction. As part of the Technology team, with your help we will use the latest technologies to design exciting new interactions for desktop and mobile browsers. It’s a tough challenge, and to do it, I need some great people to join my team.

Here are the two job descriptions: Front End Developer and UI Developer

I’m looking for people who are adaptable and are willing to learn new technology quickly. I’m after developers who will do the right thing for the long-term, over fixing a problem quickly. I want developers who are familiar with new technology, and how it can be applied to get the absolute best performance out of the web browser, and importantly, I need someone who can appreciate the differences in browsers and know how to get the best out of them, no matter how big or small the screen size is.

In return, you will get freedom to implement features as you see fit, and access to the tools that you need to do your job. The role is based in central Reading, just by the mainline train station (25 minutes from London Paddington). The office itself is large and spacious, with a great restaurant/cafeteria on the 10th floor with some of the best views over the city, and pretty decent coffee throughout the rest of the building. There’s a whole host of other benefits (including competitive salaries, naturally) that you’ll be told about if you join us.

If you want to apply, or know more information, contact me, tweet me, or just apply. Please note, you have to be eligible to work in the UK or hold a valid work visa to get either of these roles.

These roles are now filled, I will update this page if more roles are available

Are you browsing comfortably?

I was lucky enough to be asked to speak at Remy Sharp’s Side View conference in Brighton this weekend, a part of the full frontal conference event. I tried to give an overview of the state of the web on TVs and how our current attitude to responsive web design works, or rather doesn’t work, on big screens. Here’s the slides and abstract.

The Responsive Web Design trend was triggered by the need to make the web presentable on small, handheld devices. Now, the Internet is encroaching on every aspect of our lives, and it won’t be long before it takes over large screens too.

How much of manufacturers’ internet TVs claims are true? Will the next generation of consoles bring the Internet to the living room, or will Chromecast be the gateway to the large screen future, and where do web developers fit in?

Lets make a web site that is suitable for the sofa

Update: The video is now online via Remy’s YouTube channel and is embedded below. I’ve also written about this topic for the 12 devs of Xmas, if you want to read through the talk rather than watch it.

The most common question I got after the talk was, “What inspired you to do the talk, did a client ask you to do some TV work or something else?” The answer is simple, I just wanted to know how it was and tell people about it. I know that members of the Opera developer relations team have done much of the research into the web TV for the opera web TV product, and I’ve always wanted to hear them talk about this subject and wondered why they didn’t do those talks – the technology to make it happen exists. So I did my own research into the problems, and now I understand why they don’t talk about it much. The whole web on TV experience is a mess, the technology promises a great user experience that doesn’t live up to expectations, and almost actively discourages the browser usage in favour of pre-loaded app experiences.

Now that the research is done, I an going to look for better answers. Luke Wroblewski is doing this, as is Ethan Marcotte, and in this industry, when heavyweights like those start to investigate, there is clearly a problem to solve, and probably a mindset change to happen to enable our industry to grow and embrace this technology.

I hope you like the talk, let me know what you think on Twitter and in the comments