Live data from Hacker News

Ask HN: What happened to server-side rendering?

news.ycombinator.com

61–70 of 74 posts

Re: Ask HN: What happened to server-side rendering?

#61
> There was a lot of talk about Isomorphic rendering of JavaScript, but seems to have died down recently.

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.

Re: Ask HN: What happened to server-side rendering?

#62
post #25

Phoenix.LiveView — you can't ignore it, the coolest thing happening right now about server-side rendering. 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.

Calling it isomorphic might be a disgrace for mathematics, but in terms of the Greek meaning of single form, it’s accurate.

I speak Greek natively, isomorphic literally translates into "same form"

Re: Ask HN: What happened to server-side rendering?

#63
post #47
post #31

Earlier quoted context omitted.

A big one for the need of server side rendering is SEO. Without server side rendering, most web crawlers don't have access to your content and you can't rank for SEO.

SSR for the purposes of SEO can be achieved in a simpler way, without complicating your whole app to support SSR. Just pre-render the page in headless chromium / puppeteer when a search engine bot requests it and return the resulting html.

really not sure having a separate way to render your page just for crawlers, using a different rendering engine is "simpler" than having SSR.

Re: Ask HN: What happened to server-side rendering?

#64
post #63
post #47

Earlier quoted context omitted.

SSR for the purposes of SEO can be achieved in a simpler way, without complicating your whole app to support SSR. Just pre-render the page in headless chromium / puppeteer when a search engine bot requests it and return the resulting html.

really not sure having a separate way to render your page just for crawlers, using a different rendering engine is "simpler" than having SSR.

SSR is only easy if your frontend is written exclusively in SSR-compatible libraries and your backend is node.js, and even then you need to adjust your frontend code for SSR because node.js doesn't have all the browser APIs that your code could be using (like XHR or the real (not virtual) DOM).

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.

Re: Ask HN: What happened to server-side rendering?

#65
I can integrate js in a viewengine in asp.net MVC for reuse of HTML components ( yes, server side rendering based on the v8 js engine)

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

Re: Ask HN: What happened to server-side rendering?

#66
post #39
post #25

Phoenix.LiveView — you can't ignore it, the coolest thing happening right now about server-side rendering. 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.

also, from a selfish programmer standpoint, programming in elixir is really such a joy.

I've just recently gotten into elixir, and it really is the first time in a long time I've wanted to just "do things" just for the sake of doing them with a language.

Re: Ask HN: What happened to server-side rendering?

#67

Earlier quoted context omitted.

I'm evaluating next.js for a new project. But coming from create-react-app, I'm a bit skeptical of these "frameworks" that seem to provide little benefit beyond developer tooling (i.e. setting up webpack, hot reload etc). create-react-app was great in the beginning, but months later was really annoying. I get the feeling next.js could end up like that. At least you can eject from CRA. I'm curious if anyone has gone t…

The spectrum chat team, which GitHub acquired, wrote that they wish they had started with next.js https://mxstbr.com/thoughts/tech-choice-regrets-at-spectrum/

That's my blog post! If you have any questions let me know.

Re: Ask HN: What happened to server-side rendering?

#68
post #12

Earlier quoted context omitted.

Agreed. I'm a big fan of Next.js and haven't had any major problems with it. While there have been some quirks and nuances I had to learn[0] it still provides the easiest platform for SSR out of the box. [0]: https://leerob.io/blog/things-ive-learned-building-nextjs-ap...

I'm evaluating next.js for a new project. But coming from create-react-app, I'm a bit skeptical of these "frameworks" that seem to provide little benefit beyond developer tooling (i.e. setting up webpack, hot reload etc). create-react-app was great in the beginning, but months later was really annoying. I get the feeling next.js could end up like that. At least you can eject from CRA. I'm curious if anyone has gone t…

I'd highly recommend trying out Next.js. Once you've got the framework-specific concepts, it's quite refreshing to base an app on. There are plenty of "escape hatches" to customize webpack, babel, server-side API, etc.

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.

Re: Ask HN: What happened to server-side rendering?

#70
post #47
post #31

Earlier quoted context omitted.

A big one for the need of server side rendering is SEO. Without server side rendering, most web crawlers don't have access to your content and you can't rank for SEO.

SSR for the purposes of SEO can be achieved in a simpler way, without complicating your whole app to support SSR. Just pre-render the page in headless chromium / puppeteer when a search engine bot requests it and return the resulting html.

I pre-render my pages with puppeteer on build, and then hydrate with the js bundles. Everyone gets the faster experience of an HTML page (not just crawlers), while the full js loads async.

Example in my profile.

Post reply on HN