With such lagging browser support forcing you to compile ES6, it generally makes more sense to jump to TypeScript. You get all the E56 plus things like interfaces and enums and, of course, strict typing.
I already use all ES6/7 features (plus modules support with <script type="module">) for many of my personal projects and experiments: no transpilers, no build tools. I like knowing that in 15 years I'll be able to double click an index.html and run/edit my old experiments without worrying about how I'd to find the right version of some long-dead build tool - just like I do with my javascript experiments from 2002!
And then you have all of the fun stuff like their original non-standard module system, which is now super confusing in type definitions since it lives side by side with the "real" thing. I'm sure we're gonna have lots of fun having 2 ways of defining private members too. Woo. I assume decorators are gonna be entertaining too since they were based on the older version of the spec (I assume. I did not verify this claim).
I love using TS in my side projects because I avoid "the bad parts" (same as with vanilla JS when you think about it), but when we introduce it at work, Im half considering making a lint rule that blocks all the non-standard features that are not related to type checking. Will save some pain in the future.
I would bet money that you actually write less code with Typescript than regular javascript because of all the streamlining and shortcuts. And with the type inference you almost get static typing for free.
I hear this argument come up frequently against TS and all I can say is I'm fairly sure it's from people that haven't used it.
Typescript feels like a step in a completely different direction. The problems that TS tries to solve have other solutions. Solutions more idiomatic to javascript development. Redux style architectures, grouping code by feature, libraries over frameworks, GraphQL and so on. And these solutions are solid and dependable. Unlike the made up brittle and often incorrectly defined types that Typescript and Flow demand. If you want to use Typescript, then I hope you really really REALLY like Generics, because they're absolutely everywhere in Typescript. They're the solution to the fundamental flaw with TypeScirpt, it wasn't designed with the actual job that Javascript does in mind.
It's Javascript for people who don't like Javascript and don't care to learn it. Well that's fine, each to their own. But people sing it's virtues without pointing out any of the flaws in both the approach or the implementation (maybe because they simply don't see anything wrong), and that really rustles my jimmies.
Not a bad one, but very intentionally different.
I personally prefer a style/practice that doesn’t work well with TS, but I appreciate it exists and typedef files for libraries are very nice for developing in things like VSCode.
IMO the opposite is true; without types you give up some developer productivity in the form of time spent writing tests and debugging issues that the type system would obviate automatically. In my view, loose typing adds the illusion of productivity because the developer might presume they are working faster because they don't have to reason about type restrictions, however they simply end up enforcing type restrictions manually (and relatively poorly compared to a solid type system) using "typeof" and "instanceof" checks throughout their code. In general, assigning multiple types to the same variable is considered a code smell anyway, so strict typing simply enforces what is already considered a best practice.
Of course, this doesn't mean that choosing typescript in particular is always the right engineering decision, but, all other things being equal, a strict type system is almost always preferable to a loose one.
I mostly agree, I just wanted to point out that it's funny (to me, anyway) that the same argument applies in both cases. If you don't have type scripting, you also give up a certain level of developer productivity.
When you have to hunt down type bugs a linter or compiler would have caught, you can waste large amounts of time. I think type bugs are usually fast to find & fix, and only occasionally take time.
I like using a type checker of some sort (Closure compiler is probably my fave) for release builds, and leave it off for dev builds. I like this option even more than TypeScript, because you don't necessarily need to have a build step for running dev code at all. Then you get the best of both worlds, you can iterate quickly without adding or checking types, then you can spend a little time checking types before merging a branch. Any time a mysterious bug pops up, first order of business is check types.
Even for React, I'd still rather have the option to type check than not have it. Flow is nice because once setup & running, it's really fast. I've seen it catch long standing type bugs that nobody thought were there.
What lagging browser support? Most of those things have been there for years...
Android support was incredibly bad until recently for example, so anyone with a large mobile audience will have issues as well (I still see 100,000s of Android 4.4 requests for example)
Not everyone can just support Edge/FF/Chrome evergreen versions.