Angular 2 Core

It doesn't matter what the books say. Or rather - you've got to understand the reason for the advice - not just learn to follow the advice.

Programming abounds with maxims. However you can't capture a complex truth with a glib catchphrase. Everyone is trying to achieve the same ends - ease of development without sacrificing maintainability (to give a very simple example).

Catch-phrases such as "separate your logic from your views" was meant in a specific context. If you etch it in granite and pass it on to future generations it won't always embody the practical truth it was meant to convey.

So - we should remember the catch phrases but understand their context - and therefore we might hope to understand the more subtle and less easily stated truth behind the one-liners.

Edit: Other framework name ideas ~ Modil.js, Controllr.js, Framework.js, Class.js, js.js

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

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.

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"

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"

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

quoted just to remind people that Angular as we know it is older than most other single-page app frameworks - even if it only became popular a year or two ago.

We've been looking at React at work over the last week, and were considering moving some of our angular directives to react. Now there is a larger case for building a complete app in Flux.

It's so incredibly designed, even without the ES6 optimizations of 0.12.0 (coming soon) you can code today in ES6 (I use 6to5 with JSX transformer harmony just in case).

React completely changed the way I thought about rich clients. It took me a little longer than 2 days, I went into React with an absolute hatred of anything Javascript and came out 2 weeks later loving it. There is something to be said for a library that can wash away over 10 years of built up anger for a particular technology. It's not just another revamped library thrown into the frying pan, it's a complete rethink of how rich clients can be developed almost effortlessly with code that anyone can read. When I got into react, all I could think was "yes, this makes sense, this is how it should have been all along." Moving into the future I expect most libraries will unify under the concepts introduced by React in the same way that most web applications frameworks are different flavors of MVC.

Angular has a void with the lack of a useful enough eventing solution - $scope eventing has specific use cases, but you don't want to use it as a general event bus, mainly due to performance. This is important for Angular since you don't want to couple modules together with hardcoded state keys that you may want to alter in different applications.

Flux does offer a way around the eventing problem at a lower level within React components, but on a higher level, there is no application level of control - you have to construct exactly the control you want, which while liberating, also is an easy way to create a hole in architecture when designing an application if you're not careful. Angular exposes that problem directly in many ways (for example handling transitions between two urls in the application), as well as forces thinking about module dependencies with dependency injection.

HTML mixed in with JS via JSX is also an abomination, that originally made me want to run far away from React when I first looked at it. I'm not a huge fan of it still, but it's not an extremely terrible thing as long as you keep higher level templates slim, which React forces you to do in order not to have huge chunks of HTML mixed in with complex JS...although I'm sure there are developers out there who do it anyway (just like there are plenty of Angular developers who will toss plenty of jQuery in an Angular controller).

- this feels like it is a key conceptual difference but I'm not clear on what this means.

Never got beyond all the directives, digests, factories, services, scopes, dependency injentions, all the ng-* tags and so on. That is a lot of terminology for something that is supposed to make developing web appliclations easy.

Granted I am not a Web UI developer was just curious what everything was excited about.

Maybe all this complexity just makes sense to someone who already did all the more complex stuff wiht jQuery? Not sure.

Anyway React made sense to me. The whole data flow ideas, minizing mutable state and inter-dependencies between components, VDOM and even JSX.

So I like React a lot better.

You are correct that React alone won't replace Angular, but with other tools (Ampersand, Flux, etc) you can use the pieces that you want and put them together. It's the difference between a library and a framework.

Router - Backbone's router, page.js etc

Web service querying - simple jquery ajax calls or you could use breeze.js, pouchdb etc

Unit testing - React has one built in, but you could use others too.

AngularJS does too much, and nearly all of that too much poorly.

Also pay attention to the new createFactory method which aims to make it easy to separate your changing HTML from the static HTML (which you would have previously used a templating library for)

My recommendation is to not use JSX ever since it breaks a lot of your tooling. The first impression people get is that "Hey this makes my code easier to read", but that is only because JSX introduces the problem that it attempts to solve.

Basically most HTML structures are 80% unchanging and 20% changing (the reason we use templates in the first place). React.DOM was a pain previously because you'd define a complicated HTML structure in Javascript, which isn't really any harder or more complex, but then you'd have all this code that was never changing distracting you from the code that was changing (i.e. your app behavior). JSX fixed this problem by turning all the static bits to html like templates do so it was visually easy to separate from your behavior code. This was the wrong solution because it's over engineered and breaks compatibility with a lot of things.

createFactory essentially allows you to "partially apply" the static parts and get a function that only needs to deal with the dynamic parts (like compiled template functions but for virtual DOM)

Anyways, check out the following links:

https://github.com/mlmorg/react-hyperscript

https://gist.github.com/sebmarkbage/d7bce729f38730399d28

React implements UI views and controllers. You write views that know how to render themselves, and then you write views that control them; the latter type of view fulfills the role of the classical MVC controller.

For example, consider how Cocoa works. It's a classical MVC framework: You have a view controller, which mediates between data and views. The controller doesn't know how to render anything, but it listens to data modifications, and sends update commands to the views; it also listens to changes to views and propagates those changes to the data model. (You can also let Cocoa Bindings do it for you, for the most part.)

In a single app, you typically end up with many such controllers, typically one per window, and controllers can reference each other to facilitate communication; also, there are often controllers that individually control just a single view, because it's easier to encapsulate reusable components that way. For example, if you need a text field that autocompletes, you could subclass NSTextField and build this special behaviour into the view itself, but it's cleaner to create a controller that can bind to any normal NSTextView.

In React, you have the same distribution of controllers (some handling big, multi-view layouts, some targeting discrete views), but the controller actually takes part in the view hierarchy: A controller has views as its children. It may not even use DOM elements, but consist entirely of custom view components. And it does exactly the same stuff as a controller would. For example, it may contain this:

    <Form>
      <TextField label='Name' minLength={3} ref='nameField'
        value={this.state.name}/>
      <NumericField label='Age' min={0} ref='ageField'
        value={this.state.value}>
    </Form>

This is very much like building out a form in Interface Builder and connecting the actual controls to variables using IBOutlets. In fact, I would argue that there is hardly any distinction at all. The difference is that the UI is declared in the controller. And why not? Interface Builder is separate, and keeps its view data stored separately, because a WYSIWYG editor can't touch code. (Actually, Delphi showed that it was possible, but that's another story.)

The fact that there is a separation isn't actually useful to anyone. You generally cannot edit the view layout without breaking code, and you can't edit the code without breaking the view: They have to be maintained completely in sync with each other. So you might as well just keep the view layout in the same file as the controller. Which is what React does.

I think once proponets start to point to all these other things and not to nherent benefits or advantages of the technologies, they have already lost me.

> They get community right and at the end of the day, that's the only thing that really counts.

Popularity is not the most useful measure but it is a useful metric to determine the viability of a framework and it also gives an idea about how open a team is to outside contributions which is a huge factor in eventual success. (See: Linux vs Minix).

I'm not a fan of Javascript either on the clientside or on the serverside but I agree with the GGP that they seem to get community right and even if every other decision they make is wrong in the long turn that may make them the equivalent of PHP in their domain.

Listen, if I can figure it out and get lots and lots of work done with it, it's neither horrible nor overblown and the barrier of entry was there but I got over it. By all means, keep ignoring it, but drop the shtick where you know better than thousands and thousands of us out here building things with it.

I agree with your comment about it. I tried it and didn't like it. I've talked to a few devs who Have mentioned issue in larger projects more around organizing the code base.).

Regardless of all of that. There's so much demand that I'm going to drop emberjs and learn angular.

A platform like this achieves critical mass when it starts appearing in McKinsey slides, and then it will become a permanent fixture in job ads for the next 10 years. I guess Angular has reached that milestone.

I haven't done the exact numbers and 90% seems really high, but it feels like it. I bet the exact number wouldn't be lower than 75%.

I live in Eastern Europe, but I am mostly looking for remote jobs. I am a real full-stack developer and would gladly work on backend with Node.js, but these jobs are even rarer these days.

I'm honestly surprised how often I keep hearing about its high barrier to entry. I've worked on ~5 different MVC style web frameworks, all server side, over ~5 years of professional programming. I just started a front-end position using Angular for the last three months, and have found it pretty straight-forward to pick up. That is, the concepts I learned server-side have translated fairly cleanly to the front-end.

Most of the people I've seen struggle with the framework so far are those that didn't have that server side experience. Which isn't to say its required, but only to say some of the concepts they struggle the most with are concepts you need for any MVC style web framework - server side or front-end. Its not that they are that similar, but that they encounter and solve many of the same problems. Routing, separation of concerns, dependency injection, testing, getting what you want into the template, etc. And Angular isn't what you'd call a micro framework (see Django vs Flask or Bottle from Python world, for example). So of course Angular is large; it tries to solve alot of problems for you (how well it does so is another story).

Anyways, the take-away (from my point of view) is that much of the work that used to be done by server-side guys can now be done by front-end guys. So they have to learn all the same concepts and struggle with all the same problems to be effective.

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.

These are the reasons I'm using flux/react now. I'm really looking forward to following the development of Angular 2 now, and may just be my tool of choice for new development in a couple years.