How many Angular folks are sticking with native ES6 and babel vs TypeScript? Angular is clearly directing folks to TypeScript. I don't want to have to use TypeScript on front-end and ES6 + Babel in Node. Trying to pick one.
TypeScript basically made JavaScript more powerful and a whole lot more fun for me. I feel so much better about slinging around parameters now that I know my IDE will catch type/parameter mismatches before I run the code, before I build it, even before I save the file! It simply alerts me in the IDE (I use VSCode which I also love). This is a huge time saver.
Another great thing is the intellisense, which allows me to keep on coding without looking at some API documentation or other files in the project. The intellisense even has the documentation in it - so this is a really fun and efficient way to learn new libraries and frameworks.
I didn't even know how much I missed enums in JavaScript until I started using them in TS. Also love the fact that you can revert to using the Any type if you have to and there is even support for generics as well.
All of this stuff can be had in various transpilers or IDEs, but TypeScript and VSCode just bring everything together in a very simple yet powerful way.
Despite all its glaring flaws, javascript is an insanely productive language due to excellent mix of features. To improve upon that Id need to go to lisp / clojure [ but it lacks wide commercial acceptance .. not a criticism at all ]
I'm actually wary of using the newer additions to javascript language - ES6, Promises and arrow notation don't seem that much of a win to me, I'm very sceptical of new being good in language design...
whereas I really love Ramda.js as a general underscore / lodash replacement.
Productivity seems more a function of how we structure our code [ eg. keep state so we can jump back into where we were in the web app, thus iterate easily - as per the Om approach ] and thinking functionally.. rather than language syntax additions.
I don't see the need for an IDE .. they tend to come into their own when Your.ColourfulAndCompleteMethodNames are so long they need auto-completion. Thats the beauty of javascript [ and lisp etc ] we should fight to keep things small and terse.
I also like cljs, mostly in a text editor.
Code quality it is the ultimate time saver. I prefer reading concise, literate source to exploring/churning APIs.
As a big fan of types myself, I hear you. Have you tried using flow with react? I wonder how they compare.
What I liked about React is that I also got type checks in JSX (compiler tells me if the types that I assign to props are correct). I don't get that kind of type checks for angular2 templates. If I assign something wrong there then it blows up at runtime.
What I disliked about React is that the ecosystem doesn't embrace typescript. For most 3rd party components that I tried there were either no type definitions available or they were broken (which is often worse - because then you can't assign props that are actually valid).
For Angular2 at least the framework is already typescript-first (so we have automatically up-to-date type definitions through the compiler), and I would hope many 3rd libraries follow that design.
On the Flow vs Typescript thing, I evaluated both for this project, and almost went with Flow primarily because at the time, I liked that Flow felt lighter weight (it is truly "opt in" unlike TS, and getting the TS setup right was quite hard work), and I was also put off by the overhead of having to write .d.ts files (now I can create an "any" definition for a library in a few seconds, but at the time found it all quite time consuming).
However, I persevered with Typescript in the end, as I felt that some of the features it offered over Flow were worth the extra effort - specifically, the editor/IDE support (Atom with Nuclide for Flow was really unstable for me and the autocomplete still didn't compare to TS) and the fact that Typescript does a full compile of your code, so will pick up on things like mis-spelled imports, which Flow didn't seem to.
Also, I found documentation for Flow (beyond the basics) to be quite lacking, and there didn't seem to be as much community around it - for example, I just couldn't work out how to get it to check React propTypes, which was a pretty important feature for me. Bit of a shame, as its type system actually seems more fully featured than Typescript's (e.g. types are non-nullable by default), but TS's type system is certainly good enough.
I'd say go Typescript at the minute if it's a reasonably large greenfield project, but Flow might suit your needs if it's something smaller (whether that's in amount of code or in team size), or if you prefer the lighter touch/opt-in approach - for example, if you want to introduce it to an existing JS code base. I would definitely say it is worth the effort to go with one or the other, I'm not looking forward to going back to writing plain JS - having the compile stage makes refactoring in particular trivial, without the overhead of having to write loads of unit tests. In TS I'll refactor constantly as I go whereas in a large JS app, it's tempting to put off refactoring as you might miss somewhere and not know until it is QA tested (or the customer spots it is broken...).
I used to love CoffeeScript but, after giving ES6 (with eslint) a shot, it no longer has a special place in my heart.
I do enjoy the terseness of it (writing it is fun) but some things are just painful (reading it after the fact).
As for TS vs ES6+ -- I would go with TS but only because Angular projects have a tendency to become very large, and having a compile-time type system hold your team's hand is very comforting.
TypeScript is doing really good.
I kind of have a feeling that by the time we actually need (and have the resources) to upgrade or even start mixing in Angular 2 on our project, native browser support for ES6 will be close enough to complete that we won't need a transpilation step. That might be a nice time to do the migration.
Looking forward to hearing what other devs end up using.
Want to give this a try :-)
Thanks
The problem I have with decorators is that they are not officially part of ES7 spec yet, even if there is a big chance they end up in the final spec, features like ES6 modules are a proof that things can be reworked to death before being standardized.