AlexAitken.net

Guiding slides for the hour-long presentation on ‘What is jQuery’ that I’ve been giving to backend teams.

It’s a fun thing to be at the fore­front of a lan­guage/tech­no­logy re­volu­tion. I’m al­ways a little amazed at how the JavaS­cript I began cod­ing ten years ago has turned in to one of the corner­stones of my ca­reer. MBAs and years on con­sensus build­ing are one thing, but it’s this lan­guage that truly brings my design work to life, from its pro­to­typ­ing stages to its full pro­duc­tion de­ploy­ment. And while I’ve forged deep­er and deep­er un­der its hood, JavaS­cript has im­plic­ated it­self fur­ther and fur­ther in mod­ern de­vel­op­ment prac­tices. JSConf 2011 brought most of the thought lead­ers re­spons­ible for this im­plic­a­tion to­geth­er for two days in Port­land, OR, in­duc­ted oth­ers in to the circle, and hummed throughout with young, fresh, en­ergy and ideas de­voted to the stand­ards lan­guage mak­ing today’s web hop. Notes on the sum­mit:

The grid-based design be­hind much of today’s web was re­vealed to me a few years back as I was serving as in-house Tech­nic­al Lead for a ma­jor cor­por­ate re­design. My team worked with de­sign­ers from an ex­tern­al agency, and as their comps star­ted com­ing across the wire it was quickly clear that visu­al com­pon­ents were be­ing aligned to a four-column grid. Every­one liked the or­der and or­gan­iz­a­tion af­forded by the grid. When it came time to turn comps in­to code we went with the 960.gs css frame­work and to this day, design and de­vel­op­ment of new solu­tions takes place with­in the con­text of the grid.

Al­most all ap­plicatons we in­ter­act with on the web are form driv­en. User-sup­plied data in; sys­tem con­clu­sion out. To be sure, a dec­ade plus of ex­per­i­en­ce and in­nov­a­tion has seen UX im­prove by leaps and bounds. But we’re still build­ing forms, and to that end I al­ways en­joy re-vis­it­ing the ba­sic ques­tion of how to build them well. Here’s the es­sence of a re­cent stab.

Cross-Site Re­quest For­ger­ies (CSRF) ex­ploit the trust that a site has with­in a user’s browser. By in­du­cing clicks on links to sites where users are sus­pec­ted to be au­then­tic­ated, per­pet­rat­ors can ex­ecute trans­ac­tions un­der the um­brella of a user’s cur­rent ses­sion. Re­quir­ing newly gen­er­ated para­met­er val­ues with each new POST or GET is one way for pro­gram­mers to pro­tect against CSRF. But while im­ple­ment­ing this re­quire­ment in page-driv­en ap­plic­a­tions is fairly straight-for­ward, ajaxi­fied apps make things more com­plic­ated. The fol­low­ing ap­proach lets us ab­stract the com­plic­a­tions out of our day-to-day so we can code both cur­rently and se­curely.

Thomas Fuchs is au­thor of the script.aculo.us user in­ter­face JavaS­cript lib­rary, a mem­ber of the Pro­to­type core team and a Ruby on Rails core alum­nus. As he puts it, ‘You’re us­ing my work every day, even if you’re not aware of it!’ His wife Amy Hoy is a de­sign­er, au­thor, and JS pro­gram­mer in her own right. To­geth­er they team to of­fer a full-day’s train­ing on ad­vanced JS de­vel­op­ment and de­ploy­ment tech­niques that they de­liv­er via chat and video­con­fer­en­cing soft­ware from Vi­enna, Aus­tria.

IFrames get a bad rap. In the early days their cross-browser sup­port was spotty and even now, in­cor­por­at­ing them in mis­sion-crit­ic­al de­ploy­ments re­quires a good reas­on and a con­sidered ap­proach. But there are good reas­ons. And giv­en a per­fect storm of cap­ab­il­it­ies and lim­it­a­tions, an iframe can serve as the av­en­ue to a seam­less ex­per­i­ence where user in­ter­ac­tion would oth­er­wise be punc­tu­ated by popups, scroll­bars, or host switches.

IE6 is in the ICU. Developers are still forced to accommodate the 8-year-old browser’s maverick rendering engine but we also find ourselves on the dawn of a new era that isn’t defined by a market-leading millstone. IE7 and 8 come markedly closer than their little brother to true standards support. Firefox, long the coder’s favorite, has found larger love and the webkit rendering engine of Safari and Chrome continues to walk the line. We are, in effect, very close if not already at the IE6 tipping point whose far side promises unencumbered development to current and native browser capabilities.

It’s sometimes a satisfying thing when textbook case studies present themselves in real life. With some breaks in the continuum, I’ve been pretty serious about JavaScript code since about the time of Boston’s miraculous comeback against the Yankees in the 2004 ALCS. Only in the last couple of years, though, have I been turning my coding style from the functional to the object-oriented, and incorporating into it some of what I’ve learned from John Resig, Aaron Newton, and others on the forefront of the recent JS boundary pushings. One of the early lessons these guys have to impart is on JS closures. So when, in production code for a large financial institution’s online banking application, I ran across the very lines of code they use to illustrate the concept, bells went off and – to quote Jonesy from ‘The Hunt for red October’ – I ended up basically running home to Mama.

In October of 2008 I attended the Ajax Experience Conference (sponsored by ajaxian.com among others) in Boston. 2009 saw a conflict between Ben and Dion and Adaptive Path’s San Francisco UX Week, which I opted for to diversify. Here, however, near its first anniversary, I share what I took from the 2008 Boston session. We’ve made progress. There’s still a way to go. And I still think UI/X is king. The excitement and challenges of a year ago: