Live data from Hacker News

Htmx is part of the GitHub Accelerator

htmx.org

501–510 of 520 posts

Re: Htmx is part of the GitHub Accelerator

#501

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…

One minor thing. This is not an issue directly with htmx, but more on the backend. This always feels clumsy for me: I land on the index page, and get the full site, then click on about page, and now htmx swaps the content for the about page. However if i refresh the url stays the same, but i now only get the content without the container. I know this can be solved with checking for a htmx header, but i feel like "the…

This can be solved by returning the full about page always, but swapping only the content part of in the index page by selecting which element to swap from the requested page. Htmx supports it

Re: Htmx is part of the GitHub Accelerator

#502
htmx just got me to do some front-end programming again after many years of false starts with Angular, React, Flutter, etc!

Very refreshing and extremely productive! Goland, browser window and Bard for code snippets and from idea to first working flow in less than an hour!

With other frameworks I would first have to struggle for a day or two setting up the tooling and understand all of the new concepts and constructs. Or worse, learn completely new language (Flutter, Typescript)

Thanks @recursivedoubts and team!

Re: Htmx is part of the GitHub Accelerator

#503

Earlier quoted context omitted.

I see it as much more, many things can be stripped out altogether. Client-side state management. Client-side input validation. Fallbacks for when data hasn't been loaded yet. Less async-based code, less coordination-required and event-driven code (this stuff happens but much easier and often code-free with HTMX). Its not a fit for every site or use case but more than any other front-end tool or library or framework,…

So you only do input validation on submit? Isn’t that user hostile? This is what I don’t get about HTMX, you can’t give a good experience without client-side JS, sure some developers might love it, but that shouldn’t be the yardstick.

Not hostile at all, and we arent degrading the user experience -- much improving it, in my opinion. With HTMX you can do real-time validation on each input element on the server and provide instant visual cues to the user anytime one fails. https://htmx.org/examples/inline-validation/

Moreover, HTMX makes it incredibly easy to change the whole paradigm of submitting data. You can eliminate some forms entirely and just enable a series of individual questions/inputs/selects one at a time, especially useful when a single static form isn't always appropriate (multiple pathways, questions/options that are contingent on the response to a previous question, etc).

In my experience the UI flow and degree of detail for avoiding common errors is greatly improved.

Re: Htmx is part of the GitHub Accelerator

#504

Earlier quoted context omitted.

> some sort of “component” framework It's implicitly expected you're already doing so, such as web components or whatever your selected framework uses to abstract components. > Having all of your styles duplicated everywhere Locality is a feature. It's much easier to jump into any random bit of HTML and understand what's going on and confidently make changes without having to pull up multiple other files to grok the…

The GP post was talking about directly editing HTML, so I was assuming they weren’t using a component framework. That’s the context I’m replying to. We can agree to disagree about readability though, I have a lot of trouble groking long class=“…” strings.

> The GP post was talking about directly editing HTML

This is still what you're doing with any components, only the CSS is localized to the component vs. its usage.

Re: Htmx is part of the GitHub Accelerator

#505

Earlier quoted context omitted.

> some sort of “component” framework It's implicitly expected you're already doing so, such as web components or whatever your selected framework uses to abstract components. > Having all of your styles duplicated everywhere Locality is a feature. It's much easier to jump into any random bit of HTML and understand what's going on and confidently make changes without having to pull up multiple other files to grok the…

"Compression" doesn't solve change management, where you need to consistently change together things that are meant to change together. Intead of letting them fragment, diverge in millions of tiny ways until entropy takes over your project and kills it. Copy/pasting, which Tailwind is so proud of, is to fork, and never merge. Let's fork all the things. We end up with a bazillion little things and no coherence/alignme…

How have you written nearly 500 words and still not make any salient or cogent points? Try making a good faith argument and maybe we can have a discussion.

Re: Htmx is part of the GitHub Accelerator

#506
post #361

Earlier quoted context omitted.

As someone relatively new (few months in) to full-stack development, what can HTMX offer me? I've been semi interested since Prime mentioned it a handful of times, but I feel maybe I'm too new to fully understand what I gain from it. As soon as I'm finish with my current project, I'd like to check it out. For reference, I'm currently working within the T3 Stack.

HTMX is just a convenient way of handling user-initiated UI updates AJAX calls (for whatever purpose). So instead of writing some JavaScript that looks for a specific element to attach an `onclick` event and subsequently makes an AJAX call then again searches for an element on the page to update with the result you can put some (very simple) HTMX code in the HTML directly and it'll handle that sort of thing automatic…

Interestingly enough, I have something planned that HTMX would be absolutely perfect for, can't wait to give it a try soon.

Re: Htmx is part of the GitHub Accelerator

#507
post #454
post #384

Earlier quoted context omitted.

Fuck those hucksters... https://twitter.com/rauchg/status/1619492334961569792

can you epxlain this to the <100 iq

Guillermo Rauch is the ceo of vercel. In this tweet, he's effectively saying that the bulk of what his company was built upon (SPAs) is bullshit (zero interest rate phenomenon is a reference to when financial interest rates are very low/zero, as they've been for many years, all sorts of things will seem great and successful because you can borrow money for free. When rates go up, only actually viable projects will survive - as we're seeing in the startup world now).

Re: Htmx is part of the GitHub Accelerator

#508

Earlier quoted context omitted.

Mobile phones have less powerful CPUs. Parsing large json objects and then building up a corresponding html structure may be more difficult than on the server (where you already have it loaded into memory anyway).

> Mobile phones have less powerful CPUs True - but not by much > Parsing large json objects and then building up a corresponding html structure may be more difficult than on the server I doubt it. And you'd only be doing "large JSON objects" for a desktop web app, where CPU differences vs web servers are even smaller > where you already have it loaded into memory anyway Likely not true if implementation uses streamin…

I can't speak to any kind of general principle here, but viewing any standard modern web page e.g. Twitter, Discord in a Web browser reliably takes more CPU and memory than running a late-game Factorio save.

I will allow that it is probably theoretically possible to do client-side rendering in a CPU-efficient way, but it sure isn't the standard.

Re: Htmx is part of the GitHub Accelerator

#509
post #483

Earlier quoted context omitted.

Nolan Lawson demonstrated using a web worker to perform virtual DOM updates in 2015. Sad it hasn't caught on in any of the major frameworks. https://pocketjavascript.com/blog/2015/11/23/introducing-pok...

It's not enough to be a novel approach. It also has to be demonstrably better from a performance standpoint, a developer experience standpoint, or arguably both. Frameworks like SolidJS and Svelte simply got rid of the virtual DOM and reaped massive performance wins from it. I find it hard to believe that adding a worker and a virtual DOM back would end up making them faster. Quite the opposite in fact. Then there's…

Very fair assessment, though not everyone is using, or will use, Svelte or Solid. Including people who are using htmx.

I meant to suggest that frameworks might be able to take this approach internally and make the DX transparent. I actually had a go at this using Mercury back in the day, but didn't have the motivation to finish it properly.

Re: Htmx is part of the GitHub Accelerator

#510

Earlier quoted context omitted.

So you only do input validation on submit? Isn’t that user hostile? This is what I don’t get about HTMX, you can’t give a good experience without client-side JS, sure some developers might love it, but that shouldn’t be the yardstick.

Not hostile at all, and we arent degrading the user experience -- much improving it, in my opinion. With HTMX you can do real-time validation on each input element on the server and provide instant visual cues to the user anytime one fails. https://htmx.org/examples/inline-validation/ Moreover, HTMX makes it incredibly easy to change the whole paradigm of submitting data. You can eliminate some forms entirely and jus…

Disagree that it’s good UX. Now the user only gets feedback when they lose focus on the field, forcing them to go back and refocus it. In conventional React they get feedback on each keystroke allowing errors to be fixed while the field is still focused.
Post reply on HN