Slashdot Mirror
Browser Wars Redux: This Time It's the Apps
itwbennett writes "Yesterday's release of the Amazon Kindle Cloud Reader brought to mind the bad old days of the browser wars, but with a new twist: while the app works on any iOS device, it only works on computers with Safari and Chrome. Blogger Brian Proffitt knows as well as anyone that 'this isn't a deliberate snub of the other browsers. Clearly the developers of this web app had to get it to work on Safari, because that's the only vector to get it onto an Apple device. And, since both Chrome and Safari have a shared ancestor in WebKit, it makes sense that what would work in one browser would work in the other.' But it raises an interesting question: 'If HTML5 and other web technologies are supposed to be open and standardized, then will web app developers have to continually tweak their apps in order to accommodate deficiencies or advantages between browsers, or will browsers have to constantly stay in sync with each other's features just to be able to run all the web apps out there?'"
It works in Steam too, since they also changed to WebKit. The in-game and Steam store browsers feel so much faster with it, too.
Google+ vs. Facebook, and why Google+ will fail
I'm not sure how "running it in the browser" is supposed to magically erase all the problems that in years past were associated with running in multiple operating systems. The more power and control is given to the browser, the more complex they become, and the less likely it is that different browsers will be able to provide the same experience.
This isn't "browser wars", this is "Operating System Wars, The Sequel". The more things change, the more they stay the same.
Any web "app" that aims to be actually useful will ensure that it can operate on any browser. Otherwise, we would be just as well off without the "app".
I'm just as concerned with the tendency of websites with 'mobile apps' to intentionally break their own website experience when browsing on a mobile device in order to push their native app instead. Deep links redirecting to mobile homepages are also breaking the web (from mobile at least). In many cases the web worked better on my iPhone 1 then it does today on my iPhone 4.
Clearly the developers of this web app had to get it to work on Safari, because that's the only vector to get it onto an Apple device.
So, Apple locks out downloading/running any other web browser? How come you didn't say "Clearly the developers had to get it working on IE, because that's the only vector to get it onto a PC"??
Since Firefox works on all computers, and has a higher market share than Safari, it seems that Firefox would have been the better choice.
It would seem that in this case at least it will be the web app developers tweaking for additional browser platforms.
will web app developers have to continually tweak their apps in order to accommodate deficiencies or advantages between browsers
WTF does the moron that wrote this link-bait turd of an article think they've BEEN DOING for the last decade+? If it wasn't IE's lobotomized and perverse interpretation of the W3C specs, it was mobile phones, new browser versions, etc etc etc...
In future, IT World may want to find writers who've actually had some experience in the industry to avoid moronic crap like this...
between competing vendors? Maybe standards that have been used for a decade have stabilized compatibility issues between vendors, but this is always a struggle and there will always be exception handling to provide a common experience across all platforms. I am not sure where the idea comes from that because it is standardized, it will be implemented equally and the same. Have you paid attention to the last decade of web development where standards have always existed. Unless a vendor has a mission statement that says that it will only implement a standards compliant product, then there is going to be competition to innovate new features. Hopefully corporations learned the lesson of tying their web apps to a specific platform and proprietary implementations, but I am sure considering the current trend to make browsers into OS like platforms, there will be apps that only work on certain platforms. Who knows what is going to happen in the next decade so this question is a little foolish?
haha...not first
What part of the code causes other HTML5-enabled browsers to fail? (I would try to figure on my own if only it did not require to sign-in onto Amazon, which I boycott because of their handling of Wikileaks.)
What do you mean 'the bad old days of the browsers wars?' As a web developer, I've never seen the war cease. It's continually a pain-point, and even more so with html5 video and web sockets.
The comment that they "had" to get it working on WebKit in order to get the Cloud Reader on the iPhone/iPad is probably correct - but it also seems like Webkit has been leading the pack when it comes to implementing advanced HTML5 features. Generally these features appear to get added to Firefox somewhat later (after someone files it on Bugzilla).
#DeleteChrome
Wow, this must be the first time that some content only works in a proper subset of modern browsers and is broken in the others. Until now, browsers have stuck to strict standards, so that developers wouldn't have to rewrite their code for the quirks of each browser. But I guess that's all over now. What a shame!
It makes a lot more sense for browser makers (which, by my last count, consist mainly of four or so major vendors... FF, Chrome, Safari, and IE) to have to keep up with novel web standards than for web developers (10,000? 50,000? 100,000?) to have to keep up with browser inconsistencies. Sure, there are places where the standards are inconsistent. This sort of shift will force the W3C to move faster to improve the standards, which is good news for everybody.
HTML5 is still a W3C Working Draft standard (see http://dev.w3.org/html5/spec/) and is still changing so browser developers are slow to spend effort implementing it. Even after it becomes an official 1.0 standard, some browsers may not implement parts of it for years, so some amount of browser-specific code (and occasional non-availability of some features on some platforms) will always be a fact of life when building Web UIs.
Sounds like the developers used webkit to render but didn't care if webkit was already present.? Why didn't they just optionally install webkit?
Good lord slashdot, I was hoping to see informed technical discussion like that slashdot of old instead of scaremongering gossip over motives for the Book Store compatibility. It has nothing to do with Apple controlling Amazon, or browser wars. The HTML5 database storage spec is not fully standardized, and so chrome and safari both implement the WebSQL spec while Mozilla has chosen to go with their own IndexedDB spec.
The book store will be ported to firefox shortly as both DB implementations basically accomplish the same thing. It came out for Chrome and Safari first because Amazon wanted to circumvent Apple's in-app purchasing requirements on the iPad and that meant working with webkit first. Down the line I am sure that browser makers will eventually converge on either IndexedDB or WebSQL and that will become part of the HTML standard but for now the discrepancy is explainable purely in terms of using a non-standard technology that browser makers are still experimenting with and trying to shake out.
After forty years of following technology, I assure you that wherever there's a land rush in progress, a compatibility clusterbuck is sure to follow. Early mover advantage is a broken window for everyone else. It's not actually the nature of the standardization process to be out in front of the gypsy caravan waxing behind the Spanish Galleon of zeitgeist redux. As much as we complain about this, the gypsies are a tribe of legendary endurance, hardship, and snark (as often featured here on snarkdote).
Standardization is the introverted naturalist's account of rats, cockroaches, raccoons, ravens, seagulls, and urban deer: what's left behind after progressive forces have eradicated the dodo, pillaged the cod fishery, and turned most of the polar bear population into shaggy rugs of bravado.
Considering that the spec is not finalized, why are you so surprised that browsers are't done implementing it all yet?
The 11th draft of HTML5 was released this month http://dev.w3.org/html5/spec/Overview.html
How about, instead of sniffing for the browser types you (think you) know support what you need, sniff for the features you need directly? That way your app will work just fine with any browser that supports what you need, and if it doesn't support what you need you'll be able to tell the user exactly what his browser's missing so he can fix it (it may be he just needs to update his browser, or install a plug-in or optional feature he hasn't gotten around to yet).
Really, this sounds like a great thing for browsers and the internet. When developers write things to a standard (HTML5) instead of insane-crazy-time (whatever the hell internet explorer 6 renders), everybody wins. If browser authors want market share, they are forced to pick up features. Even the IE behemoth appears to be realizing that some HTML5 may be critical to its long-term survival.
In the old days the problem was that IE had a monopoly, and sucked, so people wrote crap for IE and it continued the circle of suck. Now there are other real browsers out there, you really can't be sure what systems will run your page (especially in the mobile world, sure webkit is the big boy there at the moment, but not in all places and not forever), so the best solution is to write to the standard as much as possible and let browser authors it.
I know for the purposes of my personal page that's how I operate, I don't have time to QA every system configuration. I make sure it basically loads up on the big 3 engines and call it a day.
Ze Atomic Device! It iz Ztolen!
Pretty silly to complain about HTML 5 "standards" when the real problem isn't with the standards, it's with the implementation of those standards. That's why we have tests such as Acid, of course.
I will say, however, that the implementations of the browser standards for HTML 5 and CSS3 are SO much better than earlier rounds of the browser wars. At least it's not a complete nightmare as before. Where you find problems are in edge-cases such as websocket and threads for which there is really no workaround possible, you just have to wait for the browser vendor.
"We receive as friendly that which agrees with, we resist with dislike that which opposes us" - Faraday
I really loved Firefox, when it was much more advanced then every other browser (since version 2). But now it just lags behind Webkit. Gecko's implementation of CSS3 animations is just poor compared to Webkit's.
And don't get me started on mobile browsing... I think it's a complete waste of time of Firefox to come out with a mobile browser that only works in like two different handsets! If you're unable to make it work across the isle, don't waste your time trying to compete with the native. Opera Mini and Mobile already dominates that secondary place, masterfully.
The expectation that HTML5 would end compatibility issues is not only unrealistic, but completely ridiculous. Vendors and developers have extended, misunderstood, incorrectly implemented and violated standards since the web began, and a more complex and more powerful standard only offers more ways to do so.
They want royalties on your browser wars/standards argument.
You can deposit it in the account of one honorable Nelson Malambe, somewhere in Nigeria. Check your spam for the address and account number.
-R
They want royalties on your browser wars/standards argument.
You can deposit it in the account of one honorable Nelson Malambe, somewhere in Nigeria. Check your spam for the address and account number.
-R
(sorry for the double post, I accidentally posted as an AC.)
Reeses
Try the Atomic Web browser which lets you easily set the agent response as Mobile Safari, Mobile Safari - iPhone, Mobile Safari - iPad, Safari Desktop, Wap Device, Firefox 3, IE 6, IE 7, IE 8.
I only wish I could specify the setting per web site.
This is exactly why plugins (or plug-ins) were invented. I would much rather code this up in Flash or Silverlight and have it run reliably and predictably on all browsers than have to write a bunch of one-offs. HTML5 was a giant distraction, in my opinion.
So you need both Safari and Chrome installed? Or do you need them both running and displaying the app? Some novel approach to cross-browser development.
So you're saying the iPad is missing some basic capability that all computers should have. Hmmm, basic...
It's not as bad as it sounds...
Yes, web developers do need to support multiple browsers. It may be worse with HTML5, but when I was a full-time web developer, it wasn't bad at all -- I spent maybe an hour a week fixing crap so it'd work in IE7 (we dropped IE6, thankfully) and everything else Just Worked -- we'd develop in Firefox (since it had Firebug, since this was before Chrome was as cross-platform as it is now, and before its dev tools could really match Firebug), and maybe once or twice a month there'd be an issue where it'd work in Firefox, and fail in any browser except IE.
It may not have been a deliberate snub, but I can't imagine it being too much of a problem for these guys to do the same. Even IE is getting decent, to where they might've easily supported IE9, maybe 8, and drop 7 or below.
Then again, there is one new issue with HTML5, which makes things like this much more likely -- not all browsers support the same things. While there's a very large subset that works across all browsers, it does mean that we also have to think about multiple browsers in the design phase, not just in the testing phase. That's significant -- it means we need to research cross-browser issues, not just add a few more browsers to our test cycle and debug things as they crop up. And that is the fault of the browsers -- alright, if you insist on having two wildly different local storage APIs, fine, but every browser needs to have them.
Don't thank God, thank a doctor!
-webkit-
-o-
-firefox-
Is an incredible (and STUPID) pain in the ass, especially when a vast majority of cases just follow identical, standard-specified (though not yet "recommended candidate" status) arguments and behavior.
Yeah so I've been playing with HTML5 lately, Chrome handles about everything I've thrown at it yet. When I take my site to firefox or IE9 it just falls apart, Somehow I don't consider this a problem. for me the big thing is being able to use the tag. This is just so much easier then doing some sort of jquery it's not even funny.
Take a look at this:
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML5)
I would guess Amazon's done this for future insurance (in case Apple tries to further tighten appstore rules which impact Amazon), and to say 'Hey Apple, most of our customers would rather deal with a less usable HTML 'app' for their books than convert to iBooks'.
I'm a big Apple fan in most things, and a big fan of Amazon; they've got me locked into their store unless they behave really badly. I think Apple went too far telling Amazon et all 'no app for you if you have a handy link or interface to YOUR store'.
Lazy Dev != Browser Wars
Actually, I would think that if the browser is 100% compatible with the HTML5 spec, then it should work regardless of what engine the browser has. Developers should design to the spec and browser makers should be fully compatible, if not compliant, with the spec. Once again we'll watch and see who fully supports the W3C standards and who doesn't. My support and $ will be going toward those who at least are 100% compatible.
Firefox doesn't support offline SQL, while webkit-based browsers - along with the latest offering from Opera and IE9 - do. I believe that's the reason this webapp isn't targeted at the Fox. ::Leigh
http://www.else.co.nz/