So what does reusable JS look like anyway? From my perspective, it’s all about writing and using small, self-contained and focused modules (or packages) that provide unique functionality. While many people would consider jQuery highly reusable, I would probably disagree (at least on some points).
You see, while jQuery is quite portable, you can’t just use a small piece of jQuery and disregard the remainder. For instance, I often find myself reaching for something like $.extend or _.extend but desire little or no extra functionality.
Additionally, libraries like jQuery tend to mix pure JS related logic and functionality with HTML DOM implementation specifics, which means they might have trouble adapting to platforms such as Node.js or CouchDB.
Libraries like Underscore achieve a higher level of reusability than the likes of jQuery, but I still believe we have a way to go. Barriers, however, do exist to creating more granular and thus reusable libraries.
While implementing very granular, reusable libraries is something that is generally encouraged and supported by excellent tooling (e.g. NPM) in the Node ecosystem, this is something that hasn’t translated across to the browser.
Primarily, I believe this is related to the complexity of managing dependencies between libraries for use in the browser. While patterns such as AMD are steps in the right direction, they still lack the elegance and functionality that NPM provides for Node packages. Additionally, while there have been many admirable attempts at creating package managers for the browser (list to be created) none have (or probably will) emerge as a champion in the space.
When the lack of good browser package management (or similar solution) is combined with the absence of unified pattern for module definition (apart from the oversimplified UMD - try universally defining a module with dependencies) things really do get a bit tricky.
My personal opinion (and hence a significant effort over the last 18 months) is that the solution lies in better tooling. Better tools for creating libraries, and better tools for consuming them in a browser environment. The solution (I believe) does not lie in Harmony Modules and as I complete this guide I will strive to explain why.
This guide is in no way meant to detract from the hard work of those currently attempting to improve the situation in different ways. There are many people who are doing great things in this space, but I do have a slightly different opinion and approach that I will attempt to communicate here over the coming weeks.
As this guide is coming together, I’m quite open to (and welcome) different opinions. If you wish to discuss the content of the guide as it emerges, have opinions you wish to share, or have particular topics that you would like to see covered, feel free to use Github Issues.