Live data from Hacker News

Hotwire: HTML over the Wire

hotwire.dev

71–80 of 573 posts

Re: Hotwire: HTML over the Wire

#71

This kind-of tangential reply is in bad taste, but DHH is currently being an asshole about this very topic on Twitter, so: This seems cool, but the progress that HEY has made since launch isn't very impressive if that's the flagship example. HEY's search UX, which uses these capabilities, has been abysmal since the day it launched. It's a much better experience if you disable JavaScript/Hotwire and fall back to the s…

>We were also promised custom domain support by the end of the year,

Basecamp / DHH generally speaking hate deadlines / roadmap etc. They are ready when they are ready.

Although I do agree a little update would be nice.

Re: Hotwire: HTML over the Wire

#73
post #39

Earlier quoted context omitted.

I get the rush to provide technical comparisons to something that was just revealed five minutes ago, but none of what you just said is actually how Hotwire or Turbo works. There's no client DOM in memory on the server, there's no html buttons that call native code. There are forms being submitted, there are normal requests happening, there are templates being rendered on a per-request basis (just like a full page lo…

[flagged]

Looks like link should be https://docs.stimulusreflex.com/ (the root domain you linked doesn't go anywhere).

Re: Hotwire: HTML over the Wire

#74
Spoiler, it's just Ajax but it pushes the data through your templates before sending it to the client. We were doing this literally over a decade ago in the early days of XHR.

Re: Hotwire: HTML over the Wire

#75
post #40
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.

My thought exactly, though I fully support that. I often rant about how the modern web is billions of layers of duck tape over duck tape and it has become an unmanageable mess of libraries, frameworks, resources, all while javascript remains the most outrageous and absurd language ever created. I'm by no means a fan of rails or ruby for that matter but I think things like these are a considerably better alternative t…

There is plenty of duck tape yes,

But there is suprisingly little layers on layers. Part of what has been amazing about the web is that the target remains the same. There is the DOM. Everyone is trying different ways to build & update the DOM.

Agreed that there are better alternatives than a lot of what is out there. We seem to be in a mass consolidation, focusing around a couple very popular systems. I am glad to see folks like Github presenting some of the better alternatives, such as their Catalyst tools[1] which speed up (developer-wise & page-wise (via "Actions") both) & give some patterns for building WebComponents.

The web has been unimaginably stable a platform for building things, has retained it's spirit while allowing hundreds of different architectures for how things get built. Yes, we can make a mess of our architectures. Yes, humanity can over-consume resources. But we can also, often, do it right, and we can learn & evolve, as we have done so, over the past 30 years we've had with the web.

[1] https://github.github.io/catalyst/

Re: Hotwire: HTML over the Wire

#76
post #10

It's hilarious that web servers rendering HTML and sending it to the browser over a TCP connection is now "cool new tech".

I'll just take a break for 3 years until SPAs become cool again. But they won't be called SPAs anymore... they'll be called "microapps". Elixir and Rust will be "just not fast enough" and there will be a new language VM that will "promise Hyperspeed™ on Google Crystalline™ chips". JSON will be considered harmful, and XML will be in favor again because it is flexible and there's plenty of bandwidth for all the extra bytes.

Re: Hotwire: HTML over the Wire

#77
post #12

Earlier quoted context omitted.

I found this little thread on Twitter interesting, complaining Hey (powered by hotwire) is too slow https://twitter.com/youyuxi/status/1337851036015480843

I got into the Hey beta, wound up purchasing it and I haven't had any performance issues to speak of. I'm curious to know what their setup is.

I've used Hey daily since it launched on desktop and mobile and I can't see it being slow in any way. I guess you could count that it shows a loading symbol for a file to appear (on the first load only).. but that would be excessive nitpicking.

Re: Hotwire: HTML over the Wire

#78
post #39

Earlier quoted context omitted.

I get the rush to provide technical comparisons to something that was just revealed five minutes ago, but none of what you just said is actually how Hotwire or Turbo works. There's no client DOM in memory on the server, there's no html buttons that call native code. There are forms being submitted, there are normal requests happening, there are templates being rendered on a per-request basis (just like a full page lo…

[flagged]

And while we are at it, Motion (https://github.com/unabridged/motion)

Re: Hotwire: HTML over the Wire

#79
post #15

It sounds a lot like Laravel Livewire[1] Also a lot like React Server Components that we saw on HN yesterday[2] It seems like this is the next wave of web apps. Hopefully once the hype settles, we'll be able to decide which approach is best for which project. [1] https://laravel-livewire.com/ [2] https://news.ycombinator.com/item?id=25497065

Livewire, of course, having been heavily inspired by Phoenix LiveView https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html

Re: Hotwire: HTML over the Wire

#80
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.

AjaxContentPanels or something to that effect. Those things were a nightmare. At the time, asp.net pretended to be stateful by bundling up the entire state of the page into "ViewState" and passing it back and forth client to server. Getting that to work with those panels was more work than just ajax-ing the content and injecting it with jquery. In the Microsoft-verse, this might also draw some comparisons to the more…

see here: https://docs.microsoft.com/en-us/dotnet/api/system.web.ui.up...

I used it 13 years ago. It was fancy.

Post reply on HN