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

361–370 of 573 posts

Re: Hotwire: HTML over the Wire

#361

Post by mstipetic »

sodapopcan wrote: post #79
llimos wrote: 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

I've just been getting into it, and am completely loving it, especially the elixir part. It feels like the whole OTP/erlang part of it (basically single codebase microservices and patterns that come with it) has proper engineering and principles behind it, and it's something I've been missing for a long time in our profession

Re: Hotwire: HTML over the Wire

#362

Post by dsego »

antoineMoPa wrote: post #325
dsego wrote: post #196

Earlier quoted context omitted.

Between what? Your frontend is serving the html/css/js, that's your frontend. You can have another background service behind it, as many layers as you want. This separation doesn't have to be at the http level.

Let's say you take another approach. Build a backend that serves REST, GraphQL or whatever protocol. This can be a Rails backend, could be Python, JS, whatever. Now you or the frontend team are free to build the frontend with whatever technology. You can update it more freely to shining new JS frameworks because it is not entirely tied to your backend. Also, if your client/boss asks you to build a native IOS frontend…

> You can update it more freely to shining new JS frameworks because it is not entirely tied to your backend.

With proper architecture, you would have stores & services as the main boundary of your app. Then you can easily consume them in your server-side rendered pages or JSON API endpoints, which are then just thin wrappers.

>Also, if your client/boss asks you to build a native IOS frontend, you already have built an API, useful no?

My client wanted email forms to improve engagement. And it was not a theoretical request.

Re: Hotwire: HTML over the Wire

#363

Post by dragonwriter »

sourc3 wrote: post #120

This is so exciting to see, especially for older folk like me. Almost 20 years ago, one of my professors told us before graduation that hot tech is mostly about the idea pendulum swinging back and forth. I immediately chalked it up to 65+ above white wise men snobbery. However, this is exactly that. We started with static pages, then came Ajax and Asp.net and the open source variants, then we went full SPA, now we ar…

> then we went full SPA

Rails never did, and even actual SPA frameworks (e.g., React) have had SSR support/versions for quite a while. Basecamp introducing yet another iteration of front-end-JS dependent mostly-SSR for Rails isn't a pendulum swinging anywhere.

Re: Hotwire: HTML over the Wire

#366

Post by danjac »

newsbinator wrote: post #47

I'd like to try a version of this outside of Ruby/Rails.

I use Turbolinks for some Django projects, so took a look at how much work it would be to port these over to Hotwire/Turbo. Very little in the way of docs to go on right now and what little there is in the way of examples is buried in Rails gems. Should be mostly straightforward, with a thin Django middleware to check headers and the like. I guess The Turbo Stream stuff could be adapted to Django channels quite easily. I'll wait and see how and when they improve the documentation, especially on the Rails-agnostic front.

Re: Hotwire: HTML over the Wire

#367

Post by raihansaputra »

metta2uall wrote: post #354

Isn't this replacing the complexities of JS libraries like react/redux-saga with the complexities of these new server-side libraries..? Reduced bundle size looks like a big advantage & this will hopefully encourage the adoption of lighter front-end tech like preact/inferno/svelte. But the downside seems to be more resource consumption on the back-end, especially if using websockets, and so higher cost & more vulnerab…

Yeah, I'm interested about offline support. I might have to check out the HEY trial on web and on mobile.

I think this HTML SSR approach have different tradeoffs and uses compared to Single Page Applications.

The HTML SSR works best with a stable connection and being close to the server for good enough latency. Higher cost on the backend is a tradeoff on how much computation/complexity you want to offload to the client, and also what language/framework you want to work with more.

Some HN comments from previous related topics suggest these approaches (Hotwire / LiveView / Blazor? / StimulusReflex / Intercooler / HTMX / Unpoly) fare better with apps targeting a specific region so roundtrip latency is lower. One can optimize the reads with DB replicas + app servers closer to any user, but the write DB is the bottleneck (I think). This also ties in with the feedback that US/EU HEY/BC users perceive the app as snappy enough while AU users feel the latency a lot more.

SPA (properly built) should be more resilient in regards to network stability/condition/latency and expose a lot more offline capability.

I feel like the ideal app is HTML SSR + an app shell to serve some offline capabilities. Scaling the write DB globally is a hard problem though.

Re: Hotwire: HTML over the Wire

#368

Post by petee »

arvindamirtaa wrote: post #333
petee wrote: post #109

Earlier quoted context omitted.

Why wouldn't it? It's got like 2 pictures and isn't long. I also wouldn't call it wicked fast - this is normal speed, which everyone seems to have forgotten

Go ahead and load the hey login page. The js bundle your browser downloaded right there is the entire bundle for the whole email app. What size is it?

49kB, and for the most part it's not executing, so what's your point? There is no reason that shouldn't be fast, regardless

Not trying to stray too far from my original point, loading a small page with not alot going on should be fast. I'm not knocking Hey.com, I am just not going to pass out accolades for making a properly usable site!

Re: Hotwire: HTML over the Wire

#370

Post by danjac »

saltcod wrote: post #58

This all seems super cool, but mega complicated. I'm not in the Rails ecosystem at all, so would love someone's assessment. Is this a new, giant complexity or a nice add-on? A huge mental/development shift or a nicely paved new path to something better?

I've used Turbolinks/Stimulus with Django. I can't speak to the new hotwire stuff, other than the relatviely minor Stimulus2 changes.

Honestly it's pretty straightforward and the API is tiny. It's great for that grey area between serving server-loaded static pages and full-blown SPA - for example CRUD apps (and lots of things are pretty much CRUD apps). Turbolinks gives you a "poor man's SPA" for little effort (albeit with some gotchas) and Stimulus is fine, although it gets tedious for when you have to work with a lot of DOM elements e.g. "when I click the Subscribe button, change it to an Unsubscribe button". Maybe a less imperative framework like AlpineJS might be simpler.

Post reply on HN