The shocking, unprecedented, world-changing difference that the web brings is that on the web all you have to do is click a link and your computer downloads, "installs", and runs a program. No manual installation necessary, no upgrades, no installers or wizards. No delay. This process is safe -- the page is sandboxed and can't interfere with the rest of your machine. And these things can be instantly shared! All I have to do is paste a bit of text to my friends and it turns into another clickable link that's only a touch away.

Engineers frequently undervalue this feature, especially considering the things that the web give up in order to achieve it. So yes, it's a pain in the ass to get that div to align correctly but in exchange you get to run instantly and almost everywhere [1].

Relevant: http://xkcd.com/1367/

[1] Depending on your target audience, old browsers might be a major problem (China), but the browser landscape is rapidly improving in terms of a minimum expected set of features.

That's the theory.

The practice is that

- you give your precious data to third parties

- that the safety problem now shifts from keeping your computer safe to keeping data in the hands of third parties safe (and this does not always play out in the way we would like, see codespaces for a recent example)

- that even the client side safety is a problem, the 'distribution advantages' have also been recognized widely by the blackhats.

- that we end up being tracked from here to Tokio and that the web is rapidly turning into a series of silos that try to have as little as possible to do with each other.

- that the final experience is almost always sub-par.

The theory is fantastic, but the practice leaves much to be desired.

But in practice it is much better than any alternative multi-platform instant software installation ecosystem. And in practice, it has led to a thriving ecosystem of applications, most of which can link to each other and will work on a large portion of users' devices.

Yes, absolutely true. But I can't help thinking that there must be a better way to achieve these goals than this mess we've made.

We're clearly in 'we should be amazed the pig dances at all' territory rather than in 'look how good the pig can dance'.

The better way would have been for the open source community to advance the Linux desktop in the way that OSX has been evolved - i.e. To gradually bring the advantages of the web back to the OS.

But if OSX has evolved that way... Why not just use OSX?

There are no other dancers; there are only pigs.

Giving data to third parties is a side effect of networked applications, not web apps specifically. Whether the client is in a browser or a stand-alone native app, if you give it data, it will pass that data back to the application servers.

I think it's both good and bad in theory and both good and bad in practice. Certainly most of the things you list are major downsides, but none of them keep the upside from being (IMO more) major.

I'm you're right that the experience is "almost always" sub-par. I would say "often", but not even "usually". I guess YMMV.

> I'm you're right that the experience is "almost always" sub-par. I would say "often", but not even "usually". I guess YMMV.

There aren't actually many fair/accurate comparisons around since most companies have either a shrink-wrapped product or a webapp. Rarely do you see both, and when there are I agree with jacquesm that the experience is almost always sub-par on the webapp [in comparison to the desktop app].

You can't really compare one company's webapp to another's non-webapp. i.e. you may feel GMail is better than Outlook, but since Google doesn't make a non-webapp version of GMail we don't know if that would be better than both Outlook and gmail.com. Microsoft does make a webapp version of Outlook, but I don't think many people find that better than "real" Outlook.

Google does in fact make a non-web version of Gmail. Gmail.app for iOS and the Android port of gmail. Both of which are a MUCH better experience them the comparable mobile web apps.

Apple's iWork suite is an example where someone is at least trying to make applications that run equally well within the browser, on mobile and on desktops.

> The theory is fantastic, but the practice leaves much to be desired

Ok... What is more fantastic for:

- large audiences?

- users who can't install/update software?

- " " can't/don't back up data?

- developers who don't have the resources to target multiple devices/platforms?

- integrations with other applications?

What's fantastic is your use of " on the Internet. First time I've seen that.

You mean you saw something new today? Now that's fantastic!

that the final experience is almost always sub-par.

I have a Gmail account and a work one that is on Thunderbird. Gmail's through the web is just overall better than Thunderbird and I usually get people to send work stuff to my Gmail account.

I hear these comments about giving precious data to third parties all the time.

But I don't hear many people talk about trying to improve it like some others are doing with remotestorage.io and byoFS or Mylar.

Indeed and I don't understand why many other developers poo poo web applications vs native.

For example we have a web app that syncs audio on any device running safari or chrome. When we demo/ turn a crowd and their devices into a stereo..we just ask them to go to X URL.

They load it up in their device and the host hits play. 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 web and what you can do it with current day isn't as hobbled as many think!

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.

So, which browser has a perfect sandbox for everything it does? I like the sound of it. I wonder why they don't employ those same skills to secure other software.

You trade browser lock-in for OS lock-in. The original Internet Explorer strategy. Fundamentally it is a rent seeking strategy. When I noticed that Google was up to paying a billion dollars a quarter for traffic I realized that in some ways the gold leaf was falling off the piazza and revealing the the ugly plaster behind it. My guess is that the rent seeking here is in the form of directing search traffic in some way.

Browser lock-in?

What makes you think web applications made with this kit work only in Chrome?

So understand I've got a bit of history here, back in the old days I was working on Java/HotJava and the whole applet thing. Netscape was doing their own thing with what would become known as Javascript. Our vision was "Gee everything that runs in Java can run anywhere, regardless of OS or device etc etc." its a great vision. In the nearly 20 years since since Java pushed out the door (March '95, best of times and worst of times :-) this has never worked. Not for Java, not for Javascript, not for C#, not anything. Certain browsers work, some don't, there are quirks everywhere.

The default defensive strategy is to pick one browser you know work and select that as the 'standard.'

Not complaining just noting the lock in is an emergent property.

I think that to some degree the lack of certification for browsers (and ditto for Java runtimes back in the days) is what is causing this. Write-once-run-anywhere became Write-once-debug-everywhere.

Java seems to finally start to deliver on this promise though, the last few years have seen quite a bit of improvement. (Still far from perfect though, just the other day I was fighting some corporate website that insisted I install a certain version of Java in a certain browser in order to be allowed access, and it crashed in terrible ways when I finally did gain access).

Imagine that your browser simply wouldn't be allowed on the web until it conformed to a standard. Just like cars aren't allowed to go on the road if they do not conform.

This is unlikely to ever happen for various reasons and I don't think it would be a good thing but the number of broken implementations and hacks-that-became-standards is too large to even count by now.

Didn't J2ME have a certification process? That was still a hot mess to develop for.

One of the core values behind this project is that it should work extremely well cross-device and that most definitely means on devices where Chrome isn't the primary browser. During development we've ensured that we test on Firefox OS, Windows phone, iOS and browsers other than Chrome which run on Android. I want to give people something that they can rely on. Chrome isn't the only browser in the world for sure :)

Looks like browsersync is a Chrome only proprietary feature.

http://browsersync.io/ - at least the server side seems to be open.

Nope. This is a chrome feature that just happens to have the same name as that site. There is no connection.

No, it's http://browsersync.io/ - the readme links directly to that site: https://github.com/google/web-starter-kit#features

I stand corrected. This is a design-time tool. I mistook it for the consumer feature of the same name.

I don't think he means locked into a single browser, I think he miiiight mean "generally locked into using a computer at the level of a browser vs. at the level of the OS." As in, "your mom and uncle will buy a web-browser, they won't buy a computer."

Correct me if I'm wrong :)

I don't think so. This is the sentence he replied to:

"The only plus I see in all this is that in the end we are now free of the API lock-in that OS vendors traditionally required"

The discussion here is about APIs that are specific to Apple, Microsoft, Google etc.

Exactly. This all leads me to wonder if work can't be done to take the good web concepts and back port them to the operating system level, per the ideas I've briefly touched on in these two prior comments:

https://news.ycombinator.com/item?id=7917921 https://news.ycombinator.com/item?id=7891913

edit: the two drive-by downvoters are invited to elaborate on how this comment could be improved or what they disagree with so vehemently that this merited downmodding.

That almost reads as a re-invention of the java applet.

I've seen many and worked on one in the late 90's that could out do any HTML5 app I've seen or written. We did it with cohesive API's of the caliber of Windows API but multi-platform and web transparent. Those who wrote off applets will not be looked upon favorably by history.

I wrote a powerful database GUI as an applet, to pick up an update all the user had to do was save their work and hit the refresh button. I used Symantec Visual Cafe.

So? If the Java applet was not proprietary, slow and crappy, and if Sun got GUIs and applications, it would be a good thing.

And none of the above are necessary elements of a reinvention.

In fact, it's the current web one-page-app mess that is a re-invention of the notion of the Java applet warts and all: it's slow, has crappy GUI support, and it's a mess to develop in (like Swing was over-engineered crap).

We could use an actual sandboxed, "runs code from internet resources" platform, that contains the whole stack rethought and simplified.

Like they say, there are no original ideas. At some point the W3C needs to give some serious thought as to how to do applications on the web the right way. That's roughly my wishlist for the future.

What prevents Chrome from running a simulator of Android, and web pages to embed an Android app that will execute, replacing the web page it came from?

That would be exactly like the Java applet, except with a much better API (and touchscreen laptops would finally make sense).

That is a very interesting idea.

As usually with interesting ideas someone beat you to it:

http://www.appcelerator.com/blog/2014/01/browser-based-emula...

downvoters might have been too busy to actually consider the depth of the concept.

I would just suggest that it sounds like what Win7 does underneath the surface with the thousands of real-time Registry operations.

That sounds bad, but I'm sure it's chaos because the operations all grew by accretion, not by selection, as your suggestion to backport good web concepts indicates.

so.... What are the most likely candidates? What's ready? JSON? WebGL? A SQL interface to the Registry?

It is a very interesting question to ponder. If you see the web as a logical progression from email->newsgroups->gopher->www then clearly what was missing were the missing links. Once we had those everything else grew exponentially. But the web was clearly not intended to become an application platform. At the same time now that it has become an application platform we are facing a difficult choice: stick to incremental improvements and all kinds of hacks to shoehorn application interfaces into a document model (an awkward fit at best) or, alternatively to see where that progression could go next. How to preserve the 'link' feature and the advantages of the web while addressing the gap between native apps and web apps, improved user privacy and security, less reliance on verticals.

That's a very tough nut to crack.