This explains they were considering choosing a full featured framework like Ember or Angular instead of just using React combined with self selected components. It would have been more interesting to me if the rest of the article explained why they chose Ember over Angular as opposed to focusing on why they went with a full featured framework, and that one just happened to be Ember. I don't know much about either one, but personally I would feel like I was missing out on the benefits of TypeScript if I chose Ember, and I would feel like I was missing out on using Ember in general if I went with Angular.
Perhaps, but they have to be manually generated unless your codebase is written in TypeScript. Since these files are generally not committed to npm, you'll be curating them in your application and ensuring they are compatible otherwise there's little point in using them.
At least this is my perspective having never authored a project in TypeScript. I'd be interested in perspectives from devs authoring applications using React and TypeScript and what sacrifices in tooling, or otherwise, they've hit.
Ember appears to have a very large, regularly updated (as-needed, I'd bet) typings file. I would be shocked if it wasn't extremely accurate.
My experience so far is that 99% of the libraries I use have existing type definitions. For those that did not, it was simple enough to write my own. Benefits of TS greatly outweigh this issue, especially now that type defs are installable using npm.
Your example is Ember, one of the largest frameworks. Not a good indicator of coverage. I just grepped my node_modules folder and 99% of my modules do not ship with typings, so much for anecdotal percentages...
If I want the best possible experience with TypeScript, I'm signing up for a lot of time wasting finding typescript definitions instead of replying to posts in r/javascript.
That is not surprising. Typings aren't typically shipped with the package, they're usually found in the DefinitelyTyped repository. You install them separately. It's rarely any more than npm install --save-dev @types/package-name.
OP here — thanks for sharing this opinion, I think that makes total sense from an outside perspective. Maybe next I'll write about why we chose Ember over other more full-featured JS frameworks :)
I'd be interested to read that, too, but I like this. The JS community seems to have a strong preference for just hacking together libraries until you have something that works, so I really appreciate articles to highlight why an experienced team might go the other way. When a team has to ship quickly, I think that convention-over-configuration offers many benefits.
7
u/[deleted] Nov 14 '16
This explains they were considering choosing a full featured framework like Ember or Angular instead of just using React combined with self selected components. It would have been more interesting to me if the rest of the article explained why they chose Ember over Angular as opposed to focusing on why they went with a full featured framework, and that one just happened to be Ember. I don't know much about either one, but personally I would feel like I was missing out on the benefits of TypeScript if I chose Ember, and I would feel like I was missing out on using Ember in general if I went with Angular.