The rise of functional programming and the decline of Angular 2.0
blog.wolksoftware.com
blog.wolksoftware.com
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.
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.
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)
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.