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

htmx

htmx.org

Post reply on HN
Print view View original

231–240 of 291 posts

Re: htmx

#231

Post by TekMol »

renerick wrote: post #222
TekMol wrote: post #221

Earlier quoted context omitted.

Hmm... that does no look like a minimal example to me. Is this the relevant line? If so, can you make an example with just that?

These are multiple minimal examples, they are completely self contained, independent of each other and separated by h1 tags. I separated those examples to different files: https://plnkr.co/edit/0TWYrtbMGP9UAzE4 Also, you may notice there is tag. It's just for the demo [1], it serves as a mock endpoint [1]: https://htmx.org/docs/#creating-demos

Simpler version of example 1:

https://jsfiddle.net/w6nrek81/

No need to bring up multiple examples. We just need one to show that htmx makes something simpler. This isn't one though.

Re: htmx

#232

Post by sgc »

replwoacause wrote: post #77
earthboundkid wrote: post #41

Earlier quoted context omitted.

Why does documentation need any JavaScript at all beyond opening the hamburger menu?

Why does it even need a hamburger menu?

Because you need to hide nav on mobile, since accessibility requirements from google and other web crawlers will require it to fill the much of the page, or your site won't be indexed.

Re: htmx

#233

Post by renerick »

TekMol wrote: post #231
renerick wrote: post #222

Earlier quoted context omitted.

These are multiple minimal examples, they are completely self contained, independent of each other and separated by h1 tags. I separated those examples to different files: https://plnkr.co/edit/0TWYrtbMGP9UAzE4 Also, you may notice there is tag. It's just for the demo [1], it serves as a mock endpoint [1]: https://htmx.org/docs/#creating-demos

Simpler version of example 1: https://jsfiddle.net/w6nrek81/ No need to bring up multiple examples. We just need one to show that htmx makes something simpler. This isn't one though.

I'm sorry, but that's just not fair comparison. You requested a minimal example and then pick the simplest one and tell me that you can implement this minimal example with minimal code. Of course you can fill a div with a random number with Vanilla JS, it can even be just a one liner, but it's not the point.

Your solution, for example, will break if the target div already has content in it. It also won't work if we want to insert the content after or before the element, you need to somehow keep track of the element being triggered, so it will grow more complex.

And still, it won't work with custom events

> No need to bring up multiple examples. We just need one to show that htmx makes something simpler.

This approach is not productive. A single example could be easily dismissed on the ground that it's not enough to justify design decisions that htmx has. I wrote multiple examples and provided additional links specifically to show various use cases that htmx covers and to avoid playing ping-pong of tiny examples.

> This isn't one though.

You just picked one example, which also happened to be the simplest, and seemingly ignored everything else. I apologize, I don't know how to continue from here.

Re: htmx

#234

Post by yawaramin »

chatmasta wrote: post #226
yawaramin wrote: post #108

Earlier quoted context omitted.

> None of this is possible with HTMX if the user has JavaScript disabled. The first step to using HTMX is to import a JavaScript file from a CDN, and none of the features for partial page replacement will work without it. Umm, progressive enhancement is a general concept that can be applied to any stack, not just Next.js. With htmx we can just use good old anchor and form tags to fall back to full-page loads if JavaS…

How do you do that if your backend is setup to respond to requests with partial content? You now need to make sure your backend can render both the full page and also individual components of it. That's not functionality that's provided by HTMX itself.

It's fairly easy. Htmx sends an `HX-Request: true` header with all requests. You can check for the presence of this header and have an if/else in your handler to render a partial or a full page. Or if you want to enable caching you can configure the `Accept` header with a customized content type like `text/html;hx=1`. That way you can set a response header `Vary: Accept` to ensure that caching is correct.

Re: htmx

#235

Post by sodapopcan »

dmix wrote: post #161
sodapopcan wrote: post #92

Earlier quoted context omitted.

> I suspect HTMX is more of an idea that people like to talk about on HN more generally, like Clojure and Erlang. Being the underdog matters on social media. Maybe it feels more authentic or relevant to discourse because it's still niche. Pretty glib take. The more exposure this stuff gets the better. I'd really like to have more job options out there that don't involve maintaining an internal web API so that two app…

I might have been using HN too long but you start to notice some pet technologies everyone here loves to safely upvote on HN but IRL stays niche for a reason. Especially in the serious business world of software development, not side projects or stuff we like talking about on social media. And I say that as a big fan of both Erlang and Clojure.

It can, though. Lots of enterprise apps are just page after page of forms, as was the one enterprise app I worked on. There's no reason those things need frontend frameworks talking through APIs to separate backends. It's good for jobs, of course.

Re: htmx

#236

Post by silver-arrow »

I have immensely enjoyed and benefited from using htmx for the past 18 months on projects with Clojure as the backend language. I had done years of full-stack Angular then React on the front-end and Java Rest endpoints on the back-end with teams of all sizes.

htmx has been a revelation and has really opened my eyes to the nuances of hypermedia development modalities that I was ignorant of. For me, it has become very clear that htmx and hypermedia development is far more simple, productive, beneficial, and FUN for 90% of web dev use cases. I feel huge disappointment how unnecessarily web development evolved into bad client server rpc json protocol for basically everything web.

Kudos to the htxm creator and his vision of what should have been. My experience absolutely corroborates his thinking on these things.

Re: htmx

#237

Post by replwoacause »

0xblinq wrote: post #124

I'd still pick Unpoly over it. Seems far more high level, feature rich and easier to use although less popular. And if I wanted a popular approach I'd pick Hotwire which can be used with any backend framework anyways. https://unpoly.com/ https://hotwired.dev/

I am also interested in why you like Unpoly more. Genuinely curious because I use and like HTMX and don’t really understand what you get with Unpoly that you don’t with HTMX.

Re: htmx

#238

Post by pphysch »

egeozcan wrote: post #156
pphysch wrote: post #109

Earlier quoted context omitted.

Then you need to explain it better. There is nothing wrong with offering simple solutions. The problem with WordPress is that you can't just stop using it and painlessly swap to a more powerful framework/platform. You can really dig yourself into a hole. This doesn't apply to HTMX.

All your endpoints are delivering partial HTML instead of JSON and you can switch to, say, React for your next feature? I mean, you technically can, but for that amount of work and/or friction you can pretty much go between any 2 frameworks.

There is nothing preventing you from having new endpoints serve frontend JSON, or from refactoring select endpoints away from HTMX.

If you are refactoring everything because a small subset of features didn't fit the HTMX glove, that's an engineering management failure.

Re: htmx

#239

Post by sandGorgon »

davidatbu wrote: post #192
sandGorgon wrote: post #107

HTMX + Java is almost as good as react! I think people mistake what htmx is - they think it is a way to not write react/js in a node environment. Where HTMX really shines is being able to bring the experience of writing React-like code without a nodejs environment in Java for e.g. (or Golang, Rust, etc)

> 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.

This is where HTMX shines. HTMX is just HTML++. It is is not Rust or Java. Which means your design cycles will continue to work.

Re: htmx

#240

Post by pphysch »

dmix wrote: post #132
pphysch wrote: post #109

Earlier quoted context omitted.

Then you need to explain it better. There is nothing wrong with offering simple solutions. The problem with WordPress is that you can't just stop using it and painlessly swap to a more powerful framework/platform. You can really dig yourself into a hole. This doesn't apply to HTMX.

You must not work on frontend because I've seen plenty of "simple" libraries exactly like htmx adopted and turned into monsters that power entire SaaS products the same way WordPress is turned into pseudo custom Web apps by non-programmers countess times. Being the guy who has to decipher it is not a fun job and gives you perspective on early technology choices. I've read enough discourse on HN re htmx to recognize p…

Every framework or library can be abused, but as a fellow software janitor I feel much better if the mess consists of just HTML templates and endpoints, rather than insane JS/TS/TSX build chains with invalid NPM dependency graphs (or a WordPress monstrosity).

One of the benefits of HTMX is that it doesn't add many abstractions, it primarily builds off existing ones. A HTMX dev must understand the basics of HTTP and the DOM, and not much else, to be functional.

Post reply on HN