Deprecate SSR

[ferferga]

Hello everybody! @ThibaultNocchi and me are thinking about removing (or at least leave it alone, but marked as unmaintained) SSR mode altogether.

What's SSR and CSR?

On SSR, the server returns you complete HTML for the first page you visit only. Server requires a full JS interpreter like node running (the same way you need PHP if you're running a PHP page, but with JS and HTML).

In CSR, server sends a basic HTML template and JS files to the client and the client is responsible to "compose" everything. Just an HTTP server like nginx, or Apache is needed.

Here's a simple article to understand the matter

Why?

• We're only 2 people actively maintaining the client now and supporting SSR means doing double work for almost everything we do.

• Even when some stuff is well tested before merging a PR, some stuff like Swiper (the library we use for the home header and home sections), Shaka, libass (utilities we use for video and subtitle playback), fullscreening and even login/logout have been historically a source of continuous problems. Some examples:

#926
#740
#630

• The only real benefit that SSR brings to us is to have faster first initial loads. After the client is fully loaded (when the loading circle/splash logo disappears) there's no difference at all with modern browsers. We're going to deprecate old browsers like IE after we move to Vue 3 since Vue 3 won't support them anymore
  Initial loading times are important, but the difference it's not that much. Improving loading times is as easy as reducing and optimizing the bundle size, which is more approachable than straightaway maintaining two clients.

• SSR is used by business that care about SEO and devices that don't have Javascript or really old devices, so mainly websites you browse and visit where content should appear straightaway (as faster means more time looking content instead of waiting). We're not targeting this client to be a "website", more like any of your long running application that you could have in your PC (Spotify, Skype...). Loading times will always depend on the hardware the user is running the Jellyfin server, so the speed of the experience relies more heavily on them than on us.

• Easier to configure: Client is just easier to configure. You can set up a server quickly with nginx and even python (python3 -m http.server). It's just a matter of downloading the package or compiled assets (which we will tag and release properly like we do with jellyfin-web once this client matures), place it in a folder and go. SSR requires further knowledge for setting up the interpreter.

• This client is just an alternative client for now, but maybe some day it will be shipped in our repo or directly in the server. The shipped client is 99.99% going to be the CSR version, as bundling a full NodeJS server into the server and keeping it up to date with security patches is not easy at all.

• The demo (currently offline, but we're working to bring it back) has always been CSR, so if you're a basic user, you probably only had contact with the CSR version anyway.

• YouTube (and most Google sites) and Netflix (only the logged in section, the main page when you're logged out is SSR) use mostly CSR techniques (it's true they're not 100% CSR) for their clients, since they're easier to leverage for compatibility with video playback and subtitles with modern browsers, while still leaving some headroom for older devices.

• Docker images are way lighter in CSR vs SSR.

• Although SSR is supported as of today, it's not perfect and still have lingering issues that are unresolved (and are probably from upstream, which makes debugging more difficult). Example: UI crashes on page reloads #914

Further details

Since the first day we provided docker images, SSR mode was the default "unstable" tag. Since mid-november (relevant PR: #1594) the "unstable" tag defaults to static, so if you use Watchtower or pulled our image recently from that tag, you're already using CSR instead of the SSR (which was what you had before).

Summing up

We think it's better to focus our resources in the environment that most people is going to use, right now, and in the future. We're convinced that most people used SSR because it was previously our default for the build process and Docker, but not as a matter of a deliberate decision to use it.

TLDR Our question is: Do you use SSR purposefully? Do you think it's essential? Do you really want it to stay? Why?

Outcome

We will leave this thread popping around for a while before deprecating SSR so everybody has time to voice themselves and provide feedback. If no hard reasons to keep SSR and feedback is generally positive or neutral towards the removal, we're going to lock this thread and proceed with the removal sometime in Christmas or beginning next year.

To show your support for the idea, you can simply upvote it, no comments are needed if you're feeling lazy :).

Thank you very much for your input!

[TimGels]

Do you really want it to stay? why?

I fully agree on taking the CSR only route. Removing / unmaintaining SSR would also result in less confusion for people who see that there are two versions and don't know exactly what the differences are between the two.

Do you think it's essential?

While SSR has its use cases, in my opinion Jellyfin does not have many (if any at all) use cases to consider choosing SSR over CSR.

Do you use SSR purposefully? Why?

I do not use SSR, I think it only eats time in the development of the Vue client.

[ThibaultNocchi]

Thanks for your answer :)

[KucharczykL]

I'm just a regular user so my opinion might matter very little but I've followed the project since the beginning and always hoped it would succeed. I'd say focusing your resources on CSR seems like the way to go.

[Bitwolfies]

From what you've listed I see no need to keep it, if all we're really losing is some legacy browser support while gaining much faster speeds all around, I see zero reason not to go through with it.

[ThibaultNocchi]

Removing it won't improve the client speed magically. It'll "just" free us of some tasks that sometimes take a lot of times.

[ferferga]

Performance in SSR heavily depends on your connection and server's performance, while CSR only depends on the connection, and just for the initial load.

Your client's performance still play a key role.

[ferferga]

PR up at #1632