In the blog post, I have one example of the React use case with screen capture.
I find it very helpful to have properties defined, so when I use the component, I immediately know what are the props I can provide.
There are some 3rd party React components that won't have type definitions yet, but the popular ones are well covered. I have written most of the components I have used, so I haven't had many problems.
Good point! I used similar categorising as Anders Hejlberg used in the JavaScript Jabber podcast (https://devchat.tv/js-jabber/209-jsj-typescript-with-anders-...). For those who don't like audio, he basically referred TypeScript being superset of JavaScript, unlike some other languages.
It also depends on how deep do you want to go with language features.
Let's say you have existing ES2015 source code. You could start experimenting on a local machine and use a script to rename js files to ts. Run the TypeScript compiler and annotate some of the most used functions.
You can then check what is the experience of using those functions that have type annotations, what is the speed of the development, etc.
Sit down with colleagues, show what you have done and ask what do they think. You can then decide to proceed and stick with type annotations until you're sure. Use boy scouts rule: "Always leave the campground cleaner than you found it." aka add typings to the function declaration.
About the text editor: I think all editors use the same TypeScript compiler APIs. That would mean that you would get pretty much same suggestions, error lists, etc. Correct me if I am wrong. VS Code could have some other API calls or project file support.
JS Jabber episode was great! Full of great insights.
It would be interesting to hear more about your experiences. I have been quite hesitant to use more advanced TypeScript features and stayed on a type system related annotations.
3rd party libraries / frameworks written with non-JavaScript languages is worth another blog post and discussion. I agree completely with you that libraries / -most- frameworks should be written in plain old JS.
The reason is simple, contributing and reading the project source code should not start by learning a programming language. It is a different scenario when a team in a company has decided to learn and write their project with TypeScript/CoffeeScript/etc. language.
About tooling, I think writing modern JavaScript (ES2015, ES2016) is beneficial and therefore, you need a tool like Babel. When you go to that path, why not use TypeScript instead and get ES2015/ES2016 + type system + great compiler?
You're absolutely right. Flow seems to be a very good alternative.
One thing I would like to add regarding the .js files, TypeScript 1.8 added a flag --allowJs which makes some sanity checks to the plain old .js files.
The mandatory paperwork in case of freelancer is quite minimal effort. I have an accountant to whom I need to provide material. Currently in the paper form, but soon switching to electronic. Gathering the material takes about 2 hrs/ month.
Billing takes 5 minutes (I use web application called Zervant) and checking that the payment is received takes few minutes.
Then there are "random" stuff like updating insurance, meeting people (few times per month) etc.
It's just me who to blame. I like to leave early to work, so that when I commute it's quiet and I can do work in the train. But the problem is than I like evenings. You just have to have one Game of Thrones episode and sleep rhythm is ruined. ;)
My normal sleep routine would be 23:15 to bed and 06:45 up, so about 7,5 hours. Everything under that I consider sleep deficit.
I think you're right. It could mean exactly what you said that all work is done in 4-days and then three days off.
But it's equally right to do less work and spend the time on anything you like or things you have to do.
I do agree that freelancer status gives you more control, but it should not hurt anyone to ask what is your company's point of view. Assuming that employee is interested of downshifting, studying, working on a side-project (that is not competing with employers product) etc.