Bullshit. The "decline" of angular hasn't happened, and if it happens it will have nothing to do with OOP and everything to do with its extreme complexity (build system, dependency injection, view directives, on and on).
I know "functional programming" is pretty (popular|trendy), and rightfully so. It's pretty awesome. But it's not a panacea. And it's not helpful to talk about OOP and FP as if they are mutually exclusive let alone opposites.
One of the most important principles in programming is to use appropriate abstractions. All UIs are state machines. Classes are state machines. Any attempt to make your UI as stateless as possible is just inviting leaky abstractions.
Not the decline but I guess before migration to 2.0 a lot of Users will reevaluate if they will use 2.0. I doubt that only a few already migrated to Angular 2.
Tooling gets better but in Angular 1 there are a lot of ways to create a project and minify it etc. On Angular 2 a lot of documentation is still missing.
We have a big angular 1 app but I'm not sure if we will migrate to 2.0.
I also think that once an Application get's really large it's painful to use a framework that isn't tailored to your needs anyway.
At my job we have a large angular application, and several smaller react + redux + flavor of the month.
We will never move to angular 2, not because it's not a good idea, but because we don't need it.
One of the most expensive lessons of these framework wars (in my opinion) is that the vast majority of problems don't need them or warrant the complexity.
Angular everywhere is the wrong approach, just as react everywhere is wrong.
Now if only I could convince the front-end engineers that their static form and homepage doesn't need react + redux + Babel + webpack.
Huge angular 1.x fan here , still using it. I'm not going to move to 2.x for a few reasons
- it's an entire new framework, the only thing in common in the name
- typescript : if you need typescript to write your framework you'll write your framework API with typescript in mind, making it harder to use with vanilla Javascript. I don't want to use typescript, at all, I'm a big fan of statically typed languages ... on the server. I'm sick of these complex asset pipelines on the client. Node isn't that fast so compilation isn't fast either.
In my book ,the decline of Angular has happened, nothing justifies a complete different framework. They could have back-ported a lot of ideas in 1.x . 2.x suffers from the second system syndrome and I see very little practical enhancements and features worth switching.
Complexity is definitely a barrier for Angular 2 where I work. We use Angular 1 almost exclusively for our existing applications, but are most likely going to be continuing to use Angular 1 and migrating towards React rather than learning Angular 2. We already began using Redux so it's a much easier transition for us.
I absolutely agree with you on the use of appropriate abstractions. One of our UI developers is a huge FP advocate and wrote large portions of our biggest frontend codebase using Ramda, and its basically incomprehensible to the majority of our engineers. I even though it was cool to begin with, but seeing the shape its taken at scale I regret it 100%.
So this article is basically saying. I am opinionated about how we should Design. Angular 2.0 is opinionated in the you should design. We think that Angular 2.0 way of design sucks, for anecdotal reasons. Thus Angular is going to fail.
Well angular 2 is mostly written the same way every time you want to build something and is connected through a custom html tag. This allows you to not deal with js that is built 100 different ways for a 100 different reasons. Not just that but file structure is exactly the same always. Basically angular1 was just a step up from JavaScript which seemed nice but really with not much reusability. Plus since you can build components inside components, you don't have to worry about implementation into a project. With RC5s new modules, you don't have to worry about importing into those components. So basically you can easily implement the app into any project with the same components and the same way always. Basically once you make one, you don't have to rewrite it. They even have their own CSS files, and use life cycle hooks so you can have different components fire off at different render times or events. It is basically the jquery of data. Also with easy observables, server side rendering, and simple data binding, you really can do anything. Angular 2 and 1 are night and day
I'm really hoping that Aurelia starts getting more attention, and becomes an accepted next move from Angular.js 1.
People have already mentioned some of the practical problems with Angular 2. OOP vs. functional styles is an interesting debate, but Angular 2, React and Ember each have more basic issues than that, around things like onboarding new developers, project setup, usability, and support. All three have different, but big, deal-breakers for me.
Inheritance over composition,
Internal class state,
Imperative state mutations
Only the last one is important. Internal state can exist in FP its just either immutable or private. I think even hardcore OOP people encourage composition over inheritance as much as possible and class based inheritance is not anti-thetical to FP (see scala)
13 comments
[ 2.7 ms ] story [ 31.4 ms ] threadI know "functional programming" is pretty (popular|trendy), and rightfully so. It's pretty awesome. But it's not a panacea. And it's not helpful to talk about OOP and FP as if they are mutually exclusive let alone opposites.
One of the most important principles in programming is to use appropriate abstractions. All UIs are state machines. Classes are state machines. Any attempt to make your UI as stateless as possible is just inviting leaky abstractions.
Not the decline but I guess before migration to 2.0 a lot of Users will reevaluate if they will use 2.0. I doubt that only a few already migrated to Angular 2.
Tooling gets better but in Angular 1 there are a lot of ways to create a project and minify it etc. On Angular 2 a lot of documentation is still missing. We have a big angular 1 app but I'm not sure if we will migrate to 2.0. I also think that once an Application get's really large it's painful to use a framework that isn't tailored to your needs anyway.
We will never move to angular 2, not because it's not a good idea, but because we don't need it.
One of the most expensive lessons of these framework wars (in my opinion) is that the vast majority of problems don't need them or warrant the complexity.
Angular everywhere is the wrong approach, just as react everywhere is wrong.
Now if only I could convince the front-end engineers that their static form and homepage doesn't need react + redux + Babel + webpack.
- it's an entire new framework, the only thing in common in the name
- typescript : if you need typescript to write your framework you'll write your framework API with typescript in mind, making it harder to use with vanilla Javascript. I don't want to use typescript, at all, I'm a big fan of statically typed languages ... on the server. I'm sick of these complex asset pipelines on the client. Node isn't that fast so compilation isn't fast either.
In my book ,the decline of Angular has happened, nothing justifies a complete different framework. They could have back-ported a lot of ideas in 1.x . 2.x suffers from the second system syndrome and I see very little practical enhancements and features worth switching.
I absolutely agree with you on the use of appropriate abstractions. One of our UI developers is a huge FP advocate and wrote large portions of our biggest frontend codebase using Ramda, and its basically incomprehensible to the majority of our engineers. I even though it was cool to begin with, but seeing the shape its taken at scale I regret it 100%.
This just seems to be hyperbolic.
People have already mentioned some of the practical problems with Angular 2. OOP vs. functional styles is an interesting debate, but Angular 2, React and Ember each have more basic issues than that, around things like onboarding new developers, project setup, usability, and support. All three have different, but big, deal-breakers for me.
Inheritance over composition, Internal class state, Imperative state mutations
Only the last one is important. Internal state can exist in FP its just either immutable or private. I think even hardcore OOP people encourage composition over inheritance as much as possible and class based inheritance is not anti-thetical to FP (see scala)