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

481–490 of 520 posts

Re: Htmx is part of the GitHub Accelerator

#481

Post by synergy20 »

ensignavenger wrote: post #479
synergy20 wrote: post #477

Earlier quoted context omitted.

can htmx work for restful backend that requires client side rendering and routing? my understanding is that htmx only fits for server side rendering such as Django.

HTMX pulls text from your backend, so normally folks serve HTML snippets... but you could have a bit of js that takes JSON and turns it into HTML in the browser, and HTMX will pull the JSON (or any other text) into the browser, so you could still use it with a JSON api, if you wanted to I use DRFs renderrers so my Django backend can render either JSON or HTML, so my API is still "restful", it just serves HTML to clie…

interesting,using DRF for json and Django for html at the same time for browser and nonbroswer clients.

my use case is embedded systems that can typically do client side rendering in browsers, the only server side rendering I can afford is some simple lua or c/c++ mvc alike backend,Django is too 'fat' on resources. there are some of them but none that is great and actively maintained as far as I know.

Re: Htmx is part of the GitHub Accelerator

#482

Post by pragma_x »

recursivedoubts wrote: post #247
pragma_x wrote: post #234

Earlier quoted context omitted.

This is a great project, and reminds me a lot of where folks saw hypertext going many years ago. I have read a little of the website and picked through many of the online examples. One thing I did notice is the preference to update client state (DOM rewrites) based on server HTTP request responses containing full-blown markup. Does the HTMX framework provide concessions for client-side-only triggers and client genera…

we do have a client-side template extension: https://htmx.org/extensions/client-side-templates/ however, I would encourage most folks to use HTML as the network format: it typically isn't much more CPU to generate the equivalent HTML string that corresponds to a JSON string (sometimes even less, as with tables) for pure client-side, htmx is largely hands off. We support an `hx-on` attribute to address the fact that H…

Thanks for the thoughtful reply, and the thoughtful architecture.

Re: Htmx is part of the GitHub Accelerator

#483

Post by ttfkam »

crabmusket wrote: post #404
the_gipsy wrote: post #309

Earlier quoted context omitted.

JavaScript is single-threaded, so whatever CPU work is going on will compete with the UI responsiveness. Even mobile apps, which run a dedicated thread for each, probably won't do one single clean UI update in response to the server-response.

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 the dev experience. Would it be easier for a developer to work out what to do in a separate thread and post messages back into the UI thread? Seems like extra cognitive overhead to me.

Ideas are great. They move the state of the art forward. But if your idea doesn't comport with positive results from testing, it's not useful. Intriguing, to be sure, but not useful.

Re: Htmx is part of the GitHub Accelerator

#484

Post by mejutoco »

treis wrote: post #336
mejutoco wrote: post #177

Earlier quoted context omitted.

Htmx advantage is not that it sends less bytes, but that it effectively removes frontend. Getting rid of the frontend dependencies, builds systems, and languages can bring a lot of speed to a project. Of course the downside is everything must go to the server. While not perfect, many spa also do not work nicely without a connection, although they could. Another thing is that the templates can get a bit crazy quick. I…

>Htmx advantage is not that it sends less bytes, but that it effectively removes frontend. Right, which you can achieve by replacing the main content div. HTMX takes it many steps further and allows you to slice the HTML up into small bits and replace only those. This adds a lot of complexity for little benefit.

It achieves it by not needing React, etc. IMO. That is the benefit. It might be worth it or not depending on the project.

Re: Htmx is part of the GitHub Accelerator

#485

Post by mstade »

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…

Thank you for all your hard work put into htmx and indeed promoting hypermedia driven applications!

Since htmx works by way of custom attributes, can you write a bit about a11y recommendations for developers using htmx? It would seem to me that a lot of things that we get from using standard attributes are lost, and we’d need to do more nuts-and-bolts type work with regards to dom structure and aria attributes. Or does the htmx engine deal with this to generate relevant aria attributes etc.? I couldn’t find any references to this in the documentation.

Re: Htmx is part of the GitHub Accelerator

#486

Post by hu3 »

rydgel wrote: post #478
mnming wrote: post #476

In all those SSR tools, my favorite is inertial.js, I think it combines the best of the both worlds. I am not sure why inertial wasn't getting more popularity though, anyone know why?

Because it's PHP I guess

It's not well known or advertised, but it can be used with other langs and frameworks too:

- Rails

- AdonisJs

- ASP.NET Core

- CakePHP

- CanJS

- Clojure

- CodeIgniter4

- ColdBox

- Django

- Go

- Masonite

- Mithril.js

- Node.js

- Phoenix

- PSR-15

- Statamic

- Symfony

- WordPress

- Yii2

- Flask

source: https://inertiajs.com/community-adapters

Re: Htmx is part of the GitHub Accelerator

#487

Post by graypegg »

tomnipotent wrote: post #429
graypegg wrote: post #341

Earlier quoted context omitted.

I’ve messed around with tailwind a bit now, and honestly I could never use it in even a moderately complex site without some sort of “component” framework. I think you’re talking about just serving a .html file for every page in a site right? Having all of your styles duplicated everywhere would be much more confusing than writing CSS (and having to invent one name per groups of common things.) IMO it’s only viable i…

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

Re: Htmx is part of the GitHub Accelerator

#488

Post by charukiewicz »

dgb23 wrote: post #218
afavour wrote: post #112

Earlier quoted context omitted.

> 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 ot…

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

The point to take away from htmx and hypermedia more broadly is that there isn't a clean separation between the front end and back end of a site. The concept of completely separate front and back end teams building SPAs/JSON APIs has been a very costly development that has brought substantial complexity that is wholly unnecessary for most applications.

Your banking/project management/todo list/budgeting/insurance/education/whatever app almost certainly doesn't need to be an SPA and would be developed faster or for less money if it leaned into server side rendering (SSR) and used a library like htmx or Stimulus to enhance the user experience as needed.

Re: Htmx is part of the GitHub Accelerator

#489

Post by lelanthran »

throw1234651234 wrote: post #319
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…

This will just die like Web Components and RxJS after a few people write blog posts and do conference talks on it for hype, right? Does this work with Web Assembly? Of course Web Assembly will die too since it can't do SEO. In all seriousness though, what is the "core" reason to actually adopt this over the current approach?

> This will just die like Web Components

You mean "This just won't die"? Because it seems to me that Web Components are here to stay, especially since something like htmx boosts their functionality with absolutely minimal added cognitive load.

I feel that, pretty soon, the choices for a full-functioned web application that is easy to maintain with high development velocity is going to be:

1. Master HTMX and Web components in a day, and be productive

Or

2. Spend a month learning React, and still get hit by all the footguns.

Re: Htmx is part of the GitHub Accelerator

#490

Post by mst »

tommica wrote: post #386
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…

Stupid question, why doesn't htmx parse the response html and extract from that the relevant data out needs to fulfill the configuration? Feels a bit cumbersome to return the exact part of the response on server side, like the next page of the table, if it was requested with htmx, else return the full page. This way htmx would be even easier to implement in any front-end. Or maybe I am just crazy. Edit: or is it this…

It is that, yes.
Post reply on HN