Ask HN: What happened to server-side rendering? A few years ago, there was a lot of talk about Isomorphic rendering of JavaScript, but seems to have died down recently. Are any products still using it? What happened? |
Ask HN: What happened to server-side rendering? A few years ago, there was a lot of talk about Isomorphic rendering of JavaScript, but seems to have died down recently. Are any products still using it? What happened? |
Demo: https://youtu.be/Z2DU0qLfPIY?t=2628
Links: https://leveljournal.com/why-phoenix-liveview-is-a-big-deal https://elixirforum.com/t/phoenix-liveview-info/16569
PS please stop calling it isomorphic — this is disgrace for the mathematics.
[0] http://jypepin.com/elixir-phoenix-liveview-with-a-real-world...
- various page elements update when the server/db does (new users, new items, etc.) - sorting tables works dynamically - table cells are updated on click (toggle-type stuff)
What made this so easy to do is that all I had to do was:
- move chunks of controller logic to the LiveView mount() function. - add a phx-click and phx-value attribute to my existing templates (and rename them from .eex to .leex) - add click handlers to the LiveView modules - use the built-in PubSub functionality in my DB logic and subscribe from the LiveViews
Obviously there are legitimate reasons why LiveView isn't good enough, but this is an incredibly simple solution provided you 1) are willing to use Phoenix, 2) can assume your clients have internet and you don't need offline capabilities
I've honestly worked on very few SPA projects where I can't see LiveView being a good option.
So you have two buckets: web apps that don't care too much about shaving milliseconds from the initial load, and content sites that shouldn't be shipping heavy JavaScript in the first place. The target market for hybrid rendering is the tiny slice of sites in-between those two, so it's a minority of use-cases. Though it is also used by sites in the latter category that are shipping heavy JavaScript anyway and having regrets.
That said, user experience (in this case site speed) can be a factor in how Google actually ranks pages, so that could be another motivation.
Just pre-render the page in headless chromium / puppeteer when a search engine bot requests it and return the resulting html.
Many large sites like Marvel.com, Nike.com, Invisionapp.com, hulu.com and many more run on server-side rendered React, see the Next.js showcase for a more complete list: https://nextjs.org/showcase
[0]: https://leerob.io/blog/things-ive-learned-building-nextjs-ap...
I'm curious if anyone has gone the "roll your own" route with SSR + react, starting with a simple approach and adding complexity only as it becomes necessary. Has anyone done this and maybe also used next.js? I would love to hear a comparison, because at the moment I'm unconvinced next.js is really necessary if you know what you're doing, or you intend to maintain the project for more than 2 years.
https://github.com/zeit/next.js/
It gives you SSR with React out of the box. It's really nice to work with, and flexible enough that we haven't had issues with more customized situations.
[1]: https://docs.microsoft.com/en-us/aspnet/core/razor-component...
I'm sure others are better at explaining the details, but from what I gather this approach is now more viable than it was in the past with other stacks because 1) Phoenix is really efficient and fast with rendering templates, 2) The Erlang/Elixir-specific channels/process approach makes it much easier to have tons of websocket connections open and maintaining state, and perhaps 3) javascript got a lot faster.
https://vuejs.org/v2/guide/ssr.html
Great for FB/twitter share scraping, google scraping, etc. Also much better startup speeds.
Once you get it configured it's very little additional work to maintain.
I have it set up to do things like determine mobile/desktop depending on the `user-agent` to determine the prerendered page to serve, and then the client side JS takes over depending on the viewport size and will either a) Rebuild (less than 1% of the time) changing the markup from desktop->mobile of mobile->desktop or b) Continue happily
Google scraping? How/why can it be used for google scraping? Doesn't google return html result pages?
I also happen to make the Elixir Foundation series of videos[2] that show how to do serverside rendering using elixir. So I’m dog fooding the dog food.
edit: This actually has examples https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...
Of course they are. Lots.
The New York Times. The Intercept. AirBnB. Just off the top of my head.
1) Lack of reliable real time ability to detect device and compute size. 2) Increased computation complexity of what to render - why put that load on the server when devices are now commensurately as fast - or even faster given the trend to distributed services that maximize network throughput over power.
I'm not even sure why it was so popular in the first place; client server separation is a good thing, IMHO.
[1] https://developers.google.com/search/docs/guides/rendering
It's no way near dead, just look at nuxtjs/nextjs/Gatsby. they are getting more popular day by day. Recently I worked on an E-commerce platform using next.js and Gatsby.
I have to say its really cool and good user experience overall. the only issue I had was the complexity of the code. You have to think about backend/frontend at the same time. I will definitely use it where it makes sense.
https://webmasters.googleblog.com/2014/05/understanding-web-...
So maybe that took the wind out of the sails.
I was one who jumped in, then tried to automate my way out of client-side slow renders with https://www.roast.io/ (uses a headless browser to server-side render a JS app)
I also use razor though, but this is a neat workaround instead of using a headless browser.
The right mix of using scaffolders in. Net ( server side) and client side components can decrease development time exponentially
2) What is your motivation? What problem do you think you are solving with server-side rendering?
I also had to read the comment twice to understand it.
If you want to be pedantic about it, sure.
If I wanted to trolled by framework children I would go back to reddit.
That said, I don't use it much anymore - I rolled (and continue to use) my own SSR, adding features as I needed them: taking care of async server-side actions like fetching data; rendering the app; passing initial state to client; dynamic chunk-splitting of routes; a way to export all app routes to static files..
There are many moving parts and "tricks" I had to discover - like, how to bundle client/server bundles with webpack (chunk-split on client, all bundled together on server), creating script tags on server to fetch route-specific chunks faster on initial page load..
So, unless you're into understanding and building/customizing every feature, your time might be better spent letting Next.js provide all that as a foundation. It's well-organized and documented, so I think it would be valuable for teams working together also.
Now I roll my own. I pre-render with react-snap, use react-imported-component for code-splitting and hydration. The pre-rendered static HTML pages are everybit as good as SSR. It adds an extra few seconds to the build process, but with Netlify's CI, I push to Github and its live once I'm back from the kitchen.
Knowing a bit about SEO, if you want to invest in your ranking, I wouldn't go without server-side rendering.
I would certainly consider this ahead of SSR driven by "isomorphic" Javascript for frontend-heavy apps.
Example in my profile.
On the other hand, puppeteer executes your application in virtually the same environment as the user's browser, without polluting your frontend architecture with SSR concepts and limitations.
Yes, you'll need to set up a bit of infra initially. Depending on the use case it may very well pay off.