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.
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.
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.
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
Make modules as small as possible
(without fragmenting your code to much)
Make sure your modules apply Separation of Concerns .
Use a build tool to bundle modules that make sense in your context.
On the server there's really no need for bundles.
For web go with multiple bundles, for mobile go with one.
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 .
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.
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:
Most of you are already doing this:
But you should think bigger:
Don't forget to bring a towel
- HGTTG / Towlie
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?
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