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

Ask HN: What companies are embracing “HTML over the wire”?

news.ycombinator.com

Post reply on HN
Print view View original

91–100 of 192 posts

Re: Ask HN: What companies are embracing “HTML over the wire”?

#91

Post by tracker1 »

It depends... are you delivering mostly static content or creating and interactive application front-end? Most sites are somewhere in the middle and so should the responses.

For me, if it's an application ui/ux, then the rendering should be almost exclusively on the front-end. It's just delivered via a web server instead of installed. Yeah, it's larger than server-sent. It's also emphatically not tying up server resources for template processing, instead using the super computer on your desk or in your pocket.

I frankly feel ill when I see more than a couple hundred kb of compressed JS go over the wire... why a couple hundred, that's just where I draw the line... React + MUI with some optimizations and all the application logic should easily fit in under 300k compressed payload. If you're going over that, you're probably doing something very, very wrong. Not that you can't go much smaller and hand crafted. It's a trade-off.

I also think edge development tools like Cloudflare Workers and Deno are exceedingly nice and can seriously bridge the gap closer to server rendered, but still not the same as a lot of classic legacy apps.

On the flip side, I look at how much memory and resources applications use on a server as it is... They're often massively under-utilized as well. So who knows. I just know that there's nothing wrong in using the client's system to render the client.

Re: Ask HN: What companies are embracing “HTML over the wire”?

#92

Post by nickswan »

noveltyaccount wrote: post #35

old man alert Back in my day, we wrote ASP.NET that was all server-side-rendered HTML. Once in a while we got REAL FANCY and used JQuery to make PARTIAL HTML requests and update only FRAGMENTS of the page. Hooboy I knew that fashion was cyclical but not tech!

That’s exactly what we are still doing in our bootstrapped SaaS tool! Using asp.net mvc though, not web forms.

Re: Ask HN: What companies are embracing “HTML over the wire”?

#93

Post by basicallybones »

JonathanBeuys wrote: post #21

You don't even need a fancy "send html fragments over the wire" approach to create a better user and developer experience. Just sending full pages, server side rendered, like Hacker News and Wikipedia do is fine: Going from the HN homepage to this topic we are on: 36 KB in 5 requests. Going from the Wikipedia Homepage to an article: 824 KB in 25 requests Going from the AirBnB homepage to an apartment listing: 11.4 MB…

Frontend frameworks developed in response to the need to develop/maintain very complex browser-based applications like Facebook across a large team of developers. AirBnB/Reddit have dramatically more complex user behavior and are much more input- and media-oriented. You cannot wait on round trips to the server for user interactions, and you cannot just do hybrid client/server the old jQuery way on big applications because you get spaghetti code.

Comparing Reddit and Wikipedia is like comparing a motorcycle to a bicycle. They are different, with specific strengths and weaknesses. Both design/engineering paradigms have a place, imo.

Re: Ask HN: What companies are embracing “HTML over the wire”?

#94

Post by tracker1 »

slotrans wrote: post #57
basch wrote: post #44

Earlier quoted context omitted.

IF you want the page to be interactive without refreshes though, you gotta do something. Unless you are advocating a completely pre-ajax web. https://en.wikipedia.org/wiki/Ajax_(programming)

Why are refreshes assumed to be bad?

I'm not convinced that it is... but it's not as smooth as client load-once rendering can be.

What is/was painful was, as an example, the first versions of ASP .Net Web Forms, where every client action was a full server round-trip... Server-rendered Blazor over the wire (not local or in-office server) is roughly as painful by today's standards.

I do think that it's a mix... start with basic html and enhance, or start with a component toolkit with client rendering, and inject server donut or other pre-rendering. With Cloudflare and Deno, I think the latter definitely has some traction.

Re: Ask HN: What companies are embracing “HTML over the wire”?

#97

Post by basch »

tracker1 wrote: post #94
slotrans wrote: post #57

Earlier quoted context omitted.

Why are refreshes assumed to be bad?

I'm not convinced that it is... but it's not as smooth as client load-once rendering can be. What is/was painful was, as an example, the first versions of ASP .Net Web Forms, where every client action was a full server round-trip... Server-rendered Blazor over the wire (not local or in-office server) is roughly as painful by today's standards. I do think that it's a mix... start with basic html and enhance, or start…

I find it much less smooth having a webpage consuming constant CPU.

Re: Ask HN: What companies are embracing “HTML over the wire”?

#98

Post by jay-barronville »

I understand your frustration. I feel the same way. I think the web development landscape has become unnecessarily complex. I sometimes miss how simple it used to be to just throw some PHP files together and have a working website up and running. Granted, those “simple” websites came with their own set of issues (especially security-wise), but I still miss that simplicity.

Over the past 10-ish years alone, I’ve watched web development go through so many phases, it’s not even funny. Anyone remember gulp.js? Well, I remember a time when every conference talk mentioned it and you were weird if you didn’t use it. Backbone.js anyone?

In my experience, I’ve found that most folks can’t even tell you WHY they use React or insert JavaScript framework here.

Not too long ago, I was stepping through some “hello world” code for a trendy framework and the amount of code that was touched just to write “hello world” in the browser felt absolutely ridiculous to me.

Let me stop myself before I go on a prolonged rant . . .

Anyway, all that said, this is why I’m a fan of SvelteKit (Svelte) and Remix (React). I think they provide a decent balance of modern features while building on native web features/protocols properly.

Re: Ask HN: What companies are embracing “HTML over the wire”?

#99

Post by tracker1 »

noveltyaccount wrote: post #35

old man alert Back in my day, we wrote ASP.NET that was all server-side-rendered HTML. Once in a while we got REAL FANCY and used JQuery to make PARTIAL HTML requests and update only FRAGMENTS of the page. Hooboy I knew that fashion was cyclical but not tech!

Until the page gets complex and viewstate gets ugly too... Add in a dialup connection and you were in for worlds of pain. By today's standards of interactivity, I find the modern take (server rendered Blazor) as equally painfully slow to respond.

Re: Ask HN: What companies are embracing “HTML over the wire”?

#100

Post by jacobsenscott »

danielrhodes wrote: post #62

People have gotten way too religious over SPAs, SSR, etc. Should you use X? Maybe it depends. I have been burned by using SSR when the complexity of the app increased and suddenly doing SSR was getting in the way and now I was uncomfortably mixing JS with server rendered pages and struggling to maintain state. I've also been on the other side, using React and creating more complexity than was needed. The point is: do…

People also need to work within the constraints of the chosen stack. You can make a very good experience in either a SSR and SPA app. But you can't make identical experiences.

Product designers are notoriously bad at working within the constraints of a stack - so when you choose SSR with hotwire or whatever, you definitely need to push back when a product designer hands you a mock up of something that can't be done easily with SSR. Don't create some mess of SSR and JS. Tell the designer to go back and redesign the experience so it meets the constraints of the stack.

So when I hear "the complexity of the app increased" I'm hearing "the designer invented something that doesn't work with our stack" and rather than saying no, the devs just tried to forge ahead with the wrong tools. (Obviously I'm projecting experiences I've had :))

Post reply on HN