AngularJS has a J2EE mindset. Where libraries grow to become as hard to learn as programming languages themselves. It does not make semantic sense to me anymore.<p>Here is an example from the site:<p><pre><code> <div>
Length (float):
<input type="text" ng-model="length" name="length" smart-float />
{{length}}<br />
<span ng-show="form.length.$error.float">
This is not a valid float number!</span>
</div>
</code></pre>
How semantic is ng-show="form.length.$error.float? smart-float sounds like C++. If programming languages worked like this, we wouldn't have built many apps. The problem is that some frameworks assume that everything should be done with using configuration. What ends up happening is that the configuration (and conventions) becomes its own language. This is a waste of time in the long term; library conventions are not a portable skill set.<p>Some things are just better off with plain JS and simple HTML. FB/Instagram's React is a much better approach to building HTML UIs; you get readable JS and HTML instead of configuration mess.
I have multiple friends who are very excited about Angular and one who is very excited about Knockout, so I am convinced that they are getting something right.<p>I am personally much more attracted to the reactive style of Meteor's Blaze or ReactJS. It seems much easier for me to reason about, but maybe this has something to do with my background in video games which means that a render-loop seems really natural to me.<p>I don't have enough real world experience with the former to make a comparison so I'd love to hear from someone who is able to properly compare the two styles what the real pros and cons are.
"All code in Angular 2 is already being written in ES6. As ES6 doesn’t run in browsers today, we’re using the Traceur compiler to generate the nice ES5 that runs everywhere. We’re working with the Traceur team to build support for a few extensions like annotations and assertions."<p>That's pretty cool.
Unless they plan to release this 4-5 years from now isn't it a bit optimistic to release something intended to be used in production for IE11 only? For most real-world applications it's kind of nice to be able to support anything with a browser share over 1-2%, with this requirement it places Angular squarely in the 'startups for the tech crowd'-only world.
> Dependency Injection is still a key differentiator between Angular and other client side frameworks<p>Why not just take Require.JS and use it as a dependency injector, like any other client-side frameworks allow you to do?<p>IMO Angular is trying too hard to be everything, while it is now de facto a template system with an excellent support of custom directives and two-way data-binding.<p>For example, Angular could be a good choice for a View layer of an app built on top of Backbone, since it moves away from opinionating the View layer. But it's just too much fuss happening around this templating system in Angular.
Back last year, (May 2013) Miško said:<p>"We're in early stages of designing Angular 2.0, but some of our goals are:<p>- Angular will use the underlying web platform features available to it (e.g. Node.bind, template integration, Custom Elements, etc...)<p>- Web Components (Polymer, Ember, or any other framework/library) will work seamlessly within Angular apps and directives.<p>- Components written in Angular will export to Web Components (to be used by Polymer, Ember, or any other framework/library) .<p>We're working actively with the MDV, Web Components, and Polymer teams to make sure that our approaches remain compatible as all these projects evolve (and they will still evolve).<p>-- Misko & the Angular team" (<a href="https://groups.google.com/forum/#!msg/polymer-dev/4RSYaKmbtEk/uYnY3900wpIJ" rel="nofollow">https://groups.google.com/forum/#!msg/polymer-dev/4RSYaKmbtE...</a>)<p>Does anyone know if the focus on Web Components is still there?
The new DI looks confusing. The old way is super simple to understand. You inject the location provider and call it. In the new way however I don't understand what's going on at all.<p>Where can I find a simple example?
I was at ng-conf back in January and there were some great presentations on a lot of these topics, such as the new DI model. I'll have to pull out my notes.<p>It's great to see a framework team take a fundamentally new approach. Many frameworks get stuck in a mindset while other frameworks pop around them with new and more innovative approaches.<p>Good luck to the Angular team.
ES6 support with ES5 fallback, I am stoked.<p>As to the mobile-first changes, we'll see - I have some reservations on using Angular on lower specced mobiles, for the $watch()-cycle seems to me huge drain on batteries. But since the Angular guys know what they are doing, I am looking forward to nothing but goodness.<p>Why not just include restangular as one of the resource modules if they decide to go all-out modular?<p>I am hoping for multiple ngIncludes and a bit easier development of directives, other than that, keep up the good work, guys :)
Should this be marked as Angular 2.0 BETA? The docs say that it is not done yet.<p>Also, the docs say that they do not know when they will be done. While I can understand that we may not know problem that arise, it is a pet peeve of mine that I never have a an idea when Drupal 8 will be released. I know that open source contributions are hard to track, we have to estimate (guess) when our projects will be done in our work, so why can we not do it for the projects we love?
+1 to "Integration with authentication and authorization". This is needed on 95% of apps or more, nice to know it hopefully will be supported.<p>oh, and don't forget better documentation :)
Unfortunately, Angular 2.0 sounds like a project killer. Let's abandon the huge effort put in by the community, and build this shiny new framework with all the latest and greatest (and currently unsupported) tools. Let's support everything we can possibly foresee, and make the ultimate framework that will never need improvement. That is until Angular 3.0, when we'll need to support ES8...<p>Rewriting a successful framework with no backward support is suicide. Please read this link before continuing on this path: <a href="http://www.joelonsoftware.com/articles/fog0000000069.html" rel="nofollow">http://www.joelonsoftware.com/articles/fog0000000069.html</a>. Another informative example is Perl 6. The 'rewrite' killed Perl. Microsoft also did this time after time, forcing developers to constantly rewrite their applications instead of spending time writing new products. Even Python 3, with it's limited incompatibilities, had a very negative effect on the community: <a href="https://programmers.stackexchange.com/questions/63859/why-do-people-hesitate-to-use-python-3" rel="nofollow">https://programmers.stackexchange.com/questions/63859/why-do...</a>.<p>Why should I bother supporting Angular 2.0, since 2 years from now the developers are going to get bored and want Angular 3.0? The community is NOT going to take the time to rewrite all their code to scratch your itch. My time is very limited, and I need to be selective where I use it. I love Angular, but there is zero chance I will rewrite any of my code for Angular 2.0. It's not going to happen. I'm quite certain that my sentiments are shared by other developers who have put in far more time and effort than I have.<p>My strong advice is to fix and optimize what you have. If there are areas that need rewriting or rearchitecting, then do it, but leave a clear upgrade path and don't break existing apps where possible. Sorry, but that's how software works.<p>You have a ground breaking, beautifully designed framework. Please don't destroy it because it's not perfect. Nothing is.<p>Can someone at Google please talk some sense into the developers running this project?
I realize this is a basic question, but how does synchronization between the client and server work with Angular? I understand the concept of data-binding once you've retrieved the data to a data-structure on the client-side, thus causing that data to update the view in the DOM, but what triggers a client-side update when your server-side data changes? Do you need to poll a REST service to check for changes? Does the server push the change to the client side? Say there's no client-action triggering an update? What causes the new server-data to get pushed to the client?
The actual important stuff:<p>"Simplify the directive API<p>Integrate with other component frameworks using web standards<p>Improve performance<p>Allow tools like IDEs to analyze and validate templates"
OT if you're going to insist on double spacing HTML, use "&nbps; " and not " &nbsp;" otherwise you'll have a ragged left margin like the OP.
An yet another simple text blog that is 100%, completely, utterly broken an useless without JavaScript enable. There isn't even any compelling feature. Besides the sliding out mention there is _no_ reason JavaScript even needs to be on this page.<p>I don't get why BlogSpot an so many other sites require javascript to o absolutely nothing of value just to see the site. It's maddening and appalling.
The new DI system looks promising, looks like they are trying to make a JS version of Guice which I love in java. The whole thing of using annotations in javascript seems a bit out of place though especially when ide/text don't support them. Also the logging framework, seems they are making sure that they cover some "enterprise" concerns.