What is isomorphism for?
On Habré there are several articles about isomorphism, which answer the question what isomorphism is: “Isomorphism is when the same code is used both on the client and on the server”. Yes, it is, but it is not entirely clear why it is needed at all. Actually on this basis this article was born.
The client side frameworks are great. They can help you build an interactive and fast web application that users will adore.
Unfortunately, this world is not perfect, and they have several drawbacks. One of the main ones is the initial download speed.
')
Client frameworks get a very small HTML file that includes styles and a pair of script files containing a single div for mounting the application. However, a JavaScript file (bundle) containing even minified code is often very large and can reach several megabytes.
The browser must request these files and the page will not be shown to the user until both of them are delivered. You may still need a request to api to get initial data for the application itself.
On the other hand, traditional web sites render everything on the server and, as soon as the HTML is delivered to the client machine, the user sees the page. Moreover, most web servers can render a page faster than a user's machine. As a result of all this, the initial loading of the page is very fast.
Of course, you would like to have the advantages of both approaches. Fast boot and fast and interactive application.
React can help with this.
Here is how it works. React has the ability to render any component, including its data on the server side. That is, server-side React collects the component tree and turns it into an HTML framework. All this we put in the index.html, which is sent to the user. This file also stores the application data for rendering on the client.
As soon as the HTML is delivered to the user, the browser displays the page. At this time, the “heavy” JavaScript file will still be loaded behind the scenes and, as soon as it loads, React will do the same calculations for the render locally. The smart React algorithm understands that the result of the local render matches what was already displayed on the page. As a result of this comparison, React will not make any changes, but simply add the necessary event handlers to the elements.
In this case, the HTML file, of course, becomes a bit “harder”, but it just doesn’t compare with the size of the file containing JavaScript. As a result, the HTML file is delivered very quickly.
How fast is it? Are we doing almost the same thing in two places? Yes, but almost here is the key word.
First, as soon as the server responds to the browser request, the user will immediately see the page.
Secondly, React identifies that changes to the DOM are unnecessary, and therefore does not touch it, and this is the slowest part of the rendering.
And in addition, we save one request, since the data have already taken part in rendering on the server and we do not need to request them again.
Is it possible that while the JavaScript is loaded and the page is already displayed, the user will not be able to interact with it, because event handlers are not yet attached to the page?
Theoretically, it is possible, moreover - it is. However, with the help of this technique we avoid all expensive operations (requests) and, as a result, not only the initial download speed grows, but also the attachment of event handlers happens very quickly.
Ultimately, your application will always be interactive and none of your users will encounter problems, the page load time will be extremely small, and users will be infinitely happy!
The client side frameworks are great. They can help you build an interactive and fast web application that users will adore.
Unfortunately, this world is not perfect, and they have several drawbacks. One of the main ones is the initial download speed.
')
Client frameworks get a very small HTML file that includes styles and a pair of script files containing a single div for mounting the application. However, a JavaScript file (bundle) containing even minified code is often very large and can reach several megabytes.
The browser must request these files and the page will not be shown to the user until both of them are delivered. You may still need a request to api to get initial data for the application itself.
On the other hand, traditional web sites render everything on the server and, as soon as the HTML is delivered to the client machine, the user sees the page. Moreover, most web servers can render a page faster than a user's machine. As a result of all this, the initial loading of the page is very fast.
Saving React
Of course, you would like to have the advantages of both approaches. Fast boot and fast and interactive application.
React can help with this.
Here is how it works. React has the ability to render any component, including its data on the server side. That is, server-side React collects the component tree and turns it into an HTML framework. All this we put in the index.html, which is sent to the user. This file also stores the application data for rendering on the client.
As soon as the HTML is delivered to the user, the browser displays the page. At this time, the “heavy” JavaScript file will still be loaded behind the scenes and, as soon as it loads, React will do the same calculations for the render locally. The smart React algorithm understands that the result of the local render matches what was already displayed on the page. As a result of this comparison, React will not make any changes, but simply add the necessary event handlers to the elements.
In this case, the HTML file, of course, becomes a bit “harder”, but it just doesn’t compare with the size of the file containing JavaScript. As a result, the HTML file is delivered very quickly.
How fast is it? Are we doing almost the same thing in two places? Yes, but almost here is the key word.
First, as soon as the server responds to the browser request, the user will immediately see the page.
Secondly, React identifies that changes to the DOM are unnecessary, and therefore does not touch it, and this is the slowest part of the rendering.
And in addition, we save one request, since the data have already taken part in rendering on the server and we do not need to request them again.
- Begin loading page.
- HTML file loaded, start loading styles and js.
- The styles are loaded and the user already sees a beautiful page, while the JS file continues to load behind the scenes (the page is lifeless).
- The JS file is loaded and the reactant starts rendering and comparing the virtual DOM with the displayed one.
- React understands that there are no differences and simply connects event handlers to the already existing markup. The user has access to a full page.
Is it possible that while the JavaScript is loaded and the page is already displayed, the user will not be able to interact with it, because event handlers are not yet attached to the page?
Theoretically, it is possible, moreover - it is. However, with the help of this technique we avoid all expensive operations (requests) and, as a result, not only the initial download speed grows, but also the attachment of event handlers happens very quickly.
Ultimately, your application will always be interactive and none of your users will encounter problems, the page load time will be extremely small, and users will be infinitely happy!
Source: https://habr.com/ru/post/301146/
All Articles