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

521–530 of 573 posts

Re: Hotwire: HTML over the Wire

#521

Post by learc83 »

cutler wrote: post #284
modernerd wrote: post #273

Pure JS developers trying to jump off the JS train have a few decent choices now: - Elixir / Phoenix - .NET / Blazor - Laravel / Livewire - Rails / Hotwire Or hold on for the JS ecosystem to figure out good patterns that balance performance/maintainability (React Server Components look ok, and will probably trickle into Next.js for those who want a framework). Does one of the above stand out as a good thing to learn…

Well Blazor ain't gonna reduce your load front-end load, that's for sure.

Blazor has 2 variants. The server side version works like liveview.

Re: Hotwire: HTML over the Wire

#522

Post by nickjj »

sfusato wrote: post #518
nickjj wrote: post #515

Earlier quoted context omitted.

> LiveView is just channels under the hood. Once you consider that, long polling may seem more obvious It's not obvious to me for user invoked page transitions because when I think of long polling, I think of an automated time based mechanism that's responsible for making the request, not the user. But a page transition is invoked by the user at an undetermined amount of time / interval (it might happen 2 seconds aft…

Your idea of "long polling" sounds more like periodic polling (repeated requests within a frequency), though that's not what long polling is or how it works.

> Your idea of "long polling" sounds more like periodic polling (repeated requests within a frequency), though that's not what long polling is or how it works.

Right isn't long polling keeping the connection open for every client on the server and then the server is doing interval based loops in the background until it gets a request from the client or times out?

It wouldn't be doing a separate HTTP request every N seconds with setInverval like the "other" type of polling but it's still doing quite a bit of work on the server.

In either case, LV's long polling is much different than keeping no connection open, no state on the server and only intercepting link clicks as they happen for Turbo Drive and Turbo Frames.

I don't think that's necessarily a big deal with Elixir (I wouldn't not pick it due to this alone, etc.), but this thread is more about the differences between Hotwire and LV, and no state being saved on the server for each connection is a pretty big difference for the Drive and Frames aspects of Turbo.

Re: Hotwire: HTML over the Wire

#523

Post by tonyhb »

vasachi wrote: post #130
methyl wrote: post #105

Earlier quoted context omitted.

That's one of the reasons SPA aren't going anywhere: trying to handle all the user microinteractions on the server is great when you leave next to it, but it falls apart when your users are spread across the world, especially if it's not western-ish world with fast internet connections.

Huh? How does SPA help here? JSON payloads don't go faster over the wire than html.

You're right, but the data can be cached and the views shown optimistically. After the first fetch it should be faster.

Re: Hotwire: HTML over the Wire

#524

Post by tester756 »

wokwokwok wrote: post #379
tester756 wrote: post #48

Earlier quoted context omitted.

It's proved technology .NET's Blazor (server based) uses this.

Um... Blazor hasn’t been used in any significant scale, and where it has been deployed, the websocket has been a bottleneck to performance.

proved in the sense of - the concepts makes sense, is actually implemented, used by some, viable in some cases.

Re: Hotwire: HTML over the Wire

#525

Post by danjac »

After playing for some hours with the new Turbo on a side project (with Django as backend), it mostly works fine.

One thing that is kind of broken out of the box is form submissions: so a common pattern with server side rendering is to re-render the form with validation errors, but otherwise redirect to wherever.

The workaround here I think is to use turbo-streams and just re-render the invalid form HTML snippet rather than the whole page. While this is probably ok for most cases, I have some forms (3rd party library stuff) where this is going to be more work than I'd like, and due to a bug in the beta release you can't override the default form submission behavior - Turbo throws an error if a form POST returns anything other than a redirect. So it's probably not quite ready for production yet.

Re: Hotwire: HTML over the Wire

#526

Post by sb8244 »

nickjj wrote: post #522
sfusato wrote: post #518

Earlier quoted context omitted.

Your idea of "long polling" sounds more like periodic polling (repeated requests within a frequency), though that's not what long polling is or how it works.

> Your idea of "long polling" sounds more like periodic polling (repeated requests within a frequency), though that's not what long polling is or how it works. Right isn't long polling keeping the connection open for every client on the server and then the server is doing interval based loops in the background until it gets a request from the client or times out? It wouldn't be doing a separate HTTP request every N s…

Yes there is a lot of stuff different here. I don't want to take that away. Just pointing out that websocket only is not accurate.

Re: Hotwire: HTML over the Wire

#527

Post by citrus1330 »

p1necone wrote: post #457
IggleSniggle wrote: post #453

Earlier quoted context omitted.

This is my experience in Reddit generally these days on mobile Safari

This combined with them intentionally breaking the mobile web experience has almost entirely stopped me from using Reddit.

I was trying to quit Reddit for years and their intentional breaking of mobile web (as well as making email address required even for already existing accounts) is what finally enabled me to.

Of course now I just go on Hacker News and Twitter instead.

Re: Hotwire: HTML over the Wire

#528

Post by freedomben »

ksec wrote: post #476
freedomben wrote: post #148

Earlier quoted context omitted.

I also prefer boring and love how HN works. That said though, modern consumers expect much more. We tech people like command lines, the ultimate in simple and boring. Modern consumers often want animation and things[1]. Source: UI/UX researchers tell me this when I push back and say "let's keep the tech simple and forgo some of the animations, etc in the name of using simple OOTB stuff without hacking thousands of li…

>UI/UX researchers Is that with respect to Web Page / Tech? Because people expect different things for Apps and WebPages.

Great question, largely yes web page / tech but I used to work on a Qt desktop app and it was the same story there. Luckily Qt made animations fairly easy and performant.

Re: Hotwire: HTML over the Wire

#529

Post by HeavyStorm »

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…

You've just explained the adoption of microservices in the enterprise.

I wonder if other industries suffer from the same problem, bored engineers.

Re: Hotwire: HTML over the Wire

#530

Post by jshen »

forgotmypw5 wrote: post #404
jshen wrote: post #102

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.

in no way elegant, but yes, with js, it's possible with netscape 3 and up, possibly with 2. html, http, js, css are pretty thorough in their design, and it shows. all the features described here are possible without any frameworks, this is merely a much easier way to build it than from scratch.

Yes, but I was replying to someone who said that we got all of this with cgi-bin. That’s like saying, “I can code a modern app in assembly, therefore there’s been no progress here”.
Post reply on HN