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

341–350 of 395 posts

Re: The absurd complexity of server-side rendering

#341

Post by jamal-kumar »

andai wrote: post #209
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…

Recently I've been dabbling in developing online multiplayer games. After some agony trying to make the chaos go away (rewinding time, merging conflicting physics states...), I realized I could actually harness it by re-framing the product from something serious into something lighthearted (eg. making goofy physics the whole point of the game). At worst, it lowers the expectations (eg. relative to something serious/c…

I mean as long as you can keep it from crashing completely? Sounds fun

Re: The absurd complexity of server-side rendering

#342

Post by tored »

6510 wrote: post #336
tored wrote: post #254

Earlier quoted context omitted.

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

Re: The absurd complexity of server-side rendering

#343

Post by DangitBobby »

grey-area wrote: post #210
DangitBobby wrote: post #155

Earlier quoted context omitted.

I've read the article. The pain points exist, but they are not insurmountable. I'd go as far as to say they are being a bit dramatic.

Compared to traditional server side rendering, the article describes a hellscape of self-imposed complexity. Why would anyone choose this?

You choose something like react for the frontend if you need heavy interactivity, something closer to a desktop application than a traditional web app. Then you choose tools like Next.js that will do SSR for you so you can take advantage of how good browsers are at rendering HTML.

Re: The absurd complexity of server-side rendering

#344

Post by krapp »

tored wrote: post #307
slim wrote: post #227

Earlier quoted context omitted.

you're right. it was obvious when we started seeing templating engines for php while php is itself a templating engine

Only thing missing from PHP now is to programmatically detect tainted strings, i.e. strings that are dangerous like user input, if we had that we could continue with the built in templating and still be sure to escape output at the correct moment. Tainted strings should be built into PHP (there was an RFC for it but it didn't pass). Another solution could be using operator overloading instead (that RFC didn't pass ei…

Or do what Hack did with XHP and make XML/HTML a part of the language, and escape everything else by default. That was the one Hack feature PHP should have taken, but didn't.

Re: The absurd complexity of server-side rendering

#346

Post by emteycz »

jiggawatts wrote: post #172
ryan_lane wrote: post #147

Earlier quoted context omitted.

Have you worked on one of these products before? I worked for Wikimedia Foundation, and it's not trivial to generate the pages statically. The content itself is wikitext, not html. It'd derived from content, templates, and meta-templates. Quite a bit of the data comes from other sources, like wikidata, or commons. You need to display things differently based on logged-in vs logged-out status. Through lots of layers o…

Yes, I have worked with these products at a moderately large scale. I have also developed a wiki-like CMS from scratch myself, with templating, macros, and everything. The issues I saw would occur at any scale above "tiny". Essentially as soon as scale-out is needed for a dynamic site, caching also becomes mandatory. Caching is not well understood at all . People think they understand it, but probably don't actually…

Many good points, but doing static sites like you do is an entire field of itself and not very well understood too, and you must expect some resistance from people who just want to carry on doing whatever they're doing.

What you write about caching rings especially loudly. Static sites indeed are a very interesting solution to these problems.

Re: The absurd complexity of server-side rendering

#347

Post by ConsoleTVs »

midrus wrote: post #326
grey-area wrote: post #206

The original server side rendering (HTML rendered on the server by your choice of language) is simple, efficient and most sites on the internet still use it, including this one. The article is talking about ‘modern’ js style server side rendering combined with client side rendering, which is of course a huge dumpster fire and encourages absurd complexity on both sides of the equation, starting with the fact the app i…

It's mind boggling some people don't know you can render plain html on the server, or even submit forms without javascript. Such a basic building block seems to be fading away nowadays, even some times presented as a "novel" thing or a "feature" (eg: remix)

We've gone full circle in JS-land already, and it will keep going. In circle...

Re: The absurd complexity of server-side rendering

#348

Post by nawgz »

chrisco255 wrote: post #173
nawgz wrote: post #79

Earlier quoted context omitted.

> Similarly, a serverless function that is "warm" already has all the logic needed to inject the static template into memory Sure, I accept this. > It simply needs to call out to the database, which is physically closer to the server, and always quicker, without the need for an additional HTTP handshake I contest all three parts of this. * physically closer How can this be guaranteed? You have no control over the clo…

> * physically closer > How can this be guaranteed? You have no control over the closest Edge function vs Cloud Server to the user. Because the user doesn't get to talk directly to the database. The database could be on the second floor of the user's building, but it's still going to have to get routed via an API. If you're using serverless functions for your API (presumably so, given this conversation), you still ha…

> > * physically closer > > How can this be guaranteed? You have no control over the closest Edge function vs Cloud Server to the user.

> Because the user doesn't get to talk directly to the database. The database could be on the second floor of the user's building, but it's still going to have to get routed via an API.

But the API is colocated with the database in any sane setup. You're trying to argue "the extra hops can add up significantly", when using the plural is straight up illegal - it is at most 1 hop more than via Edge - and you still never satisfied how the Edge is "closer" to the database...

> If you're using serverless functions for your API (presumably so, given this conversation)

It's like you're not even listening to me... Cloud vendor lock-in, in this thread via serverless or Edge, is worthless. It has no benefits. You've tried for 4 comments to find 1 and you haven't.

> A true Edge function has nearly 0ms latency to spin up from cold

> Lambda as a pricing comparable

You're right, I'm sure they just fixed the top issue with Lambda, did it with no extra costs, and are passing true pricing onto you as they try to aggressively grow. No risk here.

Did you know it actually costs no extra money per request to an already running server instance? Incredible.

> Trying to describe how webpage rendering works after you failed

Not interested, you completely missed the point that BI applications are going to be long-running, therefore initial startup time - the literal only gain of SSR - is virtually irrelevant, and when you look at the median request issued by their app, by virtue of it being long running, your SSR only saved you time on the initial requests out of an arbitrarily large set of them. Your average request savings are epsilon defined on session length

> A BI dashboard is an excellent use case for SSR, because it has multiple independent components that draw data from multiple API endpoints

> This is precisely where SSR shines

Again, you failed to defend how Edge / SSR are "closer to the database" (because they're not), and now you're trying to argue SSR is going to load API endpoint data faster again? Come on man

I'm done with this, you were given explicit examples to work against and you just talk past my technical objection. I'm genuinely offended you are trying to say I'm the one with "cognitive dissonance" here when you sound like a cloud spokesman and can't actually defend clear technical details. Bye, enjoy giving your money to cloud companies and your time to fitting into their lock-in architectures

Re: The absurd complexity of server-side rendering

#349

Post by Zababa »

christophilus wrote: post #274
jwr wrote: post #269

I've been using server-side rendering for many years now and I find it to be almost zero overhead at this point. Yes, I had to do some initial work to set things up, but these days I don't even remember it's there. Most people make an assumption that in order to have SSR you need to run JavaScript (e.g. Node most of the time) on your backend. That is not a valid assumption. I think the title of the article could bene…

This is a really nice combo, I agree. But… I think it’s safe to say it’ll probably remain niche forever. I wish there were more stacks like Clojure/Script. While I’m wishing, I’d love to have a modern ML with simple tooling, a good stdlib like Go (with a high performance http server baked in), and a good full stack story that doesn’t produce a 1MB “hello world”, and doesn’t require 1K dependencies. Does anyone know w…

> While I’m wishing, I’d love to have a modern ML with simple tooling, a good stdlib like Go (with a high performance http server baked in), and a good full stack story that doesn’t produce a 1MB “hello world”, and doesn’t require 1K dependencies.

I don't have anything close, but I would like the exact same thing. Especially since OCaml and F# both have JS compilers, you could easily have a fullstack app written with this language. I think your best bet might be either OCaml or F# these days if the ML part is the most important one, or Go if the rest is the most important part.

Re: The absurd complexity of server-side rendering

#350

Post by 5560675260 »

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?

It's for people that hate cascading part of CSS, people that never really took time to learn CSS, and people that got burned by an unmaintainable 5k+ line CSS file so hard that they want to jump to another extreme.
Post reply on HN