First, there have been hard feelings over breaking backward compatibility. To rub salt in the wound the new syntax doesn't seem to buy you much for many basic scenarios. If you are going to push big breaking changes you need to show big benefits that are easy to understand at a glance.
Secondly, the Ember community started small but has been kicking ass for a while now and making many improvements that are compelling to developers. It's a modern framework, but also easier to understand than some competitors like react.
I see the Typescript move as a positive because it shows they are at least trying to do what's right even when using tech from one of the biggest competitors. How this played internally at Google to overcome executive knee-jerk/bureaucracy/pettiness I don't know, but it's a good sign.
The community has clearly spoken, and the future of Angular is now riding on how well they absorb and react to the feedback and advances from competing teams.
another, more important piece (IMO) of response to the pushback they've been getting came during the new router demo at ng-conf today. Apparently, you'll be able to mix-and-match ng2 and ng1 routes within the same router, so the commitment was: if you use the new router, there's a clear incremental upgrade path as you port parts of your app to ng2.
I'm still in wait-and-see mode, but there's apparently also talk (from the same router talk) of tools to convert ui-router built routers to the new router, which would be double-rad.
https://www.youtube.com/watch?v=vecg70fPDFw (the router talk in question)
Being part of an existing project that's backed by both MS and Google is a significant value proposition though. I wouldn't have learned AtScript, although I'll probably end up learning Typescript now even though they're the exact same thing.
I could just bind the data to the view, and if the user changed it, I could react accordingly. Data changing became an actual event that I could subscribe to. It abstracted away the onkeydown, onkeyup, onclick, etc. so that it just became ng-change. So much less mental noise when I'm developing when all I have to do is react to data having changed.
I hope this gets picked up. ES6 and TypeScript have so much to offer, but without a data-centric paradigm, I find I'm just not interested anymore.
They talked about it in the ng-conf available on youtube. They are not removing 2-way databinding from Angular, they are just changing the way it works.
How in the world does this man keep up with all these projects? He needs to write a book on motivation.
By dumping them mid-way and getting to the next shiny one?
Anybody knows how this RoR kickstarter project finally went?
You can get releases at https://github.com/tokaido/tokaidoapp/releases. Andres (who now maintains the project) released Tokaido for Ruby 2.1 (with support for Mavericks) recently and we're working on Ruby 2.2 support as we speak.
The org is here: https://github.com/tokaido/ and there are a number of auxiliary projects (muxr and tokaido-dns are the big ones) that I developed separately along the way.
They must have convinced Microsoft to accept their patches into mainline TypeScript.
It means that the Angular team is giving up on traceur or maybe traceur and typescript will merge somehow in the future.
ES6, AtScript, and the es6-shim
AtScript compiles to ES6, which is not widely supported in all browsers today. The es6-shim.js file allows you to use ES6 or AtScript in the browser.
The quickstart repository includes es6-shim.js. The es6-shim.js file includes dependencies (such as Traceur) needed to compile ES6 in the browser. Traceur is an ES6 compiler that transpiles ES6 to ES5 code.
With static typing, the compiler can catch type errors early, at the cost of rejecting some otherwise valid programs.
With dynamic typing, that type checking is delayed until execution time. More programs are valid, but type errors are caught late.
With AtScript-style late type checking, they took the dynamic type system and introduced more type errors. This decreases the amount of valid programs, yet catches no errors at compile time. It does nothing but increase the amount of bugs.
It describes an extension to TypeScript that includes efficient runtime type checking. They encode type information only in situations where checks are necessary, and only information that cannot be otherwise deduced from the context.
Edit: to clarify, runtime type information should not be used to check for types again, but rather to do things similar to Java's reflection.
var length = rtts.type(name.length, rtts.int);
Perhaps I'm speaking from the perspective of our products at Yahoo, but ember has suited us well for precisely these tenets.
Recently, the results of the Ember Community Survey were released and the aspect of it I'm most proud of is the number of developers who are using the latest release version. The majority of respondents were on either 1.9 or 1.10, and 1.10 wasn't released until halfway through the survey.
I've moved to React as well and feel it's a 10x boost in productivity because I'm constantly thinking in my domain and not in a framework.
I think that's the nature of any framework.
To me React vs. Angular isn't a matter of preference like Ruby vs. Python -- it's more like git vs. FTP where there is a clear right answer if you're trying to be productive in a team envrionment.
Your entire complaint is that full-stack front-end frameworks are bad and modular systems are good. It's great that you prefer modularity and the ability to mix and match tools.
But stop pretending React vs Angular is a thing. It isn't. git vs FTP... just stop.
Also, FYI, the barrier in 1.x is not that high, either. There are many integrations between Angular and other frameworks (including React, FYI).
IME, it's a shit show, and totally inappropriate for production code. It's the mating of wrong sized dogs in the park.
I am going to start learning react as well, and if you have any suggestions on how to get started, I would be appreciative of a few resources.
I actually had to exact opposite feeling about Angular. I loved that it was a complete framework and I didn't have to mix and match several libraries to get the functionality I needed.
Having said that, I've completely soured on Angular. From the big changes coming in 2.0, to not making this backwards compatible hasn't left me with any confidence they won't do this again in future releases.
I've already moved to Ember and haven't had any issues yet.
Angular 2.0 is removing a lot of complexity and "magic" of 1.x. I've moved onto React but I think it's a bit too soon to say Angular 2.0 will be a bloated monstrosity relative to 1.x.
I notice that with people trying to learn TypeScript, and see that their struggle is with classes, lambdas and modules, not with the type system that is basically the only thing TS adds to ES6.
In the end, if you look at it there is not really much to understand and all the other things you will learn anyway with Ember, React, etc. I believe most of this fear will disappear once its released.
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.
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.
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.
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.
Try running jQuery's source through the TypeScript compiler some time.
Just curious, what and why are all your reasons to move away from Angular?
- 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™.
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.
I would strongly disagree. Watch this link to when Igor talks about Angular performance.
what are the performance issues with TS?
- 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.
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.
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).
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.
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.
Edit: Why did this question get down voted? It was an honest question...
Ok, for the down voters.
Angular is HUGE. And all that code has to get shoved onto the client side when someone visits a page. And that's JUST for the framework. We aren't even talking about the application code yet. More and more clients are mobile. Nobody sees a problem here? You're using more (precious) data, it's slower to load and slower to run. It's just a nasty little trend going on.
NOW LET'S SEE SOME FREAKING DOWN VOTING!!!
That feeling you get when you see code with lots of type checking... A lot of engineering effort could be recovered with static typing.
He said it looks like Java, I believe. Not "it's similar to Java".
Whole web is a mess and people are trying to monkey-patch it.
For example, I don't think it's particularly bad that array[-1] and array.charAt(-1) return different values.
Also, I don't get the Math.Max() example with booleans. Seems perfectly logical to me.
That has been true for the last 20+ years, but it gets less and less accurate as time goes on. The web today is way less messy than it was even 3 years ago. The way we write JS is way less messy, the way we write CSS is way less messy. Standards have improved, lighten up.
That said, static typing does help with intellisense/code completion, on-the-fly error checking, refactoring, etc...
Yes, they had to write interface for all browser APIs (and it's incomplete, PRs welcome), and in places where API might return null it states that it may return it. And your code has to deal with null and non-null cases explicitly (or at least put an if).
You are right though that this type-system is much weaker than other languages like Elm or Haskell, and for me, being from a Haskell world, writing JS with Flow was still a disappointment. It's just that currently there's no better alternative I know in terms of interop with JS and good level of error-reporting.
Sorry, I had the really stupid misconception that Maybe Types could not be applied to libraries and browser APIs.
So it seems like a good start, but it doesn't seem really useful if they aren't even in the basic API's descriptions: https://github.com/facebook/flow/blob/master/lib/dom.js#L198
Very much looking forward to seeing what insights come out of rebuilding something like angular with types.
edit actually on second reading, I'm not sure what's been rewritten in what?
Angular 1.4 is well underway and there's a lot of good stuff coming out of it, for example the reworked router module.
Here's a presentation from ng-conf today about the new router: https://www.youtube.com/watch?v=vecg70fPDFw
 Mentioned in the ng-conf keynote IIRC, but this was also told to me directly by one of the Angular core team members when I spoke with him today.
Statically typed, annotations, built-in dependency injection, comprehensive test support (easy to write testable code), declarative UIs, 100s of already available libraries & above all support from Google and Microsoft. I can say this with confidence that even with a complete rewrite & not backward compatible, AngularJS 2 with TS is going to be a huge success for everyone.
And sooner or later, all other frameworks will adopt ECMA Script 6 because of standardisation of so many things (modules, classes etc.)
Not really, no.
...then again, the 'dart community' has diminished to basically nothing, so I doubt many will care particularly.
The feverish Yehuda Katz is everywhere! But most importantly he is here on Hacker News and has close to 6000 https://news.ycombinator.com/user?id=wycats
There's too much talk about "typescript" and not enought about what problems Angular 2 solves compared to "not" having a ready made framework or how many problems it adds.
You can interact with JS libraries, but exposing some API to JS-land is a completely different matter.
There are some vague plans to improve this, but there hasn't been much interest, because if you use Dart anyways, you do of course want to use it as the "host" language. It has the tooling and all that jazz. Of course you'd want to use it for as much as you can.
The main problem I had with Dart was [a year ago] that using existing JS libraries like jQuery wasn't as seemless as I would liked. So that would be a reason against Dart, if Angular wants to make that aspect easier.
Haven't looked at TypeScript's interop with JS. I got frightened by the name Microsoft and the fact that they only had a huge language spec PDF and not a single tutorial or something easier to digest.
> Chrome (dunno if enabled by default and/or in stable) contains a Dart VM, so you "only" need to transpile into JS for non-Chrome.
You can optionally also provide a binding file that tells TypeScript about the JS code so that it can perform compile-time checking on calls. There is a repository of these bindings for common libraries called DefinitivelyTyped .
> ... They only had a huge language spec PDF and not a single tutorial or something easier to digest.
Not sure when you originally looked, but there is now a tutorial , handbook , and samples  in addition to the language spec .
> And the size of helloworld.dart.app.js is 102k
No, it's not.
dart2js --minify hello.dart -o hello.dart.js
This game is 35 KB (procedural graphics included):
264 Mar 5 12:21 a.dart
237K Mar 5 12:21 a.js
101K Mar 5 12:22 a.min.js
Anything I'm missing?
Also note that you could now add a thousand lines of code and the file size wouldn't increase much. You already paid that one-time cost.
You can further improve the size by using a better minifier on top of --minify.
Though as a counterpoint (and relevant to angular 2 :) I read they're going to just use the raw dom api's instead of a jquery/jquery-lite abstraction layer as the dom api's don't need the smoothing over in modern browsers like they used to.
The question is not here, the relevant question is
"Does JS compiles in Dart ?"
Because, JS Compiles fine in TypeScript, which means Typescript benefits from all JS ecosystem and vice versa.
(oh! You meant as, in, externally, not internally. I see...)
I remember being a MS hater as a kid. Now I hate all the big software companies. Just some more than others. And MS is heading in the right direction these days, so I'm optimistic. Hopefully it'll stick.
All JS lib compile out of the box in TypeScript.
Also, the EEE accusation doesn't really apply to open source projects. EEE is bad since after the proprietary product supersedes ("extinguishes") an open product, the community loses control forever. However when an open product supersedes another, the community always have the choice of forking the project to take back control.