4 ms·

You're absolutely right, htmx is not built for every UX flow. But neither is React. And we've been reaching for it by default for everything and that's been a

You're absolutely right, htmx is not built for every UX flow. But neither is React. And we've been reaching for it by default for everything and that's been a mistake. So much of what's built these days could be stateless MPAs. Servers have gotten crazy fast, and I'd certainly rather optimize for page size and server latency than build a React app. With the upcoming views transitions api, a bit of htmx, and custom web components and you get 95% of what React offers without anywhere near the package size or complexity. You don't even need a compile step. I'd never argue htmx is best for all use cases, I would hate for it to mutate the way React has, trying to be everything to everyone. But I hope htmx is the start of re-thinking how they approach the web and realizing that there are significantly simpler ways to build a frontend.

lloydatkinson 2y ago
I definitely think it’s important to note it’s not really React that’s mutated it’s damn Vercel with its extreme vendor lock in plan with Next that’s trying to force React to be server side as much as client side, especially now that Vercel employs some React core team members. Unfortunately worked with someone I was reasonably sure was a ~~paid shill~~ part of some Vercel partner/influencer programme as they were adamant we must use Next (and Vercel but they lost that argument) for a project the team absolutely didn’t need to use it for. In fact the rewrite of a project was worse than the original application. The original was snappy and instant and just worked meanwhile the Next version was slow, full page refreshes for every action, and just totally awful. I couldn’t get off that team quick enough.
- langcss 2y ago
  Next is odd because it gives lots of "high preformance" vibes with static rendering and image optimization. It is fast enough but not as fast as tuning up a classic MVC app which caching, avoiding JS bundles and React or deferring scripts etc. Send out the right cache headers and chuck a CDN in front. Next is ironically fast if you prerender/static generate AND the client disables JS!

lloydatkinson 2y ago

I definitely think it’s important to note it’s not really React that’s mutated it’s damn Vercel with its extreme vendor lock in plan with Next that’s trying to force React to be server side as much as client side, especially now that Vercel employs some React core team members. Unfortunately worked with someone I was reasonably sure was a ~~paid shill~~ part of some Vercel partner/influencer programme as they were adamant we must use Next (and Vercel but they lost that argument) for a project the team absolutely didn’t need to use it for. In fact the rewrite of a project was worse than the original application. The original was snappy and instant and just worked meanwhile the Next version was slow, full page refreshes for every action, and just totally awful. I couldn’t get off that team quick enough.

langcss 2y ago
Next is odd because it gives lots of "high preformance" vibes with static rendering and image optimization. It is fast enough but not as fast as tuning up a classic MVC app which caching, avoiding JS bundles and React or deferring scripts etc. Send out the right cache headers and chuck a CDN in front. Next is ironically fast if you prerender/static generate AND the client disables JS!