I've started writing up a coding guide for hypermedia-driven application architectures. #htmx
It's very much a work in progress. Some bits not started yet. But I'm quite happy with some of it...
https://hda.daz.is/architecture/why-hypermedia-driven-architecture/
More to come some!
#React is an obsolete tech and hopefully my guide, when done, will help people who want to switch to #HDA architecture from #spa
Hopefully the #Rust won't put people off.
I've started writing up a coding guide for hypermedia-driven application architectures. #htmx
It's very much a work in progress. Some bits not started yet. But I'm quite happy with some of it...
https://hda.daz.is/architecture/why-hypermedia-driven-architecture/
More to come some!
#React is an obsolete tech and hopefully my guide, when done, will help people who want to switch to #HDA architecture from #spa
Hopefully the #Rust won't put people off.
From the archive! A Look At HTMX With PHP
In this article we will look at how to get HTMX working with a vanilla PHP backend. With a few examples of the two systems working together.
https://www.hashbangcode.com/article/look-htmx-php
This ties into a package just released that shows a lot of different examples of HTMX working with a PHP backend.
From the archive! A Look At HTMX With PHP
In this article we will look at how to get HTMX working with a vanilla PHP backend. With a few examples of the two systems working together.
https://www.hashbangcode.com/article/look-htmx-php
This ties into a package just released that shows a lot of different examples of HTMX working with a PHP backend.
Oh, that is very interesting. I will queue this up for inclusion in the delightful fediverse development curated list.
#Datastar may be a great library to check out here, and goes further in #hypermedia approach, where #HTMX considers itself feature-complete. Datastar uses #SSE to keep the connection to the client open. The client-side JS lib that is needed is super small. In datastar apps most of the business logic lives in the backend, and it lends itself very well for #EventSourcing. The original author/co-maintainer uses it with #NATS which also serves as the event store.
@smallcircles To follow up on the discussion from yesterday, @evan has created a proposal for another kind of “event stream” that is not necessarily associated with *any* AP collection type (see Example 1). This is more aligned with my mental model of an event feed/stream, where a timeline^1 is the history of the feed after optional filtering and content materialization. (^1 However, the terms are often used interchangeably in the Fedi.)
Oh, that is very interesting. I will queue this up for inclusion in the delightful fediverse development curated list.
#Datastar may be a great library to check out here, and goes further in #hypermedia approach, where #HTMX considers itself feature-complete. Datastar uses #SSE to keep the connection to the client open. The client-side JS lib that is needed is super small. In datastar apps most of the business logic lives in the backend, and it lends itself very well for #EventSourcing. The original author/co-maintainer uses it with #NATS which also serves as the event store.
The early Web had a quality that has been lost ever since: it was *simple*
Download #httpd , #netscape write some #html by hand and boom, the concept of a networked digital society is born.
It first started going pear shaped with #LAMP . The complexity of a full blown database was not justified for most use cases. As proven decades later by the popularity of #sqlite and #ssg approaches.
The final blow was when #bigtech got into the act. Immense complexity for the simplest things became a moat
The journey of #javascript is the poster child of out of control #complexity. What started as tiny client side code to introduce some interactivity has eaten html itself (virtual #dom) and then metastasized also on the server side. A gargantuan duplication of functionality between client and server that eventually backlashed into the #htmx and #livewire type approaches.
When you throw in the explosion of mobile clients (with architectures controlled by a duopoly) you get to the lunacy of today.
Just a though exercice... I've found a bunch of quite heavy projects to add toasts to an #htmx website, but I feel like there's a way to do it with just a <toast>...</toast> node in a htmx response + a bunch of css classes and htmx attributes but I can't pull this off...
RE: https://fosstodon.org/@talkpython/115843758399281516
un épisode de @talkpython avec les personnes ayant créé les #frameworks #web #Python FastAPI, Flask, Django, Quart et Litestar.
- les briques des frameworks : wsgi / asgi
- async / await
- concurrence par threads et process
- ORM
- critères de choix d'un framework
- tâches de fond
- #HTMX
- hébergement cloud ou non
This might be the best episode of 2026 even though it's only the first. Features Flask, Django, FastAPI, and Litestar. #python
#533: Web Frameworks in Prod by Their Creators
Featuring With @davidism, @pgjones, Janek Nouvertné, Cody Fincher, @webology @carlton, @tiangolo, and @mkennedy
https://talkpython.fm/episodes/show/533/web-frameworks-in-prod-by-their-creators
Htmx: High Power Tools for HTML
https://github.com/bigskysoftware/htmx
#HackerNews #Htmx #HtmxTools #HTML #Development #WebDevelopment #OpenSource
Htmx: High Power Tools for HTML
https://github.com/bigskysoftware/htmx
#HackerNews #Htmx #HtmxTools #HTML #Development #WebDevelopment #OpenSource
RE: https://fosstodon.org/@talkpython/115843758399281516
un épisode de @talkpython avec les personnes ayant créé les #frameworks #web #Python FastAPI, Flask, Django, Quart et Litestar.
- les briques des frameworks : wsgi / asgi
- async / await
- concurrence par threads et process
- ORM
- critères de choix d'un framework
- tâches de fond
- #HTMX
- hébergement cloud ou non
This might be the best episode of 2026 even though it's only the first. Features Flask, Django, FastAPI, and Litestar. #python
#533: Web Frameworks in Prod by Their Creators
Featuring With @davidism, @pgjones, Janek Nouvertné, Cody Fincher, @webology @carlton, @tiangolo, and @mkennedy
https://talkpython.fm/episodes/show/533/web-frameworks-in-prod-by-their-creators
Am I being stupid or does HTMX not support this very simple use case?
on form submit:
1) clear the target area
2) show a loading indicator
3) trigger an ajax call
4) wait for the ajax call to return
5) hide the loading indicator
6) fill the target area
Ideally I would want the loading indicator IN the target area, but that would make it usable only once. Stupid, but I can live with it...
But what seems not to work is 1). It will show my indicator but not clear the target area.
It seems I have to write additional JS to get that behavior. Well then I can write the thing myself. So much for the promise of not having to write JavaScript for simple things.
#htmx #javascript
Django Interactive Frameworks Benchmark: Django LiveView (WebSocket), traditional SSR, HTMX (AJAX), and Django Unicorn (reactive components)
https://github.com/tanrax/django-interactive-frameworks-benchmark
#django #python #htmx #djangoliveview #djangounicorn