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

351–360 of 371 posts

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

#351

Post by ranger_danger »

rightbyte wrote: post #105
rektide wrote: post #11

Earlier quoted context omitted.

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?

JS allows for fingerprinting. I only run JS on a opt-in basis on like my bank and some pages I trust. You don't miss much really. https://amiunique.org/fp

actually most people will miss out on most of the usable internet without javascript. not everyone goes to the same sites as you or has the same browsing patterns.

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

#352

Post by ranger_danger »

boring_twenties wrote: post #304
rightbyte wrote: post #105

Earlier quoted context omitted.

JS allows for fingerprinting. I only run JS on a opt-in basis on like my bank and some pages I trust. You don't miss much really. https://amiunique.org/fp

"Has JS disabled" is in itself a good fingerprint factor though.

how would a website inform the server of that fact though?

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

#353

Post by Valgrim »

mmcnl wrote: post #344
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…

> SSR is always slower than static sites I don't think this is _always_ true. With SSR you only render the HTML server-side on the first page load. Any interaction after that is just the JSON payload being retrieved and rendered by a JS framework, which is faster than a complete rerender. Your comparison is valid for first page loads. But usually people visit multiple pages on a website. And then SSR usually wins, th…

Usually people visit multiple pages? I think this is a 90-10 situation. 90% of the sites I visit, I reach a web page through another website, either a aggregator or a search engine, and I almost never navigate that website. Those could be purely static for all I care.

The remaining 10%, where I stay 90% of the time, could benefit from a mostly static interface with a tiny amount of server-side rendering.

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

#354

Post by 0x445442 »

The problem is more fundamental and it’s this; web apps are broken and have been from the beginning. They were created to solve the problems related to software distribution and updates but these problems were solved in the early 2000s when broadband became prevalent and it was no longer painful to download large software packages.

The early straw man was that downloading apps was too daunting a task for users and yet some how they managed to download and update email clients, word processors, iTunes and ironically browsers themselves.

Since I began my career in 1995 I’ve seen application architecture pundits proclaim the correct way to develop applications go from thick client native to thin client native to thin client web to thick client web back to thick client native (iOS & Android) and now, according to the article back to thin client web. I’ll submit the best model is thick client native using the “web” as a communication backbone for networked features.

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

#355

Post by guhidalg »

mkl wrote: post #284
guhidalg wrote: post #243

Earlier quoted context omitted.

Are you suggesting we give up on rendering layouts that respond to different window sizes, display resolutions, and zoom levels? I think what you’re suggesting is that clients requesting websites should receive essentially an image of the website with limited interactivity, but that’s not going to make anyone that’s ever used a website satisfies in C.E. 2023.

You can make web pages responsive to "different window sizes, display resolutions, and zoom levels" with no JavaScript at all, so that's clearly not what they're suggesting.

That’s true, but it’s not like translating HTML into a bitmap for a display is some spontaneous process that happens for free. Your browser is anyone going to interpret all that HTML and CSS, and your users are going to click on buttons and submit forms that require changing that HTML and CSS. Whether that happens through JavaScript or SSR is bike-shedding: processing will be done, computation is needed, we can sit here and argue about how the web front end world sucks but billions of users expect interactive web applications that are very difficult to deliver without JavaScript.

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

#357

Post by lenkite »

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…

This was back in the pure desktop era of the Web which had ginormous amount of stuff put on one screen.

Server side Web component frameworks needed to handle far more complexity on terrible networks with lesser compute power.

One of the good things that mobile platforms did is establish a designer culture of UI simplification.

JSF as someone pointed out was a framework birthed in the wrong era.

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

#358

Post by wibblewobble124 »

mal-2 wrote: post #288
mehphp wrote: post #186

Earlier quoted context omitted.

Yes, this is how Elixir Phoenix works. The caveat is that only returns exactly what needs to be changed, so it's a small diff. It's not suitable to everything, but it works really well. I'm not advocating switching to it right now, but it's looking very promising.

htmx glosses over the difficult part, which would be keeping track of the relationship between all these hx-post and hx-target attributes, when they're all just strings in markup. That glossing over is why you don't see any well-established backend libraries on the server integrations page. ( https://htmx.org/server-examples/ ) Elixir solves this in a much smarter way, because the bindings to reactive values can be v…

It’s not a difficult part if you already have a powerful web framework. We’re using Htmx with Servant which has type-safe URLs built in. For the targets, automatic name generation is fine.

I prefer the unopinionated, language agnostic simplicity of htmx, just like HTML, over more tightly bound language specific frameworks. It provides a vocabulary that will translate across backend languages and probably endure over competitor frameworks.

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

#359

Post by JohnFen »

tiagod wrote: post #203
JohnFen wrote: post #160

Earlier quoted context omitted.

With a couple of necessary exceptions, I don't use websites to store or process personal data, so that's not really the use case I have in mind. What I have for native applications that I don't for the web is the ability to firewall off the native applications.

> What I have for native applications that I don't for the web is the ability to firewall off the native applications. There you're placing trust on the firewall's sandbox. Are you sure the application can't communicate with the outside at all? DNS exfliltration for example?

A firewall is not a sandbox, but yes, I am sure that the applications can't communicate with the outside at all. My logs would show if they were. Any and all packets that originate from them are dropped, including DNS lookups and the like.

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

#360

Post by pas »

recursive wrote: post #311
fshr wrote: post #300

Earlier quoted context omitted.

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

Huh. Ok. I just didn't know that was a thing. Ok, I guess I don't need analog outputs then. Still nice to have though. Better zero pucks than two.

Hifi geeks don't trust the DAC to something inside the TV, and ... they are not wrong. Plus you can reuse the DAC even if you change the screen.
Post reply on HN