Yeah this is great. Last time I tried, Vue itself wasn't too bad to get going with TS. The real issue for us was Vuex. The official examples and the Typescript examples we found looked completely different. It wasn't easy to get started.
We actually moved to React + Redux since it was early enough in the project to make that decision. Typescript support is much better there. If typescript support was better in Vue/Vuex, I doubt we'd have made that decision.
Last time I tried, there wasn't any support for type check across component boundaries (props, events). Did something change?
A deal-breaker for me. I mostly know types from within the component; if you keep them small enough it's not much of an issue to just look up/down to check for a name, for example. But cross-component communication is where I need TS the most. Hopefully 3.0 addresses that (didn't read the whole article thoroughly, maybe it's mentioned).
Oh wow. We didn't get far enough to notice that was a problem. We needed Vuex for something and that's where we got stuck and switched.
It's a good job - at that stage in the project, it wouldn't have been a big problem so we didn't notice. If we had continued, I would have a hard time justifying a switch at that stage and could have been in a bit of a corner right now.
Do you mean running Vue by just adding a script tag to the page? That will still work because it's just using a precompiled/transpiled JS file, which will continue to be available as part of the package. FYI, React can also run the same way.
What are you talking about? Typescript is what the Vue source code will be written in, which is compiled to javascript when distributed and includes Typescript definitions for editors that make use of it.
Your code can continue to be written in regular javascript with whatever toolchain you want.
And Typescript is a fantastic platform for bringing strong typing to Javascript, it's a rather extreme comment to say you don't recommend it to anyone.
Why would you use flow with typescript? Also valid javascript is valid typescript, you can even have typescript's tooling lint your javascript with a jsconfig file.
While there can technically be a perf improvement by making the types of functions less likely to change over time meaning to better jit code, the real reason is for safety (you'll get a warning if you pass an array of elements into a function that expects an array of functions that return elements) and IDE-style tooling assistance (like intellisense).
Types let you shift more of the testing load to the compiler instead of run time. Also, auto complete (not just string based) works much better because it's easier to reason via information that is exclusively in the realm of compile time (types).
I have seen very little value in dynamic languages in practice. Cool, you can pass any old thing into this function I wrote. Well, no, you can't really, because the function has assumptions about the structure of the things that it can operate on. So then I've got to start checking that the foo that you gave me has the kind of properties of a foo that I care about accessing, and you've got to know when you construct your foo that I care about those things. With a typed language, those assumptions are made explicit, whereas in dynamicland they remain implicit, and I've got to make runtime checks to verify that this foo can be bar()'d, and you have to determine, from docs, or reading the source, or trial and error, that I'm expecting it to be bar()-able, or things go sideways. Also, we have to agree on naming, down to pedantic stuff like case-sensitivity, so that if you give me a Bar()-able foo when I expect a bar()-able foo, we don't, in the best case, fail loudly, or worse, just do nothing. Not farming this kind of tedious drudgework off to a compiler or type-checker seems really stupid, especially nowadays when JS is already run through a compiler like babel as a preprocessing step anyway.
If anything, I think most typed languages don't go far enough in making assumptions about their data explicit, and there is far too much primitive obsession. In an ideal world, I would not have to ever refer to documentation to understand what subset of inputs from the type that is declared on a function parameter are actually valid - a function that only handles integers from 0 to 100 would raise a compiler error if I tried to pass it 200, and whole classes of runtime errors would become impossible, and vast swathes of trivial unit testing harnesses would be irrelevant.
This was the only thing stopping me from using it in larger projects. Can't wait to see how it plays. Hopefully the class-based interface has no weird object notation (methods, props, computed) and uses decorators like Angular.
We actually moved to React + Redux since it was early enough in the project to make that decision. Typescript support is much better there. If typescript support was better in Vue/Vuex, I doubt we'd have made that decision.