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

251–260 of 573 posts

Re: Hotwire: HTML over the Wire

#251

Post by [deleted] »

fwip wrote: post #92
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…

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

[deleted]

Re: Hotwire: HTML over the Wire

#252

Post by yashap »

As others have noted, seems reasonably similar to LiveView, Livewire and Blazor. I’m somewhat bullish on these approaches - server side rendered monoliths (Rails, Django, etc.) are SO productive, at least for the first few years of development, but lack of interactivity is a big issue, and this solves it well.

However, another big issue is the dominance of mobile. More and more, you’ve got 2-3 frontends (web and cross-platform mobile, or explicitly web, iOS and Android), and you want to power them all with the same backend. RESTful APIs serving up JSON works for all 3, as does GraphQL (not a fan, but many are). This however is totally web-specific - you’ll end up building REST APIs and mobile apps anyways, so the productivity gains end up way smaller, possibly even net negative. Mobile is a big part of why SPAs have dominated - you use the same backend and overall approach/architecture for web and mobile.

I’d strongly consider this for a web-only product, but that’s becoming more and more rare.

Re: Hotwire: HTML over the Wire

#253

Post by greenyoda »

exabrial wrote: post #194
csixty4 wrote: post #191

Earlier quoted context omitted.

I'd take it back even further: We started out on mainframes. Then things moved to the desktop, with some centralized functionality on servers (shared drives, batch jobs). The processing moved to centralized web servers via the web, SAAS, and the cloud. Then more moved into the client through React & similar. And now things are moving back to the server. Tick. Tock. These changes are not just arbitrary whims of fashio…

Virtual machines, containers, very similar to partitions and spaces on mainframes as well.

Virtual machines are not a recent invention. They were already being used on IBM mainframes starting in the early 1970s:

https://en.wikipedia.org/wiki/VM_(operating_system)

Notably, the VM operating system could run an instance of itself in one of its own virtual machines.

Re: Hotwire: HTML over the Wire

#254

Post by blablabla123 »

phaedryx wrote: post #160
SahAssar wrote: post #41

I've never seen one of these "logic in html-attributes" systems take error checking seriously. In stimulus they start to mention it in "Designing For Resilience" (though only for feature-checking), but in "Working With External Resources" where it uses calls network/IO bound calls they never mention how to handle errors or if the framework just leaves it up to you. Stimulus is also where you need to write your own js…

Yes! 1. What if something goes wrong? 2. How do I test for handling success/error? They never address this stuff.

...also what is when response/request "items" are not handled chronologically due to load. I once wrote a real-time application with that pattern (HTML over AJAX). It worked but it was not enjoyable at all. Also literally every larger feature change would break the code because you had all these weird corner-cases.

Re: Hotwire: HTML over the Wire

#255

Post by Twirrim »

blorenz wrote: post #230
fmakunbound wrote: post #186

Earlier quoted context omitted.

I’m glad this technique is making a comeback. The last 10 years of JavaScript on the client have been an utter shit show that left me wondering wtf people were thinking.

You have the benefit of hindsight at this time. You can draw parallel to history of flight and all the crazy contraptions that people attempted. Great technology can emerge from the combination of numerous shit shows. The whole is greater than the sum of the parts.

> You have the benefit of hindsight at this time.

People have been pointing out it's a shit show with no end in sight for the entire duration of the phase. Pointing out the performance impact and cost to end users, how diabolical it is for those on lower latency or poorer network connectivity (i.e. most of the world), and so on.

Same thing as always happens with these pendulum swings, newer engineers come in convinced everyone before them is an idiot, are capable of building their new thing and hyping it up such that other newer engineers are sold on it while the "old guard" effectively says "please listen to me, there's good reasons why we don't do it this way" and get ignored. Worse, they'll get told they're wrong, only to be proven right all along.

I'm not denying there are obstructionist greybeard types that just refuse to acknowledge merits in new approaches, but any and all critique is written off as being cut from the same cloth.

It's perfectly possible to iterate on new ideas and approaches while not throwing away what we've spent decades learning ('Those who do not learn history are doomed to repeat it'), but tech just seems especially determined not to grow up.

Re: Hotwire: HTML over the Wire

#257

Post by werdnapk »

staticelf wrote: post #174
poxrud wrote: post #152

I'm curious how this is different from Turbolinks, which was been available since rails 3.

Turbolinks afaik, loads a larger part of a page upon hover and click, replacing all of the old html while this only updates the parts that has needs updating. This will prevent forms from being cleared or other state in the DOM to be wiped.

Exactly. Targeting specific sections of the page is pretty helpful when dealing with dialog content for example. If a dialog is open and you're managing something like the state of a form within that dialog, you don't want anything else outside of that dialog content being touched during a page update.

Re: Hotwire: HTML over the Wire

#258

Post by Twirrim »

epistasis wrote: post #241
blorenz wrote: post #230

Earlier quoted context omitted.

You have the benefit of hindsight at this time. You can draw parallel to history of flight and all the crazy contraptions that people attempted. Great technology can emerge from the combination of numerous shit shows. The whole is greater than the sum of the parts.

I'm not a front end engineer, but it always seemed crazy to me. I remember testing out the Google Web Toolkit when it came out more than a decade ago, and the craziest thing about it to me wasn't the Java --> JavaScript compilation, it was that the server just dumped an empty page and filled everything in with JavaScript on the client. Then, remember the awful awful #! URLs? Atrocious, and seemed like obviously a ter…

AWS used to rely on JWT for their consoles (haven't for a few years now, most folks migrated away some 5 years ago)

It's why they used to be horrendously bloated with large javascript bundles that took so long to process on the client side.

Roughly speaking the idea was "We don't have any Javascript developers, but we do have Java developers. JWT allows us to bridge that divide". Neat in theory, and an understandable decision, but diabolical in practice!

Re: Hotwire: HTML over the Wire

#259

Post by dsego »

jeroenhd wrote: post #146
vasachi wrote: post #130

Earlier quoted context omitted.

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…

Skeleton screens and spinners don't feel faster.

Re: Hotwire: HTML over the Wire

#260

Post by filmor »

epistasis wrote: post #241
blorenz wrote: post #230

Earlier quoted context omitted.

You have the benefit of hindsight at this time. You can draw parallel to history of flight and all the crazy contraptions that people attempted. Great technology can emerge from the combination of numerous shit shows. The whole is greater than the sum of the parts.

I'm not a front end engineer, but it always seemed crazy to me. I remember testing out the Google Web Toolkit when it came out more than a decade ago, and the craziest thing about it to me wasn't the Java --> JavaScript compilation, it was that the server just dumped an empty page and filled everything in with JavaScript on the client. Then, remember the awful awful #! URLs? Atrocious, and seemed like obviously a ter…

Hashbang URLs are gone because of the PushState API, not because people have given up on the idea.
Post reply on HN