This is the second of two posts discussing talks I attended at the jQuery UK conference. The first post covered the morning sessions, and this post will talk about what I saw in the afternoon.
Edit (24th March): Updated each talk with its video and slides where possible.
Architecting resilient front-ends (video | slides)
tl;dr: Avoid things that block the page form rendering, like external scripts and fonts.
Andy Hume from Twitter pointed out that we spend thousands on making robust back-end infrastructure, but have nothing in place to help if connection is lost or interrupted during a page load. This is almost progressive enhancement in the other direction. He noted that at the Guardian they had three priorities: Content (HTML and general CSS), enhancement (e.g. fonts, JavaScript galleries) and leftovers (e.g. adverts and analytics). The content was the most important thing to reach the user, whilst the enhancements and leftovers could realistically be forgotten without fundamentally stopping the user from getting what they wanted.
He then broke down the chain of events in a page load:
DNS lookup -> TCP connector -> HTTP request -> server load -> HTTP response
And pointed out that an HTTP redirect occurs before “server load”, so causes the first three steps to be done repeatedly.
He then went on to the chain of events used to display a page:
HTML parser -> DOM tree -> render tree -> layout -> paint
The first potential block here is during the HTML parser, where an external script tag (<script src="..."></script>) will cause the parser to wait for the script to load in (through the page load sequence above) before it can continue. This is why scripts should be included at the bottom of the page, or given the async attribute.
The next block is at render tree, and caused by fetching a stylesheet. This can’t be solved in a similar way to <script> because it would cause the page to load without CSS first, which would cause confusion to the user. Instead, you could put critical CSS inline, with additional non-critical stylesheets to be loaded later.
The final major block is fonts, which are handled slightly differently in each browser. Internet Explorer will load a fallback font, and replace it with the loaded font if it’s found. WebKit- and Blink-based browsers will block the page render until the font file is found, whilst Firefox and Presto-based browsers will block the page render, but give up after a timeout of three seconds.
To get around font loading issues, Andy recommends using a JavaScript font loader to give you complete control of when the font is loaded. The drawback to this is that the font may noticeably change after a delay, which could surprise the user. However, this is surely preferable to the render being completely blocked by unresponsive fonts.
What does this mean to IS Apps? Uptime can be very important for some of our applications, and some of the methods discussed in this talk are worth considering in our front-line projects. Generally speaking, we should bear in mind the way in which a page is loaded and attempt to optimise where possible.
What the heck is the event loop anyway? (No video yet)
tl;dr: Explained properly, the JavaScript runtime engine is fairly straightforward, and can really help in identifying performance problems.
In one of the best explanations of “under JavaScript’s hood” I’ve heard, Phil Roberts of &yet introduced us to the inner workings of the JavaScript runtime engine, particularly the call stack Web APIs and the event loop.
I would struggle to re-explain Phil’s talk in words, and may hold a full demo explaining the engine/event loop. Instead, here’s the basic premise (to go along with the image above).
The main JavaScript script stacks up functions as it needs them, and then removes them when they resolve. Some functions (like setTimeout, XMLHttpRequest, addEventListener) aren’t in the JavaScript corpus but are instead Web APIs, which the main runtime stack delegates to, before continuing with its duties. This is why you can’t use the result of an AJAX request after calling it, it’s with the Web APIs by that point.
The Web APIs then put their resultant functions (like an AJAX response) in the callback queue, and the event loop performs them when the stack has nothing else going on.
Understanding the event loop, and the JavaScript runtime in general, makes identifying and explaining performance problems much easier, and will be very useful hand-in-hand with the DevTools advertised by Addy Osmani in the morning session.
What does this mean to IS Apps? Understanding the event loop is an incredibly useful skill for people working with intensive JavaScript. I hope to be able to put on a session at some point going over some of the details and how the knowledge might be applied to our applications.
Dismantling the barriers to entry (video)
tl;dr: Ractive provides a good environment for non-techy people to easily create web-based visualisations without needing to understand technical points.
This talk was more of an advertisement/awareness raiser for Ractive, a library which speaker Rich Harris has developed with the Guardian. Ractive uses client-side virtual DOM to easily create powerful and performant front-end applications. Unlike potential “counterparts” like React and Angular, it is not designed for a full app experience but is more suited to a small component (like a visualisation). Whilst other apps uses heavy client-side templating, Ractive is designed to use a “virtual DOM” which can be updated at extremely rapid speeds, and to work well with SVG.
Ractive isn’t something IS Apps is likely to use in development, since we tend to build full applications rather than visualisations. However, as Rich expresses in his title, it could be a suitable tool for other members of the University (particularly researchers) to easily create interactive displays for their output. In this regard, it might be worth us investigating the library if we want to recommend it to colleagues.
Rich says “the web should be as open and democratic as possible, and we can help that”, pointing out that we are the keyholders with technical knowledge, and the only ones who can properly utilise the web.
He also provided a list of checks for anyone developing a JavaScript component:
- Use “readme driven development”, and write your high-level documentation before implementing it.
- Eliminate dependencies on other libraries (or include them in your production source)
- Don’t over-modularise
- Use Universal Modular Definition
- Share prominent download links
- Output helpful error messages
- Don’t require command line usage
- Provide lots of examples
- Eliminate jargon
- Empathise
What does this mean to IS Apps? Ractive is something we might consider using in Apps, but it probably has greater use elsewhere in the University. It would be fantastic to use Ractive as a way to display research findings, allowing researchers to generate interesting visualisations of their results, and building a local support community around the library.
Hacking front-end apps (video)
tl;dr: Be aware of common front-end vulnerabilities, don’t let users write to the DOM. Use CSP if suitable.
Alex Sexton of Stripe, the jQuery foundation and Modernizr provided a series of common ways in which the front-end can be hacked, and what we can do to avoid them.
- Content injection: If you let users insert content into the page, it may contain dangerous
tags. You should always sanitise anything that is user-entered. Alex also pointed out a colleague’s homemade User-Agent string which contains<script>alert('lol')</script>to irritate people writing bad analytics software. - CSS hacks: Hackers used to be able to tell which pages you’d visited by, say, having the CSS
:visited{color:red}and then using JavaScript to determine which links are red. Whilst this is now disallowed by JavaScript, there are still ways it can be implemented. My favourite was giving visited links complex styles which take longer to compute and then comparing render times per link. Hackers are devious. - JSON-P: JSON-P allows the response to contain JavaScript that will then be run client-side. For this reason, making a JSON-P request to an unknown service could cause any old JavaScript to be run. Don’t do this.
Ultimately, Alex explained that anything that makes an external request (including something as innocuous as background-image) has the potential to be dangerous. His prefered solution was to use Content Security Policy (CSP) to block everything risky (eval, function constructors, fonts, images) and then whitelist the things that you can trust. You can also provide a report URL to be pinged whenever something attempts to break the rules, giving an early warning if an attacker comes in or if you forget to whitelist a certain resource.
He also noted that CSP2 is coming soon (though isn’t in any browsers yet) and will allow better control over individual scripts and images. Final remarks: use HTTPS everywhereonly, and turn on HSTS.
What does this mean to IS Apps? We’re already doing a lot of this, but it’s always worthwhile keeping on top of the latest developments.
Real world jQuery (video)
tl;dr: You can do interesting things with a room full of 700 mobile devices.
The last talk of the day by Ben Foxall from White October was a bit more high-level. Ben asked us to stop thinking of browsers as browsers, but rather as just “things”, and then asked us all to turn on our mobiles and go to a particular URL.
This created a link between all of our devices and his server, a link Ben could use to pull out individual and demographic data. He showed us the battery life of the devices in the room (including which were charging), the light levels, and pointed out how much data you can easily crowdsource.
He then went on to push things back to the devices, causing them to vibrate and play sounds. Finally, using a crude triangulation method, we determined where in the room everyone’s device was, and a wave of colour and music was played out across the crowd in various directions.
Whilst the “Real World” name may have been a bit dubious, Ben’s talk certainly provided some interesting ideas about how we get caught up on browsers being web-delivery tools and not communicators to the device and it surrounding world.
To me as well this also highlighted that at the University we don’t always use the most modern options available. Whilst we have little use for accessing a user’s phone’s camera, we could certainly use location and orientation information (both widely supported) to add functionality to our apps.
What does this mean to IS Apps? We’re cheerfully developing for tablet and mobile devices now, but we should consider if we’re using them to their full capability. Almost all UK users support geolocation now, and yet it often doesn’t reach its potential (both within our department and the wider world). We should always be looking to get the most from the web platform, and using modern features where suitable.
Conversations around the conference
Talking to various people around the conference, it was clear that use of jQuery is very varied. Some are using it as a primary tool, others are experimenting for the first time, but the majority have been using it for a while though often not to its fullest potential.
Delegates I spoke to worked in PHP, .NET, C++, Node.js and many more back-end platforms, demonstrating that jQuery fits into all sorts of stacks. One C++ user was making native apps leveraging jQuery to help organise the front-end. He demonstrated a customer-initiated redesign that he did in one day, made simple by having front-end tools like jQuery and Bootstrap included. He also recommended trying Polymer as a good web development tool that takes some of the legwork out.
Another delegate strongly advised using Angular, saying that despite its weight it’s great for predominantly single-page apps. He noted that it has a massive learning curve (and lacks documentation in places), but was noticeably more powerful than Backbone (he rebuilt a Backbone project in Angular because of its offerings). Particularly of note is MVC separation which is well-organised and makes sense.
Generally there was a consistent buzz around proper client-side templating. Several speakers and delegates suggested that templating added great improvements to their workflow. There was no clear front-runner in the JavaScript templating world but, going forward, it looks like the addition of ES2015 template strings will be a great starting point.
Conclusions
I took a lot of information away from jQuery UK. I learnt about what other people and companies are doing, what mistakes we’re regularly making, and how we fit into the bigger ecosystem of web development. But one of the largest points of jQuery UK was the future of the front-end. We talked a lot about what’s coming next and I think the most logical conclusion I can write is what we can use today, and what we can’t.
| Feature | Status | |
|---|---|---|
| Build tools/ Preprocessing | Usable today in many different tools, and a great way to keep code organised. | |
| Content Security Policy (CSP) | Usable today. | Browser support |
| CSS transitions | Usable unprefixed today. | Browser support |
| CSS animations | Usable prefixed today as progressive enhancement. | Browser support |
| DevTools | Available in all major browsers and incredibly useful; generally well-documented. Features vary between browser. | |
| ECMAScript 2015 | Usable today with a suitable preprocessor. | Browser support |
| Geolocation | Usable unprefixed today. | Browser support |
| HTML5 forms | Usable unprefixed today. Partial support across all browsers, so use with care, but a lot of options available. | Browser support |
| Ractive | Usable today, could be helpful elsewhere in the University. | Documentation |
| Web components | Not ready yet, still incompatible with most major libraries. | Browser support (multiple tables) |
<select>
| Best to avoid, in lieu of radio buttons. | |
$().hide()
| Best to avoid, in lieu of classes or hidden attributes.
| Evidence |