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

251–260 of 395 posts

Re: The absurd complexity of server-side rendering

#251

Post by ryanbrunner »

trinovantes wrote: post #81
hnov wrote: post #59

Earlier quoted context omitted.

If you need SEO and (to a lesser degree) performance, you're likely serving content rather than an application and likely could've done with SOR (a new moniker I've come up with, Server Only Rendering).

Except that many applications have public content that you want to be indexed and interactive for the user e.g. forums and ecommerce

I've never seen an ecommerce or forums app that wouldn't be done better by more traditional techniques vs. an SPA. Interactive doesn't need to mean "driven entirely by Javascript", and also sites that use entirely HTML generated by a server can still use Javascript (there's even frameworks for this!)

Re: The absurd complexity of server-side rendering

#252

Post by tored »

diego_sandoval wrote: post #151

> After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found intimacy, the age of interactivity had begun. I didn't get the memo when this was decided, and I'm still unconvinced. Let me see if I get this straight: The main reason for client-side rendering is that some web applications don't want to do a full page reload ev…

One explanation could be that if you are a hammer everything looks like nail.

One problem with web dev in general is that we have multiple backend technologies, thus creating a complete client and server rendering framework requires you to integrate it against multiple backend technologies.

But if you assume that the best API is JSON over HTTP then you can completely ignore what makes sense from the perspective of the chosen backend technology.

Re: The absurd complexity of server-side rendering

#253

Post by victor9000 »

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?

Re: The absurd complexity of server-side rendering

#254

Post by tored »

6510 wrote: post #186
diego_sandoval wrote: post #151

> After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found intimacy, the age of interactivity had begun. I didn't get the memo when this was decided, and I'm still unconvinced. Let me see if I get this straight: The main reason for client-side rendering is that some web applications don't want to do a full page reload ev…

> 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.

Re: The absurd complexity of server-side rendering

#255

Post by fuzzy2 »

diego_sandoval wrote: post #151

> After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found intimacy, the age of interactivity had begun. I didn't get the memo when this was decided, and I'm still unconvinced. Let me see if I get this straight: The main reason for client-side rendering is that some web applications don't want to do a full page reload ev…

IMHO, this isn’t about “Modern JavaScript” or “JavaScript Culture” at all. It’s just $CURRENT_THING and the Cargo Cult is happy to oblige.

Futhermore, dev shops (like my employer) profit from selling overcomplicated solutions.

So in the end it’s just group dynamics that drive the usual hype cycle. Remember MVVM?

Re: The absurd complexity of server-side rendering

#256

Post by tonto »

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.

why do you think after 36 years, its htmx that is changing things

Re: The absurd complexity of server-side rendering

#257

Post by tored »

pphysch wrote: post #7
donatj wrote: post #5

Call me old fashioned, but PHP still gets the job done better than just about anything else.

And usually leads to a BBOM architecture

You can write BBOM in any language/platform/technology.

It is always the programmers that is the limitation, not the chosen technology. Thus you should pick technology that makes sense for the majority of programmers. PHP fits that. Just follow a guide to avoid BBOM.

Re: The absurd complexity of server-side rendering

#258

Post by danjac »

the_gipsy wrote: post #235
vecinu wrote: post #202

Earlier quoted context omitted.

> 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…

Do you realize that neither points justify SSR? You only need those because you introduced SSR. Anyway, there are webapps that fall between the highly interactive webapp examples of the GP, and static sites. With just enough interactivity that static + sprinkled JS becomes unmanageable. In that area I would really like to see a comparison between SSR (which everybody seems to jump on) and alternatives like... knockou…

Modern alternative would be for example AlpineJS+HTMX, or Turbo/Hotwire.

Re: The absurd complexity of server-side rendering

#259

Post by danjac »

vecinu wrote: post #221
danjac wrote: post #218

Earlier quoted context omitted.

"We built a very complex SSR framework so we can share code between client/server". Um, how many development hours did you save here?

Honestly that's difficult to quantify, if not impossible. The beauty of what we've done is that other microservices internal to our corp are also leveraging said SSR code and can bootstrap their own backend very quickly. We've been following the BFF pattern (Backend for frontend).

I know big SV companies have money to burn, but surely there was some project management in place to quantify the cost of building such a complex, in-house solution?

Re: The absurd complexity of server-side rendering

#260

Post by jefftk »

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…

> sometimes you cannot even use [SSR] - for example, if your code needs to know browser windows size to arrange objects on the page

It's been a very long time since I ran into a situation like that which wasn't best solved with CSS. Describe what you want to the browser and let it handle it for you.

Post reply on HN