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. Stacks of a variety of cardboard and food boxes, some leaning precariously.
    Article post type

    Setting up Sass pkg: URLs

    A quick guide to using the new Node.js package importer

    Enabling pkg: URLs is quick and straightforward, and simplifies using packages from the node_modules folder.

    see all Article posts
  2. Article post type

    Testing FastAPI Applications

    We explore the useful testing capabilities provided by FastAPI and pytest, and how to leverage them to produce a complete and reliable test suite for your application.

    see all Article posts
  3. A dark vintage accessory store lit by lamps and bare bulbs, with bags, jewelry, sunglasses and a bowler hat on the wooden shelves and carved table.
    Article post type

    Proxy is what’s in store

    You may not need anything more

    When adding interactivity to a web app, it can be tempting to reach for a framework to manage state. But sometimes, all you need is a Proxy.

    see all Article posts