The jQuery Divide

The jQuery Divide
Rebecca 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, Safari
xmlhttp=new XMLHttpRequest();
} else {
// code for IE6, IE5
xmlhttp=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 oﬀers 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);
omg wtf is this???
}).join('');

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


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 eﬀects 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:


JavaScript

jQuery


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


#1
popularity contests are stupid


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


#2
choose tools, not APIs


// YUI3
var parent = Y.Node.create('<div/>'),
child = Y.Node.create('<p>foo</p>');

child.on('click', fn);
parent.appendChild(child);

// Dojo
var parent = dojo.create('div'),
child = dojo.create('p', { innerHTML : 'foo' });

dojo.connect(child, 'click', fn);
dojo.place(child, parent);

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


#3
understanding the problem
is key to determining the solution


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?


#4
RTFM can’t be our go-to answer


“[It’s] a diﬃcult 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


#5
sharing what we know
is as important as
making new things


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

More Related Content

What's hot

Viewers also liked

Similar to The jQuery Divide

More from Rebecca Murphey

Recently uploaded

The jQuery Divide