
Server-Side Only React with Next - danielstocks
https://webcloud.se/blog/2020-03-12-nextjs-without-client-side-react/
======
jensneuse
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 performant by making it less interactive again.

Step 5: Server Side HTML

-> More performant than the previous iteration, also less complex.

You can see that nothing really changed but developers are super happy because
they improved the experience all the time.

~~~
simplify
No joke, I started my career in Step 1 with Ruby on Rails. I lived and
breathed Step 2 and Step 3 with the ever-changing industry standards: jQuery,
backbone, angular (avoided), react, and (currently wrangling at work) the
complex beast that is graphql & apollo, all over the span of 10 years. Coming
back to Rails for a side project has helped me realize:

\- Server-side rendering is actually fantastic. It's fast for users and
there's no sluggish build step holding you back.

\- Turbolinks covers 70% of the interactivity you need.

\- Alpine.js covers another 20%.

\- With Rails having webpack built in, there's no friction to
writing/importing your super-fancy JS interaction for that last 10% when you
need to.

Rails gets it right. It truly makes your dev life better, in ways that
actually matter. Back then I was convinced Rails led to spaghetti code, but in
hindsight I just needed to improve as a software developer.

10 years later, there still isn't a better tool than Rails for tech founders.
There are some promising ones, but none that get you launched nearly as
quickly. It's kind of annoying, to be honest. Is this that hard of a problem?

~~~
midrus
Totally agree. I use [https://unpoly.com/](https://unpoly.com/) instead of
Turbolinks, anyone interested in this more sane approach should give it a try.

------
davnicwil
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 don't need any of that, right? Seems
like without having to structure the server code in the same way you'd
structure client code, things just get a lot simpler and the native React SSR
stuff should be fine to use directly. Just curious which other features of
Next you found you wanted for a server-only app?

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

~~~
davnicwil
Got it - so literally just for the higher level 'rails like' dev experience
and nothing 'react-y' _per se_? Thanks!

I actually thought it might have something to do with data loading, so it was
a slightly leading question as I'm very interested in that stuff - I have a
library react-frontload [0] that does client & server data loading that could
feasibly be used in a server-only context, and am always looking for ideas on
different usecases etc.

[0] [https://github.com/davnicwil/react-
frontload](https://github.com/davnicwil/react-frontload)

------
dugmartin
I'm playing with something similar on a side project inspired to Gatsy & Next
but for Elixir/Phoenix. I've created a webpack plugin that compiles Next-like
React page components into .eex templates and then optionally generates a
bundle to "hydrate" the page using assigns from the Phoenix controller.

You get the speed/reliability of Phoenix and the (for me at least) power of
creating your UI in React without having to run a node server at runtime. I'm
planning on releasing the plugin once I've used it on a couple of personal
projects to remove the rough edges.

~~~
davydog187
Would you consider open sourcing this? I’d be interested in using this for
some of my own projects, having dealt with similar problems to the one you’re
describing.

Phoenix Live View is cool and all, but still not stable enough for my liking.
Also, depending on the use case, it can be unviable.

~~~
dugmartin
I plan to open source it soon but I want to try it out on at least one
personal project first to figure out any holes in the api before I release it.

I have it working with a sample page that renders three dates (static webpack
render date, phoenix render date and current date that updates each second
with a timer) but I think I need to try it on a real page with real data.

------
sandGorgon
Nextjs SSR 9.3+ could be the first serious replacement to Rails. Its one of
the only frameworks where you can mix Statically Generated Pages, Server Side
Rendering and Client Side Rendering.

It doesnt have everything built-in, and the fact that Zeit has such tight
control over nextjs to be a minus...but im expecting Next (and Gatsby) to some
extent to drive full stack webplatforms for the next decade.

You have to write javascript anyway in Rails...why not go JS all the way ? And
Typescript is definitely a fantastic language.

~~~
dgb23
Another project I'm following, which is very young is this:

[https://redwoodjs.com/](https://redwoodjs.com/)

It is worth looking into their discussions, issues and so on, doing the
tutorial and looking at the roadmap if you are interested in this kind of
thing. Very opinionated and they embrace a component based approach with
React, GraphQL and so on, while providing useful code generation.

Also this CMS project does a lot of things really well too:

[https://strapi.io/](https://strapi.io/)

Also pretty young but at a stage where you can use it for real things. Also
code generation, GraphQL support and very modular.

But if we're pragmatic, there is still nothing that beats shared hosting LAMP
stacks currently if you need a CMS and/or custom backend for a web-app in
terms of operational overhead and cost. And it is not like the PHP community
was sleeping either. For Rails specifically: It introduced a paradigm shift
but both the Python and PHP world caught up very quickly. I don't see a big
enough benefit of using either of those three except for the lower operational
cost of PHP.

So I agree with your prediction, but we are not quite there yet, or at least
not for small to medium projects.

------
nfriend
I did something similar with Nuxt.js when building my résumé site:
[https://resume.nathanfriend.io/](https://resume.nathanfriend.io/)

I used a more heavy-handed approach: I strip out all <script> elements from
the build output before publishing: [https://gitlab.com/nfriend/nuxt-
resume/-/blob/63e0298fdb5a08...](https://gitlab.com/nfriend/nuxt-
resume/-/blob/63e0298fdb5a08b99e0d24e21b1124e7dfc93f95/ci/strip-script-
elements.js)

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

------
deltron3030
Something similar also based on Next called Blitz that popped up recently.

[https://github.com/blitz-js/blitz](https://github.com/blitz-js/blitz)

RedwoodJS, a new rails like full stack framework for JS is also very
interesting:
[https://github.com/redwoodjs/redwood](https://github.com/redwoodjs/redwood)

They focus on a classic server side Rails like workflow but embrace the
separation of API and clients on the technical side, for a future as a multi
frontend framework (web, mobile etc.).

------
jamil7
Isn't SSR React notoriously slow? Whats the benefit here over a standard
templating language?

~~~
danielstocks
It can be, but I’m not running a server in production: I’m using the static
site generation feature in Next (comparable to Jekyll or Gatsby). It takes an
input (Markdown in my case) and spits out a bunch of HTML files that are later
deployed on a CDN. No server-side runtime required.

~~~
Can_Not
If you're not running the SSR server in production, then wouldn't that just be
a static website and not SSR at all?

------
cprecioso
I will definitely use this approach in some of my Next sites, but I got a bit
sad that the writer’s removing React but then has to go back to vainilla
JavaScript and global libraries to recover the functionality they’ve lost.

At times like this is when I most think of Svelte’s aspiration, to remove the
framework and compile its uses to regular DOM calls. It just bothers me so
much with their magic syntax.

PS: Maybe something similar could be made for React Hooks? If a component
doesn’t use any hooks it’s marked as static and doesn’t need the framework or
to be re-hydrated. If it uses any, we only need to create a discrete React
root for that component and its children.

------
azangru
> 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?

~~~
magicalhippo
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?

~~~
PascalW
It doesn't. In fact it doesn't do anything for assets in general. But
integrating it with Webpack is quite straightforward if you're comfortable
with Webpack.

~~~
magicalhippo
Ok. I saw all those "make a blog with Eleventy" examples but an integral part
of a blog is images and of course automatic resizing of preview etc of those.

But cheers, I'll check it out some more.

------
_bxg1
Hybrid client/server React is a monstrosity that does provide a genuinely
compelling set of benefits. Next.js neatly wraps up this monstrosity so you
can at least try to pretend it doesn't exist.

Server-side-only React sounds like a fundamental misunderstanding of what
purpose React actually serves.

In React, you write functions that accept data and output what amounts to
HTML. Thing is, you can easily do this with a plain template string. You're
just dropping values into HTML. The only benefit provided by React is the
efficient modification of _existing_ DOM to bring it up to date with the new
state, without dropping the whole thing and rebuilding it from scratch. If
there _is no_ existing DOM - because you're only making one rendering pass -
React serves no purpose at all.

Here's my website. It uses virtually nothing except Express and a Markdown
parser. Pages and components are rendered from plain JavaScript functions.
Blog posts are in markdown and automatically detected. Right now it statically
renders all of the pages on startup, for efficiency, but it could be made
dynamically-rendered with a flip of a switch:
[https://github.com/brundonsmith/website](https://github.com/brundonsmith/website)

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

~~~
terandle
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)

------
leerob
This was fascinating! I also read some of your other posts and thoroughly
enjoyed the content. Great work.

Related – If anyone wants to learn more about Next.js, my course is free right
now while everyone's stuck indoors.

[https://twitter.com/leeerob/status/1244313263720062977](https://twitter.com/leeerob/status/1244313263720062977)

------
FlashBlaze
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?

~~~
danielstocks
Yes, you can read more here: [https://docs.simpleanalytics.com/bypass-ad-
blockers](https://docs.simpleanalytics.com/bypass-ad-blockers)

------
XCSme
Maybe it's a good idea if you already had a React codebase and want to switch
to a static site with few code changes, but I think it makes zero sense to
start a new project with React only to have it rendered on the server-side.

------
hisnameisjimmy
Every time I read one of these types of articles I have an "Am I taking crazy
pills" experience.

I get that as an educational experience this is interesting, but the level of
complexity required to generate static html is extraordinary. Just the amount
of tooling and conceptual understanding necessary is so crazy.

I've been working on building out a simple Electron app recently and
considered React, but realized with little to no interactivity it would be
insane overkill. However, one of the most popular boilerplates out there
combines react, redux, typescript, webpack, etc, etc.

There seems to be this default right now of 'over-engineering' everything.
It's like people have forgotten how to make simple things.

------
rado
Good, it should be server side only.

~~~
enlyth
Depends on what you're building. Client side rendering vs SSR have both
different trade-offs and performance implications, and it's best to evaluate
which is better for your use case.

For a blog or mostly static webpage? SSR is probably the better choice. But
there are many times where serving a minified React bundle to the client and
letting it do all of the rendering work is better. It's actually a much lower
strain on your server, because all you're doing is serving static files from
behind a proxy like Nginx, whereas with NextJS your server incurs significant
performance overhead from having to evaluate each page view in JS. Imagine
this for a million visitors at once when you have content that cannot be
statically cached.

~~~
nfRfqX5n
why couldn't you cache it?

~~~
doque
Because it could be personalized content that differs for each request/user.

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

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

~~~
dbbk
Uncacheable things are always reserved to the client side only

------
ecmascript
Is this serious or just a troll post?

Because this triggers me a lot. Why wouldn't you just use a normal templating
language that render html? Isn't this seriously all the same except you just
add a massive dependency for no reason? This is why I hate the javascript
community.

The only word I find for this is that this is dumb.

~~~
sgzfx
The post includes the author's reasoning.

~~~
doubletgl
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".

~~~
hazz99
> 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 different
things than you do.

~~~
pxtail
> "I'm using x technology because I'm familiar with it" is exactly what most
> people should be doing.

Not necessarily, there are multiple tools in the world and not without reason
- almost all of them were created with specific purpose. One can be very
familiar and skilled with using hammer but it doesn't mean that it will be
efficient to cut a slice of bread with it.

For software tools makers it is very tempting to try to make it versatile
enough to be able to use it for every possible case, however this is not
possible and never will be without sacrifices - and most frequently speed,
clarity and ease of use is sacrificed first - there are multiple examples of
this: jira, gitlab, facebook, clickup. Complexity, bloat and cognitive load is
growing, users are starting to have difficulties to grasp all options and
possibilities - and boom suddenly from most loved to most hated.

------
cryptica
I'm tired of the dogma that's behind all the hyped up software development
tools and techniques.

For years, I was telling people that React and related tooling was a bad idea,
that it adds a lot of unnecessary bloat which is not worth it. Everyone (like
99% of developers) disagreed with me and kept insisting that it was a simple
solution.

Fast forward half a decade, now pretty much everyone agrees that React adds a
lot of unnecessary bloat... The level of bloat just had to get truly appalling
for people to actually notice (I swear a lot of projects seem to take 10
minutes to build). It took 5 years for people to accept the PREMISE of my
original argument.

But now even though a lot of people finally accept the premise, they are still
desperately trying to rationalize the existence of their favorite hyped up
tools in any way they can.

I'm tired of explaining to people that "simpler solutions are better than
complex ones". If any idea should be recited dogmatically, that should be it.
Someone should write a book about it so that people can repeatedly whack
themselves over the head with it until it gets through their thick primal
skulls.

~~~
krainboltgreene
You may want to check the temperature again. The react community is still
huge, still growing, and still improving. React jobs are still widely
available and new companies get started using react (or transition to react).

You aren't the first person (or the last) to care about payload size to the
browser. Everyone cares about that, including the React core team.

~~~
cryptica
>> React jobs are still widely available

I don't doubt React's effectiveness as an economic tool for job creation. No
economic tool is able to turn a simple 1-person job into a complex 100-person
job as effectively React does. The Federal Reserve Bank loves React.

But is it the most effective tool for writing web apps? Not by a long shot.

~~~
ng12
> But is it the most effective tool for writing web apps

What's your preferred alternative, pray tell?

~~~
cryptica
If you use VueJS without a compiler or bundler during development (and yes,
this means no TypeScript), you can achieve an amazingly productive development
experience. If you can resist all the tools which try to bait you into adding
a bundling step, you won't regret it.

It takes a lot of effort to figure out how to use VueJS without the bundling
step and it can feel constraining initially, but the simplicity pays off in
the long term.

I'm quite annoyed though that VueJS team has been moving towards TypeScript
and bundling. Am I the only person who thinks that front end work is too
simple to need type safety?

Front end programming is like riding a bike, after a while, you don't need the
training wheels anymore; they just slow you down and deprive you of real
enjoyment.

Also, there is a joke my colleagues used to say about front end:

"Front end work is like building a house of cards. If it collapses, no one
gets hurt. On the other hand, back end work is like building a house out of
wine glasses..."

~~~
ng12
Can't say I agree. The relative cost of bundling is minimal. I don't really
think about my setup at all -- it's such a minute part of my daily workflow.

Anyways, your disdain for front-end development will probably preclude a lot
of people from taking your stance seriously.

~~~
cryptica
If you had actually tried it properly, you would not disagree, it's really
that self-evident.

~~~
ng12
If your goal here is just to gloat about how "everyone else is doing it wrong"
then I don't think this is a productive conversation. I was doing web
development before bundlers were a thing and I do not miss those days.

