Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Angular 2 Core

docs.google.com

Post reply on HN
Print view View original

121–130 of 279 posts

Re: Angular 2 Core

#121

Post by dragonwriter »

inglor wrote: post #5

The problem I see with this is that it's very different from Angular 1 to the point people using Angular would have to learn it all over again. Breaking how the framework looks this drastically is both very brave and very risky. Especially since from discussions with Angular core (and as you can see from the presentation) - Angular 2.0 relies heavily on ES6 features and syntax which are not yet supported in any brows…

> Angular 2.0 relies heavily on ES6 features and syntax which are not yet supported in any browser

Which is why part of the project is a compiler which compiles ES6 (actually, an ES6 superset) to ES5, which is supported by every browser.

https://github.com/google/traceur-compiler

Re: Angular 2 Core

#122

Post by omarelamri »

novaleaf wrote: post #114
omarelamri wrote: post #113

Is he using TypeScript or ECMAScript 6? Also, is it just me, to does this seem like a completely different framework than Angular 1?

Typescript is ECMAScript6, with additional (typing) features. I'd venture it's ecmascript 6 being used, as Google suffers NIH syndrome too..

Yeah, it definitely is EcmaScript 6. They've added the "class" and "constructor" keywords. Typescript is very mush modeled after EcmaScript 6 anyways, so technically it can be both. But I'm sure it's EcmaScript6, because that's what Angular 2 is written in.

Re: Angular 2 Core

#124

Post by kyllo »

nilliams wrote: post #99
kuni-toko-tachi wrote: post #55

Earlier quoted context omitted.

Agree 100%. Things like dependency injectors have no real place in JavaScript, where programmatic wiring and modules already solve the problem in an idiomatic way. Angulars modules factories services etc are absurd and attempt to reinvent what the language naturally provides.

>> where programmatic wiring and modules already solve the problem in an idiomatic way Can't agree with that. Not sure what you mean by 'programmatic wiring' as it sounds vague, but certainly modules do not solve the same problem that DI solves. Modules, (assuming you mean stuff you require() or equivalent), provide module-level dependencies but do not provide object instances. For example, if an instance of House re…

For example, if an instance of House requires a Door it is not enough to just require('Door'). You still have to do the equivalent of `new Door()` in your House module to get an instance. By doing so within the House module you just tightly coupled House to Door (your House now knows how to create Doors).

So what? What is so bad about House and Door being "tightly coupled"? Here's a House constructor that can take any kind of Door instance:

    function House(door){
        this.door = door;
    }
This is JavaScript, let's stop trying to make it into Java.

Re: Angular 2 Core

#125

Post by mateuszf »

skore wrote: post #54
robert_tweed wrote: post #43

Earlier quoted context omitted.

Indeed. If number of contributors is the only metric that counts then, since React has more contributors than jQuery, I guess that means we shouldn't bet on jQuery. Nobody's gonna be using that fly-by-night project in a year!

That's why I wrote "for reference". jQuery, of course, is a different kind of library. A proper argument would be: jQuery has about three times the contributors that mootools has. If I had to decide between mootools and jQuery, I'd pick the second because of that metric alone, yes. (And this is how the market ended up playing out.) Angular (born Jan 2010) has 2.5 times the number of contributors of ember (born Apr 20…

> But it's simply too young to warrant the same kind of investment that I have personally made into Angular.

Sure .. it makes sense. Though one of the main selling points of React is that it's dead easy.

Re: Angular 2 Core

#126

Post by woah »

davidholmesnyc wrote: post #92

I feel that Angular changes too much in HTML to be considered useful for long term projects.The new syntax is also disturbing. My ideal MVC for front end utilizes regular javascript and html tags. At most just add data-ang-click="" something like that instead of "(click)" the latter isn't even valid HTML. Sometimes I think Angular is mainly popular because it's supported by Google. If any regular developer made these…

I've been using Vue.js recently, it's a lot like Angular (inspired by?), without all the crazy nonsense: http://vuejs.org/api/

Re: Angular 2 Core

#127

Post by nilliams »

kyllo wrote: post #124
nilliams wrote: post #99

Earlier quoted context omitted.

>> where programmatic wiring and modules already solve the problem in an idiomatic way Can't agree with that. Not sure what you mean by 'programmatic wiring' as it sounds vague, but certainly modules do not solve the same problem that DI solves. Modules, (assuming you mean stuff you require() or equivalent), provide module-level dependencies but do not provide object instances. For example, if an instance of House re…

For example, if an instance of House requires a Door it is not enough to just require('Door'). You still have to do the equivalent of `new Door()` in your House module to get an instance. By doing so within the House module you just tightly coupled House to Door (your House now knows how to create Doors). So what? What is so bad about House and Door being "tightly coupled"? Here's a House constructor that can take an…

What you just wrote as a code example is Dependency Injection, it's just manual dependency injection as opposed to using an IOC container or any of the mechanisms Angular provides.

I am very much in favour of the approach you posted. That's exactly how I write my code (I don't currently use Angular), but yep ... that's DI. As James Shore said 'Dependency Injection is a 25-dollar term for a 5-cent concept'. [1].

What you show in that code example is what in my head I call "poor man's DI" or ... "passing stuff in" but it's actually my favourite kind as it demonstrates the fundamental idea and is easy to explain to people - as soon as you start talking about IOC and service providers things start to get murkier. I think that's definitely where Angular is losing some people. You can get a long way with the basic "poor man's" approach.

[1] http://www.jamesshore.com/Blog/Dependency-Injection-Demystif...

Re: Angular 2 Core

#128

Post by watty »

personZ wrote: post #107
marknutter wrote: post #78

It's sad to see a post on HN specifically devoted to Angular utterly devolve into framework flame wars. If the title were "Why Angular 2 will be better than React" I could understand, but this is just a sneak preview of features to come. Can we please just choose the tools we prefer and build stuff instead of nursing our insecurities about the choices we've made?

As someone at the inflection point of choosing a single-page framework, I find these "flamewars" incredibly useful. Further I find the notion that this is evidence of insecurity itself evidence of insecurity -- why feel threatened that people discuss alternatives and merits/detriments? When new language features of C# or other languages (e.g. Go) are brought up on here, inevitably those features and benefits will be…

Surely you don't really find "off topic" complaints an insecurity. This article is about Angular 2.0, I would expect to read about thoughts/pros/cons about Angular 2.0 when reading the comments.

It's similar to reading comments on a Halo (Xbox) post on Reddit. Over half the comments are flame wars about PS4 > Xbox. There have been many "framework vs. framework" potss already on HN, let's keep the flamewars contained.

Re: Angular 2 Core

#129

Post by swalsh »

dodyg wrote: post #84
swalsh wrote: post #74

There have been so many binding frameworks, with a few varieties of approach. It has always been clear that it's "experimental". But it's been a few years now, and the mature(er) frameworks are focusing themselves. This is a good thing! I'm glad they're learning, and willing to make it better. In my career I've gone from ASP -> PHP -> ASP.NET Web Forms -> ASP.NET MVC -> Angular/knockout/react. We're developers, if yo…

It's not about you, the developers. You can easily move on and jump from frameworks to frameworks. Your clients or employers suddenly have to worry about one extra thing because their newly developed applications/systems suddenly become 'out of date' simply because the crazy churn in on JavaScript frameworks API. It is not a good thing. We are invalidating people's investments, time and money for no good reason.

Honestly, that's why you don't develop a new production system in a framework that's just a few years old. I had a coworker suggest using Angular on our main product that pays our bills. My reply was, it looks great... i'm excited about it, but I think we should use it on less critical systems until it matures. There's too many unknowns. There's no reason every new platform you develop needs to be using literally the latest tech. Actually, there's really good reasons not to.

Re: Angular 2 Core

#130

Post by cpursley »

skore wrote: post #36

To everybody trying to make this into a tech fight about Angular vs. React/whatever, I've been repeating this like a mantra and even mentioned it in a talk on javascript once[0]: You can argue about the minor details of the tech stack till you turn green and blue, but Angular wins because it succeeds in the only metric that really counts. jQuery: (for reference) 5,656 commits 7 branches 122 releases 199 contributors…

You made a good point about the community.
Post reply on HN