What are the advantages and disadvantages of generating HTML on the client or server?

Question

Historically, HTML has almost always been generated on the server, with Javascript being used for a few things, such as animations, validations, masks, etc.

However, in recent times there was a tendency to generate HTML (almost) totally in the client, using Javascript.

I’m particularly skeptical about this trend, due to problems like:

• Development and maintenance is more laborious;
• Takes longer;
• It is difficult to achieve testability;
• Javascript not so intuitive for these things as a good server template tool;
• Few people have the knowledge of this technique;
• Difficult compatibility between browsers;
• Among others.

But I would like an opinion from those who have more experience in the subject. What are the advantages and disadvantages of generating HTML on the client? And on the server?

Answer 1

Separate HTML or not (front-end) of back-end cannot be considered good or bad practice in a universal way, it 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:

• Independence between client and server;
• Use of different resources;
• Focus restricted to each area

Independence between client and server:

Separating client and server layers so that they communicate only via API (REST, for example) you create total independence and prevent rework if your back-end needs some kind of change.

For example: You created a project in the X language, but the project scaled to such an extent that you now need to transcribe much of it into the Y language to get more performance. This often leads to the loss of the template system you used, but with the server-independent client, you would have it the same way and would only have to take care to expose and maintain the same Apis in the new language.

Use of different resources:

As much as people still underestimate the UI and UX part of a project, it becomes increasingly evident that this is one of the most important parts in the scope 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 own language, or generate the screens in your code, you can hardly get anyone to create screens thinking about 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) precisely in the HTML, CSS and Javascript languages.

Focus restricted to each area:

Following the above advantage, this topic represents the fact of having different professionals for different tasks. Just as you don’t put the engineer to decorate the living room of a building, you shouldn’t put a back-end programmer (who takes care of the logic of the system) to create screens, visual and logic on the front end of a system. Separating the areas (back-end and front-end) you can leave each side more free to work centered in your area, without mixing the sides and tasks of each professional.

Main disadvantages:

• High cost;
• More complex management;
• Quality risk.

High cost:

His project, which had a development team, will now have another arm focused on the front-end side. On the one hand this would open up the back-end programmers a little, 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);

More complex management:

As stated above, one more "sector" may lead to the need for another manager focused only on the front-end team. The project would now have two fronts that would walk independently, but at the same time having the need to have synchronization for harmonious communication between the client and server sides.

Quality risk:

This problem can occur both in the back end and in the front end, but if it is not done a good level monitoring and management, or if the hired professional is not in fact of quality, it is possible that you have a front-endmessy end and difficult maintenance and scalability, which would bring you more losses (of time and money) than advantages.

---

As said there at the beginning, whether or not to separate the front end depends a lot on the context in which your project is. And you should take into account that cost and management can be heavier initially, but if done with planning, they can have good long-term results.

Answer 2

What is the requirement?

The competition of the web makes more and more the differential of the applications is in the usability or UX (User Experience).

Interaction and response time are priority requirements for the modern user, adept from an early age of smartphones and other devices smart.

And this trend is justified in the fact that it is necessary to please the user and, at the same time, it would be impossible to send requests to the server every interaction with the graphical interface (UI - User Interface).

As for the points raised

Development and maintenance is more laborious

Yes, but more elaborate results are almost always more laborious. Industries always start with simpler products and add layers of complexity year after year as technologies mature.

Takes longer

Yes, but the same is true when we always want more quality, more performance or any other technical issue.

It is difficult to achieve testability

Yes, but it is also easier to test a bicycle than an airplane, however, the companies that manufacture the latter bill much more.

What I mean is that complexity always increases the difficulty of testing, but the additional cost is a price to pay for greater rewards.

Javascript not so intuitive for these things as a good server template tool

Yes, but the trend is to change. I agree that almost all frameworks that propose to generate or abstract HTML or CSS end up being a nightmare in the end. But sooner or later someone gets it right. (Have you seen the React.js?)

Few people have the knowledge of this technique

Yes, but that’s just the difference. Companies with a vision of the future and that invest in technology (not so much the reality here in Brazil) prefer to invest in a UX above average in order to maintain a competitive advantage.

Difficult compatibility between browsers

This is a reality in more dynamic or more static systems. But just as jQuery has revolutionized this compatibility issue in a way, the same result can be achieved with libraries like Angular.js and others that are in this category.

Completion

Although the development scenario of web applications is increasingly complex, this is a trend that has come to stay, given the great competition between high quality applications available today.

It is up to us developers, however, to think and rethink more productive and secure ways of progressing technologically rather than trying to grasp the security of what is "traditional".