Thursday, June 28, 2012

Code of Three Kinds

Client-side javascript can be generally be put into three categories:

  • Frameworks  ("raw material")
  • Plugins          ("wheel")
  • App code      ("ford taurus")
The first two are what i often call "libraries".  They are reusable features and functions meant to be shared across projects.  The third is the code that makes your app what it is and is typically useless to others except perhaps as an example or template of how to use the frameworks and plugins.  Even then, it is often so busy and complex that it rarely works as a clear example.


These are the libraries we are required to use (See Use jQuery).  Probably single most distinguishing feature of these libraries is that your webapps can (and should!) pull them off of a CDN.  These have become part of the plumbing of the internet, and the more people who use a CDN for them, the better.  It speeds things up for everyone involved.

Another common reality about frameworks is that they usually offer far more features than any one app will use.  This is to be expected and accepted.  Customizing them to only download what you need defeats the point of common CDNs and all the caching available that way.  Don't worry about the extra code, it's not worth the worry.

Again, DON'T CUSTOMIZE and DON'T REINVENT, at least never a core feature.  These are not wheels, these have become the raw materials of a webapp.  Reinventing or rearranging them one molecule at a time is a waste of time, unless perhaps, you are doing it on behalf of a major tech company that plans to market and fund it all for you.


These are what i am calling "wheels".  They are the shims, polyfills, widgets, extensions and other features that are used to build applications.  They are not specific to a particular application but are not likely to be needed or wanted by a majority of applications out there.  These cannot be found on CDNs but are rather all over GitHub and Google Code and hundreds of personal blogs and websites scattered around the internet.  For each polyfill or widget i might want, there are a dozen competing implementations, all of which do either too much or too little or both.  I usually think i could write them better myself and odds are 70/30 that i'm right.  This isn't just arrogance, the reality is simply that they wrote it for a particular app or audience that doesn't exactly line up with me and my app.  Personally, even when i'm wrong about this, i often learn some good things in the process of trying to write my own version or port one over to jQuery.

I will probably freely switch between calling these "plugins", "wheels" and just "js libs" to keep things confusing.

App Code

This is the code that uses the plugins and framework(s) together in a unique way to make your webapp (or just web page) what it is.  Unless your next app is merely a variation on your previous one, then you can expect that none of this will be reused.  And, in general, it is only worth talking about in the context of ways to reduce and simplify it via better plugins and frameworks.  Just as i would never pollute a framework with plugin customizations, i strive to keep my plugins free of app code.

Make sense?