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+)
- 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.
- 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.
Brian Arnold | Slides
- Become as familiar with your browser's dev tools as possible! They are growing and getting more advanced by the day.
- Free course: http://discover-devtools.codeschool.com/
- For performance, this is an awesome tester: http://www.webpagetest.org/
- Check out the Command Line API in Chrome's dev tools: https://developers.google.com/chrome-developer-too...
- You can use Breakpoint Actions in Chrome in order to do console.logs without actually writing "console.log()" messages into your code. http://www.randomthink.net/blog/2012/11/breakpoint...
Tyler Benziger | Slides
- 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.
- 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.