Why Your JavaScript Apps Don’t Scale


Lots of people talk about scalability when building JavaScript apps and platforms, but what does scalability mean?

I think people mean two things. They either mean a JavaScript app can scale from a technology perspective or, they mean it can scale from a people perspective.

The former being a consideration around tooling and performance, the second being a consideration around interactions and communication within a team of engineering folk who are building complex software.

Today we are talking about the second!

The Framework Crisis

Our Story starts with the crisis of frameworks. There are many frameworks in the JavaScript ecosystem such as React, Mobx, Moment etc.

A framework is just a collection of code that ‘somebody else’ wrote to help us make writing custom code faster and easier.

As a development team builds software they must connect up parts of the framework to other parts of the system and even other frameworks!

This presents a problem with the dependencies in our code base. Much of our framework code becomes conjoined and tangled up with other parts of the framework. The stuff in the user interface (the view) calls the stuff in the navigation (the pop out menu on a web or mobile app). The stuff in the navigation calls back into the view. The view then calls our web stuff (like API’s). And when the call is complete it comes back to the view.

At first, connecting up parts of our framework to other parts of our framework ‘seems’ fine. The documentation says to do it. All the blogs say to do it, and it makes ‘logical’ sense.

But over time this criss-crossing of having one framework tell another framework what to do introduces the biggest hurdle in building complex software; complexity.

The complexity exists because it’s hard to remove duplication of code when you have an app built in such a way. It’s hard to make generic modules of code when much of it is hard wired to a framework, why? Because the framework has now affected the shape of your code. The framework is now in charge of your custom software not your development team.

Also, developers only have a limited attention span. Forcing them to understand both framework level detail and business problem level detail is restrictive.

Complexity stands in the way of productivity because it slows down thinking. And slowing down thinking ends up in two things;

1) you need more thinkers which is harder to manage
2) the rate of productivity with each thinker starts to get slower and slower

Thus, through the use and ‘abuse’ of the humble frameworks you have a ‘scale’ problem on your hands!


A better way to organise a code base for JavaScript teams is to divide up their apps into boundaries. Boundaries in software present clear architectural ‘divisions’ in code. These divisions can be anywhere we want them. For the purpose of this article we are going to create a boundary between the following ‘types of code’

  1. Modules that change the shape of the view
  2. Modules that run a business process
  3. Modules that interact with the infrastructure

Many JavaScript teams are now using TypeScript; and with it’s ability to load in extra information into the design of software declaring boundaries is set to get easier!

So in our upgraded form of code base where we have boundaries, we begin to ‘pop’ all of the code that was buried in the framework ‘out’ of the framework and put it into simple objects that have only a single purpose. They don’t call the view. They don’t call the web. In fact, they don’t do much apart from provide simple inputs and outputs.

They allow themselves to be called and for the most part simply return data structures back to our framework code.

We can now begin to see our app take a ‘clearer’ architecture because we have separated out our custom code and the framework code.

With Clarity Comes Scale

We have built many apps here at Logic Room and when we have a clear policy for separating using our methodology untangle code into custom code and framework code; it helps us produce better software.

For example; when my colleague asks me for my opinion on how to solve a particular issue we now have a more granular code base, and because of this we can put custom code into relevant modules that serve simple purposes, we can keep the framework code where it belongs (in the framework).

This aids communication because we have a policy for organisation. And being organised makes things easier.

When we converse about architecture I can picture in my mind’s eye where exactly my colleague us asking me to think about. And what it might look like to him/her. This ability for me to be able to understand them more quickly and more confidently allows us the ability to work better together.

And working better together is the start of building a scalable team of people!


We see that building scalable JavaScript apps is about making it easy for the developers themselves to be part of this scale. By building software in a ‘framework first’ approach we reduce our application to framework configuration over customisation.

Whilst framework configuration is fine for smallish apps that need little customisation as soon as you build up your requirements you will hit scalability issues.

By taking a ‘custom code’ approach and separating your apps into two apps (framework and custom code) you can separate out the true business problem and scale this until your hearts content.

This ‘dual’ approach can be used in any app that uses a framework (even microservices).

I hope you enjoyed this article.