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

331–340 of 371 posts

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

#331

Post by gonzo41 »

KronisLV wrote: post #329
kaba0 wrote: post #170

Earlier quoted context omitted.

Slightly off topic, but I found JSF the most productive out of any framework. It has some not so nice edge cases, but when you are “in the green” and you don’t need to scale to infinity (which, let’s be honest, is the case most often than not) it really is insanely fast to develop with. For internal admin pages I would hardly use anything else.

> Slightly off topic, but I found JSF the most productive out of any framework. In my experience, it has been a horrible technology (even when combined with PrimeFaces) for complex functionality. When you have a page that has a bunch of tabs, which have tables with custom action buttons, row editing, row expansion, as well as composite components, modal dialogs with other tables inside of those, various dropdowns or…

>When you have a page that has a bunch of tabs, which have tables with custom action buttons, row editing, row expansion, as well as composite components, modal dialogs with other tables inside of those, various dropdowns or autocomplete components and so on, it will break in new ways all the time.

Everything you're describing sounds like someone was able to create requirements for features without push back or thinking.

I think part of the design process is thinking and really asking, why do we have an editable table in a row, and how useful and core to our business is this.

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

#332

Post by ebiester »

Existenceblinks wrote: post #275
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.

I don't remember those as the good old days, especially on true web applications.

I remember more bugs than I'd care to recount with the back button and scope and that's not even talking about having to simultaneously think in JavaScript and your server side rendering language of choice.

I also think there is a lot of room for multiple choices. For web applications, I think server side rendering as a default is a poor choice. For information conveyance, I think server side, or even pure static sites, makes a lot of sense.

What problem are you trying to solve?

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

#333

Post by kaba0 »

KronisLV wrote: post #329
kaba0 wrote: post #170

Earlier quoted context omitted.

Slightly off topic, but I found JSF the most productive out of any framework. It has some not so nice edge cases, but when you are “in the green” and you don’t need to scale to infinity (which, let’s be honest, is the case most often than not) it really is insanely fast to develop with. For internal admin pages I would hardly use anything else.

> Slightly off topic, but I found JSF the most productive out of any framework. In my experience, it has been a horrible technology (even when combined with PrimeFaces) for complex functionality. When you have a page that has a bunch of tabs, which have tables with custom action buttons, row editing, row expansion, as well as composite components, modal dialogs with other tables inside of those, various dropdowns or…

I did meet a few bugs (though they were from a few PrimeFaces components), and the js interop is not too trivial, but otherwise I can’t share your experience.

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

#334

Post by throwawaymaths »

kaba0 wrote: post #325
throwawaymaths wrote: post #316

Earlier quoted context omitted.

By chuck away I mean all those processor cycles to perform cryptographic verification... And then throw away the result because you have to do it on the next connect anyways And I have written a library that does the full SSL handshake/upgrade cycle off of tcp sockets, and managed my own private CA, so I'm not a total idiot.

How is that different than all the other CSR SPAs that do a REST call on every button press as well? They do almost the same amount of work, and will also “throw away” the results.

It's not, but there are server side options (topic of op) where it's a websocket. I believe HTMx supports ws too, but gp was only talking about RESTful round-trips

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

#335

Post by rwalle »

WuxiFingerHold wrote: post #303

There are only few use cases, where the new kind of SSR (with hydration) is worth it. An example are e-commerce sites where you want the customer to see all your great products as soon as possible and then some seconds later to be able to interact with your side fluently to buy something. These kind of scenarios paired with low end devices are the only proper use case. And I say consciously "only proper" because SSR…

Thanks, exactly what I was going to say. This article seriously lacks context. Not many websites will benefit from going SSR.

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

#336

Post by rwalle »

superkuh wrote: post #231
forgotpwd16 wrote: post #112

Earlier quoted context omitted.

>when a website pushes computation to me for simple things like displaying text and images I close the tab How will you even know without looking at the source or blocking JS across the web? Like, sure, if they've fancy animations across all elements from the moment you open the page should be obvious. But what about something like https://rhodey.org/ ? It opens instantaneously in my ancient laptop connected to a ter…

I block JS across the web by default. For some sites I'll learn the miminum set of domains to allow for temporary whitelisting. But most aren't worth the effort.

Sure, great for you, but most websites and most developers don't care about use cases like this and always use JS to "enhance" the UI and UX, however you interpret it. They (supposedly) need to achieve basic accessibility but then do whatever they can in the UI. I don't think anyone would care about users who "disabling JS by default", at least now.

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

#337

Post by rwalle »

onion2k wrote: post #125
superkuh wrote: post #39

Earlier quoted context omitted.

I'm probably not in your target demographic but when a website pushes computation to me for simple things like displaying text and images I close the tab.

If a website is just showing text and images it shouldn't really be dynamically rendering anything anywhere. Write the content to static files during deployment and serve them.

"shouldn't"

Sorry to let you know that 99% of the websites on the Internet are not like this.

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

#338

Post by aatd86 »

simonhorlick wrote: post #323
WuxiFingerHold wrote: post #303

There are only few use cases, where the new kind of SSR (with hydration) is worth it. An example are e-commerce sites where you want the customer to see all your great products as soon as possible and then some seconds later to be able to interact with your side fluently to buy something. These kind of scenarios paired with low end devices are the only proper use case. And I say consciously "only proper" because SSR…

Have a look at Qwik, it’s a new framework from the author of Angular. It does SSR without the need for client-side hydration. It’s fast and immediately interactive. I’m really hoping it gains some momentum because I’d love to use it in some client projects.

Looks like a shiny new thing syndrome to me tongue-in-cheek ;)

It's claimed to be fast for "initial page load".

Remains to be seen if that's worth it for everything and if it remains as fast on subsequent navigations.

If third party scripts are the bottleneck, that probably has a marginal effect at best.

Partytown looks much more interesting to me.

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

#339

Post by KronisLV »

kaba0 wrote: post #333
KronisLV wrote: post #329

Earlier quoted context omitted.

> Slightly off topic, but I found JSF the most productive out of any framework. In my experience, it has been a horrible technology (even when combined with PrimeFaces) for complex functionality. When you have a page that has a bunch of tabs, which have tables with custom action buttons, row editing, row expansion, as well as composite components, modal dialogs with other tables inside of those, various dropdowns or…

I did meet a few bugs (though they were from a few PrimeFaces components), and the js interop is not too trivial, but otherwise I can’t share your experience.

That's perfectly fine, it might just be that the project had certain challenges in regards to complexity, or that the codebase might have been a bit peculiar.

But I think that's why it's nice to provide even single data points to a discussion sometimes.

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

#340

Post by KronisLV »

gonzo41 wrote: post #331
KronisLV wrote: post #329

Earlier quoted context omitted.

> Slightly off topic, but I found JSF the most productive out of any framework. In my experience, it has been a horrible technology (even when combined with PrimeFaces) for complex functionality. When you have a page that has a bunch of tabs, which have tables with custom action buttons, row editing, row expansion, as well as composite components, modal dialogs with other tables inside of those, various dropdowns or…

>When you have a page that has a bunch of tabs, which have tables with custom action buttons, row editing, row expansion, as well as composite components, modal dialogs with other tables inside of those, various dropdowns or autocomplete components and so on, it will break in new ways all the time. Everything you're describing sounds like someone was able to create requirements for features without push back or think…

> Everything you're describing sounds like someone was able to create requirements for features without push back or thinking.

This might be it! However, the composability of solutions still matters, for example, while I dislike certain other aspects of React, its approach to nesting components is a breath of fresh air, especially with JSX (as long as state management is manageable).

> I think part of the design process is thinking and really asking, why do we have an editable table in a row, and how useful and core to our business is this.

I might have structured that sentence badly: the tables had editable rows (say, the ability to edit contents in a row, like Excel, but only when an edit button is pressed, as well as sometimes other action buttons are present; which may or may not get interesting when you are doing that on multiple rows and have validations against already entered data), which might sometimes open modal dialogs. For example, if you need to select some data which doesn't quite fit into an autocomplete text field, you might bring up a modal dialog for selecting what you need, maybe have a search form and so on.

Personally, I'd say that development would often be easier regardless of technology, if requirements could be aligned with the available technologies (as well what can be done well and easily within them) and not vice versa. Then again, the final say is up to the poeople who are giving you money, so there's that.

Post reply on HN