The simplicity is the point
Htmx 4.0
171–180 of 211 posts
Re: Htmx 4.0
#172Somewhat of an aside: it's ironic the that some of the clearest, most concise technical documentation I now find on the Internet has come out that way because it was written for a machine: https://raw.githubusercontent.com/bigskysoftware/htmx/v4.0.0... Human readers don't receive this level of care or attention.
It took me a long time to grok what htmx even was from barely glancing at news articles about it every once in a while. If I'd seen such a concise text explanation I'm sure I'd have got it immediately! Lesson learned: go to LLM docs first I guess?
Re: Htmx 4.0
#173Somewhat of an aside: it's ironic the that some of the clearest, most concise technical documentation I now find on the Internet has come out that way because it was written for a machine: https://raw.githubusercontent.com/bigskysoftware/htmx/v4.0.0... Human readers don't receive this level of care or attention.
It's removing all the unnecessary words and fluff. FWIW I adhere to RFC-2119 when writing docs, and tell agents to do so as well.
Re: Htmx 4.0
#174According to their docs "htmx is a library that allows you to access modern browser features directly from HTML, rather than using javascript"
Can anyone confirm this claim? How good is this? Doing everything in HTML/CSS might have some advantages. Is it quick and compatible enough?
Re: Htmx 4.0
#175According to their docs "htmx is a library that allows you to access modern browser features directly from HTML, rather than using javascript" Can anyone confirm this claim? How good is this? Doing everything in HTML/CSS might have some advantages. Is it quick and compatible enough?
Yes, I can confirm. The main advantage is that you can build a site that feels like a React site, but with 100x less code, and no frontend to maintain.
Re: Htmx 4.0
#176Congratulations on the release! I have enjoyed working with htmx very much. I'm still skeptical of htmx being the foundation for a 100-year web service, but I think this is a really worthwhile goal. I'll add that aside from static HTML, I don't have a better option.
Thinking about how well your web architecture will hold up for 100 years (or even 10 years) is bikeshedding and a pointless exercise. Perfect is the enemy of good and all that. If something is useful, it’s possible to fix the architecture later. The only counter-example I know of has been GitHub, which was built on RoR and so poorly planned that it’s still biting Microsoft on a regular basis.
Is it though? It doesn't need to be perfect to last. Good engineering practices certainly embrace timeless concepts. I understand if you are working in a feature-factory, but creating inheritable code should be given more consideration however much programmers dislike thinking about things like ROI.
Re: Htmx 4.0
#177Maybe a contrarian view, but as someone very knowledgeable about .NET API backends + angular on the frontend, I've found that HTMX made things more difficult as it required me to move back to mixing presentation concerns with business-logic and data concerns (basically have the backend produce the UI, which is whole point of HTMX). This is not a criticism but I suspect that the people enjoying HTMX are either people…
For me htmx is a utility library to spruce up a couple of interfaces here and there that benefit from a bit of reactivity. Anything more complex I really don't feel that it's the right tool. Or that there is any great tool to build SPAs.
There is sometimes this trends on projects of using anything like a universal hammer. And then they SPA their project.
Re: Htmx 4.0
#178Re: Htmx 4.0
#179Congrats and thanks! htmx brings me joy. Pretty much every experiment I build now starts with Go, htmx, and SQLite to keep things simple and fast but still responsive. I put a few more thoughts about this here: https://housecat.com/blog/the-hugs-stack-hypermedia-unix-go-...
I go with rust/datastar.
I actually think JSX is better, but I am bored of it because we don't need state in JS no more.
Re: Htmx 4.0
#180Maybe a contrarian view, but as someone very knowledgeable about .NET API backends + angular on the frontend, I've found that HTMX made things more difficult as it required me to move back to mixing presentation concerns with business-logic and data concerns (basically have the backend produce the UI, which is whole point of HTMX). This is not a criticism but I suspect that the people enjoying HTMX are either people…
> ... managing state on the server is not fun at all. Do you not have a database for your backend? Managing state is kind of their thing.
Are you not familiar with building web apps?
So, when building for the web you'll essentially have 2 different categories of state: server and client.
Server state is obviously what's pulled fromt the db, but that's 100% not where something like form state should be stored. Or button toggle state. Or whether a modal is open, etc.