Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

jQuery: It's a library, not a framework

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.

  • Be the first to comment

jQuery: It's a library, not a framework

  1. 1. jQuery Its a library, not a framework.
  2. 2. SpeakersRyan SmithFront-end architect with Credera. Focused on good user experiencethrough well-crafted client side code. Current interests includeHTML5, CSS3, mobile development, and Javascript patterns forresponsive web apps. Geeks out on great coffee, cooking, beautifuldesign, and elegant code.Kenny RosenbergSenior consultant with Credera. His focus areasinclude front end development (usually with JQuery)and Java web development (usually with SpringFramework). He graduated from the University ofTexas with a BBA in Management InformationSystems.
  3. 3. Library vs. Framework• This is a semantic argument• Why make a distinction?• Managing expectations
  4. 4. Library• A collection of helper methods• Helps us not reinvent the wheel• Enables greater consistency, readability• Abstracts away the tedious stuff
  5. 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. 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. 7. jQuery never claimed to be aframework…which means the framework is up to you to implement
  8. 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. 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 IExmlhttp=new ActiveXObject("Microsoft.XMLHTTP");}xmlhttp.onreadystatechange=function() { if (xmlhttp.readyState==4 && xmlhttp.status==200) {document.getElementById("theDiv").innerHTML=xmlhttp.responseText; }}"GET","shiny.html",true); xmlhttp.send();}But this is cake.$("#theDiv").load("shiny.html");
  10. 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. 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. 12. jQuery Plugins• Easy to write• Easy to use• Proliferated rapidly as jQuery popularity grew• Attracts new users and JS novices to jQuery
  13. 13. jQuery Plugins A Word of CautionAdopting a plugin is like adopting apuppy. Know its behavior beforeletting it into your home.Translation: Read the source.
  14. 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. 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. 16. Recommended Strategies1. Logical separation of JS into loosely-coupled modules2. Standardized communication between modules3. Separation of model (application state) from view (DOM)
  17. 17. Module Pattern• Douglas Crockford first publicized in 2007• We like the “Revealing” variant proposed by Christian HeilmannSources:
  18. 18. Anatomy of a Module anonymous functionname private scope var Presentation.sampleModule = function() { //private vars and functions var secretText = "I cant 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. 19. { demo }
  20. 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. 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. 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. 23. { demo }
  24. 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. 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. 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. 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. 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. 29. { demo }
  30. 30. Thanks for attending!• Questions?{ Contact Us }Ryan Smith Kenny @ryanlsmith @kennyrosenberg