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

Hotwire: HTML over the Wire

hotwire.dev

Post reply on HN
Print view View original

551–560 of 573 posts

Re: Hotwire: HTML over the Wire

#551

Post by smichel17 »

masa331 wrote: post #487
webmaven wrote: post #360

Okay this is a bit meta, but the whole cluster of "everything old is new again", "the pendulum of fashion has swung", "nothing new under the sun" takes is ignoring what tends to drive this sort of change: relative costs. The allure of xmlhttprequest was that over connections much slower than today, and with much less powerful desktop computers, a user didn't have to wait for the whole page to redownload and re-render…

I don't think app complexity and sophistication grew that much. Most of the problems common apps are solving can be dealt with standard CRUD-like interfaces and old boring tech and it works just fine. I think what drives this crazy train of overengineered solutions of SPAs and K8s for hosting single static page is deep separation of engineeres from the actual business problems and people they are trying to help. When…

Curious what you make of this:

I recently wrote a SPA (in React) that, in my opinion, would have been better suited as a server-side rendered site with a little vanilla js sprinkled on top. In terms of both performance and development effort.

The reason? The other part of the product is an app, which is written in React Native, so this kept a similar tech stack. The server component is node, for the same reason. And the app is React Native in order to be cross-platform. We have ended up sharing very little code between the two, but using the same tech everywhere has been nice, in a small org where everyone does everything.

Re: Hotwire: HTML over the Wire

#552

Post by ehutch79 »

webmaven wrote: post #342
yashap wrote: post #252

As others have noted, seems reasonably similar to LiveView, Livewire and Blazor. I’m somewhat bullish on these approaches - server side rendered monoliths (Rails, Django, etc.) are SO productive, at least for the first few years of development, but lack of interactivity is a big issue, and this solves it well. However, another big issue is the dominance of mobile. More and more, you’ve got 2-3 frontends (web and cros…

> More and more, you’ve got 2-3 frontends (web and cross-platform mobile, or explicitly web, iOS and Android), and you want to power them all with the same backend. RESTful APIs serving up JSON works for all 3, as does GraphQL [...]. This however is totally web-specific - you’ll end up building REST APIs and mobile apps anyways, so the productivity gains end up way smaller, possibly even net negative. I bet someone w…

I can't think of a worse idea than telling people their mobile app should be scrapping their desktop page for data.

Re: Hotwire: HTML over the Wire

#553

Post by ebiester »

1_player wrote: post #538
ebiester wrote: post #531

Earlier quoted context omitted.

Form submissions are brutally bad the moment a back button comes in. I remember so many "The client used the back button in a multi-page form and part of the form disappeared for them" bugs.

They're not if coded correctly and using the correct redirect/HTTP response code.

Yeah. I remember dozens of edge cases that involved errors and back buttons and flash scope and on at least one occasion, jquery plugins.

Or back buttons and CSRF tokens and flash scope...

Or, let's talk about a common use case. Someone starts filling in a form, and then they need to look at another page to get more information. (This other page may take too long to load and isn't worth putting in the workflow, or it was cut from scope to place the information twice.) So, they go out to another page, then back, and are flustered because they were part way through the work.

So, if you want this to work, you're going to need state management in the client anyway. (Usually using SessionStorage these days, I'd presume?) So, then, we've already done part of the work for state management. You are then playing the "which is right, the server or the client" game.

You accumulate enough edge cases and UX tweaks, and you're half way down the SPA requirements anyway.

Now, hopefully Hotwire will solve a large number of these problems. I'm going to play with it, but the SPA approaches have solved so many of the edge cases via code and patterns.

Re: Hotwire: HTML over the Wire

#555

Post by webmaven »

ebiester wrote: post #553
1_player wrote: post #538

Earlier quoted context omitted.

They're not if coded correctly and using the correct redirect/HTTP response code.

Yeah. I remember dozens of edge cases that involved errors and back buttons and flash scope and on at least one occasion, jquery plugins. Or back buttons and CSRF tokens and flash scope... Or, let's talk about a common use case. Someone starts filling in a form, and then they need to look at another page to get more information. (This other page may take too long to load and isn't worth putting in the workflow, or it…

> but the SPA approaches have solved so many of the edge cases via code and patterns.

Part of the problem has also been ameliorated by larger screens and browser tabs.

Re: Hotwire: HTML over the Wire

#557

Post by webmaven »

jshen wrote: post #483
webmaven wrote: post #349

Earlier quoted context omitted.

> cgi-bin didn’t give you the ability to update a chat page across several different windows in near real-time. Servers could maintain an open connection and stream new data to the browser.

That was a much worse solution, and even worse with cgi-bin.

Sometimes worse is better.

Re: Hotwire: HTML over the Wire

#558

Post by webmaven »

ehutch79 wrote: post #552
webmaven wrote: post #342

Earlier quoted context omitted.

> More and more, you’ve got 2-3 frontends (web and cross-platform mobile, or explicitly web, iOS and Android), and you want to power them all with the same backend. RESTful APIs serving up JSON works for all 3, as does GraphQL [...]. This however is totally web-specific - you’ll end up building REST APIs and mobile apps anyways, so the productivity gains end up way smaller, possibly even net negative. I bet someone w…

I can't think of a worse idea than telling people their mobile app should be scrapping their desktop page for data.

Not the page, the API (which returns HTML fragments for incorporating into the page).

And if you can't think of anything worse, you're not trying very hard.

Re: Hotwire: HTML over the Wire

#559

Post by webmaven »

samtechie wrote: post #549
webmaven wrote: post #342

Earlier quoted context omitted.

> More and more, you’ve got 2-3 frontends (web and cross-platform mobile, or explicitly web, iOS and Android), and you want to power them all with the same backend. RESTful APIs serving up JSON works for all 3, as does GraphQL [...]. This however is totally web-specific - you’ll end up building REST APIs and mobile apps anyways, so the productivity gains end up way smaller, possibly even net negative. I bet someone w…

Isn't GraphQL supposed to solve this problem? You have one GraphQL API and each client requests only the information it needs. Maybe the responses are still JSON but I would think you would come very close to an API that serves all the clients.

Even without GraphQL, you can accommodate both sets of needs. I said as much. I'm also saying that the argument about the user-facing tech stack is bogus.

Re: Hotwire: HTML over the Wire

#560

Post by exabrial »

vp8989 wrote: post #295
dsego wrote: post #245

Earlier quoted context omitted.

Serverless is kind of like Apache running PHP scripts in virtual hosts.

The greatest trick the devil ever pulled is convincing people that shared hosting is preferable to dedicated, and then charging them way more money for it.

The cloud is just someone else's computer in a data center in new Jersey about to be hurt by a hurricane.
Post reply on HN