Hotwire: HTML over the Wire • Hacker News Board

Re: Hotwire: HTML over the Wire

#91

Post by [deleted] » Tue, Dec 22, 2020, 6:10 PM UTC

dhh wrote: post #39

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 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…

[deleted]

Re: Hotwire: HTML over the Wire

#92

Post by fwip » Tue, Dec 22, 2020, 6:11 PM UTC

axegon_ wrote: post #40

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.

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…

Surely your point could be made better without the hyperbole?

"Most outrageous and absurd language ever," "Megabytes of javascript", "corporate-grade bandwidth", "8th-gen i7 and 8GB of memory" to open "3 images and a contact form."

I'm sure you can find one or two poorly-optimized sites that have 2MB of javascript to download, but it's by no means the necessary outcome of using "ridiculous libraries and frameworks," and not even a particularly common one.

Re: Hotwire: HTML over the Wire

#93

Post by naikrovek » Tue, Dec 22, 2020, 6:14 PM UTC

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. JS is very fast now, but it's still absolutely glacial in its speed compared to server-side code written in compiled languages.

Re: Hotwire: HTML over the Wire

#94

Post by dsego » Tue, Dec 22, 2020, 6:14 PM UTC

antoineMoPa wrote: post #84

The downside of this is very high coupling between the frontend and the backend. However, many companies have been successful with strong coupling to Rails so maybe it's not a problem.

The backend here _is_ your frontend. Nothing stopping you from adding another service layer behind it.

Re: Hotwire: HTML over the Wire

#95

Post by shireboy » Tue, Dec 22, 2020, 6:15 PM UTC

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.

Glad I'm not the only one seeing that parallel. I'd be hesitant to use this for that reason, but maybe that's bias on my part? Just seems like you'd get stuck in a similar mess of "special" updatepanels aka hotwire frames that are trying to "save you from having to write javascript". Except it still uses javascript under the covers, so you still have whatever issues that may entail, only now it's more removed from the developer to be able to solve.

Re: Hotwire: HTML over the Wire

#96

Post by axegon_ » Tue, Dec 22, 2020, 6:15 PM UTC

rektide wrote: post #75

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…

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 se…

If by surprisingly little, you mean 4 pages and 500mb of requirements for a "hello world" project with the "modern" web, then yes. The DOM has always been a mess, much like javascript. And the fact that no one has tried to do something about it contributes to the mountains of duckt tape. It was bad enough when angular showed up, but when all the other mumbo jumbo showed up like react, vue, webpack and whatnot is when it all went south. I refuse to offend compilers and call this "compiling", but the fact that npm takes the same amount of time to "compile" it's gibberish as rustc to compile a large project(with the painfully slow compilation that comes with rust by design), is a clear indication that something is utterly wrong.

Re: Hotwire: HTML over the Wire

#97

Post by clarkevans » Tue, Dec 22, 2020, 6:15 PM UTC

antoineMoPa wrote: post #84

The downside of this is very high coupling between the frontend and the backend. However, many companies have been successful with strong coupling to Rails so maybe it's not a problem.

In many one-off applications there's no real need to create a separate API, tight coupling lets you focus on an MVP without having to focus on abstracting out an intermediate model -- you could go from the SQL database right to HTML rendering.

Re: Hotwire: HTML over the Wire

#98

Post by dsego » Tue, Dec 22, 2020, 6:16 PM UTC

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?

More complicated than having to deal with auth, routing, validation, xhr, application state, business logic in an SPA? And write your endpoints again with another round of routing, auth, validation, business logic. And then integrating everything.

Re: Hotwire: HTML over the Wire

#99

Post by dangoor » Tue, Dec 22, 2020, 6:17 PM UTC

antoineMoPa wrote: post #84

The downside of this is very high coupling between the frontend and the backend. However, many companies have been successful with strong coupling to Rails so maybe it's not a problem.

If you have a frontend that is entirely dependent on data from the backend to display something to the user, then you've already got high coupling between the two.

You probably wouldn't use this for a drawing app. But if you've got something where you're showing/updating database data, this model is likely fine.

Re: Hotwire: HTML over the Wire

#100

Post by domano » Tue, Dec 22, 2020, 6:18 PM UTC

axegon_ wrote: post #40

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.

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 :)