Good ole Django. Worked with a number of frameworks (tm), but nothing really quite scratches my itch like Django does. I still find the ORM and database migration system unmatched.
I found Django a bit hard to get on with vs. other frameworks and I've used Rails, .NET MVC and Express (and friends). I just found more friction trying to achieve X for any given X for some reason. Not sure why.
Yes you could, or even just a vanilla DOM event handler on a button click.
The problem is that you cannot introspect the browser’s history with the history API. So you have to hack your way around that if you want the “go back in history if possible, otherwise navigate to fallback url” behavior. Which I guess is easier if you’re in a react SPA. Or if you’re fully a MPA and can just check document.referrer
There’s a brand new Navigation API that does let you introspect history entries from the same origin, which perfectly addresses the issue.
There's several frameworks that use JSX but don't act like React. I definitely have found myself in the "I love JSX but don't always love React" camp. I used Cycle.JS for a while, but came back to React for the ecosystem.
For what it is worth, I'm rather proud of my smaller reactive (RxJS-based) JSX alternative (Butterfloat), which is not a Virtual DOM like React or Cycle.JS (it is more "What if Knockout but TSX?"), and I am working on its second version now (among other things expanding its SSR/SSG powers, which already have a very different, I'd argue simpler, take on SSR/SSG than the Next.js/Nuxt.js/React Server Components world).
I’m the opposite. I loved React (before its hook madness) but I hated JSX. I’ve been using a lispy language to write React since it first came out. Initially went with someone’s pet project and eventually switched to ClojureScript. If you are already tolerating a build tool to transform your code into a form browsers can run, why not switch to a better language that’s designed for nested tree structures?
Working with multiple teams in a large project, hooks can be a nightmare to maintain.
I see 7x layers deep of hooks, with no test cases to support them. Some of the side effects are not properly tested, and mocks that abstract away the whole implementation means the test case only works for certain scenarios.
FWIW this scenario might be an outlier in large projects, considering how some developers prefer to "just wrap the hook in another hook, and not worry about its internals".
That's a valid concern. I've seen some hard to grok hooks with polling, async stuff, hard to follow logic, etc. Like with anything, need to have taste, it's easy to dump too much into one hook and like you mention, it gets hard to follow what gets triggered when.
reply