Massive JS

JS application development at an enterprise levelĀ 

EF Labs (Shanghai)

Defining Massive

Big is something like jQuery - a few modules, one-five maintainers, all modules synced in one release.

Large is something like GitHub - many separate modules, a few teams working in separate areas, but one core front-end team focused on the whole website.

Massive is something like GMail - many applications in one page, many different teams collaborating, separate release cycles per team and application.

N applications - N teams
1 experience

In the usual enterprise environment we see many applications maintained by many different teams.

A lot of the time these teams are not in the same group.

  • or the same department
  • or the same office
  • or even the same company

So naturally changes and releases are a P.I.T.A and communication often breaks down.

But we still want it all to be one integrated and consistent experience.

All your modules
are belong to us

The first rule of massive scale
JS application development is modularization.

The second rule of massive scale
JS application development is modularization.

Everything should be a module

  • your code
  • your templates
  • your styles
  • your data

Develop small

Make modules as small as possible
(without fragmenting your code to much)

This keeps your code:

  • easy to read ...because there's less of it
  • easy to maintain it's easier to debug and fix
  • easy to use ...and modify ...and extend

Make sure your modules apply Separation of Concerns .

Deploy bigish

Use a build tool to bundle modules that make sense in your context.

  • Common reusable code packaged in a separate bundle.
  • Applications packaged in multiple bundles, by function.
  • Massive application should be split into smaller applications.

On the server there's really no need for bundles.
For web go with multiple bundles, for mobile go with one.


Or why a message bus rocks

Let's try to learn something from our friend / foe
the back-end developer

In massive systems (and probably everywhere else) small, modular and distributed always beats large, monolithic and centralized

This is why we have EIP , ESB and micro services.

Actually, this whole REST thing was invented for server to server integration way before all you DHTML kiddies came along with AJAX .

What about the front-end?

Similar patterns can be applied in the front-end to, but instead of just connecting to the back-end, we connect components.

You are probably already doing (some) of this with DOM events and event bubbling.

A good rule of thumb

When you are talking to a logical parent component use DOM events, when talking to any other component use a message bus


One of the advantages of using a message bus is that components can subscribe to changes without affecting the whole application.

It also also allows the developer to swap out implementations of components without having to update all the dependent applications.

If you think about it, you can actually mock an entire component or application from the message bus, thus getting the same benefits we get when we mock the back-end.

Be async

Asynchrony, in the general meaning, is the state of not being synchronized.
- Wikipedia

Unless you are sure whatever you are doing
is and always will be synchronous
go async.

Because things change:

  • Your connection speed.
  • Your connection reliability.
  • The weather.
  • Solar flares.

Be event driven

Most of you are already doing this:

But you should think bigger:

Be expressive, declarative
and stay DRY

Don't forget to bring a towel
- HGTTG / Towlie
  • Be expressive - name your methods, chain operations, think about your URL structure.
  • Be declarative - what do we want to do instead of how do we do it.
  • Do not repeat thyself!

In the end it's all about congnitive load.

So we split our code into modules that are used in our applications then package them into bundles. What now?

The root application

the one application to rule them all

  • Is the only guaranteed singular application.
  • Is responsible for managing common services.
  • Is the container for other applications.

For example:

If you are GitHub , and you bubble events from everywhere , and you catch them all at the top of the page

you would probably call that piece of code the root application|controller|router|whatever