Javascript libraries

There are many discussions (some quite heated) on what JavaScript library/framework is better.  I believe it all depends on your own abilities, needs, and intentions.  There are many developers working with all the popular libraries and frameworks.  Can all front-end developers be wrong?  In contrast I have seen many developers who have opted to not use a library and decide to do it all on their own.  This often strikes me as odd in some of these situations, since I usually don't care to reinvent if there is not a valid reason.  There are some elements of a framework I feel necessary when coding JavaScript for a large system in a fast paced work environment.  I am going to touch on a couple of these.

• Object Oriented - structure, inheritance, etc
• JavaScript Loading - module based, dependency management, important to think about for those JavaScript heavy pages
• Build system

I'm not going to go into detail on the above points, but I do believe they are important to a framework.  Especially since, for larger systems/sites, JavaScript's nature could easily end up with a large bundle of disjointed code risking unpredictable results (bugs) from possible conflicts.  Now I don't mean to wish for JavaScript to mutate into a more structured language since it does have so many uses that take advantage of JavaScript because of its core nature.  I have a lot of bookmark scripts and macro like apps all using JavaScript that I would not expect to need any of my above points.

Recently a question came up to me at work once again about the use of jQuery.  This came up because we currently use Dojo throughout our sites.  This led me into thinking more about some of the reasons why we currently use Dojo.  Some of these thoughts I am about to share.  I am not sharing to bash jQuery but rather plan to use jQuery as an example; some of the points pertain to not using a framework at all as well.

jQuery does have its place.  Since it provides a lot of plugins there are a variety of scenarios for its use, especially for those who don’t know or are not able to learn JavaScript.  This has ended up making it popular, but this isn’t really a popularity contest.

It is lacking in areas necessary for consistent enterprise development.  A couple of these areas are in the coding environment and modular asynchronous loading and build.  Why should these be part of the framework?  Well, you could decide to implement inheritance patterns on your own, and structure your code on yet other patterns, and build all of your code using RequireJS (which would require wrapping open source plugins not already written with RequireJS) to provide dependency management, modules and dynamic loading, and incorporate (or develop) a build system.

By doing all that, you could come close to some of what Dojo provides.  To what end do we assemble a hodgepodge of tools? Maybe the thought is that its API looks simpler, though I wonder about those who would think it looked simpler.  You know we are all smart people and must realize we are not attempting to build dancing huts stacked on top of each other to assemble an experience.  Are we not building a skyscraper, or a first class user experience?

So why push jQuery.  Maybe there is the thought that finding jQuery developers seem easier than developers of other libraries/frameworks do.  However, if someone claims to know jQuery does it really tell you anything about that person's ability?  All it really means is they know how to copy a piece of code.  You need to find developers who also know how to write quality JavaScript code.

Maybe there is the thought that there are so many plugins available for jQuery maybe we should use that even though other libraries provide the same functionality.  Some could even offer more features and functionality.

So if we throw all of these plugins together in a mixed organization and use a variety of tools trying to make it all fit, what risks do we accept?  Down the road we may end up paying the price in terms of maintenance and performance of code developed by various independent developers of unknown abilities and dedication to the code.  There would be no guarantee of maintenance of any form.

Is Dojo the perfect tool?  Is it really the absolute answer?  I cannot say that it is “The” tool to build that skyscraper.  Why?  Too often, you do need multiple tools to achieve something so great.  There is a benefit in Dojo in that its contributors are continuing to look into the future of building the next great site as well as the next hot client side application.  They also embrace other open projects.  One such move was to utilize other open source “standards” (such as those at CommonJS).  Another move was incorporating something like RequireJS for modules and dependencies.  They are now able to integrate “seamlessly” any JavaScript based module built using RequireJS.

  

I was going to list some benefit features for Dojo, but found a list I had copied from a blog at some time in the past and thought it was maybe more meaningful.  Here are some interesting points from a prior avid jQuery only developer who moved to using Dojo (for the first time) for a large project.
"

•  ·         Code organization patterns: Dojo provides pretty clear guidance on structuring both  your features and your codebase. I’ve given a lot of thought to organizing jQuery code. I wrote an article on the topic for JSMag and gave a presentation on the topic at the jQuery conference. I was eager to try a library that explicitly answers the organization question.
• ·         Class inheritance: I knew from the start that I was going to use a lot of interaction patterns over and over. I wanted to be able to write those patterns in a way that would let me use them across features while still staying DRY (don't repeat yourself). The class inheritance provided by dojo.declare() was an elegant, easy-to-use solution to the problem.
• ·         Dependency management: Being able to easily manage dependencies was a huge draw for me; it promotes reuse and abstraction in a big way. Dojo’s dependency management would also pave the way to easily building production-ready files that would combine all the necessary functionality for a given type of page, reducing the number of HTTP requests required.
• ·         Service method descriptions: This particular application relied on XHRs (AJAX) in a big way. Dojo’s service method description approach would let me manage the URLs and parameters for those requests in a single place, keeping pieces that might change separate from the core code. Eventually, theoretically, the server-side code could actually generate this SMD file automatically. More on this in a bit.
• ·         Templating: All the XHR responses were JSON, which I’d need to turn into HTML. jQuery has templating plugins to solve this problem, so this wasn’t really a differentiating factor, but nonetheless it was going to make my life easier. I could maintain the templates for turning JSON into HTML separately from my JavaScript, and even programmatically choose the template depending on the situation.
• ·         The meaning of this: When binding a function to an event on an element in jQuery, this inside the function refers to the element that triggered the event. This is arguably desirable for simple code, but when you start organizing your code into objects with methods and you want this to refer to the object, not the element, it can get painful. The dojo.hitch() method lets you cleanly change the meaning of this for any given function, and it’s transparently rolled into other methods, such as dojo.connect() for event binding.
• ·         Documentation and support: Dojo has a reputation for poor documentation, and to some extent it’s deserved. Their documentation is a whole lot harder to use than jQuery’s because, at first glance, it’s quite a bit more scattered and substantially more API-based than task-based. However, once I figured out where to look for the docs I needed, finding answers to my questions was pretty painless. I also leaned heavily on some experienced Dojo developers for guidance and support, and dropped in to the ever-helpful #dojo IRC channel on Freenode if I got stuck.

"

From the above list, I think one big take away is that finding a single JavaScript library that is the absolute solution is not possible.  You can learn a lot from working with different libraries.  Some libraries provide quite varying perspectives on solving the same problems as other JavaScript libraries.  By learning about their uniqueness you can begin to look at problems in different ways allowing you to become better at designing or putting together your system.

Some other libraries I have recently been learning more about are:

• AngularJS - Built on a concept of providing a full web application framework with simplicity.  They claim much of the simplicity by extending HTML elements with directives (a good introduction on what it does: AngularJS in 20ish Minutes).   Vojta Jina talks about another interesting part of AngularJS in his talk on Dependency Injection.
• React.js - The design decisions made in the architecture of this framework were around reducing coupling and increasing cohesion.  This resulted in a different perspective for a MVC solution (a good introduction by Pete Hunt: React: Rethinking best practices).
• Node.js - "a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices."