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

81–90 of 573 posts

Re: Hotwire: HTML over the Wire

#81

Post by eecks »

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 agree. This seems complex but I am NOT a rails developer. The least complex stack I can find is Svelte (with Sapper) on the front end that calls out to API made in Spring Java.

That lets me have quick development on the frontend, server side rendering for fast first page load and use of a typed language for the backend. The client is also overburdened with a large JS framework.

Re: Hotwire: HTML over the Wire

#82

Post by BryanBeshore »

simonw wrote: post #62
BryanBeshore wrote: post #30

Earlier quoted context omitted.

Any idea how many people use Hey.com? That might be an early indication as to how scalable this is (at least for hotwire's concerns)

GitHub scales just fine on their own variant of Turbolinks.

Agreed. My comment about scaling is simply that a lot of other companies use rails at scale, and alike that of hey.com (which I presume is heavily used) it is probably built to... scale

Re: Hotwire: HTML over the Wire

#83

Post by OJFord »

'HTML over the wire' is an unfortunate tagline, but it does actually seem interesting, I'd suggest looking at the 'Turbo' docs before reacting.

I have thought in the past I wish I could have a frameworky component-style frontend, but where the component is HTML rendered by my rust (or whatever) backend. This would seem to get me a lot closer to that.

Re: Hotwire: HTML over the Wire

#85

Post by sfvisser »

wejick wrote: post #19
paxys wrote: 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".

It's actually not as simple as that. The simplification is too brutal and doesn't appreciate the details. It's the answer for people that sick of the weight of modern webapp, where everything need to be rendered client side.

Honestly, my experience is that most webapps aren’t that heavy for what they actually do.

Web sites are heavyweight, serving megabytes of useless nonsense just to display an article. With a bunch of ads obviously.

Re: Hotwire: HTML over the Wire

#86

Post by Trasmatta »

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?

> mega complicated

I would argue it looks a lot simpler than the average SPA framework or library.

Re: Hotwire: HTML over the Wire

#87

Post by ksec »

BryanBeshore wrote: post #30
elamje wrote: post #26

This is the Ruby on Rails version of what Elixir Phoenix Live View and .NET Blazor do. For those not familiar, rather than using a standard web framework where a lot of processing is done client side, these frameworks allow html buttons etc to call native Ruby, C#, or Elixir functions on the server rather than using some sort of post/get request to do that. Every UI interaction goes over the wire, which is where perf…

Any idea how many people use Hey.com? That might be an early indication as to how scalable this is (at least for hotwire's concerns)

Well Rails was never not scalable in literal sense. It was just the cost of scaling being expensive; comparatively speaking when people say Rails not able to scale. And for most if not all SaaS that should never be much of a problem. Because you are getting revenue per user, and generally speaking the cost percentage of user / app / server resources is so small, that is a rounding error in grand scheme of things.

What doesn't work quite as well is when the app is operating a freemium / ad based model. Where a large volume of traffic are required before you start generating revenue.

Re: Hotwire: HTML over the Wire

#88

Post by staticelf »

I love that these new techniques come out to make web dev simple again. I however think Phoenix Liveview is still the best from all the alternatives I have seen so far and that is mainly because Elixir as a language seems to be very stable and suited for having a lot of websocket connections open at the same time.

It seems easier to accomplish this with Liveview and perhaps Alpine.js for displaying stuff like modals etc. It's a really good way to build applications I think for places that need a server roundtrip anyway which is most of the stuff in a modern app.

I write a SPA app for work in javascript and about 90% of the issues that occurs are mainly state issues where the state differs or is in a bad state for some reason. State management is very hard to do right and I think solutions like these simplyfies it a lot!

I urge people to check out Elixir and Phoenix Liveview which I think is the "original gangsta" when it comes to sending small updates over websockets and if you try it I will guarantee you will be blown away of the speed of which you can develop web apps as a solo dev.

Re: Hotwire: HTML over the Wire

#90

Post by aantix »

elamje wrote: post #26

This is the Ruby on Rails version of what Elixir Phoenix Live View and .NET Blazor do. For those not familiar, rather than using a standard web framework where a lot of processing is done client side, these frameworks allow html buttons etc to call native Ruby, C#, or Elixir functions on the server rather than using some sort of post/get request to do that. Every UI interaction goes over the wire, which is where perf…

It's not keeping a copy of the DOM server-side..

That's not how it works, at all.

Post reply on HN