Recent searches
Search options
The pain and tears of "reactive" development.
I decided to update an old React Native project I hadn't touched since 2020. Due to Google Play's new requirements regarding minSdkVersion and targetSdkVersion, I inevitably had to upgrade React Native itself.
And that's when the fun began:
Half of the npm packages I'd previously used were effectively dead—either incompatible with the latest React Native version or simply deleted by their maintainers.
Along with React Native, I had to update NativeBase, which had transformed into Gluestack-UI. Unsurprisingly, Gluestack refused to install without the latest version of XCode, which in turn demanded the latest version of macOS. Fortunately, macOS still tolerates my hardware—at least for now. But I fear that's just temporary.
The ironic part is, the app itself is ridiculously simple: only five screens, hand-crafted logic, and minimal dependencies. Yet I've already lost several days on this.
I have significantly larger projects, and the mere thought of updating them pushes me towards uncontrolled panic. I genuinely believe that soon developers simply won't be able to manage all this complexity without AI assistance.
@henry Having (almost fully) switched to #NodeJS in 2012, I quickly recognized the danger of relying to _anything_ (#npm included, this one gave me a lot of pain for several times over the years).
Ended up with a monstrous monorepo. Forked (and improved) just 2 other people's repos, one abandoned and one that took months to finally get it right regarding garbage collection, but I had no time to wait.
Thereby I never got to a situation to hate a programming language because of the hype around it, but it surely got me coding a ton of #javascript.
The experience helped me a lot in JS5=>ECMAScript and ECMAScript=>TypeScript switching in the last year or so.
@crnkovic thanks for the inputs! I tried to organise a monorepo but it didn't work fine for me.
@henry However you turn it - it's pain 
After some initial nagging, I find the ECMAScript modules approach to be more lib-developer friendly - compared to CommonJS approach. It gently forces you to build a large lib inside a single repo, and then later use it via cherry-picking. But this is just an ECMAScript freshman's opinion, I'll see how it works once the ECMAScript monorepo grows significantly 
https://nodejs.org/api/esm.html