Angular 2.0 | Hacker News Reader

Angular 2.0

blog.angularjs.org

367 pointscallmevlad166 comments

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.

I'll keep this high level; that's where I have issues with Angular.

Angular wants you to learn its vocabulary, and encourages users to expand it further. Like you point out, smart-float is a directive specific to the example. To me, it is a foreign object I don't recognize in html. In fact, directives, scopes?

The big one. Dependency Injection, factories, modules. In JS, this is a solution looking for a problem. There are simpler alternatives to DI. They have issues, but only in theory.

Clarity matters a lot. ng-show="form.length.$error.float". Is there a more simpler way of doing it? There should be; I can't even tell what that means.

I think there are distinctly two camps. I'm in the one which wants frameworks to make me productive with the languages, specs and standards I already know. React (+ router) does this. Backbone does this too, depending on what you're building.

(Edit: replaced semantic with clarity)

I'll agree it's not pretty to view source and see an inordinate amount of fluff in what was once your beautifully handcrafted semantic HTML. Much of this can be alleviated with templating (ng-view).

Have you taken the time to play around with angular before airing your grievances? My hunch is yes and that you may just be simplifying things for others who haven't used it yet.

For those of you who haven't had the pleasure of working with angular: Once you've familiarized yourself with the verbiage, most of jeswin's concerns here come second nature just by glancing in one's source code. Let's take the example:

    form.length.$error.float

The name form, albeit horribly chosen in this case, represents the parent form's identifier in angular (the form's name attribute). It would've made more sense to use <form name="formLengthValidationDemo"> or something more insightful so you could more easily see the name matching from HTML to JS.

$error is simply the representation of any form validation errors that may have occurred. It's standard in angular, and there's plenty of documentation. Just google for "angularjs form validation" and you'll find a million resources at your disposal.

form.length.$error.float is checking if an error exists for the validation rule float. Given the limited amount of code in the sample, we'd have to arbitrarily assume that the "smart-float" directive is implicitly setting a custom validation rule via:

    ngModel.$setValidity('float')

I'll have to agree to disagree regarding pattern usage and dependency injection. They do have a place, and it tends to be in larger applications which become a burden to maintain as your application grows. To be quite honest, I believe angular brought a simplicity to DI that has yet to be seen in many other frameworks. It entirely lowered the barrier to entry for writing testable code and heavily promoted unit testing at the same time.

Agree 100% with your post - some of these complaints are misrepresenting the aspects that are not as desired in Angular. I've used Angular quite extensively for the past 1 1/2 years, and most of the complaints I have with it are more nuanced, such as having to dynamically inject some custom directives via $compile in a service method provided to a controller due to the complexity of being able to alter the attributes present dynamically in a template.

The declarative style that Angular coaxes you into makes things incredibly easy to understand - you can write code like

    <header>
      <navbar></navbar>
    </header>
    <main>
      <sidebar></sidebar>
      <content></content>
    </main>
    <footer>
      <company-info></company-info>
      <credits></credits>
    </footer>

And instantly understand what the purpose of these elements are - they're easy to read, they're descriptive, and they're clearly custom elements not part of the normal HTML5 spec, so you can instantly recognize that they must be directives.

I can also do simple directives like <loading-spinner></loading-spinner> and create a nice template for CSS to hook into by using the loading-spinner element tag without having to distract from the rest of my DOM with a nesting of 8 divs that can easily be tucked away in a reusable template.

I agree with you that since your elements appear to not be a part of the HTML5 spec they must be custom and are directives, wouldn't it be a good idea to mark them as such in some way? Maybe prepend them with "an-" or something?

The reason being, considering that HTML5 is an ever evolving spec that it might be possible for a new element to be introduced that could be using the same name as one of your examples. That might muck things up a bit. At least visually, as I would imagine the directives would likely continue working the same as before. It's just that the "they must be directives" logic would fail in that instance.

Good point. I, too, enjoyed using custom tags like <zoomer> or such, but I'm going to think twice in future.

Interestingly, out of the box Angular provides directives as a, input, or form—meaning that when you write <input> you are, in fact, invoking a directive that provides extra features along with native tag's functionality. While using Angular, you may as well consider every HTML element a directive.

Nevertheless, Angular uses ng- prefix with their built-in directives that don't replicate some existing tag's functionality closely.

You can make your custom directives HTML5 compliant, see [1], you can use the HTML5 data- prefix. For instance:

  <sidebar></sidebar>

can instead be coded as:

  <span data-sidebar></span>

or something similar.

[1] -- http://docs.angularjs.org/guide/directive

Custom elements are part of the HTML5 spec too:

http://w3c.github.io/webcomponents/spec/custom/

The only requirement is that they have a dash in the name. So while <sidebar> is not a valid HTML5 element, <a-sidebar> would be.

That's my usual way, or the class-based way for older IE.

Maybe prepend them with "an-" or something?

Yes, this is actually the recommended practice from the documentation. Built-in Angular directives are typically prefixed with `ng-`, and they suggest that other projects/developers use their own prefixes to avoid conflict.

That seems like a poor reimplementation of XML namespaces.

Why not use XHTML at that point? If XHTML ever had a clear mission statement in life it was that.

I mean I thought XHTML was a curse a few years ago when it was The Thing Every Good Designer Uses™ since it couldn't be rendered as XML in the most popular browser. But hopefully that's not as much an issue anymore. Or maybe it is. I haven't kept up with IE.

>That seems like a poor reimplementation of XML namespaces

Or you know, an adoption of only the needed part, instead of all the BS junk that comes with XML namespaces.

>Why not use XHTML at that point?

Because of all the other junk that comes with it. And because it comes from W3C.

XHTML is on the way out, I'm afraid. Angular is designed for HTML5.

Actually, it's a little more complicated than this even. Not only might HTML add more tags, but a non-standard tag might be a W3C custom element: http://www.w3.org/TR/custom-elements/

When users gain the ability to define their own tags, you might not know which ones are driven by directives, the custom element, or both even.

The philosopher David Lewis had a lot of critics, and they would often cite the fact that they couldn't possibly see how modal realism could be true, to which Lewis would reply, "I don't know how to refute an incredulous stare."

Arguments from personal incredulity don't engage substantively with what they ostensibly claim to refute because they import a variable- the argument-maker's conception of what seems plausible- that really should do no work in a logical analysis.

The arguments adumbrated in the parent comment seem to have similar failure modes, adorned as they are with premises such as "to me, [the directive] is a foreign object I don't recognize," and "I can't even tell what that means." Someone who has never programmed before could look at some vanilla javascript and plead perplexity, but obviously this isn't an indictment of javascript itself. To really make the point, the parent comment would have to show that the learning curve is disproportionately arduous for the payoff at the summit, but reiterations of personal unfamiliarity were offered instead.

Jeswin gives no evidence of having made a reasonable attempt to understand Angular ("directives, scopes?"), but more crucially, displays little understanding of the benefits of Angular. DI is criticised as "a solution looking for a problem" in the context of javascript, as if dependency injection were a bandaid for not being a dynamic language. DI enables testability, and not even mentioning this advantage, let alone not providing a cogent argument for why the learning curve of DI doesn't justify the gains in testability, is to refuse to participate in the discussion entirely. Directives are similarly dismissed as "foreign objects," which they might be to some, but they're hugely powerful foreign objects that allow arbitrary behaviour to be written declaratively. Not knowing the benefits of Angular obviously contributes greatly to a reluctance to learn it, and perhaps a subsequent rationalisation of this reluctance as being provoked by something intrinsic to the framework.

Fittingly, after expressing bewilderment regarding Angular scoping, Jeswin goes on to divide the world into two camps, declaring membership in "the one which makes me productive with the languages, specs, and standards I already know", which is about the closest thing to a natural language scoping bug I've come across.

> DI enables testability, ..... the learning curve of DI doesn't justify the gains in testability

Dependency Injection is a redundant, useless pattern in dynamic languages; especially when it comes to testability.

In test.js:

  //paymentService may be an instance or a class
  services.paymentService = mockPaymentService;  
  ....
  //use paymentService in your tests here.

The above over-simplified example satisfies most test cases. You can convince me with some use-cases.

(Edit: You weren't misrepresenting what I said. Removed that claim. I misread, apology.)

With DI you can ensure you're not accessing anything that's globally defined. While you can mock out global objects and methods on global objects, it becomes far less clear what the ramifications of doing so becomes when your app becomes large and complicated. With DI, you have all the dependencies clearly defined for the function you're concerned about.

Beyond testing, DI makes it much easier to swap in different implementations of a dependency than simply throwing things into the global scope lets you do. Suppose I want to switch my model from one that communicates with Parse to one that communicates with Firebase. Supposing I adhere to the same interface, I should be able to simply drop it in place without affecting other functions or objects that still rely on the Parse version of the model.

Your first point cannot be debated, since we are speculating. In practice, I'vent seen a problem. It works, it's clean, and it is the right amount of engineering needed to solve the problem.

Parse and Firebase example:

  //someservice.js
  ...
  //works as long as both retain the same interface.
  provider = new FirebaseProvider; //new ParseProvider()

  //add: just using an if condition, the old fashioned way.
  getProvider: function() {
    if (config.provider === 'parse')
      return ParseProvider()
    else
      return FirebaseProvider()

Why is writing configuration cleaner than doing the above? That thought process is carried over from projects with lengthy build time.

Whether or not Angular's implementation of its provider is cleaner is irrelevant to your original point that DI is a "problem looking for a solution" in dynamic languages.

My interpertation of the AngularJS DI implementation is that it exists primarily to make it easy to swap items out for testing purposes. I believe it solves that problem very well.

What alternatives do you recommend to DI?

Nothing, for swapping things out. :)

In my test initialization, I'd probably just replace the value of "ns.someService" worldwide with a mock.

> just replace the value of "ns.someService" worldwide with a mock.

Having a window-wide namespace might make sense in the test, but it is pretty risky/limiting if you are writing a component that should be reused in contexts you don't fully control. There are other ways around that besides DI, but they will probably have similar trade-offs in safety EOU, etc.

Totally agree and also recommend to look at React. While Angular is just way too much of everything React is pretty much thought-out:

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

This is true. AngularJS is much better than what we had before, it is kind of large and monolithic.

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.

Except that Backbone.js, a micro-framework if there ever was one, exploded in popularity long before most people had even heard of AngularJS.

Backbone was the start of the cycle. It came around at a time when front-end apps were largely jQuery soup and put polish on best practices that good JS developers were already doing. Then a lot of other frameworks were developed which largely started from the same code-first premise that Backbone had/has, and Angular "won" by introducing a new paradigm built on declarative binding.

I predict that the next winner will leverage web components and do the one thing that makes that paradigm better.

Backbone doesn't do data binding; it's a completely different thing.

(That's why things like rivet and epoxy exist; because backbone doesn't do it right)

Correction: Backbone doesn't try to be the kitchen sink like Angular. Its source code is about 500 lines, and its docs say as much:

"Two way data-binding" is avoided. While it certainly makes for a nifty demo, and works for the most basic CRUD, it doesn't tend to be terribly useful in your real-world app. Sometimes you want to update on every keypress, sometimes on blur, sometimes when the panel is closed, and sometimes when the "save" button is clicked. In almost all cases, simply serializing the form to JSON is faster and easier. All that aside, if your heart is set, go for it.

This. I would add angular is good for teams requiring extensive structure. The cost is control. If you're building a corporate webapp, angular is great to keep everybody neat. If you're doing something unprecedented such as 3D rendering or a new UI element, angular will hinder more than backbone.

I never understood how JQuery and JS were just dumped the past 3-4 years in favor of all thse complex frameworks like AngularJS, Ember, etc... is there something these frameworks can do that JQuery can't? Can they make fancy single page apps and JQuery can't? I need to be enlightened.

Or is it simply ppl need to exercise their mental creativity?

Among other things that Angular, Ember & others bring, what you should understand here is that JQuery does not help you to structure your code. Those frameworks offer the type of structure that makes it easier to reason about how an app should be built, and it helps a lot when you're working in a team.

JQuery and JS were certainly not dumped, it is just that people writing single page apps moved on and are now using tools that help them.

"I never understood how JQuery and JS were just dumped the past 3-4 years in favor of all thse complex frameworks like AngularJS, Ember, etc..."

Well, you can't have Angular without JS so we'll focus on the point of jQuery here.

jQuery does a few things really well – so well that Angular itself uses jQuery (or jqLite by default). angular.element(selector) returns a jQuery object.

Angular also does a few things well. Code reusability and testability are much easier to achieve with Angular, in my opinion. Features like data-binding also help to reduce boilerplate code.

> Well, you can't have Angular without JS

Well you certainly can use it without writing any JS:

https://github.com/angular/angular.dart

However, you're going to compile it to JS when you're done.

Ok, cool. if Angular returns a jQuery object then its proof that it uses jQuery quite extensively. So does Ember.

There was a similar discussion last week. What I said then was that a lot of the things you would use jQuery for have a different solution in Angular: https://news.ycombinator.com/item?id=7396016.

jQlite is a pretty small subset of jQuery. Many things are left out to keep it lean. For example $(el).offset()/height()/width() etc. Mostly only the DOM methods are left as they do still need a bit of normalization across browsers.

Personally, the two big draws to me of Angular were "free" (as in, I don't have to write much code) DOM<->data binding, and the explicit goal of testability.

As a learning exercise, I wrote a page using just jquery, rewrote it in backbone, and then rewrote it in angular. Backbone helped me separate concerns; Angular helped me do that while writing _way_ less code, since I didn't have to manage keeping the DOM and the JS model in sync.

I had the same experience as well.

I redid a relatively trivial CRUD interface from backbone to Angular. The amount of code that I didn't need in Angular was ridiculous. Most of the code in backbone was moving stuff from the DOM into JS. Like var x = $('#elem').val(); kind of things over and over just did not need to be there in Angular.

I think that these kinds of interfaces hit a really good sweet spot with Angular and other databinding frameworks.

Agreed - data-binding and "magic" automatic updates to the view when the model changes are key to what make Angular attractive. The focus on testing is nice too, though.

>* is there something these frameworks can do that JQuery can't? Can they make fancy single page apps and JQuery can't? I need to be enlightened.*

jQuery has nothing to do with whether the app is single page or not.

Those frameworks make writing single page apps very easy.

Yes, there are a tons of things that jQuery cant do out of the box, like handle state in your application or keeping your client and server data reliably in sync, list goes on. Also, lots of frameworks haven't ditched jQuery, for instance, Ember.$ is a reference to Embers copy of jQuery.

It is strange to see Angular labeled "large" and "monolithic" here, when it was blasted for being too small and simple by one of the Ember guys (http://eviltrout.com/2013/06/15/ember-vs-angular.html).

I have suffered trough JEE which is/was really humungous, and Angular is really tiny in comparison.

imo AngularJS can be pretty micro and scales nicely. Its one of its major strengths, as you can use it to just build a tiny widget inside an existing page or all in and build a huge application.

Micro in the code you write, not the code that's loaded, so it doesn't seem practical to me.

It's worth noting that one of the goals listed for 2.0 in this post is increased modularity, which they imply will let you only load the pieces you're actually using.

What's after Flask? I don't see any Python framework after Flask.

such as vuejs?

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.

React is the Holy Grail of JS frameworks.

When I investigated React in detail, I found that there is a lot to like about it, but it's certainly no "holy grail." Specific downsides: you have to go back to manually writing event handlers (instead of getting automatic two-way data binding) and the virtual DOM is a leaky abstraction.

Here's my article where I analyze this in much more detail: http://blog.reverberate.org/2014/02/react-demystified.html

Also React does not "solve all the problems in the world" -- it says nothing about routing, validation, testability, and many of the other problems that Angular has solutions for.

Until tomorrow when someone else on HN tells me "______ is the Holy Grail of JS frameworks."

I'm curious what happens when you want to share models across components. In angular.js you would use services to do this, but what's the analog in React?

React encourages you to use a parent component that controls the state and passes it down to it's children via props.

Passing data to separate components without a shared parent is outside of what React is trying to accomplish but I've handled it before by passing a Backbone model to the separate components as props.

If you're passing it to child components you pass it through attributes. If you're passing up to parents, however, you have to create a function on the parent that will get called to accept the child's new data. This can get really messy if you have deeply nested components and need to get data from one branch to another branch.

I have been successful by instantiating separate services to perform REST operations and a global event emitter to establish communication between all the services and all the components that relate to these services in any way.

I cringe when I hear the words "global" and "event" together in the same sentence. Projects I've worked on in the past that relied heavily on global events often became a maintainability nightmare.

Why? Please share your experiences. I don't understand what's the utility of event emitters if not for serving as glue to all the separate components of an app. Am I wrong?

You're not wrong. It's definitely one way to solve it. I just find it harder to jump into a project with heavy reliance on global events and be able to quickly understand what's going on. It gets even harder if you have events firing other events.

> I just find it harder to jump into a project with heavy reliance on global events

Harder than what?

Harder than the way that it is done in Angular, via services.

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.

Thanks; I will read up on the proper definition. I had been using it to imply 'meaning' (more or less), from Semantics which wiki says is the 'study of meaning'.

'unclear' is a better choice. And less pretentious too, than 'semantic'.

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.

'JSX' is also what made me avoid React at first. But once I started using it, it made perfect sense. The 'JSX' is just compiled to Javascript anyway, it's just more convenient for deep nesting of html elements within a component.

In more recent talks the React devs have avoided using JSX in examples and instead use the compiled form as JSX goes far enough from what people expect that it turns people away before they've given it a chance.

The most important idea to take from React is that UI components are much simpler when they are state machines.

The thing that sold me on React was this statement: "Most people make the mistake that the DOM is a place you put things."

The DOM is what the user sees. That's all. With React, you have a virtual DOM that can hold everything, not just what the user sees. It's a pure data structure, and can be manipulated as such.

Because that DOM is a pure data structure, React can figure out for you what parts have changed, and re-render those bits as needed.

I agree with you that React's virtual DOM is a real breakthrough. However, that doesn't make all of React worthwhile. Other frameworks can (and should) integrate a virtual DOM.

>Most people make the mistake that the DOM is a place you put things.

I guess this is why Angular keeps the model separate from the DOM.

That said, the virtual DOM strikes me as a really good idea I'd like to see in Angular.

It's just the first impression. React view code is not HTML in pure sense—it's a DSL for describing virtual DOM tree (that happens to look a lot like HTML for obvious reasons).

You won't regret taking a couple of hours to try to build something simple with it.

But then again, is the comparison between Angular and React even a valid one? After all, Angular is more or less MVC with a lot of functionality for resource routing, component building whereas React seems like a view templating library. So if I am not wrong, we are comparing a framework with a targeted library.

The weakness with Angular is not the view imo, but the $apply-cycle which can bog down even a modern browser with moderately sized data.

React basically eliminates the need for something like the apply cycle, because you just re-render from the top whenever something changes. React is the view layer, but its approach is different enough that you may restructure (and simplify) the rest of your app as a result.

That puts me off too, it's too PHP, as you said, but I love React because I use it with Coffeescript, which eliminates the need for a JSX compilator: http://blog.vjeux.com/2013/javascript/react-coffeescript.htm...

(You can do the same thing with pure JS, there are some forms of simplifying the React.DOM.div() calls, but coffeescript makes it beautiful.)

You know, I disagreed at first, but then I looked at React's semantics and couldn't agree more afterwards.

>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.

smart-float is an HTML attribute. It does not "sound" like C++. Maybe you should learn HTML5 first?

Why this is the top comment is beyond me. This is whining.

Except that it appears to be an angular directive...?

http://docs.angularjs.org/guide/forms

What do you think an Angular directive is?

It is a DOM marker (HTML attribute, element, class or comment) with behavior (JavaScript) tied to it.

Angular lets you create your own HTML attributes. That's what a directive is.

Please don't insult JEE by comparing it with Angular.

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......

Big +1 to Facebook breaking down React into smaller parts that are reusable. Makes it hard to point out where there are weaknesses in the library with the "all or nothing" system of dependencies.

"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."

That's pretty cool.

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.

I write Ember applications using CoffeeScript plus ES6 module extensions, and everything gets transpiled down to JavaScript. And yet, I find it pretty easy to debug the generated code: It looks more-or-less like what I wrote, it's nicely indented, and there's just a little extra boilerplate here and there.

Do you have any reason to believe that the Traceur compiler generates unreadable output with Angular?

Really? Do you mean it's just super optimized and advanced, or coded badly? I kind of always assumed that famous libraries built by a team of open source geniuses would be super tight and tested for major errors and performance inefficiencies.

No snark, I really did think this. Of course, Wordpress and Drupal do seem to have a lot of crazy architectural decisions that made maintenance difficult, so maybe I am just completely off.

Here are two JS files from a framework that I've written myself over the past few years, for my own use. Is the angular source code pretty much like this, or much more optimized?

https://github.com/EGreg/Q/blob/master/platform/plugins/Q/we...

https://github.com/EGreg/Q/blob/master/platform/plugins/Stre...

It seems that they go as far as creating their own benchmark tool to optimize their performance[1]. They also seem to have a logging tool in the works just to expose the stuff going on under the hood[2].

[1]: https://docs.google.com/file/d/0BwftRCZoTFiyRzhnVml3dlRiR1A5...

[2]: https://github.com/angular/diary.js

> things will literally be hell to debug

The word "literally" has officially lost all meaning.

What do you mean by 'The word "literally"'? I don't understand.

He may mean the word no longer has a clear meaning -- it also means "figuratively". Which means it can't be relied on to have any meaning at all.

http://www.merriam-webster.com/dictionary/literally

1 : in a literal sense or manner : actually <took the remark literally> <was literally insane>

2: in effect : virtually <will literally turn the world upside down to combat cruelty or injustice — Norman Cousins>

Well, in either case it is meant to strengthen.

Err..Am I missing a joke? I think they literally mean the word "literally"

That may be, but the rug has been pulled out from under "literally". One will never again be able to assert something ... literally ... and expect to be believed.

http://www.merriam-webster.com/dictionary/literally

1 : in a literal sense or manner : actually <took the remark literally> <was literally insane>

2 : in effect : virtually <will literally turn the world upside down to combat cruelty or injustice — Norman Cousins>

I've taken to repeating it twice. For example, "When the board saw the CEO's plans for the company-wide reorganization, they literally-literally cut him off at the knees"

(As in, they drew a sword and severed his limbs, such that literal-literal blood was everywhere)

Very sad.

Why does this necessarily mean things will be more hellish to debug than Angular alone?

That's the reason I've not done anything more than dabble with it. My experiences building anything that wasn't Angular from the foundation up left me frustrated.

This is great for XYZ, but I need to do AB123C... well... shit.

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.

Just to clarify, even Traceur has a hard time supporting browsers before IE10. Though I agree that it is not an issue here.

FYI, your last post on the Nvidia post is dead.

There are a lot of intranet applications where you know the browser you target.

Dependency Injection -- the heroin of abstraction junkies.

This doesn't really add anything to the discussion. You should elaborate.

Thanks for saying that.

You must have never done unit tests client side.

I salute you comrade. +1.

> 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.

Well yes, Require.JS is not strictly speaking a dependency injector (however you can use it as one), but underlying AMD pattern is a very good example of IoC. And this allows all kinds of interesting stuff to do with your codebase - for example, use Require.JS for development, simplified module loader for production and, if Require.js configs become messy in your specific project, you can just load a module for your tests purposes directly, passing all of it's dependencies manually. I don't see what exactly Angular's dependency management adds to this.

RequireJS is not a service locator,it's a module loader. It doesnt instanciate anything.AngularJS DI IS a service locator, not a dependency injection container.

You're confused. A service locator doesn't have to instantiate anything.

Angular's injector, like Guice's injector is a service locator. Because the normal way to use AngularJS is to simply list your dependencies instead of requesting what you want from an injector instance, it is an IOC DI framework.

Back last year, (May 2013) Miško said:

"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?

First thing I looked for myself, this doc is titled "Polymer Notes" https://docs.google.com/document/d/16O2Im1ekfdJ4FU8FBbVRYGjq... - sounds like team Angular and team Polymer aren't exactly on the same page quite yet.

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.

Where can I find a simple example?

https://github.com/angular/di.js/blob/master/example/kitchen...

Seems pretty simple, imo.

I don't understand how that correlates to the current DI.

How do I rewrite the following using the new DI system?

  function MyCtrl($http, Base64) {
  	$http.get('http://www.example.com').success(function (data) {
  		console.log(Base64.decode(data));
  	});
  }

  import {Http} from 'angularjs/http';
  import {Base64} from './base64';

  @Inject(Http)
  @Inject(Base64)
  export class MyCtrl {
    constructor(Http, Base64) {
      Http.get('http://www.example.com').success(function (data) {
        console.log(Base64.decode(data));
      });
    }
  }

Not too bad, right?

I don't like it at all; the Http and Base64 imports require three tokens / lines to import, while the existing DI just needed one. RequireJS requires two (array entry, callback parameter).

I'll stick to ES 5 / Angular 1.2 if we're required to write this much boilerplate to achieve the same thing.

Isn't this line missing?

  import {Inject} from 'di/annotations';

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.

Good luck to the Angular team.

ES6 support with ES5 fallback, I am stoked.

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 :)

Using heavy javascript computation in low performant mobiles, isn't the same as playing Playstation 4 games on a Playstation 3?

You will need to go Playstation 3 native for performance, otherwise, you will not be able to do much computation.

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?

Yeah this a bit is misleading, title gives the impression this is a release announcement, instead it is more of blueprint of "how we plan to do it".

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.

> Should this be marked as Angular 2.0 BETA?

Not really, since it's not remotely in Beta yet. It sounds like early alpha at best.

looking at the design documents probably a RC in the next 6-8 months

+1 to "Integration with authentication and authorization". This is needed on 95% of apps or more, nice to know it hopefully will be supported.

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...

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.

So if you want to poll a service periodically, you can do that ... or if you want to use a websocket and just leave a pipe open to refresh your client-side model ... you can do that too? Got it. Thanks.

Yep. The $http service in angular core basically does your standard Http stuff (with some nifty additions like caching and promises), but people have built services to do sockets, sails, handle server-side events, etc.

You should actually use a service to keep data synchronized.

The actual important stuff:

"Simplify the directive API

Integrate with other component frameworks using web standards

Improve performance

Allow tools like IDEs to analyze and validate templates"

They mention annotations, presumably type annotations? Is that actually a part of ES6? I can't find any mention of it.

Would love to see Angular 2's ES6 use promote some of the 'inline async' you can do with ES6 generators.

I really want to hear more on that from the angular team. Generators and modules are my favorite ES6 features right now.

OT if you're going to insist on double spacing HTML, use "&nbps; " and not "  " 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.

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.

It's maddening and appalling to you because you deliberately disabled an essential part of the web platform on your browser. Your problem, not theirs.

What about the blind who use screen readers or braille displays? Why should the page become so bloated that I can't read simple text simply?

This is not an endorsement (or not) for blogs that rely on JS, but apparently 98.6% of screenreader users have javascript enabled.[0]

[0] http://webaim.org/projects/screenreadersurvey4/

Doesn't mean that it's makes for a pleasant or useful experience. Viz http://hanselminutes.com/413/im-a-blind-software-technician-... from a sibling comment of yours.

Also, I'm surprised I got downvoted for saying that we should be considering the disabled when making decisions on how to structure a blog. I know accessibility isn't _cool_ but it's the right thing to do, especially for a text-based site, like a blog.

(PS: mendelk, I'm not accusing you of downvoting me)

I don't have first-hand experience, but my impression is that modern screen readers shouldn't have too much trouble with simple JavaScript like this.

Could anybody with experience confirm/deny?

According to a recent podcast I listened to[1] about a blind Software user, it seemed like there is a lot of issues with the current generation of Screen Readers. This includes issues with JS.

1.http://hanselminutes.com/413/im-a-blind-software-technician-...

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.

It's pretty bizarre that people keep saying AngularJS is "large and monolithic" when it, in fact, is modular.

All I really need are client-side templates and awesome DOM binding.

What's the current best options?

Backbone.JS, it's exceptionally bare bones, but hey it's YOUR code. You don't have to memorize an entire framework like Angular.

Pick up a Backbone book and in two weeks your dangerous enough to use it. A month, you're in the groove. 6 months: Angul-who?

If you are going to use Backbone for the first time in a big project, beware that you don't end up with low-level code that is duplicated in different flavours all over the place.

When you have implemented features enough to notice that it takes too many steps to make new views that resemble old ones, ease off from feature building, and make proper custom abstractions suitable for that particular project.

Also check out Backbone extension: Marionette for modularizing and backbone-documentmodel for non-linear forms.

> Pick up a Backbone book and in two weeks your dangerous enough to use it. A month, you're in the groove. 6 months: Angul-who?

Is this supposed to sell Backbone? Because I'm on a similar curve with Angular with just the online docs. Doing stuff in Angular is really unbelievably easy once you let go of your old preconceptions. It's a new way of thinking, but it's one that's very effective.

Exactly.

Amen....

http://knockoutjs.com is probably a good contender as something primarily focused on templates and data bindings without much else.

http://www.ractivejs.org/

Ractive is my favorite. The community is not there though.

http://www.rivetsjs.com/

I'm planning to use it in my next project but haven't yet. It seems to fit the bill nicely.

AngularJS.

I will stick with jqueRy for now, i don't need this yet.

The focus on mobile web development is key here.

That's what bothers me. AngularJS is not going to be a big enough step (time will tell) for native apps to suddenly disappear and for everyone to go web app. They should have continued focus on a desktop-first approach since that's where they can really shine. What I see here with this announcement is that they are optimizing for the limited resources of the mobile device rather than the more powerful applications and usage patterns that we see on desktops.

They are getting rid of the config phase!!!

Reply on news.ycombinator.com