JavaScript Libraries

1. JavaScript Libraries How To Create Our Own JS Library Ivan Zhekov Telerik Corporation www.telerik.com Front-end Developer

2. Table of Contents • What is a JavaScript libraries • Prominent JavaScript libraries • prototype js • MooTools • jQuery • Dojo • YUI • KendoUI

3. Table of Contents (2) • JavaScript Library Fundamentals • Object creation / inheriting • Query • Traversing • Manipulation • Insertion / Deletion • Events • AJAX • Animations

4. Table of Contents (3) • Recommended features • All spiced up for basic users • Powerful syntax for advanced users • Strong coding convention

5. What is a JSL? Have you seen a moose? It’s nothing like it!

6. What is a JSL • A JS library is pre-written code that aims to facilitate and /or jump start development, especially AJAX based tasks • A JS library: • Works around browser differences • Abstracts common work • Adds sugar and spice • In addition it might have widgets, themes • … and even more sugar

7. Library vs. Framework • Technically speaking, it’s just text, so pick your favorite • Never the less mind that in order to call a library a framework, it needs: • More features • More cases • Widgets • Full stack of dev love

8. Prominent JSL A brief, based overview

9. Prototype • Created 2005 by Sam Stephenson • One of the corner stones of JS, IMO • Features • Object creation, DOM query, traversal, manip, events, Ajax, utility methods… • Scriptacolous / Scripty for animations / fx • Sadly no development over the past year • … my personal favorite

10. Prototype syntax • Sample code // Get an element and attach event varheader = $("header"); header.observe("click", function() { alert("Yay ... clicked :) "); }); // Delete all elements of tag name $$("a").each(Element.remove); // Ajax new Ajax.Request(url, { method: 'get', onSuccess: function(transport) {...} });

11. MooTools • Created 2005 by VallerioProietti • Initially moo.fx was a FX lib for prototype • Developed over the years as a separate lib • Features inspired by Prototype, but different: • Object creation, DOM query, traversal, manip, events, Ajax, utility methods… • Some what active development

12. Mootools syntax • Sample code var header = $("header"); header.addEvnet("click", function() { alert("Yay ... clicked :) "); }); $$("a").each(function(element) { element.dispose(); }); varmyRequest = new Request({ url: url, onSuccess: function(responseText, responseXML) {...} }); myRequest.send();

13. jQuery • Created 2006 by John Resig • Initially just selectors • Have become one of the most powerful and used js libraries in the web • Features • DOM query, traversal, manip, animations, Ajax, utility, plugins… • Bundled with popular IDE’s • Quite magical for n00bs

14. jQuery syntax • Sample code var header = $("#header"); header.bind("click", function() { alert("Yay ... clicked :) "); }); $("a").remove(); $.Ajax(url, { success: function(data) {...} });

15. Dojo • Created 2005 by John Resig • Somewhat underestimated, but powerful library with many features • Features • DOM query, traversal, manip, animations, Ajax, utility, plugins… • UI widgets • Mobile • Just released 1.7

16. Dojo syntax • Sample code var header = dojo.byId("header"); dojo.connect(header, "onclick", function() { alert("Yay ... clicked :) "); }); dojo.query("a").orphan(); dojo.xhrGet({ url: url, load: function(data) {...} });

17. YUI • Created 2005 by Yahoo! • Home grown and developed • Features • DOM query, traversal, manip, animations, Ajax, utility, plugins… • UI widgets • Developer tools • Still actively developed

18. YUI syntax • Sample code (for YUI3) YUI().use(["node", "io"], function (Y) { var header = Y.one("#container"); header.on("click", function() { alert("Yay ... clicked :) "); }); Y.all("a").remove(); Y.io(uri) });

19. Kendo UI • Just released by Telerik • So far, build on top of jQuery, but improved: • Blazing fast templates • Excels performance and ease of use • Features: • UI widgets, templates, data visualizations • Serves CSS as browser compiled LESS • Coming in mobile flavor soon

20. KendoUI syntax • Sample code // Kendo doesn't do DOM it's all UI // It requires certain HTML to be on the page // auto complete widget $("#autocomplete").kendoAutoComplete(["Item1", "Item2"]); // calendar widget $("#calendar").kendoCalendar(); // dropdown widget $("#combobox").kendoComboBox([{text: "Item1", value: "1"}, {text: "Item2", value: "2"}]); // fancy upload $("#files").kendoUpload();

21. Other • There are many, many, many, many, other js libraries out there • Some deal with common tasks • Other excel in UI • There are those who do JS MVC • And some do server side • Just ask G about them

22. Building our own JSL Ready! Set! Go!

23. Roadmap • We begin at the very end (feature wise) • Ensure code quality • Homogenous syntax • Module patterns • Get the job done, add candy later • Let’s pretend that there are NO old browsers • Then suddenly remember it and add support

24. Recommended features Unicorns and rainbows

25. Code Convention • What is a coding convention? • A set of writing rules concerning some or all aspects of the coding • How to comment • How to name functions, variables, params etc. • White spaces…

26. Code Convention (2) • Why have one? • Homogenous code • Easier to read • May help avoid problems in the future • Some habits are just good

27. Powerful Syntax • That would be the normal way • Libraries are generally wrapping native functionality • All native functionality should be achievable trough parameter combinations • One of two ways to do that: • Have a single method for many operations • Havea method for each operation

28. Syntax sugar • Not a new thing – almost 50 years old concept • Syntax sugar means having shorthand methods that do heavy lifting • Sort of a Swiss army knife for some stuff • Benefits: • Easier to read / compact code • Gentle learning curve • More expressive • Cons: random hate… above all

29. Documentation • Documentation is essential • Don’t over document • Don’t under document • Document just right: • No more or less than needed • Concrete sentences, clear language • Avoid disambiguation • Try to be neutral • Update the docs in a timely manner!

30. Examples • The best documentation has examples • Never the less have separate examples • Organize examples in scenarios • Describe scenarios fluently • Elaborate if a scenario is a bad practice • Help users choose between scenarios • Provide at least one example per scenario • Have as many examples as possible • Try not to mix code with content

31. Community • Don’t underestimate the community • The community is using the library • They are important, but not too important • Have your own opinion, but listen to others • A proper community needs • Commenting articles, forums, tracking system, contribution system • Even awards • A community is created by itself • And is dissolved that way

32. Let’s start Chat: show me the code

33. Code convention • It’s a bit see as we go, but just a start: • //commentspreferably • Code indentation is one tab (set to four spaces) • Functions and properties are in camelCase • Objects and constructors are in PascalCase • If we need a getter use get_property • If we need private use _property • No curly braces for single line control structures • Use white space accordingly

34. Object creation • Object creation is important for: • Custom utility objects • UI widgets • Magical base is overrated (IMO) • Actually, magic is overrated • Simple inheriting first, multiple later • Object factory • Prototype.create(…)

35. Querying the DOM • Specificity first • A method for one • A method for all / sub querying • Return what’s expected: • One, Many or NULL • Use built in methods where possible • Optimize by analyzing parameters

36. DOM traversal • Not that different from querying • node.nodeType == 1 means HTML element • The parentNodeis usually an element • Utility methods for: • Siblings – all, left, right, single • Children – first, last, all • Recursive parents • Selectors based traversing

37. Manipulation • Attributes are mostly the same in HTML and DOM • With few minor exceptions • First use concrete attributes • Then normalize input for easier development • Mind that the style attribute is a bit different • We could make it work to set or get multiple attributes at once • Regardless of the choice for implementation, setting and getting props must work the same

38. DOM insertions / deletions • Cover the basic DOM insertion • Add extension methods for easier insertions, like prepend, insertAfteretc. • Remember that innerHTMLworks faster in some cases and documentFragmentin the rest • Do we eval scripts upon insertion?

39. DOM events • For a proper event system • Events should not bubble e.g. last paramis false • We can make syntax that omits it • Unless one wants to specify it explicitly • What do we do about anonymous events? • How do we mass remove events? • Event delegates • Events handlers for collection of elements

40. Ajax • Just the basics • Implement methods for: post, get, put, delete • Use native objects • Don’t wait for forever to timeout • Status code vs. words based callbacks • Should the Ajax invoker be void? • Plain old fetching data to populate elements • Persistent connections

41. Animations • Ways to do it: • Interval with fixed steps • Interval with time based steps • Native request animation frame • Stopping animations and reverting to base • Chaining animations • Animation callbacks • Anything else you can think of

42. JavaScript Libraries ? ? ? ? ? ? ? ? ? ? http://academy.telerik.com