F
F
fetis262014-12-13 14:33:35
JavaScript
fetis26, 2014-12-13 14:33:35

How widely can render be applied on the client now?

I can't draw a line. Modern frameworks provide ample opportunities for client rendering. It seems like you can remove the whole thing from the server or greatly minimize it.
But it is embarrassing that the search engines will not see anything. Yes, and the user seems to be not comfortable, opened the page and there is nothing until the scripts have worked. If we write some kind of closed system, then such questions seem to be irrelevant. What if we make a public site? Or something like a personal account, for such a site.
How do you decide where you can render on the client, where you can’t. And what exactly do you output.

Answer the question

In order to leave comments, you need to log in

8 answer(s)
S
Sergey, 2014-12-13
Protko @Fesor

The ideal situation is client and server are different applications. This means that we have partially duplicated logic, etc. etc. Also, the implementation of the client becomes more complicated and the implementation of the server is simplified to a simple rest api.
As for the edge - you expose it. Just estimate in time how much time it will take for you to take a project with a classic approach and on the same AngularJS. For example, to write a blog, an ordinary blog. In fact, there is no logic here. The server can simply cache and serve HTML. It makes no sense to make dynamic transitions since 95% of the page will be replaced anyway, and this does not happen often.
As for the search engines, this also adds to the hassle. either connect services like prerender.io or implement something similar based on phantom.js
I personally do only web applications on Angular. There it is not necessary to take a steam bath strongly with indexing. In most cases, I don’t see the point in making sites on it, it’s easier to make dynamic only individual elements that actually require it.

S
smanioso, 2014-12-13
@smanioso

From a UX point of view, you just need to optimize the loading speed, caching and other aspects of the site / application.
In terms of SEO, there are a lot of ready-made solutions, for example https://prerender.io

N
Nikita Gushchin, 2014-12-13
@iNikNik

If you write in angular, then rendering something on the server in most cases does not make sense.
As for SEO - I myself was interested some time ago, take a look here: Site indexing when using AngularJS
So now there are no special problems with the SEO of such applications.

M
Marat Amerov, 2014-12-14
@amerov

Now you can render on both sides with React.
https://github.com/enaqx/awesome-react#server-side...
https://www.youtube.com/watch?v=cKYGPGlUfc4

I
Ilya Agarkov, 2015-01-31
@ElianL

Now the idea of ​​isomorphic applications is being actively promoted, when the first page is rendered on the server, and the subsequent ones on the client.
There are two approaches here, either use the so-called full-stack frameworks (on nodejs), like derbyjs or meteor. Very interesting tools, but tied to mongo. With this approach, both the server and the client are written in JS.
The second approach is that we have a server with which we work via API (write on whatever you want), and the frontend has, let's say, a layer on nodejs.
With the advent of ReactJS, rendering the same page on the server and on the client has become very simple.
Already now there are experimental tools for example from Ebay https://github.com/appsforartists/ambidex
I think we will soon be covered by a wave of similar decisions. And then such questions will disappear by themselves =)

D
Dmitry Polushkin, 2015-02-12
@dmitry-polushkin

The best way is to use true isomorphic architecture. Render on the server, then sync via virtual dom on the client. In this way, several problems are solved at once ... and even more than a few. At a minimum:
- Fast page loading for the client
- Fast page loading for search engines
- Code sharing between client and server
- With React.js, it also speeds up development, because testing takes less time, and there are much fewer side effects than when using bindings.
Based on my own experience. With react.js, everything works much faster, more transparent and more modifiable.

P
Pavel Demyanenko, 2015-01-08
@xeLL

Ember.js will have native ability to render on the server emberjs.com/blog/2014/12/22/inside-fastboot-the-ro... .

L
lega, 2015-01-10
@lega

Divide projects into sites and web applications (with the latter, I think everything is clear - one page, everything is in it).

But it is embarrassing that the search engines will not see anything. Yes, and the user seems to be not comfortable, opened the page and there is nothing until the scripts have worked.
I think that there are no particular problems with search engines (phntomjs / prerenderio), but the download speed is essential, so I think that the main content should arrive immediately from the server so that the user can already read, and additional. functionality, all sorts of forms, buttons, other goodies already through client frameworks. For example, VK, most of it arrives immediately, and the rest is search, loading already through js (although the posts being loaded were rendered on the server).

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question