jQuery has reached the level of popularity that even your grandmother is considering adding it to her Wordpress blog because she wants to "Write Less, Do More." (You know the world is changing when she calls you on a Sunday afternoon for help installing AJAX onto her AOL.) It's true that these days, you can pretty much drop jQuery on your page to automagically add more cowbell to your user interactions. But should we be content to just sprinkle fairy dust on our DIVs and call it a day? If you have ever watched your front-end code grow from a few polite lines of click handling to a full-on spaghetti code mess, or lost count of your jQuery plugins and wondered in despair, "How did I get here?" you might have already realized that it is time to start thinking about JavaScript architecture. This talk will briefly introduce jQuery, consider what it does well and what it leaves up to the developer, and look at some patterns and best practices for taming code and thinking architecturally about client-side scripting.

1. jQuery
It's a library, not a framework.

2. Speakers
Ryan Smith
Front-end architect with Credera. Focused on good user experience
through well-crafted client side code. Current interests include
HTML5, CSS3, mobile development, and Javascript patterns for
responsive web apps. Geeks out on great coffee, cooking, beautiful
design, and elegant code.
Kenny Rosenberg
Senior consultant with Credera. His focus areas
include front end development (usually with JQuery)
and Java web development (usually with Spring
Framework). He graduated from the University of
Texas with a BBA in Management Information
Systems.

3. Library vs. Framework
• This is a semantic argument
• Why make a distinction?
• Managing expectations

4. Library
• A collection of helper methods
• Helps us not reinvent the wheel
• Enables greater consistency,
readability
• Abstracts away the tedious stuff

5. Framework
• Implies architecture / structure
• Often driven by patterns considered
to be "best practice," i.e. MVC
• Designed to save you time by
employing reasonable defaults
("convention over configuration")

6. Comparison
• Libraries can be more open-ended
and expressive
• Libraries allow you to learn the API
as needed
• Frameworks require holistic
understanding
• Frameworks bring structure to large
amounts of code

7. jQuery never claimed to be a
framework
…which means the framework is up to
you to implement

8. Why do we use jQuery?
Because this was pretty bad.
<a href=“/something" id="myLink"
onclick="doSomething()">Click Me</a>
This was a little better.
if (el.addEventListener){ // Mozilla
el.addEventListener('click', doSomething, false);
} else if (el.attachEvent){ // IE
el.attachEvent('onclick', doSomething);
}
What a relief.
$("#myLink").click(doSomething);

9. Why do we use jQuery?
Because this wasn’t much fun.
function doAjax() {
var xmlhttp;
if (window.XMLHttpRequest) {
xmlhttp=new XMLHttpRequest();
} else { // Support older version of IE
xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
}
xmlhttp.onreadystatechange=function() {
if (xmlhttp.readyState==4 && xmlhttp.status==200) {
document.getElementById("theDiv").innerHTML=xmlhttp.response
Text; }
} xmlhttp.open("GET","shiny.html",true); xmlhttp.send();
}
But this is cake.
$("#theDiv").load("shiny.html");

10. Why do we use jQuery?
Selectors!
$("#nav li:first > a")
$(":input:not(:checked)")
$("#invoice tr:odd")
• Most browsers have implemented
native querySelector /
querySelectorAll, but prior to that,
complex node selections were
painful.

11. jQuery Patterns
• Anonymous functions
• Method chaining
• $(document).ready
• Manipulates references to this
inside callbacks for convenience
(i.e. this == the calling DOM
element in event handlers)

12. jQuery Plugins
• Easy to write
• Easy to use
• Proliferated rapidly as jQuery
popularity grew
• Attracts new users and JS novices
to jQuery

13. jQuery Plugins
A Word of Caution
Adopting a plugin is like adopting a
puppy. Know its behavior before
letting it into your home.
Translation: Read the source.

14. jQuery and Complexity
• jQuery is ideal for most websites
because of its simple API and
compact but expressive syntax.
• But what about really large
websites? Complex web apps?
Single page web apps?

15. Possible Pitfalls
• Tightly-coupled code leads to copy
& paste pattern
• Failure to stay DRY
• Polluted global namespace
• “Pluginitis”
• Reliance on DOM to hold transient
application state

16. Recommended Strategies
1. Logical separation of JS into
loosely-coupled modules
2. Standardized communication
between modules
3. Separation of model (application
state) from view (DOM)

17. Module Pattern
• Douglas Crockford first publicized in
2007
• We like the “Revealing” variant
proposed by Christian Heilmann
Sources: http://www.yuiblog.com/blog/2007/06/12/module-pattern/
http://www.wait-till-i.com/2007/08/22/again-with-the-module-pattern-reveal-something-to-the-world/

18. Anatomy of a Module
anonymous function
name
private scope
var Presentation.sampleModule = function() {
//private vars and functions
var secretText = "I can't be accessed directly";
var moduleDescription = "Revealing module pattern
example"
var getText = function() {
return secretText;
}
public scope
//create a public API by exposing certain members
return {
revealText: getText,
about : moduleDescription
}
};
}();
self-executing

19. { demo }

20. Pub/Sub
• Publish and Subscribe
• Events replace direct function calls
• Publishers notify the system
• Subscribers listen and act
• Publishers and subscribers don’t
need to know about each other

21. Pub/Sub
• Trivial to implement with jQuery
custom events
//subscribe
$(document).bind(“listChanged”, function(e, data) {
$(“#items”).effect("highlight", {}, 5000);
});
//publish
$(document).trigger(“listChanged”);
• Binding events to the DOM is
slightly slower than other plugins

22. Pub/Sub
• Binding events to the DOM with
bind() and trigger() has a slight
performance cost.
• For large numbers of events,
consider a dedicated pub/sub plugin
• Use namespacing for added clarity
“/some/topic”

23. { demo }

24. Templates
• Sometimes we need to create
HTML from Javascript data.
• Ever done this?
productHTML = '<h2>' + name + '</h2>';
+ '<h4><span>' + description + '</span></h4
+ '<p>$' + price + '</p><a href="„
+ detailsUrl + '"><img src="' + thumbnailImgUrl
+ '" alt="' + thumbnailAltTxt + '" /></a>';

25. Why templates?
• Templates are more powerful and
elegant than string concatenation
• Usually, server-side templates do
the heavy lifting
• Demand for highly responsive UIs
has created a need for client-side
rendering of data

26. When to use templates
• Useful when calling 3rd party APIs
that return JSON
• Async calls that return large
amounts of repetitive HTML can be
refactored as JSON + client side
templates
• User interactions that require
instant feedback

27. Current state of JS templates
• Ideally, we would write a single
template that can be rendered both
server and client-side
• Systems that support this:
• Google Closure templates (used
for Google +)
• {{ mustache }}

28. jQuery Templates
• Still in beta
• Developed by Boris Moore, adopted
as an “official” jQuery plugin in
October 2010
• Support for conditional logic,
iteration, nested templates
• No server-side implementation yet

29. { demo }

30. Thanks for attending!
• Questions?
{ Contact Us }
Ryan Smith Kenny Rosenberg
rsmith@credera.com krosenberg@credera.com
@ryanlsmith @kennyrosenberg
http://blogs.credera.com