Well, for starters, web applications without internet connectivity are, at best, an inferior experience. Secondly, web applications are inferior in terms of both user experience and performance in all but the most trivial applications. Thirdly, developing for the web is actually at least as much of a pain, if not more so, than supporting native code bases for multiple platforms. The difference is that webdevs have shifted that fragmentation from the native SDKs and APIs into the webdev versions of the same thing (JS frameworks, browser support, etc.).

> For example we have a web app that syncs audio on any device running safari or chrome.

That's not a web-app thats a 'safari or chrome' app.

This is more or less a perfect illustration of the the issue at hand here.

The other way this illustrates a massive problem is the idea that we are supposed to be impressed by this functionality.

I'm not speaking specifically of the functionality that the grandparent poster used in his example, but just the general idea, for example: "Look at this classic console emulator, running in a webpage! (At 80% of the speed it would have run on a circa-1990s 90 mhz Pentium if it were a a native app!)"

To be clear, it is impressive when people create such things given the constraints, but (even ignoring the fragile compatibility problem between different browsers) when the platform you are using makes doing something that was impressive almost 20 years ago impressive (again) today, I'm not sure that's something we should all be that proud of as an industry.

>The audience is not forced to download an app and do a few other steps. It's just load URL and bam everyone's devices become a stereo. Many other ideas in this space can occur.

The same thing could happen with any sandboxed platform that allows code download from an internet resource -- even Java did it more than a decade ago (WebStart I think it was called).

For some reason (traction I guess) we did it through piling up of more and more BS into the web model (meant for documents), and leading into the current mess.

I mean, instead of the big guys (W3C style) getting together and creating a cross-platform sandboxed platform for native style apps (e.g with actual rich GUI widgets instead of just text entry boxes and text-boxes).

The irony is that each of the big guys developed a kind of its own half-arsed version of that, e.g Microsoft and XAML, QT and it's XML/JS thing, Adobe and Flex, etc etc.

Cross platform GUI widgets were possibly a good idea seven years ago if you didn't care about looking too good on OS X (still today, Qt applications look somewhat off on that platform). Today, they are a terrible idea, because every mobile platform looks different and if you try to make one interface for all, it will feel non-native on every one. At least if you use completely custom widgets, as HTML forces you to, it will be clearly non-native, not something pretending to be native but with the wrong behaviors.

I'm sure many people fundamentally want programming to be as close to write-once-run-anywhere as possible, and hence think this is a terrible state of affairs; for me, though, having different platforms with different, clear design philosophies is a good thing as it encourages people to care about and innovate in design.

Because the experience is not as good.

It's not as fast or as smooth or as fluid as a native experience.

It comes close, but there is a always a slight, yet perceptible lag.

In addition, each platform has specific strengths - and the LCD of web-enabled means that they can't be used.

What's the distinction? It also runs in Firefox yet the audio is out of sync (as of now). IE doesn't support the necessary tech needed.. Not yet at least.

Also the majority of mobile web users use safari and chrome anyway. Those two browsers to me are the mobile web.