jQuery UK – Morning Sessions

Last week I was lucky enough to attend jQuery UK, a¬†conference focussed around front-end web development, the technology and tools behind it. Despite the title, jQuery UK isn’t focussed exclusively on jQuery. This year’s keynote speech from Mark Otto was specifically about CSS, and a couple of talks discussed practices which avoid using even JavaScript.

The conference mostly took place across two streams, which means I can only report on around half of the content based on the sessions I attended. I specifically tried to attend talks that could be relevant to the work we do in Apps, and so missed out on topics like game development and WebGL. When the videos for the remaining talks are uploaded I’ll scan through them as well and write a follow-up post.

I’ve split my talk descriptions into two posts: morning and afternoon. I should also note that I’m providing this write-up from the point of view of IS Apps, so some stories might not be as relevant to you as others. I’ve provided a tl;dr with each talk which will hopefully help suggest which you might want to read more details on.

Edit (24th March): Updated each talk with its video and slides where possible.

ES6 is the answer! What was the problem? (video)

tl;dr: New ECMAScript features are very useful and can be used today with a suitable preprocesing transpiler.

The first talk of the day was from Dave Methvin, president of the jQuery Foundation. He talked about ECMAScript 6 (aka ECMAScript 2015, and the “formal” name of JavaScript), the features it would offer and how to get started using it today. ES2015 has recently been adopted as the name for the standard since the work is being released on a per-feature basis rather than having one fixed draft (like the living specification of HTML and other current technologies).

New features in ES2015 fall into two categories: There are new functions which are polyfillable (like Map and Set), and syntax changes which aren’t, but can be transpiled (like let, yield and destructuring). Transpilation involves writing code in one format (like ES2015), and having it converted into a different language (like the current JavaScript standard, ES5). This means that you can write code using futuristic features, but still provide something that the browser can understand. Dave suggested using Babel as a ES2015 transpiler, and this definitely seems to be the weapon of choice at the moment.

Dave also provided some examples of new features in ES2015, and I’ll provide a few here (note that there is much more to ES2015 than what I show below). Native browser support of these features can be found here.

See an interactive demonstration of some of the new ECMAScript features.

What does this mean to IS Apps? For those of us using preprocessors, adding Babel (or another transpiler) to our build process is a great way to start writing futuristic JavaScript today.

mdoular CSS (video | slides)

tl;dr: Write well documented CSS, and define good rules to follow. Avoid silly selectors and overwrites.

Mark Otto, of GitHub and formerly Twitter, and perhaps most notably the co-creator of Bootstrap, provided his ten top guidelines for writing CSS.

  1. Simple class structure. Mark suggests that all selectors should be written as classes, rather than using IDs, attributes of tag names. This is difficult in SITS, which specifically locks down the class attribute, but seems like good advice in general.
  2. Identifiable classes. Make it obvious what your classes do without knowledge of the rest of the application. Avoid common terms like “button” because it will make it hard to search your codebase for usage (which is why Bootstrap uses “btn”). Abbreviations can be helpful, but avoid inventing a new language.
  3. Base classes and prefixes. Create base classes (like “btn”) and use that as a prefix for common variations (like “btn-danger”). Avoid having multi-use classes (like a class “danger” that works differently with buttons or text), because they quickly become difficult to maintain.
  4. Minimise overrides. Writing an override is often just an acceptance of writing bad CSS from the off. However, this can be more easily said than done when working with big applications: most pages in SITS come with the default Tribal-written CSS and Bootstrap before any project-specific CSS appears. In particular, when this code involves bad selectors (see point 1), it can be very expensive to overwrite.

    Also, avoid using shorthand styles since these contain overwrites. “margin: 20px 0;” is a bad idea, instead “margin-top: 20px; margin-bottom: 20px;” is preferable since it doesn’t override the margin-left and margin-right properties.

  5. Keep it CSS-y. With preprocessors, it’s easy to get carried away and attempt to write CSS more like a programming language. Whilst variables and nesting are very helpful, avoid using @extend as it can quickly cause bulk. Mark noted that a GitHub deployment recently contained an extra 300 selectors because of a rogue @extend statement.
  6. Minimise nesting. It’s mostly unnecessary, and classes can do the job just as well. Nesting also ruins specificity. Good places to use nesting are code organisation tasks, like grouping pseudoselectors (.btn{ :visited{} :link{} }). Any nesting that goes beyond a two levels should be heavily considered.
  7. Mark Otto's CSS declaration order (source)
    Mark Otto’s CSS declaration order (source)
  8. Formatting matters. “Every line of CSS should look like it was written by the same person, no matter the number of contributors.” Mark noted his code guide, which includes an expected order of properties. I also always write my properties in a specific order and find it greatly helps code maintenance. Whilst forcing style doctrine on people can be a bit heavy-handed, I certainly think we could aim for more consistency.
  9. Document guidelines. Mark advocates for documenting not just what your CSS does, but how and why it does that. This is very pertinent in IS Apps, where many different developers can end up touching the same code. NB: GitHub’s “Primer” should be released next week and will contain their guidelines for CSS writing and documentation.
  10. Embrace utility classes. Classes like “left” which just contain “float:left” make your elements’ class lists descriptive, rather than relying on component-level classes to contain a bunch of functional properties.
  11. Automate and track CSS. Lint, validate, grunt and test your CSS when it goes up to the server. Perform analytics on it to determine how efficient it is. Parker was mentioned as a good analysis tool.

What does this mean to IS Apps? We don’t have any big sets of code standards for CSS (or JavaScript), which could be a helpful means to ensure we have a consistent codebase. This is particularly pertinent in the SSP where everyone works on the same system and we often re-use the same files across multiple projects.

The cure for your Web Components hangover (video | slides)

tl;dr: They have a lot of potential, but aren’t ready yet.

Soledad Penad√©s from Mozilla talked about the state of web components, the shadow DOM and HTML imports. This talked covered a fairly broad range of material, and a lot of is too far in the future for the University to really consider. Whilst the features are promising, they’re still being designed and are very weakly implemented by browsers.

If you’re determined to use web components, the big tip here was to use webcomponents.js as a polyfill since you will definitely need one. It was also noted that Polymer and X-tag have similar functionality but aren’t technically connected to web components.

Soledad went through a few big libraries (jQuery, Angular, Ember and React) to discuss how well they played with web components, and the general consensus was “not at all”. Obscure and unexpected behaviour is rife.

Top tips for using web components:

  • Use the smallest polyfill available
  • Don’t use the is attribute.
  • Have a separate JS and CSS file for each component and preprocess them together when building.
  • Be aware of library nonsense in pretty much every major JavaScript library today.

What does this mean to IS Apps? Not much. Web components seem far too volatile to consider using in major systems at the moment, and presumably won’t be for a few years yet.

DevTools State of the Union (video | slides)

tl;dr: Chrome DevTools are continuing to introduce frighteningly useful features. Don’t use $(...).hide();

Google’s Addy Osmani drew the first audible gasps of the day as he demonstrated some of Chrome’s latest DevTools. I’m a big follower of DevTools and some of this still absolutely blew my mind. Addy’s presentation was very visual, which makes it more difficult to write up in a blog post. Nonetheless, I’ll endeavour to cover some of my highlights.

A current big goal in designing front-end applications is speed and efficiancy. 60fps is now the standard expectation of web apps, and the 2015 web performance model suggests that operations should not exceed the given time limits:

  • Load time: 1000ms
  • Response to user interaction: 100ms
  • Animation: 6ms
  • Idle (maximum time doing idle/cleanup work): 50ms (in case the user interacts and “wakes up” the app)

DevTools have some features to support this. Note that some features have only landed in Chrome Canary, others have been around for longer. Firstly, the network panel timing bars are being colour coded and redesigned to easily identify where common bottlenecks occur (e.g. if TNS problems are regularly occurring). The panel will also be more sortable, and has a growing myriad of filters you can apply (e.g. “domain:google.com” to show resources loaded from Google or “-.js” to show everything but JavaScript files).

The device emulation technology has had a lot of love recently, and particular attention was drawn to the “network throttling” setting which allows you to limit network speed to emulate the experience of using, say, 3G. This provides some very interesting results.

The timeline panel is now much better at recording what’s going on behind the scenes. You can now identify what’s causing layout changes and browse the history of call stacks in your application (which comes up again in an afternoon talk). In particular, the 3D layers history you can explore through the timeline is incredible. Admittedly, not many of our applications use 3D layers, but the general idea of exploring rendering layers is fascinating.

Performing some heavy debugging on Path's Programme Builder with Chrome DevTools.
Performing some heavy debugging on Path’s Programme Builder with Chrome DevTools.

More features included on our whistle-stop tour:

  • An eye dropper when you’re editing a colour.
  • An animations explorer which lets you pause animations, and slow them down.
  • An inline cubic-bezier editor for transition timing functions.
  • Script blackboxing: Treat scripts (like jQuery) as a blackbox and skip them in the breakpoint debugging process.
  • When editing a JavaScript file, it’s run through a validator to find errors before running the code.
  • Debugging of promises.

Addy also took us through a case study Google ran on Wikipedia to assess their JavaScript usage and potential bottlenecks, which provided some interesting advice. Most of these were to use native functions rather than jQuery (which seemed funny at a jQuery-centred conference).

The main concern is that jQuery often makes unnecessary additional calls which can slow applications right down. For example, using the show() and hide() methods is far less performant that using the hidden attribute of an element, or a class. This may seem unlikely, but you can see from this jsPerf test how significant the difference is.

Some highlights:

  • Don’t use show/hide, use classes or the hidden attribute.
  • Keep DOM size low (don’t add thousands of elements)
  • Touch the DOM as little as possible: for example, don’t run a loop which adds a row to the DOM each time. Generate all the HTML first, then add it to the DOM. This means the browser doesn’t have to repaint the page repeatedly.
  • Where possible, use the native querySelector and querySelectorAll functions rather than jQuery’s $(...) matching. The native functions are faster and supported in most browsers.
  • Avoid using the $(':hidden') jQuery selector, since this can perform heavy calculation on the DOM.

What does this mean to IS Apps? We should be careful with high-performance applications using certain jQuery functions (I know Path is guilty of this), and use the DevTools (which are available in some form in all modern browsers) to identify and debug problems in JavaScript performance.

Bin your <select> (video | slides)

tl;dr: The <select> tag is misunderstood and misused by many users. In their place, use textboxes, radio buttons or other alternatives.

I expected this session to just resolve with “use a JavaScript plugin like Chosen”, but Alice Barlett from Government Digital Service (GDS) provided a much more interesting and unexpected discussion.

The GDS does a lot of user research. Some of it is very specific to their stack and sites, but some has more wide-reaching consequences. One such example is their research into select boxes, where they have found many problems. Alice showed us two incredibly uncomfortable videos as users attempted and failed to use select boxes to enter their date of birth. There are a few problems, but ultimately it comes down to the fact that the inputs have been badly designed and don’t work as expected:

  • Users are unable to close the select box
  • Users try to type into the select box
  • Users get confused with what focus means in a select box
  • Users on tablets try to pinch zoom, and then find options disappearing from their field-of-vision.

The date of birth research also identified that all participants could easily type their date of birth into a textbox, so Alice advocated for using those instead: clearly identified as day/month/year and with some level of validation, this solution was met with pleasure from users. Equally, the common dropdown field of “title” has been made a textbox on GDS sites, since it allows people to enter what they want to be called rather than developers pre-guessing what titles might be relevant. Since title is generally used to address the user who entered it, there’s no reason they shouldn’t be allowed to be called “Banana Sophia Jex-Blake” if they want.

Another option suggested was using radio buttons, the functionality of which is generally more obvious to users (though people don’t click on labels much). For small lists, this is an easy change that can have a really positive effect.

For larger numbers of options, Alice demonstrated a GDS-designed widget that used radio buttons in a vertically-scrollable box (which could be collapsed with JavaScript). This solution, which of course also displays identically on all devices, was well met by users. The widget also uses keyboard navigation if JavaScript is enabled and aria roles for accessibility.

Finally, Alice noted the GDS’s rules for creating a custom widget:

Whilst the last two points are less necessary at the University, I appreciated Alice’s point that users without JS and on old browsers are not doing so out of choice, but because it is the only option open to them. In some regard, it is those users who we should be working hardest to support.

There was one point Alice made about GDS that really rang true with me when thinking about the University: “Most users don’t want to be on our website, they need to be.” Whilst we work on a lot of sites with a lot of different goals, a large number of our projects are to make applications that staff don’t want to use but, for whatever reason, have to. We, like the GDS, should work hard to make sure these users get the best experience they can, rather than disliking the system even more.

What does this mean to IS Apps? This talk was probably the most identifiable of the day for me. We have a large user base, like the Government, to whom we are often providing a service that they have to use. For this reason, we should also strive to “do the hard work to make it simple”. This is something we should consider at all levels, including the information we collate. The idea of using textboxes for fields like Date of Birth and Title might seem unlikely but, given the research by the GDS, it’s clearly the sort of thing we should look out for.

Cover photo by Garrett Coakley under CC BY-NC license.