> Vue itself wasn't too bad to get going with TS

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).

As there is no mention of it, it should be available. After all, as you said, Modern mode is a killer feature.

Nope, and it won't run with ECMAScript-compatible editors, linters, static analyzers, or type checkers (see: Flow).

I can't imagine recommending TypeScript to anyone I like.

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.

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).

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).

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.

With the current TS helpers you have:

    @Prop myProp!: string;
    get myComputedGetter(): string {…
    set myComputedSetter(val: string) {…
    myMethod(in: number): string {…
    @Watch('property') methodToCallOnChange() {…

And a bunch of decorators to connect vuex actions etc.

I assume the Vue3 version will be similar