Friday, August 1, 2014

The Horror of Angular

I forget where, but somewhere I heard that you should rebuild your website every five years. I think this is pretty much true. If anything you might want to rebuild it if a smaller amount of time. Yes, this would be hard, but going into a project with the thought that everything is going to be rewritten in five years will help you produce quality code because you will avoid the coupling and dependencies that make code hard to work with.

Anyway, I work with Angular right now. I pretty much love Angular, but certain parts are horrible and I definitely think Angular will go away or be useless in five years. Frameworks in general will have to face a lot of issues and what remains of them in the future is unclear.

Okay, so first why is Angular horrible. When I was first introduced to Angular it was in comparison with Knockout. The exact comparison was the Knockout was a rowboat and Angular was a cruise ship. Angular gave you all sorts of stuff like a dependency injection framework, composable HTML in the form of directives, a promises framework, an ajax framework, and so on. Angular, unlike Knockout, also data binds on POJOs (plain old JavaScript objects). You don't need to do the weird Knockout wrapping that when you mess up you get weird behavior. That all sounds really great! But the reason Angular gives you all this stuff is because it needs to control your world. The dependency injection framework exists so your code runs in an Angular context. Timing events, ajax, and promises are all wrapped by Angular because all your code has to run in that Angular context. The fact that Angular gives you all this stuff seems like a strength, but it is really a weakness. Instead of being able to pick and choose what I need I have to use your whole package. And when I need some control that Angular doesn't have a version of... Well I have to build a complex wrapper to make the control work with Angular.

People tend to forgive Angular for this lock in because it is free and the source is public so it doesn't feel like a marketing thing. But the reality is that this lock in is going to cause problems. Of course, the Angular guys are very smart and they work at a company very aware of how the web is changing. So they know this. They know that they have built a really cool framework, but they also know that at some deep core level it has big issues. To their credit they want to fix those issues. They want to replace dirty checking with Object.observe. They want to replace the Angular controls everything with Zones, a project that wraps the source of any event with a hook where you can insert code.

So why does Angular die in five years? Controls. In Angular controls are tightly bound to the framework. You can't use Angular controls outside Angular and you can't use non Angular controls in Angular. You can write interface layers, but this is work. Object.observe and Web Components will usher in a new era of controls. In web development that is what people really want. Data binding is great, but want we want is to bind data to complex controls like interactive tables and calendars If you can't work with random third party components easily you are at a big disadvantage. I used to work with an engineer who preferred ExtJS to Angular and her very valid reason was that ExtJS gave a rich component framework and you could build applications fast instead of trying to find the tree control you wanted and then integrate it into Angular.

It's great when I see big companies build awesome frameworks, but for most web development you really want something that slaps together fast that will have a planned lifetime of five years and then means small composable elements and not giant do everything frameworks.

Note that some frameworks leverage composable pieces. Angular does a very nice job of not touching your model objects although it doesn't leverage UI elements from outside Angular well at all.

3 comments:

  1. First, excellent point on Angular about the short fall of it MVC model, especially considering you spotted it and wrote in 2014. Wondering whether you evaluated Angular 2 yet. The lack of build-in component may still an issue, while framework like Clarity could help.

    ReplyDelete
  2. Hi, thanks for commenting on my blog. I am actually mainly developing in Angular 2 right now (they keep me so busy I no longer have time to blog). Angular 2 addresses many of the issues I mention. Zones takes care of the "Angular has to rule your world" issue, although the DI system still wants to run everything. They have strongly embraced web components and component creation itself is much, much easier. The ease of component creation and the embrace of TypeScript to manage contracts between components makes Angular much better and allows component libraries like Clarity to take off. So I feel like many of the issues I fretted about above have been directly addressed.

    ReplyDelete