Let's face it: The engineers at Google know that the changes they are working for in Angular 2.0 will be very unpopular and cause many developers to jump to another framework - just at a time when Angularjs is really picking up steam.

It seems on the surface to be a very bad decision and my immediate reaction was like many other developers - WTF?

But thinking about it has given me a different perspective. Prior to Angular, I used jQuery for my front end business. I really didn't even know about Emberjs or Knockout or any of the other front end frameworks. I don't even remember how I heard of Angular, but when I first looked at it, it made no sense to me and I didn't see how I could write better code in Angular and was very familiar and pretty good with jQuery. But I figured that there must be something to this whole Angular thing, so I went through the pain of the learning curve and came out on the other end more productive and able to more easily write bullet proof front end code. In short, the pain was worth it and placing faith in the fact that smarter people than I had developed a worthwhile tool paid off.

So now I look at Angular 2.0 through the same lens as I looked at Angular when I was jQuery bound. For all intents and purposes, it's a completely different animal and there will be a steep-ish learning curve, but I'm willing to accept this. As developers, we must embrace change - how else did you come to learn Angular in the first place? Google does not hire dummies and I believe that the Google engineers have very very good reasons for making such fundamental changes and that after it's all said and done, I will be a better developer and write better code for it.

One thing I like about react is that the components you define only exist in the JSX without showing up in the actual DOM. That means that I can define the main content of my reusable react component within a "container div" so that it looks like const MyReusableComponent = () => <div className="container" style={{width:"100%", height:"100%"}}> ... </div>, and then I can put this reusable component in a "wrapper div" of definite size that the reusable component will then fill up. So something like this:

<div className="wrapper" style={{width:100,height:100}}>

<MyReusableComponent>

<div>

will end up like this in the DOM with only standard HTML elements:

<div className="wrapper" style={{width:100,height:100}}>

<div className="container" style={{width:"100%", height:"100%"}}>

...

</div>

<div>

By contrast, if I create a reusable component in angular2+ with a selector e.g. `app-my-reusable`, then the DOM will end up with an actual element called <app-my-reusable></app-my-reusable>. That means that in between my wrapper div and my container div will be this non-standard HTML element with default property display: inline;. This feels awkward to me since I'm now having to put block level divs in inline elements, which I've been told is poor practice (but seems to be expected on angular's approach).

I also just don't like having non-standard elements in my HTML though I don't really have a technical reason against them (other than the one stated above about inline elements).

Does anyone else feel this way about angular's use of non-standard HTML elements? Are there cases where these in-between inline elements can mess up one's CSS, or can they always be ignored? Do angular pros style these non-standard elements directly (using `:host{ ... }`, etc. in their CSS)?

I'm interested to hear your thoughts.

Here's why I think Angular is much better than React for creating SPAs.

React is not a framework like Angular is. It doesn't provide a comprehensive, one stop solution for all the things that you need for building an SPA. Often you will hear that React is 'un-opinionated' and that it allows developers the freedom to use whatever technologies they want alongside it. In practise, this means having to either constantly reinvent the wheel, or else employ a hotchpotch of third party libraries and be completely at the mercy of their maintainers.

Third party libraries may be buggy and there's no guarantee that fixes will be swift, if they even happen at all. Plus, they may be deprecated without any notice and you have to hope that they will work together successfully.

For state management Redux is the defacto standard. Redux is, in my view, seriously flawed. Firstly, why do you need to have a store in your client side at all? Is that not what the Database is for? In an SPA, the URL should be the single source of truth and the entire state of the app should be derived from this, using data fetched from a service. When you use Redux in an SPA, you need to work to keep the store in sync with the URL. This is a lot of work for no obvious benefit.

Another problem is that it risks storing stale data. Once the URL changes, all the existing data is potentially stale. There is no value in storing data across requests. If you want to cache data, the browser will cache your requests. Invalidating caches is notoriously difficult to do - why on earth do we bring this problem to client side development!

Redux also introduces Race conditions. If we make multiple requests to the server in quick succession, the Redux store has no way of knowing in what order these were made and given that they can return in any order, it is quite possible that the page we are looking at could be overwritten by the data from an old request! More detail about this problem here:http://blog.richardhunter.co.uk/index.php/13

The Redux store does NOT represent the current state of your app. It probably contains it, but it contains an awful lot besides and working out what is the current state and what is old state involves a lot of error prone work.

The next problem with React is that it does not support Dependency Injection. https://en.wikipedia.org/wiki/Dependency_injection DI is essential for building a complex enterprise grade application. The main benefits of DI are that it makes object creation a much cleaner process and it decouples dependencies from their implementation. If the last point is unclear, what it means that when you build an object you can supply completely different objects for any particular dependency. This is useful in testing where you can swap in mock objects for dependencies and thus test your objects in isolation from each other. With React, you have to rely on monkey patching or else test much larger chunks of your code at a time.

In React, you have to pass any dependencies down to components through props which can mean that a component has props that it doesn't actually use itself but just has them so it can pass them down to child components. You can use the Context for surfacing dependencies in a component but this is very much a poor man's DI imho.

There are other things about React that I don't like, but I don't want to extend this post too much. In particular PropTypes seem like an extremely feeble way of doing static typing and really typifies what is bad about React.

React isn't just different for not being a framework - it's worse. It is hopelessly inadequate for doing the job that it is supposed to and just results in messy, buggy, and inadequately tested applications.

I think the reason that React is more popular than Angular is because Angular lost a lot of good will during the shift from version 1 to 2. Maybe the Angular team didn't cover itself in glory, but I think the decision was the right one as the new Angular is much superior to the old one. It's irrational to dislike Angular because of these events but maybe a lot of developers are irrational.

http://memeizle.com

Memeizle is a weekend project which is build with angular.js and bootstrap. It aims to collect bouncing boobs on a platform to watch and you know...

It needs internationalization support but you can still use its shortcuts:

space -> next boobs :) x -> hide these boobs

Memeizle is one of the first beta testers of MongoLabs' API v2 which provides read-only access to mongo collections over REST.

Memeizle is licensed with GPL. You can fork or contribute on github: https://github.com/dedeler/memeizle

It's possible to request a Spotify API Key for my Angular app, without having a premium account? "Not for commercial use"