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

11–20 of 395 posts

Re: The absurd complexity of server-side rendering

#11

Post by bob1029 »

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 this works out great for us.

If we were webscale, we'd have to consider client side options.

Re: The absurd complexity of server-side rendering

#12

Post by robertoandred »

Daishiman wrote: post #2

The complexity of web development frontend itself is just absurd. The mess of dependencies, the mess of language transpiling, opaque abstract functions with unreadable call stacks, asset management, sync vs async, the random best practice of the week, etc. I look at the state of web pages and apps and it's not even for the betterment of user experience! Hacker News and old.reddit.com still provide the smoothest, fast…

I take it you haven't taken a look at backend lately. Vagrant? Or Docker? Composer? Maybe Drush. Will this plugin break? Is it even still actively maintained? Which database? Are we still on the NoSQL fad? Maria, or postgres or mysql? And does my production host support my language version, and oh god another php vulnerability

Re: The absurd complexity of server-side rendering

#13

Post by gmfawcett »

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

I have colleagues using Laravel, and there's nothing muddy-ball about their apps at all. Their code is tidy, modern, readable, and clearly maintainable.

In terms of practical effect, frameworks influence developers more than languages do.

Re: The absurd complexity of server-side rendering

#14

Post by jvanderbot »

I opened this thinking it would lament the challenges of server side frameworks and templating.

But those things seem so, so sane and simple compared to the mess I just read about. It's worse than I could have imagined.

Who thinks that's a good workable solution? Who's idea was this?

Re: The absurd complexity of server-side rendering

#15

Post by gmfawcett »

robertoandred wrote: post #12
Daishiman wrote: post #2

The complexity of web development frontend itself is just absurd. The mess of dependencies, the mess of language transpiling, opaque abstract functions with unreadable call stacks, asset management, sync vs async, the random best practice of the week, etc. I look at the state of web pages and apps and it's not even for the betterment of user experience! Hacker News and old.reddit.com still provide the smoothest, fast…

I take it you haven't taken a look at backend lately. Vagrant? Or Docker? Composer? Maybe Drush. Will this plugin break? Is it even still actively maintained? Which database? Are we still on the NoSQL fad? Maria, or postgres or mysql? And does my production host support my language version, and oh god another php vulnerability

There's maybe two of those questions that you actually have to care about as an architect. Nobody's forcing you to chase fashions except you.

Re: The absurd complexity of server-side rendering

#16

Post by jamal-kumar »

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 math client side in javascript only to learn the hard way how completely broken that is. Fun fact - You can't maintain state when floats start to drift off of values they were supposed to land on due to javascript's crappy math libs

Re: The absurd complexity of server-side rendering

#17

Post by pphysch »

jvanderbot wrote: post #14

I opened this thinking it would lament the challenges of server side frameworks and templating. But those things seem so, so sane and simple compared to the mess I just read about. It's worse than I could have imagined. Who thinks that's a good workable solution? Who's idea was this?

Adtech needs a lot of JS to work. JS to determine how long they are hovering over this and that element, how long this or that ad is in their view, and so on and so forth.

The logical conclusion is that every single HTML element needs to be wrapped in a bit of JS somewhere. Nothing should happen in the users browser that can't be monitored by JS.

Re: The absurd complexity of server-side rendering

#18

Post by [deleted] »

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…

[deleted]

Re: The absurd complexity of server-side rendering

#19

Post by kraig911 »

I gave it a shot at one startup using next.js that wanted to pre-hydrate redux state, but also use tracking with session cookies et al the regular bag of beans. I spent maybe 6 weeks on it and basically I grew to realize I was in a miasma of pain. I didn't last much longer. I could've wrote the entire thing just vanilla js/css in probably a weekend...

So I can commiserate with this.

Re: The absurd complexity of server-side rendering

#20

Post by stickfigure »

SSR feels like an echo of JSF (that's JavaServer Faces for you youngins) - an exceptionally complicated way of doing simple things. IMO, SSR will follow the same arc in history - a brief period of popularity, followed by a lot of "what on earth were we thinking". Client side rendering is much simpler and cleaner.
Post reply on HN