I'm reading Pekka's book, Latency, and in chapter seven, he discusses the best serialization and deserialization is none at all, and he gives flatbuffers as opposed to protobufers as an example, which sends memory over the wire in little endian, but not in a serialized format. And it got me to thinking, React server components are serializing the JSON and React tree format and then deserializing it on the other end, along with hydrating it, which is effectively part of the deserialization process if you want to consider it as part of a function, functionally go-live environment. And that takes a really long time to produce that. So that just brought that to my imagination.
Remix V3 is using the HTMX model, serializing or sending HTML, which is effectively the end result markup, which is then spliced into the shell. So it's not really serialization at all. It's just sending those, sending those bytes over the wire.
13
Models are good at HTML and CSS, not so much HTMX, and even less DataStar.
As I explained, if I’m not the one writing the code, I don’t care nearly as much. React isn’t my favorite thing but it’s incredibly well resourced, and models are great at it.
I care more about solving problems than writing code I like.
1
29
Aman 🧋 retweeted
Go Goroutines → Concurrent Systems
Go Gin/Fiber → High-Performance APIs
Go GORM/sqlx → Database Access
Go HTMX → Full-Stack Web Apps
Go WebAssembly → Browser Apps
Go Wails/Fyne → Desktop Apps
Go Ebiten/OpenGL → Games & Graphics
Go TinyGo → Embedded & IoT
Go Docker/Kubernetes → Cloud-Native Systems
Go Apache Arrow → Analytics & Data Processing
one language
performance
simplicity
concurrency
full-stack
and people still say
"go is only for backend"
47
1
49
688
Unrelated to HTMX/FastAPI. I'm rebuilding devpu.sh to be Docker Compose compatible. It's a completely different model from what I was doing before and would have required a complete rewrite even if I stuck to FastAPI HTMX. But since I'm doing the rewrite, I thought I might as well pick a stack that manages async better and is more popular (it's open source).
1
1
85
I still use it in other places:
- Admin UI for heypi.dev, mostly because it needs to be lightweight and reliable
- All of my static sites (hx-boost)
I think it has its use, but I will likely not use it for complex anymore.
My hope is enough of it makes it into the HTML spec that we don't even need HTMX anymore
1
108
Avoiding the JavaScript package upgrade treadmill makes it worthwhile for me to stick with HTMX, even if writing the React code is no longer an issue
1
2
111
Maybe htmx just need a better skills section like shadcn ?
ui.shadcn.com/docs/skills
1
21
I hate it but I've also come to the same conclusion. HTMX really was great when I was the one writing code, but the advantages mostly disappear when AI is doing the writing.
2
2
87
I'm rewriting /dev/push entirely, moving it from FastAPI HTMX to TanStack Start. Not because I love React (I don't), but because it doesn't matter once somebody else is writing the code. And Codex is actually writing the code (mostly).
9
17
2,083
Astro やhtmxなどHTMLファーストの設計はよいと思うが、Next.jsが持つクライアント、サーバ、認証周りの機能を全てカバーするのはまだまだではないのかな。
だから、AHAスタック的なものはそこまで普及してない。
Next.jsの仕様をみてると、これを代替するフレームワークをつくるのはかなり大変そうだと思う。
改めてよくできたフレームワークだと思う。
サーバ、クライアント、認証それぞれ効率性を重視した設計もしてる。
各論では劣るかもしれないが、総合で考えるとこれに匹敵するものないのでは？
2
105
画面の更新を、サーバーが返すHTMLでそのまま差し替えるHTMXのような作り、また見直されてきましたね。規模によっては、重い構成を持ち込まない選択も現実的です。
15
Jun 13
How good are Crystal web servers at recompiling the backend and restarting quickly so you don't get forced out of flow state? With htmx et al. since all the logic is in the backend you're doing a lot of that
1
1
86
Jun 13
I’m looking for an excuse to write more HTMX.
Maybe I should rewrite my Next.js apps from scratch using HTMX.
What do you think?
2
3
362
Jun 13
it didn’t work out he said codebase is too complicated for him to understand i blame htmx
Jun 6
tomorrow I’m gonna call him and get some more input and if it’s good input then day after tomorrow I’m gonna hire him to fix it
23
