kevinsd

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.

Github stats on number of issues

# Totoal #

Flow: 2081 open, 2748 closed

Typescript: 2541 open, 14421 closed

# Between 4/11 and 5/11 #

Flow: 88 closed, 93 new

Typescript: 448 closed, 173 new

Note: We are using flow but we are not happy that Flow is not up to speed with answering questions or addressing concerns.

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.

"According to The State of Javascript survey, only 6% of responders that have used coffeescript before said that they would consider using it again."

Nit: the calculation seems wrong to me.

- Used it before, would use again: 6%

- Used it before, would not use again: 25%

- Therefore, "responders that have used coffeescript before said that they would consider using it again" shall be: 6% / (6% + 25%) = 19.4%

The post did not mention anything about babel (or whether it is still needed). Any pointers?

And squash merge is still an ee-only (paid-only) feature ¯\_(ツ)_/¯

Why do this when they have google hangout?

I can see that hangout is tied to a person but home phone is not. But making it a different product/service and charging $10/month is absurd.

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?

I have read all 1-3 parts that seem available at this time. My immediate questions are:

(a) is the client supposed to get a copy of the consensus to start with? (b) what if direct access to all DAs are blocked?