231–239 of 239 posts
And by the looks of it, the Author is starting to understand the reason React and the likes exists and has start to build them over again: https://fixiproject.org/ LOL. Frontend dev never changes.
What part of the Fixi project is building something like React?
Most sites/apps I work on are progressively enhanced ( https://www.gov.uk/service-manual/technology/using-progressi... ) So far I've used a little bit of htmx (2) for one of them, and I really love it. Just a few attributes and we get some very reasonable progressively enhanced client/server interactive elements without full page loads. Not sure I would choose if I had to make a SPA - it's partially from ignorance, b…
TIL! One more reason to like gov.uk. I had no idea this was a standard but in hindsight it's quite obvious that's the case. I wonder how much of a burden it is at times, and how one can enforce this with automation?
Automatic enforcement for all services is tricky, because you _can_ depend on JavaScript if the user needs justify it.
Earlier quoted context omitted.
I haven't used sessions in over a decade and haven't regretted that decision once. It opens up a whole new class of problems you don't have when using client-side frameworks.
So what do you use instead?
Having the client/server split has made this a lot easier to reason about. I store client state on the client and server state stays on the server.
Earlier quoted context omitted.
Are you not familiar with building web apps? So, when building for the web you'll essentially have 2 different categories of state: server and client. Server state is obviously what's pulled fromt the db, but that's 100% not where something like form state should be stored. Or button toggle state. Or whether a modal is open, etc.
I have written web apps and about 80% of the sorts of things you are talking about can be handled with just html/css and I just use javascript for the other 20%. It's not like when you use htmx it disables all other javascript APIs.
And it makes me think you haven't had as much experience as you think.
How do you deal with form state using CSS? Where does it get stored? In the html as elements? So not on the server?
Maybe I’m missing something, but why would you want HTMX server side rendering, rather than a restful API that can return platform-agnostic data structures that you could render in various contexts, like a SPA, or a mobile app, or a terminal app, etc?
Because serialisation and deserialisation have a price and you almost never need what you describe
And I disagree, we definitely use the same API for other contexts.
Congrats and thanks! htmx brings me joy. Pretty much every experiment I build now starts with Go, htmx, and SQLite to keep things simple and fast but still responsive. I put a few more thoughts about this here: https://housecat.com/blog/the-hugs-stack-hypermedia-unix-go-...
How are you using dbos with SQLite? The docs say its a Postgres library
Our Golang and Python SDKs support SQLite as well as Postgres.
Earlier quoted context omitted.
How are you using dbos with SQLite? The docs say its a Postgres library
Hello, I'm from DBOS. Our Golang and Python SDKs support SQLite as well as Postgres.
I recommend updating the README to mention SQLite somewhere, with maybe a link to https://docs.dbos.dev/golang/reference/configuration#using-s... ?
Earlier quoted context omitted.
I have written web apps and about 80% of the sorts of things you are talking about can be handled with just html/css and I just use javascript for the other 20%. It's not like when you use htmx it disables all other javascript APIs.
We are talking about how state is stored, not about CSS. And it makes me think you haven't had as much experience as you think. How do you deal with form state using CSS? Where does it get stored? In the html as elements? So not on the server?
For really simple stuff you can use CSS sibling selectors: https://jsfiddle.net/Kqscu/4/
For more complicated stuff, it is in the html as elements. With htmx you can often do this by making a request to the server to update a subtree; the server doesn't need to know the state that the user is seeing, just what is happening in the specific request.
Sometimes just updating html subtrees isn't quite enough, and then I use javascript. Transient state that is only concerned with what is presented to the user is probably not best done on the server.
Earlier quoted context omitted.
So what do you use instead?
It depends on the specific data. Do you have anything that you store in session in mind? Having the client/server split has made this a lot easier to reason about. I store client state on the client and server state stays on the server.