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

141–150 of 573 posts

Re: Hotwire: HTML over the Wire

#141

Post by progressbwc »

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…

I can’t speak for Blazor but LiveView does not keep a DOM on the server nor it requires all UI interaction to go to the server.

Re: Hotwire: HTML over the Wire

#142

Post by hn_throwaway_99 »

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.

Interesting bit of history (and yes, I see the /s), XMLHttpRequest was actually invented by Microsoft in Explorer because the Outlook team needed better responsiveness for the web email client.

Re: Hotwire: HTML over the Wire

#143

Post by offtop5 »

domano wrote: post #100
axegon_ wrote: post #40

Earlier quoted context omitted.

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…

Just wanted to point out that it is called duct tape, just to avoid misunderstandings since i had a similiar spelling error as a non-native speaker :)

I'm a native speaker.

I use alot of Duck Tape .

From the little language study I've done, English is one of the most flexible. You can discard entire parts of speak and it still works.

Saying , ,'ey you woke up yet', is ok in many contexts.

Re: Hotwire: HTML over the Wire

#144

Post by ausjke »

SPA moves all the routing/templating to the browser side.

server side rendering does it all on the server and spits out html(legacy cgi style)

between these two: static html template downloaded from the server, then use ajax to update json in the html pages, which is the old boring way but it might still be the best middle ground?

Unless I need make a desktop complex GUI program where SPA could be a reasonable choice, I will just do the html/ajax old way, not fully geared towards to server or client side rendering, life is much easier.

Re: Hotwire: HTML over the Wire

#145

Post by jack_riminton »

Most of the comments here are along the lines of: this is old tech!

But this isn’t really about the tech, it as much a productivity hack that allows people to be much closer to that old fashioned concept of a full stack developer

This is what has allowed Basecamp to create Hey with a team just a fraction of the size of their competitors

Re: Hotwire: HTML over the Wire

#146

Post by jeroenhd »

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.

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 and the screen hasn't hung.

Minimal JS pages often have very little direct interaction built in, so they feel blazing fast when the connection is good and the payload is small (HN is a great example) but terribly slow if your internet connection is bad and it's not masking the network delays (again, HN is a great example).

The 2-5s mentioned on Twitter are something else though, perhaps the Hey app is being transferred through a saturated connection in the US or something.

Re: Hotwire: HTML over the Wire

#147

Post by dashesyan »

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.

Because the DOM can be updated client-side before the server responds

Re: Hotwire: HTML over the Wire

#148

Post by freedomben »

1f60c wrote: post #123

I wonder how long it will take before we reinvent SPAs? I like Hacker News in part because the tech is so boring. Server-side rendered, static HTML with a minimal amount of JS[0]. [0]: https://news.ycombinator.com/hn.js

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 lines of JS together." Also family members will tell me the same things.

Re: Hotwire: HTML over the Wire

#149

Post by naikrovek »

jshen wrote: post #102
naikrovek wrote: post #93

amazing. This used to be called /cgi-bin/ with templates and XMLHttpRequest (a Microsoft invention initially supported only in IE then adopted by everyone) and now it's suddenly a new technology/approach but with a new name so you're not ridiculed for using it? I gotta give them credit for revisiting server-side page assembling though; moving application logic and templating mostly to the front end was a HUGE mistake…

cgi-bin didn’t give you the ability to update a chat page across several different windows in near real-time.

It did if you used XMLHttpRequest.

Re: Hotwire: HTML over the Wire

#150

Post by Trasmatta »

dgb23 wrote: post #137
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…

I don't think this addresses all of what SPAs is used for. It seems to assume full-stack control.

It's specifically built for Rails, so yeah, it definitely assumes full-stack control.

And there are definitely applications I would prefer to write as an SPA over the Hotwire approach. But given that the vast majority of websites are just a series of simple forms, I prefer this approach over the costs you incur from building an entire complex SPA.

Post reply on HN