You’ve likely heard about frameworks and libraries around JavaScript. The ecosystem is evolving at speed where we are facing JavaScript fatigue. The overwhelming amount of tooling it requires to set up a project and get it running is quite high. In this post, we’ll take a bird's eye view of the problem libraries/frameworks are trying to solve and when you might want to use one.

Specifically, we’ll be understanding:

• How frontend applications grow
• What problems do we face when it scales
• How libraries/frameworks are helping in these matters

How frontend applications grow

We can build a simple frontend app with just three files: HTML, CSS & JavaScript. However, if we keep on building this app with more features:

• Files grow along with it, leading to unmaintainable code.
• There’s a lot of repeated code between them.
• We’d be binding event listeners to UI elements(input fields, buttons, etc..), then writing callback functions to update the values of the same elements.
• We worry about how it’ll impact the application before making any change.
• Explaining code to fellow developers will take hours

These problems deepen with time and the complexity to manage these issues grow over time even if we plan for these since you may never know how our app is going to evolve.

Two of the most important ideas of reactive programming are that systems should be event-driven and responsive to state changes.

• The DOM’s user interface components have an internal state, and updating the browser isn’t as simple as just regenerating the DOM whenever something changes. If Gmail did this, we would be constantly annoyed when the entire browser window refreshed in order to display a new message, wiping out the email we were composing.
• The statefulness of the DOM is why we need user interface libraries and solutions such as key/value observation or dirty checking (which is used by Angular). UI libraries handle watching for changes to the data model and updating the correct part of the DOM when these changes occur, or watching for changes in the DOM and updating the data model when they occur.

This type of watching and updating is called two-way binding, and it can often make working with user interfaces very complex and confusing.

Enter, library & framework

Each framework offers its own design philosophy but they are trying to solve the same general problem we encounter in the development cycle:

• Easy to maintain code, easy to read and change for new developers onboarding the codebase.
• Ability to reuse components to create pages or features.
• Ease of manipulating DOM without any side effects
• Standardizing UI to be consistent and intuitive, means having defined values for typography, colors, padding, margin, etc.

Frameworks and libraries provide a full toolset that helps in shaping and organizing our app. It provides a standard from the moment you install them, guiding you to think and code in a specific way. We don’t need to spend time creating a standard with our team; we can just follow how things are done in the framework.

Ideally, we want our web app as a standalone application, requesting data from the backend, processing it client-side, if needed, and displaying it on browsers. The underlying principle here is “separation of concerns”. How each part of our app should operate independently and have a well-defined interface to communicate with others.

Conclusion

Frameworks and Libraries are powerful tools enabling us to write applications in a declarative way. It encourages all the right ways to build a modular, standalone architecture that is easy to maintain and scale.

However, it can be overkill for smaller projects and prototypes. It has a steep learning curve apart from the tooling it requires to build and run projects.

Now to answer our first question, do we need libraries and frameworks in JavaScript, the short answer is no if you focus on the features, while the real answer is yes if we focus on the user and developer experience.