Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The future (and the past) of the web is server side rendering

deno.com

Post reply on HN
Print view View original

291–300 of 371 posts

Re: The future (and the past) of the web is server side rendering

#291

Post by hamandcheese »

bigmattystyles wrote: post #164

If you don't do server side rendering, you don't (almost) automatically get a set of nice REST endpoints that return JSON/XML/ETC? I get that the abstraction might be nice for security, but at least for corporate intranet applications, a nicely structured, secured (e.g ODATA) webapi you query for client side rendering has the added benefit that it can be invoked programmatically with REST by other authorized parties.…

Getting an API for free is an anti-feature for all the temporarily-embarrassed monopolists on HN.

More seriously, though, it's nice to be able to just build without thinking too hard about if you're getting your abstractions perfect. To me, this is the main advantage of SSR - moving fast doesn't leave behind a wake of idiosyncratic APIs that need to be (carefully, dangerously) cleaned up later.

Re: The future (and the past) of the web is server side rendering

#292

Post by mixmastamyk »

robertoandred wrote: post #190
silver-arrow wrote: post #165

Earlier quoted context omitted.

Yes indeed! The core aspect, however, is that your server is returning fragments of html that htmx places in the DOM extremely quickly. They have pretty good examples on their site illustrating some "modern" UI patterns. As an example, you may have an HTML table on your page that you want to insert a new row for some reason on let's say a button click. You place some attributes that htmx understands on your button th…

Sounds pretty slow. At least a second before the UI responds to any action?

Same as a javascript round trip. Can still make local-only changes if you'd like.

Re: The future (and the past) of the web is server side rendering

#293

Post by b4je7d7wb »

berkle4455 wrote: post #268
robertoandred wrote: post #190

Earlier quoted context omitted.

Sounds pretty slow. At least a second before the UI responds to any action?

What sort of slow backends do you work with? My PHP htmx application responds in ~30ms including network transmit. Even if you’re across an ocean it’s maybe 300ms.

300ms feedback on user action is unacceptable. But I read another comment saying there can be loading indicators so in that case its fine.

Re: The future (and the past) of the web is server side rendering

#294

Post by recursive »

no_wizard wrote: post #247
recursive wrote: post #205

Earlier quoted context omitted.

I love the concept, but for my case, I'd need more granular filters. In particular, I only buy TVs that have analog audio outputs so I can hook them up to any speakers. That's a minority of TVs these days, but there are still a few around. Finding the good ones would be useful to me.

I assume that converters have negative side effects?

I'm unaware of their existence. I'm guessing they're big and expensive. Or maybe hard to get?

Re: The future (and the past) of the web is server side rendering

#295

Post by splistud »

rektide wrote: post #11
JohnFen wrote: post #3

If web sites have to so dynamic, I much prefer that the computation involved is done on their machine than on mine. I simply don't trust random web sites enough to let them run code on my machines.

What is it you dont trust? This Fear Uncertainty & Doubt clashes heavily with the excellent security sandbox the web browser is. What is the harm you are afraid of? What are you supposing the risk is/what's in jeapordy here?

[dead]

Re: The future (and the past) of the web is server side rendering

#296

Post by splistud »

stcroixx wrote: post #103
habibur wrote: post #80

Earlier quoted context omitted.

Another interesting question : are frontend developers jealous of what the backend developers are doing, or are they not?

I sure was when I had to do front end work. Finally got out of anything front-end for good and it's probably been the single most pleasant change in my career ever. I didn't start out doing front end work though, so I could see while I was doing it how ridiculous it was compared to almost any other domain in software dev and only getting worse. A good portion of front end devs I meet have not done anything else so th…

[dead]

Re: The future (and the past) of the web is server side rendering

#297

Post by Lio »

cafebean wrote: post #178
ketralnis wrote: post #171

Earlier quoted context omitted.

Is it though? Is composing a response into a graphql or JSON or XML format that much more expensive than into an HTML format? Is {"comment": {"body: "lol"}} notably expensive than

Web page design will have to fundamentally change to accommodate surgically updating web pages, for the large overhead to disappear.

This is so easy to do with Rails via https://hotwired.dev/

Anything that wouldn't require a round trip for data can be scripted pretty simply just using Stimulus.

I can't imagine it's any harder with any of the other server side technologies like Liveview, Blazor, etc.

Re: The future (and the past) of the web is server side rendering

#298

Post by lolinder »

hamandcheese wrote: post #291
bigmattystyles wrote: post #164

If you don't do server side rendering, you don't (almost) automatically get a set of nice REST endpoints that return JSON/XML/ETC? I get that the abstraction might be nice for security, but at least for corporate intranet applications, a nicely structured, secured (e.g ODATA) webapi you query for client side rendering has the added benefit that it can be invoked programmatically with REST by other authorized parties.…

Getting an API for free is an anti-feature for all the temporarily-embarrassed monopolists on HN. More seriously, though, it's nice to be able to just build without thinking too hard about if you're getting your abstractions perfect. To me, this is the main advantage of SSR - moving fast doesn't leave behind a wake of idiosyncratic APIs that need to be (carefully, dangerously) cleaned up later.

In my experience moving-fast SSR absolutely does leave behind a wake of idiosyncratic APIs that definitely need to be cleaned up later.

You still need client-server communication, so you still have an API, it's just an ad hoc API that speaks HTML and form data instead of JSON. And because you didn't think of it as an API while you were building it, it actually tends to be harder to clean up later, not easier.

Re: The future (and the past) of the web is server side rendering

#299

Post by achillean »

bigmattystyles wrote: post #164

If you don't do server side rendering, you don't (almost) automatically get a set of nice REST endpoints that return JSON/XML/ETC? I get that the abstraction might be nice for security, but at least for corporate intranet applications, a nicely structured, secured (e.g ODATA) webapi you query for client side rendering has the added benefit that it can be invoked programmatically with REST by other authorized parties.…

Why are those things mutually exclusive? You can have an API and then have a different app that uses that API with server-side rendering. I.e. instead of a client SPA you have a server app using the API.

Re: The future (and the past) of the web is server side rendering

#300

Post by fshr »

recursive wrote: post #294
no_wizard wrote: post #247

Earlier quoted context omitted.

I assume that converters have negative side effects?

I'm unaware of their existence. I'm guessing they're big and expensive. Or maybe hard to get?

What kind of outputs? Fiber to analog is about $15 and the size of two hockey pucks stacked.
Post reply on HN