I just want to give an alternate solution that solves almost all SPA issues, but with a lot less hustle: services (self hosted or 3rd party) for cache, similar with Prerender.io
There is no need to complicate your code, use a specific language, framework or server like nodeJS and is very lose coupled.
It acts like a buffer between your server and internet, when a bot comes it will be served a cached static version of the page.
Yes, but you trick the reader because there is no performance gain or lose, if you invest a lot of resources in servers maybe you can achieve a faster first page render, if all goes well, but if the user is browsing a 2nd page the SSR will be slower overall.
And also you mentioned only the cons of prerender, actually is a better solution, less code to maintain, less server resources consumtion than a SSR solution and a faster response time because is only a cache, so you will have more performance.
I think there's some confusion here. I am not advocating only using SSR like a traditional monolithic app.
I am, however, advocating having a SPA experience that is also utilizing SSR. The initial render is from the server, and then the client side JavaScript takes over to provide a SPA experience. This means that web crawlers are able to view content on that initial render of any page.
This is probably my fault in not making that clear in the article, so I will probably add that to the "Universal JavaScript" section.
I just want to give an alternate solution that solves almost all SPA issues, but with a lot less hustle: services (self hosted or 3rd party) for cache, similar with Prerender.io
There is no need to complicate your code, use a specific language, framework or server like nodeJS and is very lose coupled.
It acts like a buffer between your server and internet, when a bot comes it will be served a cached static version of the page.
Thanks for sharing Adrian! I mentioned Prerender.io at the end of the article. It's definitely an option to consider.
Yes, but you trick the reader because there is no performance gain or lose, if you invest a lot of resources in servers maybe you can achieve a faster first page render, if all goes well, but if the user is browsing a 2nd page the SSR will be slower overall.
And also you mentioned only the cons of prerender, actually is a better solution, less code to maintain, less server resources consumtion than a SSR solution and a faster response time because is only a cache, so you will have more performance.
Hopefully this clears things up:
I think there's some confusion here. I am not advocating only using SSR like a traditional monolithic app.
I am, however, advocating having a SPA experience that is also utilizing SSR. The initial render is from the server, and then the client side JavaScript takes over to provide a SPA experience. This means that web crawlers are able to view content on that initial render of any page.
This is probably my fault in not making that clear in the article, so I will probably add that to the "Universal JavaScript" section.
Rendora github.com/rendora/rendora exactly does what you need and it's FOSS