Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The absurd complexity of server-side rendering

gist.github.com

Post reply on HN
Print view View original

311–320 of 395 posts

Re: The absurd complexity of server-side rendering

#311

Post by midrus »

The moment you need SSR, you'd be in a better place if you were using just plain old server rendered (componetized) views, such as the ones you can do with laravel's Blade system, and do your client side interactions with Alpine and your server interactions with unpoly/HTMX.

SSR per se is not a "big problem", specially if using something like Next. The problem comes when you have to mix in translations, i18n, data fetching from external sources, authentication, cookies forwarding, etc, etc, etc... in my opinion complexity grows so exponentially that I don't see the advantage anymore.

I'm working on a project built with Laravel + Tailwind + Unpoly + Alpine and it is such a walk in the park to implement anything thrown at us. Although it is not "cool" tech, so some people around here don't want to work on it because they only want React all the things :-s

Re: The absurd complexity of server-side rendering

#312

Post by midrus »

codedokode wrote: post #38

There are cases when server-side rendering (without SPA) is easier and faster. For example: documentation sites, blog-like sites, internet stores, sites like Hacker News. In all these cases, you can save on development time by writing just one application instead of two (server and client), and improve performance (no need to load multimegabyte JS applications and make multiple AJAX requests to display a page). Of co…

But it is trendy and fashion, so we still do it

/s

Re: The absurd complexity of server-side rendering

#313

Post by midrus »

vecinu wrote: post #202
codedokode wrote: post #38

There are cases when server-side rendering (without SPA) is easier and faster. For example: documentation sites, blog-like sites, internet stores, sites like Hacker News. In all these cases, you can save on development time by writing just one application instead of two (server and client), and improve performance (no need to load multimegabyte JS applications and make multiple AJAX requests to display a page). Of co…

> So I think that SSR (running JS on server) is rarely useful. I would disagree for a couple of reasons. The team I work with at a large SV company built a very complex SSR framework for our mostly static app for 2 reasons: - Isomorphic codebase, you can share the majority of your code with the client/server since it's Node on the backend and ES2015 on the frontend - SEO. Google penalizes your site for slowness and m…

> Isomorphic codebase, you can share the majority of your code with the client/server since it's Node on the backend and ES2015 on the frontend

I've been working for 20 years on this, last 8 ~ 9 only with node and React and not a single time, other than sharing some validation rules and/or for SSR, got anything useful out of having the possibility of running the same code in the browser and on the server... totally different responsibilities, libraries, requirements and environments.

Re: The absurd complexity of server-side rendering

#314

Post by wtetzner »

di4na wrote: post #194
KorematsuFredt wrote: post #142

Earlier quoted context omitted.

I had a website which I was rendering statically using Jekyll. Overtime I had millions of pages, rendering was getting too time consuming and was taking up far too much of space. I then moved on to PHP. Worked like a charm with $15/mo server on Google cloud. Excellent search performance as well.

I would point out that this is not the hit you think at SSG but at their current build system. You could imagine a distributed build system for this that would build it really fast for competitive price on any ci/lambda/batch system. The fact we barely hear anyone talk about this is the strange twist of history the parent made.

But at that point, what exactly are you gaining?

Re: The absurd complexity of server-side rendering

#315

Post by midrus »

franze wrote: post #279

I make a difference between website and webapp. a website is a collection of webpages, where the maingoal is to display some mostly static information (i.e. an article) a webapp has the main goal of managing and reacting to a complex, non trivial user state. website, go server side all in, do not add the tax of client side rendering / hydration to the frontend. if necessary embed small enclosed client side webapps on…

> I make a difference between website and webapp.

Everyone says this, which doesn't solve anything. 99,9% of what we build is just something in between. It is not as easy as you make it look like.

Re: The absurd complexity of server-side rendering

#316

Post by midrus »

geenat wrote: post #120

https://htmx.org/ Having spent 36+ years in the computer industry, I consider the advent of htmx to be the first thing in web development to to attempt to pull the industy's head out of it's ass. Don't forget to include a solid remake of css in your project like tailwindcss. It also makes code much more readable.

Don't forget Unpoly! A bit more opinionated and "batteries included" than HTMX, still same ideology. I use it every day and I love it.

Re: The absurd complexity of server-side rendering

#317

Post by midrus »

victor9000 wrote: post #253
geenat wrote: post #120

https://htmx.org/ Having spent 36+ years in the computer industry, I consider the advent of htmx to be the first thing in web development to to attempt to pull the industy's head out of it's ass. Don't forget to include a solid remake of css in your project like tailwindcss. It also makes code much more readable.

I have never really understood the purpose of tailwindcss. It's main benefit seems to be that it exposes CSS rules using classes. Then I have to add a mountain of classes to my html. Am I missing something?

A lot.

https://blog.jannikwempe.com/debunking-tailwind-counterargum...

https://www.swyx.io/why-tailwind

And many similar ones.

Re: The absurd complexity of server-side rendering

#318

Post by di4na »

wtetzner wrote: post #314
di4na wrote: post #194

Earlier quoted context omitted.

I would point out that this is not the hit you think at SSG but at their current build system. You could imagine a distributed build system for this that would build it really fast for competitive price on any ci/lambda/batch system. The fact we barely hear anyone talk about this is the strange twist of history the parent made.

But at that point, what exactly are you gaining?

Lower cost, better use of hardware, better scalability, easier debugging, more robustness to failure, etc etc

Re: The absurd complexity of server-side rendering

#319

Post by midrus »

toastercat wrote: post #162
geenat wrote: post #120

https://htmx.org/ Having spent 36+ years in the computer industry, I consider the advent of htmx to be the first thing in web development to to attempt to pull the industy's head out of it's ass. Don't forget to include a solid remake of css in your project like tailwindcss. It also makes code much more readable.

What's the difference between this and AlpineJS?

I use Unpoly (equivalent to HTMX for your question) + Alpine and they complement each other very well.

Unpoly handles everything that requires what in SPA world would be an "API call", the difference is that the response I get is just the HTML with the data already rendered and which is dynamically updated in the DOM. Also Modals and page transitions Turbolinks style are handled by Unpoly.

Alpine handles everything that doesn't require a server API call, such as form wizards steps, dropdowns, tables filtering, sidebars, buttons loading/disabled states, etc.

The end result, the application "feels" like Github.

Re: The absurd complexity of server-side rendering

#320

Post by midrus »

cersa8 wrote: post #271

Do I live in a parallel universe where building SSR/SPA sites with Next.js is somehow incredibly complex? I know below the abstractions there is complexity, but building SSR rendered SPA's today with something like Next.js has never been more simple. I think web development has taken a huge leap forward where we now have stable tooling, a strongly typed language with TypeScript and top notch boilerplate free state ma…

Next.js is easy peasy and lovely and wonderful until you need to mix in validations + translations + authentication + authorisation + calling upstream APIs with user's credentials + ...

That's when you realise using what would be a perfect framework for building landing pages might not be the best one to build a full web application.

Post reply on HN