Live data from Hacker News

Server-Side Only React with Next

webcloud.se

41–50 of 75 posts

Re: Server-Side Only React with Next

#41

Step 1: Server Side HTML -> Website needs to be more interactive. Step 2: Server Side HTML + Client Side React SPA -> Website is now interactive but performance decreased. Step 3: Server Side HTML + Server Side React + Client Side React SPA -> Website is interactive, performance is good but now it's overly complex. Step 4: Server Side HTML + Server Side React -> Let's make it a bit more simple and even more performan…

The scaling characteristics of a client side and server side rendered app is different. Client side apps have up front costs which are amortized as the view can be incrementally updated. Whether this is more performant depends on the metric and the problem domain.

Particularly static pages with minimal interactivity can be prerendered and cached at the CDN, but that’s not necessarily the same as an on demand server side rendered page, either.

Re: Server-Side Only React with Next

#42
I did something similar with Nuxt.js when building my résumé site: https://resume.nathanfriend.io/

I used a more heavy-handed approach: I strip out all elements from the build output before publishing: https://gitlab.com/nfriend/nuxt-resume/-/blob/63e0298fdb5a08...

The end result is a pure HTML/CSS site that has all the Nuxt.js niceties during development (e.g. hot reloading).

Re: Server-Side Only React with Next

#43
post #23

> In the past I've also tried Jekyll and Hugo. I found that both work great out of the box, but were hard to customize as I'm not very fluent in either Ruby or Go. Why do people not know about Eleventy, why?

I came here to say this - Eleventy is so simple!

Re: Server-Side Only React with Next

#44

Step 1: Server Side HTML -> Website needs to be more interactive. Step 2: Server Side HTML + Client Side React SPA -> Website is now interactive but performance decreased. Step 3: Server Side HTML + Server Side React + Client Side React SPA -> Website is interactive, performance is good but now it's overly complex. Step 4: Server Side HTML + Server Side React -> Let's make it a bit more simple and even more performan…

I don't think any of these changes have made the pages less interactive. What the move back to server has generally done is remove all the unnecessarily deferred layout. The worst performance offenders remain advertising and tracking.

Re: Server-Side Only React with Next

#45
post #27

Earlier quoted context omitted.

Yes, and it's nonsense. "I needed something to convert markdown to html", "I like the component mental model", "I wanted to use Node libraries for date formatting etc.", "Next has a great developer experience" None of these justify using React. It all boils down to "I'm doing it because I can and I'm familiar with those tools".

> None of these justify using React. It all boils down to "I'm doing it because I can and I'm familiar with those tools". "I'm using x technology because I'm familiar with it" is exactly what most people should be doing. Many people try to create production sites with tooling they're not familiar with, or take too long learning something new. Why do none of these justify using React? They probably care about differen…

[deleted]

Re: Server-Side Only React with Next

#46

This is cool, and you make it clear it's an experiment, but I'd just like to ask you in a bit more detail on the part about not just using React SSR directly because you felt you were just reimplementing Next - to me most of the value Next brings is abstracting away the isomorphic stuff, making everything work the same on client and server in a seamless 'app-like' structure. But since you don't need the client, you d…

Good question. I think that relates to the “developer experience” point I was trying to get across: Things like file-system routing (eg. drop a JavaScript or Markdown file in /pages) and overall a Webpck/Babel setup along with the build/export scripts that just work out of the box. Regardless I still think you have a valid point and yes this is experimental and not something I would generally advise.

> file-system routing

Ah yes, there are some interesting new frameworks built around this concept. PHP.js comes to mind.

> yes this is experimental and not something I would generally advise.

I know what you mean, but it is still funny, given how long this was the way nearly 100% of web development was done for about 15 years.

Re: Server-Side Only React with Next

#47
post #23

> In the past I've also tried Jekyll and Hugo. I found that both work great out of the box, but were hard to customize as I'm not very fluent in either Ruby or Go. Why do people not know about Eleventy, why?

I tried looking at the tutorials and docs, but didn't immediately find any mention of images. Does it do images in a sane way, or does it require third-party plugins?

Re: Server-Side Only React with Next

#48

Is this a precursor for the pendulum swinging to the other side and we're moving back to server side rendered HTML pages?

Personally I think the best thing about React is the component based architectures, which you don't need JS/SPA to use. Are there any good SSR frameworks that have a similar react-ish syntax? (Next/node.js is apparently too slow to use as a server backend for rendering pages on demand)

Re: Server-Side Only React with Next

#49
I read your blog on the tech stack used for building your site and in the analytics section you mentioned using Simple Analytics as it allowed you to serve the analytics script from your own domain. Was it because one of the things was bypassing ad blockers? As serving from your own domain won't block them?

Re: Server-Side Only React with Next

#50
post #37
post #34

Earlier quoted context omitted.

You could take a mixed approach. Server render non-stateful stuff, restrict user state to client-side only. You can then CDN cache the public stuff.

Which is the reasonable way to do it. However, uncacheable things might remain.

Uncacheable things are always reserved to the client side only
Post reply on HN