Hacker News Reader

Comment by realusername | Hacker News Reader

I'm quite disappointed by this presentation, I see only new syntax everywhere for approximately zero benefit.

There is not even any mention to the Object.observe integration which would be the most exiting feature to improve Angular apps.

Angular looks and feels now like a Java framework, with ugly decorators and bloated APIs, that's really sad...

View on HN

Came here to say this. In the last slide, when they were piling "RIP Directives", "RIP DI", "RIP Modules", etc., the only thing I had in mind was "RIP Angular". Very disappointing.

Really? Because I found angular to be highly convoluted in practice (and I have implemented it in practice).

Most of my team eventually settled on the conclusion that "the cognitive load of working through the implications of how these nested directives play out in an application is simply not worth it". Or something to that effect.

We all studied angular studiously, we all did our best to implement it in an effective and sound manner, and when things went wrong, and they always go wrong, the shear complexity of the framework tied our hands and forced us to do some very ugly hacks.

I look at our application as it stands, and I regret using angular.

If angular 2 is simplifying it's framework, the only thing I have to say to that is "Thank god, maybe I'll try it again"

Ever since reading Angular 2's goals, I put 2 and 2 together, the API was definitely going to have to change massively to accommodate ES6.

I'm sure they're using Object.observe it just wasn't mentioned in the presentation.

This is not even ES6, its some weird abomination (AtScript) on top of ES6.

We definitely wont be switching to Angular 2.0. Hello React.

While terribly written and in poor format, it has some semblance to ES6.

I like how a lot of people see React as a full-on alternative to AngularJS. It's not, React is just for the view (think jQuery), you'll need other components or a lot of manual work to build a full application with React.

> React is just for the view (think jQuery)

That is comparing apples to oranges. I agree that React is a view layer, but jQuery is most definitely not. The only thing they have in common is that they (usually) act on the DOM in some way.

Agreed on your point about needing other components/architecture to use React.

React's V and Angular's V aren't entirely compatible, in fact it's be nasty to use them together. Sure it's not a full alternative, but I believe when people are saying React, they are inferring that they will be using Flux with React (Or Backbone, Knockout, etc).

React can be much more than just a view. Even before integrating Flux or a lightweight library, React can be powerful.

The awkward DI/module system, I'm fine with loosing that.

The router I will probably miss, but there are decent router components for react.

Services, factories and providers? Rather big words for some insignificant differences.

The only thing I'll really miss is simple data-binding - but it has too high of a performance cost anyway. Simpler server-side rendering and testing will more than make up for that.

Looking at directives vs react components, it seems like many Angular features are just workarounds for some of its design choices.

What bugs me the most is the cognitive dissonance caused by what I'm reading about the new Angular. Its supposed to be more modular. Yet the thinking shown on these slides is quite the opposite:

* it introduces attribute changes in the markup that seem disharmonious with CSS selector syntax.

* it now also coupled with a new language in order to be used sensibly, which reintroduces annotations - another language-in-language that may lack the proper design care to make it composable and usable (e.g. how do you combine 5 annotations into one? I have no idea, guess you'll have to copy-paste them)

In short, to me it seems like Angular 2.0 is intent on going forward with adding even more complexity while breaking backward compatibility. "More modular" is not what I'm seeing here at all.

Oh, now I get it. The whole reason that AtScript exists is because they just can't give up the desire to have that bizarre Javaesque IoC container.

Object.observe is ES7

Yes but it's in Chrome Stable right now, I'm sure that when ES6 is implemented by vendors next year, they might throw in a few ES7 bits.

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.

It isn't quite a solved problem in the regular ecosystem. Currently importation is rigid - you end up testing the functionality of what you are importing instead of purely the logic of your modules. The tests are polluted with logic that really tests both the details of how an api provided by another library functions under the hood.

DI is the solution to that. It has every place in a language like JS, and I am excited with having it available.

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

DI allows you to provide an object with object instances it depends on without tightly coupling said object to those dependencies (pass a Door instance into a House instance, advantage being you can pass in any type of Door and House doesn't need to care - thanks polymorphism)!

I'm not sure that's a great explanation, but it's worth trying every now and then right?

You seem to be making the argument that the language provides alternatives, and it's true that in dynamic languages you can eschew some of the benefits of DI by doing monkey patching instead (e.g. to mock out an object's 'tightly coupled' dependencies during testing), but to myself and many OOP proponents DI leads to cleaner design and simpler tests.

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.

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

I remember the first time I heard the term Dependency Injection. I sounded really advanced and I felt like a fool not knowing about. Like have been living under a rock for last years.

When I realized it was "passing stuff in" I wanted to shout, I have done that for years!

>When I realized it was "passing stuff in" I wanted to shout, I have done that for years!

Well, it's the "automatic" part that is important, not just the DI.

So the setter gets called automatically, but now you have to store the object names as strings or in an XML file. How is that better?

Loose coopling?

Well, now the different classes inside your application are more loosely coupled, but your business logic is more tightly coupled to a DI framework.

I felt the same way about DI until I watched this video: http://www.youtube.com/watch?v=_OGGsf1ZXMs

Fantastic video. I think it nails what DI is good for, and furthermore, what a DI framework is good for. Not only that, but it's a faaaaar more elegant solution than what's been in Angular so far.

  var prod_dependencies = {
    obj0: require('obj0'),
    obj1: require('obj1')
  };

  var test_dependencies = {
    obj0: require('mockobj0'),
    obj1: require('mockobj1')
  };

  var dependencies = test_dependencies;

  some_func(dependencies.obj0,dependencies.obj1);

Javascript does not need Java-style dependency injection. Javascript's configuration language JSON is valid Javascript.

You're slightly off on your definitions - what you show in that example is dependency injection.

You are injecting dependencies into `some_func` by passing them in. See my response to kyllo below.

I think what you are arguing against is using further patterns to facilitate dependency injection, e.g. IOC containers, or what Angular uses (service locators).

Not all JSON are valid javascript: http://timelessrepo.com/json-isnt-a-javascript-subset

The topic of DI and/or IOC in dynamic languages is an interesting one.

I've seen a similar debate play out in the Python world and the debate seems to polarize into two camps:

"You have never built anything complex enough and therefore you don't understand the benefits of DI/IOC"

vs.

"You've come to a dynamic language from some verbose public static void main hell-hole and are suffering from some form of Stockholm Syndrome"

Reply on news.ycombinator.com