AngularJS IE Findings

February 5, 2014
Reading Time: 2 minutes

I recently had the joys of getting an AngularJS app I had created, working with IE9, and then subsequently IE8. If you haven’t had to do this, be happy. If you don’t have to ever do this, be even more happy. Internet Explorer will break your app from working correctly, for some very simple things. I wanted to post this to save people from the hours I had to spend, to finally track down the problems.

My initial plan of attack was to go to the AngularJS IRC Channel (#angularjs on freenode), I got responses like:

The best way to support IE8, is to show an alert that says to upgrade to IE9.

If you have to support an SPA in IE8, get a new job.

Even if tongue in cheek, none of them were helpful. The AngularJS docs on IE support were helpful in at least showing me the different things that I needed to incorporate into my application to prevent IE from freaking out on the custom tags and to use everything as attributes on existing html tags, rather than having AngularJS elements.

So here’s my run down of what had to be done in order to get this app to run in both IE9 and IE8:

  • No HTML5 tags (will break IE8)
  • Be sure there are no console.log statements ANYWHERE. (will break IE9)
  • Make sure your custom directives are defined as new elements in the index page header. // document.createElement(‘my-directive’);
  • I couldn’t get the AngularUI modal window to not throw an ‘unknown injector’ error in IE8, so I had to remove this functionality, and replace it with just an alert.
    • You could have something to check the version of IE and use one set of JavaScript over another however. I just didn’t have time to do this.
  • ng-include was breaking if any of the included parts had HTML5 tags.
  • Careful how you do your routes. See more on this below.

I originally was using my own modified version of John Papa’s Hot Towel Angular build combined with the AngularJS Seed build. However, the way that Hot Towel Angular does it’s routes, would break IE8, and I again didn’t have time to try and debug it further. So, I had to modify this to the way the AngularJS Seed build does the routes.

Please let me know if there are any other items that could be added to the list above. And just know, that AngularJS 1.3 will be dropping support for IE8 altogether. (Windows XP and IE8 support officially end April 2014).

 

Travels with AngularJS

January 21, 2014
Reading Time: 3 minutes

Speed of development is essential with web application development. Not to mention, if you aren’t careful your code will end up in a big mess in no time. Abstracting out highly identifiable layers in the front end development process can be not only tricky, but very cumbersome and difficult to maintain. Having recently tried developing a personal project I’ve been working on, only to stop and realize that the front end of it was becoming so complex, I could barely follow it while developing (damn you JavaScript!!). I had made my flowcharts ahead of time, reviewed them, re-reviewed them, only to hit this stopping point and realizing that there must be something better out there.

I thought I’d start by looking at a few of the MV* frameworks, such as Knockout.js, Backbone.js and AngularJS. I had used Knockout.js at the office somewhat, but found that it wasn’t what I was looking for. After developing my Ruby and Ruby on Rails skills over the last few years, I wanted something that was very fast for development all while allowing maximum control. Something that wasn’t overly verbose, and could accomplish everything I needed to develop on the front end.

Next up, I tried Backbone.js. Just a simple multi-field forms code was quite long, and I was still looking for something more concise. Hello, AngularJS.

I had once looked at AngularJS at the recommendation of a colleague, however, I didn’t initially grasp the API concepts documentation, didn’t want to waste development time on it at that moment and didn’t come back to it until I hit this project road block, as the entire back end of my project is now completed in Rails. This time however, without any distractions I dove right in. I found the exact resources on YouTube to explain the basics, followed by signing up for some video training on it. Within a week and a half, I was ready to go.

It was a slower start initially, making sure things were setup correctly, cross-checking my code with the API documentation that I now understood, first utilizing it on a work project which could only be completed in the compressed time frame I had available with the power and speed of AngularJS. I had a fall back plan in the event something didn’t work out as intended, which gave me only 4 days of working time to figure out if I could truly utilize AngularJS in the way it was meant to be used. I tired effortlessly until I had the skeleton on the application setup and functioning, and from there everything fell into place. I did in 3 days, what would have taken close to 3 weeks if doing it by Vanilla JavaScript and jQuery. I had multi-line fully dynamic forms with AngularUI (BootStrap UI AngularJS Compatible framework) and a fully responsive BootStrap 3 layout, with the ability to dynamically swap out the theme on the fly. I had a user account authentication system setup and working. The project didn’t require the use of any custom written directives, however, I’ve done the studying necessary to know when I would need them more.

As I continue to work on my personal project with AngularJS, I find a lot more satisfaction in working on the front end. Having a wonderful layout system and theme setup from BootStrap makes the development process a lot more enjoyable as well. It’s not, first build it out, then style it out. It’s now baked right in from the start.

If you’re looking to really try out AngularJS and see how it can enhance your front end project, I highly suggest looking at this YouTube video that greatly helped me.