251–260 of 291 posts
Earlier quoted context omitted.
This doesn't appear to be what the docs recommend anymore, which is exactly what my (obviously flippant) post was meant to highlight.
Hooks were introduced five years ago and have been stable since then. So that's half a decade with no changes to the API.
I continue to be impressed at the effort people will put into avoiding writing any JavaScript. Is it really easier to learn yet another DSL embedded in attribute tags rather than taking a day to setup your JS dev environment and then writing idiomatic code for running inside a web browser? Surely your htmx project will eventually cross a complexity threshold where you've added enough scaffolding that you may as well…
For a certain kind of application HTMX is a convenient way to work. It lets you write a webapp the way you did in 1999 except you can update pages partially. Here is a screenshot of an my HTMX-powered RSS reader https://mastodon.social/@UP8/110432673973724419 This is a research project, but it's a research project by an applications programmer so it has to be solid. Yet I have to be able to change anything when I wan…
I've also found the productivity of a "strong" decoupling from frontend and backend to be super satisfying.
Earlier quoted context omitted.
> Where HTMX really shines is being able to bring the experience of writing React-like code without a nodejs environment. FWIW, if that's all you're after, and you've mastered the Rust borrow checker, Yew (a React-like experience), or Leptos (a SolidJS-like experience) might be interesting to look at.
not its not the same thing. I work in Java (not rust), but the analogy will hold. Yew is writing Rust to create html. Same as Java Thymeleaf. Here's the problem - Java developers are bad at UI. And good UI designers/developers think in HTML. I am not pro or anti this situation...im just talking about the reality. The tooling is also around html. Figma-to-HTML is the most effective way to have your design cycle work.…
I was just suggesting, if, by "react-like" code, you meant "a UI library that uses a vDOM to transform functionally written code into DOM nodes", Yew fits the bill.
Also, typically, one writes JSX when writing react, not HTML. It's similar with Yew[0].
If you're already aware of Yew, I'm not trying to change your mind. I was just trying to make you aware if you weren't already.
[0] It says so right on the homepage: https://yew.rs/
On the one hand I see the appeal of staying inside, say, Django the whole time and getting 3x done. On the other hand I am so pampered by front end component based templating especially with Tailwind. It would be cool if I could just import my Svelte components from Django.
I really want to use htmx on the next project but I am not sure how to make it handle poor network connections yet. The app I'm building will be used in areas with poor mobile connections - I want to submit a form, add it to a list and say it's pending saving, while the user can add more. Have to use hyperscript probably? Can trivially do it in vanillajs so I'm sure it's possible?
Earlier quoted context omitted.
> there's a huge number of professional, revenue generating websites out there that just host a form. And that form probably just needs to send an email. You don’t need JavaScript or htmx for this. It’s been in the html standard since 1.0. Forms work from plain vanilla html. > Using a form, then a network request to some service, then showing some HTML will solve 100% of the problem for the local hair salon taking re…
This response is an excellent example of how, when stating a case or making an argument on HN, you should provide as little concrete information as possible and avoid a specific example if possible. The point they were making was that for many small single-purpose sites the interactivity needs are low but for various technical or social reasons may be higher than exposed with pure html/css, and htmx meets those needs…
If you're going to make a point like that via examples, they should be (in aggregate) useful examples that make your point!
Even setting aside that examples made up basically that poster's entire point, the reason people provide examples even for more developed argumernts is because concrete evidence is important to persuasiveness (not because they are being charitable). When someone tries multiple examples and none prove their point, it's perfectly valid to point that out.
I really want to use htmx on the next project but I am not sure how to make it handle poor network connections yet. The app I'm building will be used in areas with poor mobile connections - I want to submit a form, add it to a list and say it's pending saving, while the user can add more. Have to use hyperscript probably? Can trivially do it in vanillajs so I'm sure it's possible?
Hmmmm... can you define a "poor connection"? The web used to work the "htmx"/hypermedia through all the dial-up years where things were REALLY slow. I see no reason it would not work now.
I really want to use htmx on the next project but I am not sure how to make it handle poor network connections yet. The app I'm building will be used in areas with poor mobile connections - I want to submit a form, add it to a list and say it's pending saving, while the user can add more. Have to use hyperscript probably? Can trivially do it in vanillajs so I'm sure it's possible?
Hmmmm... can you define a "poor connection"? The web used to work the "htmx"/hypermedia through all the dial-up years where things were REALLY slow. I see no reason it would not work now.
Heh, the "Memes" section of their Essays page is brilliant: https://htmx.org/essays/#memes
A lot are also missing the point entirely for comedy's sake. Which is admittedly fine for a meme... While I love making projects with htmx, doing the equivalent for the complicated frontends we've got at my dayjob would not be enjoyable to maintain either. You'd end up with with fragment routes all over the place and will have serious issues finding where which is used, as the routes are all just strings with variabl…
Or, you could define every route to render a full page by default and render a fragment only if you detect an htmx request. So you end up with the same number of routes as for a normal MPA.