Web Apps. Mobile Apps. Awesome!


Whatever You Do… Don’t Use Angular.js

November 4, 2015

I have been using Angular.js at my current client SeedInvest to handle the client side interaction of their website. It… has been an eye opening experience.

Way, way back when, I wrote a blog post about Backbone.js. Well… it’s now been a few years so let me revisit it and say this:

Backbone.js is freak’n awesome.

It’s light. It’s easy. It’s not opinionated about how stuff should be done. You want to make the whole thing one view driven by one controller, you can. You want to break it down so every little thing is driven by it’s own controller driven by a router, you can. It’s up to you to decide where to draw the line. I’ve put together some really great sites that use it and I’ve been able to put them together quickly.

And these aren’t simple sites. In fact, they do some incredibly complex things. Which is yet another great advantage of Backbone.js. It is exceedingly easy to debug. And when you find that your app is doing something wrong, it’s incredibly easy to fix those issues. Bug fixes can be done in minutes, not hours or days, which is important when you’re a guy like me who bills by the hour. Clients don’t usually mind paying for new development. They’re a little more touchy about paying for bug fixing. So being able to fix those bugs quickly is awesome.

All of these factors… Angular.js does not have. It is very complex. It is very opinionated. It is ridiculously hard to debug and fix issues.

All of these factors… Angular.js does not have. It is very complex. It is very opinionated. It is ridiculously hard to debug and fix issues.

If you don’t do things the “Angular way”, then you’re fighting a losing battle. Things will just not work. And, what’s worse, it will not tell you why things don’t work. It just won’t. It fails silently.

Which for a developer is the worst.

If something fails and doesn’t say somewhere why, then it makes it almost impossible to fix because there’s no easy way to identify what the problem is and to address it. Instead, you end up commenting out pieces of code to isolate things. And this process can takes hours if not days.

Then there are the “meta” languages that Angular makes you learn to write re-usable components, helpfully named “Directives“. A “directive” is, essentially, what I just said, it’s a re-usable component that you can place into HTML and that Angular will translate into that component. But, before you do this, you need to understand whether to link your variables with a “=” or a “@”, because each has a special meaning that’s completely clear. As does the way Angular knows how to cue a directive, either with a “A” or a “E” or a “C”. Because that matters also.

Forgetting the fact that inside this directive Angular is only granting you access to do certain things. The rest it “auto-magically” handles by itself. But if you set up either one of those things wrong, it either won’t do what you think you’re doing or it will do it wrong and good luck trying to find out why.

Compare this to Backbone. In backbone, everything that can be interacted with is a View. A view can be as small as a single list row or as large as the entire page. The size and way in which you intend to re-use, does not matter. Because it’s up to you. Now… generally, the best way I’ve found to handle these things is one-model-one-view. But it doesn’t have to be done this way.

Now… the most important thing about Backbone versus Angular is that Backbone is just JavaScript. Yes, it will handle REST calls for you behind the scenes but even that is just jQuery. But Angular is everything. It’s a superset on top of the JavaScript language. It’s a framework for developing apps. It’s a super set on top of HTML markup. You can define controllers to be either in directives or in the HTML itself. So it’s two-way binding. JavaScript can drive the rendering of the HTML which, in turn, can select it’s own child controllers to drive the HTML.

I’ve changed my mind about Backbone.js. In the years since I wrote the last post, I’ve had a lot more hands on experience with it and believe that it is simply the best way to have a JavaScript driven front end. Angular.js on the other hand, I wouldn’t recommend to anyone. It’s a shame it has such a large amount of support around it because it truly is a terrible, terrible mess to work with.

Back to Blog

42 Tags: , , , ,


Content for class "bottomYellow" Goes Here
Content for class "bottomBlue" Goes Here

42 Solutions

Working with 42 Solutions, you’ll find that it’s not the technology that’s important, it’s the idea. Regardless of whether your company is based on proprietary software or open source, we will find the right tools to get the job done.

Invite us to your office and we’ll send a pair of consultants armed with laptops and bright ideas, ready to solve your problem and offer solutions. We pride ourselves in getting to know how you do business and integrating into your process.