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

461–470 of 573 posts

Re: Hotwire: HTML over the Wire

#461

Post by hombre_fatal »

ZephyrBlu wrote: post #438
vasachi wrote: post #184

Earlier quoted context omitted.

Well, a spinner can be added even into non-SPA applications. So I don’t see how that is an argument for SPA. I presume you can lie to user by pretending that their change was instantly submitted, while syncing in background. In that case, yes, SPA all the way.

That's not really lying, it's good UX. Optimistic updates feel a lot better than waiting for something to happen.

This varies on how important the action is.

Optimistic updates are great for inconsequential stuff like an HN upvote. The user likely doesn't even want to see an error message if their upvote timed out.

But it definitely is "lying to the user", or better phrased "breaking user expectations". It's just that the user isn't likely to care except for important actions.

For example, imagine applying optimistic update to sending an email. The user would expect to be able to close their laptop after sending an email and seeing the UI transition. It would be catastrophic if the email was never actually sent.

Optimistic updates are best relegated to micro-polish imo. Frankly, I think it's overused especially in combination with autosave UI.

Re: Hotwire: HTML over the Wire

#462

Post by hu3 »

Osiris wrote: post #199
mdoms wrote: post #74

Spoiler, it's just Ajax but it pushes the data through your templates before sending it to the client. We were doing this literally over a decade ago in the early days of XHR.

I have a small website and I have one page with an order form and I show a modal with the result of the order. This is how I do it. The Ajax calls gets back HTML that it shoves into the modal. It was just easier than writing JS with templates and parsing JSON. It always felt icky to me because that's not the way you're "supposed" to do it, but it works quite well.

A client of mine has an entire internal Line of Business application built on that mechanic: backend returns javascript to shove HTML somewhere. The trick is that the js is built automatically based on components. Devs rarely have to touch js.

It's lightweight on the frontend and a pleasure to develop for since forms are entirely coded on the backend with components. On rare exceptions more complex pages have some sprinkled lodash.js.

They have around 400 CRUD pages with complex business validations. Up to 1.5k concurrent users. At that point MySQL starts to sweat a bit and p95 increases above 200ms. All running on 2 machines: a nginx+phpfpm and a MariaDB.

The instant no-compilation feedback loop of edit-save-refresh is orgasmic. That system opened my eyes to a lot of preconceptions and buzzwords I once held sacred.

Re: Hotwire: HTML over the Wire

#463

Post by msie »

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.

We need something like XMLHttpRequest right now. Google should integrate Dart into Chrome.

Re: Hotwire: HTML over the Wire

#466

Post by IggleSniggle »

jolux wrote: post #423
rorykoehler wrote: post #235

Earlier quoted context omitted.

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…

I also love the animations in macOS, but fwiw each version of iOS feels like a step backwards for usability to me.

Re: Hotwire: HTML over the Wire

#467

Post by recursivedoubts »

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…

in htmx we trigger an htmx:responseerror:

https://htmx.org/events/#htmx:responseError

in general, the right approach in HTML-oriented, declarative libraries appears to be triggering error events and allowing the client to handle them, since it is too hard to generalize what they would want

Re: Hotwire: HTML over the Wire

#468

Post by zelly »

esroyo wrote: post #326

Generally people argue that static HTML is more energy efficient than server side rendering. I wonder If that is true in the case of static HTML "that loads an SPA", versus a server-side rendering with a proper cache in place. The SPA loading will still consume good energy on each client computer. Would love to see some numbers. Lots of hype, lots of projects and approaches, and lots of opinons about what is more con…

My intuition is that network transfer uses almost no energy, on a marginal basis, because the network links are always on anyway. When you pay for bandwidth, you're paying the amortized costs of building and maintaining the infrastructure.

Rendering a SPA on a client device consumes CPU time, which definitely uses energy proportional to the number of client devices.

Assume the server uses less clock cycles to render than the client--e.g., because of optimized software, hot caches, or tuned hardware.

Therefore rendering on the server should always be more energy efficient than on the client.

Re: Hotwire: HTML over the Wire

#469

Post by DaiPlusPlus »

ZephyrBlu wrote: post #420
mywittyname wrote: post #298

Earlier quoted context omitted.

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.

Or just... use indexes.

Re: Hotwire: HTML over the Wire

#470

Post by IggleSniggle »

danielsokil wrote: post #290
modernerd wrote: post #273

Pure JS developers trying to jump off the JS train have a few decent choices now: - Elixir / Phoenix - .NET / Blazor - Laravel / Livewire - Rails / Hotwire Or hold on for the JS ecosystem to figure out good patterns that balance performance/maintainability (React Server Components look ok, and will probably trickle into Next.js for those who want a framework). Does one of the above stand out as a good thing to learn…

Also IHP (Haskell) has Auto Refresh https://ihp.digitallyinduced.com/Guide/auto-refresh.html

Thanks for reminding me about this. I really want to give IHP a try. Seems like a really nice design.
Post reply on HN