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

431–440 of 573 posts

Re: Hotwire: HTML over the Wire

#431

Post by satyrnein »

still_grokking wrote: post #399

Likely an unpopular opinion. But anyway. I think the presented thingy is fundamentally wrong. It's just another attempt to put the square peg in a round hole. The point is: "The web" is not, and never was, a framework for application development! It's the wrong tool. No matter how hard you try. You want to build applications? Use tools that where build from the ground up to support application development. On mobile…

So if you want to build the next big social app, sure you build a native mobile app. But then what, you build a _desktop_ app, because that's better on certain technical dimensions than a webapp? Should facebook.com have simply offered Windows and Mac installers instead?

Re: Hotwire: HTML over the Wire

#432

Post by EdwardDiego »

mmastrac wrote: post #4

What's old is new again. I recall ASP.NET had some interesting tech around this in the 2000s where it could dynamically update parts of the page. If I recall correctly, this made use of that new technology of the time called "XMLHttpRequest" (/s) which pretty much jump-started web 2.0.

Yep, was using this approach in Java server-side frameworks 12 years ago.

Re: Hotwire: HTML over the Wire

#433

Post by mhh__ »

Scarbutt wrote: post #353
philote wrote: post #238

Earlier quoted context omitted.

Same. And I'm still amazed that people loved JS so much they put it on the SERVER too! And now node/npm is everywhere.

Node has a better runtime than ruby or python, so why not? and you also have TS.

The node runtime is actually pretty quick (It's roughly as fast as an optimizing compiler from 10-15 years ago, give or take, which is fairly impressive), but even TS is still makeup on a wart - you can't escape JS's more bizarre semantics that easily.

Re: Hotwire: HTML over the Wire

#434

Post by inopinatus »

SahAssar wrote: post #297
Nextgrid wrote: post #222

Earlier quoted context omitted.

Counterpoint: is there any error handling in the majority of SPAs today? From my experience, SPAs can crap out in all kinds of interesting ways when the underlying network connection is flaky and I often end up stuck on some kind of spinner that will never complete (nor give me a way to abort & retry the operation when I already know it won't complete and don't want to wait for the ~30-second timeout, if there is a t…

I agree that most SPA apps do it badly too, but hiding the opportunity to do it well certainly does not help. > there is no state and it should thus be safer and quicker to reload the page should things go wrong. That's not exactly true since there are non-idempotent HTTP methods and while the browser will prompt you if you want to resend a non-idempotent HTTP request when refreshing a normal form POST I don't think…

You're correct in that the only standards-based way to retain a POST in the session history is to not disturb an existing entry. However:

> it seems to try to say things are simple or easy

That's an unfair mis-characterisation. The developers are not pitching a universal panacea that solves all your problems and handles every edge case. They are offering an architecture that simplifies many common scenarios, and one that is thoroughly developer-friendly when it comes to supplying observability and integration hooks for edge cases.

For this latter purpose it merely remains to bother with reading the (clean & elegant) source code to enlighten oneself.

> it seems like it is undocumented

On the contrary, the behavior w.r.t full-page replacement on non-idempotent verbs is extensively discussed in the Turbolinks repo.

The "Turbo Drive" component appears to me as essentially unchanged behaviour in Turbo 7.0.0beta1 from Turbolinks versions 5.x. Turbolinks was introduced in 2013, has many years of pedigree and online discussion, and is well understood by a large developer community. Turbolinks was always maintained, even being ported to TypeScript (from the now venerable CoffeeScript) ca. two years ago with no change in behaviour. Turbo Drive is, practically, just a slightly refactored rebrand of the TypeScript port.

The stuff everyone is so excited about are Turbo Frames and Turbo Streams. These are new, and may be used without adopting Turbo Drive: as with practically everything from Basecamp, the toolkit is omakase with substitutions. They are, nevertheless, complementary, so you get all three steak knives in one box.

Re: Hotwire: HTML over the Wire

#435

Post by hinkley »

mmastrac wrote: post #4

What's old is new again. I recall ASP.NET had some interesting tech around this in the 2000s where it could dynamically update parts of the page. If I recall correctly, this made use of that new technology of the time called "XMLHttpRequest" (/s) which pretty much jump-started web 2.0.

jquery also had a function for doing swaps. Then there's Rails turbolinks, and now Phoenix LiveView in Elixir.

I don't know if it's so much 'everything old is new again' as it is a problem of market penetration.

Re: Hotwire: HTML over the Wire

#436

Post by p1necone »

Nextgrid wrote: post #222
SahAssar wrote: post #41

I've never seen one of these "logic in html-attributes" systems take error checking seriously. In stimulus they start to mention it in "Designing For Resilience" (though only for feature-checking), but in "Working With External Resources" where it uses calls network/IO bound calls they never mention how to handle errors or if the framework just leaves it up to you. Stimulus is also where you need to write your own js…

Counterpoint: is there any error handling in the majority of SPAs today? From my experience, SPAs can crap out in all kinds of interesting ways when the underlying network connection is flaky and I often end up stuck on some kind of spinner that will never complete (nor give me a way to abort & retry the operation when I already know it won't complete and don't want to wait for the ~30-second timeout, if there is a t…

Facebook does this constantly for me. It's a crapshoot whether I'll be able to open notifications or messages without a couple of refreshes, or if I'll just get the fake empty circle loading UI indefinitely until I hit F5.

Re: Hotwire: HTML over the Wire

#437

Post by bird_monster »

claudiawerner wrote: post #425
bird_monster wrote: post #403

Earlier quoted context omitted.

Best of luck getting paying users to install each individual desktop application, as opposed to installing a browser and then navigating to multiple applications without any additional desktop/native work. I guess there might be space for something like Steam, but for business apps, but I just don't see it. The argument "This isn't what the web was made for" is kind of a cowpath argument. The web is being used to (am…

Yeah, it doesn't make sense to me. Consider this from the developer's point of view, and every single developer will tell you they'd rather make Javascript and some HTML rather than GTK application in C, especially when it'll work on every platform except maybe Plan 9.

For the vast majority of developers, C/C++ native desktop applications aren't a great idea. For the vast majority of businesses, C/C++ native desktop applications aren't a great idea.

If QT was going to become ___the tool___ for desktop dev, it would've done it by now.

Re: Hotwire: HTML over the Wire

#438

Post by ZephyrBlu »

vasachi wrote: post #184
jeroenhd wrote: post #146

Earlier quoted context omitted.

JS interacting locally can make a web page be perceived to be faster, even if there's no meaningful content yet. Humans enjoy working with systems that so _something_ as soon as they interact with them and a placeholder/spinner/animation is that exact something. Of course, you don't want any placeholders or animations to go on for too long, but it's good to know that the button you just pressed actually did something…

Well, a spinner can be added even into non-SPA applications. So I don’t see how that is an argument for SPA. I presume you can lie to user by pretending that their change was instantly submitted, while syncing in background. In that case, yes, SPA all the way.

That's not really lying, it's good UX. Optimistic updates feel a lot better than waiting for something to happen.

Re: Hotwire: HTML over the Wire

#439

Post by ZephyrBlu »

konha wrote: post #136
rk06 wrote: post #127

Earlier quoted context omitted.

he is complaining on Hey's lack of speed and interactivity, not complaining about the lack of js. which is a fair complaint, I would say.

It is. But he also wrote this in a subsequent tweet: > For a typically long running app like an email client, the obsession with shipping as little JavaScript as possible is actually detrimental to the end UX.

I'd argue that's almost objectively true. For a long running app, initial load time isn't as important as something like a ecommerce store.

Re: Hotwire: HTML over the Wire

#440

Post by sb8244 »

nickjj wrote: post #422
sb8244 wrote: post #373

Earlier quoted context omitted.

Fwiw, you can use long polling for LiveView if you wanted. That could completely remove websockets as everything happens over http. Hotwire will benefit from caching better than LiveView, because frames are distinct URLs. But I haven't personally need that.

> Fwiw, you can use long polling for LiveView if you wanted. How does that work for page transitions? The docs don't mention anything about this or how to configure it. With Turbolinks or Hotwire Turbo Drive, the user clicks the link to initiate a page transition and then the body of the page is swapped with the new content being served over HTTP. With Turbo Frames the same thing happens except it's only a designated…

It uses long polling over http. To be clear it's not restful http, but it's not websockets. I believe that Chris doesn't believe it's important for most people so there are no directions right now. Could be wrong there, I'm not Chris.

Page changes are still initiated by the client in LiveView (although can be server initiated)

LiveView is just channels under the hood. Once you consider that, long polling may seem more obvious

Post reply on HN