Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving from React to htmx

htmx.org

Post reply on HN
Print view View original

291–300 of 326 posts

Re: Moving from React to htmx

#291

Post by tomhallett »

danielvaughn wrote: post #78

Some years ago, a bright guy created something called 7 GUIs. It’s a collection of seven problems that all UI systems must successfully implement, and it was intended to act as a guide for comparisons. Unfortunately I think the author has passed away, but it would be interesting to see it rekindled and used for baseline comparisons like these. https://eugenkiss.github.io/7guis/

Wow, this is very cool! I think this applies not only to gui frameworks (react vs htmx), but also to design systems (bootstrap, tailwind ui, etc).

Re: Moving from React to htmx

#292

Post by tomhallett »

As I was reading https://htmx.org/, I kept thinking "Oh crap, yet another framework ripping off intercooler/alpine. Why?". Then I when I got to the bottom, I read that it's a rebrand/rename of intercooler, which gives me a lot more confidence/trust about the project. I would recommend putting the "htmx 1.0 = intercooler 2.0" at the top of the htmx website, similar to the intercooler website.

Note: while the htmx homepage is short, I spent about 30 seconds reading/thinking about each "motivation" bullet point, and my monkey brain is very content jumping to conclusions about the project at a much faster pace, :).

Re: Moving from React to htmx

#293

Post by pier25 »

hunterb123 wrote: post #281
adamckay wrote: post #215

Earlier quoted context omitted.

> Gmail is the perfect use case for an SPA Is it really, though? It's a paginated list of emails, some drag-and-drop functionality, buttons for some ajax functionality. It works reasonably well, but it doesn't need to be so high Javascript compared to Google Docs or maps.

Viewing your emails offline is pretty important.

And being able to use Gmail (search emails etc) while writing an email too

Re: Moving from React to htmx

#294

Post by spion »

pwdisswordfish0 wrote: post #288
spion wrote: post #274

Earlier quoted context omitted.

There is always client-side state. The dropdowns, for example, have selection that affects the entire app. That selection must be stored in a state which will affect the reloads triggered by changes in the dropdowns.

Well, sure, the value of an input is in its value property, but you build your stuff in such a way that you don’t access it unless you absolutely have to.

Did you actually watch the video? The things are built in such a way that there is global state shared among components.

Re: Moving from React to htmx

#295

Post by jpe90 »

singularity2001 wrote: post #264
jpe90 wrote: post #169

Earlier quoted context omitted.

that's a good reason to invest in self hosting! https://git.jeskin.net/hiero-wiki/file/%F0%93%83%80.md.html

oh, thanks for cloning! but [[links]] dont work and other (internal)[links] don't link to markdown.md.

gah, you're right. perhaps that could be fixed with a few clever grep/sed incantations. very interesting repo if you're the author, by the way.

Re: Moving from React to htmx

#296

Post by ahungry »

withinboredom wrote: post #173
singularity2001 wrote: post #156

Earlier quoted context omitted.

Github does? Maybe that's the reason why I often get the error message: "page took too long to render" after ten seconds of waiting. example: https://github.com/pannous/hieros/wiki/%F0%93%83%80 this is admittedly a complicated markdown file, however it often fails on much simpler files.

I hate it when devs implement their own timeouts. That’s handled at the network level, and the socket knows if progress is being made. I was stuck using 2G data speeds for a couple of years and I loathed this behavior.

Sometimes the infrastructure causes this. For a long time (and now?) AWS Api Gateway has a hard cap of 30 seconds, so the sum of all hops along the way need to remain under that.

Re: Moving from React to htmx

#297

Post by lliamander »

criddell wrote: post #286
lliamander wrote: post #280

Earlier quoted context omitted.

I think you have it backwards. If you want to build a client using HTML, then targeting the browser is exactly the right choice. Javascript-heavy SPAs are much closer to traditional native apps - and lose some of the benefits of running on the web/ in the browser as a result. There's a lot more reason to consider native app if you are building an SPA than if you are building an MPA/SSR app.

I'm suggesting not using HTML for the client. Anything running in a browser is heavy and slow compared to well written native code.

I think there's an argument for HTML-focused clients - the whole web (including this site) benefits from hypermedia.

I'm less convinced about Javascript SPAs. Perhaps the biggest advantage is that you don’t have to "install" these apps. The browser just downloads the source and runs it automatically in a (somewhat) sand-boxed environment. Also, they work on "most" systems (though mobile vs. desktop is still a thing).

Re: Moving from React to htmx

#298

Post by pwdisswordfish0 »

spion wrote: post #294
pwdisswordfish0 wrote: post #288

Earlier quoted context omitted.

Well, sure, the value of an input is in its value property, but you build your stuff in such a way that you don’t access it unless you absolutely have to.

Did you actually watch the video? The things are built in such a way that there is global state shared among components.

I did watch the video, iirc he literally says “is this client-side state I have to worry about? No.” multiple times. When the user changes something that affects the UI in multiple places, all the necessary fragments are fetched from the server and swapped in by htmx.

Re: Moving from React to htmx

#299

Post by ColonelPhantom »

tomhallett wrote: post #292

As I was reading https://htmx.org/ , I kept thinking "Oh crap, yet another framework ripping off intercooler/alpine. Why?". Then I when I got to the bottom, I read that it's a rebrand/rename of intercooler, which gives me a lot more confidence/trust about the project. I would recommend putting the "htmx 1.0 = intercooler 2.0" at the top of the htmx website, similar to the intercooler website. Note: while the htmx hom…

I believe HTMX is also a rewrite (at least to some degree) of Intercooler, as it uses vanilla JS instead of jQuery.

Re: Moving from React to htmx

#300

Post by ChrisDevx »

samwillis wrote: post #7

Love htmx and this talk is a brilliant run down of where it works well. But as always it’s about choosing the right tool for the job. Server rendered pages/fragments solve so many issues around security and time to develop a product, however it only gets you so far. Ultimately I think the decision when choosing a stack comes down to how much state you need to managed in browser. The vast majority of sites needs very…

I have 2 problems with htmx (IMHO):

1. SoC: the server API needs to return only the data and meta data requested, and it should not be concerned with the display-layer (html), because many different clients i.e. mobile app, browser, Electron etc. might want to consume this API.

2. Logistics & scaling: Imagine a large application with 100s of html/htmx components and views, now you alter your database, you introduce new business rules etc... If you used React or Alpinejs etc. you could just go to the relevant stores or app code and make the change as opposed to sifting and refactoring tons of html.

Personally I'd rather just use Alpinejs from the start, knowing its lightweight, fast and easy to implement, and not end up painting myself into a corner over the application lifecycle.

Post reply on HN