
SimpleSSR: Server-Side Rendering at Scale - momonga
https://www.simplessr.org/
======
tylerjwilk00
I may get hate for this but watching JavaScript development mature makes me
feel like I am taking crazy pills. So much shit was figured out decades ago
but it's like everyone is just learning this shit for the first time. I don't
know if it is because the standard library is so lacking or that it's been
historical a client side only language but it makes me feel completely
disillusioned with programming. It's like we're not progressing at all, merely
learning that same shit over and over again each generation in a series of
cycles.

Or maybe I'm just too old and need to get off my own lawn.

~~~
intothemild
You’re not crazy.

I created and maintain VueJS’s other Server Side Rendered library. Express-vue

I’ve spoken on it at a few talks, and every time I do, the eyes of the
audience just go blank when I talk about SSR. It’s like I’m talking in some
strange language they don’t seem to understand, where the only thing they get
is client side everything.

I get the stupidest questions like “so how do I add in <insert unnecessary
bloat for a SPA here>” most of these are about state management on the client.
Aka redux, or vuex etc. Which I reply. “You don’t need that. State lives on
the server. It’s simple”.

Since having this library and it getting as big as it has, having to defend it
and defend SSR. I’ve fully burnt out of JavaScript and frontend all together.

We use my library in production at work, and have started talking about
migrating to Nuxt. I’m planning on changing teams before that happen.

Javascript is just hype driven development, of the worst kind.

~~~
BigJono
Thanks for all the work you've done on express-vue. Even though I'm not the
biggest fan of vue and only really use it at work, it makes me happy to know
there's good libraries out there for it that do one thing well (a trait that's
sorely lacking in a lot of JS libs).

------
highwind
You can't beat serving useful data to the user on the first payload (base
HTML), no matter how fast or clever client-side rendering gets.

~~~
mzzter
Agreed. Useful data in the first payload is what matters for a responsive
experience. The kind of engineering team drives whether it is appropriately
accomplished with view templates, rendered view frameworks, or some other HTML
rendering technology that embeds preloaded data.

~~~
muthdra
Here's a pattern: since your Service Workers won't run the first time a user
visits a page, you should send server-side rendered content to the user that
also has a line that installs a Service Worker after the page is fully loaded
from base HTML with useful data.

The second time the user visits your page, the Service Worker will ideally be
installed and will run, intercept the call and download your components
separately, when they're needed, and save them on cache, as opposed to let the
server render the components to base HTML.

Third time forwards, components are loaded directly from cache and rendered by
the Service Workers.

~~~
kinlan
This is exactly the pattern I use in [https://github.com/PaulKinlan/webgde-
deck](https://github.com/PaulKinlan/webgde-deck) and whilst is a little harder
to mange it's incredibly fast

[https://webdev.topicdeck.com/](https://webdev.topicdeck.com/) is an example
of it hosted.

~~~
mxstbr
FYI I'm getting "542: An error occured with your deployment" when clicking
that link!

------
BigJono
I'm seeing a lot of posts about NextJS here...

Adding a (huge) abstraction on top of another (huge) abstraction to solve a
problem introduced by the first abstraction is rubbish software engineering.
It's one of the oldest anti-patterns in the book.

I get that these libraries provide some utility beyond their core purpose, and
that it's a bit more nuanced than A -> B -> A, but I'm highly suspicious of
people that recommend these libraries without giving much context behind it.

~~~
smokeyj
The industry norm for SPA seems to be moving towards SSR along with code-
splitting and offline workers. The main SSR framework for React is NextJS. Vue
and others have their equivalents.

Honestly I don't see a reason not to use it. I could write a traditional
website using Next/react at the same speed as someone using Django/rails/etc.

~~~
subsection1h
Next.js is a front-end framework, right? So how can you build a traditional
website using only a front-end framework at the same speed as someone using
Django or Rails?

~~~
ricardobeat
It's not like it's hard to find: [https://nextjs.org](https://nextjs.org)

Next integrates the server and client code in a single framework, and is made
for seamless deployment using Now.

~~~
subsection1h
I previously visited nexjs.org and read the docs, and it wasn't clear that
Next.js is a full-stack framework. The term "full stack" isn't used anywhere
at nextjs.org[1], unlike rubyonrails.org[2].

Furthermore, there are numerous references on the web to Next.js being a
front-end framework, including statements made by Next.js maintainers[3]. Do
these statements not reflect the current state of Next.js?

If Next.js is a full-stack framework, then this seems to be another instance
of JavaScript tools having inadequate documentation. Speaking of which, if
Next.js is a full-stack framework that's comparable to Rails and Django, why
is the documentation just one page (!) and there's no mention of database
migrations or other basic features that are included with every full-stack
framework?

[1]
[https://www.google.com/search?q="full+stack"+site:nextjs.org](https://www.google.com/search?q="full+stack"+site:nextjs.org)

[2]
[https://www.google.com/search?q="full+stack"+site:rubyonrail...](https://www.google.com/search?q="full+stack"+site:rubyonrails.org)

[3]
[https://github.com/zeit/next.js/issues/1933#issuecomment-300...](https://github.com/zeit/next.js/issues/1933#issuecomment-300476550)

~~~
friedman23
Next.js is not really a fullstack framework. It provides a server for static
websites but as soon as you want dynamic content you can use any js api
framework of your choice.

------
toolz
disclosure: I'm the biased author

texas [https://gitlab.com/dgmcguire/texas](https://gitlab.com/dgmcguire/texas)
is a library that brings development back to the server. You can integration
test without headless browsers, get SPA-like UX without writing a line of JS
and basically just write SSR apps with only adding a few lines of code to make
you apps realtime and SPA-like.

It works by leveraging persistent connections (websockets) first page load is
entirely SSR and subsequent updates are SSR, but only by V-DOM diffing html
fragments, sending only the minimum amount of patch data over the wire.

Your apps will be faster, your development process will be faster with less
code and removing all kinds of complex tooling.

Here's a todoapp that does all rendering SSR [https://warm-
citadel-23442.herokuapp.com/](https://warm-citadel-23442.herokuapp.com/) \-
you can see just how fast it is even on a free tier of heroku - open it up in
multiple clients and you'll see that all operations are realtime broadcasted
too and believe it or not there's only like 3 lines of code you write to make
that happen (plus all the code necessary to get a normal SSR app running)

~~~
ngrilly
That's interesting, but the latency is clearly perceptible between each action
and the related screen update.

~~~
toolz
Likely you're just located somewhere far from the server in Virginia, USA. If
you watch the conference talk just a few minutes in I show a gif of the
latency from Seattle to a server in California. Most interactions you can't
tell at all.

------
kenOfYugen
I can't say I fully comprehend the SSR vs SPA war. Both concepts are
definitely being misused/overused, one is "dated" and the other "modern", but
surely the middle ground where best usage of both can be attained is prefered.
I don't know of any terms that mediate the opposition other than perhaps
"hydration"?

~~~
sam0x17
This is the key. There are super developed SSR frameworks and super developed
SPA frameworks, but getting the two to work together is like pulling teeth. No
one tries to write an SSRSPA framework because that would be considered too
"opinionated", but maybe that's exactly what we need.

~~~
kraftman
Doesn't nextjs do this already? You write an SPA that nextjs implicitly also
knows how to render server side

~~~
leetbulb
Yeah, that's essentially the purpose of Next.js and it does it very well.

------
friedman23
I've been using Next.js and SSR with react is dead simple. I use React even
when building standard web pages because the React way of doing things makes
more sense to me as a programmer than the html/css/js way of doing things.

I like building composable building blocks with self contained state. The old
model of separate html, css, and js never worked well for me.

My main complaint with React SSR is that it almost forces on me the
requirement of using Node for the backend. I'd prefer to use a language like
python.

~~~
raihansaputra
Is there any way to do use python as the backend? I feel the same way about
handling raw HTML/CSS/JS. Either I haven't learned enough about handling those
or I should learn React/Angular/Vue, but I do want to stay on python for my
backend.

~~~
friedman23
I mean, the way to do it is to have a server for ssr and standard requests and
another server for the api written in the language of your choice.

------
shaunpersad
Gatsby.js (and some other recent tools) makes the SSR vs. SPA argument moot.
There's no need to pick one when you can have both.

Disclaimer: I'm not affiliated with Gatsby.

~~~
city41
I’m a fan of gatsby and think it’s a sensible approach for many sites. But it
has limitations. Most obvious being it essentially reverts to an SPA if you
need the user to be logged in before you can render any real data.

------
scottmf
React SSR is not a problem, and I can get quicker TTFB than I ever remember
getting with even a simple RoR app (300+ms yikes).

I can also work faster with the React ecosystem (and find it much more
enjoyable) than RoR and SSR makes the end result the same anyway.

People like component-based frameworks and modern JavaScript (and its
supersets). Things are different now. Deal with it!

~~~
wrl
> Deal with it!

We, your users, _do_ deal with it. Constantly. Usually, we deal with it by
waiting 30 seconds for your single-page application blog article to load
because we only get intermittent 3G reception on the metro.

I don't really care what sort of frameworks you like. Stop building shit
webapps!

~~~
friedman23
Your complaint has nothing to do with using React over using other frameworks
such as django.

The problem you have is that people are not implementing SSR on their websites
and they don't host all of their assets.

------
nemanja
Upcoming Phoenix LiveView is actually pretty viable for SSR -

[https://www.youtube.com/watch?v=Z2DU0qLfPIY](https://www.youtube.com/watch?v=Z2DU0qLfPIY)

------
quantummkv
I really don't get this whole SSR thing. You take a framework designed
explicitly for dynamic client side code and use it to make a glorified old
school framework (insert your choice of RoR, Django, Laravel, etc).

Why does anyone think this is a good idea? You end up re-implementing Rails on
a foundation of quicksand and manage to throw the excellent standard libraries
that come with those languages out in one stroke.

Is this a result of too much kool-aid? Or have we ended up with hippie
bootcampers without a shred of knowledge in high level positions? It's
depressing to watch really.

~~~
silviogutierrez
I firmly believe defaulting to SSR/old-school is the way to go. And only add
dynamic behavior when needed.

But when you _do_ need to add that dynamic behavior... things get hairy.

See this comment for more info:
[https://news.ycombinator.com/item?id=18289460](https://news.ycombinator.com/item?id=18289460)

~~~
kraftman
I went to a conference recently where one of the talks was a guy from comcast
on 'Progressive Web App performance'.

The two takeaways were that they had decided against ever using SSR (he didnt
say why just acted like it was ridiculous), and that through various clever
performance tricks they'd managed to get their page load time down from 30
seconds.. to 15.

------
SomeCallMeTim
On-demand Server Side Rendering should be killed for 98% of applications.

SSR->static hosting + client framework is the future.

------
RantyDave
I can't help feeling that edge rendering is greatness personified ... but that
it's perhaps not any more useful than just server side rendering. An edge
renderer is still going to have to either access a model/controller held
centrally (getting our latency times up again) or use some godforsaken
distributed/replicated state that's a bitch to debug. Perhaps an edge renderer
can hold open a connection to the central logic and knock a hundred millis or
so off the set up time as a result, but none of the proposed models for doing
this would seem to support that. They don't seem to support stateful
_anything_.

------
dmcbrayer
Yeah this is a little too on the nose.

~~~
scottmf
Also probably shouldn’t put RoR as the first item in your list of full-stack
frameworks if your title says “at scale”

~~~
hamandcheese
Lots of companies successfully use RoR at scale.

~~~
deialtrous
I think both statements depend on the definition of "at scale". I am no
expert, but every RoR thing I have ever seen has been tiny in terms of traffic
and still performed terribly. Is there anything in the top 100 sites using
RoR?

~~~
jashmatthews
YouTube, No. 2, was still running Python 2.7 as of last year. Python and Ruby
are basically the same performance wise.

Instagram is also a Python app, AFAIK. Last year they contributed some memory
efficiency improvements to CPython.

Shopify is likely the largest RoR site at 80k requests per second but since
it's served as tons of different domains it doesn't really count.

~~~
sam0x17
Twitter was (originally) also built on RoR. Not to mention GitHub is a rails
app.

~~~
hnzix
It's also worth noting that Twitter's feature velocity fell off a cliff when
they moved to Scala.

~~~
fouc
Oh interesting, I hadn't noticed that pattern.

------
mosselman
The number of use cases that people implement with SPAs is huge while the
number of use cases where a SPA is actually better than just rendering some
HTML can be counted on one hand.

------
iamgopal
My golang template render in tens of ms. About same time my slow computer
browser take for spa.

------
wishinghand
For those saying to forgo Next.js and to also serve templates from a non-Node
server, how are sub-views handled? Same as JavaScript but the AJAX call
returns a sub-template and data?

------
CharlesW
> _Is this a joke? Sort of, not really._

 _" SimpleSSR: Don't do SSR"_ is as humorous as _" SimpleC++: Don't use C++"_.
I'm guessing it's funny to SSR haters? (Related question: Are "SSR haters" a
thing?)

So is the essence of this particular hot-take that it's better to render pages
per-request with Ruby or PHP than to serve a rendered result that has no
additional per-request overhead?

~~~
allover
It's not that simple. (I say this as a JS dev who develops SPAs for a living).

For one, "no additional per-request overhead" is an oversimplification, that
is not the case for most SPAs that grow beyond 'small' size, see 'code-
splitting'.

Modern SSR involves re-using the same client-side rendering code on the
backend (which typically means a Node backend), and modern SPAs may employ
some techniques to code-split the client side app, either by-route or other
means.

You can make a decent case that for a lot of 'sites' this whole setup is more
complex than the server-side rendered frameworks of old mentioned by this
site.

~~~
CharlesW
> _For one, "no additional per-request overhead" is an oversimplification…_

That's fair, but setting aside packaging decisions like code-splitting (which
aren't unique to SPAs), my point is that SSR is typically used to deliver
content and app logic that would otherwise require round-trips to code running
on a server. It hardly seems like a huge win for "SimpleSSR".

------
arborsoftware
NextJS - GG

------
philippz
After reading all the comments here... "TRY ALL THE NEW FANCY FRAMEWORKS"

------
stanislavb
Let's make SSR great again

