41–50 of 81 posts
I got a wave of shudder reading the acronym "HAM stack". Yugh. MEAN, MERN, RERN–once hyped up hot air which now sounds so dated and hackneyed. It's cool to be excited about tech but if your main selling point is building "faster and cheaper", I don't know if picking up a minimalistic framework you know nothing about is faster than just re-using your trusty boilerplate. Be it React or Svelte or whatever. With serverle…
Earlier quoted context omitted.
Htmx can scale. It's very basic and Htmx isn't the only technology to use that approach.
It cannot scale because it doesn't have a solution for reusable components. That's why I have abandoned it. Frameworks like React solve this in a much saner way.
Earlier quoted context omitted.
They didn't mention sending JSON though... and you can absolutely return HTML fragments in a JSON response.
But why?
so far I got HARM (Rust), HARC (Raku) and now HAM (F#) along with Fast HTML / htpy (Python) and GOTHH (Go)
seriously, it is very good news that HTMX has uncoupled web development from the server side language choice
now there is a blossoming of many server side stacks to fill this new opportunity
I wrote https://harcstack.org because Raku is the natural successor to perl and PHP for web development due to its facility with text processing and multi-paradigm chops
Earlier quoted context omitted.
Htmx can scale. It's very basic and Htmx isn't the only technology to use that approach.
It cannot scale because it doesn't have a solution for reusable components. That's why I have abandoned it. Frameworks like React solve this in a much saner way.
class Counter does Component {
has Int $.count = 0;
method increment is controller {
$!count++;
self
}
method HTML {
input :id("counter-$.id"),
:name("counter"), :value($!count)
}
}HTMX sets up an underlying network traffic pattern: 1. The user interacts with the page. 2. The page sends a request to the server. 3. The server returns one response to the client, containing HTML, which the client inserts into the page. 4. (Optional) If the response includes references to other resources, like images or fonts, the client makes more requests for these. The consequence of the 'one request, one respon…
Is it basically like Ajax?
Earlier quoted context omitted.
Yes. The cycle has completed and the old new things are new again. But they're still too new and unproven for the React-embroiled companies to switch just yet. HTMX is basically a framework for AJAX that lets you more quickly set up interactions in the markup instead of having to write scripts to manipulate the DOM yourself. It also tells on sending HTML fragments over the asynchronous request instead of JSON that ha…
> But they're still too new and unproven for the React-embroiled companies to switch just yet. I've seen a few of HTMX projects attempted in production, at my previous employer. Decently sized, moderately complex web products for serious commercial purposes I will say though, all three were complete disasters.
https://htmx.org/essays/when-to-use-hypermedia/
However, in many case, it can be much simpler architecture than alternative approaches:
I can't believe they still don't have a way to parse JSON responses automatically. If you combine e.g. hx-post with hx-target, then it will put the text from the response into the target selector... but there is no "hx-source" to select what part of the response to use. I'd really love to be able to set e.g. hx-source="somejsonfield" instead of having to manually handle the response with a custom function that parses…
we do have a json extension for handling JSON responses, but it's a step away from the hypermedia architecture:
HTMX seems like a solution in search of a problem.
Considering most of my side projects are web based and I loathe JS and prefer MPA patterns, this is very intriguing. I admit I haven’t been keeping up with HTMX or new web frameworks. Anyone have any examples that are noteworthy?
As I mentioned in a comment above, I've seen a few commercial projects attempted. But I'm hesitant to recommend HTMX, all three of them were failures (and for technical reasons not business ones)