something about using html attributes as a programming language makes me cringe a little. The toy apps look great and maybe where these can really shine, but seems like it may start to turn into a mess very quickly
People got so stuck on JS for decades that they've forgot that HyperText in HTML is there for a reason. It was always supposed to be more than just UI descriptor markup.
It is JS who is out of place in web. A little script in form of DHTML that grew into becoming a cancer that it is now.
And I feel a lot of Tailwind’s flak comes from people who never used it.
Having used inline styles in the past, there is no comparison to tailwind. Tailwind is a good and productive, though certainly not ideal tool. But it’s miles ahead of whatever else has been produced by css frameworks, in terms of productivity and maintainability.
These "stacks" ONLY work if you are building hobbyist apps, or if you want to sell services. A fast-moving product company has many better alternatives that are probably far more tailored to their business objectives and team composition.
Maintaining these things in production for many years is often painful and cumbersome. Moreover, they usually are introduced by a single person who has a lot of enthusiasm to maintain it, but when that person leaves all hell breaks loose. Even more fun is when the underlying infrastructure provider decides to deprecate an API that requires a ton of bespoke fixes (e.g. Netlify's Next.js edge plugin which recently had a behind-the-scenes change to how Lambdas are spun up causing bugs with state leaking between requests).
With that said, it's good to explore new technologies. I just wish these sorts of posts (which are thinly veiled product marketing/tutorials) would expand to actual direction/feedback about how to use new tools in production effectively.
This is a blog post from somebody exploring how to use a (combination of) tool and reporting on writing a TODO app with it. How could they give direction/feedback about how to use these tools in production effectively when they are only playing around themselves?
New tools are, by definition, new, and full of unknowns. There are roughly only two ways to use them in production effectively: either you understand what they are trying to do and take the risk because you are convinced it is The Way, or you wait until the tool/tech settles and becomes not so new anymore as the experience reports from the first group trickles in.
I'm not sure how that's worse than the plethora of binding attributes that you find in React/Vue/Svelte and the like. Sure they are not technically HTML attributes, but as programming languages, the outcome is very similar.
The `value={state}` / `onchange={evt => setState(evt.target.value)}` dance you do instead also fits the "programming with attributes" paradigm, which was my point.
That's really not the recommended way. Write a handler for the event and just mention it in jsx. Don't do stuff inline. Also jsx conceptually is not html. Just alternative syntax for some JS. You don't even have to use it if you want to completely avoid coding in anything that even resembles html.
This is also how frontend engineers do frontend, except their chosen random technologies tend to be orders of magnitude more complex for rarely justifiable reasons.
Yes, it is definitely a combination of things you could use. Calling it a "stack" makes it sounds like it's a good combination though.
If you find yourself using a library as quick fix to avoid learning or investing time into something, your end result will be forever limited by that. Real systems have hundreds or thousands of parts and they are always eventually complex, so complexity and the underlying tech cannot be avoided for long.
Think twice before building a house of cards, that's the wrong kind of stack.
There’s nothing in OPs architecture that dictates a descent into spaghetti code.
It looks very similar to a Flask (Python), Sinatra (Ruby) or Express (JavaScript) server-side application. It is very straightforward to use a traditional MVC-with-HTTP-verbs architecture.
These end up being way cleaner than whatever happens when you split up the backend and front end into separate coupled applications.
The downside has always been that your website seems a bit sluggish when doing full page reloads… but that’s where edge compute comes into play and it starts to feel as snappy as a server-side rendered web app feels when running locally.
Real systems don’t become “stacks” just because of their complexity. In fact there is no merit whatsoever in complexity unless it serves a great good!
Complexity can definitely be reduced and maintenance complexity is the real killer in software these days — both in price, wasted resources and stunted careers.
Simple means supportable, and we should encourage more people to explore systems that “just work” even if they sacrifice some elegance.
This may not be it, and your point about not confusing simplicity with progress is valid as heck, but there are good reasons to explore this stuff and I love seeing new combinations like this on HN.
I don’t really understand this perspective whatsoever. It sounds like you’re saying we shouldn’t rely on abstractions? Isn’t react a quick fix to avoid learning or investing in virtual dom management? Real systems are built upon abstractions
Absolutely incredible. I was working on something like this a few weeks ago but never got round to finishing. A huge source of inspiration: https://www.youtube.com/watch?v=cpzowDDJj24
Well it avoids client side state and improves load times. I personally think the main benefit of htmx is fetching components individually from the server and so JS on Edge makes sense.
It’s using cloudflare d1 as a database, which is based on SQLite. What does this means for multiple concurrent users/sessions and transaction management?
It means your SQL is sent to the location where your database actually lives. With promises of being able to send read-only requests to closer (potentially stale) replicas later.
Oh, ok, so Htmx avoids JS so let's hurry to shove some JS back around it. The entire appeal of HTMX for me is that I can basically never touch JS except maybe a tiny bit of progresive enhancement, at the end, probably in plain old vanilla browser only JS.
A better way to think about it is that HTMX avoids large, stateful, client-side applications, so that you keep all the actual logic on the server. You can still choose JS on the server side if you want, it's just no longer forced on you.
In this specific case, the point is to run the backend on the Cloudflare edge, and that only runs V8, so using a JS backend makes particular sense.
Yeah, and a bunch of other languages that also compile to wasm. But wasm is rarely a "first class" citizen (it is a tier 2 target for Rust, so there are no automated tested, for instance), so again, can't fault anyone for not making that choice.
But yeah, would be interesting. Actually, I'd also be interested in a perf+efficiency comparison between JS and $lang+WASM on the backend, because this discussion makes me realize that the JIT tradeoffs are wildly different for a long-running process servicing many requests per second compared with many copies of a single-user client.
