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

411–420 of 573 posts

Re: Hotwire: HTML over the Wire

#411

Post by still_grokking »

resu_nimda wrote: post #409
still_grokking wrote: post #399

Likely an unpopular opinion. But anyway. I think the presented thingy is fundamentally wrong. It's just another attempt to put the square peg in a round hole. The point is: "The web" is not, and never was, a framework for application development! It's the wrong tool. No matter how hard you try. You want to build applications? Use tools that where build from the ground up to support application development. On mobile…

I can't remember the last time I opened a native email or word processing application on desktop. I much prefer the web experience. What makes it the wrong tool? What's the point of these silly rules? You want to build applications? Use whatever freakin tool or platform your users will adopt. Don't be constrained by pointless prescriptivism.

It's not a "silly rule" that the web is not for application development. It's about the technology as such!

An example what I mean: One can use a stone to put nails into a wall. But a hammer is clearly the better tool for that task.

Re: Hotwire: HTML over the Wire

#412

Post by wwweston »

yashap wrote: post #252

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

> RESTful APIs serving up JSON works for all 3, as does GraphQL (not a fan, but many are). This however is totally web-specific

HTML is a machine-readable format, like XML and JSON. Have your back end represent a given resource as microformatted-semantic markup, send it gzipped over the wire, and you've got the data exchange you need, even if your mobile app isn't already dressed-up webview.

Re: Hotwire: HTML over the Wire

#413

Post by bird_monster »

still_grokking wrote: post #406
bird_monster wrote: post #403

Earlier quoted context omitted.

Best of luck getting paying users to install each individual desktop application, as opposed to installing a browser and then navigating to multiple applications without any additional desktop/native work. I guess there might be space for something like Steam, but for business apps, but I just don't see it. The argument "This isn't what the web was made for" is kind of a cowpath argument. The web is being used to (am…

People are installing apps for "everything" on mobile. Even for stuff where a web page exists and is fully sufficient. The rest is just: "But with a big enough hammer we get the square peg into the round hole, so what's wrong with that? People are doing that the whole time. Seems fine".

Right, and when there is a viable app store that might be possible for desktop environments (the exact reason I brought up steam). Until then, though, desktop apps are just a unanimous negative most of the time (from a "get users to actually use our software" perspective).

edit I am speaking from the experience of trying to build a desktop app. I think people suggesting "Just build a desktop app" have no idea the amount of feedback that gets received to the tune of "Why do I have to download an app". It's staggering.

Re: Hotwire: HTML over the Wire

#414

Post by Nextgrid »

SahAssar wrote: post #297
Nextgrid wrote: post #222

Earlier quoted context omitted.

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…

I believe the only place you'd use a POST with Turbolinks is in response to an explicit user action like pressing a button. In this case, if it fails, you'd refresh the root page (which embeds the button) at which point the state of that page would reflect whatever the server has, so it would display the new data or may not even have the button anymore if the initial POST actually did make it to the server.

Re: Hotwire: HTML over the Wire

#415

Post by merb »

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.

webforms is dead, long live webforms.

Re: Hotwire: HTML over the Wire

#416

Post by mshenfield »

The downside is that this makes it really easy for developers to avoid making an actual API. The turbo frames _are_ the API. Great to bootstrap, but miserable if you ever want to implement a native mobile app (or any other client) on top of the same codebase.

Re: Hotwire: HTML over the Wire

#418

Post by still_grokking »

nerdponx wrote: post #407
still_grokking wrote: post #399

Likely an unpopular opinion. But anyway. I think the presented thingy is fundamentally wrong. It's just another attempt to put the square peg in a round hole. The point is: "The web" is not, and never was, a framework for application development! It's the wrong tool. No matter how hard you try. You want to build applications? Use tools that where build from the ground up to support application development. On mobile…

So what? Modern web browsers turned out to be a great application runtime and the Web turned out to be a great delivery platform. Nowhere else in software engineering would you see so much resistance to a perfectly good tool. Maybe the problem is that it's too good: people and organizations end up producing "web applications" instead of "web sites" just because the technology is so readily available and so widespread…

If the status quo would work as great as alleged we wouldn't discuss the article as we just do... ;-)

Modern browsers are completely crazy bloat-ware. Bigger by lines of code than most operating systems! Things like the JVM become small and lightweight compared to a modern browser.

And still, it's not a "great application runtime" - as people still not even found out how to use it "properly" as one (as again: that's the point of the article we're discussing).

That people everywhere do irrational stuff all the time is also no prove that anything of that stuff makes any sense at all. Things don't become smart only because there are more people out there doing the same thing. Actually the mass isn't doing the smartes things at all usually. So that's imho a quite bad benchmark for anything anyway. ;-)

Re: Hotwire: HTML over the Wire

#419

Post by satyrnein »

wwweston wrote: post #412
yashap wrote: post #252

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

> RESTful APIs serving up JSON works for all 3, as does GraphQL (not a fan, but many are). This however is totally web-specific HTML is a machine-readable format, like XML and JSON. Have your back end represent a given resource as microformatted-semantic markup, send it gzipped over the wire, and you've got the data exchange you need, even if your mobile app isn't already dressed-up webview.

Are you still referring to dedicated API routes, or are you talking about annotating your UI to the point where it can serve as the API as well? I remember the latter being the vision behind things like RDFa, but those approaches never took off, for a variety of reasons.

Re: Hotwire: HTML over the Wire

#420

Post by ZephyrBlu »

mywittyname wrote: post #298
cyrialize wrote: post #261

Earlier quoted context omitted.

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

> I sit in design meetings all the time where people with I mean, this is just dumb. I have less than 5 years experience and I understand that SQL isn't "slow", there are just different tradeoffs between SQL and NoSQL databases and you have to pick the right tool for the job.
Post reply on HN