As if we didn't have enough reason to move on from Angular. Now you need to learn Typescript to contribute or grok the source files?
Everyone seems to hate on JavaScript but it's really not that bad to use.
Not all transpilers may be to your taste, but they have their place.
I disagree and my original statement applies as much to TypeScript as it does to an ECMAScript 6 transpiler. If you want to use the new features and you're transpiling now you need to have a good understanding of the differences between ECMAScript 5 and 6 and you open yourself up to possible bugs in the transpiler.
Instead you could just write ECMAScript 5 until 6 is more widely available. Sure no one likes to wait but it requires the least amount of expertise and lower chance of bugs from a 3rd party interfering with your application.
Besides all that everything ever created has bugs; why risk introducing bugs from a JavaScript engine and from a transpiler when you can risk a single one?
As an aside my first and last time using CoffeeScript I ran into an issue that, since this was about two years ago, has already been fixed but at the time it cost me hours of debugging time. It really soured my experience with any transpiler.
If I used Babel or any other transpiler for critical production code, I would only enable a whitelist of features that I thoroughly understand: for example, how a fat arrow is translated into a regular function. This vetting would be time-consuming, but that's a price I'd be willing to pay because I enjoy writing ES6 much more than ES5. That's highly subjective though, so I completely understand how some other people would rather just stick to ES5 and get stuff done with the lowest possible risk of weird things happening.
I have an affinity for Babel unlike any other JS project (except React). They team works really hard to keep it interesting.
For production code I'd still stick to a whitelist of features that have been released for at least a month though. Babel is aggressively pursuing ES6 coverage and new features might not have all edge cases covered when they're released. Give them one month though and with their responsiveness it's 90% likely it's going to be fixed.
I would argue that knowing some of the implementations of features such as module/export/class/extends of TypeScript in native javascript requires a lot more expertise to create coherent OOP code than just opening up TypeScript and using a syntax for OOP that most people are already familiar with.
It would seem that if you want angular to evolve in possibly non-backward-compatible ways, then conversion tools would be a requirement. And this is going to be a simpler task with a typed language.
For a certain style of Javascript, making it Typescript is a no-op
http://crystae.net/2015/01/22/typescript-is-not-a-superset-o...
Try running jQuery's source through the TypeScript compiler some time.
It seems to me that JavaScript haters would be better off moving to a completely different language, like ClojureScript. TypeScript rather feels like it's made for people who enjoy JavaScript but wish it provided the peace of mind of static typing.
I tried TypeScript for the first time a few months ago and it was a breeze. I felt "fluent" almost instantly and only had to look up the docs a few times. With ES6+ picking up steam, TypeScript-specific features are being replaced by their ES6+ equivalent, so TypeScript is going to feel even more natural going forward.
Just curious, what and why are all your reasons to move away from Angular?
- Obtuse, verbose, non-performant code
- Did I mention breaking changes?
IMHO, Angular isn't progress, and neither is painting yourself into a corner.
Opinions maybe useless, but some opinions are more useless than others.
[1]: http://flowtype.org/
FWIW, the Angular team mentioned they talked with the Flow team - not sure what that will mean in the near term, but I get the impression that efforts might be in progress to unify the different libraries' efforts.
I mean something like this: https://atom.io/packages/ide-flow
Tool-tips, call-tips, auto-complete, type checking, and so forth. The kind of stuff you get with TypeScript or Dart.
- Lengthy learning curve.
- Not concerned with performance at all (can be a nightmare on mobile devices with low RAM).
- Google's history of throwing away and/or deprecating projects, (see Angular v1).
- I still have yet to see a Google website using Angular in any large capacity.
- Ecosystem lock-in. It tries to do a LOT of stuff, and you generally need to be doing all these things the Angular Way™.
what are the performance issues with TS?
I would strongly disagree. Watch this link to when Igor talks about Angular performance.
Angular is not intended for typical "websites". It's for replacing what would previously have been desktop CRUD applications. Google use it extensively for internal tooling.
It's also worth remembering that most public facing Google applications have been around for years, decades even. It would take a long time to replace one of these with Angular, even if there was a desire to do so.
It's that they're collaborating.
I'm pretty sure that's a sign of the Apocalypse. We may want to stop worrying about transpiling and pay closer attention to the skies, looking for raining frogs and or blood moons.
Then it's not "just ECMAScript 6", is it? Anyway, I'm not saying TypeScript doesn't have merit--in fact, I'm considering using it in my next web app. I'm just saying that using TypeScript is a tradeoff that's not without drawbacks, since you're now dependent on a new set of tools and new additions to the syntax (which means, for instance, that your editor/IDE has to specifically support TypeScript). You could say the same about ES6, but at least the latter is at some point going to be standard among browsers (and the tools won't be needed).
It's not "Javascript with a bunch of proprietary extensions", either. Type annotations can't be the difference between understanding code in Typescript if you understand Javascript.
You have a point about tooling, but you would have the same problem if you had a project on visual c++ 6 and upgraded to c++/14, and again, you didn't mention it.
All of this is in spite of the fact that ES6 nearly had optional type annotation in the same syntax that Typescript does, along with many other Javascript derivations that use the same type annotation syntax (Actionscript and Atscript that I know of).
The counter to that is that TypeScript is Apache-licensed. However, you can't erase history by throwing up a Github repo.
Moreover, I'm hearing more people say they don't trust relying on a big corp for their client-framework. I think many don't disagree with that idea, but more or less trust Google, so they embrace Angular with prejudice. Anything with Microsoft's signature feels less open, and may push some past that tipping point.
The same way that Google's shuttering of services over and over earns them a bit of discomfort amongst their users.
Technical forums ain't what they used to be. The problem for me is that this kind of Tarot card thinking is also now to be found in your local workplace. But there really isn't time for this if you are trying to build things. Do you want type checking in a language that's very close to js or not? If so then just get on with it.
Seriously, stop the FUD
Not only are these strategic moves, they are strategic moves by a large company aimed at competing with people like me who develop software on multiple platforms and contribute, unpaid, to an open software ecosystem.
Why? Sure, people here complain about Microsoft, but people here also complain about (1) novel things in domains where they think the existing thing is good enough (which, for many, JS probably is), and (2) things, new or old, that they see as fundamentally flawed (which, for many here, JS or any "next version" that isn't radically different, is.)
So, I suspect people here would be complaining about having to learn a language that resembles the next version of JS whether or not Microsoft is involved. Maybe not exactly the same set of people that are complaining with Microsoft involved, but people here nonetheless.