kw.

jQuery UK 2012

These are the notes that I took during the day and I may well have gotten things down wrong, particularly in some of the presentations where we whipped through slides at a frantic pace. Slide decks and alternative coverage should congregate on Lanyrd sooner or later.

Ralph Whitbeck — The State of the jQuery Project

• 54% of top 17,000 sites use jQuery
• Flash at 47%
• community fix bugs, raise bugs, educate others, use jQuery, develop plugins
• team actively working on projects (core/ui/mobile)
• projects are core, ui, mobile, infrastructure, dev relations, web/design and events
• board members are elected by board, lead sub teams, create governance policies and approve spending
• all decisions are transparent and public (http://groups.google.com/group/jquery-board-public)
• jQuery is a member of the Software Freedom Conservancy, holds TMs, non-profit, provides free law services
• largest member of SFC, budget is double that of all the others combined
• looking to form own non-profit organisation because they’ve “outgrown SFC”, 1-3 year scope for transition
• 10 releases of core in last year, 3 major, 7 minor
• future releases cleaning code, slimming down file size, break IE6/7 support into compatibility plugin (unlikely), no new APIs expected
• new plugin site (with backups) “is close”

This first talk up provided an interesting insight into the inner workings on the jQuery team/board and the day-to-day decision making process.

Todd Parker — jQuery Mobile

• “mobile-first” UI, works on desktop too
• ajax-based navigation and animated page transitions
• “1 codebase, All Platforms”, 50+ unique mobile devices for testing, don’t use emulation for testing, “hands on is better”
• uses feature detection, not UA sniffing
• web standards, progressive enhancement, responsive, accessible (ARIA roles, etc)
• touch and mouse events supported
• PhoneGap lets you turn a web app into native mobile apps
• theme roller tool available, integration with Adobe kuler, users can make custom themes to make it look like native app
• used in production by OpenTable, IKEA, Audi
• http://jqmgallery.com for inspiration
• hijacks links and pulls content back with ajax, adds transitions by default
• uses hash change and push state to keep history and urls working nicely
• data-prefetch=”true” can preload pages in the background to reduce load times
• revamped transitions in the next version, only fade transition on Android 2.x, feature-tested for 3D transforms
• using a JS fix to make CSS position:fixed work as expected, let’s you keep native browser scrolling

It’s been a while since I’ve looked at jQuery Mobile and this talk from Todd makes it look like a very exciting project. I’m interested to see how theming it actually works so that we don’t end up with thousands of look-a-likey sites, but will definitely consider giving it a test run next time I want to build something aimed at a mobile platform.

Dion Almaer and Ben Galbraith — Web vs. Apps

• apps are worth $3,000,000,000 now, generally have higher viewer levels than TV in the US
• many native apps are starting to look better than the main website (e.g. Ebay)
• Delta Airlines native app is “so much better” than their mobile web app
• apps are starting to overtake desktop for page views
• the ease of getting software now is a major factor for widespread of apps
• both web and native apps have advantages
• native apps are awful for continuous integration (e.g. Etsy deploy ~25 times a day)
• open web APIs make mash-ups/integrating different systems super easy
• native GUI toolkits are hard to match with web apps (jQuery Mobile/Twitter Bootstrap?)
• consistent main functionality is important, with app-specific shell around it (e.g. Facebook, Linkedin)
• remember that mobile apps and native apps have different audiences
• not necessary to mimic native functionality in the web app with hacks and tricks
• “what are the mission critical parts of the business that we want to be able to a/b test or hot upgrade?”
• Walmart apps are all event-based, browser can manage events, native apps can manage events
• Thorax project on Github
• revisit your approach frequently, move with technical developments
• Android seems to be the sticking point at the moment due to the very poor web experience, web apps just don’t work well enough
• “I don’t see us walking away from native SDKs any time soon” — Ben Galbraith

Good discussion on how to approach the ways in which both web apps and native mobile apps are used to give a user access to core functionality, including some cool implementations using Backbone.js.

Jörn Zaefferer — Pitfalls and Opportunities of Single-page Applications

• made jquery.validate plugin
• HTML5 history API is an important part of building single-page apps to support proper urls (history.js library includes fallbacks)
• .pushState( ), .replaceState( ), .on(‘pop state’, function( ) { }) are the important bits
• server-side template rendering in node.js using handlebars
• use ‘exports’ global object to make JS modules work for both node.js and client-side, good way to share functionality
• catch errors on client, aggregate, and send back to the server
• errors encountered are most likely to be SyntaxError, TypeError, or Ajax errors
• bind a logEvent callback to the $(window).bind(‘error’) === window.onerror function( ) { }
• $(document).ajaxError(function( ) { }) is supplied by jQuery
• logError could log to the console and/or send an Ajax call back to the server to log the error
• track errors back to your analytics tools as well
• Airbrake and BugSense are third-party apps for aggregating errors
• better UX from single-page apps as long as URLs are respected
• good first impression/slick interface
• solid error-tracking leads to a stable product
• https://github.com/jzaefferer/pitfalls-examples
• http://svy.mk/xtVS2F

Very interesting talk, particularly the thinking around solid error logging. It’s given me some good ideas around trying out server-side rendering in my projects. Maintaining correct URLs using new HTML5 APIs is very important; hash-bangs are rubbish.

Chris Heilmann — Embracing and celebrating redundancy

• cater to the lowest common denominator? no. block out old browsers? no. abstract browser differences into a library? yes.
• jQuery created an API to work around browser differences, introduced chaining, replaced the DOM based on CSS selectors
• “the new flash intro is semantic HTML”
• dependencies on and between jQuery plugins are not a good thing, plugins shouldn’t replace doing a proper job
• time to move on and “change the native web technology”
• native is good, but shifting the use case is better
• separation between JS/CSS has become blurred with style properties being set with jQuery
• $ === document.querySelector
• remember to set tabIndex of -1 on inserted elements to make it keyboard targettable
• element.classList === $.attr(‘class’)
• “the love we give IE6 is bordering on necrophilia at times”
• use what browsers natively give you, e.g. use CSS transitions instead of jQuery animations
• structure code in cached elements and reusable functions
• don’t write plugins or add methods to cater for edge cases, “that’s getting into PHP land”

This seemed to be an amusing polemic against the proliferation of using jQuery plugins to mask knowledge and coding ability. I agreed with a lot of what was said regarding the idea that browsers are catching up and it may be less necessary to rely on abstractions like jQuery to pave over differing levels of browser support and implementation of features. Chris didn’t really cover using polyfills to cover gaps where feature support is spotty, which seems to me like a logical sister act to this talk—maybe that was what the other half an hour he mentioned consisted of?

Haymo Meran — Aloha Editor

• aims to make web editing as “simple” as using MS Word, make edited text look exactly like the final output
• contentEditable property introduced by MS in IE5.5 and now it’s more widely implemented
• cross-browser implementations vary widely and, as such, aren’t reliable for use yet
• Aloha has realtime interactions, immediately visible results no apply/confirm step, undo, as few interactions as possible
• migrating from ExtJS to jQuery UI at the moment
• WordPress plugin, python packages and Ruby gem available
• some issues when using jQuery UI sortable
• Aloha Wikidocs in alpha, collaborative online editing of HTML5

Probably more of a sales-pitch-cum-tech-demo, Haymo was enthusiastically showing off Aloha Editor without getting into the (arguably more interesting) details of how they’d built it. WYSIWYG technology is certainly advancing, but still doesn’t feel quite right to me: I still think that web content should ideally be written using semantic markup, or at least Markdown. WYSIWYGs will always mark content up for how it looks instead of necessarily using the correct semantics.

Paul Irish — Webapp development stack & tooling

• lots of time focused on common tasks rather than building unique experiences
• Firebug was the first widely-used tool
• lifecycle:
  • boilerplate
  • authoring abstractions
  • iteration workflow
  • performance tuning
  • build & optimisation
  • deploy
• authoring:
  • sass
  • compass
  • less
  • stylus
  • haml
  • markdown
  • jade
  • handlebars
  • coffeescript
  • Dart
• TodoMVC; experiment into building the same simple app with different libraries to allow comparison
• workflow:
  • CodeKit
  • autosave
  • JSHint
  • browser developer tools
• get to know the shortcuts for your editor

Very amusing and energetic presentation from Paul covering the range of tools available to web developers these days, from source code abstractions (e.g. SASS/LESS & CoffeeScript) to one-page websites such as Sassy Text Shadows. Time seemed to run out far too soon so I’ll have to make a note to check out the slides and see what else we might’ve missed out on, but it’s definitely convinced me to have a go at using SASS and CoffeeScript for an upcoming side project.

Addy Osmani — Large-scale applications using JavaScript and jQuery

• “building JS apps that have to scale from the get-go”
• decoupling:
  • separates units of code that don’t depend on each other
  • promotes reusability
  • reduces the risk of breakage when other modules fail
  • publish/subscribe model (observer pattern), event-driven
• “if one part of the application breaks, can the app fix this break itself?”
• it should be possible to test modules individually
• how much is easily reusable? how secure is the app from itself?
• facade pattern; simplifies the workings of a function via an API, hides implement ion level details
• mediator pattern; centralised controller which passes messages between subscribers, mediator can perform validation on pass-through
• module patterns; object literals, module pattern, AMD
• large application is “a non-trivial app requiring significant dev effort to maintain, where most of the heavy lifting of data manipulation and display fall to the browser”
• app core:
  • manage the module lifestyle (start/stop/restart)
  • mediator pattern
  • reacts to actions passed from a sandbox
  • handle error detection and management
• sandbox:
  • interface for interacting with libraries
  • permissions manager, securing what modules can/can’t access
• modules:
  • initialise/destroy methods

This talk covered some solid software architecture principles in a very similar vein to Nick Zakas’ talk from Full Frontal last year, but with better code examples and prettier slides. That said, old thinking isn’t necessarily out-dated, and this gave me and my Guardian colleague, James, food for thought with regards to ways that we could better make use of patterns in future developments.

Doug Neiner — Contextual jQuery

• declarative code bad, dynamic code better, contextual code best
• minimal use of IDs, leverages selectors and traversing, very little repeated code, HTML follow conventions, virtually no selectors running on DOM ready
• flexible and more responsive code, less code overall, easier to maintain and reuse
• minimize setup, delegated events, traversal and selectors, HTML conventions
• use CSS classes to control state, remove JS to control visual display
• “just in time initialisation” because users don’t generally use every part of a page all the time
• setup areas of the page only when needed, leverage probable user actions to load parts of the page
• user actions: click, mouseenter/mouseleave, scrolling, focusin/focusout, metrics
• consider balance of optimisation, be smart
• “write code like you spend money — opt to pay a little more later so you don’t risk losing it all on something that never happens”
• make sure that delegated events have as few false positives as possible, bind as close to the elements you’re actually targeting
• traversal methods: prevAll, prevUntil, nextAll, nextUntil, siblings, parents, parentsUntil, offsetParent, closet, children, find, end
• brittle vs. flexible traversal methods
• faster selectors (using ids) are less reusable and not necessarily better
• filter methods: filter, eq, first, slice, has, not
• “write code like you buy a car — always weigh the difference between cost and quality”
• HTML conventions are consistent patterns that you define yourself and stick to, they can change between projects
• aim to avoid adding any extra mark-up to solve JS problems
• “write code like you ask for directions — try to get there on your own first!”
• http://bit.ly/contextual-uk
• social sharing buttons are a great candidate for lazy loading

By far my favourite of the day, and sadly rushed since it fell at the end of the schedule. Fantastic talk and very thought-provoking, in particular making me think when it comes to balancing between fast selectors and reusable selectors. I’d like to l look much more closely at lazy-loading functionality and content based on when it’s actually likely to be used. I’d love to get this guy to come and give a talk to the Guardian tech team.