Live data from Hacker News

Htmx Is the Future

quii.dev

191–200 of 875 posts

Re: Htmx Is the Future

#191
This really comes down to backend devs thinking frontend must be simple, and when they realize it's not they blame the tools. So they come up with new tools and pretend they're better because they cater to backend devs and not those silly frontenders who just don't know anything.

Re: Htmx Is the Future

#192
This is a weak argument. The article is demoing a TODO app talking to localhost. Almost any library, framework, or language is the future if this is how we're judging the future.

> Working with HTMX has allowed me to leverage things I learned 15-20 years ago that still work, like my website.

Yes, a website is different than a webapp and has different requirements.

Re: Htmx Is the Future

#193

People were making this prediction ten years ago. It was wrong then, and it's wrong now. This article makes its case about Htmx, but points out that its argument applies equally to Hotwired (formerly Turbolinks). Both Htmx and Hotwired/Turbolinks use custom HTML attributes with just a little bit of client-side JS to allow client-side requests to replace fragments of a page with HTML generated on the server side. But…

Intentionally or not, this doesn't read like a cogent argument against the merits of HTMX (and isn't, since it is factually incorrect) but just as a person who is trying to convince him/herself that his/her professional skill set isn't starting to lose relevance.

From the February 31, 1998 Hacker News archives: "According to state of the web survey, Yahoo and Altavista are looking great on usage, Hotbot and AskJeeves are the upstarts. Google doesn't even hit the charts."

Re: Htmx Is the Future

#194
The tricky part of an SPA is that as a developer, you're taking on a lot of the burden of managing location state that in an MPA is handled by the browser. And location state often is a significant component of application state.

Certainly it's possible to take on that burden and execute it well, but I think a lot of teams and businesses don't fully account for the fact that they are doing so and properly deciding if that extra burden is really necessary. The baseline for nailing performance and correctness is higher with an SPA.

Re: Htmx Is the Future

#195

People were making this prediction ten years ago. It was wrong then, and it's wrong now. This article makes its case about Htmx, but points out that its argument applies equally to Hotwired (formerly Turbolinks). Both Htmx and Hotwired/Turbolinks use custom HTML attributes with just a little bit of client-side JS to allow client-side requests to replace fragments of a page with HTML generated on the server side. But…

It's interesting that this paradigm is especially popular on Hacker News. I see it pop up here pretty regularly and not many other places.

Re: Htmx Is the Future

#196
post #58

I really want to switch over to htmx, as I've moved away from SPAs frameworks, and I've been much happier. SPAs have so much abstraction, and modern, vanilla JavaScript is pretty decent to work with. The thing that keeps holding me back from htmx is that it breaks Content Security Policy (CSP), which means you lose an effective protection against XSS.[0] When I last asked the maintainer about this, the response was t…

If you don't like abstraction, why would use something as abstracted and non-standard is htmx?

It's a tradeoff, and either extreme has problems.

Too much abstraction (especially leaky abstraction the way web frameworks are) makes it difficult to reason about your application.

But if you optimize for absolute minimal abstraction, then you can get stuck with code that's very repetitive where it's hard to pick apart the business logic from all the boilerplate.

Re: Htmx Is the Future

#197

People were making this prediction ten years ago. It was wrong then, and it's wrong now. This article makes its case about Htmx, but points out that its argument applies equally to Hotwired (formerly Turbolinks). Both Htmx and Hotwired/Turbolinks use custom HTML attributes with just a little bit of client-side JS to allow client-side requests to replace fragments of a page with HTML generated on the server side. But…

I guess it depends on what your definition of "the future" is.

If it's teams of 10X devs working around the world to make the next great Google-scale app, then yeah, maybe React or something like it is the future.

If it's a bunch of individual devs making small things that can be tied together over the old-school Internet, then something like HTMX moves that vision forward, out of a 90-00s page-link, page-link, form-submit flow.

Of course, the future will be a bit of both. For many of my various project ideas, something like React is serious overkill. Not even taking into account the steep learning curve and seemingly never-ending treadmill of keeping current.

Re: Htmx Is the Future

#198
post #11

Earlier quoted context omitted.

I often work on an old ColdFusion application. It's amusing that for a long time the response was "oh man that sounds terrible". Now it is "oh hey that's server side rendered ... is it a new framework?". The cycle continues. I end up writing all sorts of things and there are times when I'm working on one and think "this would be better as Y" and then on Y "oh man this should be Z". There are days where I just opt for…

ActionScript is basically ES6 too isn't it?

No, it’s more like ES4 which was eventually abandoned and never became part of ecmascript

Re: Htmx Is the Future

#199

People were making this prediction ten years ago. It was wrong then, and it's wrong now. This article makes its case about Htmx, but points out that its argument applies equally to Hotwired (formerly Turbolinks). Both Htmx and Hotwired/Turbolinks use custom HTML attributes with just a little bit of client-side JS to allow client-side requests to replace fragments of a page with HTML generated on the server side. But…

I've spent almost my entire career working on react based SPAs and react native mobile apps. I've just started playing around with HTMX. > no good story for what happens when one component in a tree needs to update another component in the tree HTMX has a decent answer to this. Any component can target replacement for any other component. So if the state of everything on the page changes then re-render the whole page…

> do I want my api to talk in html

https://htmx.org/essays/splitting-your-apis/

Re: Htmx Is the Future

#200
Why people concentrating on creating more hacks on top of fundamentally ill-suited stack for app development, rather then rethink the whole stack from the first principles?

Luckily, after 3 decades, there is some sobering realization that typesetting engine is not a good foundation for modern apps. https://news.ycombinator.com/item?id=34612696

Web development without HTML/CSS/JS is the future.

Post reply on HN