Browser Engine Extravaganza!! Come one! Come all!
Pros and Cons of multiple browser engines and how it can help and hurt the industry.
Franklin at s60 blogs (Nokia's blogs for their s60 platform) posted a couple of blogs regarding Mozilla's mobile browser announcement (http://blogs.s60.com/browser/2007/10/
coring_the_browser.html and http://blogs.s60.com/browser/2007/10/
yamb_yet_another_mobile_browse.html).
He makes some very interesting notes about the need for a single standards compliant core. I actually like a few of his reasons.
One of the reasons that I agree with is this:
There are a TON of mobile web browsers. None of them handle web pages in the same manner, or even support the same features. This, unfortunatly, makes development difficult for web developers. If a developer wants to support a popular web application on a wide variety of devices he/she must create a different version of the application for each device, or each class of device at the very least. Being able to condense the list of browser engines would make development easier on the web developers. This would also reduce the need for browsers to be inter-compatible. Having fewer engines would result in potentially less standards-incompatibilities which would result in less of a need to mock what the "other" browser does to remain consistent to the user (having all of the browser engines follow standards, and having standards cover as many aspects of web technologies as possible, would be the most ultimate solution. More will come below). The result would be few really good engines as opposed to many weak engines.
Unfortunately, there is always an opposing view. One that I see that is just as equal. The problem with having one or two engines is that you get a monopoly... And, the result is "we own the market, we will do what we want," including not following standards. This is bad. As a result, competition is non-existent and everybody must use the engine. This can get really bad for open source software and commercial software.
The goal is to find a middle ground. Many engines, but not too many. All the engines would be standards compliant and the standards would dictate as many aspects of technology as possible. This way, to the user the only difference is how the UI operates and not how the engine operates. Device manufacturers and carriers can then know that the browser supports the standards and then only needs to be concerned with how the engine handles resources. Competition would come through UI and resource management and not which engine works with which site, because all of the engines would work with all of the sites.
I will add a little bit more about defining mobile browser and desktop browsers and still remaining standards compliant next.+
Franklin at s60 blogs (Nokia's blogs for their s60 platform) posted a couple of blogs regarding Mozilla's mobile browser announcement (http://blogs.s60.com/browser/2007/10/
coring_the_browser.html and http://blogs.s60.com/browser/2007/10/
yamb_yet_another_mobile_browse.html).
He makes some very interesting notes about the need for a single standards compliant core. I actually like a few of his reasons.
One of the reasons that I agree with is this:
"But I think the LAST thing the mobile device world needs is Yet Another Mobile Browser. We're still suffering from the mobile browser fragmentation that web content developers have to deal with: Openwave, Obigo, Nokia, Opera (Mobile & Mini), Microsoft, Access, Blazer, Danger, Picsel, Thunderhawk, Novarra, etc... each with multiple versions, on multiple devices with a range of capabilities." (YAMB - Yet Another Mobile Browser)
There are a TON of mobile web browsers. None of them handle web pages in the same manner, or even support the same features. This, unfortunatly, makes development difficult for web developers. If a developer wants to support a popular web application on a wide variety of devices he/she must create a different version of the application for each device, or each class of device at the very least. Being able to condense the list of browser engines would make development easier on the web developers. This would also reduce the need for browsers to be inter-compatible. Having fewer engines would result in potentially less standards-incompatibilities which would result in less of a need to mock what the "other" browser does to remain consistent to the user (having all of the browser engines follow standards, and having standards cover as many aspects of web technologies as possible, would be the most ultimate solution. More will come below). The result would be few really good engines as opposed to many weak engines.
Unfortunately, there is always an opposing view. One that I see that is just as equal. The problem with having one or two engines is that you get a monopoly... And, the result is "we own the market, we will do what we want," including not following standards. This is bad. As a result, competition is non-existent and everybody must use the engine. This can get really bad for open source software and commercial software.
The goal is to find a middle ground. Many engines, but not too many. All the engines would be standards compliant and the standards would dictate as many aspects of technology as possible. This way, to the user the only difference is how the UI operates and not how the engine operates. Device manufacturers and carriers can then know that the browser supports the standards and then only needs to be concerned with how the engine handles resources. Competition would come through UI and resource management and not which engine works with which site, because all of the engines would work with all of the sites.
I will add a little bit more about defining mobile browser and desktop browsers and still remaining standards compliant next.+
posted by Donald C. Kirker at 11:23 AM
5 comments
