Live data from Hacker News

Ask HN: What happened to server-side rendering?

news.ycombinator.com

71–74 of 74 posts

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

#71
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 had that exact experience with Next. Ended up hating it for a variety of reasons (routing, file structure, build) and fortunately no longer have to support that project.

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.

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

#72
post #36
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.

I've started to play around with LiveView by migrating something from ajax to it [0] and it seems very nice! It's still in beta tho and a lot to do still... but very promising indeed :) [0] http://jypepin.com/elixir-phoenix-liveview-with-a-real-world...

It's quite impressive. Took me two hours to figure everything out, and just one hour to turn much of an existing 'old-fashioned' server-side rendered Phoenix app into a quite dynamic one where:

- 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.

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

#74
post #3

While not JavaScript, there's now Razor Components[1]. It doesn't work exactly like isomorphic JS, as it operates more like a terminal session (the server sends down VDOM mutations to the client). I'm not entirely sold on the approach yet, but I am going to be keeping an eye on it. [1]: https://docs.microsoft.com/en-us/aspnet/core/razor-component...

I wonder what took so long for DOM-deltas-over-websockets tech to show up. It was only in the last two years or so for stuff like Plotly's Dash and Elixir Phoenix's LiveView to become popular even though we had Websockets and event driven networking for ages.

If I understand correctly, Chris McCord actually did something similar back in his Rails days (https://github.com/chrismccord/render_sync), but the issues he ran into actually led him to create both Phoenix and, eventually, LiveView.

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.

Post reply on HN