Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Htmx in a Nutshell

htmx.org

Post reply on HN
Print view View original

91–100 of 414 posts

Re: Htmx in a Nutshell

#91

Post by fearthetelomere »

Xeoncross wrote: post #67

1. One of the most painful thing with SSR forms is passing the data back-and-forth between the server and client when there are validation errors. Sometimes the data is very sensitive and you have to return the form with some values (like SSN) empty and make the user retype that along with with whatever field(s) were the actual issue. I'm also curious about how file uploads would work. 2. REST/GraphQL/gRPC API. Often…

Regarding #1, I've found that Phoenix + LiveView has been helpful for these cases. They have great form validation tools using Changesets and the `phx-change` attribute [1]. You can redact certain fields [2], and even treat certain fields like virtual fields (like password not being stored vs the password hash being stored) [3].

Of course, the (potential) drawback is in using Elixir for both front-end and back-end which may be a tough sell to a client or employer.

-----

[1]: https://blog.appsignal.com/2021/09/28/real-time-form-validat...

[2]: https://hexdocs.pm/ecto/Ecto.Schema.html#module-redacting-fi...

[3]: https://elixircasts.io/ecto-virtual-attributes

Re: Htmx in a Nutshell

#92

Post by afavour »

colordrops wrote: post #68
leetrout wrote: post #3

I am burnt out (but recovering!) with web dev and htmx is what I am using for my project. Django, DRF, Postgres, tailwind and HTMX. I am so tired of all the front end frameworks and all the complexity that gets added. At some point I think you need it and you get returns from it but hearing more people in the industry recognize and talk about how JS everything isn't always the answer gives me hope. I like what HTMX h…

I am so tired of everyone complaining about complexity in front end frameworks, as if this sort of thing doesn't exist in other languages and stacks, and as if frontend dev isn't as complex as other domains. Just ignore them or do something else.

I’m tired of everyone talking about the frontend as if it’s a monolith. In a world where web uses span all the way from a blog with a contact form to an entire app like Gmail it’s silly to pretend there’s only one answer.

I think we’re still suffering from “everything with React” syndrome, I’ve never used htmx but if it can help as an antidote I’m all in.

Re: Htmx in a Nutshell

#93

Post by icedchai »

kkapelon wrote: post #84
colordrops wrote: post #68

Earlier quoted context omitted.

I am so tired of everyone complaining about complexity in front end frameworks, as if this sort of thing doesn't exist in other languages and stacks, and as if frontend dev isn't as complex as other domains. Just ignore them or do something else.

> as if this sort of thing doesn't exist in other languages and stacks It doesn't. For example in the Java world and in the last 10 years there were only two "frameworks". Just Spring and Oracle/Java EE Now two more have appeared (Quarkus and Micronaut) bringing the total number of frameworks to 4.

Sure, if you ignore Dropwizard and tons of other less popular java frameworks out there.

Re: Htmx in a Nutshell

#94

Post by kelnos »

kkapelon wrote: post #84
colordrops wrote: post #68

Earlier quoted context omitted.

I am so tired of everyone complaining about complexity in front end frameworks, as if this sort of thing doesn't exist in other languages and stacks, and as if frontend dev isn't as complex as other domains. Just ignore them or do something else.

> as if this sort of thing doesn't exist in other languages and stacks It doesn't. For example in the Java world and in the last 10 years there were only two "frameworks". Just Spring and Oracle/Java EE Now two more have appeared (Quarkus and Micronaut) bringing the total number of frameworks to 4.

Is the argument here that there are too many JS frameworks, or that the complexity of the frameworks themselves tends to grow over time?

If the former, totally agree. If the latter, Java frameworks are plenty complicated.

Also not sure how you've missed a lot of other frameworks; Spring and J2EE are certainly not the only ones that have been around for 10+ years. Dropwizard, Vert.x, akka-http, GWT, Play... just to name a few.

Re: Htmx in a Nutshell

#95

Post by 88913527 »

leetrout wrote: post #3

I am burnt out (but recovering!) with web dev and htmx is what I am using for my project. Django, DRF, Postgres, tailwind and HTMX. I am so tired of all the front end frameworks and all the complexity that gets added. At some point I think you need it and you get returns from it but hearing more people in the industry recognize and talk about how JS everything isn't always the answer gives me hope. I like what HTMX h…

It's tiring, but for those of us that have the humility to know, for example, that we aren't experts in implementing every last detail of WCAG-spec compliant accessibility --and the application I'm building requires it-- it's better to build on top of someone else's solution. There's so many pitfalls to quite easily writing un-semantic, incorrect HTML. Browsers are forgiving, but a screen reader won't be.

Re: Htmx in a Nutshell

#96

Post by makapuf »

This pattern is very pleasant and I sure hope browsers would embed as HTML standard a simple version of this (with simple hx-get/post, hx-target and hx-event to start)

Re: Htmx in a Nutshell

#97

Post by t8sr »

t8sr wrote: post #75

I'm confused about what value this adds. The introductory example is certainly not helpful, as it takes an ` Blog ` and turns into 7 lines of markup to accomplish the same thing. (And then it says a bunch of things that are arguably not desirable, like "any element can now trigger requests".) Like: what's the point of using this over HTML5+js? I've spent 15 minutes reading the website and I still don't understand why…

Replying to myself: I guess the main point of this library is to use HTML as the protocol payload between serve and client, instead of JSON. I can see the benefit of doing that, although I have a bone to pick with the condemnation of all data APIs because JSON is awful. Protocol buffers, for example, are trivially forward and backward compatible and mostly self-describing.

Also if you build stuff on top of hypermedia APIs then bye bye performance. It's probably fine for web pages, because you're competing with JS+JSON/REST frameworks that are written by people who have never heard the term "L2 cache", but I strongly suspect the right move is to drop the framework completely, not replace it with a new flavour-of-the-week thing.

Just write HTML5. It's fine. Add javascript for the 2-3 bits of interactivity you actually need. If you hate JSON, use protobufs. Your web page will work forever, because it'll sit on the actual API provided by the browser, and it won't make my laptop overheat when I load your site.

Re: Htmx in a Nutshell

#98

Post by bogwog »

I don't love the idea of implementing common app state logic via attributes. It probably works a lot better than I'm assuming, but it feels hacky to me. Like it can't solve every problem you'd actually encounter when making a complex app, so eventually you'll need to fall back to using javascript, and possibly a framework or three...on top of htmx.

But it does seem like this would be fun to play around with using PHP as your backend. No more JSON, or GraphQL, or bloated frameworks, just intermixed code and markup in the same PHP file...just like the good ol' days! For the situations where it does work, this could simplify the architecture of an app significantly.

Also, 10/10 meme page.

EDIT: are there any large and complex projects using this that are publicly accessible?

Re: Htmx in a Nutshell

#99

Post by TrickardRixx »

recursivedoubts wrote: post #38
shireboy wrote: post #35

I want to like - I feel like the frameworks are all too much ceremony now. You need to buy into a bunch of different build tools, a cli or two, and are left wondering "where is my app again?" I've tried htmx, though, and like the simplicity, but am not 100% sold. In the olden days, ASP.NET Web forms Ajax had "Update Panels", which were similar to this. You'd wrap a section of markup in an "Update Panel" and that made…

Hypermedia APIs and JSON (Data) APIs are different. I have a few essays up on these differences here: https://htmx.org/essays/hypermedia-apis-vs-data-apis/ https://htmx.org/essays/splitting-your-apis/ Generally, I would recommend splitting your data and hypermedia APIs up, so you can take advantage of the features of hypermedia (the uniform interface) and still provide a good data API to clients that want it. Also, t…

I'm aware that I'm abusing the tool, but I wrote a htmx extension that overrides the mimetype and JSON encodes all the parameters. The JSON is decoded into a data bag on the back end. Basically I can do "fuck it over HTTP"[0] with needing close to zero JS. HTMX has been a god-send to me.

[0]: https://twobithistory.org/2020/06/28/rest.html I misremembered the name, it is actually "fuck it, overload http"

Re: Htmx in a Nutshell

#100

Post by can3p »

I like gymzaal and hyperscript - they solve few cases but those cover something like 99% of what a average app needs.

My biggest pain point lies with the docs, there are not many of them and it takes time to figure out what’s happening

For example, there was no simple way to understand that both libraries are loaded correctly, also it wasn’t immediately obvious where to use htmx and where to start using hyperscript

Post reply on HN