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

331–340 of 395 posts

Re: The absurd complexity of server-side rendering

#331

Post by Daishiman »

robertoandred wrote: post #192
Daishiman wrote: post #167

Earlier quoted context omitted.

I have done nothing but backend for a decade. Docker's been around for the past 6 years and still going strong. Database? Postgres, always. You have to bend it so far until it breaks it's not even funny. If you need something else, you'll now. Backend lang? Python. Framework? Django. Need data munging? NumPy/SciPy/Pandas/PySpark. Need a really high speed component? C will do, Rust if you feel fancy. OS? Ubuntu, or De…

So React has been around longer than Docker? Good to know that frontend is on a slower treadmill than backend, which according to this thread has moved on to alpine or htmx or something else.

React's ideas of best practices and library ecosystem have sure changed way more.

Re: The absurd complexity of server-side rendering

#332

Post by dbbk »

etchalon wrote: post #64

I'm convinced SSR is only a thing because of Lighthouse scores. Client-side rendering with client-agnostic REST APIs is a fantastic architecture. But noooooooooo we can't have nice things

Let's say you're a mobile user on a 3G network, which a lot of our users are. With a SSR app (that's cached behind Cloudflare), they can see a document in about 100ms max.

With a fully client-side rendered app, you're talking multiple, multiple seconds while they're staring at a blank white screen.

Try it in real life and you'd quickly see your idea would be a terrible user experience.

Re: The absurd complexity of server-side rendering

#333

Post by dbbk »

nawgz wrote: post #44
Rauchg wrote: post #41

Since the post mentions Next.js, it's worth calling out two streams of ongoing work that solve major painpoints of SSR: 1. A filesystem convention (`*.server.ts`) for more cleanly separating client and server component trees 2. The introduction of a Web standards runtime[1] for SSR. If anything, we're entering the best generation of SSR ever. We'll see new generations of apps shipping less JS to the client, rendering…

Is it believed that you'll do less overall compute and bandwidth if you use serverless functions to execute (parts of your) client, in place of sending static bundles to the client and letting them execute it? I don't really get SSR. Isn't it more desirable to have more of the compute required to render the client done by the client machinery? I view this both as true in corporate and public web scenarios, surely it'…

Doing something fully on the client is a nice idea, if your users all have fast connections, high processing power, and are all visiting from a desktop instead of a mobile device.

As soon as you have anyone visiting on a mobile device, and particularly on a mobile network, it's far superior to render it on the server.

Re: The absurd complexity of server-side rendering

#334

Post by dgb23 »

midrus wrote: post #315
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.

Especially the web sites that get built by developers are almost by definition "something in between" or more. It's the reason they need developers in the first place. As soon as it needs to have anything bespoke and is updated by non-technical people it is a web app anyways. If not they could use a pre-built no-code solution.

Re: The absurd complexity of server-side rendering

#335

Post by ryathal »

pjmlp wrote: post #292
dinkleberg wrote: post #165

Earlier quoted context omitted.

I can’t speak to the decisions on the parts of whoever is building the frameworks. But I will say the dev experience working on a frontend app using React, Vue, etc. is substantially greater than using something like Django templates. And I say that as someone who has written a great deal of both. I really wish I could be as productive in Django templates as I am with React, but alas. Once you go to component based U…

JSF and WebForms were already component based UIs 20 years ago, with page designers at development time, and 3rd party component vendors!

Honestly I wouldn't be surprised if web forms could also provide a faster and more user friendly experience even with all the page loads than some SPAs.

Re: The absurd complexity of server-side rendering

#336

Post by 6510 »

tored wrote: post #254
6510 wrote: post #186

Earlier quoted context omitted.

> The main reason for client-side rendering is that some web applications don't want to do a full page reload every time that there's a non-trivial state change (usually triggered by user interaction). If that is the reason (I don't know) some element other than would be a much simpler solution. I had a few ideas just now. It seemed the most fascinating to tie part of the query string to a div. Then you have your usu…

Basically what turbolinks did.

Or what 99% of ajax did. What I really want to see is for html to work toward what people are actually doing with web pages.

I basically want a lawnmower not a bag of parts that allows me to build my own. I know how to sort tables but I don't want to. I know how to dynamically xhr, display and insert auto complete values but I don't want to write it and I don't want the chunk of js on the page. I definitely don't want to load a library for it.

Re: The absurd complexity of server-side rendering

#337

Post by gmfawcett »

eurasiantiger wrote: post #322
gmfawcett wrote: post #100

Earlier quoted context omitted.

That's good, I think? I'm not claiming that Laravel was the first or the best PHP framework, just that they were using it. (Admittedly I assume it's a reason their code is so well organized.)

Laravel inherits its organisation from the underlying Symfony 2 framework, just like Drupal nowadays.

Thanks, I didn't know that.

Re: The absurd complexity of server-side rendering

#338

Post by fatbird »

fatbird wrote: post #213
dimgl wrote: post #183

Earlier quoted context omitted.

I think you're confused as well. Most frameworks that provide any kind of HTML rendering method can do server-side rendering. The trickiness is making them isomorphic. > the other is the definition of leaky and crappy abstraction Well that's just like, your opinion man.

You're not wrong , dimgl, you're just an asshole.

Clearly this generation needs a refresher on The Big Lebowski.

Re: The absurd complexity of server-side rendering

#339

Post by jamal-kumar »

petrocrat wrote: post #149
jamal-kumar wrote: post #16

Earlier quoted context omitted.

Even in smaller applications this is incredibly relevant. I've recently written something that's meant to interface on a local area network, just controlling something on another computer, literally just one or two users at a time -- thing is the precision of floating points are a big thing here, and we have to consider that. So all of the bignum stuff had to stay server-side in C++ after much messing around doing ma…

Did you try to use javascript's BigInt data type?

I clearly stated we were working on floating points here, ones originally provided by the c++ application.

There was a thought to just make everything into big integers here but for this particular application it really just was the realization that all of this stuff was better off server side anyways for state maintenance reasons

Re: The absurd complexity of server-side rendering

#340

Post by pjmlp »

ryathal wrote: post #335
pjmlp wrote: post #292

Earlier quoted context omitted.

JSF and WebForms were already component based UIs 20 years ago, with page designers at development time, and 3rd party component vendors!

Honestly I wouldn't be surprised if web forms could also provide a faster and more user friendly experience even with all the page loads than some SPAs.

It can indeed, and now there is Blazor as its replacement.
Post reply on HN