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

291–300 of 573 posts

Re: Hotwire: HTML over the Wire

#291

Post by mruniverse »

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…

Around the time that GWT came out, offshoring was a big thing. And most of the contractors only knew Java. Also Java was the trusted language and javascript was not.

Re: Hotwire: HTML over the Wire

#292

Post by cleaver »

csixty4 wrote: post #191
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'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…

Yes. I have thought about this a lot. There are cycles...

Like thin client (VT100), to thick (client/server desktop app), to thin (browser), etc.

Similarly, console apps (respond to a single request in a loop), to event-driven GUI apps, to HTTP apps that just respond to a simple request, back to event-driven JS apps.

It depends on how you define the boundaries, but history rhymes.

Re: Hotwire: HTML over the Wire

#293

Post by inopinatus »

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.

They do already address error handling. GP is shooting the breeze here, evidently has no specific knowledge of Turbolinks family API or behaviour.

Re: Hotwire: HTML over the Wire

#294

Post by nickjj »

codethief wrote: post #272

In case anyone from Basecamp sees this thread: The introductory video is far too long, far too technical (I know a lot about web dev but don't know a lick of Ruby or Rails) and far too fast to follow. I was really interested in Hotwire because of the comments here and now… not so much anymore. (Which of course doesn't say anything about the quality of the tech. I just thought I'd post my first impression of the websi…

I'm not from Basecamp but it's interesting you mentioned it's too fast. I noticed that too and this is coming from someone who listens and watches everything at 2x speed.

I've seen a lot of DHH's talks and demos and never had a problem listening to them at 2x. This is the only time where it feels like he scripted out the entire video word for word and then talked over a screen recording that was recorded separately from his voice. This video sounds nothing like what he normally sounds like (both tone and speed). I really wonder if he recorded this in a booth.

Re: Hotwire: HTML over the Wire

#295

Post by vp8989 »

dsego wrote: post #245
madmulita wrote: post #211

Earlier quoted context omitted.

And serverless is an anemic CICS executing non-transactions.

Serverless is kind of like Apache running PHP scripts in virtual hosts.

The greatest trick the devil ever pulled is convincing people that shared hosting is preferable to dedicated, and then charging them way more money for it.

Re: Hotwire: HTML over the Wire

#297

Post by SahAssar »

Nextgrid wrote: post #222
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…

Counterpoint: is there any error handling in the majority of SPAs today? From my experience, SPAs can crap out in all kinds of interesting ways when the underlying network connection is flaky and I often end up stuck on some kind of spinner that will never complete (nor give me a way to abort & retry the operation when I already know it won't complete and don't want to wait for the ~30-second timeout, if there is a t…

I agree that most SPA apps do it badly too, but hiding the opportunity to do it well certainly does not help.

> there is no state and it should thus be safer and quicker to reload the page should things go wrong.

That's not exactly true since there are non-idempotent HTTP methods and while the browser will prompt you if you want to resend a non-idempotent HTTP request when refreshing a normal form POST I don't think that turbo/turbolinks/similar will allow you to prompt or resend.

On refresh should turbo retry a POST? The "right way" is to keep the state of the last POST and prompt the user for confirmation, but it seems like it is undocumented as to what it does. I'm guessing it either does not retry or it retries and hopes effect will be idempotent.

No one (SPAs, traditional webpages and "spiced" webpages like this included) is doing everything right, but my objection to this framework is that it seems to try to say things are simple or easy when they clearly aren't.

Re: Hotwire: HTML over the Wire

#298

Post by mywittyname »

cyrialize wrote: post #261
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 completely agree with this. For reference, I'm a relatively new developer - 3.5+ years of experience in my first developer position. At the beginning of college everyone was SUPER into NoSQL. All my friends were using it, SQL was slow, etc. Nearing the end of college and the beginning of my job I began seeing articles saying why NoSQL wasn't the best, why SQL is good for some things over NoSQL, etc. Technology is c…

The NoSQL trend was so terrible. Anyone starting out right in that time frame where mongo and other NoSQL DBs were getting popular was really done a disservice.

I sit in design meetings all the time where people with I helped out on one project lead by a few younger devs who chose FireStore over CloudSQL for "performance reasons" (for an in-house tool). They had to do a pretty major rewrite after only a few weeks once they got around to deleting, because one of their design requirements was to be able to delete thousands of records; a trivial operation in SQL, but with FireStore, deleting records requires:

> To delete an entire collection or subcollection in Cloud Firestore, retrieve all the documents within the collection or subcollection and delete them. If you have larger collections, you may want to delete the documents in smaller batches to avoid out-of-memory errors. Repeat the process until you've deleted the entire collection or subcollection.

> Deleting a collection requires coordinating an unbounded number of individual delete requests.

Turns out, once they started needing to regularly delete thousands-millions of records, the process could run all night. Luckily, moving over to CloudSQL didn't take very long...

Re: Hotwire: HTML over the Wire

#299

Post by webmaven »

edoceo wrote: post #128
domano wrote: post #100

Earlier quoted context omitted.

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

Check out Gaff Tape as a replacement for the duct-tape at home use-case. And for actual ducts you'll want to use foil-tape because temperature changes wreck the adhesion of duct-tape, then the moisture leaks into the walls/ceiling which is $$$$ bad.

> And for actual ducts you'll want to use foil-tape because temperature changes wreck the adhesion of duct-tape, then the moisture leaks into the walls/ceiling which is $$$$ bad.

This strongly depends on the type of duct. Flex ducts that are a plastic skin over a wire coil don't work so well with aluminum tape.

Re: Hotwire: HTML over the Wire

#300

Post by Trasmatta »

devwastaken wrote: post #289
Trasmatta wrote: post #281

Earlier quoted context omitted.

Literally nobody is saying this

They are, look at the context of what they're saying. JS is simply a programming language in a VM like plenty of others, there's nothing inherently bad about it. But every thread here's the uneducated hate for it, completely misunderstanding that html/css static pages don't solve the problems a programming language does. I'd like to see these people make applications in pure XML. No programming.

No, the argument has never been "replace all JS with static HTML/CSS". The argument is "JavaScript frontends are becoming unnecessarily bloated, slow, and complicated, and we can do better". Solutions like the one Basecamp is proposing with Hotwire include pushing as much rendering logic as possible to the server, where you're using a language like Ruby for logic. Nobody thinks you can just remove all logic from a web application unless it's literally just static content.

And even with Hotwire, you're not getting rid of JavaScript entirely. You can write it with Stimulus. The idea is just that frontend web development has become a mess, and it's possible to simplify things.

> there's nothing inherently bad about it

Disagree.

Post reply on HN