Is AngularJS really that perfect? Detailed analysis of several issues with angularjs

Let’s not talk about AngularJS Advantages, at least most front-end workers still have a fanatical respect for AngularJS. Because it makes development easy. So the question is, why don’t many well-known websites use Angular? Let’s take a look at this article

Let’s start with a few points:

1. The worst SEO friendliness

This point is undoubtedly very fatal , this is an important reason why many young start-up companies dare not try. Search engine crawlers and social preview screenshots cannot recognize pages rendered with JavaScript, and existing solutions are complex and very slow.

In fact, usually the loading of a page is composed of five parts (take java as an example):

1. The browser sends an Http request to the server

2. The server processes this request to obtain the result data, obtains the Jsp template, builds the data into html text recognized by the browser through the template and sends it to the browser

3. The browser parses the HTML text and presents the page content

It can be seen that in the last step, when the browser gets the HTML text, that is when the process ends, we need The data will be displayed. The process of using Angular is as follows:

1. The browser sends an Http request to the front-end server

2. The front-end server sends the HTML template to the browser

3. The browser parses the HTML and executes the js script, and sends an Http request to the business server.

4. The server processes this request and obtains the result data. Encapsulate it into Json format and send it to the browser

5. The browser parses Json and presents the data in the page

These two processes, one One is to put the page building operation in the server, and the other is to put it in the browser. This is the most obvious difference. Not to mention the extra number of interactions, from the perspective of a search engine, it can only see the static content obtained by the browser, and it will not execute your js code.

The former search engine sees an article, while the latter search engine sees curly braces one by one! This is also the reason why pages rendered by Angular are included in Baidu's "blacklist". So how to solve it?

Quote:

There are two ways to let crawlers access your website. You can run a browser instance on your server and then generate HTML pages based on the DOM after JavaScript execution. Or you can build another set of HTML static pages for search crawlers.
The former option requires you to install WebKit (and possibly Xvfb) and then generate the page after it has loaded (you can also use caching, but this adds more complexity.) This will increase your page load time, This affects your search engine rankings.
The latter solution (making another server-side website) can satisfy simple websites, but if your pages are very diverse, it will be a nightmare. And if your backup website is completely inconsistent with your main website, Google will punish you severely and your traffic will plummet.

2. The worst user experience

After using AngularJS, the page rendering method is split into multiple processes, so if I visit a page, and the page's When there is a lot of content, I will obviously feel the browser's rendering process. I have too much content to load. This process is very bad, especially when the loading process is placed on the client, the delay will be Very big.

In rich JavaScript applications, page transitions usually occur immediately, and then different elements are loaded from the server. In server-side applications, the page starts rendering data without waiting for the client to download all the data.

It sounds like the client application is better, but in fact this is an illusion.
Imagine that when the user clicks on a link, a loading animation immediately appears in the client's JS application, but the data takes 5 seconds to load. The application just looks fast at first glance,
Let’s not discuss how many programmers want to add functions to this page. It is difficult for you to require people to present the content quickly in an asynchronous manner. In fact, people will not care if the things below the page are loaded later.

In server-side applications, if an API call is slow, the entire page will load slowly. You can't ignore server-side slowness because it affects everyone. But the slowness of the client is easily overlooked.

You can easily solve the slowness of the server, because the server is controllable and runs on the machine you configured. You can clearly know what is happening on this machine. Moreover, most servers are in an internal cluster network, which makes the information transfer between them very fast. Even if an action requires multiple information transfers, it can be completed in an instant. But putting these transfers on the client will slow it down for many factors.
We cannot strictly control what browser users use, nor can we control the configuration of the user's machine, but we can control everything about our own server.

3. The most important thing is too tasteless

tasteless? Some people will say that AngularJS has various benefits, such as 'easy to maintain', 'convenient coding' and so on. But this is based on sacrificing performance and user experience. And the so-called 'dependency injection' and other back-end ideas are forcibly introduced into the front-end. This seems lofty, but what seems wrong? The back-end is divided into architectures, services, and various frameworks are used for simpler development. The web front-end itself is just HTML text that appears in the browser. It is static and does not involve business. I don't think it would be of any real help to him.

From these conveniences, it may not be said to be useless, but In any scenario, there is almost a solution that can perfectly replace AngularJS and do it better than it. this. . . This is embarrassing! For example freemaker.

Freemaker will be familiar to everyone. It can directly call the freemakerApi function provided by Java instead of executing an http request through ajax to obtain data asynchronously. Similarly, its performance also beats AngularJS Perhaps it is a bit bullying compared to its performance, but as a template engine, freemaker is indeed qualified to crush AngularJS in terms of performance.

In terms of ease of use, in addition to directly calling Java functions, freemaker can also obtain data through http, but it will build the obtained data into html text and then hand it over to the browser for parsing. , and the most important thing is that it also supports dependency injection and other related features, and is perfectly integrated with the back-end program. Combining the above points, whether it is in terms of scalability, maintainability, overall performance, user experience, etc., it is Crushed AngularJS. The only thing that is not as good as AngularJS is the development stage. Compared with angular, freemaker development is more complicated, or in other words, angular is much simpler in the development process. If it is just because development becomes enjoyable and a large number of performance factors are discarded, this is It's very scary. Some people are constantly optimizing in pursuit of performance mechanisms, while some people are optimizing for simpler development. I can't say who is right or wrong, but I prefer the former.

Leave aside freemaker, there are also a large number of replaceable solutions in nodejs and a large number of mvc frameworks, so I won’t go into details here.

I think the role of js in the browser should be more in interaction rather than content presentation. That is not the correct solution.

4. Application scenario issues

AngularJS seems to be a good choice in the scenario where the front and back ends are separated, but as mentioned above, AngularJS takes too much into account when the front and back ends are separated. Too narrow, after our separation, development became more convenient, but the original performance and experience were lost, which is undoubtedly a failure. Combining these reasons, there may be very few scenarios where AngularJS can be used, but it seems to be in the background ( It can be used in two scenarios: backend management control panel) and WEBApp.

Then the question is, developing the management console page does not need to consider too much about performance, nor does it need to be optimized for SEO, but the midpoint in this scenario is interaction, not content display. superior. AngularJS has lost its position as a front-end template engine. His role was minimal, which was embarrassing.

When developing WebApp, she may not need to consider SEO. In terms of performance, the App framework can optimize performance because I can strictly control the client version used by users. I can choose the App framework, but since I can choose the App development framework by myself, almost any App framework has a solution that surpasses AngularJS, both in terms of performance and ease of use. So this seems worse than developing the admin console page.

Based on these points, I think AngularJS’s position is very embarrassing.

The only scenario without conflict may be the scenario of developing internal applications of the enterprise.

This may be why AngularJS seems great, but few companies choose it. The pursuit of performance is what every programmer should have, especially those engaged in back-end development. They will consider more and cannot give up experience for the sake of seemingly convenient development. If you really give up, what kind of distinction will you make between junior high school and high school? Where did the architect come from? Just start a bunch of code consultations.

Similarly, this has also caused embarrassment for some front-end engineers during interviews:

Q: Can you use AngularJs?
Answer: Yes! Well. . But not used much. . But I really do. . Well

Let’s not talk about the advantages of AngularJS. At least most front-end workers still have a fanatical respect for AngularJS. Because it makes development easy. So the question is, why don’t many well-known websites use Angular?
Let me start from a few points:

1. The worst SEO friendliness

This point is undoubtedly very fatal, which has caused many young start-up companies to fail easily. An important reason to dare to try. Search engine crawlers and social preview screenshots cannot recognize pages rendered with JavaScript, and existing solutions are complex and very slow.

In fact, usually the loading of a page is composed of five parts (take java as an example):

1. The browser sends an Http request to the server

2. The server processes this request to obtain the result data, obtains the Jsp template, builds the data into html text recognized by the browser through the template and sends it to the browser

3. The browser parses the HTML text and presents the page content

It can be seen that in the last step, when the browser gets the HTML text, which is when the process ends, we need The data will be displayed. The process of using Angular is as follows:

1. The browser sends an Http request to the front-end server

2. The front-end server sends the HTML template to the browser

3. The browser parses the HTML and executes the js script, and sends an Http request to the business server.

4. The server processes this request and obtains the result data. Encapsulate it into Json format and send it to the browser

5. The browser parses Json and presents the data in the page

These two processes, one One is to put the page building operation in the server, and the other is to put it in the browser. This is the most obvious difference. Not to mention the extra number of interactions, from the perspective of a search engine, it can only see the static content obtained by the browser, and it will not execute your js code.

The former search engine sees an article, while the latter search engine sees curly braces one by one! This is also the reason why pages rendered by Angular are included in Baidu's "blacklist". So how to solve it?

Quote:

There are two ways to let crawlers access your website. You can run a browser instance on your server and then generate HTML pages based on the DOM after JavaScript execution. Or you can build another set of HTML static pages for search crawlers.
The former option requires you to install WebKit (and possibly Xvfb) and then generate the page after it has loaded (you can also use caching, but this adds more complexity.) This will increase your page load time, This affects your search engine rankings.
The latter solution (making another server-side website) can satisfy simple websites, but if your pages are very diverse, it will be a nightmare. And if your backup website is completely inconsistent with your main website, Google will punish you severely and your traffic will plummet.

2. The worst user experience

After using AngularJS, the page rendering method is split into multiple processes, so if I visit a page, and the page's When there is a lot of content, I will obviously feel the browser's rendering process. I have too much content to load. This process is very bad, especially when the loading process is placed on the client, the delay will be Very big.

In rich JavaScript applications, page transitions usually occur immediately, and then different elements are loaded from the server. In server-side applications, the page starts rendering data without waiting for the client to download all the data.

It sounds like the client application is better, but in fact this is an illusion.
Imagine that when the user clicks on a link, a loading animation immediately appears in the client's JS application, but the data takes 5 seconds to load. The application just looks fast at first glance,
Let’s not discuss how many programmers want to add functions to this page. It is difficult for you to require people to present the content quickly in an asynchronous manner. In fact, people will not care if the things below the page are loaded later.

In server-side applications, if an API call is slow, the entire page will load slowly. You can't ignore server-side slowness because it affects everyone. But the slowness of the client is easily overlooked.

You can easily solve the slowness of the server, because the server is controllable and runs on the machine you configured. You can clearly know what is happening on this machine. Moreover, most servers are in an internal cluster network, which makes the information transfer between them very fast. Even if an action requires multiple information transfers, it can be completed in an instant. But putting these transfers on the client will slow it down for many factors.
We cannot strictly control what browser users use, nor can we control the configuration of the user's machine, but we can control everything about our own server. (If you want to learn more, go to the PHP Chinese website AngularJS Development Manual to learn)

3. The most important thing is too tasteless

? Some people will say that AngularJS has various benefits, such as 'easy to maintain', 'convenient coding' and so on. But this is based on sacrificing performance and user experience. And the so-called 'dependency injection' and other back-end ideas are forcibly introduced into the front-end. This seems lofty, but what seems wrong? The back-end is divided into architectures, services, and various frameworks are used for simpler development. The web front-end itself is just HTML text that appears in the browser. It is static and does not involve business. I don't think it would be of any real help to him.

From these conveniences, it may not be said to be useless, but In any scenario, there is almost a solution that can perfectly replace AngularJS and do it better than it. this. . . This is embarrassing! For example freemaker.

Freemaker will be familiar to everyone. It can directly call the freemakerApi function provided by Java instead of executing an http request through ajax to obtain data asynchronously. Similarly, its performance also beats AngularJS Perhaps it is a bit bullying compared to its performance, but as a template engine, freemaker is indeed qualified to crush AngularJS in terms of performance.

In terms of ease of use, in addition to directly calling Java functions, freemaker can also obtain data through http, but it will build the obtained data into html text and then hand it over to the browser for parsing. , and the most important thing is that it also supports dependency injection and other related features, and is perfectly integrated with the back-end program. Combining the above points, whether it is in terms of scalability, maintainability, overall performance, user experience, etc., it is Crushed AngularJS. The only thing that is not as good as AngularJS is the development stage. Compared with angular, freemaker development is more complicated, or in other words, angular is much simpler in the development process. If it is just because development becomes enjoyable and a large number of performance factors are discarded, this is It's very scary. Some people are constantly optimizing in pursuit of performance mechanisms, while some people are optimizing for simpler development. I can't say who is right or wrong, but I prefer the former.

Leave aside freemaker, there are also a large number of replaceable solutions in nodejs and a large number of mvc frameworks, so I won’t go into details here.

I think the role of js in the browser should be more in interaction rather than content presentation. That is not the correct solution.

4. Application scenario issues

AngularJS seems to be a good choice in the scenario where the front and back ends are separated, but as mentioned above, AngularJS takes too much into account when the front and back ends are separated. Too narrow, after our separation, development became more convenient, but the original performance and experience were lost, which is undoubtedly a failure. Combining these reasons, there may be very few scenarios where AngularJS can be used, but it seems to be in the background ( It can be used in two scenarios: backend management control panel) and WEBApp.

Then the question is, developing the management console page does not need to consider too much about performance, nor does it need to be optimized for SEO, but the midpoint in this scenario is interaction, not content display. superior. AngularJS has lost its position as a front-end template engine. His role was minimal, which was embarrassing.

When developing WebApp, she may not need to consider SEO. In terms of performance, the App framework can optimize performance because I can strictly control the client version used by users. I can choose the App framework, but since I can choose the App development framework by myself, almost any App framework has a solution that surpasses AngularJS, both in terms of performance and ease of use. So this seems worse than developing the admin console page.

Based on these points, I think AngularJS’s position is very embarrassing.

The only scenario without conflict may be the scenario of developing internal applications of the enterprise.

This may be why AngularJS seems great, but few companies choose it. The pursuit of performance is what every programmer should have, especially those engaged in back-end development. They will consider more and cannot give up experience for the sake of seemingly convenient development. If you really give up, what kind of distinction will you make between junior high school and high school? Where did the architect come from? Just start a bunch of code consultations.

Similarly, this also caused embarrassment during interviews for some front-end engineers:

Q: Do you know how to use AngularJs?

Answer: Yes! Well. . But not used much. . But I really do. . Uh

This article ends here (if you want to see more, go to the PHP Chinese website AngularJS User Manual). If you have any questions, you can leave a message below.

The above is the detailed content of Is AngularJS really that perfect? Detailed analysis of several issues with angularjs. For more information, please follow other related articles on the PHP Chinese website!