Browser Wars, The Sequel (or, How I Learned to Stop Worrying and Love HTML)

Imagine if you will…

The meeting is over, you have your new design that needs to be built, and now you sit at your whiteboard to plan your strategy.

First, we need an HTML version for the Web.  That’s easy.

Then we need an app for the iPhone, and possibly another app for the iPad, customized for the larger screen.  Okay, going to have to learn Objective-C… Or hire someone to do it.

But now there’s also the Palm Pre, so, going to need another app for that, at least that one can be HTML/JS/CSS, but there is the Palm’s SDK to learn…

And of course, we can’t forget the Blackberry market, we’ll need an app for them… Make that one app for each of the different Blackberries…

Holy crap, this is so much worse than the first Browser Wars ever were!  Back when I was a kid, all we had to worry about was Netscape and Internet Explorer!  Now, you kids with all your fancy devices are making the world a mess!!  Why can’t you just browse the web, you know, on the web??

With thoughts from Cameron Moll, and follow-up from PPK, I remain even more firmly planted in my position that, as a web developer, my job is to make websites.  And by websites, I mean valid, standardized, semantic HTML, not the “flavor of the month” device-specific language.

The approach to this positionis nothing new:

  • Always start with POSH. Valid HTML will never go out of style (I recently got into a somewhat-heated discussion with someone on a Discussion Board about his reliance on JS for his primary navigation.  His justification was that he didn’t care about IE6 users with JS turned off.  So I asked him if he cared about search engines, or mobile devices (which usually have JS turned off as a default).  He said, well, mobile devices weren’t part of the original scope.  And I said, well they’re part of the scope now, and if you had built the site to work without JS in the first place, you wouldn’t have to worry about what comes in the future, because it would just work anyway!  Wait, what was I talking about?  Oh yeah!)
  • Add CSS so it doesn’t look like crap, but don’t forget the print and handheld stylesheets (like I’ve done with this site)
  • Enhance the site with JS (note the word “enhance, which means everything in your site should be findable without JS; see tangent in first bullet)
  • And if you must do more work to justify your existence in your job, you can always do a little sniffing at the server to modify your webpages for certain devices, stuff like eliminating large images, “unnecessary” modules, etc. for bandwidth-challenged devices

What this gives you is a rock-solid product that should look good and function well on any device that any user should ever come across, from a text-only browser like Lynx, to the latest Nightly from Webkit, or any of the devices listed at the top of this rant, and even things that Steve Jobs hasn’t dreamt-up yet…

But after all of that, the business decision regarding individual apps remains: If you don’t build it, will they come?  I talk with so many people that talk about their mobile devices and apps as if they cannot be separated, as if apps were the only way to view content on mobile devices.  So, if you don’t build an app for their device, will they ever view your content?

That’s a pretty big question.  But I think, even with the mobile device development junkyard we are creating for ourselves, the browsers are getting so much better, and the technology they display is getting so much stronger and more elegant (I’m talking to you HTML5, CSS3, and jQuery!), that we are at a place where we can stop developing a new gadget for every device that falls off the truck, and simply revert back to doing what we do best: developing websites, for the web.

Or at least that’s my hope…

Otherwise, maybe it is time to buy that shotgun and move to that shed in the mountains…  You kids get off my property!!

Happy developing,

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.