Separating or not the front-end HTML of the backend can not be considered good or bad in a universal way, this depends on the scope of your project , the type of professionals you have at your disposal, how much you are willing to invest, among other things. And like all development methodologies, there are advantages and disadvantages:
Main advantages:
- Client-server independence;
- Using different resources;
- Focus restricted to each area
Client-server independence:
By separating the client and server layers so that they communicate only via the API (REST, for example) you create complete independence and prevent rework if your back end needs some sort of change.
For example: You have created a project in the X language, but the project has climbed in such a way that you now need to transcribe much of it into the Y language to achieve more performance. This often results in the loss of the template system you used, but with the client independent of the server, you would have it the same way and would only have to take care of exposing and maintaining the same APIs in the new language.
Use different resources:
As much as people still underestimate the UI and UX part of a project, it is becoming increasingly clear that this is one of the most important parts of a project. But the problem is that most professionals working with UI and UX are not back-end programmers, and vice versa.
That is, if you use a template system of your language, or generate the screens in your code, it will be difficult for someone to create screens with the principles of usability and final experience. Now emancipating the front-end and leaving its development to specialized professionals, this is no longer a problem since the Front-end Designers and Developers market has experience (among others) in HTML languages , CSS, and JavaScript.
Focus restricted to each area:
Accompanying the above advantage, this topic represents the fact of having different professionals for different tasks. Just as you do not put the engineer to decorate the living room of a building, you should not put a back-end programmer (who takes care of system logic) to create visual and logical screens on the front end of a system. By separating the back-end and front-end areas you can leave each side freer to work in a focused way in your area, without mixing the sides and the tasks of each professional.
Main disadvantages:
- High cost;
- More complex management;
- Quality Risk.
High cost:
Your project that had a development team will now have one more arm focused on the front end. On the one hand this would somewhat offend the back-end programmers, but on the other, it would have the additional cost of new developers, a new team and an eventual manager for the new area (see next topic) / p>
More complex management:
As stated above, one more "industry" may entail the need for one more manager focused only on the front-end team. The project now would have two fronts that would walk independently but at the same time having the need to have synchrony for a harmonious communication between the client and server sides.
Quality Risk:
This problem can occur on both the back-end and the front-end, but if good tracking and management is not done, or if the contracted professional is not really quality, you may have a front -end messy and difficult to maintain and scalable, which would bring more damage (time and money) than advantages.
As said at the beginning, separating or not the front-end depends a lot on the context in which your project is. And you should take into consideration that cost and management can be heavier at first, but if done with planning, they can have good long-term results.
