The jQuery Divide

The jQuery DivideRebecca Murphey • JSConf.eu • 25.09.2010@rmurphey • rebeccamurphey.com

Wednesday, September 29, 2010

what this presentation covers

how jQuery’s popularity means newcomers learn bad things

why I think this is worth talking about at JSConf

what I think the larger JavaScript community needs to do about it


We need you to help us organize our jQuery-based application. It’s a steaming pile of unmaintainable crap.


But we want to keep using jQuery. It’s just so easy! And popular!


It’s almost guaranteed that the client will point to jQuery’s popularity as a reason to keep using it. It’s also a pretty fair bet what their code will look like.


Plus that way our database guy can still help us out with the front end.


*headdesk*


“... it turns out that if you have absolutely no idea what you’re doing in the language you can still generally make things work.”

Douglas Crockford, Yahoo!

http://developer.yahoo.com/yui/theater/video.php?v=crockonjs-2




the morals of the story

perceived popularity & perceived ease of use factor into library choice (duh)

people who don’t know JS write non-trivial JS apps whether we like it or not

there’s a demand for answers to app org questions

the people seeking these answers aren’t necessarily dumb, just untrained in JS


jQuery meant we didn’t have to understand this ...


var xmlhttp;

if (window.XMLHttpRequest) {// code for IE7+, Firefox, Chrome, Opera, Safarixmlhttp=new XMLHttpRequest();} else {// code for IE6, IE5xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");}xmlhttp.open("POST","ajax_test.asp",true);xmlhttp.setRequestHeader("Content-type","application/x-www-form-urlencoded");xmlhttp.send("fname=Henry&lname=Ford");

xmlhttp.onreadystatechange = function() { if (xmlhttp.readyState == 4 && xmlhttp.status == 200) { document.getElementById("myDiv").innerHTML = xmlhttp.responseText; }};


we could just write this ...


$.post( 'ajax_test.php', { fname : 'Henry', lname : 'Ford' }, function(resp) { $('#myDiv').html(resp); });


jQuery offers a really clear answer when we need to build this ...


$(document).ready(function() { $('#searchForm').submit(function(e) { e.preventDefault(); var myVal = $(this).find('input:first').val(); $.ajax({ url : 'search.php', data : { term : myVal }, dataType : 'json', success : function(resp) { var tpl = '<li><h2>%title</h2><p>%desc</p></li>'; $('#results').html( $.map(resp.results, function(r) { return tpl.replace('%title', r.title).replace('%desc', r.desc); }).join(''); ); } }); });});


... which is why we see this ...


But when it comes time to create this ...


... it can be hard for the average jQuery developer to see how they might get from the #rst version to the second without creating a whole lot of spaghetti code.


It turns out jQuery’s DOM-centric patterns are a fairly terrible way to think about applications.


Applications require thinking in terms of loosely coupled, DRYed out units of functionality, designed to work with each other without depending on each other.


require.def('views/Results', [], function() { return Class.extend({ itemTemplate : '<li><h2>%title</h2><p>%desc</p></li>',

init : function(el) { this.el = el; $.subscribe('/search/results', $.proxy(this, '_showResults')); },

_showResults : function(results) { var tpl = this.itemTemplate, html = $.map(results, function(r) { return tpl .replace('%title', r.title) .replace('%desc', r.desc); }).join('');

this.el.append(html); } });});


require.def('views/Results', [], function() { return Class.extend({ itemTemplate : '<li><h2>%title</h2><p>%desc</p></li>',

init : function(el) { this.el = el; $.subscribe('/search/results', $.proxy(this, '_showResults')); },

_showResults : function(results) { var tpl = this.itemTemplate, html = $.map(results, function(r) { return tpl .replace('%title', r.title) .replace('%desc', r.desc); }).join('');

this.el.append(html); } });});

omg wtf is this???


We shouldn’t scold; cartoon client man — and the developers lured to JavaScript by jQuery — don’t know what they don’t know.


Some people i’ve talked to think we or the market should discourage these people from writing code, but that ship has already sailed.


ey’re writing code whether we like it or not, and it’s not good code.


is has actual effects on the perception of JavaScript, and on our ability to do interesting things with it.


In a nutshell, this is what these developers need to learn:


jQuery

JavaScript


Companies need developers, and if bad ones are all that’s available, they’ll hire them anyway.


Aaron Newton from Cloudera wrote a post a while back about how hard it is to #nd “badass” JavaScript developers.


e productive reaction to a post like that isn’t to feel superior because you’re a badass JavaScript developer.


e productive reaction is to #gure out how to #x it.


jQuery’s ease has brought us legions of developers who think of an application like this: disparate pieces with few organizing principles; components that are fun but aren’t made to work together.


We need to turn them into developers who think of applications like this.


five things to think about


popularity contests are stupid

#1


Making decisions based on this graph ...


... makes as much sense as making decisions based on this graph ...


We have to be intellectually honest when we discuss library pros & cons — and vigorous in correcting those who are not.

http://xpandapopx.deviantart.com/art/The-Prideful-Hypocrite-68848153




#2choose tools, not APIs


// YUI3var parent = Y.Node.create('<div/>'), child = Y.Node.create('<p>foo</p>'); child.on('click', fn);parent.appendChild(child);

// Dojovar parent = dojo.create('div'), child = dojo.create('p', { innerHTML : 'foo' }); dojo.connect(child, 'click', fn);dojo.place(child, parent);

// jQueryvar parent = $('<div/>');$('<p>foo</p>') .click(fn) .appendTo(parent);


$(document).ready(function() { $('#searchForm').submit(function(e) { e.preventDefault(); var myVal = $(this).find('input:first').val(); $.ajax({ url : 'search.php', data : { term : myVal }, dataType : 'json', success : function(resp) { var tpl = '<li><h2>%title</h2><p>%desc</p></li>'; $('#results').html( $.map(resp.results, function(r) { return tpl.replace('%title', r.title).replace('%desc', r.desc); }).join(''); ); } }); });});


understanding the problem is key to determining the solution

#3


Decision-makers need help to make actual decisions ... and understand their consequences.


understand the project

application vs. website?

team skills: dedicated F2E?

team size & turnover?

project lifecycle: long-term, evolving product?

service-oriented back-end?


assess the application’s needs

code & #le organization?

dependency management & build tools?

templating & templated widgets?

data abstractions & binding?

a11y, i18n & l10n?


then and only then, choose your tools

features that address the application’s needs?

active development?

active community?

documentation & resources?

institutional backing?


RTFM can’t be our go-to answer

#4


“[It’s] a difficult time to learn to be a JavaScript ninja, or even a JavaScript street beggar. Good resources for getting beyond the very basics are hard to !nd, documentation is sparse or wrong, and a snippet of code that may have been viable last year is now an anti-pattern.”

http://www.clientcide.com/deep-thoughts/why-its-a-good-idea-to-be-a-javascript-developer-and-what-it-takes-to-be-one/#comment-32703




sharing what we knowis as important as

making new things

#5


rebeccamurphey.com • blog.rebeccamurphey.com • @rmurphey

anks, in guilt-free alphabetical order, to: Tim Caswell, John Hann, Peter Higgins, Tom Hughes-Croucher, Paul Irish, Brian LeRoux, Roger Raymond, Alex Sexton, Colin Snover, Adam Sontag, Chris Williams, and to everyone who listened to me formulate my thoughts.


The jQuery Divide

Technology

Transcript of The jQuery Divide