JavaScript for Line of Business Applications

Cody Lindley explains why you should ditch non-standard JavaScript module formats and move to the ECMAScript 6 module format with examples.

By using jspm.io you can make use of the official JavaScript module control system (and its syntax) today – all while not having to wait for older modules to be re-written or having to limit yourself to one particular module format or package manager. In other words, you shouldn’t have to care from where a package comes and in what format it’s being provided.

The ideal, and yes we have arrived, is to just use ES6 modules and let a tool like jspm.io sort out all of the ugly details as it pertains to non-es6 modules from multiple endpoints. Not to mention, by using jspm (and a ES6 transpiler like traceur or Babel) you get most everything that ES6 offers, not just modules. Writing ES6 code in your ES6 modules sounds good, right!

With frontend development moving as fast as it does at Bitly, things can get pretty messy. We found ourselves with piles of unmanaged script tags and little indication of what was still being used in the app’s current iteration. There had to be a better way!

Enter Browserify! 

Build and use reusable components in Backbone.js and Marionette.js to make clean and modular code.

Components are critical to scaleable applications because they encourage separation of concerns. Each piece of an application, including components, should have one responsibility and not heavily depend on the other pieces. Applications with tightly coupled modules or a lack of division of work will become incredibly more difficult to maintain and amend with newer features. Adding a single feature could require changing code in several places. Altering a function here breaks a function there, which then requires this other function to handle another parameter.

WHAT
Browserify is and does
WHY
Using it is a good thing
HOW
Your AngularJS code will benefit

Tready.js is a JavaScript framework, that allows running components in Node.js and the browser.

So we asked ourselves, “Wouldn’t it be nice to implement something once and use it in both environments?”. Luckily Node.js provides a way to run JavaScript on the server. Who knows, otherwise we might have ended up trying to run PHP in the browser.

We like to call this approach “Shared Code”, but it might be better known as “Isomorphic JavaScript”. We certainly weren’t the only ones thinking like this. Nodejitsu wrote about this in 2011 and Airbnb picked it up for their Rendr framework.

But we had more ideas. We wanted to build a modular thing similar to an app store, where you’d be able to choose from a pool of apps to put together a website.

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.

I'm a massive fan of JavaScript's Module Pattern and I'd like to share some use cases and differences in the pattern, and why they're important. The Module Pattern is what we'd call a "design pattern", and it's extremely useful for a vast amount of reasons. My main attraction to the Module Pattern (and it's variant, the Revealing Module Pattern) are because it makes scoping a breeze, and doesn't overcomplicate JavaScript design.

It also keeps things very simple and easy to read and use, uses Objects in a very nice way, and doesn't bloat your code with repetitive this and prototype declarations. I thought I'd share some insight as to the awesome parts of the Module, and how you can master it and it's variants and features.

Webpack, for all its size and features is actually pretty flexible in its usage. You can use it in various ways as long as you’re willing to write a long enough config file.

If you only use commonjs and don’t use webpack for managing any CSS or images, then you could, use it like browserify and maintain compatibility with node. But webpack doesn’t try to conform.

Browserify on the other hand, being smaller and more established is easy to pick up. And if you conform to some of its conventions, you have write very little or no configuration to make it work.

So, Browserify is much more likely to work with minimal configuration but will force you into a small set of conventions. Webpack on the other hand will always require some configuration to work for anything but the most basic case.

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.

An amazing omission in Javascript’s design is the lack of a built-in module system. As more projects used Javascript and shared more code, the need for a robust module system became necessary. Two contenders sprung up, Asynchronous Module Definition (AMD) and CommonJS (CJS). The former is much more popular with browser applications and the latter is much more popular with server applications written in node.js.

Having two major standards for defining modules led to a technological holy war in the Javascript community akin to the vim/emacs arguments of the editor world. It wasn’t pretty.

Fortunately, there is light at the end of the tunnel.

You already know that Kendo UI has magnificent widgets. UI is in the name, and Telerik has a long proud history of building amazing UI components. What you may not know, is that you can actually use Kendo UI (specifically MVVM) to work with plain HTML to construct your own widgets. This is sort of like running on the bare metal, but it’s tons of fun and thanks to Kendo UI’s streamlined MVVM, it’s quite easy as well.

Knockout provides the ability to loop over a collection by implementing a for iterator. The power of this really can’t be underestimated since it allows you to take collections and render them visually with HTML getting fine grained control over how each of the items will look. The only problem with this, is that for loops can get unwieldy and don’t mix very gracefully in HTML attributes. This earned some bad rep for Knockout in it’s early days through no fault of the framework itself. Regardless of it’s tendency to clutter HTML, it’s a powerful construct that is noticeably absent from Kendo UI’s MVVM implementation. Or is it?

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.