quisido
commented
5 years ago I agree. That has always been the driving inspiration behind the development of ReactN. This repository as made because there wasn't enough adoption yet to have any data on development time saved -- just myself as a single anecdotal data point. A hurdle of adoption for some users was performance, which mattered on their app, so I created this to showcase the only real data I could collect at the time.
Since this, ReactN has exploded, and the commentary from developers as far as 'hours saved' can speak for itself.
While the developer experience is and always will be the primary drive behind ReactN's future, a baseline to say that adopting ReactN won't crash your app or quadruple your memory consumption at the very least needs to exist, and this repo aims to provide that proof.
Unfortunately, I don't own an organization large enough to assign ReactN to A/B projects for numerical data on hours and money saved. That would be a greater repo, but beyond the scope of my abilities right now.
If you have feedback or ideas on future steps, I am interested in hearing them.
juanlanus
Since a long time now, hardware resources are much less important than human resources.
Yes, is it good that the reactn bundle is 15% smaller.
But the real thing is that thousands of developer hours will be saved by an easy to understand state management feature. Entire lifespans, I'd say.
On the other hand, the performance-oriented discussions are remains of the old time when CPU time was expensive, like during the early mainframe years.
We developers are very fond of performance discussions and premature optimizations.
IMO selling reduxn should be (almost) totally focused in the ease to understand the API (the devs UI), mentioning the better performance as a non-central byproduct.