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

271–280 of 371 posts

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

#271

Post by [deleted] »

throwawaymaths wrote: post #256
BizarreByte wrote: post #219

Earlier quoted context omitted.

It’s much faster than that in practice, but of course it comes down to how well your backend is written. I’ve been using HTMX lately and I can blink and miss the UI updates. I wish I had numbers, but in my experience it’s far better than you’d expect. Basically take the length of a REST call you’d have to make anyway and add a few milliseconds for the rendering. It won’t be the right choice in all cases, but it’s a g…

It seems such a waste... You're chucking all that cryptography (ssl, encrypted cookies) away only to be redone every. single. Dom change

[deleted]

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

#273

Post by chrischen »

cutler wrote: post #269

What on earth does this tangled mess "simplify"? I've been at it with web dev for over 20 years and I was left scratching my head. The trouble with going down the JS rabbit hole is that you lose perspective on simplicity. **d help us if this becomes the new hotness. Oh, wait it already is. Oh well, until next month ...

Simplicity is a facade. Great experiences are often complex behind the scenes. The JS ecosystem just tends to splay things open so the complexity is visible.

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

#274

Post by movedx »

throwawaymaths wrote: post #256
BizarreByte wrote: post #219

Earlier quoted context omitted.

It’s much faster than that in practice, but of course it comes down to how well your backend is written. I’ve been using HTMX lately and I can blink and miss the UI updates. I wish I had numbers, but in my experience it’s far better than you’d expect. Basically take the length of a REST call you’d have to make anyway and add a few milliseconds for the rendering. It won’t be the right choice in all cases, but it’s a g…

It seems such a waste... You're chucking all that cryptography (ssl, encrypted cookies) away only to be redone every. single. Dom change

Huh? How does HTMLx "chuck" away SSL (you meant TLS, right? I hope you're not using SSL) and encrypted cookies?

How about you try it and see?

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

#275

Post by Existenceblinks »

cutler wrote: post #269

What on earth does this tangled mess "simplify"? I've been at it with web dev for over 20 years and I was left scratching my head. The trouble with going down the JS rabbit hole is that you lose perspective on simplicity. **d help us if this becomes the new hotness. Oh, wait it already is. Oh well, until next month ...

I still don't get it. We went from great backend languages with widgets approach on frontend to letting the whole shiny thing taking over the whole system and impose weakness here and there in architecture. My theory is that incompetent technical leads or CTOs reading too much tech twitter but not immune to all the echo bullshit.

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

#276

Post by uneekname »

cutler wrote: post #270
duncan-donuts wrote: post #260

Earlier quoted context omitted.

I just started using htmx in a new personal project. I’m pretty excited to see how it goes. I’m doing a sort of back to basics stack with PHP, simple classless css lib and htmx. So far it’s been a refreshing experience

"classless css lib" ??

Not op but classless CSS frameworks are awesome. The idea is to keep it simple and use the appropriate HTML tags where there were generally meant to go, and the framework will theme the page to improve usability and add flair. I've developed some great little sites with no classes at all!

Obviously this approach has its limits, but it works well for proof-of-concept sites or sites that don't need to be very complex or dynamic. Just a sensible font size, nicer looking form elements, etc.

Here is a list of classless CSS frameworks: https://github.com/dbohdan/classless-css

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

#277

Post by 1123581321 »

cutler wrote: post #270
duncan-donuts wrote: post #260

Earlier quoted context omitted.

I just started using htmx in a new personal project. I’m pretty excited to see how it goes. I’m doing a sort of back to basics stack with PHP, simple classless css lib and htmx. So far it’s been a refreshing experience

"classless css lib" ??

It's a CSS stylesheet you include in every page/view. You don't add any classes to your HTML and rely on the defaults of that stylesheet to style the semantic markup. If those defaults are good for your project, and you have some command of HTML elements beyond using divs and spans for everything, it saves a lot of time.

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

#278

Post by BizarreByte »

amelius wrote: post #259
BizarreByte wrote: post #219

Earlier quoted context omitted.

It’s much faster than that in practice, but of course it comes down to how well your backend is written. I’ve been using HTMX lately and I can blink and miss the UI updates. I wish I had numbers, but in my experience it’s far better than you’d expect. Basically take the length of a REST call you’d have to make anyway and add a few milliseconds for the rendering. It won’t be the right choice in all cases, but it’s a g…

> but of course it comes down to how well your backend is written Also the latency of your connection matters.

I thought frontend devs stopped caring about bad connections years ago? ;)

HTMX is fine with showing loading icons are the like if needed, but yah, connection latency is going to have an effect.

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

#279

Post by devin »

movedx wrote: post #274
throwawaymaths wrote: post #256

Earlier quoted context omitted.

It seems such a waste... You're chucking all that cryptography (ssl, encrypted cookies) away only to be redone every. single. Dom change

Huh? How does HTMLx "chuck" away SSL (you meant TLS, right? I hope you're not using SSL) and encrypted cookies? How about you try it and see?

It’s fine to use SSL interchangeably with TLS IMO. It’s still called OpenSSL.
Post reply on HN