Put aside the scoring and conclusion parts, the author has a couple interesting observations that resonate with me:
> ... but conscientious developers will be interested in doing things right. They’ll spend hours Googling for examples, trying to learn how to type things that TypeScript simply can’t type properly.
> ... if you only need to hire one or two developers, using TypeScript may make your opening more attractive to almost half the candidate pool.
On the other hand, it seems that the author worked on a few medium-size projects and then moved on:
> All projects for which impact was judged were >50k LOC with several collaborators working over several months.
So I wonder if he was able to evaluate the impacts from a longer term perspective, which shall include refactoring experience, iteration speed, developer morale, etc.
While React Native is constantly being improved, to use it in its current form, one has to be very aware of its under-developed parts, and more importantly, make them aware of by designers and PMs.
Surely for any "fancy" feature one may think of doing with RN, there are always some libraries, plugins, tutorials, solutions that exist in the vast ecosystem trying to help. But more often than not they eventually lead into a maintenance/integration nightmare, simply because how fast the whole mobile industry moves and leaves things behind.
Therefore, I suppose that a wise approach is what I would call "React Native-first design": let the whole team (PMs, designers, devs) know that anything that is not officially supported by React Native and without caveats is off the limit -- just try to avoid the design until it is fully supported.
IIRC the survey was open in July/August. But it took the authors 3+ months to produce this result, which IMO has very limited commentary. It would have been much nicer for such a time-sensitive survey to come out sooner.
(Disclaimer: Using RN in production) The author listed some very legit points that RN is lacking and I share the same pain or complaints. You can beat up any tech with its shortcomings and that will be a good read. But arriving at a conclusion that something unjustified is better is logically flawed.
I have been missing a feature from Alibaba Cloud that AWS does not provide and there seems no easy replacement: Their Object Storage Service (OSS)
provides an endpoint for transforming images (resizing/thumbnailing, compressing etc). Putting it behind a CDN (which is also integrated in the feature), this solves virtually all the image processing requirements ever needed in a common web or mobile application. https://www.alibabacloud.com/help/doc-detail/44687.htm?spm=a...
I think the closing down is normal in this case. If you were google, how would you motivate any SDE or ops to devote any time to it, given that a newer replacement is already in place?
> ... but conscientious developers will be interested in doing things right. They’ll spend hours Googling for examples, trying to learn how to type things that TypeScript simply can’t type properly.
> ... if you only need to hire one or two developers, using TypeScript may make your opening more attractive to almost half the candidate pool.
On the other hand, it seems that the author worked on a few medium-size projects and then moved on:
> All projects for which impact was judged were >50k LOC with several collaborators working over several months.
So I wonder if he was able to evaluate the impacts from a longer term perspective, which shall include refactoring experience, iteration speed, developer morale, etc.