HTML5 Live London, October 19, 2011
Jake Archibald, TweetHelped Develop BBC's Standards & Guidelines on Markup and JavaScript
Biography: Jake Archibald
Jake works at creative agency The Team http://theteam.co.uk and has extensive experience building JavaScript components to meet strict performance and accessibility requirements of clients such as the BBC. He also helped develop the BBC's technical Standards & Guidelines on markup and JavaScript.
Outside of the web, Jake is a keen photographer and motorsport fan.
Follow him on twitter: @jaffathecake
Q & A with Jake
Q. Tell us a little about what you will be talking about at HTML5 Live & what will people learn?
A. Very few people build sites without using JavaScript components written by others, eg something like jQuery running in the browser or something like expressjs running on the server. However, a lot of reusable components, especially UI components, are incredibly restrictive on design and interaction. Most JavaScript developers I've met have built some kind of carousel widget because their requirements aren't met by the 100s out there already. I'm going to be looking at techniques to avoid that, how to build components that are intuitive without being restrictive.
We'll look at how to develop components that gives users creative freedom, letting them use it for things you didn't imagine, but without introducing bloat or up-front complexity. We'll also have a little chuckle at some bad examples, but make sure we learn from what makes them bad.
Q. What will they take away that they can apply right away?
A. Hopefully the different ways reusable code can be organised and presented, and which to choose for a given situation. We'll cover the differences between traditional constructors & namespacing (as node.js uses) vs jQuery plugin patterns. Writing documentation is boring, but vital and often overlooked, so we'll look at ways to make it part of development rather than irritating afterthought.
Q. In your opinion, why should people attend HTML5 Live?
A. There's a good balance between the 'big picture' stuff and nitty gritty implementation bits. The best thing attendees can do at a multitrack conference is throw themselves at a subject that isn't 'their thing', having an appreciation for what everyone does in the process is really important. I'm not an 'enterprise' guy, so I'm really interested to hear the thoughts of those who are.
Q. Why is HTML5 exciting for web developers? Architects?
A. I liked the XHTML2 spec for its semantic purity, but its strictness (especially the XML stuff) made things difficult for the developer without any real benefit. I'm not saying people should get away with invalid markup, but little things like data attributes and allowing an ampersand followed by a space to be treated as a litteral ampersand... these are things browsers already supported but we had this "Book of NO" telling us we couldn't.
It's great to see this thinking going into the DOM specifications too. Most of the DOM spec is written to be logically pure rather than making stuff easy for developers, that's why we ended up with patterns like ode.parentNode.removeChild(node). Now people involved in the DOM spec are looking at common things developers do, they saw that most of us used some kind of library to get elements by CSS selector and gave it natively - querySelectorAll. They saw all the horrible hacks were were using to maintain connections for pushing notifications and gave us web sockets.
It's an exciting time to be a frontend developer!
Presentation: TweetReusable Code, for good or for awesome!
Abstract
What sets reusable JavaScript apart from other JavaScript? How can we make our code developer-friendly, fast, robust & compatible?
In this talk we'll cover testing, code structure, working with compressors, documentation, measuring performance, but concentrating on API design.
The API is make-or-break when it comes to reusable code. It's the API that lets other developers use your application, if it's difficult to use then they won't get the most out of what you've written.
We'll analyse existing APIs, looking at where they fail and where they succeed, looking at what patterns they use and how users react to them.
By looking at the wins and fails in the real world, we can discover what makes code a pleasure to use and reuse.
