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.
Here is an example from the site:
<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>
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.
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.
This is a critique of the example, more than the framework itself. The "smart-float" directive is not a native angular directive, but rather a directive made for the example.
As for the "form.length.$error.float", it probably could be a bit more concise, but is it really that bad? What would be a "more semantic" way?
The main strength of angular, is that you are able to point your DOM elements to environment variables in your JavaScript code -- eliminating the need for traversing the DOM to find a mount node. If you are opposed to this functionality and insisting on traversing the DOM from the JS side, I'd love to hear why.
You can find small things you dislike in any framework, but rarely are they valid criticisms of the general concept. Often, these details are there for a reason, and just as often, they are flaws waiting to be fixed by an open source developer.
React solves all the problems in the world with their nestable but still autonomous components approach. It dispenses controllers -- and automatically give control to the component which deserves it --, it dispenses templates, and automatically gives the power to make the entire app in modular small pieces of HTML, it dispenses models, because models are already embedded in the components in which data is rendered.
This is extremely picky. "Smart-float" is the name of a custom directive that is used as an example. The term "smart float" can be used as a React component name just as easily. In that case, your React component would "sound like C++".
Also, the "we wouldn't have built many apps" part is a stretch. It's actually the opposite, AngularJS is extremely popular and the most successful current JS framework.
I don't see the problem. `<span ng-show="form.length.$error.float">` makes total sense to me. You show the content of that span when form.length.$error.float is truthy. Probably when it exists.
And yes, AngularJS absolutely defines its own language. The directives create an enhanced HTML (that you can enhance even further), and it has its own expression language where you can ask the value of `form.length.$error.float` without fearing null pointers.
This is basically what Angular is about, and why it works as nicely and cleanly as it does. And it's true; learning a new framework is absolutely comparable to learning a new language. Rails is not simply standard Ruby; it defines loads of new stuff that automatically handles things for you below the surface. Spring completely changes the way you work with Java. Grails has its own DSLs for various tasks.
Every framework has a learning curve. And a framework that doesn't change how you think is as useless to learn as a language that doesn't change how you think. But if you don't like learning, you can always simply stick to what you're familiar with.
> How semantic is ng-show="form.length.$error.float?
I agree with your conclusion, but I think you're misusing semantics. This isn't semantic, but neither would anything else be. As soon as we get to using logic, we don't have semantics.
That line is unclear and not easy to understand. That is why I object to it.
I only looked superficially at React, so maybe I got something wrong, but the HTML/XML intermingled with Javascript seems extremely off-putting to me, akin to ASP/JSP/PHP.
>How semantic is ng-show="form.length.$error.float?
I could not care less. I find that talk about web programming has been polluted by non-terms like "semantic" that doesn't mean anything specific (in the context).
Especially the whole hoopla with regard to "semantic HTML", with designers (who don't know much if anything about programming, and just heard this "semantic" term from a few industry fad gurus) using it to insist developers should treat HTML as a format for reuse (as if the reason we write HTML is to enable better screen scrapping).
Endless discussions about whether it's ok to a DIV if it's purely for display purposes of not, as if HTML/CSS dont already make a clusterfuck of separating markup from presentation.
Fuck "semantic HTML" -- it's a presentation format, that also happens to have a not-that-functional styling component. If you wan't reuse and semantics, get those from the data level (the db, the REST endpoint, etc), not from code meant for browsers.
That's not necessarily semantic, but that's declarative and it's what I like with Angular. No need to think cinematic such as "when this change, update that", but just declare links.
Angular is starting to remind me more and more of JSF + CDI which immediately triggers a negative visceral reaction for me. But, if I step back and think for a moment, most of what I despised about working with JSF was related to the amount of state it needs to maintain between the browser and server. If that state is completely contained on the client and the client maintains a stateless connection to the server, it may actually work out well.
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.
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.
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.
I've worked on one large project with Angular, and a couple of medium sized ones in Meteor (using the original UI system) and am working on a POC project with ReactJS at the moment.
I think Angular is better for "slightly more traditional" webapps such as dashboards. Its directives are nice for building small custom widgets, and the thin model wrappers $http and $resource can be useful (though I'm looking forward to what they add to these in v2.0). Data-binding is very straightforward and easy to understand.
I've built a couple of projects in Meteor, and I'm still a fan, though I've yet to have a real use case for the realtime (pub/sub) stuff: I'm still making straightforward webapps that would probably be just as easy (if not easier) to build in Angular or Backbone. The reason I'm using Meteor is more for productivity than for reactive realtime: I love that I get Mongo, a watched asset pipeline and a bunch of other stuff for free. I love being able to share/move code around easily between the client and server.
Sometimes the reactivity in Meteor can be quite subtle and difficult to get your head around, and I wish I was just using straightforward webservices instead; other times it's a productivity booster and keeps things simpler.
ReactJS is a really nice concise view library, with some extra stuff that Facebook put in that I'm not sure should really be in there (e.g. the synthetic events) and should maybe be a module instead (an approach I'm very happy to see Angular taking). ReactJS does for views and templates what Meteor does for client-server. It's also got its share of subtleties and gotchas though.
I'm also from a video games background and am also tending to favour Meteor and ReactJS. But I do think the extra power of these technologies brings an extra set of complexity and things to watch out for. But then Angular has transclusions, so......
"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."
While "cool" and "clever" and any other half-positive adjective you like, it does mean things will literally be hell to debug until native ES6 support is available in current browsers.
I thought the internals of Angular already had a reputation for being pretty horrible and indecipherable already. I doubt this will improve on any of that criticism.
On the one side, yes; on the other though, it's a shame that the technologies we use or want to use for web applications right now (HTML5, ES6, etc) are just not done, standardized or implemented yet.
JS not good enough? We'll invent new languages; Dart, Typescript, Coffeescript, etc. ES6 not yet done? We'll build a transpiler so we can fiddle with it until it's done - if ever.
I just wish the standardisation processes for web technologies would go faster. We get small revolutions every 2 years or so, but the standards behind them only get updated every decade.
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.
The intention is to use it with Traceur, which is an ES6->JS transpiler that works right now. It's like writing a framework in CoffeeScript or dart2js - users shouldn't care about the implementation language, the ultimate binary is just a blob of JS that works on browsers - except that the source code will eventually run natively in the browser.
> Dependency Injection is still a key differentiator between Angular and other client side frameworks
Why not just take Require.JS and use it as a dependency injector, like any other client-side frameworks allow you to do?
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.
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.
Require.JS is a service locator. It's not an inversion of control dependency injector. You can swap in a different service locator for your tests, but it's messier than just directly passing in different dependencies for your tests.
"We're in early stages of designing Angular 2.0, but some of our goals are:
- Angular will use the underlying web platform features available to it (e.g. Node.bind, template integration, Custom Elements, etc...)
- Web Components (Polymer, Ember, or any other framework/library) will work seamlessly within Angular apps and directives.
- Components written in Angular will export to Web Components (to be used by Polymer, Ember, or any other framework/library) .
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).
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.
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.
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.
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.
Why not just include restangular as one of the resource modules if they decide to go all-out modular?
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.
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?
It's not necessarily a beta since you can't start using the half-baked product right away. It's more of a foreseen product announcement. Awkward for sure though.
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...
Rewriting a successful framework with no backward support is suicide. Please read this link before continuing on this path: http://www.joelonsoftware.com/articles/fog0000000069.html. 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: https://programmers.stackexchange.com/questions/63859/why-do....
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.
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.
You have a ground breaking, beautifully designed framework. Please don't destroy it because it's not perfect. Nothing is.
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?
AngularJS is not a server-side framework and therefore it is agnostic on that question. You can do it however you like and you can even create directives that keep the client model synchronized with server-side, but it doesn't come out of the box.
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.
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.
[+] [-] jeswin|12 years ago|reply
Here is an example from the site:
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.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.
[+] [-] kayloos|12 years ago|reply
As for the "form.length.$error.float", it probably could be a bit more concise, but is it really that bad? What would be a "more semantic" way?
The main strength of angular, is that you are able to point your DOM elements to environment variables in your JavaScript code -- eliminating the need for traversing the DOM to find a mount node. If you are opposed to this functionality and insisting on traversing the DOM from the JS side, I'd love to hear why.
You can find small things you dislike in any framework, but rarely are they valid criticisms of the general concept. Often, these details are there for a reason, and just as often, they are flaws waiting to be fixed by an open source developer.
[+] [-] versusdotcom|12 years ago|reply
Here a quick comparison of both: http://versus.com/en/angularjs-vs-react
Here a pretty good video of React's founder pointing on some weakness of Angular: http://www.youtube.com/watch?v=x7cQ3mrcKaY
[+] [-] stuaxo|12 years ago|reply
The cycle probably goes thusly:
Large monolithic framework comes and shows everyone a new way of doing things (Angular/Django).
People think it is too large and monolithic, so make microframeworks (Flask/Whatever comes after Angular).
The next step will be a kind of happy medium.
[+] [-] fiatjaf|12 years ago|reply
React is the Holy Grail of JS frameworks.
[+] [-] watty|12 years ago|reply
Also, the "we wouldn't have built many apps" part is a stretch. It's actually the opposite, AngularJS is extremely popular and the most successful current JS framework.
[+] [-] mcv|12 years ago|reply
And yes, AngularJS absolutely defines its own language. The directives create an enhanced HTML (that you can enhance even further), and it has its own expression language where you can ask the value of `form.length.$error.float` without fearing null pointers.
This is basically what Angular is about, and why it works as nicely and cleanly as it does. And it's true; learning a new framework is absolutely comparable to learning a new language. Rails is not simply standard Ruby; it defines loads of new stuff that automatically handles things for you below the surface. Spring completely changes the way you work with Java. Grails has its own DSLs for various tasks.
Every framework has a learning curve. And a framework that doesn't change how you think is as useless to learn as a language that doesn't change how you think. But if you don't like learning, you can always simply stick to what you're familiar with.
[+] [-] porker|12 years ago|reply
I agree with your conclusion, but I think you're misusing semantics. This isn't semantic, but neither would anything else be. As soon as we get to using logic, we don't have semantics.
That line is unclear and not easy to understand. That is why I object to it.
[+] [-] iSnow|12 years ago|reply
[+] [-] dmak|12 years ago|reply
[+] [-] coldtea|12 years ago|reply
I could not care less. I find that talk about web programming has been polluted by non-terms like "semantic" that doesn't mean anything specific (in the context).
Especially the whole hoopla with regard to "semantic HTML", with designers (who don't know much if anything about programming, and just heard this "semantic" term from a few industry fad gurus) using it to insist developers should treat HTML as a format for reuse (as if the reason we write HTML is to enable better screen scrapping).
Endless discussions about whether it's ok to a DIV if it's purely for display purposes of not, as if HTML/CSS dont already make a clusterfuck of separating markup from presentation.
Fuck "semantic HTML" -- it's a presentation format, that also happens to have a not-that-functional styling component. If you wan't reuse and semantics, get those from the data level (the db, the REST endpoint, etc), not from code meant for browsers.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] eloisant|12 years ago|reply
[+] [-] mbell|12 years ago|reply
[+] [-] ErikAugust|12 years ago|reply
Why this is the top comment is beyond me. This is whining.
[+] [-] smrtinsert|12 years ago|reply
[+] [-] kristiandupont|12 years ago|reply
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.
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.
[+] [-] davedx|12 years ago|reply
I think Angular is better for "slightly more traditional" webapps such as dashboards. Its directives are nice for building small custom widgets, and the thin model wrappers $http and $resource can be useful (though I'm looking forward to what they add to these in v2.0). Data-binding is very straightforward and easy to understand.
I've built a couple of projects in Meteor, and I'm still a fan, though I've yet to have a real use case for the realtime (pub/sub) stuff: I'm still making straightforward webapps that would probably be just as easy (if not easier) to build in Angular or Backbone. The reason I'm using Meteor is more for productivity than for reactive realtime: I love that I get Mongo, a watched asset pipeline and a bunch of other stuff for free. I love being able to share/move code around easily between the client and server.
Sometimes the reactivity in Meteor can be quite subtle and difficult to get your head around, and I wish I was just using straightforward webservices instead; other times it's a productivity booster and keeps things simpler.
ReactJS is a really nice concise view library, with some extra stuff that Facebook put in that I'm not sure should really be in there (e.g. the synthetic events) and should maybe be a module instead (an approach I'm very happy to see Angular taking). ReactJS does for views and templates what Meteor does for client-server. It's also got its share of subtleties and gotchas though.
I'm also from a video games background and am also tending to favour Meteor and ReactJS. But I do think the extra power of these technologies brings an extra set of complexity and things to watch out for. But then Angular has transclusions, so......
[+] [-] tectonic|12 years ago|reply
That's pretty cool.
[+] [-] josteink|12 years ago|reply
I thought the internals of Angular already had a reputation for being pretty horrible and indecipherable already. I doubt this will improve on any of that criticism.
[+] [-] Cthulhu_|12 years ago|reply
JS not good enough? We'll invent new languages; Dart, Typescript, Coffeescript, etc. ES6 not yet done? We'll build a transpiler so we can fiddle with it until it's done - if ever.
I just wish the standardisation processes for web technologies would go faster. We get small revolutions every 2 years or so, but the standards behind them only get updated every decade.
[+] [-] tijs|12 years ago|reply
[+] [-] nostrademons|12 years ago|reply
[+] [-] pavlov|12 years ago|reply
[+] [-] marknutter|12 years ago|reply
[+] [-] fiatjaf|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] johnny635|12 years ago|reply
[+] [-] andy_ppp|12 years ago|reply
[+] [-] anton-107|12 years ago|reply
Why not just take Require.JS and use it as a dependency injector, like any other client-side frameworks allow you to do?
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.
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.
[+] [-] lern_too_spel|12 years ago|reply
[+] [-] richbradshaw|12 years ago|reply
"We're in early stages of designing Angular 2.0, but some of our goals are:
- Angular will use the underlying web platform features available to it (e.g. Node.bind, template integration, Custom Elements, etc...)
- Web Components (Polymer, Ember, or any other framework/library) will work seamlessly within Angular apps and directives.
- Components written in Angular will export to Web Components (to be used by Polymer, Ember, or any other framework/library) .
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).
-- Misko & the Angular team" (https://groups.google.com/forum/#!msg/polymer-dev/4RSYaKmbtE...)
Does anyone know if the focus on Web Components is still there?
[+] [-] Kiro|12 years ago|reply
Where can I find a simple example?
[+] [-] Osiris|12 years ago|reply
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.
Good luck to the Angular team.
[+] [-] iSnow|12 years ago|reply
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.
Why not just include restangular as one of the resource modules if they decide to go all-out modular?
I am hoping for multiple ngIncludes and a bit easier development of directives, other than that, keep up the good work, guys :)
[+] [-] opendomain|12 years ago|reply
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?
[+] [-] rdtsc|12 years ago|reply
[+] [-] orky56|12 years ago|reply
[+] [-] mcv|12 years ago|reply
Not really, since it's not remotely in Beta yet. It sounds like early alpha at best.
[+] [-] flylib|12 years ago|reply
[+] [-] johne20|12 years ago|reply
oh, and don't forget better documentation :)
[+] [-] orandolabs|12 years ago|reply
Rewriting a successful framework with no backward support is suicide. Please read this link before continuing on this path: http://www.joelonsoftware.com/articles/fog0000000069.html. 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: https://programmers.stackexchange.com/questions/63859/why-do....
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.
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.
You have a ground breaking, beautifully designed framework. Please don't destroy it because it's not perfect. Nothing is.
Can someone at Google please talk some sense into the developers running this project?
[+] [-] uptown|12 years ago|reply
[+] [-] candybar|12 years ago|reply
[+] [-] CmonDev|12 years ago|reply
"Simplify the directive API
Integrate with other component frameworks using web standards
Improve performance
Allow tools like IDEs to analyze and validate templates"
[+] [-] thoradam|12 years ago|reply
[+] [-] nailer|12 years ago|reply
[+] [-] ajanuary|12 years ago|reply
[+] [-] jimktrains2|12 years ago|reply
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.
[+] [-] kclay|12 years ago|reply