New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Server-side rendering #23

Open
slimsag opened this Issue Feb 13, 2016 · 17 comments

Comments

Projects
None yet
4 participants
@slimsag
Member

slimsag commented Feb 13, 2016

Useful for two reasons:

  1. Needed for quicker page loads (other option is code splitting).
  2. Needed for compatability with web scrapers such as search engines etc.
@dmitshur

This comment has been minimized.

Show comment
Hide comment
@dmitshur

dmitshur Feb 13, 2016

Member

I've suggested this idea to @neelance too, and we discussed it. @neelance told me it's a nice to have that is more long term, because it requires quite a bit if work that is completely separate from everything else.

This is primarily because of the difference between properties (what this package currently deals with at runtime) and attributes (what needs to be specified in static HTML).

Have you already had that conversation too @slimsag, or is the above info new to you?

Member

dmitshur commented Feb 13, 2016

I've suggested this idea to @neelance too, and we discussed it. @neelance told me it's a nice to have that is more long term, because it requires quite a bit if work that is completely separate from everything else.

This is primarily because of the difference between properties (what this package currently deals with at runtime) and attributes (what needs to be specified in static HTML).

Have you already had that conversation too @slimsag, or is the above info new to you?

@slimsag

This comment has been minimized.

Show comment
Hide comment
@slimsag

slimsag Feb 13, 2016

Member

Yes, I've had a pretty similiar conversation.

I'm not 100% convinced that it should be put off until later (there might be unforeseen issues), but I do agree it's not the highest priority.

Member

slimsag commented Feb 13, 2016

Yes, I've had a pretty similiar conversation.

I'm not 100% convinced that it should be put off until later (there might be unforeseen issues), but I do agree it's not the highest priority.

@influx6

This comment has been minimized.

Show comment
Hide comment
@influx6

influx6 Feb 15, 2016

What would the current approach look like, will there be a backend DOM library to provide the similar features that the HTML Dom library requires or will a headless rendering engine be used to get the rendered page and serve + cache also

influx6 commented Feb 15, 2016

What would the current approach look like, will there be a backend DOM library to provide the similar features that the HTML Dom library requires or will a headless rendering engine be used to get the rendered page and serve + cache also

@slimsag

This comment has been minimized.

Show comment
Hide comment
@slimsag

slimsag Feb 21, 2016

Member

@influx6 I don't know exactly what the approach would look like. Using a headless rendering engine would not make sense at all, though. We would want to generate an HTML page from components and then reconcile those properly client-side in JS when the page loads attaching event listeners etc.

Member

slimsag commented Feb 21, 2016

@influx6 I don't know exactly what the approach would look like. Using a headless rendering engine would not make sense at all, though. We would want to generate an HTML page from components and then reconcile those properly client-side in JS when the page loads attaching event listeners etc.

@influx6

This comment has been minimized.

Show comment
Hide comment
@influx6

influx6 commented Feb 21, 2016

I see @slimsag

@influx6

This comment has been minimized.

Show comment
Hide comment
@influx6

influx6 Feb 25, 2016

When thinking about this feature, the key is to have some kind of marker for the markup being generated that allows markup generators on the client to identify their markup counterparts from the server, this will allow you to either do a initial re-rendering on the client thereby letting the client side take over or continue to use those until a update forces a re-render, but I prefer the former,because each markup rendering take ownership and binds the necessary event handlers, the only problem is having a identification system that persists from server to client and over multiple runtime execution.

These is majorly the problems I faced when I tackled this issue.
Hope this information helps, am not so sure yet how we should bring this feature into Vecty

influx6 commented Feb 25, 2016

When thinking about this feature, the key is to have some kind of marker for the markup being generated that allows markup generators on the client to identify their markup counterparts from the server, this will allow you to either do a initial re-rendering on the client thereby letting the client side take over or continue to use those until a update forces a re-render, but I prefer the former,because each markup rendering take ownership and binds the necessary event handlers, the only problem is having a identification system that persists from server to client and over multiple runtime execution.

These is majorly the problems I faced when I tackled this issue.
Hope this information helps, am not so sure yet how we should bring this feature into Vecty

@slimsag

This comment has been minimized.

Show comment
Hide comment
@slimsag

slimsag Apr 12, 2016

Member

IIRC React made some changes recently such that they do not need the react-id's anymore. Should look into their new impl and see how exactly it works if it doesn't use the react-ids, I bet their experience could point us in the right direction

EDIT: I was wrong! They still use react-id's for server-side-rendered components.

Member

slimsag commented Apr 12, 2016

IIRC React made some changes recently such that they do not need the react-id's anymore. Should look into their new impl and see how exactly it works if it doesn't use the react-ids, I bet their experience could point us in the right direction

EDIT: I was wrong! They still use react-id's for server-side-rendered components.

@slimsag

This comment has been minimized.

Show comment
Hide comment
@slimsag

slimsag Apr 12, 2016

Member

Found it -> @bep mentioned it in another issue #20 (comment)

Member

slimsag commented Apr 12, 2016

Found it -> @bep mentioned it in another issue #20 (comment)

@influx6

This comment has been minimized.

Show comment
Hide comment
@influx6

influx6 Apr 28, 2016

Also, Luna notified me some months back that web scrappers, mainly all major search engines, run your JS first before crawling the pages, so let this focus on code splitting as this is not really anymore an issue.

influx6 commented Apr 28, 2016

Also, Luna notified me some months back that web scrappers, mainly all major search engines, run your JS first before crawling the pages, so let this focus on code splitting as this is not really anymore an issue.

@slimsag

This comment has been minimized.

Show comment
Hide comment
@slimsag

slimsag Nov 12, 2016

Member

From http://stackoverflow.com/a/1785101/5905344

JavaScript is handled by both Bing and Google crawlers. Yahoo uses the Bing crawler data, so it should be handled as well. I didn't look into other search engines, so if you care about them, you should look them up.

The complexity we would gain from this may not be worth it. It might be easier to suggest that users create static versions of their website with e.g. html/template should they want both.

Member

slimsag commented Nov 12, 2016

From http://stackoverflow.com/a/1785101/5905344

JavaScript is handled by both Bing and Google crawlers. Yahoo uses the Bing crawler data, so it should be handled as well. I didn't look into other search engines, so if you care about them, you should look them up.

The complexity we would gain from this may not be worth it. It might be easier to suggest that users create static versions of their website with e.g. html/template should they want both.

@slimsag

This comment has been minimized.

Show comment
Hide comment
@slimsag

slimsag Nov 12, 2016

Member

I'm marking this as I currently see it. Discussion welcome.

Member

slimsag commented Nov 12, 2016

I'm marking this as I currently see it. Discussion welcome.

@slimsag slimsag added the wontfix label Nov 12, 2016

@influx6

This comment has been minimized.

Show comment
Hide comment
@influx6

influx6 Nov 13, 2016

It's possible, Just just have to be willing to disconnect your
implementation from the core browser DOM

On Nov 13, 2016 00:35, "Stephen Gutekanst" notifications@github.com wrote:

I'm marking this as I currently see it. Discussion welcome.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#23 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAICLVX34ZcW5Dsj4WNOYpuJ8lq30o53ks5q9k04gaJpZM4HZkR3
.

influx6 commented Nov 13, 2016

It's possible, Just just have to be willing to disconnect your
implementation from the core browser DOM

On Nov 13, 2016 00:35, "Stephen Gutekanst" notifications@github.com wrote:

I'm marking this as I currently see it. Discussion welcome.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#23 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAICLVX34ZcW5Dsj4WNOYpuJ8lq30o53ks5q9k04gaJpZM4HZkR3
.

@slimsag

This comment has been minimized.

Show comment
Hide comment
@slimsag

slimsag Jan 4, 2017

Member

I see no reason to keep this issue around, except maybe in a FAQ of sorts. Let's close and anyone who has new ideas / thoughts around this can create a new issue or chat in #vecty on Gophers slack :)

Member

slimsag commented Jan 4, 2017

I see no reason to keep this issue around, except maybe in a FAQ of sorts. Let's close and anyone who has new ideas / thoughts around this can create a new issue or chat in #vecty on Gophers slack :)

@slimsag slimsag closed this Jan 4, 2017

@slimsag

This comment has been minimized.

Show comment
Hide comment
@slimsag

slimsag Oct 8, 2017

Member

Back when I closed this issue, I closed it mostly on the grounds that:

  1. More and more search engines are beginning to execute JavaScript, and as such server-side rendering matters less and less in terms of SEO.
  2. Getting server-side rendering in a Vecty application working will likely be harder than just using html/template and serving an SEO-friendly version of your data.

But I quickly after closing this issue realized that the above does not cover the other primary use case of server side rendering: initial page load time.

A JavaScript bundle (especially GopherJS bundles) are quite a bit larger than a server-side-rendered HTML page. This transfer + render time can add 1s or more to page load times, which isn't great.

I think to be competitive we may have to offer a solution to this eventually, but it's not exactly clear what it would look like today.

Member

slimsag commented Oct 8, 2017

Back when I closed this issue, I closed it mostly on the grounds that:

  1. More and more search engines are beginning to execute JavaScript, and as such server-side rendering matters less and less in terms of SEO.
  2. Getting server-side rendering in a Vecty application working will likely be harder than just using html/template and serving an SEO-friendly version of your data.

But I quickly after closing this issue realized that the above does not cover the other primary use case of server side rendering: initial page load time.

A JavaScript bundle (especially GopherJS bundles) are quite a bit larger than a server-side-rendered HTML page. This transfer + render time can add 1s or more to page load times, which isn't great.

I think to be competitive we may have to offer a solution to this eventually, but it's not exactly clear what it would look like today.

@slimsag slimsag reopened this Oct 8, 2017

@slimsag slimsag removed the wontfix label Oct 8, 2017

@slimsag slimsag added this to the Long Term milestone Oct 8, 2017

@dmitshur

This comment has been minimized.

Show comment
Hide comment
@dmitshur

dmitshur Oct 10, 2017

Member

Another important (IMO) benefit of server-side rendering is that it enables a gradual transition path for developers. If vecty rendering API allows for server-side rendering, then users can:

  1. Start with rendering HTML on server as they currently do, e.g., via html/template.
  2. Rewrite parts of their HTML rendering to use Vecty rendering API.
  3. After having a good experience and becoming more familiar with it, finish rewriting all their HTML rendering to use Vecty API, while maintaining existing behavior.
  4. Easily switch to or add frontend rendering, while reusing Vecty rendering code.

Without server-side rendering, users must:

  1. Start with rendering HTML on server as they currently do, e.g., via html/template.
  2. Rewrite their entire application to use Vecty API and move rendering to frontend. All in one huge step, and hope functionality doesn't break, and not able to see and evaluate partial results until a lot of work is done.

Of course, this assumes a server-side HTML rendering starting point. If users start with frontend rendering, e.g., via React, then this isn't applicable.

Member

dmitshur commented Oct 10, 2017

Another important (IMO) benefit of server-side rendering is that it enables a gradual transition path for developers. If vecty rendering API allows for server-side rendering, then users can:

  1. Start with rendering HTML on server as they currently do, e.g., via html/template.
  2. Rewrite parts of their HTML rendering to use Vecty rendering API.
  3. After having a good experience and becoming more familiar with it, finish rewriting all their HTML rendering to use Vecty API, while maintaining existing behavior.
  4. Easily switch to or add frontend rendering, while reusing Vecty rendering code.

Without server-side rendering, users must:

  1. Start with rendering HTML on server as they currently do, e.g., via html/template.
  2. Rewrite their entire application to use Vecty API and move rendering to frontend. All in one huge step, and hope functionality doesn't break, and not able to see and evaluate partial results until a lot of work is done.

Of course, this assumes a server-side HTML rendering starting point. If users start with frontend rendering, e.g., via React, then this isn't applicable.

@slimsag

This comment has been minimized.

Show comment
Hide comment
@slimsag

slimsag Dec 4, 2017

Member

Other things to consider here:

  1. With WebAssembly support eventually coming to Go, bundle sizes may be less of a problem (but probably still enough of a problem to warrant trying some server-side rendering).
  2. If we have to offer a solution for this, it will probably require some API changes or else we will end up with some duplicated / ugly methods in the Vecty API. So I'm tagging as 1.0 just to figure out what APIs would need to be in place before supporting this.
Member

slimsag commented Dec 4, 2017

Other things to consider here:

  1. With WebAssembly support eventually coming to Go, bundle sizes may be less of a problem (but probably still enough of a problem to warrant trying some server-side rendering).
  2. If we have to offer a solution for this, it will probably require some API changes or else we will end up with some duplicated / ugly methods in the Vecty API. So I'm tagging as 1.0 just to figure out what APIs would need to be in place before supporting this.
@glycerine

This comment has been minimized.

Show comment
Hide comment
@glycerine

glycerine Dec 29, 2017

you've probably seen https://github.com/olebedev/go-starter-kit/ which does react/server side rendering using goja. Might provide some inspiration/go code to borrow (MIT licensed).

glycerine commented Dec 29, 2017

you've probably seen https://github.com/olebedev/go-starter-kit/ which does react/server side rendering using goja. Might provide some inspiration/go code to borrow (MIT licensed).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment