Five drawbacks of client JavaScript

:The original title is: "Why don't we use AngularJS :...", Later, the author thought it was inappropriate to get rid of it, because AngularJS is usually applicable to SPA. Many people understand it as an attack on AngularJS, but this is not his intention.

A few months ago, when we opened the Sourcegraph website, it was a rich AngularJS application. The server only needs to return the original HTML and JSON endpoints, and the rest will be handled by Angular. We made the Sourcegraph of the original version in this case.

However, the single-page JavaScript framework does not apply to every site. Sourcegraph is a content-based site. We gradually find that the development of this rich js application is more harmful than the advantages. The following is a gap we have encountered on this road, I hope to help developers who have similar experiences.

Next week, we will discuss more about how we migrate server-side GO templates from AngularJS.

Five drawbacks of the client JS framework

We have long known that there will be many difficulties, but we do not know how difficult it is.

1. search ranking and Twitter/Facebook Preview

Search engine crawlers and previews of social media sites cannot load pure Javascript sites. If a new version is provided, it is slow and complex.

There are two ways to allow crawlers to read your website. You can run a browser instance on the server to execute Javascript in your application, and then return the HTML result PlantomJS or WebLoop ). Or you can create an HTML version for your website to serve crawlers.

The first method requires you to create a headless browser or tab for each page load). It takes a lot of time and system resources compared to generating HTML directly. Based on the framework you use, it will take a lot of work to decide when the prepared page will be rendered. You can cache pages, but if the pages change frequently, the optimization will not only be minimal, but also increase the complexity.

This will also reduce the loading speed of your page for several seconds, which is not good for the search engine ranking. PlantomJS requires Xvfb and WebKit)

The second method is to create a server-side site) which is effective for simple websites. However, if there are many pages, this method will be a nightmare.

If Google thinks that your server version site is very different from your main site version, it will severely punish you and you will not even know how to die.

2. unreliable statistics and monitoring

Many analysis tools need to be prone to errors. Manual integration is used to use HTML5 history APIpushState) for navigation. It is difficult for them to automatically detect that your application uses pushState to navigate to a new page. Even if they can, they still need to wait for the signal in your application to collect information on the new page.

How can this problem be solved? It depends on what navigation your client uses and what analysis tools you want to integrate. Using Google Analysis + Backbone. js? Try backbone. analytics. By the way, Heap is cool.) and UI-Router? Set your own $ stateChangeSuccess and call heap. track

It's not over yet! Do you want to track start page loading? Maybe you are tracking him in two ways? Will you track records of failed pages? What if you use replaceState instead of pushState? If you have configured the analysis hook incorrectly or the check causes the dependency upgrade to break down. After-sales services are discovered, it is difficult to restore the analysis data you missed or eliminate duplicate data)

3. slow and complex building tools

Front-end JavaScript build tools, such as Grunt, require complex configurations and are slow. Fortunately, we have a project like ng-boilerplate to help us with configuration, but if you want to add a custom step, you can't escape it, slow, and complicated. Why do I say Grunt is complicated, check the configuration file)

Once you have configured your application, you still have to endure a long JavaScript build time. You can separate dev and production build channels to improve the development speed, but it is always inevitable that this is the case, especially with AngularJS, it needs to use ngmin before ugly code if you use this function ). In fact, Sourcegraph has been destroyed several times because of these ugly JavaScript expressions.

Fortunately, Gulp has greatly improved.

4. Slow and unreliable Testing

Websites that test JavaScript-only require browser-based testing frameworks, such as Selenium, PhantomJS, or WebLoop. Installing these in addition to PhantomJS usually means installing WebKit and Java dependencies, configuring Xvfb (the new PhantomJS authority removes these prerequisites), or running a local VNC client and server for testing. Finally, you need to set all the things on the continuous integration server.

On the contrary, the pages generated by the test server usually only need the class library or URLs and parse HTML. The installation and configuration are much simpler.

Once you start writing a browser test, you must process asynchronous loading. You cannot test the elements on the page before the page is loaded. However, if the elements are not loaded at a specific time, your test will fail. The browser Test Library provides good functions to handle this situation. They can only use these functions on the load page.

If you want to use a heavyweight browser to perform Selenium, add Firefox or Webkit) very complicated tests because of the asynchronous nature of the browser )? Your testing requires a lot of configuration, which takes a long time to execute and is not reliable.

5. Slow, can be mitigated, but not solved

In rich JavaScript applications, page conversion occurs almost instantly, and all specific elements are loaded asynchronously. In server-side applications, the opposite is true: the page is not sent to the client before the server load is complete.

It sounds like the client-side application is successful, but it may be a pitfall.

When you click a link, the client-side application immediately loads and displays the page. If you use sidebar to navigate to a page that takes 5 seconds to load. The first time I felt very fast, but if a user needs information in sidebar, it would be quite uncomfortable for the user. Even if the specific content you need is displayed immediately, you still need to endure the jitter after loading the indicator and page filling.

Let's consider if developers want to add new features on that page. It is very difficult to make her functions have to be quickly loaded-because they are all asynchronous, who cares how many seconds it takes to load the bottom of the page? After so many times, the whole site may feel delayed and jitters.

In server-side applications, if an API is called slowly, the entire page will be stuck until it is completely completed. The server-side slow pace that cannot be ignored is easily measured and affects everyone fairly. However, in client-side applications, it is easy to ignore

You can say that a good development team should avoid these errors, and the client-side JS framework is not the culprit. Yes, the client-side JS framework improves the speed. This change encourages any development team

Next?

None of the above is a big problem. We have done a lot to alleviate the above situation.

All in all, the above thought that this client-side JS framework has increased the burden for our development.

Remember that each site is different. Sourcegraph is a content site. It won't change much after loading pages than rich JS applications.) We still love the western Zhejiang technology, but they are not necessarily the right tools to build the main site.

Http://blog.jobbole.com/61681/.