This kind of reminds me of (my limited exposure to) XAML, in a good way.
Also interesting to note that this project seems thoroughly "de-Googled". Code hosted on github under a non-Google name, site made with bootstrap and not on a Google domain either.
I talked with one of the devs at BackboneConf (Vojta) and this project started as a 20% project that became fulltime for 3 devs. Apparently a team had been working on an internal project for 3 months and there was a bet that it could be rewritten in two weeks, which was won. Google uses it for a few internal apps.
Of the KVO frameworks, I consider it closest to Ember in the focus on bidirectional bindings for dom/model isolation. The most unique feature of Angular is the change detection technique.
Most frameworks handle this via extension of a base object and using get/set functions or ES5 accessors. Angular actually walks the entire model graph on demand. This allows it to work with base JS objects (there's no special syntax to learn) and third party libraries at the cost of having an O(n) operation in the system. The assumption is that modern JS engines are fast enough to do 10s of thousands of checks without a noticeable impact and your client side model is most likely under this size.
Interesting you mentioned Ember, which I'm a fan of as well as Angular, though I've been using Angular almost exclusively for severa weeks.
One key difference for Angular is that your markup ends up pretty much exactly how you want it. Ember had <script> tags littering my DOM for binding purposes, which made progressively enhancing forms (and leaving the standard submit event) require manual cleanup prior to letting the page change.
To Ember's credit, it is refreshingly opinionated, and solves the very difficult problem of handling complex states and transitions to deep portions of the app.
Ember had <script> tags littering my DOM for binding purposes, which made progressively enhancing forms (and leaving the standard submit event) require manual cleanup prior to letting the page change.
I'm familiar with the <script> tags it dumps for binding, but I don't understand why you needed to manually clean them up.
I think that would be a great tactic for newly launched google services. Every new service gets %50 credit from me because they're all intermingled with other google services which hinders user experience and shows lack of focus.
Well, Spine has fat controllers, and AngularJS has fat views. Whether I bind the data from the controller or the view it is the same amount of work. I don't see the immediate advantage over other frameworks.
The "Reusable Components" section states "This lets you focus either on what the application does or how the application looks separately." However, directly below is a view (template) stuffed in a controller as a string. AngularJS uses a "ng-" namespace for data whereas Knockout and others use the HTML5 "data-" spec. These seem like a step backwards, and behind what is found in Backbone, Spine, Ember, or Knockout.
Angular also includes its own forEach, JSON parsing, isArray, isElement, isFunction, isObject, isUndefined, noop and Promises methods (and more!). Other frameworks instead rely on existing, familiar libraries like jQuery or Underscore. It even has its own Uppercase and Lowercase methods, despite existing already in native JS. Even on the AngularJS website jQuery is included, therefore many of these methods unnecessarily exist twice.
Rather than use the existing event bindings, Angular has recreated them all with an "ng" prefix. Angular also has its own testing suite rather than integrating one of the existing popular JS test frameworks like Jasmine.
Angular doesn't seem to have any serverside equivalent for its proprietary design, so creating a fallback for less rich clients will be difficult.
I am striving to understand the distinct advantage of AngularJS, however mostly what I see is just reinventing the wheel. With so many proprietary methods, the learning curve is steeper than using a popular framework like Spine which is already extensible with common modules. It is a good effort, but against its comparables it has catching up to do.
Perhaps data-ng-* should then be the default, as another commenter has suggested.
The Web Component spec[1] examples always have the template in plain HTML, wrapped in a <template> and separate from any JavaScript. Searching the AngularJS site, there are zero references to "Web Components". Web Components are so new that the spec still has Norse mythology references, so a reference from Angular to the spec would be a big help.
More importantly, while Angular has been duplicating the functionality of Underscore and jQuery, the rest of the JS world is extending itself with CommonJS modules according to spec. Half of the builtwith.angularjs.org examples include jQuery anyway. Angular's attempt to be a complete "end-to-end solution" may easily make it a jack-of-all-trades, master of none. This also seems at odds with its focus on being a component.
Lastly, I am not the first person to raise these concerns.[2]
> AngularJS is our testbed to see what works and what doesn't. We are taking the best ideas from angular and use them to shape the (Web Components) specs (and the other way around too!).
As the first step, we are hoping to start to replace some pieces of angular when native apis are available. we'll see how far we'll get with this approach. What is important is that Angular can help you start thinking in the way that will be required for using these native apis and believe me that is a huge plus already.
So not only do they care about Web Components, they are using AngularJS to shape the specs and vice versa. Hard to be more standard than given that the specs are still unstable.
About being able to re-use the code on server side, I don't care about that, I write my apps in ruby anyway and this is out of scope of a JS MVC anyway. The only people that might care about that are Node users, and most people don't use Node or other js server side. So that's a non issue.
The template doesn't have to be inlined as a string. It can be loaded from external file (html), or included within a <script type="text/ng-template">
Having couple of util methods (forEach, isFunction, etc...), is just so that Angular can work without any other dependency, which many projects actually do. However you are free to use underscore, jquery and other libraries...
Jasmine ? Yep, we like it and we use it. Angular DOES use jasmine as its unit testing framework + we provide some helpers to make your life with jasmine + angular easier. But again, you can use any testing framework you like.
Angular is server agnostic. However, we have some ideas and plans how to do server side prerendering, so I believe it will come...
> Does angular use the jQuery library?
>Yes, angular uses jQuery, the open source DOM manipulation library. If jQuery is not present in your script path, angular falls back on its own implementation of jQuery lite. If jQuery is present in the path, angular uses it to manipulate the DOM.
The point of AngularJS is boilerplate-free 2-way data binding with plain javascript objects, which no other JS framework has. Give it a try, you will at least be able to draw much better comparisons afterwards.
Another framework worth taking a look it in this general category is https://github.com/elabs/serenade.js. It's a lot smaller and comes with it's own haml inspired templating language (whether those are pros or cons is up to each person to decide), but it feels very much in the same spirit as AngularJS, with two-way data binding and plain javascript objects.
"Angular also has its own testing suite rather than integrating one of the existing popular JS test frameworks like Jasmine."
are you sure about that? pretty sure it uses Jasmine.
From the tutorial:
"Angular developers prefer the syntax of Jasmine's Behavior-driven Development (BDD) framework when writing tests. Although Angular does not require you to use Jasmine, we wrote all of the tests in this tutorial in Jasmine. "
There are very brief references to Jasmine in the Unit Testing[1] and Testing Services[2] sections, however the complete (proprietary) E2E testing documentation does not mention Jasmine at all.[3]
The template tag conflicts with Django's. You can easily define a new AngularJS tag like this: "(( ))" tag
var m = angular.module('myApp', []); m.config(function($interpolateProvider) { $interpolateProvider.startSymbol('(('); $interpolateProvider.endSymbol('))'); });
A little OT but I have often found that when watching hour long videos, esp. conference videos it is best to play it at least 1.5X its original speed. For some reason not only does it save your time but maybe because the video is going faster I get less distracted and grasp more of it (maybe because your thought train isn't interrupted by other thoughts at faster speeds). This is also great for watching video tutorials by Linda, etc.
Youtube had this feature inbuilt too but seems they've discontinued it now. There is an iOS app called Foxtube that thankfully has retained this feature. Or you can just download it and play it in VLC. Thought I'd share this "hack" since the Google video is 2 hrs long.
On youtube, if you're part of the HTML5 experiment (check at http://www.youtube.com/html5), you can put the following in your address bar, to watch at a higher rate of speed:
My med school broadcasted all of our lectures online within minutes of the lecture being done. Although some students(20% or so) enjoyed being there the rest of us watched them online at speeds of 1.5 to 2x. I still have my freshman class shirt that reads "I watched it in Double Speed".
Not sure how you do it, but client-heavy applications that I've written quickly become a huge mess when written in pure Javascript/jQuery, especially when my clients require the app to be single page with no reloading.
Adding something like AngularJS or Knockout far reduces the amount of code you have to write and you get an app written around a data model. Knockout has a good description here:
> I read Backbone's documentation and to me is a mess of heavy JS programming to achieve something that I don't know what it is.
That got me thinking.. Could I ever explain a non-web developer what Backbone is in a succinct way? I'm gonna try..
Web development is basically storing data at the server side, modifying and handling that data on both the server side and the client side. So basically you got multiple representations of the very same thing on two very different mediums. Passing and modifying that representation back and forth between those two very different mediums can be very tricky and error prone by itself, let alone the situation that you're handling varying numbers and varying types of these representations. Now what these MVC frameworks give us are idiomatic methods and structures attacking this very problem of representational hell.
I've been using Angular with Grails for the last 6 months (but these comments would apply to Rails or any other server-side MVC framework) Although we do use Grails MVC to build the Angular-powered HTML pages, the pages are very nearly static HTML. We're using Grails to create a JSON API that the Angular controllers and services communicate with. We are also using the Grails resource pipeline (similar to the Rails Asset Pipeline) for LESS to CSS conversion, .js and .css catenation and minification, etc.
If you're creating "rich" front-end apps (as we are) you will be using your server-side framework mostly for implementing REST services with JSON (or XML, etc) However, you could also use Angular to add new functionality to some existing pages in an existing app.
| I don't understand this JS MVC thingy, what do they bring up to the table?
What MVC brings to any table -- structure and maintainability. This is more geared towards complete client-side applications than your typical jquery plugin.
Backbone and its ilk are full MVC themselves. Typically, you'd have models on the backend which are synced to the frontend via XHR/websockets/etc, so that both sides have a representation. Backbone also has controllers (in the Cocoa sense rather than the Rails sense), in the form of collections. Unlike Rails, though, most of the functionality is going to be in your views and your models.
Google releasing open source code and not revealing if they've ever used it on any of their sites (see 'built with angularjs http://builtwith.angularjs.org/ ) is somewhere between silly and suspicious.
Cool; the page is much improved. This has annoyed me with Closure library in the past, though that's been improved a bit. Users look at it and wonder whether anyone uses it, then Google people insist it's the most deployed javascript framework ever. Which, like, sure, great guys, but why not just say that on the website? Why the intrigue?
I work at Google, but not on the Angular team. Our team has deployed angular.js: places.google.com/manage. Angular's also used extensively in internal projects.
Does anyone know if the public-facing site is supposed to be using Angular? There are no references to the library anywhere in the source of http://www.google.com/doubleclick/.
DoubleClick is a public facing app, but you need an account which you can get only through a sales rep (I believe). The target audience are medium and large advertising agencies and not individuals.
Looking at Angular in more detail makes me want to port Plunker over. It would be a neat test of the framework since I find myself hitting some tricky areas in Backbone.js and in others wishing for a more prescriptive harness.
This is indeed interesting! Any googler want to comment how is this different from its cousin Google Closure Library? It looks like it is leaner and more modern. Any other difference?
Not a googler, but it has little in common with GCL's approach from what I've seen. Angular and most of the MVC frameworks seem targeted at removing boilerplate data-binding out of common business apps.
Closure is a collection of high performance libraries suitable for very large javascript applications and puts emphasis on reduced code size (post-compile) and performance/memory. It doesn't have any HTML bindings so you'd have to do that manually. After compilation I'd argue Closure would be leaner than the equivalent Angular application. I'm sure Angular can scale well, but probably not like Closure. It's no less modern than Angular and still being actively used (G+, schemer).
I'd say 95% of devs are looking for something like Angular. It looks like it will significantly reduce your JS source code; Closure will do the opposite.
There's little overlap between Closure Library and Angular.
Closure Library is a grab bag library full of useful functions that you can pick and choose from and integrate into your own code. Kind of like a standard library.
Angular is a client-side MVC framework that gives you two-way databinding and custom views and dependency injection.
Indeed, in our angular project, we use both - Closure Library for useful functions and advanced compilations, and angular for MVC.
I'm using an older version of Angular (0.9.19) for a medium sized project. The bad part is that they changed it so much for version 1.0 that it's almost another framework. And the worst part is that they introduced a lot of boilerplate. Too bad, Angular 0.9 was IMO better.
Can anyone with any ember experience comment on the differences between the two? I've been doing Ember for the past few months and my team is about to convert two Backbone projects into Ember for consistency. Based on what I've read, I'm starting to wish we had gone with AngularJS instead of EmberJS, but I'm sure each has it's pros and cons. At this point in the game, I think it's a bit too late for my team to switch frameworks unless there's a really compelling reason to do so.
If you can tell, I like Angular's approach better. However, the crucial thing is that Ember still has 2-way data binding. And I think you will have a much easier time porting Backbone to Ember than to AngularJS.
I thought it was the other way round, that AngularJS had features that most other frameworks didn't. Personally, when I looked at Angular and Knockout (and Backbone, etc.) last year, I liked that Angular didn't require using KO.observable to do binding like Knockout did. Angular isn't new, either; it's been around since 2010, but has mostly flown under the radar while other frameworks got more attention.
Angular's main weakness is probably its marketing. It's made by engineers and not designers, so its web fronts aren't crowd-pleasers. Its API and internals have been changing so rapidly that the documentation only recently caught up. But it's got very solid engineering under the hood, and there are a few blogposts out there by people who compared various JS MVC frameworks and picked Angular for its engineering.
With the advent of client-server frameworks like Derby and Meteor (and the Rails-integrated framework Joosy), the pure client-side frameworks may have to evolve to keep up, but among this slightly more mature crowd, Angular ranks very well IMO.
<<< Jason - AngularJS is 100% MVVM. The reason the Angular boys call it MVC, is because they are Googlers, not XAML developers. In Angular, Controllers are equivalent to ViewModels. You'll notice - there are no references to the view and zero DOM manipulation in Angular controllers. Knockout uses proxy objects for observable databinding. You will soon get tired of calling ko.observable() & ko.observableArray() to wrap any objects you want to databind. Proxies cause problems. Angular does not use proxy objects, and therefore you can databind directly to any JSON (ie, coming in from a service). – Ryan D. Hatch May 28 at 11:53
Jason (part 2) - Angular is also an HTML compiler... you can create new tags & attributes, just like you could create User Controls & Attached Properties in XAML. So everything becomes modular / you can create your own reusable components / controls. AngularJS supports scope inheritance, which is the equivalent to DataContext inheritance in XAML. AngularJS has a very bright future. Did I mention it has fully support for routes & deep-linking, partial views, services with dependency injection, and an excellent testing story? :) – Ryan D. Hatch May 28 at 11:53
---
Ryan, thanks for the feedback! You may notice that I wrote this answer almost one year ago. I still really enjoy MVCC, but your prediction is correct. I am getting weary of ko.observable(). – JasonSmith May 29 at 0:21
>>>
Although, forgoing "data-" prepending by default in the interest of saving a few bytes doesn't seem like a good tradeoff. If you have any HTML5 validation as part of your testing process, not having valid attributes is going to throw a whole mess of errors that you'll have to ignore.
Does HTML5 validation really matter when your goal is to build an MVC JavaScript app? I'm not trolling btw, many others in the community have long had validation pegged as a red herring [1] [2].
Validation of your attributes is fairly meaningless, and if you have a decent validator setup as part of your workflow (save-time or build-time - I personally wouldn't bother with either), then you should be able to customise it to turn off silly errors. You could also pre-process your JS files as part of your build step to replace ng-* with data-ng-* if it really meant that much to you. The byte-saving doesn't matter of course, but it seems like extra typing and more repetition in your templates for zero benefit.
The problem is not whether a validator spits several errors or not, HTML validators are tools designed to point out stuff that is not conforming to the specs. It's stuff that you should avoid, not that will necessarily break your application on any web browser.
Why should you avoid it? Because, basically, if it's explicitly forbidden, or not covered by spec, you can't be sure of what will happen in all (or newer) browser implementations. If there's no defined behavior for some code, any behavior is correct.
Also, it's not like you have to go an extra mile in order to follow the specs here.
Btw, here's my point:
The reason, why you want valid html, is to be able to use some html validator, which is super helpful, when finding bugs like unclosed div etc.
However, if you prefix all the custom attributes with data-* you only get these attributes ignored, not validated. For example if you type data-ng-rrepeat="", the validator won't catch it.
So I would rather extend html validator to accept new tags/attributes in some format, say JSON, so that during the build process of your app, you can get all the directives your app defines and validate them. Then you get even your custom directives validated. I believe that's the way to go.
The intro video is interesting, but the suggestion that apps in Angular are going to be "much more like HTML" seems to me to be belied by the fact that the second example has a more or less Backbone-like Model definition.
I can appreciate the desire to have declarative relationships within markup, but if there's going to be Javascript running anyway, what does it gain?
Yeah, the point of Angular is not to "program in html", just to have declarative html for dealing with the DOM and otherwise program in JS.
I totally agree for server-side templates that there are limited benefits (designer friendly perhaps) to a template as valid HTML. However, when you want to make your HTML interactive (2-way data binding) in an unobtrusive way, you are forced to understand html.
A good example I went over is how would you bind data to a checkbox automatically? I think you are advocating the Ember.js approach, which uses a function call to represent a checkbox, but a plain tag is actually much easier to understand: http://tunein.yap.tv/javascript/2012/06/11/javascript-framew...
I have tried several javascript mvc frameworks: angular, backbone , javascriptmvc (i'm serious, the name is javascriptmvc) but time and time again I'm always drawn back to backbone, as this is a post about angular, one thing that turns me off about angular is the high lock in/dependency towards the framework.
They have a lot, I mean a lot of functionalities built in, but with that comfot comes the price if you want to use any other jquery/javascript library plugin that's available out there. The only option you have is to "angularize" the plugin before you can use it. This is different from backbone, almost like the name suggest, it's bare bone, there will be more boilerplate code but you get more freedom and most if not all the plugins that are available to you from your js libs can be used as is. My suggestion before going all out to ANY js framework, know how the application would behave beforehand.
I believe mostly any object can be easily wrapped to be accessible by Angular (which is what's happening in angular-ui for jQuery plugins, for example). Right now documentation for these projects is sparse, but their authors tend to be active on the AngularJS Google Group, and people often offer solutions to problems very quickly there.
How is that different from trying to mix frameworks in the backend? If your framework doesn't do as much, you write more boilerplate. If it does more, you write less, but have vendor lockin.
I still like using Backbone collections and models with Angular and leave Angular with the VC part.
Angular, knockout and ember are the contenders I'm now aware of for 2 way data binding. Looks like angular also brings in some of the stuff backbone provides... I might prefer to go more ala cart and stick with knockout for now.
There seems to be a lot of magic going on under the hood, which will help you get off the ground quickly but I worry how easy it is to extend this to do unusual things.
Likewise, to provide features like dynamic update when a function's return value changes I assume it has to do either something very clever, or something very dumb (polling?). How performant is this sort of approach?
Yes, it polls. Most functions are quite fast, and fine to just poll, and it's quite convenient to be able to bind to functions when needed.
But it's all tradeoffs - in our app we have a few that aren't - for those, we profiled to find them, and added a bit of code to the functions to cache the return value.
After you bootstrap your app, nothing happens, unless:
- user interacts (DOM event is fired)
- response from server is back (xhr callback)
- setTimeout fires
- couple of other minor async stuff
So you only need to dirty check when some of these events occur and that's exactly what Angular does. Check out scope.$digest method, that's where all this stuff happens.
Sorry, what I meant is that when the application rerenders (digesting changes that have been made) it will re-evaluate the function to check if the result has changed.
Polling the function for changes, contrast with how e.g. knockout.js pushes changes. (I could be wrong, please let me know if my understanding's not reality)
Does anyone else find it odd that most JavaScript frameworks end up solving half the easy problems of doing frontend heavy web development, and leave the other half unsolved?
Backbone goes so far as to encourage a menagerie of bizarrely constructed HTML strings getting injected into templates, Spine has superfat controllers instead utilizing models more prominently, and AngularJS solves the (relatively easy) problem of databinding and little else.
What the hell? This is why we have to use roll our own solution at my company using jQuery + BackBone + _.template. We end up having most of the state either bound into the DOM (ala Angular, but done ourselves), or stored in a Cache object backed by Backbone.
FWIW, check out https://github.com/politician/outback for a bidirectional declarative binding solution for Backbone. It'll help you keep all of your DOM manipulation code safely away from your Views.
Also interesting to note that this project seems thoroughly "de-Googled". Code hosted on github under a non-Google name, site made with bootstrap and not on a Google domain either.