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

Htmx is part of the GitHub Accelerator

htmx.org

Post reply on HN
Print view View original

211–220 of 520 posts

Re: Htmx is part of the GitHub Accelerator

#211

Post by toddmorey »

toddmorey wrote: post #207
recursivedoubts wrote: post #131

hi there, as many of you know, i am the creator of htmx and I'm happy to answer any questions about it htmx has seen a surge in popularity, triggered by a video by fireship dev ( https://www.youtube.com/watch?v=r-GSGH2RxJs ) and a series of videos by ThePrimeagen, a popular twitch streamer on it hacker news readers might be interested in the essays I have written on htmx & hypermedia in general here: https://htmx.org…

Congrats on the GitHub program! Very cool. I just had a fresh read of the docs and htmx is refreshingly, gloriously simple--such a breath of fresh air. So natural, self-documenting, and well thought out. It _does_ feel like a natural extension of html. To me, the only "missing" piece of htmx is a component model, but for anyone looking for that, htmx would pair amazingly well with Astro[1] which allows you to define…

Also: I think every project / saas service should be required to have a footer haiku:

   javascript fatigue:
   longing for a hypertext
   already in hand

Re: Htmx is part of the GitHub Accelerator

#212

Post by nologic01 »

dartos wrote: post #125
nologic01 wrote: post #16

I think we need an impressive "made with htmx" example that will trail blaze an new class of web experiences. People have typecast htmx as something to use for simple use cases that dont "warrant" getting out the serious guns. There is something to that, but it is limiting. Htmx and related 'back-to-the-server' approaches are a distinct category that could have been explored much earlier but for various reasons isnt

> trailblaze a new class of apps I think you misunderstand HTMX. It’s the revival of an old class of apps in a backend agnostic way. It’s not doing anything new, or anything that warrants a “new class of apps.” It’s a way to build hypermedia (read: content) focused sites. Classic sites like shopping catalogs, forums, admin front ends, blogs, etc. It’s just jquery/liveview/turbolinks, but backend agnostic and without…

Do you think we have exhausted the space of "hypermedia" apps? I dont think so.

Re: Htmx is part of the GitHub Accelerator

#213

Post by airtag »

buro9 wrote: post #109
mikece wrote: post #12

The twists and turns my career has taken had me pretty much skip the whole front-end JavaScript framework wars so it's nice to see "plain old HTML" make an enhanced comeback.

The site and it's examples do not work with JavaScript disabled. This is a regression on graceful degradation.

Yes but for your own projects you could have a first page with a "no JS" div and attach a HTMX load request. That's how I did my first HTMX project and it works well informing you to turn on JS.

Re: Htmx is part of the GitHub Accelerator

#214

Post by recursivedoubts »

logankeenan wrote: post #210
recursivedoubts wrote: post #131

hi there, as many of you know, i am the creator of htmx and I'm happy to answer any questions about it htmx has seen a surge in popularity, triggered by a video by fireship dev ( https://www.youtube.com/watch?v=r-GSGH2RxJs ) and a series of videos by ThePrimeagen, a popular twitch streamer on it hacker news readers might be interested in the essays I have written on htmx & hypermedia in general here: https://htmx.org…

What plans do you have for 2.0?

No major changes, it should be about 99% API compatible with htmx 1.x. Big things:

- Websocket & SSE support will be completely pulled out to extensions (already available in 1.0)

- We will drop IE support

- We may include a "morph" swap strategy based on idiomorph (https://github.com/bigskysoftware/idiomorph/)

- We will change a few defaults around how HTML is parsed, taking advantage of the removal of IE support

Hopefully transparent to the vast majority of htmx users.

Re: Htmx is part of the GitHub Accelerator

#215

Post by rakoo »

gochi wrote: post #155
giraffe_lady wrote: post #152

Earlier quoted context omitted.

I'm kind of guessing / reading into their comment here but. Using htmx doesn't give me the feeling of "this is the only way I ever want to do this" but more "if html worked like this I wouldn't use js most of the time." The sense that an opportunity was missed and now we're paying for it in complexity.

The complexity is just shifted around from JS to HTMX (or hypothetically, html). Not a noticeable improvement.

With JS you must use JS or TS and the steam factory that comes with it. With htmx you can use any language. That's a very high improvement for many.

Re: Htmx is part of the GitHub Accelerator

#216

Post by recursivedoubts »

silver-arrow wrote: post #205
recursivedoubts wrote: post #195

Earlier quoted context omitted.

i definitely think there is room for multiple implementations unpoly is higher level than htmx, with different design sensibilities and concepts like 'layers' ( https://unpoly.com/up.layer ) which is something that doesn't make sense from htmx's "just extend HTML" perspective

Exactly! I love the sweet spot that htmx hits; please don't change that!

:) i will not

Re: Htmx is part of the GitHub Accelerator

#217

Post by uxns »

silver-arrow wrote: post #98

Great news. I have had good success and a rewarding experience using htmx the past year. It has been so great in tandem with Clojure using hiccup for SSR. Once htmx clicks for you, you are almost left stunned by how simple and flexible it is. You can't believe that this isn't how HTML evolved to as a hypermedia. It becomes very obvious that this is how web development should have evolved. I hope someday that what htm…

Out of curiosity, I presume you were working on the frontend part using Clojurescript? Have you used some kind of wrappers around htmx or just a simple js interop was enough?

Re: Htmx is part of the GitHub Accelerator

#218

Post by dgb23 »

afavour wrote: post #112
silver-arrow wrote: post #98

Great news. I have had good success and a rewarding experience using htmx the past year. It has been so great in tandem with Clojure using hiccup for SSR. Once htmx clicks for you, you are almost left stunned by how simple and flexible it is. You can't believe that this isn't how HTML evolved to as a hypermedia. It becomes very obvious that this is how web development should have evolved. I hope someday that what htm…

> It becomes very obvious that this is how web development should have evolved. I have to disagree with that. I’m happy htmx exists and that it works for many but in my professional life I've found few cases where it's the best choice. And that’s fine! It’s a wonderful thing that the web has been able to grow in so many diverse ways, there should be no one way it “should have evolved”. IMO this is the biggest mistake…

I fully agree with you. I'm a fan of htmx, can recommend it and have used it in some projects by now. But...

For one, htmx is not a full solution to avoid JS. It's excellent for the parts that are AJAX/CRUD, which certainly covers a lot of ground. You still need something more if you're doing stuff that doesn't fit here like interactive visualizations and many other use cases. However, it integrates very well with other lightweight libraries.

Secondly, htmx is great if you're developing full-stack (like GP). Meaning you touch every part of a site from the data model to coordinating messages to the frontend etc. If you want a much clearer separation between frontend and backend of a site, especially in terms of contributors/teams, then it might not be the right tool. IMO there are plenty of good reasons to do either.

Third, and this is a bit of a combination of the first two points, if you directly fetch data from a third party, say a JSON API, then htmx doesn't help you at all.

So really as you said, there is no one right way. For me it has been working very well though. People should look into it for sure though. There's an opportunity to combine htmx with orthogonal libraries that do the dynamic parts like lit etc.

Re: Htmx is part of the GitHub Accelerator

#219

Post by suction »

thefreeman wrote: post #115
agumonkey wrote: post #89

Earlier quoted context omitted.

Had an heated debate with someone that was really angry at everything react, for good reasons, but being oblivious that htmx can't replace client side logic. React hype + backend crowd I guess.

as a primarily backend dev I really don't see the appeal here. So now I need to make endpoints for every little UI element that I want to be updated by user interactions? And somehow keep it styled and matching all of the UI elements rendered on the frontend? No thanks, I'll just give you data and you can present it however you please.

[dead]

Re: Htmx is part of the GitHub Accelerator

#220

Post by suction »

simonbarker87 wrote: post #58
synergy20 wrote: post #40

it does not work well with the ever growing restful API backend services to me.

How so? (no snark, genuine) Your frontend makes a request to your server, the expectation is that will respond with html. If you have other services you need to bring in to the mix that responds with JSON then make the request to them from your server, have that parse the JSON in to HTML (most likely some kind of templating system like handlebars) and then send that back to your frontend as html for htmx to handle. O…

[dead]
Post reply on HN