Introduction

We've seen the MVC pattern that allows us to serve static assets from dynamic content. The next paradigm that we will explore is the concept of having light API back-ends whose sole purpose it is to send and receive data with "heavy" front-ends that handle all of the application logic with JavaScript. This frees us up from the "tight-coupling" that we get with MVC applications which in turn gives us the ability to enhance our applications with relatively lower overhead.

"Heavy" JS front-ends vs MVC

Probably the first benefit of a heavy front-end vs and MVC based application is how much faster a heavy front-end ecosystem is. In this sort of an environment only the pieces of the application that need to change actually get changed. This saves the application from going all the way back to the server to refresh the entire application and return you a whole new page every time the user has some dynamic interaction with the app.

The other benefit is the ability to decouple the front-end from the back-end and essentially make two separate but interactive projects. This way these layers of the application don't need to know anything about each other and allow use to write less code. It also means that our front-end application is free to interact with multiple different APIs at any given time thus reducing the work that our single back-end is responsible for. So, if we are building an app to track the books our users are reading/have read, instead of having a database that has to handle our users and all of their information, authors and all of their information, books and all of their information, etc. We can consume information from a few smaller more dedicated services. One db for our users, another for authors, another for books, etc.

Heavy Front-ends are Fast

Contrary to their name, which only means that all of the application functionality is housed on the client, JavaScript front-ends are super fast. They do come with the trade off of sending a decent sized chunk of JS to your user right up front. But once it's there, we don't have to send requests to the server for full page reloads. We're only sending data back and forth and using JavaScript on the front-end to re-render, which, by comparison to reloading the whole page every time we make a small change is considerably faster.

Code Cleanliness

This approach also ends up being a more clean approach generally because of the code separation. You get to have separate testing suites that are never run together because they are totally independent. Also being able to build small APIs that don't have to interact with each other keeps data design much more simple.

Conclusion

This approach has a lot of upsides with the way the web currently runs. But it is extremely important to note that it is not inherently better than an MVC application. It is important to keep in mind to use the right tool for the job. Be sure to evaluate just which approach is going to be best for the tool you want to build.