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

101–110 of 192 posts

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

#101

Post by enraged_camel »

basicallybones wrote: post #93
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 be…

Yeah, I cannot even begin to imagine what it would be like to develop AirBnb without some sort of front end framework. I used to write pure JS and jquery back in the day, and it was super easy to end up with a rat’s nest of spaghetti code. And those apps were several orders of magnitude less complex!

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

#102

Post by sodapopcan »

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…

I agree 100%. Doing everything on the client has its place, but those aren't the type of apps I'm interested in working on. My problem is that for the bulk of web apps out there, a frontend JS framework (I'm sorry I don't have hard data on that but going by experience and the experiences of people I know). The "good fight" I'm referring to is not defaulting to React to build your information app that has very little interactivity. The recent "HTML over the wire" frameworks lean heavily on abstracted away JS to give you a middle ground between SPAs and pure SSR.

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

#103

Post by tracker1 »

basch wrote: post #97
tracker1 wrote: post #94

Earlier quoted context omitted.

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.

That's a different issue. There's no reason CPU consumption should be high when you aren't interacting with an application.

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

#104

Post by victorbjorklund »

gemstones wrote: post #38
88913527 wrote: post #32

Earlier quoted context omitted.

Having only worked at SPA places, it's hard for me to imagine not having tools like Storybook, Chromatic, and Mocked Service Workers. Building the UI in isolation means with mocked API responses means I can, in parallel, validate 1000's of use cases with pixel-level precision. The backend teams can keep their focus on scalable, performant APIs. The frontend teams can focus on accessibility, consistency, etc. I've fou…

Yeah, I hear the HTML-only case more from people who were full-stack or backend. Giving up the tooling around SPAs would be hard. I'm not sure what the equivalent is - is there any frontend-specific advice for backend devs that amounts to "wouldn't it be cool if you gave up all your developer tooling?"

Like "lets use firebase"?

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

#105

Post by jibe »

basicallybones wrote: post #93
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 be…

You cannot wait on round trips to the server for user interactions

Old Reddit still works fine, and I’d argue better than new front end heavy Reddit. You are right it may be for the benefit developers, but Reddit isn’t complicated enough that a heavy front end provides much benefit to the users.

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

#106

Post by rswskg »

sodapopcan wrote: post #59
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)

"HTML over the wire" generally refers to tech like [0] LiveView, [1] Hotwire, [2] LiveView, [3] Blazor, etc. They aren't about about ditching JS and more about not writing your HTML in JS (and yes, SSR). [0] https://github.com/phoenixframework/phoenix_live_view [1] https://hotwired.dev/ [2] https://laravel-livewire.com/ [3] https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...

Or mvc?

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

#107

Post by foresto »

MrPatan wrote: post #80

I think I get it. You really don't want to shift your mind to the browser. Your mind is in the server, you know what's up in there, and distributed systems are complicated, so one of the ends should be made as dumb as possible. I get it. Except, guess where the mind of the user is? On the other side of the browser. Embrace the browser, server people, it's closer to the user!

There are user-focused reasons to build sites without (requiring) javascript.

For example, respecting the wishes of users who disable scripts to avoid most of the web's privacy, security, and attention disruption problems.

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

#108

Post by pictur »

It is quite easy to say “you should definitely use x” by giving examples of simple applications. however, the vast majority of examples given will turn the app into a soup if you want to do a thorough study. If you're happy with this soup, it's up to you. So enjoy your soups and stop criticizing the useful things people produce with empty arguments. If you have a worthy alternative, offer them. Please stop suggesting things like htmx as alternatives.

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

#109

Post by jacobsenscott »

88913527 wrote: post #32
mjfisher wrote: post #5

Earlier quoted context omitted.

It is rendered server side, but typically the server keeps track of only what needs to change and sends as small as possible an update to dynamically update the DOM. You end up with a user experience that feels close to an SPA, but a dev experience that feels close to traditional SSR.

Having only worked at SPA places, it's hard for me to imagine not having tools like Storybook, Chromatic, and Mocked Service Workers. Building the UI in isolation means with mocked API responses means I can, in parallel, validate 1000's of use cases with pixel-level precision. The backend teams can keep their focus on scalable, performant APIs. The frontend teams can focus on accessibility, consistency, etc. I've fou…

Indeed this is one of the challenges of hiring front end for SSR apps. There's now a whole generation of front end engineers who have never had to build a plain old SSR html page, and never had to use or read any language other than JS. Learning this style of development is starting from scratch for them. Yes SSR is a radically simpler stack, but not until you learn it. And you probably need to learn at least on more language.

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

#110

Post by jacobsenscott »

tracker1 wrote: post #91

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 reso…

I wouldn't assume building the html on the server uses any more server resources than building JSON. Either way you are just building a giant blob of text. With html fragment caching the server could easily be doing less work this way.
Post reply on HN