gistfile1.txt

Me at 9:33 AM
Honestly, though, this should be a huge red flag that you have to jump through a dozen hoops just to properly type redux... It works well, but it's way more complicated than any state management needs to be.
I can write code in C/C++/Rust, I can work with binary data, I can render advanced imagery over Web/OpenGL, but I can't wrap my head around redux spaghetti. No fucking thanks, lol

Someone Else at 10:08 AM
so how would you manage a large redux state?

Me at 10:08 AM
not with redux
If you start to really look at their API, you could write your own store using less code that fits your own needs and is less complicated. Or, you could use a much more sane library like MobX
Too often developers will just grab libraries off the shelf without actually understanding their problem or how the libraries work
Just because people write about how much they love it on Dev.to doesn't mean you should use it too
/soapbox

Someone Else at 10:11 AM
Redux isn't complicated. And writing your own store will inevitably turn into a worse redux.

Me at 10:11 AM
That attitude just completely bewilders me
It's a common attitude

Someone Else at 10:11 AM
I have considered mobx, and may take another look at it.

Me at 10:12 AM
But it's so... lazy? Or safe. It's a very safe attitude. If you never learn to think outside the box that other people have put you in, you'll never grow.
See, I'm all about tearing systems apart, learning what makes them tick, and then finding better ways to do things. Just because someone did something that other people adopted doesn't mean it's the best way, especially since everyone's use case is going to vary

Someone Else at 10:14 AM
Sounds like you're all about the not invented here syndrome.

Me at 10:14 AM
No, I use tons of other people's work and libraries, I just choose not to blindly fall into patterns that don't make sense, simply because other people have

Someone Else at 10:14 AM
I don't disagree with you about always looking for better solutions.

Me at 10:15 AM
Hell, I adopted react quite early when it was on the up-and-up. I absolutely build on top of the shoulders of giants, but if you seriously think that every giant is created equal, then you should maybe start being more curious and start asking more questions

Someone Else at 10:15 AM
But I also don't want to leave behind a homegrown state system that's hard to onboard new devs onto.

Me at 10:17 AM
Just because people widely adopt something, it doesn't mean that it's good. Just look at php, python, ruby, etc. Widely adopted languages that are honestly pretty terrible, lol
Well, ruby is mostly dead at this point

Someone Else at 10:17 AM
It's all subjective.

Me at 10:17 AM
It's not all subjective
If you want solid numbers to compare by, let's look at performance
Especially of python
The only way to get performant code out of python is to actually not use python and have it use C libraries under the hood
Of course there are use cases where you don't need to squeeze performance out of it, and I get that, but if you want an objective view across the board, python is slow as fuck, lol

Someone Else at 10:20 AM
Can't really argue with you there, as I'm not very familiar with python.

Me at 10:21 AM
Way off topic anyways, lol. The point is, that yes, you're right in that it's gonna be easier to onboard new people using established patterns, but if you blindly adopt a pattern simply because other people are, you're not really doing your job as an engineer. You have a specific problem at hand. Not every bandaid is going to work for every problem.
And if you have to jump through a dozen hoops to properly type your redux stores for your specific use case, then maybe you need to reevaluate if it's the right solution for your problem