Live data from Hacker News

Please just try HTMX

pleasejusttryhtmx.com

491–500 of 530 posts

Re: Please just try HTMX

#491

Earlier quoted context omitted.

Please do a write up of the best practices you've found. I tried htmx a few years ago for a side project and while I appreciated the simplicity of a lot of it, I had trouble understanding how/when to use it and in what ways. I think I was trying to contort it too much into my understanding of api/spa. That or my interactivity needs were too complex for it, I can't tell. These days, I admit, though, the ship has saile…

That is what DATAOS.software is all about. It is a manifesto of my proposed best practices somewhat like Hypermedia Systems, but more hands on, more of a cookbook.

Interesting read. I haven't quite finished it all. I haven't ever needed anything like that when writing web pages with HTMX, html-form (my own), nor htmz-be (another one I wrote based off of htmz but the back end decided where the HTML will go, similar to data-star and nomini). When I write code from the back end and target the front end I can use middleware to common updates.

Here's the most complex app I've made with it. The most complex part of the app is the match page. I just use morphdom for that part of the app and it makes it super easy, I just send the whole main part of the page back and let a dom diff happen.

https://github.com/jon49/Soccer

Re: Please just try HTMX

#492

Earlier quoted context omitted.

I was able to find architectural patters that work smooth as glass. Here is what my htmx apps have: - Single-purpose endpoints: Each endpoint returns ONE thing (a card list, a tag cloud, a form fragment) - Optimistic UI: Preferences like font/theme update the DOM immediately; the save is fire-and-forget with no response needed - Simple error handling: Most endpoints either succeed (return HTML) or fail (HTTP error co…

Please do a write up of the best practices you've found. I tried htmx a few years ago for a side project and while I appreciated the simplicity of a lot of it, I had trouble understanding how/when to use it and in what ways. I think I was trying to contort it too much into my understanding of api/spa. That or my interactivity needs were too complex for it, I can't tell. These days, I admit, though, the ship has saile…

Here's an example offline-first hypermedia-driven soccer application. The match page is the most complex part of the application and I use Morphdom to just do a diff on the main section of the page. I find hypermedia-driven development to be super simple.

I find React to be really complex. What normally takes me just some HTML rendered from the back end and some interactivity on the front end can be done in just a few lines of code, but React takes 10s of lines of code for what I can write in a single line of code using vanilla js. The virtual dom causes it to make everything state. I always find it odd that people reach for that as their front end. I could understand something like Svelte, but even that is too complex for my needs. But I'm always writing CRUD apps, so there is some complexity but not that much, React just makes something that was simple, super complex.

https://github.com/jon49/Soccer

Re: Please just try HTMX

#493
post #15

I am tired of people using the smallest "Hello World" example to demonstrate how something is better than React -- "See, you don't need all these things to get a website up and running!" Of course it will work. I can vibe code the most terrible web framework you have seen within 20 minutes and claim it is better than React, but what does it prove? > You write zero JavaScript > The whole library is ~14kb gzipped Oh su…

No one is forcing you to use it. I haven't used it myself, but htmx looks to be a good solution for many web applications.

Is this comment relevant at all???

Re: Please just try HTMX

#494
post #152

Earlier quoted context omitted.

Different teams/projects have different needs and require different solutions. While it's good it worked in their favor, I am quite confident that someone else can tell a completely different story. In fact, there are some comments in this very HN discussion that detail their negative experience with htmx. I would not use one or the other to "convince" anybody to go with either solution like what this article attempt…

Disliking evangelism is something most of us can relate. I give you that. And everything you said is very reasonable. But have you tried it though? Don’t you think it’s time to give your story? Slam your needs to htmx and see what comes out of it’s ruins?

I did something similar to htmx over a decade ago, so I know what it's about. And everything I need to say is already said by others in a more elegant way.

> Don’t you think it’s time to give your story?

I am afraid that's completely irrelevant to my comments here. If you read my posts carefully, you'll notice that I haven't said a single negative thing about htmx itself, because I want to very cautious in giving opinions. Everything I said was specifically about the horrible arguments in this article.

Re: Please just try HTMX

#495
post #265

Earlier quoted context omitted.

This matches my experience. State management is the key thing - you end up needing to put way more on the backend then you'd otherwise like to. Quick example: something like a multi-step "wizard" is far more difficult to express in HTMX than with any SPA-ish pattern.

Check out DecisionMe.com. 100 percent wizard pattern, htmx based nav and validation.

Eh.. this does not contradict the previous point? Unless we can see the backend code and do some comparison with a reference implementation, it does not disprove "far more difficult to express". "can be done with htmx" != "easy/easier to do with htmx"

Re: Please just try HTMX

#496
post #9

Earlier quoted context omitted.

There is a cert, it's just not signed by a CA.

What are you guys talking about. It automatically redirects to the HTTPS version and the cert is signed by Let's Encrypt.

You are late to the party, and it's already fixed.

> It automatically redirects to the HTTPS version

That's your browsing doing the job, not how the site is set up.

Re: Please just try HTMX

#497

You know, I see logic/"programming" inside of templates and I'm out, gave up that life many years ago and never have I been eager to go back to it. No, I'll keep using hiccup and similar things that are just data and nothing more, no syntax, just functions and built-in data structures, then give me HTML as a string which consumers can do whatever with, and we're golden.

how do you feel about this mixing of control logic and display information: click me

we call that HTML standard, and (in principle) works in any browser without the need to use JavaScript.

Re: Please just try HTMX

#498
post #51

The framework has been built into the browser for a while now. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...

I don't know what you actually mean, but very likely you are completely misguided.

Re: Please just try HTMX

#499
post #63

Earlier quoted context omitted.

> polluted my codebase I'd love to hear more about that.

Well listen, we have two modes of operation. It's either html/js/css in the classic sense, or Go templating with some tailwind and JQuery (or whatever the kids are calling it these days). In the case of react, something totally different. But essentially when you try to go that middle path with something that defines its own syntax, it starts to bleed into everything. It's not self contained. I'd argue maybe tailwind…

That's why you need something that lets you componentize your templates. React did this really well with JSX. But classic-style templating languages are not great at this. Django just recently introduced a 'partial templates' feature. I built my own: https://github.com/yawaramin/dream-html/blob/todoapp/app/REA...

Re: Please just try HTMX

#500

Earlier quoted context omitted.

I use nested templates the same way React uses nested components. The key is cascading the context (like props) down the hierarchy. Column order change? One edit in the table template; everything that includes it gets the update. The "header frontend / body backend" split is a choice, not a requirement. I wouldn't make that choice.

> The "header frontend / body backend" split is a choice, not a requirement. I wouldn't make that choice. I mention it because that's the first example on the official website, so I'd assume this is the right way.

Htmx is not a framework. It doesn't dictate a 'right way' to do anything. If you are interested in idioms that work well in practice, refer to the book that the htmx people wrote: https://hypermedia.systems/
Post reply on HN