The insanity of SSR (Server-Side Rendering) for Enterprise apps

Recently, we talked to a prospect who was building an ETL (Extract, Transform, Load) front-end, and found out that they were doing it in an SSR framework.

This is insane.  Truly and completely nuts. 

To set the stage for this discussion, there are two basic models:

1. SSR (Server-Side-Rendering) and
2. CSR (Client-Side-Rendering).

An SSR framework renders the content shown to the end user on the server. 
A CSR only pulls data from the server, then renders all content inside the browser.

Just speaking in general of apps, a CSR offers the following benefits:

1. Massive scalability: anywhere from 30-90% of requests cause no server load at all, and provide instantaneous response to the user.
2. Rich, productive UI: huge suite of powerful components, well beyond SSR frameworks.
3. Radical productivity: simple programming model with drag & drop and low code design available.
4. Cacheable & offline: the entire application is cacheable, and almost all application functionality is available offline.
5. The app can be readily packaged as an installable mobile or desktop app.

Radical scalability, radical responsiveness, and extremely rich UI: this is what characterizes Isomorphic SmartClient’s CSR approach. 

In comparison, an SSR architecture offers:

1. SEO

….

Oh wait, we missed one:

• If you are accessing an SSR app for the first time ever,
• and you are on a phone,
• and the site involved doesn’t have an app it recommends you download,
• and you happen to have never encountered the CSR libraries involved so you don’t already have them cached.

Then perhaps, on an antique smartphone, SSR might edge out the initial CSR render time by a nose: ~200-500ms.  Maybe.
All subsequent requests will be much slower with SSR.

Now, let’s examine CSR vs SSR in the context of an enterprise app.

Think of all of the enterprise apps you know: ERP, CRM, ETL, BPM, BI, SCM, PLM, IAM, DMS..

Do any of these involve SEO? 
Do any of these apps need particular screens to rate high on Google? 

No.

So, let’s revisit the benefits of CSR vs SSR in the specific context of enterprise apps:

CSR: 

1-5. same benefits as before (radically scalable, instant response, productivity, etc.), only more so.
Long session times amplify all the benefits.

SSR:

1. …. well, crap!

That’s right – absolutely nothing.

So if it’s that bad, why SSR at all?

Imagine an app that benefits from SSR. 
What are its characteristics?

1. SEO is paramount – it’s trying to attract maximum traffic from consumer-level users.
2. Reducing server load is actually kind of bad: it’s actually better if there are more hits on the server, because the app’s success is gauged by views, not productivity.
3. Pages are very simple – there is limited benefit from client-side interactivity because we’re offering a “lowest common denominator” UI.

This rings a bell.. ah yes, that’s a social network.
That’s Facebook!  That’s Instagram!

It’s also (kind of) eBay, or Etsy, or maybe Amazon’s product listings – all sites that want to attract maximum attention from search engines and have limited interactivity (just buy and check out).

And that’s the #1 reason SSR is visible as an approach at all. 

It’s because these social networks and large ecommerce sites have very good reasons to use SSR – all of it fundamentally rooted in their need to maximize SEO, and their very limited interactivity.

So, developers see these massively successful sites and their huge valuations and think: well, anything good enough for those megasites should be good enough for my ERP app.

But this actually makes no sense at all. 

The #1 benefit of SSR (SEO) has zero relevance to your ERP, ETL, PLM, whatever app.  Zero.  

Indeed, people need to log in to view the data in your app. 

If the confidential data in your app were to be visible on a search engine, guess what?? 
You’d be fired! 

So why are you picking a framework that emphasizes appearing in search engines??

What you actually need are all the benefits of a CSR architecture listed above: rich, sophisticated UI, easily built.  Immediate responses with no server load.

Reason #2 – Follow the money!

Reason #2 is a little darker. 

I’m going to veer a bit off-script and tell you what’s really going on.

“Edge services” companies (companies with networks that extend into every ISP and every physical location possible) can make a lot of money from apps that need to get compute power as close to end users as possible.

In a CSR (Client-Side Rendering) architecture, what you need to deliver to the “edge” is just a static file – some JavaScript, maybe some SVG for icons – no compute power involved. 

There are many “edge services” for this (CDNs – “Content Delivery Networks”), and it’s inexpensive.

Honestly, in the context of the costs of enterprise application development, the cost of maximally delivering your application to “the edge” in a CSR framework – it’s basically free. 

It’s not a cost that even registers in the overall scheme of things.
That’s not good for “edge services” companies.

SSR architectures are much better for edge services companies.

They want as many apps as possible to use SSR approaches, because then, many more apps will require their services in order to perform well.

This isn’t MKULTRA or COINTELPRO here, it’s just basic economics.
These companies would like to promote this architecture.  If people use it, they make more money.

“It’s scalable” – the zone is flooded with ****

If you Google CSR vs SSR, or if you ask ChatGPT for a comparison, you will, amazingly, in your first foray, be told that SSR frameworks are “more scalable” than CSR frameworks such as SmartClient.

It’s hard to convey just how absolutely insane, how gibberingly off-the-charts, how mad-hatter-snorting-mercury this is.

It’s simple to understand:

1. An SSR with edge services can try to make a given request very fast.
2. A CSR means the request never happens, at all, edge services or no.  It’s instant.

Another way to come at it: you can spend as much money as you want on edge services. 
A CSR is still infinitely faster.  Because the server request never happens at all.

If that still isn’t clear, imagine being offline on a hike where you (unfortunately) really need to access some data you were recently looking at.  CSR: instant response.  SSR: … waiting…

Need further confirmation? 

Having asked about CSR vs SSR benefits, and having received the default response, raise the above points with ChatGPT. 

It will immediately backtrack on its claim that SSR is “more scalable”, and you will see headlines such as “Does SSR ever make sense?”.  Because that’s the reality.

Conclusion

When it comes to enterprise apps, there is absolutely no question: a CSR architecture (like SmartClient’s) is vastly, vastly superior.

Certain enterprise developers are, through pure naivety, picking SSR architectures because:

1. They are wrongly thinking that Facebook’s architecture is the right one for their BPM, ERP, CRM, PLM, etc. app – even though the requirements are opposite!
   
2. They have been bogusly influenced by marketing from edge providers, who literally want them to pick the worse architecture!

Don’t be naive. 

Any competent developer should be able to see through the noise and make the right choice.

Join us and move faster than anyone imagines is possible!