There was a time when you wrote a web site and you targeted IE6.
That time has long passed.
When you really only had to target IE6, you could pretend the web was platform independent.
The truth is now the web is neither, nor will ever be platform independent. It?s just an illusion based on the simple notion that browsers basically just render HTML.
How many platforms are there then?
This is a surprisingly difficult question to answer.
Back before the web really took off there were basically 3 platforms to develop an app for: Windows; Unix/Linux; and Mac.
When we answer this question for the web, really we have to look at browsers as if they are the operating system. Since the same browser exists on multiple base OS?s but could be different, we have to count each combination of browser and OS as a potentially separate version.
Windows: IE6, IE7, IE8, IE9 (beta), Firefox, Chrome, Safari
OSX: IE, Firefox, Safari (more?)
Linux: Firefox, Chrome
Android: Webkit
iPad, iPhone: Safari
I don?t have nearly every combination listed, but this is what I would consider a good coverage for any kind of public facing website.
Oh, don?t forget to cross this again with localization and globalization, because you might have a localization problem that only happens in a certain language in a certain browser on a certain OS.
Not just rendering level differences
It is also very interesting to consider that a web developer now has to consider how their site will not just render, but be used on a mobile platform.
Consider how Google released an iPad version of Gmail. And although, you may not really care if your site works on an iPhone or an Android phone, you probably should start caring about how it works on tablets like the iPad, because that market is only growing.
If you have a website that doesn?t work on someone?s iPad when they are shopping online, do you think they will get up, go turn on the computer, and go to your site to make the purchase or they will buy from a different site with a few touches?
With a phone size resolution, the considerations are even more important.
Tools help me make the web platform independent
No tool exists right now that can handle the non-technical aspects of platform independence for your web application, but let us imagine for a second that a library like JQuery really made your javascript platform independent.
If we were to hold onto that shaky assumption, we would need to make sure that we never wrote javascript that wasn?t written through the JQuery API. (Which happens to be an extremely leaky abstraction over javascript, CSS, and the DOM.) We would still have to make sure our HTML and CSS tags were platform independent.
So even if we could get parts of our development to be mostly platform independent, we would still need to test on all of the major platforms, because we could not rely on the platform independence.
Now, don?t get me wrong here. I love JQuery. It makes the job of a web developer so much easier. But, there is an important distinction. APIs and libraries like JQuery make it easier to write platform independent web code, but they don?t make our code platform independent.
What does all this mean?
We?ve gotten to the point where the most platform independent technology you can use is either Flash or Silverlight.
I?m not sure if this is the future of development, but it very well might be.
One important point to draw from this realization is that we shouldn?t necessarily choose to make our application a web application, because we need it to be platform independent. It seems like about 5 years ago, the web became the default choice, because it was better to have platform independence than a rich UI.
Hopefully, for the sake of web developers some of these paths die off or converge, or that standards compliance becomes so good that you could really write code for one browser and expect it to work on all the others.
Serve your content as plain text?
I don’t think the drive to the web was ever platform independence. It was deployment independence. I’ve had customers demand web apps for house appraisers out in the field to enter their appraisals into on site because their IT staff refused to deploy to clients anymore. They didn’t even care that they didn’t have connectivity. After we told them what they wanted was impossible, they canceled the project rather than build the client app they actually needed.
Not having to deploy, in many minds, makes up for any other costs in development time.
@Chris Tavares
Hi Chris,
You are right about the deployment, but Air, Flash and Silverlight accomplish that goal now also.
But… actually you were right about deployment, because it seems that we have gone back to the deployment model with deployment 2.0. Consider Google’s Chrome store in the making, the Apple Store for iPhone and iPad apps, and the android Market.
Seems installing apps is ok now?
jQuery’s goal has never been to make development more platform independent. Any functionality that it has in this regard is a derivative of other features and functionality.
Depending on what your web app is supposed to do, and what back-end code it interacts with (which renders the platform independence moot), web development is very much platform independent. A GOOD front-end engineer knows what to avoid and how to write code that works across all browsers OUT OF THE BOX, without a need for a plug-in.
When is Silverlight or Flash coming out for iOS, by the way?
Also, note that Google’s Chrome Store is based on HTML5, CSS3, and the advanced JavaScript APIs. Maybe the deployment model or packaging is changing, but the underlying code is still “web”.
@Derek
I didn’t mean to imply that jquery is built to provide platform independance, although certainly one of the goals of jquery is platform independence.
I completely disagree about a good front end engineer being able to write code that works on all browsers right out of the box though. Certainly someone can be skilled enough to know about most of the nuances between the browsers, but not all of them and not all the time. Perhaps it used to be the case that your statement is true, but not anymore.
As for flash and silverlight, we will see what happens, but good point. Apps do seem to be prevalent in the mobile devices though, and I don’t see that changing anytime soon.
I just got this month’s Wired magazine which happens to agree by coincidence thier cover story is “the web is dead.”
The Chrome store has an app deployment model. That is my only point there.
Chill out web development is my lively-hood also. Take a deep breath and smile. It will all be ok, even if there is no web in 5 years time. We will all have Mac books and work on iPad apps. 🙂
@John Sonmez
As most people who develop for the web are moving, feature-detection is where it’s at, not necessarily browser detection.
If the client supports “feature”, then run your awesome web 3.0 code (or whatever the kids are calling it these days). Otherwise, run your fallback which may simply remove the burden from the client and shift it to the server while still providing full functionality. That’s a pretty compelling design methodology to cover your bases. You can also make older browsers act new by importing such projects as html5shiv and utilizing a site like Modernizr. All of this can be embedded within your app, which is what I meant by “out of the box”. You can provide everything the client needs to run your code, rather than requiring a plug-in.
On that note, you can give me the stats about what percentage of browsers have Silverlight/Flash plug-ins installed, but the simple fact is they’re not baked into the browsers from the start and it requires user interaction to install. I do not deny that it’s an issue for an increasingly smaller percentage of users, but strictly speaking, I think it’s safer to develop for things you know for certain are present in the client.
Maybe in a perfect world you have a Silverlight/Flash app on top of a “pure” web app with a fallback to traditional client/server web dev, and throw in a mix of shivs and well known “hacks” to get the display you’re looking for. But when pitted against each other, I’d take the non-plugin code over the requiring a plug-in code unless there’s a real good reason to require our users to have that installed.
I am chill, though. 😉 I just sometimes get annoyed when I see what appears to be a reliance on a single-vendor solution because that’s what the developer/company is comfortable with (in the Silverlight case, .NET development). I have to ask if they’re really choosing the .NET & Silverlight path because it’s the _best_ choice or if it’s the path of least resistance. 🙂
It’s not that Silverlight/Flash are always better than traditional web applications but rather they offer advantages in certain situations. There is an overhead in having to maintain a HTML/CSS/JS code base that supports every nuance of browser and platform – taking a standards based approach helps but there are gotchas that even the pro’s have to struggle with. This overhead doesn’t exist in SL (what I know and I assume also in Flash) – you literally write it once and can largely assume it will work anywhere that supports the plug-in – of course, you have to accept that not all browser/OS will support your app but in some cases this is fine.
I think we have to stop seeing Silverlight/Flash as alternatives to HTML etc but simply as another tool in our belts to solve the increasingly demanding requirements of our users.
To be Platform Independent, the application that runs on the server must be capable of being installed and run on many different platforms. The best way to accomplish this is through an interpreted P-Code language like Perl, or PHP. The most important thing to know about this is that despite how difficult this might sound, it is really very easy to do.This one can summarize it all.