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

381–390 of 395 posts

Re: The absurd complexity of server-side rendering

#381

Post by midrus »

cersa8 wrote: post #362
midrus wrote: post #320

Earlier quoted context omitted.

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.

Isn't that the part where you as a developer step in? Most of these things are solved problems with mature libraries to integrate. I much rather mix and match then fight some all-in-one super framework that doesn't do quite what you need.

I think my job is to ship useful, secure and robust features to my company's customers. Dealing with technology is a consequence of that, not the end goal itself, which seems to be what's most wrong about this industry.

Certainly tying together libraries (or writing your own framework) is a valid approach, it's just a lot more expensive to reach the same quality level. That's why usually you end up with half assed solutions or never ending projects.

Re: The absurd complexity of server-side rendering

#382

Post by nawgz »

dbbk wrote: post #380
nawgz wrote: post #363

Earlier quoted context omitted.

You're right, it's a far superior pattern to waste tons of dev cycles to enable your team to give money to AWS so AWS can execute the logic their device would already do, just so your initial page load is 50% faster and your app otherwise performs identically, except the huge stutter step when you try to hydrate the state to match what your server rendered, which looks like hot garbage. HN is not full of front-ends,…

Your viewpoint is valid but it's a philosophical argument, not a pragmatic one. I'm also not sure what you mean by 'stutter step'. I would posit that 95% of visitors never even notice hydration.

> Your viewpoint is valid but it's a philosophical argument, not a pragmatic one.

I think not locking yourself to specific cloud architectures is quite pragmatic, but to each their own.

> stutter step

SSR advocates: parsing JS and interacting takes way too long, it's so noticeable and terrible!

Me: so if you serve a pre-rendered-via-SSR page AND a bundle of interactivity, there's going to be a nice set of static content that will be uninteractable during that entire terribly long parsing and loading phase?

SSR advocates: Never heard of such a thing, parsing JS and getting interactivity is instant!

Re: The absurd complexity of server-side rendering

#383

Post by hnov »

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'd say if it's timely content, e.g. you have a stream of comments flowing from the server to the client on a livestream then doing it all in JS is warranted, but the content has poor long-term value and indexing is pointless. Conversely if it's comments on Reddit, you can do any number of things that stop short of rendering everything in JS and I don't think your users will even notice.

I think the overarching theme is that you end up having to think about these things: if it was clear-cut we wouldn't even be having these discussions. Do you want to think about wiring event handlers to DOM elements rendered on the server or about how your JSX renders on the server vs browser? A similar conundrum exists in mobile development, do you want to be thinking about implementing everything twice in standalone iOS and Android apps or do you want to think about how to get Xamarin/ReactNative/Flutter to do the thing you want.

Re: The absurd complexity of server-side rendering

#384

Post by quickthrower2 »

etchalon wrote: post #370
quickthrower2 wrote: post #203

Earlier quoted context omitted.

SSR would make HN better under load when logged in, for example. When logged in you would get the cached versions like a logged out person, and then wait for user-specific content (and if it never renders, you can always just read).

As far as I can tell, HN is rendered on the server.

I meant SSR as in what nextjs does. Render on the server using front end tech, cache for performance and then rehydrate in the front end for up to date data.

They should have called it Server Side React Initial Rendering maybe :-)

Re: The absurd complexity of server-side rendering

#385

Post by nnain »

zabil wrote: post #276
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 find writing isolated unit tests tough when using htmx over the wire frameworks like HTMX and HotWire. The options are to mock the server and test the page, which is not exactly unit test. So I am curious is there an easy way to write unit tests for htmx bits of the page?

Same. Testing is an issue. I bought into the Hotwire idea on a recent project. But I can’t see how it’s any different then SSR + jQuery. They have some nice ideas, but it requires every team member to know the whole thing top to down. Backend engineers can’t always be burdened with taking care of HTML/templating/Writing JS specific functions. Feels almost wrong to me at how hard it has been sold.

Re: The absurd complexity of server-side rendering

#386

Post by account42 »

di4na wrote: post #318
wtetzner wrote: post #314

Earlier quoted context omitted.

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

Plus, no way for outside actors to trigger the rendering is great for security.

Re: The absurd complexity of server-side rendering

#387

Post by account42 »

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…

It's sad that the primary reason for making the site perform well is SEO and not the improved user experience.

Re: The absurd complexity of server-side rendering

#388

Post by rwallace »

jamal-kumar wrote: post #16
bob1029 wrote: post #11

I've been saying it for years - the hard part is not "server side" vs "client side", it's making sure the state stays consistent between those 2 buckets. If you want to remove the hell from your life, you need to be all in on one or the other. For us, we've been keeping all state server-side using things like Blazor and hand-rolled js-over-websocket UI frameworks. We never have to worry about more than ~10k users, so…

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…

I'm curious, what problems did you have with JavaScript math? I had the impression it was bog standard IEEE 754 same as every other language nowadays, but I have never tried doing any serious calculation in that language.

Re: The absurd complexity of server-side rendering

#389

Post by midrus »

DangitBobby wrote: post #114
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

It's a nice architecture when the API devs get to throw stuff over the fence to the frontend devs. It's less nice when you are the guy throwing stuff over the fence and then running around the fence to catch the stuff you just threw over it. It makes you start to wonder if there's anything you can do about the fence. The answer is "yes."

What an awesome metaphor, 100% agree with this. That's why I've always said that the SPA architecture with a separate backend is a way to increase the amount of work so that it can be distributed to more people/teams.

It baffles me when I see single developer or small team projects going for this.

Re: The absurd complexity of server-side rendering

#390

Post by 6510 »

tored wrote: post #342
6510 wrote: post #336

Earlier quoted context omitted.

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

Old pages had its charm. You can still use it with HTML5! If I remember correctly was that screen readers sometimes had some difficulty handling a page, especially if the were multiple s. is also great, but hard to layout horizontally. And resizing can be tricky. And nowadays you don't even need your own event layer to talk between frames, you can use postMessage. But yes, agree, continue evolve and such to become mo…

One can use postMessage but if everything lives on the same domain one can top.frames["left"] in stead of window and call functions or manipulate the dom.

You had me play with framesets for a bit.

   document.write((function(){switch(window.name){

     case "main": switch(location.search){
       case "?foo": return `Article text`;
       default: return `no article selected`;
     }

     case "menu": switch(location.search){
 case "?bar": return `List of 's`;
 case "?youtube": return ` list of  links`;

     default: return `
        
         
           
             
             
           
         `;

     }})());
I laughed so hard writing that.
Post reply on HN