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

A clean start for the web (2020)

macwright.com

Post reply on HN
Print view View original

131–140 of 200 posts

Re: A clean start for the web (2020)

#131

Post by Barrera »

> We hope that all this innovation is for the user, but often it isn’t. Modern websites seem to be as large, slow, and buggy as they’ve ever been. Our computers are barely getting faster and our internet connection speeds are stagnating (don’t even try to mention 5G). Webpage size growth is outpacing it all.

The author makes a good start at fleshing out this argument, but stops short. He goes on to talk about a gizmo that was added to his own work to track use of a feature, which then was abused by others in the company.

The problem is that the same motivation and tools that are used by developers to figure out how to make their products better are the same motivations and tools used by advertisers to sell crap and snoop on users. Exactly the same tools, very different outcomes. One improves the experience while the other degrades it.

It's not clear how to separate the two, allowing only the "good" uses of tracking technologies while preventing the "bad." For its part, the essay doesn't really provide an answer so much as start talking about technologies.

But if you really want to improve the Web, it makes a lot of sense to really drill down into what makes the Web bad today. It is really technological complexity, leading to rendering engine monoculture? Or is it something more sociological in nature?

Re: A clean start for the web (2020)

#132

Post by seydor »

Tade0 wrote: post #90
fredrikholm wrote: post #79

Earlier quoted context omitted.

New idea? Hypermedia is from 1965, and has been a thing since 1991; HTML. recursivedoubts HTMX library is cutting edge 2005 technology. To add to both of your arguments, "JS-routers" like SvelteKit/NuxtJS/NextJS are literally reinventing server side rendering for the client to then call the actual server to get data ... to render HTML. HTMX, LiveView, Livewire, Hotwire etc are escape hatches back to sanity.

> SvelteKit/NuxtJS/NextJS are literally reinventing server side rendering for the client to then call the actual server to get data ... to render HTML. It's all done in one call - at least in Svelte. You can even render all this into a fully static site. Meanwhile htmx and the like is the same idea that was popular 15-ish years ago, which died for good reasons.

I don't think the reasons were good

Re: A clean start for the web (2020)

#133

Post by hutzlibu »

brtkdotse wrote: post #108
_448 wrote: post #97

Earlier quoted context omitted.

One advantage of pushing the computing on the user-side is that it reduces the load on the server: less requests, less processing and smaller request sizes. Thus it reduces the bill for the developers/companies :)

So by spending thousands of dollars on developer time we can save dozens of dollars on server costs? ;)

It is all a question, of how big you want to scale it.

Re: A clean start for the web (2020)

#134

Post by GordonS »

scrollaway wrote: post #112
GordonS wrote: post #107

Earlier quoted context omitted.

The server load from a server-side rendered page vs an API call that returns JSON is... very minimal. Unless you're building at great scale, it's such a negligible difference that it really shouldn't be part of your decision making process, IMHO.

[Edit: I don't want to get into this argument right now]

I'm guessing you haven't measured it, as IME it certainly is true. Try it, you might be surprised.

Also, SSR'd pages can be cached too.

Re: A clean start for the web (2020)

#135

Post by hutzlibu »

GordonS wrote: post #107
_448 wrote: post #97

Earlier quoted context omitted.

One advantage of pushing the computing on the user-side is that it reduces the load on the server: less requests, less processing and smaller request sizes. Thus it reduces the bill for the developers/companies :)

The server load from a server-side rendered page vs an API call that returns JSON is... very minimal. Unless you're building at great scale, it's such a negligible difference that it really shouldn't be part of your decision making process, IMHO.

"The server load from a server-side rendered page vs an API call that returns JSON is... very minimal."

That greatly depends how you designed your architecture and if you have just a simple webpage or a sophisticated webapp displaying data in various ways.

My main app is designed to work mainly offline, with bursts of data transfer. All the state is local. Sending html from the server would mean in my case, the server would need to know and keep track of all the user states and data.

Re: A clean start for the web (2020)

#136

Post by xigoi »

zozbot234 wrote: post #89
betwixthewires wrote: post #11

I personally would love a "document web" and an "application web." I've thought of this before independently and talked about it to some people, I think the author is right, the idea of one client application for everything internet related is a core source for the problems we face with the web. I like Gemini, a lot, and I think it could serve as a "document web" very well, except it's missing certain document featur…

> except it's missing certain document features like italics, bold and superscript There are ANSI escape codes for these features. It's not missing.

Those don't work on every client.

Re: A clean start for the web (2020)

#138

Post by egeozcan »

recursivedoubts wrote: post #120
egeozcan wrote: post #104

Earlier quoted context omitted.

htmx is designed to work with a HTML API. Everyone here seems to love it, I found it forces terribly complicated routing and templating and IMHO projects grow towards unmaintainable very quickly. I'm saying this as a person who really tried hard to like it. You can perhaps use Alpine.js plus sprinkle htmx here and there, to have the best of both worlds, at least on paper. Didn't try this myself.

i'm old enough to remember when everyone here hated it ;)

I used intercooler.js (the predecessor of htmlx) a lot to sprinkle interactivity on top of static pages. Back then I remember the attidute was positive for it too. Not for building proper web apps though...

Re: A clean start for the web (2020)

#139

Post by brtkdotse »

hutzlibu wrote: post #133
brtkdotse wrote: post #108

Earlier quoted context omitted.

So by spending thousands of dollars on developer time we can save dozens of dollars on server costs? ;)

It is all a question, of how big you want to scale it.

Stack Overflow runs SSR with a half a dozen servers. How much more scale do you need?

Re: A clean start for the web (2020)

#140

Post by mvolfik »

brtkdotse wrote: post #108
_448 wrote: post #97

Earlier quoted context omitted.

One advantage of pushing the computing on the user-side is that it reduces the load on the server: less requests, less processing and smaller request sizes. Thus it reduces the bill for the developers/companies :)

So by spending thousands of dollars on developer time we can save dozens of dollars on server costs? ;)

I wouldn't say that it increases developer time. From my (sure, limited) experience of building both with Flask (Django-like, Python BE framework) and Svelte, the difference between developer time is negligable, if not in favor of building on the client - the component frameworks bring much more to the table, like scoped CSS, often better editor support for dynamic values in the HTML templates etc.
Post reply on HN