That's the reason I really hope most of the software will be webbrowser-based in the future. I know that right now native apps give you a better overall experience but too often they pull you into the walled garden of hardware vendor.
There are solutions like phonegap etc. that let you write semi-native apps that use embedded browser inside it, but with HTML5 and successors I believe it will be possible to just have everything run in a browser, setting everyone free from any vendor specific solutions.
Still doesn't really save you unless you can export all of your data into some open data format that can be read hassle free by other services (oh and you need a guarantee that the company won't just kill their export functionality when they get bought by another company etc).
You also have to ask who controls the browser, this is going to ultimately be whoever controls the OS. iOS won't allow alternative browsers, not sure if Windows RT does?
So there's nothing really stopping the OS vendor with enough market share deciding they won't allow certain HTML5 / JS functionality incase it interferes with native app sales.
It might seem the case that one or two big ecosystems eat up everything else and choosing which ecosystem you live in becomes a major life choice. At this point computing and media have become a natural monopoly.
Depends what you mean by "alternative browsers". iOS allows alternative browsers but not alternative engines (in that javascript executed on-device has to be executed through webcore). Thus Opera Mini is a completely independent implementation (all of its interpretation and rendering is done on Opera's own server), though most alternative browsers (and there are many) are UIWebView wrappers with additional features.
What iOS does not allow at all is setting an other browser as default.
> not sure if Windows RT does?
It's unclear. It definitely does not allow JITs (WinRT doesn't expose VirtualAlloc or VirtualProtect), which iOS does not allow either, but I don't know if a JIT-less completely independent browser implementation would be allowed.
If there's no way to add features to the underlying core then it's not really much better than just an alternative browser skin. A JITless browser is not going to be much good for performance sensitive applications either.
This is enough power to enable the OS vendor to gag browser apps into being second class citizens effectively.
I think it all comes down to standards, as the OP mentioned in the article. Google services usually support open standards (ODF for google docs), which makes migrating your data, when the service closes, a whole lot easier.
If only there was an open standard for "offline" apps that could be used on android, iphone, iOS, windows, linux...etc with the same end user experience.
There are solutions like phonegap etc. that let you write semi-native apps that use embedded browser inside it, but with HTML5 and successors I believe it will be possible to just have everything run in a browser, setting everyone free from any vendor specific solutions.