Hotwire: HTML over the Wire • Hacker News Board

Re: Hotwire: HTML over the Wire

#421

Post by ziftface » Wed, Dec 23, 2020, 2:01 AM UTC

still_grokking wrote: post #411

resu_nimda wrote: post #409

Earlier quoted context omitted.

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.

But what about users who actually prefer some web applications, like the user you responded to? To them, the web application is the hammer. I mean really who gets to decide which is better besides the user?

Re: Hotwire: HTML over the Wire

#422

Post by nickjj » Wed, Dec 23, 2020, 2:01 AM UTC

sb8244 wrote: post #373

nickjj wrote: post #209

Earlier quoted context omitted.

> How does Hotwire compare to Phoenix LiveView? It seems the same to me. It's much different based on a preliminary reading of Hotwire's docs. Live View uses websockets for everything. If you want to update a tiny text label in some HTML, it uses websockets to push the diff of the content that changed. However you could use LV in a way that replaces Hotwire Turbo Drive, which is aimed at page transitions, such as goi…

Fwiw, you can use long polling for LiveView if you wanted. That could completely remove websockets as everything happens over http. Hotwire will benefit from caching better than LiveView, because frames are distinct URLs. But I haven't personally need that.

> Fwiw, you can use long polling for LiveView if you wanted.

How does that work for page transitions? The docs don't mention anything about this or how to configure it.

With Turbolinks or Hotwire Turbo Drive, the user clicks the link to initiate a page transition and then the body of the page is swapped with the new content being served over HTTP. With Turbo Frames the same thing happens except it's only a designated area of the page. In both cases there's no need to poll because the user controls the manual trigger of that event.

How would LV do the same thing over HTTP? Everything about LV in the docs mentions it's pretty much all-in with websockets.

Then there's progressive enhancement too as another difference. Turbo is set up out of the box to use controllers which means you really only need to add a tiny amount of code (2-3 lines) to handle the enhanced experience alongside your non-enhanced experience. For example you could have a destroy action remove an item from the dom when enhanced using Turbo Stream or just redirect back to the index page (or whatever) for the non-enhanced version.

There's an example in the Turbo docs for that at https://turbo.hotwire.dev/handbook/streams if you search for "def destroy".

But with LV wouldn't you need to create both a LV and a regular controller? That's a huge amount of code duplication.

Although to be fair I would imagine most apps would require JavaScript to function so that one is kind of a non-issue for most apps, but it's still more true to the web to support progressive enhancement and the easier you can do this the better.

Re: Hotwire: HTML over the Wire

#423

Post by jolux » Wed, Dec 23, 2020, 2:03 AM UTC

rorykoehler wrote: post #235

freedomben wrote: post #148

Earlier quoted context omitted.

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

Do people really want that stuff out do they just think they want it?

I'm a developer and I definitely want that stuff some of the time. On platforms that can handle it, absolutely. I love all the animations in macOS and I always have. GNOME and Windows are nice but they don't feel like home in the same way, they don't have sophisticated and fluid animations.

They need to be performant and they need to improve the usability of the system, not reduce it. That's the criteria. It's often not achievable with the web, though people try.

Re: Hotwire: HTML over the Wire

#424

Post by still_grokking » Wed, Dec 23, 2020, 2:03 AM UTC

bird_monster wrote: post #413

still_grokking wrote: post #406

Earlier quoted context omitted.

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

Doing an "apt install", or just clicking install in some GUI, isn't such a big deal as you're pretending.

I've heard of systems where it's a bit more fuss. But that's a problem with their software distribution model respectively.

Re: Hotwire: HTML over the Wire

#425

Post by claudiawerner » Wed, Dec 23, 2020, 2:05 AM UTC

bird_monster wrote: post #403

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…

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…

Yeah, it doesn't make sense to me. Consider this from the developer's point of view, and every single developer will tell you they'd rather make Javascript and some HTML rather than GTK application in C, especially when it'll work on every platform except maybe Plan 9.

Re: Hotwire: HTML over the Wire

#426

Post by mhh__ » Wed, Dec 23, 2020, 2:06 AM UTC

philote wrote: post #238

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.

Same. And I'm still amazed that people loved JS so much they put it on the SERVER too! And now node/npm is everywhere.

I think a huge amount of that success is because JS is cheap to hire, i.e. Node is fast enough so why bother using a good language (cynically).

Anecdotally, most people I see who really really love JavaScript are kids who haven't really don't much else.

Re: Hotwire: HTML over the Wire

#427

Post by dmos62 » Wed, Dec 23, 2020, 2:07 AM UTC

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…

This doesn't apply to all tech. Web just doesn't have a good solution because it's so complex. You'll always be making compromises. Some compromises are trendier than others at any given time. IMO, simple tech you don't have to think about, it's usage doesn't have "pendulum" effects. You forget it's there.

Re: Hotwire: HTML over the Wire

#428

Post by bird_monster » Wed, Dec 23, 2020, 2:09 AM UTC

still_grokking wrote: post #424

bird_monster wrote: post #413

Earlier quoted context omitted.

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

Doing an "apt install", or just clicking install in some GUI, isn't such a big deal as you're pretending. I've heard of systems where it's a bit more fuss. But that's a problem with their software distribution model respectively.

> Doing an "apt install", or just clicking install in some GUI, isn't such a big deal as you're pretending.

To you. Software devs are rarely the targets of the products they build.

Also, I am not pretending. It was my job for several years.

Re: Hotwire: HTML over the Wire

#429

Post by benatkin » Wed, Dec 23, 2020, 2:10 AM UTC

I'm currently more interested in processing content as JSON serializable abstract syntax trees, whether it comes from Markdown, HTML, or something else. The popular Markdown renderer Remark (https://remark.js.org/) supports this. It's based on Unified.js which has markdown abstract syntax trees (mdast) and HTML abstract syntax trees (hast). https://unifiedjs.com/

Re: Hotwire: HTML over the Wire

#430

Post by hinkley » Wed, Dec 23, 2020, 2:10 AM UTC

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…

Which I find frustrating because literally the only reason I find compelling for making an SPA in the first place is to deal with flaky networking situations.

If I know the network is always there, why bother.