IE is like that bad ex- you get drunk and hook up with again…

… it’s not that you forgot how bad they were. It’s that you forgot the myriad and sundry ways in which they were bad. Worse, you forgot all your coping mechanisms for dealing with them.

I’ve had the misfortune to be doing an Angular project for a client who relies entirely on IE8 still. Installing Chrome was out of the question. It’s that kind of place. So, after years away from the <insert gender-non-specific pejorative genitalia reference> that IE is, I looked up the Angular guide to dealing with IE, dutifully prepared…

… and got totally horse-whipped anyway. Some of the low-points:

• IE not only doesn’t support the `console` object, which I forgot… but it sorta-kinda half-heartedly supports it when it feels like it. But only when the console is actually open, and then maybe for a while after you have it open, which really, REALLY confuses your testers. Because your functions will simply halt when they hit a call to `console`, other than in that mysterious window. And you’re busy telling your testers to open their console and purge their cache and try all kinds of crazy things. Which works for, like, 90 seconds and then stops. And you’ve got your console open all the time, so you’re imagining all kinds of esoteric problems that could be intervening other than YOUR OWN CODE. So, be sure to purge all console statements from your code before pushing to IE and expecting normal people to use it. (Does anybody have a grunt task that’ll strip them during `build`?)
• IE does support XHR, but not all of it. Remember the good old days before `onload`, back when you had to muck around with `onreadystatechange`? Yeah, those days are back with IE8.
• Just forget about anything involving `.innerHtml`. And forget about any frameworks or widgets that might secretly make use of it.

One of my big takeaways? I’m *not* too good to have JQuery in my projects. We try hard to get rid of JQuery on Angular projects, to remind us to avoid JQuery-style thinking about imperative DOM manipulation. If you’re messing with IE<9, just put it back in there. (Be sure it’s version 1.x.)

Another: CHROME FRAME.

Another: What the hell is this? 2006?

Finally: If you’re developing for AngularJS, be sure to consult the Angular Dev Guide for IE, and just don’t mess around with trying to make your directives into elements. Slap attributes on <div>s, and be done.

Phat UI & Angular Testing

The world has changed. UI Engineering is 4 realz. Servers have gotten skinny, UI has gotten fat phat.

To fulfill its potential, UI Developers need to learn/use some important lessons that used to be the exclusive domain of Server-side Dev. Automated testing is one of the biggest. Automated testing, in a nutshell, allows you to prevent regressions while you work, particularly when you’re developing on a large codebase and/or a codebase worked on by many people. Often, this is hard. Angular.JS provides tools that make it easy (-er).

Chrome’s Incognito Mode is Good for More Than Just Porn & Larceny!

I don’t know if it’s the latest version of Chrome or just a normal variation in experience, but over the last day or so I suddenly find that many .html & .js files I’ve changed aren’t rendering in browser. The old versions are getting stuck in Chrome’s cache and not updating.

I started with ‘Force Reload’, which didn’t do the trick. Then, I bounced my server a couple times, but that didn’t help at all. Finally, I just manually cleared the Chrome cache, which solved it. 

And then I did it again. 

And then I left the settings page open to make the next 5 cache clearances easier.

And then I finally noticed that little yellow message the next time I opened the ‘Clear Browsing Data’ window: 

 

Oh, right. A tool beloved by porn-hunters, freedom-fighters, cheating spouses, and anybody else who doesn’t want to leave a trail actually has a very straightforward and more abstract purpose I should have thought of sooner: allowing you to browse without caching anything. Which is exactly what this UI guy wanted.