Mocking the Web-challenged, redux

My issues with the Weather Channel’s site remain ongoing. A few weeks ago I let them know that the new system they were using to load up content was broken, because their developers thought it’d be brilliant to use native geolocation built into a browser without checking to see if the browser gave them access. If it didn’t, it caused a cascade of JavaScript errors that basically kept any of their content from appearing. This made it very hard to check the weather. If I turned geolocation on, the problems went away, but obviously that’s not a real solution, so I let them know about it.

The good news is, they fixed the geolocation issue. The bad news is, they managed to screw up two more things in exactly the same way.

When I checked back in some time later, I found that content still wouldn’t load—but now, turning geolocation on doesn’t do squat, because I’m no longer getting errors about that. What I did get were errors regarding the Promise feature from EMCAScript 6, and localStorage. I reported these as well.

Promises are an interesting thing, very similar to Futures in Dart which I’ve been working with a lot. Their support is relatively wide, but as with all new Web features it’s nowhere near what you could call universal. On, support for Promises is rated at about 67%. This means if someone visits with a browser that doesn’t have them, the Weather Channel should be including a polyfill script if they want to use Promises.

I got an e-mail back from them. They fixed the Promise issue, and apparently disregarded my note that there was also an error with localStorage.

I have localStorage disabled on most sites, and as a result, the Weather Channel’s script throws a security error when attempting to use it. This error is not being caught (of course), and it therefore prevents some of their core objects from being created. Without those objects, the content loading still fails.

Naturally, I had to reply telling them the loading problem still wasn’t fixed. Which it would have been (I didn’t say this part) if the developers had read my entire message the first time around.

So to recap, so far I’ve seen three site-murdering errors.

  1. Let’s rely on geolocation, which some users may disable for obvious privacy reasons.
  2. Let’s rely on the browser having good EMCAScript6 support, which is obviously a bad idea.
  3. Let’s rely on localStorage, which some users may disable for obvious privacy reasons.

Ugh. I know how hard it is to be a developer. I know how hard it is to develop Web content that works across a wide spectrum of browsers and user profiles. But I also know what a frelling try/catch block is, and I know you never, ever take new options for granted even if support seems fairly good. Unless support is darn near universal, you always fall back. And if a user disables something, you need to handle it. I don’t go as far as worrying about users disabling JavaScript altogether, but having come from the dark days of worrying about IE6, I know the value of preparing for the worst.

There are times I envy some of the younger programmers who are pushing the envelope with new technologies, and it’s really an amazing time for Web development because it’s so much easier to write code that just plain works now. (At least, you would think so.) But on the other hand, I see what lack of experience is doing to these millennials, and it just makes me wince. These particular errors are rookie mistakes, not something you should see on a big site.

About Lummox JR

Aspiring to be a beloved supervillain
This entry was posted in Uncategorized and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s