This post’s a slapdash review of the TXJS sessions I attended, adapted from my Moleskinings — things that pricked my ears and may burn the speakers’. If you weren’t able to attend, you may find the conference’s website more useful, where slideshows and videos are being accumulated as they’re uploaded.
@tomocchino: Front End Abstractions at Facebook
“Early flushing” isn’t a phrase I’d have elected to hear first thing after Friday night’s party ;) but Facebook’s doing some awesome stuff and I’m embarrassed I hadn’t properly looked into flushing techniques before — it’s even on Yahoo’s best practices list.
Facebook actually sends a skeleton of the page initially, and fills in the blanks progressively, using JavaScript to populate the skeleton as the server completes its tasks. The overall effect is a much faster experience for end-users, who can still view parts of the page even while it’s loading. Another Facebook Engineer very recently posted an in-depth article on this, and Stoyan has a good post on flush() itself.
I also liked Facebook’s live()like method of looking for mousedowns, checking to see if the event applied to an anchor (and also for some other conditions), and then attaching the click event handler if true.
@jeresig: JavaScript on the Mobile Web
“We’re on the cusp of the Golden Age of mobile web development.”
I’d forgotten all about playing with WML as a kid in 1999, but it came flooding back to me in a flash when John said that. Little over a decade later: Mobile Safari & Android. Pretty amazing, really.
But for JavaScript, the mobile web’s a rough place. John knows. But this session wasn’t just his war stories from working on jQuery Mobile, it was useful, relevant information for anyone who wants to understand how to target websites for mobile devices. He’s doing an incredible amount of work providing us, not just with a library that works on major supportable browsers, but with the tools to understand precisely what works, precisely what devices we need, and even grading devices and browsers so we can perform triage according to our needs and budgets.
A few things that stood out to me:
- StatCounter and Gartner are the better sources for mobile browser stats.
- But stats don’t differentiate between browser versions, or even between Opera Mini & Opera Mobile, which are completely different browsers.
- Test Swarm is very very useful for automatic UI testing.
- …but interaction testing must be done on a physical device. Even emulators are no substitute.
John’s releasing more information on jQuery Mobile very soon, including (I believe) his list of 13 devices (with a cost breakdown), and details on browser support and browser popularity.
@joemccann: Rapid Prototyping with JavaScript
Joe made a good case for JavaScript as a tool for prototyping apps. While people are using PhoneGap and Titanium to develop production applications, they and other JS tools are also useful for playing with desktop and mobile interfaces; for prototypes.
But Joe really caught my attention when he started talking about YQL, something that’s been on my “to investigate” list for too long. He demonstrated YQL’s ability to “query” a specific URL (and other data sources) in a SQL-like syntax and get back a JSON representation of your results; a sort of screen-scraper for the internet. Its application for prototyping is the rapid accumulation of oodles of real-life test data. Joe’s example was a mobile web app he built in 10 minutes that scraped crockfordfacts.com and worked on Android and iPhone.
Earlier this year, @codepo8 caught my eye with a post about querying the Guardian Data Blog using YQL, and the amount of data and possibilities that blog presents, with YQL’s help, are phenomenal.
@paulirish: 10 Things I Learned from the jQuery Source
Paul’s and Peter’s talks were both great for the many intermediate-but-intimidated JS users out there. Most of us started using libraries (Prototype, jQuery, Dojo, etc.) before we properly understood how they’re structured, or even how they work. Very often, we want to know precise information about something that jQuery does — information that’s only available in the source. Even if we don’t think we want to know, possibilities open up by simply reading the source (ah, jQuery devotionals) and learning its secrets.
I could write several blog posts trying to summarize the session, but the main message was that jQuery’s unminified source isn’t inscrutable. This talk’s a great leg-up for the many, many jQuery users who want to scrute it.
@stubbornella: The Top 5 Mistakes of Massive CSS
Something Nicole really stressed: "If there were a “CSS: The Good Parts”, specificity would be an Awful Part."
I only recently started using YSlow, and the first thing I hit upon was overqualified selectors, specifically “tagname.classname”, a habit I picked up from tweaking jQuery Sizzle selectors for performance. But Nicole made the case that CSS should describe visual patterns, and not just skins dependent on HTML for context.
Nicole talked about how CSS becomes bloated and unmanageable, usually by thinking in terms of stylesheets that reflect semantic markup instead of visual patterns. I’m sure she’ll have slides up soon, but here are some points that stood out to me:
- Avoid selectors that target ID’s. You’re looking for visual patterns, not elements.
- Avoid browser-targeting classes (e.g., .ie). Developers may not see these styles in Firebug, and may change the class it overrides in a way that breaks your site on the targeted browser.
- Use grep to find patterns that have been overlooked:
- Colors that are commonly declared often belong to the same visual pattern.
- h1-h6 get overly declared. You should be able to merge these.
- Lots of floats in the CSS is an indication that you need to use grids.
Nicole also has a very cool sounding alternative to the overflow:hidden technique, that I hope she’ll blog about soon.
@sh1mmer: JavaScript Everywhere! A 100% JavaScript Web Stack
Slides from Tom’s talk are online.
“Progressive enhancement is free.”
Just one of the exciting possibilities of Node is code re-use between the server and client. Tom talked about YUI specifically, and why he feels that it’s a particularly good candidate for code reuse since so many of its modularized components are useful outside the context of the DOM.
But since I have no previous experience with YUI itself, Tom really caught my attention when he started talking about using Node to render HTML through DOM methods via jsdom and node-htmlparser, which Dav Glass supports in his YUI3 bootstrapper for Node. As Tom said, this makes progressive enhancement good as free. He demonstrated the YUI calendar control rendered by the server. With SSJS, users could see and interact with the calendar before the page had even finished loading. Another possibility Tom mentioned would have Tom Mocchino excited: using JavaScript to pull only the data for page requests, and render it with templates; through progressive enhancement, the server could draw complete pages if requested by direct URL’s.
@kangax: Dive into ECMAScript 5
Why, yes, it will be a while before we can safely use ES5 in all browsers. (To corrupt Crockford: IE 6, 7, 8, and 9 MUST DIE.) But we’ll see JSC & V8 support long before then, and it pays to be aware of any nice or nasty surprises, like arguments.callee being gone; yes, even .caller.
So, a confession: I haven’t paid enough attention to ES5, resting on my laurels knowing it’d be an age before I could use it on the front end. Unfortunately, a lot of Juriy’s talk went over my head at the time. If you have slides of it, please tweet me.
@phiggins: It’s Just JavaScript
Slides from Peter’s talk are online.
I thought this would be “10 Things I Learned from the Dojo Source”, but Peter took a different approach entirely. A main message of his session was that playing with JavaScript is the fun path to grokking it. He took us through some common language patterns (curring & binding and variations thereof, etc.) in the context of a library he’s been working as an experimental side-project. With a nod to Paul, he also covered a pattern for “duck punching” methods. These are conceptually complex patterns, and it’s helpful to have practical examples of their application. I read the section on currying several times in The Good Parts, and never really understood why I’d want to use it. Helpful session.
@getify: Web Performance & UI Architecture
I wanna use Node nao! But our company’s hugely invested in a Not-Node architecture. Among other things, Kyle presented a CVC (Client-View-Controller) architecture as it would apply to a mostly (or fully) JS web stack. Basically: the architectures we’re already using are capable of kicking out JSON, and many of us already build JSON API’s for our apps. Why not reduce our apps to black boxes that read JSON requests from and return JSON to JavaScript-based UI controllers & views? That way, we’ll still have the advantage of sharing the libraries we’d want to share between the server and the client, and we’d have a better separation between our application model and our views & controllers.
Kyle also talked a bit about LABjs, which I began using recently and plan to use for pretty much every project I start. Very useful to know that 2 or 3 .js files seems to be the sweet spot for parallel downloads.
Also
All this, and a Facebook sponsored before-party, a Media Temple sponsored open bar at lunch, and a Google sponsored .party:after.
An understatement: I learned a lot from TXJS. Equally valuably, I learned about a lot — things that’d never before entered my sphere of awareness; and I can’t learn about something until I know I don’t know it. The speakers I spoke to were magnanimous and passionate, and I think there’s something valuable too about being able to pin personalities to some of the tools and libraries I’ve been using and articles and books I’ve been reading these past few years. Aside from a couple of Bar Camp events, TXJS was my first proper tech conference, and I came away from it with an overwhelmingly positive perspective. Thanks again, @rmurphey and the entire yayQuery team, and of course all the speakers and sponsors and attendees.