Many entrepreneurs have a bit of a blindspot about what using the best technology means: they think that it’s mostly a decision about the functionality it will provide, how long it will take to code it up, and whether it is worth it.
Often they neglect the ramifications of choosing a cutting-edge technology on your companies ability to hire, do SEO, be compatible on many browsers and integrate with common plugins.
The front-end coder we hired suggested Angular.js, and after doing some research, finding out that Google supported it, we decided to give it a go. Ember.js seemed like it was too new and didn’t have much documentation at the time, and we had heard that Angular was a more elegant solution than Backbone.js, even though Backbone was much more common.
We are happy with our decision, but we have been surprised at how many different issues have come up that we didn’t even expect, and didn’t weigh into our calculations when we first decided to use Angular. The following is a list of things you should think about before you adopt Angular.js, but in reality ANY new cutting edge technology.
**1) Older browsers**
Angular.js doesn’t work on any IE version below 8. Currently our website doesn’t work on IE 8 and 9, we are still trying to figure it out. It took a while to figure out the bugs on IE 10. IE on the whole is ~25% of our traffic and IE 8 and 9 make up around 80% of that traffic. That is a huge chunk of users that can’t yet use our site and is significantly affecting our conversion rate.
It’s already hard enough to program for old browsers like IE 8 and 9, but adding a new cutting-edge front-end technology when those browsers can barely handle CSS quirks is a pretty huge obstacle.
**2) SEO**
If you have a full Angular.js app, that means the vast majority if your source code will just be javascript files. Google hasn’t yet figured out a good way to scrape dynamic content, so you are out of luck unless you make some modifications.
We have what we call “hybrid” pages that exist outside the Angular SPA (Single Page Application). They are normal pages in Django (The Python framework we use) that have content that is crawl-able. The only part of these pages that is angular is the search box, and when you do a search it launches the Angular App.
What this means is we essentially have a bunch of satellite content splash pages around a central Angular app.
It means some code in headers and footers need to be duplicated, so when we want to add a library or tags we need to do it in two places.
**3) Adsense, Clicktale, and many libraries we tried to use didn’t work right out of the box.**
Adsense doesn’t work with websites that load dynamic content. In fact, it’s against the the TOS to do the workarounds that would make it possible (iFrames, etc.). That means Angular.js, anything using AJAX, etc. can’t use Adsense right out of the box.
I’ll let that settle in for a second: yes, the worlds foremost leader in online advertising hasn’t figure out an easy way to present ads on webpages that dynamically load content. While Angular.js is new, dynamic content loaded via AJAX is most definitely not, and its shocking to me that Google hasn’t figured out a good solution yet.
Adsense doesn’t work because it waits until the DOM has been constructed and then instantiates the ads based on the content of the page. It does this on page load, but in a “Single Page Application” like Angular.js, you never reload a page, all content is loaded dynamically, you transition seamlessly between “pages.”
The solution, which took an entire day to sort out, was to use Doubleclick For Publishers, a different Google Product, and load Adsense through that. We then had to “refresh” the advertisement’s div once the new “page” loaded. It’s a bit of a hack, but it works.
It took a while to figure that out.
This was similar for Clicktale, software we use to watch user sessions to find usability problems. For normal webpages you can just drop in a snippet of code, but for our website we have to use their special API.
What should have taken 5 minutes has now taken a week of back and forth with their tech team in Israel.
**4) Coders**
Many programmers will be ignorant of the new technology, so you will not have a ton of choices when it comes to employing people.
We ran into this problem ourselves when our front-end coder walked off the job on the day we launched a major partnership. We got lucky, a friend of ours employed a guy in Belarus who actually contributed to the Angular.js source code. They cleared some time in his schedule as a personal favor to us. But most people we talked to had no Angular.js experience. The common response was “Yeah, we have been intending on learning it because it’s definitely the future, but we don’t have anyone whose an expert yet.”
In conclusion, there are more things you need to think about than just “is it a good framework” before you choose to use a new technology like Angular.js. You need to consider how easy it will be to find people who know the framework, the ramifications on other parts of the business like SEO, Advertisement integration and cross browser compatibility.
We are very happy with Angular because we have the money and time to build something that is sustainable in the long haul, but it’s definitely not right for everyone.
Make sure you have the bandwidth as a company to deal with all the potential complications that arise from being on the cutting-edge.
David Litwak 
Nice post!
Anyway, isn’t it always like this in the FE world? I mean, it looks like something that’s changing all the time and there’s no framework that be “the bomb” for many long years.
LikeLike