I'm the CEO of HTML. I approve of unpoly. A+++++
Please just try HTMX
221–230 of 530 posts
Re: Please just try HTMX
#222I haven't used HTMX but the author doesn't make a very convincing case. On the one hand they say,
> "But what about complex client-side state management?"
> You probably don't have complex client-side state. You have forms. You have lists. You have things that show up when you click other things. HTMX handles all of that.
On the other hand,
> I'm not a zealot. HTMX isn't for everything.
> Genuinely complex UI state (not "my form has validation" complex—actually complex)
But my interpretation is that any UI which displays the same data in just two places (like a "new notification" indicator as well as bolding new messages in an inbox, or a list of articles which can change dynamically as well as a count of the number of articles) is "complex" enough that you'll need client side state.
Re: Please just try HTMX
#223[deleted]
Re: Please just try HTMX
#224Was hoping for a sandbox so I could actually try it!
Re: Please just try HTMX
#225Mitrhil.js is 8.8 kB gzipped.
And you can just return JSON from your API.
And you can add JSX later if you want.
Re: Please just try HTMX
#226Earlier quoted context omitted.
Okay, so what do you your servers actually serve stuff to? I kind of don't get why if you want to display something in a web browser you'd generate anything other than HTML.
I think the parent's point is that when you have a react front-end, your back-end basically just deals in structs of data. There's no HTML or templating to think about. It's just JSON-serialisable structs. That makes the code on the back end much simpler, which makes it easier to run in a resource-constrained environment. The only exposure the back-end has to HTML is streaming the static files to the browser. Which c…
This is plain false.
Re: Please just try HTMX
#227> When you click it, HTMX POSTs to /clicked, and whatever HTML the server returns replaces the button. No fetch(). No setState(). No npm install. No fucking webpack config. Can someone explain something to me? To my view, the single best idea React has is that it forces you to encapsulate the full set of states in your component - not anywhere else. For instance, if you have a "Comment" button that becomes "Submitted…
The state encapsulation concern is exactly what DATAOS addresses: dataos.software The premise is that React's "UI=f(state)" creates a synchronization problem that doesn't need to exist. If the DOM is the authority on state (not a projection of state held elsewhere), there's nothing to sync. You read state from where it already lives. I built multicardz on this: 1M+ cards, sub-500ms searches, 100/100 Lighthouse scores…
I would be happy to discuss more. I am genuinely curious (though I do hold a pretty strong belief that React is a good abstraction).
When you say that the DOM is the authority on state, I’m not sure if that addresses my concern. Let’s revisit my example of the button. Image I look at the DOM and see that it’s in a “Submitted” state, and I think that’s a bug. How can I determine how it got into this buggy state? The DOM can’t answer that question, as far as I can see, because it is only an authority on the current state of the system at this exact moment. The only way I see you answering this question is by scanning every single API endpoint that could have plausibly swapped out the button for its new state - which scales at O(n) to the side of your repository! And if one API could have added HTML which then added more HTML, it seems even worse than that.
The advantage of React is that you get a crisp answer to that question at all times.
> I built multicardz on this: 1M+ cards, sub-500ms searches, 100/100 Lighthouse scores.
I believe you! But I am more concerned about readability. React makes some tradeoffs, but to me readability trumps all.
Re: Please just try HTMX
#228> Most teams don't fail because they picked the wrong framework. They fail because they picked too much framework. HTMX is a bet on simplicity, and simplicity tends to win over time.
I've built enough stuff in my time to know this is hyperbole at best and an outright lie at worst. I've never seen a team fail due to complexity. Team fails because the thing they built was wrong.
You should spend 99% of your time paranoid that the thing you're building is useful enough to justify its existence. Whatever tool you use along the way makes up the last 1%
Re: Please just try HTMX
#229Hey, I created htmx and while I appreciate the publicity, I’m not a huge fan of these types of hyperbolic articles. There are lots of different ways to build web apps with their own strengths and weaknesses. I try to assess htmx’s strengths and weaknesses here: https://htmx.org/essays/when-to-use-hypermedia/ Also, please try unpoly: https://unpoly.com/ It’s another excellent hypermedia oriented library Edit: the arti…
You really need to shut this down dude. If HTMX becomes famous for having overbearing advocates that's a really bad look. Look at what happened with Rust.
Re: Please just try HTMX
#230I haven't used htmx, but I've given turbo a fair shake. I've only worked on server side rendered apps for my whole career, and they are generally they way to go. But just like react, or anything else, you throw enough engineers at it and it becomes a mess. But also you'll only find a handful of engineers who understand it compared to react, so that makes it worse. I think the bottom line is creating web UI is just as…
> this isn't what http and html were even built for
Ding! Ding! You win the prize. Absolutely correct.