Comment by mattgreenrocks
2 days ago
Curious what you meant by the last sentence there. Does React uniquely complicate maintenance as a codebase grows?
2 days ago
Curious what you meant by the last sentence there. Does React uniquely complicate maintenance as a codebase grows?
Theres a constant churn of a bunch of dependencies. Devs add minuscule libraries all the time. And I think some of the best React libraries have been abandoned, which is kinda sad, but nice from a maintenance perspective.
React very much feels like programming using only side-effects and that’s not really a fun experience IMHO. Performance issues are also somewhat difficult to spot in review and not very elegant to solve.
It’s been a few years since I’ve used React Native so maybe things are better now?
This is my experience with all javascript stuff these days. If you leave the codebase even for a few months now you're spending days updating it to all the new breaking library changes. Worse, if your tooling is out of date you're probably spending a week just fighting to fix/change/update the tooling. It's the most brittle tech stack I've ever had to work with.
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!
2 replies →
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?
"React very much feels like programming using only side-effects" this absolutely nails it.
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.
1 reply →
> React very much feels like programming using only side-effects and that’s not really a fun experience IMHO.
This is interesting and I like the way you've phrased it. Are you talking about React Native, or React in general? And do you use hooks?
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. I still find it tedious and overly hook-y¹. It also gives a lot of wiggle room for devs to shoot themselves in the foot with useEffect, like some of my previous clients have done.
¹ Hold on, I gotta pull in 18 hooks from across my project, npm dependencies and react itself before I can write the jsx in what would otherwise be a 10-15 line fooButton function.
> 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.)
2 replies →
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.
Any idea on whether this is a result of just npm/js ecosystem? Or just native frameworks in general?
Trying to figure out if Flutter or RN would be best use of what little time I have left on this planet
We maintain a few number of projects for clients - the apps are feature complete and will not change much in the next years. The goal here is to spend not much money on the apps but to keep them functional in the appstore. RN is somewhat cheaper up fron than native development or say flutter. Unfortunately, maintenance cost is high and difficult to predict. Why? Appstores are adding new requirements and increase API-level all the time. Support for that is often baked into new RN versions. Unfortunately, new RN versions often break things, which break libraries in turn. So you need to upgrade this morass and if you are unlucky, you need to redevelop huge swaths of your app because the lib now is deprecated /works differently / will never be updated to the new RN version.
Also true for any large JS/TS application, in my experience. It's an emergent property of a developer culture that places no value on backwards compatibility.