When I heard about jQueryTO, the Toronto jQuery conference, I got excited—a jQuery conference a few hours away by plane, train, or automobile? I’m in! My co-worker, Karen Ford and I both attended, and walked away full of new and exciting ideas.
I was a bit apprehensive leading up to the conference, since it wasn’t put on by the jQuery Foundation, but the amazing lineup of speakers put my mind at ease. I have to commend Darcy Clarke and all of the volunteers and local folk from Toronto that not only put on a great conference, but also welcomed us into their vibrant community of developers with open arms.
Session Summaries
There was much more to each session than I could possibly document below, as well as many sessions I couldn’t attend. Thankfully, notes and slides, and in some cases, video, of most of the sessions have been collected and posted to GitHub.
State of jQuery – Dave Methvin
- Slides: http://slidesha.re/WyH62j
The opening keynote was an update on the State of jQuery by the jQuery Foundation president, Dave Methvin.
- Did you know that the same number of people search Google for jQuery as do those searching for JavaScript?
- He discussed the jQuery versions 1.9 & 2.0 roadmap, and how both would continue to exist and progress in feature parity to a 1.10 and 2.1 version, respectively.
- jQuery 2.0 will not support Internet Explorer 8 or before
- There is a jQuery Migrate plugin to help make the transition from v1.x to v1.9
- A very emphatic point was to “Stop linking to the latest version!” Make controlled updates to the jQuery version you are using so that your code doesn’t break.
- //code.jquery.com/jquery-latest.js
- //ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js
- jQuery 2.0 is also being built on EcmaScript 5 (ES5). Dave went on to explain that although all of the code related to bugs for old versions of IE had been removed from 2.0, that all they really did was shift the problem onto older versions of some of the other browser engines, namely old WebKit which don’t yet support ES5.
For anyone looking to get involved with jQuery, there are plenty of opportunities. Dave recommended checking in on IRC (#jquery-dev, #jquery-content, #jquery-meetings) to ask where help is needed, if people aren’t sure where to start. Adam Sontag went into more detail on how people can get involved in his talk on Day 2.
Device API with HTML5 – Wes Bos
- Slides: http://bit.ly/ZG00TI
In this session, Wes talked about the different APIs that currently exist in mobile /modern browsers for accessing the hardware sensors, without using a third party like PhoneGap or similar. Using just JavaScript, he showed how to access four different types of sensors:
- Accelerometer
- File System
- Crapstagram, uses FileReader (HTML5 spec) and Canvas to add a single filter to an image entirely in the browser
- Device Compas
- Camera & Audio (WebRTC)
- The browser can request camera/audio access, and if granted, can stream that directly into an HTML5 video element. Wes showed a pretty cool demo of manipulating live video with, among other things, a green screen effect and face recognition that added glasses to faces.
- Wes also showed an example of using the real-time video stream as a motion detector, with a demo of how he could have his computer notify him when the mail-person had been to the house by comparing video frames.
Overall, the state of the device access in HTML5 is getting stronger all the time, and this was just the tip of the iceberg for what is possible now or will be in the future as more device APIs are released to the browser.
When jQuery and CSS3 collide – Louis Lazaris
- Slides & Additional Info: http://bit.ly/ZG1X2r
Louis talked about how jQuery and CSS3 animations can co-exist in harmony. By simply adding a class on an action using jQuery, you can then let CSS3 handle the actual animation or transition action.
One common problem front-end developers run into is that they are afraid they won’t be able to execute a callback function once the animation completes, something that jQuery makes really simple (just pass a callback function into .animate). However, you can listen for the event “transitionend” and “animationend”, prefixed if necessary, and then execute additional code when an element finishes its CSS transition.
There was no discussion of how to polyfill browsers that don’t support CSS3 transitions or animations, as browser support can prevent developers from being able to use these effects. The session was more focused on how to effectively use these effects in modern browsers.
Louis went on to talk about the page flow, and what elements and effects will cause the page to reflow, and which ones will not affect page layout. He then went over ways to make sure all the new animations and transitions won’t negatively affect page performance.
You Want Client Side Package Management – Ralph Holzman
- Slides: http://bit.ly/ZG21zc
This was a session about why we as front-end developers should both desire, and use, client-side package management. APT (Advanced Packaging Tool) in Linux, GemBundler in Ruby and NPM (Node Package Manager) in Node are some examples of package management done really well. However, on the client-side we are still referencing individual scripts manually and handling all of the dependencies manually as well.
Ralph went into some of the historical ways Package Management has been done for front-end work, including Plugins and Git Submodules, and the problems with each of those. The rest of the discussion focused on Bower, Component, Jam and Volo, some of the package managers that have managed to rise to the top recently. A good comparison of the four can be found here. He then did a demo showing how Bower could be used to build a site quickly while handling all of the package requirements.
Documenting Interfaces – Darcy Clarke
- Slides: http://bit.ly/ZG26D3
This session introduced DSS (Documented Style Sheets) in Darcy’s talk about documentation. He went through some of the previous documentation examples, like KSS (a Ruby gem for CSS documentation) as well as showing examples of good documentation in existing projects. DSS is meant to allow front-end developers to add a minor amount of documentation to their CSS files, and have a generated style guide based on that documentation.
Depending on jQuery – Alex Sexton
- Slides: http://bit.ly/ZG27XI
Alex talked about how to use require.js to include jQuery in your project and to register it as a dependency, rather than just including it with a script tag. There was significant discussion about how using modules (either AMD (asynchronous module definition) or CommonJS style) can improve your code. Plus, jQuery defines itself as an AMD module already, so it is relatively easy to use in this context.
One of the interesting takeaways from his session, which wasn’t even the main point, was that jQuery should almost never be included from a CDN (like Google CDN) but rather, should be included as part of a single concatenated/minified JavaScript file served from your site. Afterwards, while asking him about this, he pointed out that in real world testing, less than 2% of sites actually get any caching benefit from using the CDN, and there is the additional overhead of another DNS lookup and the separate HTTP request itself.
Gone in 60 Seconds – Addy Osmani
- Slides: http://bit.ly/ZG2bXv
Addy Osmani gave an excellent closing keynote for Saturday night that delved into the best way to fight “jank” on a site. Jank is a disruption in consistent frame rate that manifests itself visually. Higher FPS makes a site feel more responsive to the users.
The main points about how to create a great web app experience were:
- Snappy performance, silky scrolling and smooth animations
- Things should work
- Performance should be great on both desktop AND mobile (suggested testing mobile first, which will in general lead to good performance on desktop as well)
- A high frame rate—your FPS (frames per second) need to be 30 (minimum) to 60 (optimal) to avoid a poor experience. Most importantly, your frame rate should be consistent.
The session was a pretty deep dive into using the Chrome developer tools, particularly the Timeline, to debug bad performing websites. Using Pinterest’s website, Addy showed how to go about debugging which elements and/or styles are causing performance issues and how removing the box-shadows around each pin instantly made the site performance much smoother.
What things slow down frame rate in the browser?
- Doing too much inside of an event handler
- Doing almost anything on scroll—such as rearranging elements on the page
- Long image decodes—avoid large image files
- Unnecessary image resizes
- Heavy animation or data processing
- Repaints
- DOM node changes in JS
- Animations
- Interactions (hover/style changes)
There was some talk about the different CSS properties that are considered slow, but no general rule saying “don’t use these elements.” Rather, the theme was, try it, test it, and fix the things that perform badly. Browsers are always updating, and things that performed badly yesterday may not be a problem today.
When testing, the recommendation was to always use Incognito mode so that plugins and other tabs won’t interfere with the results. Then look for frames that are over budget (less than 30 FPS) and adjust the page until those frames are back within budget.
This was an excellent look into the ways to make your site run silky smooth and provide a great experience for the end user.
End of Day 1
That was the end of the day 1 sessions. Already the amount of new information was overwhelming and there were tons of new things to look into, and existing practices to update. The evening was filled with meeting new friends at various watering holes nearby the conference venue. For day 2, look forward to Karen’s Ford’s post coming shortly.
