JQuery Conference 2014

#tech - 6 Minute Read

jQCon 2014 was a great event down here in SD and I learned a ton. Check out highlights from some of my favorite talks from the Fundamentals talks here.

JQuery and Web Performance

Dave Methvin | Slides

  • jQuery 1x will remain geared for older browser support
  • jQuery 2x will be a more compact build, for modern browsers only (IE 9+)
  • "A poor workman blames his tools." Do not blame the browser for your problems. Remember that the browser must do loads of things and your Javascript is just one of the tasks necessary to produce a webpage.
  • Utilize developer tools in order to test and re-test for page performance problems.
  • "Premature optimization is the root of all evil." Realize that your first-thought optimizations may not always be the key to unlocking the best performance gains.
  • Most significant optimizations can be done without rethinking your entire architecture.
  • Try to avoid significant DOM manipulations with jQuery. Any Javascript that makes the browser re-paint the page presents performance issues.
  • Instead of :visible or :hidden selectors, which can only be triggered after the page has already been painted once, use pure CSS selectors or the newer HTML5 data attributes.
  • As browsers advance and bake in their own event triggers and DOM manipulation APIs, there has been talk about the future need for jQuery. jQuery is still projected to remain a flagship library to help make sense of cross-browser behavior implementations across the web.

Real World Responsive Design Projects and Patterns

Catherine Farman | Slides

  • Media queries and window size calculations are the current standard for responsive design
  • Remember not only must CSS change between breakpoints, but behaviors must change as well. Wrap some desktop-specific code in a conditional $(window).width() block.
  • Avoid anonymous functions, which will run at any breakpoint. Initialize a unique set of functions depending on the layout size.
  • Make it possible to re-fire these functions a few milliseconds after the $(window).resize() event so that the JS has a chance to re-calculate at the new screen size.
  • Good framework: Enquire.js
  • Lightboxes on mobile devices suck. Try AccordiBox which changes to a full-screen popup on mobile devices.

Digging, Debugging

Brian Arnold | Slides

JS Legos: Reusable UI Patterns in JavaScript

Tyler Benziger | Slides

  • You'd be surprised how many user interface designs utilize the same basic Javascript patterns
  • As long as we do our job to separate Structure (HTML), from Style (CSS), from Behavior (JS), we will have a much easier time of replicating the same bits of user interface JS across multiple sites.
  • This means: Style only happens with CSS. Animations also only happen with CSS (as possible with CSS3), and JS should be as agnostic about the particular markup as possible.
  • In your JS, use the most logical selectors to make your code portable. For example, consider .closest() over .parent() in case the element you're manipulating isn't necessarily the direct parent element.
  • Try creating your own events with .on() and triggering them with .trigger() to further modularize your code. This will free you up from relying on .click() and other specific events.

Hacking Front-End Apps

Alex Sexton | Slides

  • There exist plenty of security holes in many websites from frontend development practices
  • Common mistakes developers make: 1) not validating user input, 2) using JSONP, 3) polluting the global namespace in JS
  • JSON-P Users: "I'd really like it if someone could run arbitrary dynamic scripts on my page."
  • Lesson: You can't "detect" malicious scripts.
  • New approach: CSP (Content Security Policy): http://www.html5rocks.com/en/tutorials/security/co...
  • The CSP allows you to define domains from which certain page elements can load
  • Disallow inline CSS and JS!
  • Disallow cross-domain fonts, JS, CSS!
  • Detect any violations you can by reporting them to your company and/or to yourself.

Accessibility - A feature you can build

Monika Piotrowicz | Slides

  • Accessibility is sometimes used interchangeably with "usability", and maybe rightfully so.
  • Applications should be not only easy to use, but easy to use for as many people as possible
  • Up to 10% of the US population have vision problems
  • Up to 8% of the US population have color blindness
  • Up to 8% of the US population have physical disabilities
  • Up to 6% of the US population have other cognitive disabilities
  • 1) Develop for keyboard-only users (handle focus well and make it visually appealing)
  • 2) Add fallbacks for visual information (ALT tags, etc)
  • 3) Forms that function well (again, handle focus well)
  • Design body copy with high contrast. Set your screen to a low contrast. Can you still read it?
  • Don't rely on color alone in your designs. If the luminance is the same, the tones will blend for a color-blind user.
  • Give all images meaningful ALT attributes. This is still important, and even more so with screen readers which will read this to the user. CMS developers… encourage your users to provide this information when uploading the images.
  • Always use labels for form fields
  • Try a screen reader for yourself! Mac OS has the VoiceOver function, windows has TalkBack.
  • 98% of screen readers have Javascript enabled!
  • Screen readers ignore style, so stop trying to "remove" content with style="display:none;"!
  • Screen readers won't ignore properly hidden content: http://webaim.org/techniques/css/invisiblecontent/
  • ARIA: Accessible Rich Internet Applications http://www.w3.org/TR/wai-aria/
  • ARIA - the purpose of ARIA is to further describe key usability information about HTML for assistive devices and operating systems in general
  • Here are some very practical ARIA examples: http://heydonworks.com/practical_aria_examples/


Updated May 22, 2020.