does “simplest” here mean simplest for the user to use, or simplest for the dev to build? these are sometimes completely opposed to one another.
an example: filtering a large table of data on multiple fields in an otherwise fully-server-rendered project. doing it server-side is likely mostly sql queries using existing stack and re-rendering the page after some “submit” click.
doing it client side means the data can react immediately to selections and never require a full page refresh (which might be costly, depending on the rest of the page). the dev downside is that this might require an enormous amount of new stack and complexity.
This is only sometimes true. Other times, cutting the server rendering makes things a million times easier because maybe you're not contacting your database, or you're offloading large per-user objects to the client instead of keeping them in ram for thousands of uniques per minute, or, or ...
Some calculations are less heavy on the client side. It's not building the html itself once you know what you need that is heavy, it's that awful dropdown menu with dozens of nested filters that rely on user-input data which is awful to build serverside, but incredibly easy to build client side.
Yes in that instance you are correct that server-side rendering is easier. It doesn't make it any easier to build a mash-up application in which you are relying on multiple sources of data that you do not control.
Yeah, in theory it's pretty simple. If you're using Javascript on both the server and client, it's definitely easier. But I guess I'm conflating server-side rendering with "pages that don't require Javascript to work", which is definitely more work.
I definitely meant simple. To the average newcomer to Javascript, what they're familiar with is server side rendering. An HTML page is sent from the server, the markup is rendered, and bam - a page.
Now, go tell this newcomer that you don't actually need a server to serve multiple web pages, it can just serve one! Client side rendering with a client side router is a pretty far departure from what even experienced programmers know about the world.
Now, go tell this newcomer that you can absolutely still render components from the server without redrawing the whole page. They'll enjoy this until they run into the limits and constructs of SSR. Again, a pretty far departure from send a whole page.
Now, go tell this newcomer you can do both at once, and that often it's beneficial to do so. You have taken what was a very simple task and made it quite complex.
Well, you can at least appreciate the simplicity of a server just being a simple API that all of your clients use in the same way rather than the server having an API and then also generating the page for one specific idiosyncratic client that has this weird feature where you can serve layout to it.
Also, once you have any interactivity, there's a point where it's nicer when all of the application is in the domain of Javascript instead of only parts of it.
Server-side rendering has some nice upsides, but there are various trade-offs, good and bad, at play here.
Easier to develop for but in terms of raw computation costs and speed, client side wins.
If you want the maximum tradeoff for ease of development then having all of the UI rendered on the server is the ultimate solution in terms of ease of development.
HTML (or more specifically HTML+css, and how they interact with and render in the browser) are anything but trivial. javascript (the language, not the JIT) is relatively simple in contrast
client side rendering + json apis on the server are the holy grail of openness (esp with an MIT licensed client)
I keep hearing this, but I think it's too broad of a statement.
There are definitely functionalities that are impractical to implement with server-side rendering and forms alone. Map widgets and drag-and-drop come to mind.
The issue I have though, is that the overwelming majority of web functionality can be implemented as server-side rendering.
I'm not sure I've ever seen a case where I have a data set that's small enough to be quickly searchable (and quickly re-renderable) using client-side JS but big enough that I need dedicated and app-like sort, search, or query functionality. And where such a set of data to exist, that data set would almost certainly be _growing_ with time, meaning even if it started out as something where I can have snappy JS search, as time passes the JS search grows heavier and slower through time.
Additionally, when it comes to client-side spreadsheets I have seen far more terrible half client-side, half server-side implementations (being only able to sort within a page, instead of across all pages of results). If I had to choose one, I'd choose a world were all we had were server side spreadsheets.
is there still an argument that can be made in favor of doing your UI on the server side?
Ability to link to documents, bookmark, meaningfully use history and save pages to the disk for offline use.
Ability of the users to customize standard behaviors without reverse-engineering your JavaScript code.
Transparency, which often leads to much, much easier debugging and improved usability.
No need to run a quad-core 4GB desktop to use the website.
And this is just the stuff relevant to internal (non-public) websites. You can argue that all of this can be achieved with JavaScript heavy clients, but in reality, it's just isn't. It's not something you get by default, it's tons of extra work, and most people don't do that work.
Even just in principle, it can't possibly be close to as fast (client-side can render optimistically, where possible), and it can't be close to as flexible (you don't have a model of state on the client to perform logic with).
In principle, server-side rendering can allow you to share pre-rendered components between thousands of users saving everyone tons of work. In practice, rendering on the server side is just string concatenation and is insignificant compared to things like running SQL quires, which you'll have to do anyway.
> With server-side rendering you don't have to create yet another layer to actually transfer the data to the client just to render it.
That layer doesn't go away with server-side rendering. It is always there, even if you don't use a REST API. It just gets fused with views.
In fact, I'd argue that this perception that server-side rendering gets rid of that layer is a telltale sign that the project is already plagued with accidental complexity.
> It usually also implies that you don't have build your data model in two different languages ($BE_LANG + JS/TS);
Unless the front-end is written in pure HTML+CSS, this hypothetical simplification doesn't materialize. Also, you can't brush off or ignore the complexity added by templating engines.
> Developing an API may also be a waste of time when your client-side application is the sole consumer of the server API.
I don't get what point you're trying to make. Even if you are the only client for that API, don't you still need to put it together and maintain it?
For simple projects it really doesn't make much difference. Depending on your available tools, client-side or server-side rendering might be easier. In the end the only difference is what is going down the wire: data or HTML.
That said, client-side rendering is strictly more general than server-side rendering. So I prefer to use client-side rendering everywhere so that I don't have to switch between two different modalities and maintain two sets of tooling (or worse switch in the middle of a project!) I gather this is against the current fashion but whatever.
I'm not seeing a direct connection between UI simplicity and server capability. I can serve a hideously complex UI with a very minimal demand on the server. Demand on the server is much more about actual traffic, not the UI being rendered in the browser.
an example: filtering a large table of data on multiple fields in an otherwise fully-server-rendered project. doing it server-side is likely mostly sql queries using existing stack and re-rendering the page after some “submit” click.
doing it client side means the data can react immediately to selections and never require a full page refresh (which might be costly, depending on the rest of the page). the dev downside is that this might require an enormous amount of new stack and complexity.
reply