I have written my fair share of browser reviews — it used to be part of my job when I was an editor for CNET. But, these days, I view a Web browser as just a platform, a way to deliver the Web applications that I build.

This is why I’m not a big fan of Apple’s new Safari browser for Windows. Don’t get me wrong, I think it’s a great move for Apple. It will increase the company’s mind share in the Windows world beyond just the iPod and iTunes. And it’s great that it passes the Acid Test for CSS rendering, something that neither IE7 nor Firefox 2 are able to handle.

But if a Web browser is just a platform, then what really matters to a developer is the stability of that platform. A new browser brings with it new challenges and new incompatibilities, which is the antithesis of a nice, stable platform on which to build applications.

Instead of spending time innovating and moving our Web applications forward, we now have to go back and re-test everything against Safari on Windows. We have to re-verify that our JavaScript code still works, that our CSS still renders properly, yada yada yada. And as Safari creeps forward from beta to release, you have to repeat that process for each new release.

Meanwhile, it’s not like IE and Firefox will stand still — they will probably have new releases, either because of previously-planned releases or new features added in direct response to Safari. This means another round of testing and re-verification of code.

Now I know that we’re moving to a world where most of what happens on the Web happens on frameworks like Prototype and Google Web Toolkit. In theory, all you have to do as a developer is code to those frameworks and let the framework developers worry about testing and re-verifying on a new browser like Safari for Windows.

But let’s be real, the framework developers cannot guarantee that every nook and cranny of their code will work the same on all of these different rendering platforms. You will still have to test and re-verify your own app if you really intend to support Safari for Windows. You can’t just leave it up to the framework developers.

Besides, you probably have some things you did in your own code that was outside the scope of the frameworks — some CSS or JavaScript that’s unique to you, which you will definitely have to re-verify for Safari. If Safari does grab reasonable market share, then your testing matrix has gone from two primary browsers (IE and Firefox) up to three. This is a fifty percent increase in the number of tests you have to run.

I don’t want to sound like a Luddite — I do think competition and innovation in the software world is a good thing. It’s just such a headache personally to have to deal with yet another platform. I guess I’m getting too old to deal with a new round of the browser wars.