JavaScript for Line of Business Applications

This article introduces the Browserify tool. It also shows how Browserify can be integrated with Grunt and Gulp.

any of us now work with JavaScript modules – independently functioning components that come together to work as a cohesive whole, yet can happily have any component replaced without causing armageddon. Many of us have been using the AMD module pattern and RequireJS to accomplish this neatly.

The Javascript world is dominated by frameworks, and it is because of our reluctance to having dependencies in our libraries. If you are going to write a Javascript library, you have two options:

1. Depend on a proven framework.
2. Depend on no one.

If you choose option #1, you contribute to the worship of the framework.

If you choose option #2, you are faced with a problem. If you make it too small, it may not be useful enough to warrant a download (are you download-worthy?). What happens sometimes is a set of smaller functionalities get packaged up into a larger library to give users more value for the download. Another thing that tends to happen is established libraries get bigger over time as new techniques are discovered and new features invented, because this makes it easier for existing users.

As someone who likes to write small libraries, the dream for me, is this: I want easy dependencies: regardless of how many dependencies and/or nested dependencies my project has, I want to be able tell people "using my library is as easy as 1-2-3."

What I want is something like NPM.

An often overlooked piece of JavaScript examples, tutorials and discussion is the writing of libraries/modules.

While there is a vibrant community of people writing UI centric jQuery Plugins with a de-facto style and methodology, paging through Github repositories of the many libraries, frameworks, plugins, etc will show an extremely disparate set of coding styles and methods.

As more and more browsers support experimental ES6 Module Features, and others use transpilers to write in ES6 transpiling to shim'd JavaScript/ECMAScript5 which export to AMD format & client-side JavaScript becomes even more complex and large, users will use module style coding as the standard.

Regardless of whether or not you want to support CommonJS, RequireJS/AMD or just write a library which aliases its' constructor or main method/object to the window: anyone could benefit from writing small, testable and compartmentalized modules.

RequireJS is great, and if you are using or planning on using RequireJS for managing JavaScript then you’ll really notice the benefits.

However one of the trickier parts of RequireJS greatness is finding a way to organise JavaScript modules across multiple pages and on a more granular level, multiple HTML modules on those pages.

This post won’t be an intro to what AMD modules are, or even a RequireJS tutorial, as a basic understanding of AMD and RequireJS is assumed but I will break some of the concepts down where necessary.

Recently I had the opportunity to use Browserify as one of the tools for creating a JavaScript module for a client that is building a mapping product for architects and urban planners.

In that project I used Browserify and npm scripts to bundle the module into a file the client could use as a standalone library that could be added to any web page that needed to use the tool.

It was a fairly straightforward and flexible build process, and here I'll outline a similar structure that you could use in your projects.

Our example project will be named Pizza, because our example library will do nothing but return the string 'Pizza'. Deal with it.

After being a bit resistant at first, I have happily moved to using require.js to manage dependencies in most of the Knockout.js applications that I have written in the last year or so. With each application, I have tried a number of patterns to make it easier to work with AMD (Asynchronous Module Definition) modules. Recently, I decided to formalize some of these patterns into a lightweight plugin that makes it simple to bind against modules and pull in templates that live in external files.