Comment by breckenedge

This is the missing criteria in the technical decision making, IMO. How reliant is the team on the recruiting/retention of the current size and structure of the talent, both on the team and in the wider community?

Small teams trying to keep burn ultra low vs. giant companies might have similar technical goals but opposite staff capabilities. This is a crucial factor.

A second-order effect is how much time/energy/money you have to throw at maintenance. Can you afford to spend X% of your time on maintenance? Which technologies offer comparative advantages on maintenance cost? These are surprisingly often easy to answer, and nearly never explicitly considered!

I just write everything from scratch. This seems like a lot of work but it allows me to focus on other things that usually have no deadlines.

Im dense enough to delete things and rewrite if they require babysitting.

Im sorry but I was never able to relate to this problem. All core libraries of javascript are atleast a decade old at this point and that too without any major breaking changes.

Express is almost decade old, react is more than a decade old, redux is almost a decade old, Tailwind is the only new thing but that too is almost half a decade old.

Can you share your package.json?

This is essentially how DOM manipulation works, which is JS' main use case.

You’re never telling React “do this”, instead it’s always “change this state” and then hope that it does what you expect it to do, but instead it re-renders 10 components for nonobvious reasons. Sure useMemo can help with this, but, eh, I just wish it worked the first way.

And every React-adjacent project either ends up abandoned or subsumed into the beast.

> I like React on the web, but only when using hooks and only because I haven't found anything that I like more than it.

After being thrown into the Angular woods for a while I found that what I really wanted was just a "React with RxJS Observables that look like writing Hooks if you squint, but don't have some of the complex rules either" and then I realized that I was basically trying to reinvent some of Knockout, but with TSX templates. I'm still amazed by how much I was able to accomplish from that idea, including some of the "advanced" features of modern React, in a relatively small package (modulo the one and only one dependency on RxJS).

I don't know how many other developers want the same thing.

(I know some find RxJS overly complex, which is exactly why Angular is as awful to work in as it is, both in how it badly uses RxJS (and teaches bad habits) and how there's generally three ways to do everything, one with RxJS and two others avoiding it or misusing it, with now a fourth way of Signals which are just RxJS-lite with Knockout-style `computed`, proving time is a flat circle and Angular remains a design-by-committee mishmash of too many things that don't interoperate well. I think learning Angular's mishmash is far worse than just learning RxJS well, but I also spent a lot of time doing Rx in C# and in CycleJS for a while, too.)

Yea precisely. Hooks themselves are OK, it’s just plain ole code reuse, necessary the language itself makes that somewhat difficult. But then you’re not programming JS anymore — you’re wed to React and nothing else. I hate how it takes over codebases.