Live data from Hacker News

Moving from React to htmx

htmx.org

91–100 of 326 posts

Re: Moving from React to htmx

#91

I consider this an alternative development approach neither better or worse than what it is trying to replace. The winner in recent approach, imo, is Remix Run.

For literally every developer on the planet who is not an expert JavaScript developer—or who doesn't wish to be—this is undoubtedly a better development approach. Saying "Remix is the winner" doesn't really move the needle. It's still JavaScript, still React—just with some work pushed to the server instead of the client. The contract of the web is that while the client-side language in use may not be up to the discre…

> It's still JavaScript, still React—just with some work pushed to the server instead of the client.

This is being too reductive of the design of Remix. It is closer to traditional web applications in handling form submissions. There's no client-side state management needed for those use cases.

Whether it's the "winner" or not, really depends on use case, but it is decently different than a traditional SPA.

Re: Moving from React to htmx

#92
post #59

Htmx is great for developers who need client side interactivity, but would rather not write any js. If you don't mind writing a bit of js however, you can't go wrong with Preact. Same api as React, but at a fraction of react-dom's bundle size. It looks like the minified source is even smaller than htmx (which is already very minimal) [1][2]. They've also packaged Preact in such a way that you don't need to add a buil…

I was just picking technology for my new landing page and was looking into Preact first. I wanted basic SSR and things like that. Preact has a library called preact-cli for this. The last commit is from Aug 17. I ended up with SvelteKit. It just felt much more alive. I don't love learning a new technology just for a landing page, but that was kinda fun.

> The last commit is from Aug 17. I ended up with SvelteKit. It just felt much more alive.

I don’t understand - are you saying you think a project whose most recent commit was Aug 17, 2022 is not alive?

Re: Moving from React to htmx

#93

Earlier quoted context omitted.

The slippery slope that scares me (as a React developer) about htmx (or Hotwire.dev, in particular is the one I was looking at), is that you start making the assumption that the client's internet is fast. There was demo that showed it normally takes ~100ms to click a mouse, and if you attach to the on-mouse-down, then by the time the mouse has been released (100ms later), you can have already fetched an updated rende…

As someone who has been writing code for 30 years and has been developing "web apps" since the late 90s, it's really funny to me how things come full circle. You just described the entire point of client-side rendering as it was originally pitched. Computation on the server is expensive and mobile networks were slow and limited in terms of bandwidth (with oppressive overage charges) just a few years ago. Client-side…

People always take a good idea to far.

There's nothing wrong with loading a page and then everything on that page loads data from the server and renders it.

Where the issues come in is that modern SPA claims loading a new page is unacceptable and that somehow doing so means you can't fetch data and render anymore.

It's just not true.

Re: Moving from React to htmx

#94
post #4

Earlier quoted context omitted.

Speed is the big one for me. 2-6+ seconds is insanity for anything.

I would argue that 1-2 seconds is not impressive either. It's like seeing people breaking rocks with hand tools being impressed with a bigger mallet. I used to aim for 15 millisecond cold load times, which is apparently unheard of these days even for front pages with entirely static content.

15ms to who? I’ve never had that kind of latency on a cold connection. My pages have an LCP of around 600ms, and it’s hard to push it much lower because even static pages on a CDN end up taking 400ms to connect and download.

Re: Moving from React to htmx

#95

I'm just so burnt out with new things. How do I combat such burnout? I really don't care about 'Htmx', I think barely any apps need much beyond what was available in ~2006 in terms of web tech. I just feel tired knowing that moving from React to Htmx is an option. Yet another option which will very possibly bring zero commercial value (although it might be a nicer dev experience I guess) to any project I ever work on…

> How do I combat such burnout?

What works for me: don't waste time with frameworks.

The web standards are simple to learn and are also wonderfully not opinionated.

Re: Moving from React to htmx

#97

I'm just so burnt out with new things. How do I combat such burnout? I really don't care about 'Htmx', I think barely any apps need much beyond what was available in ~2006 in terms of web tech. I just feel tired knowing that moving from React to Htmx is an option. Yet another option which will very possibly bring zero commercial value (although it might be a nicer dev experience I guess) to any project I ever work on…

HTMX is much closer to 2006 web than React.

Re: Moving from React to htmx

#98
post #67

Earlier quoted context omitted.

I think anywhere you introduce more complexity, more ways for things to interact, it's inherently less secure without the additional work checking for both the App + the API being secure on their own.

There's no such thing as a secure "app". Only the API needs to be secure. That's more straightforward when your API looks like REST/RPC calls rather than "renders html templates to a string".

> That's more straightforward when your API looks like REST/RPC calls rather than "renders html templates to a string".

How so? You're now dealing with two applications (or two parts of an application) that need to understand and access authentication as defined by "the app"

If the same codebase handles auth across the board it's much simpler and more reliable.

Re: Moving from React to htmx

#99

I'm just so burnt out with new things. How do I combat such burnout? I really don't care about 'Htmx', I think barely any apps need much beyond what was available in ~2006 in terms of web tech. I just feel tired knowing that moving from React to Htmx is an option. Yet another option which will very possibly bring zero commercial value (although it might be a nicer dev experience I guess) to any project I ever work on…

For me, this feeling came from trying to stay on top of all the innovation happening out at the edge of problem domains. The thing is, none of those problems at the edges applied to me. I was chasing them for the sake of chasing them.

Once I stopped chasing the outer edge of what everyone else was trying to solve, and instead focused on the problem directly in front of me, the anxiety of being on the technical treadmill went away. When I have a problem to solve, I research it. As the outer edges get figured out, they start forming boring tech. I try to keep things boring when doing research - and avoid running up the treadmill unless necessary.

Re: Moving from React to htmx

#100

I'm just so burnt out with new things. How do I combat such burnout? I really don't care about 'Htmx', I think barely any apps need much beyond what was available in ~2006 in terms of web tech. I just feel tired knowing that moving from React to Htmx is an option. Yet another option which will very possibly bring zero commercial value (although it might be a nicer dev experience I guess) to any project I ever work on…

[deleted]
Post reply on HN