Your frontend, is not your backend...

Introduction

Back in the days, before my time, most webpages were static. They were just a bunch of HTML files served to the user. Then came the dynamic webpages, where the server would generate the HTML files on the fly. This was done using a templating engine, which took the data from the database and inserted it into the HTML file. This was a huge improvement, as it allowed for dynamic content, and the ability to create a single page that could be used for multiple purposes. This marked the birth of the backend, paving the way for the segregation between the frontend and backend.

As technology advanced, we gained the ability to make asynchronous requests to the server. The frontend could now fetch data from the backend, updating the page without reloading it. This is popularly known as a Single Page Application (SPA). More and more logic moved to the frontend, while the backend primarily served data to the frontend.

Don't mistake your frontend, for your backend

As a frontend developer, we've all been there. You're asked to consume some kind of data from the backend. The task might go a little like this: "We need to display a list of products for our customers. Their individual discount should be calculated into the product's price". Sounds easy enough, right? Well... As with everything else in life, it depends. If the data we need is already provided to us by the backend, then it's a simple task. But if the data it isn't, and needs to be calculated, then it's a whole other story.

You might see where I'm going with this, but still, let me explain.

Doing heavy calculations in the frontend is like using a butter knife to chop vegetables. Sure, you might manage to get the job done, but it's not the right tool, and you'll end up spending more time and effort than necessary. The frontend is designed to present data to users in an appealing and intuitive manner, while the backend is where the heavy lifting, data processing, and business logic should take place. And yes, you are allowed to convert data types in the frontend, but that's about it. Again, it's about representing the data, not "processing" it.

Beware of overloading the frontend

If you start shifting tasks that traditionally belong in the backend to the frontend, you risk:

• Performance: If the task is resource-heavy, it's going to hinder the browser from doing "browser stuff". The page might feel slow, leading to a poor user experience.
• Security: Doing calculations in the frontend could expose sensitive data or business logic to the user. The browser should be treated as an untrusted environment!
• Maintainability: You might end up with the same logic in multiple places, making it harder to maintain. Discrepancies could arise, leading to different results in different places.

Conclusion

Maintaining a clear separation between the frontend and backend will enhance your developer experience and make your code more maintainable, especially in larger teams with distinct frontend and backend developers. Let the backend do what it's good at - data processing, business logic, and calculations. And let the frontend do what it's good at - presenting data and handling user interactions.