Edit (24th March): Updated each talk with its video and slides where possible.
tl;dr: Avoid things that block the page form rendering, like external scripts and fonts.
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
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.
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)
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 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.
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.
- 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
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
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
everywhere, 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.
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.
|Usable today in many different tools, and a great way to keep code organised.|
|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)|
|Best to avoid, in lieu of radio buttons.|
|Best to avoid, in lieu of classes or ||Evidence|