HTMX's whole vibe is amazing. It's good tech, kept simple, useful in gobs of situations, but doesn't take itself too seriously. I've used it in professional and side projects since intercooler.js, and still love it. Here's a crazy unicorn-laser-eyes mug[0] that evokes the vibes of NROL-39[1]. I adore it. [0]: https://swag.htmx.org/collections/octohorse [1]: https://en.wikipedia.org/wiki/USA-247
I was against it for ages but having have claude use it in a simple project and being frankly sick/bored of React, it seems nice.
with that im very enjoying the challenge of scaling ssr stuff like this. i am very tempted to throw months of my life away building out a full fledged framework that means no npm / node toolchains, an easier to customize component model thats more performant and doesn't feel like... abstractions of abstractions, compile time tree shakedowns. for all of it. streamlit showed me the beauty of a declarative api that kinda went and did the rest but it missed a ton of marks with its top to bottom runs and it's just awkward.. a little too opinionated, terrible performance, perhaps the dumbest state management ive ever seen in my life... nicegui improved on that, but python just doesn't fit the bill for what i want to do. something that's go and its fully reactive and gives you full control. i genuinely think the hardest part of doing this is designing a framework api that is approachable and easily-rememberable. golang actually makes this hard, python wins with kwargs and stuff. i also suppose i could just start using wasm
i think where this might all be headed.. it's a touchy subject if im being honest. our guy at work is an amazing person super candid and honest. he says it kinda hurts seeing the front end stack he's been in pretty much his entire career start to lose developer interest. we've talked in depth about how the entire history of things like react came to be out of necessity, a product of its time with all the historic constraints that used to exist.. it led to educational curriculums, bootcamps and full blown careers.. but it's really hard to get behind what feels like an overly complex workaround that spans well over a decade at this point. people have invested a lot in their frontend-frameworks and toolchains and workflows and other pieces of knowledge and understandably are ready to defend it the entire existence of "make the client browser do a lot of work work" model. but hey, I've used both heavily and for what it's worth I think server-side and a general programming language are really the path forward here and it feels like something that corrects one of computing histories biggest weird sidequests. i genuinely think everyone will have a deeper and better understanding of computing in general approaching from this angle, and i think ssr is a very valuable path to explore that can really open the doors to understanding what makes good software as you're forced to contend with the most important design pattern: if you're going to make the server do most of the work, what is needed to do it well & scale to many clients. it naturally leads you into some really exciting possibilities. i personally love where this is headed because it completely nerfs the need for such abominations such as graphql & it's supporting infra. i can just rawdog sql, the most goated query language of all time.
highly performant data grids imo are the gold standard of components. i'm okay with a blend of client and server side work to make this a reality, aggrid is a good example of a very sick front end lib that does this. but i look forward to seeing if anyone's going to do something new here that is performant as hell and served up from the backend, some kind of tanstack demonchild or satanic wasm data grid 9000