Skip to main
Article

jQuery Chicago 2014

Five practical JavaScript coding takeaways from jQuery Conference Chicago 2014.

After attending conferences, I find it helpful to synthesize a few practical takeaways that I can immediately begin working into my code. Some of them are new, while others are common techniques that I’m just not in the habit of doing.

So what got my attention at jQuery Conference Chicago 2014? In no particular order:

Web Workers are here and ready for primetime (or at least close enough to ready). It would be nice to get some abstractions to make them easier to work with (and it’ll be great when SharedWorkers and ServiceWorkers get to the same level of support), but I’m not waiting around.

Basically, Workers provide the ability to run computationally intensive tasks in a background thread, without blocking the UI or other scripts. Workers don’t have access to the window object or the DOM, but they can pass data back and forth from the main client script.

Keep the UI responsive, and let Workers do difficult tasks in the background. (Aside: This is awesome. Why isn’t everyone using it already?)

// main script
var worker = new Worker('my_worker.js');
worker.addEventListener('message', function (e) {
  console.log('The worker said: ' + e.data);
}, false);
worker.postMessage('Hello Worker!');

// worker script ('my_worker.js')
self.addEventListener('message', function (e) {
  console.log('The client said: ' + e.data);
  self.postMessage('Hello Client!');
}, false);

Check out another (contrived) example to see it in action. Notice that the timer (and the entire UI) locks up while running the task without Workers, but continues smoothly when Workers are used. (I’m also using the Blob() constructor to allow for inline Worker scripts, instead of importing from another file.)

So when might I actually use Workers? From this helpful web.dev article:

  • Prefetching and/or caching data for later use
  • Code syntax highlighting or other real-time text formatting
  • Spell checker
  • Analyzing video or audio data
  • Background I/O or polling of webservices
  • Processing large arrays or humungous JSON responses
  • Image filtering in
  • Updating many rows of a local web database

Do you already use Web Workers, or have additional suggestions or warnings?

HT: @potch for the talk that got me started.

You know what else is here, and (mostly) ready for primetime? ECMAScript 6. Some of the new features I’m most excited about:

var name = 'Jonny';
var company = 'OddBird';
console.log(`I'm ${name}, and I work at ${company}.`);

This just scratches the surface. Check out a helpful summary, and keep a close eye on the browser support chart.

So how can I use these features without waiting for full browser implementation?

A subset of ES6 can be used by simply adding Paul Miller’s ES6 Shim. To use the more substantive features (e.g. template strings, default parameters, modules), compile ES6 code into ES5 using Google’s Traceur (probably with gulp-traceur or grunt-traceur).

HT: John K. Paul for his talk encouraging devs to use ES6 now.

Error objects have been around forever, and aren’t difficult to use:

if (user.id) {
  // do the thing
} else {
  throw new Error('User ID not found.')
}

But I’m not very good at actually doing this. When I’m writing code, I usually default to the “fail silently” approach:

if (user.id) {
  // do the thing
}

There are times when failing silently is exactly what I want: when the code will continue to work correctly regardless. But often it’d be better (especially in development, and maybe even in production) to throw an error with a descriptive message stating what went wrong. Not only does this speed debugging, but it also lets me know that something went wrong in the first place.

To make this simpler, I’ve started using runtime assertions:

var assert = function (message, test) {
  if (!test) {
    throw new Error('Assertion failed: ' + message);
  }
};

assert('User has an ID', user.id);

When to consider throwing Errors?

HT: Ralph Holzmann for his helpful talk.

Brian Arnold demoed how to use proxy tools for development and debugging.

Charles is a really powerful tool for anything from Ajax debugging and bandwidth throttling to DNS spoofing and local/remote resource mapping. I can view or modify outgoing requests or incoming responses (even from another device on the same network connected through Charles), essentially turn my computer into a dev environment for any website with resource mapping, throttle my bandwidth to mimic 3G or LTE, or disable caching or cookies entirely.

I’ve been using Karma as a test-runner, and I’m mostly satisfied with what it can do (notably: run tests quickly using PhantomJS to mimic a browser environment, and generate istanbul coverage reports).

But I’m intrigued by some of the features that Intern offers (notably: integration with Selenium, support for true browser events and running tests in standalone browsers, and built-in Travis CI integration).

Have you used either of these tools, or have further pros/cons to offer?

Recent Articles

  1. Fragment from a 13th century alchemical manuscript with a red and green oroboros serpent biting it's own tail, and seeming to give us side-eye
    Article post type

    HTML Web Components are Just JavaScript?

    I’m still getting used to this

    There’s been a recent flurry of articles about web components, with advice on how to shape them as extensions of HTML. I decided to dig in, and see how these ‘HTML web components’ could become a part of my own workflow. Despite a few rough edges, I’m excited to see…

    see all Article posts
  2. Article post type

    How to Design More Intuitive Websites & Apps

    Do you want to make your website or web app more intuitive for the people who visit? If so, I’d like to introduce you to the world of Object-Oriented UX. As a UX designer at OddBird, using OOUX strategies to identify and avoid unintuitive objects has been key to…

    see all Article posts
  3. Pen and notebook with a sketch of a website interface
    Article post type

    When to Choose a Progressive Web App

    Part 3 – Responsive Web App vs Native Mobile App vs Progressive Web App

    If you’re weighing the performance optimization and device integration opportunities of a native mobile app against the broad reach and lower cost of a responsive web app – and can’t decide which is a higher priority for your digital product – don’t despair. A progressive web app may be just…

    see all Article posts