There are some big parts identified for this case, and because it is dependency of 3rd party service, we can not do much about it.
But more importantly, I think it is the product itself, the market is probably does not appreciate that much of "customization / personalization" as I thought, in other words, we are probably haven't figured out the best path to get the ideal users yet.
In the other side, free users do not have this issue. We do have free tier which counts for 1/3 of all active users.
I find a lot of this to also be true with sole engineers managing agents.
I've now seriously approached vibecoding two nontrivial projects, and in each case using "safe tools" was a good way to get to a working stage, faster:
- in one I insisted on typescript early and found it to be more of a hurdle than letting the LLM cobble js learning in and address bugs in a way an engineer might find uncivilized (trial and error over bulletproof typing).
- in another, I found that using react was not offering much benefit to a given project, and asked the llm to rewrite in vanilla. while this mostly worked, it introduced new bugs that were not present when using react. switching BACK to react eliminated these and enabled the LLM to continue writing features at no (current) technical or performance cost!
just want something comparable to next (api layer, ssr ability, nice surface api), for a relatively simple case (oauth with ms, simple api to query other apis).
I'm avoiding Next because deploying it on anything non-vercel sucks.
I still have no idea what benefits having your API serve markup is supposed to confer, but people tell me it's "great".
also, I find your headline misleading. htmx uses javascript, there's no accessing anything "directly from html". you could say that about any framework with directives, ie vue, but we all know better.
you mean via SSE? is any part of that an inherent "htmx only" thing, or even a "markup API only" thing?
a framework using a neat piece of technology isn't really a boon for the framework -- the technology of streaming itself is great, sure, but you can do that with any stack.
Sure, but the browser is fast and rendering HTML so why stream anything else? Why stream javascript + json to build html. You're adding a bunch of marshalling that doesn't need to be there.
Yeah, as I understand it the idea is that instead of making the server-side complex and the frontend code complex, you retain as much complexity server-side as possible and treat the browser as just a hypermedia renderer.
If a part of the page needs to change, the server figures out what it should change to and sends that page fragment.
Right. But, hypermedia systems doesn't go far enough. It can be even simpler then that.
In a video game the "server" doesn't figure out what's changed (that's too much work) it just redraws the frame. So rather than the complexity of working out what has changed you can just send down the whole page again whenever something changes.
This gives you view = f(state) over the wire and has great DX. It's called immediate mode in games.
The main point of hypermedia is the browser, not a gaming platform. Not even the mobile platform. HTMX is not purposed nor it advertises that it should be used outside of the browser scope.
I use Unpoly that replies on the same principles (HTML over the wire) and both of them are very clear about their intentions.
In my mind collaborative apps are a core feature of the web. Streaming hypermedia is a great way to keep all your state on the server and have a solid multiplayer/realtime experience, especially with large datasets.
Here's a basic google sheets clone that does just that:
I mean, the main goal would be not to have one's limbs blown off at war, I don't really care if they pay me. I'm confused... drafting has nothing to do with voluntarily enlisting.
on reading, not seeing your actual markup code generation and seeing method stubs instead doesn't inspire me to change. seemingly, htmx only moves the markup generation from client to server, making the server/api more brittle in the process. I was unconvinced before that it's an improvement and remain that way.
reply