Live data from Hacker News

Angular 2.0

blog.angularjs.org

131–140 of 169 posts

Re: Angular 2.0

#131

Earlier quoted context omitted.

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

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

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.

Re: Angular 2.0

#132
post #102

Earlier quoted context omitted.

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?

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 J…

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.

Re: Angular 2.0

#133
post #86
post #60

Earlier quoted context omitted.

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…

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…

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.

Re: Angular 2.0

#134

Earlier quoted context omitted.

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?

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?

Re: Angular 2.0

#135

Earlier quoted context omitted.

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/

Re: Angular 2.0

#136
post #92
post #88

Earlier quoted context omitted.

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?

Re: Angular 2.0

#137

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 w…

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.

Re: Angular 2.0

#138

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.

Re: Angular 2.0

#139
post #92

Earlier quoted context omitted.

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?

Isn't this line missing?

  import {Inject} from 'di/annotations';
Post reply on HN