Live data from Hacker News

The absurd complexity of server-side rendering

gist.github.com

391–395 of 395 posts

Re: The absurd complexity of server-side rendering

#391

Earlier quoted context omitted.

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.

The reason this approach lost to dynamic rendering is the absence of any sort of logic that would rebuild _only_ updated pages.

The job of many, many web sites is to make it easy for people to add content to them. When adding something takes many minutes, the web site is doing its job poorly.

Things are around today that are fast and that even offer the logic I refer to above, but the ship has sailed. We largely live in a world of cached pages that are changed via a complicated database-driven CMS.

Re: The absurd complexity of server-side rendering

#392
post #83

Earlier quoted context omitted.

Yes it’s cheaper but also it’s a worse experience. It’ll take longer for a user’s crappy android phone to render your page from source than for a beefy cloud server on the edge to do the same.

> It’ll take longer for a user’s crappy android phone to render your page from source than for a beefy cloud server on the edge to do the same. Yes, if you pay more money and integrate into cloud vendor systems, you can get more compute. Besides, the person with a crappy android is irrelevant to monetizing your application anyways, so their user experience is pretty irrelevant surely? I don't really understand the id…

- depending on use case you don’t need to pay much to get these perf benefits (eg caching snapshots on CDNs)

- monetization depends on your business. How about B2B where customers are employees using crappy corporate laptops. Not like the only high value customers are using high end computers.

- and besides maybe you have ethics and don’t want to lock out people who don’t have the latest high end gear.

- flawless isn’t the point, better is the point

Re: The absurd complexity of server-side rendering

#393
post #185

Earlier quoted context omitted.

Remix has the exact same issue unfortunately: https://remix.run/docs/en/v1/guides/constraints

This actually bit me multiple times. I started leaking server-side code to the client, which completely turned me off. Also I've been in several arguments with Remix community members as to why middleware is necessary for server-side frameworks and why there needs to be a global state option. I was going to evangelize them at my current gig... thankful that I didn't go down that route and made my own prototypes. Ther…

I'm very interested to hear more about those arguments w/ the Remix community; got links to share?

Re: leaking server code to the client, so far I've been well-served by the recommended preventative measures: audits for inadvertent side-effects, and/or ".server.tsx" filenames as needed. But your experience here may be more extensive. Could you expand on "made my own prototypes"?

Re: The absurd complexity of server-side rendering

#394
post #340

Earlier quoted context omitted.

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.

Or https://Remix.run

Re: The absurd complexity of server-side rendering

#395
post #186

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

This mapping of URL segments to areas of a page is precisely what Remix (and React Router v6) achieve with "nested routes". I used to denigrate React router's "routes as components" approach, but completely changed my mind with tbe advent the of nested routes as implemented by Remix; it's profoundly powerful, intuitive, performant, etc.
Post reply on HN