As a long time fan of rust I’m very disappointed this name was used do a ui app. It’s close to the stack I use but don’t see any reason why I’d want to try it out.
I was just browsing through this code all night. In principle, Htmx is really showing how React or any frontend framework is just not needed for most applications. Htmx simplifies everything.. even component endpoint caching is as simple as just adding a good ol' header. No more "partial rendering" or related complexity needed.
I'm still unconvinced that Rust is a good idea for general web servers due to (overly) aggressive compiler checks and chaotic documentation related to web server concerns (many Rust web related libs cannot work together or not easily).
Today I'm mostly just using Hono+htmx+view transitions. Astro is a similar stack, but with more batteries included (and some additional complexity).
When there's a programming language in the project name and it's not a library, it's not a good sign. It means that there was nothing interesting worth mentioning.
In general you are right, but as the readme says, this project was an experiment to try out the stack. The intended consumer of the repo is probably not someone who wants to run yet-another-chatgpt-clone, but someone who wants to poke at the code, in which case the stack is the most relevant information!
I barely know htmx but this example seems quite easy to parse. This snippet deletes a chat from the backend and removes the corresponding element in the UI.
- send a DELETE request to /chat/chat.id
- the response is going to swap the content of the #chat-chat.id element
I think that snippet is perfectly reasonable if you are an individual or a small team in charge of the whole stack. This line of code is unlikely ever to change. Contrast this with React+Redux, where the code must constantly change to accommodate schema changes from the backend. The React project thus changes more often, but this is a false sense of maintainability. Further, imagine the 200+ dependencies a starter React app requires and how all of these must be kept up to date.
Hype as in, why announce that it was made in Rust? Well to me, because i like to see the languages things are made in, and i especially like to see projects i would be interested in contributing to (read: also using my preferred language at the time).
It was the same for Go when i was using Go. Why is this always debated?
When I browsed GitHub repos. I came across some repos that implied "Because my thing is written in Rust, it automatically comes with a good performance, good scalability, etc". Jumping into a new language because people said it has good performance without actually understanding suited applications and the reason it gives a good performance seems to be a hype to me. It can be just my own bias. Maybe people out there already have a very solid understanding of Rust.
The times I've searched for Rust stuff on GitHub I've mostly found junk, like projects people wrote while they were learning Rust, also leaving them abandoned.
Maybe you should search around for solid projects and look into them in order to gain appreciation the language.
Or watch a couple of videos from Jon Gjengset, like his recent "Implementing (part of) a BitTorrent client in Rust" [0] while keeping in mind that the code he's writing is memory safe, which would probably not be the case with C at the same expertise level and speed of development. And considering that it is a BitTorrent client, one would definitely want it to be memory safe.
This comes up a lot but I never get tired of answering it. There might not be anything about Rust that is interesting to you personally but generally the benefits are different depending on what language you're coming from:
If you're coming from C/C++/C# you get very good memory guarantees, a standard library that is very well fleshed out, a well supported package manager and a fairly robust (though a bit immature still) ecosystem.
If you're coming from Java or Golang, you have the benefit that now your code can be consumed by other languages. You also get the memory guarantees, better error handling ergonomics, and in the case of Java the ecosystem is much higher quality and safer (at least in my extensive experience).
From Java specifically (and any of its derived languages), you loose all the operational and memory problems that come with just starting the JVM.
If you're coming from Python, Ruby, JavaScript the biggest benefit is probably performance but you get all the benefits that Java and Golang do as these are also dead end languages.
There is a lot of quality of life, safety, security, and performance benefits but what matters the most to YOU is going to largely depend on where you're coming from, what you want to build in it, and what your priorities are. It legitimately isn't for everyone, but its a VERY good choice as a default language.
This is such a great project, thank you for sharing! It seems like you're getting the usual dump of negativity around HTMX... but as usual, not much coming from anyone who's actually tried to build something small/medium-sized. I keep hearing that this stack "would" fall apart in a bigger project, but I never hear any concrete, empirical descriptions of issues that actually do arise.
I'll offer one here... using HTMX usually means you're going to be writing HTML templates, and HTML templating languages don't have much IDE support. I really miss goto-definition etc. when I'm writing Jinja templates.
That being said, I've personally found Rust/HTMX to be a magnificent combo. I personally find writing backend endpoints in Rust to be no more cumbersome than any other language (after becoming comfortable with Rust)... and there's massive gains from the incredible tooling and type system.
I wonder if you've considered using Askama for your templates? It has a Axum integration that cleans up some of the boilerplate around template rendering. There's also an open PR for block fragments [1], which will make componentization of HTML fragments much easier, as discussed in this essay on the HTMX site [2].
We need more projects like this to demonstrate how useful, highly-interactive apps are made with HTMX. I'd encourage skeptics to try the same before writing it off.
> HTML templating languages don't have much IDE support
However JSX has amazing IDE support, but you need to use JS/TS with it. This is where I think the ergonomics of JSX defined Htmx endpoint rendering has been a very natural DX transition moving away from SPAs. Now with CSS View Transitions and htmx element replacements, the user experience is largely just as seamless as developing a spa app.
I think a lot of us reach for Jinja-style templates so it feels a little more like we're writing bare HTML. But they're of course still just templates, and they need a build step before they become valid HTML.
So it's true, if you're willing to use a DSL embedded in your server language (like JSX), then you'll have the full language tooling available to you. And this probably isn't giving up much over language-specific templates.
A JSX-equivalent for the Rust server-side rendering world would probably be maud [1] or leptos [2].
I appreciate the insight. I looked into Maud, but it's very different from being a drop in html template engine like JSX, where most of the time vanilla html is a drop-in. I'll have to look more into leptos and understand its DX approach to Rust web apps and how it would mesh with Htmx.
32 comments
[ 3.0 ms ] story [ 68.3 ms ] threadI'm still unconvinced that Rust is a good idea for general web servers due to (overly) aggressive compiler checks and chaotic documentation related to web server concerns (many Rust web related libs cannot work together or not easily).
Today I'm mostly just using Hono+htmx+view transitions. Astro is a similar stack, but with more batteries included (and some additional complexity).
In reality, it contributes nothing to gpt.
Also, it’d be nice if one could try the demo without creating an account. Otherwise I’m just judging by your screenshots.
> Why not Bun?
On a perfectly fine project that was using Deno instead of Bun. You can't really have it both ways.
e.g.
hx-delete="/chat/{{ chat.id }}" hx-target="#chat-{{ chat.id }}" hx-swap="outerHTML"
- send a DELETE request to /chat/chat.id
- the response is going to swap the content of the #chat-chat.id element
How could I implement an error flash message in case the delete fails in this case?
The server can include a couple response headers to override the placement of the message to not affect the existing page state
https://htmx.org/docs/#response-headers
This allows the error to either be added inline in the UI somewhere or (my preference) displayed as a toast by appending to the end of the <body>
It was the same for Go when i was using Go. Why is this always debated?
Maybe you should search around for solid projects and look into them in order to gain appreciation the language.
Or watch a couple of videos from Jon Gjengset, like his recent "Implementing (part of) a BitTorrent client in Rust" [0] while keeping in mind that the code he's writing is memory safe, which would probably not be the case with C at the same expertise level and speed of development. And considering that it is a BitTorrent client, one would definitely want it to be memory safe.
[0] https://www.youtube.com/watch?v=jf_ddGnum_4
If you're coming from C/C++/C# you get very good memory guarantees, a standard library that is very well fleshed out, a well supported package manager and a fairly robust (though a bit immature still) ecosystem.
If you're coming from Java or Golang, you have the benefit that now your code can be consumed by other languages. You also get the memory guarantees, better error handling ergonomics, and in the case of Java the ecosystem is much higher quality and safer (at least in my extensive experience).
From Java specifically (and any of its derived languages), you loose all the operational and memory problems that come with just starting the JVM.
If you're coming from Python, Ruby, JavaScript the biggest benefit is probably performance but you get all the benefits that Java and Golang do as these are also dead end languages.
There is a lot of quality of life, safety, security, and performance benefits but what matters the most to YOU is going to largely depend on where you're coming from, what you want to build in it, and what your priorities are. It legitimately isn't for everyone, but its a VERY good choice as a default language.
warning: `rustgpt` (bin "rustgpt") generated 15 warnings error: could not compile `rustgpt` (bin "rustgpt") due to 19 previous errors; 15 warnings emitted
I'll offer one here... using HTMX usually means you're going to be writing HTML templates, and HTML templating languages don't have much IDE support. I really miss goto-definition etc. when I'm writing Jinja templates.
That being said, I've personally found Rust/HTMX to be a magnificent combo. I personally find writing backend endpoints in Rust to be no more cumbersome than any other language (after becoming comfortable with Rust)... and there's massive gains from the incredible tooling and type system.
I wonder if you've considered using Askama for your templates? It has a Axum integration that cleans up some of the boilerplate around template rendering. There's also an open PR for block fragments [1], which will make componentization of HTML fragments much easier, as discussed in this essay on the HTMX site [2].
We need more projects like this to demonstrate how useful, highly-interactive apps are made with HTMX. I'd encourage skeptics to try the same before writing it off.
[1] https://github.com/djc/askama/pull/824 [2] https://htmx.org/essays/template-fragments/
However JSX has amazing IDE support, but you need to use JS/TS with it. This is where I think the ergonomics of JSX defined Htmx endpoint rendering has been a very natural DX transition moving away from SPAs. Now with CSS View Transitions and htmx element replacements, the user experience is largely just as seamless as developing a spa app.
So it's true, if you're willing to use a DSL embedded in your server language (like JSX), then you'll have the full language tooling available to you. And this probably isn't giving up much over language-specific templates.
A JSX-equivalent for the Rust server-side rendering world would probably be maud [1] or leptos [2].
[1] https://github.com/lambda-fairy/maud
[2] https://github.com/leptos-rs/leptos