i still don't prefer that style though

hence why I'm here 😁

same!

it decides when to interleave them

<<-- there's one gripe I have Another: you typically end up having to use another library to manage more complicated states (Redux, MobX being examples). Well now you've increased your bundle size. Then you have to change your api (don't care if it's rest or graphql) to meet the needs of the frontend and keep that performant too

you don't only kick the problems down the road with frameworks like react but you also complicate already solved problems

htmx makes way more sense to this crotchedy old programmer who's seen it all over 25 years

why grug go into complexity demon spirit lairs

Architectures like React, IMO, only really start to make sense when you're solving Facebook app level problems. Where you have multiple islands of interactivity (or refreshing) on a single page, often delivered by entirely separate teams and integrated by yet another team. If you're not living in that world, you are probably better off with some simpler model.

But cargo cult and voodoo coding say if Facebook or Google tempt battles with complexity demon, so should Grug.

My 2 cents: I like writing applications in Go, but I am not a fan of writing website backends in it because for starters I don't like the standard template engine. I tried other template engines but the tooling around them sucks. I didn't want to try front end frameworks either because they seemed so complicated. At some point I decided to try using a couple different front end frameworks that just call JSON API endpoints and I really prefer it. The tooling around front end frameworks is great: hot module replacement, easy Tailwind integration, out of the box TypeScript support, minifying assets, adding the hash to the file name for caching, etc. I also like client-side routing, no full page refreshes, not having to keep all state on the server, etc. Of course there are solutions like adding HTMX and Alpine.js in the mix, but it just doesn't feel as polished to me. My Go app is primarily a JSON API anyway so I just reuse existing code. But then again, this is for a personal project and I have too much time on my hands so I can imagine that for a lot of people just using HTMX is the way to go. Front end frameworks and libraries move rapidly, so unless you want to spend a bunch of time keeping your code up to date with the latest versions, it might not be the best choice. Anyway, if anyone has questions about React, Next.js, Vue, Nuxt, Svelte or SvelteKit, let me know.

I don't actually use it much myself, though I would if I had appropriate use cases. As is my app is a non-PWA SPA. It's pure Javascript and DOM with no back end at all, and uses hyperscript for UI interactivity and JS libraries to implement the actual functionality.

avi checks out

🤣

Front end frameworks are a psyop

i don't even know who's psyoping who anymore

Pysops have become memetically self-aware and choose their own targets.

Luke Plant (core Django dev and htmx + django patterns wizard) suggested using only GET and POST. Given how long we've been using those two verbs, and given that well established frameworks don't use those verbs natively, what's the value proposition of taking the time to figure out how to use them?

I found using a client-side store makes React/etc somewhat better. Astro to glue components together, and all React/etc do is update the store. Clicking a button updates the store. Then the store handles the logic (API call, etc). Usually just one hook, to rerender on a change in the store. So update a table is just cramming the API response into a store variable, and the hook rerenders the table. Astro+nanostores has been good for this.

> Also, HTMX is best styled with semantic classes. Which is a problem for companies using Tailwind and utility classes in their HTML. This critique is actually more accurate about hyperscript, I think. Django-widget-tweaks fixes the Tailwind problem in Django easily.

Can you expand on that a little bit? I just don't see how semantic classes makes noticeable difference in htmx/hyperscript but if I'm wrong, I'm wrong.

I've had the same thought. I want to take the time to learn how to increment a count properly in React to make a comparison video based off this video:

Things might have changed, but last I saw, you couldn't

add

or

remove

multiple classes in my command.

Also, hyperscript doesn't support Tailwind classes like .bg-red-500/50 or arbitrary classes.

Just checked, and it looks like

add

and

remove

can work on multiple classes at once now. Still, the other things are true.

ok so you're right BUT

I mean, hacky, but it was the quickest I could think of

might be smarter ways to do that

If I wanted to get crazy, I could have a hidden element on page that housed the classes I wanted to use for any given state of an element and then use hyperscript to pull

<element>@class as string

and then put it into my element on some event

so, like... I dunno, I just feel like there are some easy and creative escape hatches