Live data from Hacker News

Angular 2.0

blog.angularjs.org

21–30 of 169 posts

Re: Angular 2.0

#21
post #16

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.

Re: Angular 2.0

#22
post #15

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: Length (float): {{length}} This is not a valid float number! 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 pr…

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.

Re: Angular 2.0

#23
post #15

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: Length (float): {{length}} This is not a valid float number! 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 pr…

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.

Re: Angular 2.0

#24
post #23
post #15

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: Length (float): {{length}} This is not a valid float number! 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 pr…

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.

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.

Re: Angular 2.0

#25
post #23

Earlier quoted context omitted.

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.

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.

Re: Angular 2.0

#26
post #6
post #2

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

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

Re: Angular 2.0

#27
post #7

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.

Re: Angular 2.0

#29
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?

Post reply on HN