What utter BS. You are essentially celebrating the victory of consumer commerce, not technology X over technology Y.

Think about it.

There never was any battle between the "Web" and "MFC, Java Applets, Webstart, .NET, Flash, Silverlight". Those thing survive & even thrive in places where nothing else would do. Do you really think everybody in investment banks & brokerages fire up their browser first thing in the morning ? 99% of what they did, do & will continue to do, will continue to be done via native apps - mostly C#, C++, .NET & Java apps. This is just plain reality. It isn't because they are lazy or don't grok the web. Processing realtime trading feeds isn't the browser's strength. Sure I'll show you an iframe with some ticker, equities blotter, trading tickets ...but that's just consumer commerce. I'm soliciting your cash - Here consumer, click on this Buy button, give me your money. After that ? Once you fire off your client request, that's when 99% of the task actually begins, and it ain't on the browser, no siree.

The web is just the tip of the iceberg. Most of the action is below the surface of the water, and that's not the web & will never be.

To your point - the whole idea behind Webstart, Java applets, Winforms, was to mimic the native UI on the web & try to offload as much client-side logic to the client's machine.

Turned out customers didn't like "fat clients" - they wanted textfields & simple input forms, accept their inputs & go away & process the inputs elsewhere.

We said - Hey, you guys have a fast processor & slow network, let's do this one-time applet download/Webstart download/Silverlight app download, & once done, we won't tax your network, we'll just tax your machine. I wrote one of the first equities trading applet for Goldman Sachs. It was a fat client ~100 MB, you actually waited 10 minutes for the install. But it did so much - all the trading rules validation, portfolio construction & computation, everything happened inside that applet. Once the applet downloaded, it felt & behaved like a native desktop app. It was so much more powerful. There was actual science in that applet. It took a doen CS PhDs to build the infrastructure for shipping that. We fucking got dozens of patents...pseudo-realtime trading applet over the web ha ha ha! Today, the interface is so dumb - zero download time - but they hit the network so much harder. Absolutely nothing happens on the client. To check whether a simple trade is valid, you have to hit the server multiple times during the workflow. Customers are ok with it because the network has gotten so much faster. They were downloading ~100MB applets on 56.6k modems, now they have superfast broadband, so it makes sense to hit the server more & do less on the client box. So you just hire an 18 year old & he'll build a polished web UI for the trading applet over a weekend. That doesn't mean all those CS PhDs just up & died. They just migrated to the server side, where all the action now happens.

So this isn't success of the web & failure of the applet - its success of broadband. Network penetration today is massive & ubiquitous. You can place million dollar trades over android. You couldn't do this just 10 years back. At that time, applets were state of the art. In hindsight, the whole exercise appears pointless. 100MB applets WTF, just use underscore dot js & ajax & broadband & a little bit of markup & your trading window shows up on a tiny 4 inch android cellphone. Yeah, true, but we didn't have any of that back then. Cut us a little slack, will ya.

It isn't celebrating to point out a reality of the world relative to a post that seems to imagine that every other solution was handicapped in the race. And it IS completely based upon technical merit.

"Do you really think everybody in investment banks & brokerages fire up their browser first thing in the morning ? 99% of what they did, do & will continue to do, will continue to be done via native apps - mostly C#, C++, .NET & Java apps."

Humorously I build software for the financial market. Our presentation tiers are almost entirely through web apps. The competitors I was talking about -- the ones who poured cement on their own feet -- went the "thick client" route. And we keep on iterating.

"The web is just the tip of the iceberg."

Yes. No kidding. I'm not building a database in the DOM. I'm not processing trades in JavaScript. This discussion is about the presentation tier. Every criticism of the web always holds that you could toss together something so much better in some illusory, never proven alternative, but that simply isn't true.

Kind of sounds stupid without 6 paragraphs filling it out, huh?

It won what, exactly? The war against Gopher for presentation of hypertext documents and information display? There's more to heaven and earth than data presentation and consumption.

The examples of genuinely great web applications are few and far between, if not near non-existent. Are Google Apps really the best the web has to offer?

Cappuccino provided one example of how to move the browser past the shackles of the traditional HTML/JS/CSS and into a world where developers could work with more accurate abstractions that actually represented the problem domains of application development.

This lesson has essentially been ignored, tossing out 3+ decades of experience our industry has in building applications.

The pop culture of web development strikes me as a spastic, young programmer who flits from framework to framework, always in search of some magic elixir to make application development more pleasant. They know it isn't quite right, but they don't want to give up the hard-earned, arcane JS knowledge they've used. Nor are they willing to sit down and admit that, maybe they need to sit down and learn a thing or two about how to structure programs better (as we all do)!

Instead, it's emotional blog posts and bikeshedding over inane topics (vim, Coffeescript), rather than looking at the deeper issue - the utter mediocrity of the tools they're using.

I am also a strong advocate of web apps and have been for a long time. Reality has proven out my position as, as has mentioned, the web won the presentation tier (clearly this has nothing at all to do with data processing or database or system programming or anything of the sort).

In any discussion on web apps they are always held against an illusory foe that is all capable and all perfect. Let's get specific however -- I love Rdio and love their web app. They came out with a new .NET client so I of course gave it a whirl.

Worse, slower interface. Constantly updating (in big monolithic chunks). Consuming hundreds of MBs of memory.

I'm not trying to criticize specifically Rdio, but I guarantee that initiative started with someone slamming the web and its crazy mishmash of standards, promising that they'd do something that would exploit the full power of the client. The result was something much worse, holding the single and only advantage of "not in a web browser" (for what that's worth?). Amazon has fielded various trials with various rich apps (they usually partner with Microsoft), but you've never seen them because they never have a compelling story, coming with enough detriments that it outweighs the benefits. My local library system used to have a whole nasty Java interfacing tool that was an absolutely abomination, with a horrendous rickety interface that seldom worked properly, was slow, and was a beast. They replaced it with a dramatically better web interface.

Those are all just anecdotes, but they're constant across the space. Yet every post pretends that the web is a weakling that has no merit and no advantages, completely missing why it has made all of these wins against endless competitors.

Sorry, you're going to need to elaborate here or else you're really sensationalist. Also, you can't be serious about the community not admitting we need to learn how to structure programs better, as if that were the only problem. I didn't learn that UNTIL I started working on the web.

Every good web application beats its desktop rivals simply by being ubiquitious. People who dismiss the web typically ignore this simple fact completely. But it's always been true, you can look back to 1997 when Yahoo Mail killed the desktop email client business not by being flashier or better (it had full-page refreshes over 56k modems, awful!) but because you didn't have to ever worry about not having access to your email again.

How Microsoft lost the API war: http://www.joelonsoftware.com/articles/APIWar.html

and

The Location Field Is the New Command Line: http://daringfireball.net/2004/06/location_field

Note that both of these articles kvetch about user experience and how the web simply can't compare to native apps, but emphasize that the ease of deployment matters more.

Also, note that the app store model obviates some of the deployment difficulties of native apps and makes it almost as easy to install native apps on the phone as it is to visit a web page.

I think this (desire for ubiquity/multi-platform) is the main reason I don't see eye-to-eye with the people who are pushing for web apps for everything. Web apps everywhere is great for large corporations that want to provide their service on as many platforms as possible. It's great for venture capital funded startups where the name of the game is to get as many users as possible and get bought out before your money runs out.

I'm a small indie dev though, I produce software (not software as a front end to a non-software business), and I'm not looking to become a billionaire (really!). I want to develop software because I enjoy it: to solve problems for real people, to solve my own problems. So really I don't care too much about being able to target every platform at once. I want to target the platforms I like, using the tools that I like, and as long as the platform has enough users to make it viable then I can do that with native software on open platforms (the latter is important and why I don't write iOS software, for example). There is the risk that the platform I target gets killed, but if a lot of people use it then that's generally going to be a slow process, and there is plenty of churn in web tech and standards anyway so it's not like it provides immunity to technological change. Additionally, I just have a hard time working with web technologies. I find them much harder to use, to the extent that if using html/css was the only way to write software I wouldn't be writing software at all and I'd go stack shelves in the supermarket instead. Maybe I'm just not smart enough to use them effectively, I don't know.

I guess this is partly the old 'software as craft'/'lifestyle business' argument, but it saddens me slightly that the big industry players are moving us away from the kind of industry where you can write software that interacts with some arbitrary bit of hardware in unsupported or unintended ways towards a much more controlled and profit orientated one (i.e. your software running everywhere being the most important criterion of all). Web people are not the only offenders here of course, but arguments against things like iOS have been well explored over the years.

Some people seem to view the web as some kind of beacon of freedom, the little guy fighting the big bad industry giants of Microsoft, Apple, Adobe and so on. But from where I am, the web is the big bad industry giants. Writing web software means being restricted to a very limited sandbox. The APIs available to me are decided by what a small cabal of powerful companies (Apple, Microsoft, Google, Mozilla, Nokia and maybe a few others) can agree on. None of their interests align with mine (why would they?).

If Gopher had taken off and supplanted native development to the extent that people were using platforms that could only run Gopher apps, would the current web even exist? All user facing software being written to a single standard and API has good things about it, but it also limits new ideas tremendously ("sure you can add X feature you just need to get it through this committee of industry heavyweights first and get them all to agree, and then wait for them to ship it").

What is important to me is that data uses open standards, whether at rest or in motion. If people control their data, and it is in open formats, then there is little companies can do to lock them in. Which is good for me as a dev since I can write software to help users work with that data. Web technologies don't do much to help me there, in-fact for the most part they have made it easier for companies to keep users data locked away on their server in unknown formats or behind proprietary APIs that I don't feel confident building software against. More concisely: email good, Facebook bad; FLAC good, Spotify bad.

I'm not arguing against all web sites/apps (or any hypothetical tech stack that offers a similar standard sandboxed environment). For some things it can be appropriate: wikipedia or hacker news or other inherently networked activities for example. I'd prefer something less byzantine of course, but I expect that if the web apps model does take off then ways of targeting it that mean you don't have to think about CSS or Javascript will get more traction, in the same way that I can write native code without having to worry about assembly (most of the time). Javascript as a compilation target will become "fast enough" on most hardware for general purpose things (not for absolutely everything, but that is just another manifestation of the problem of not being able to break outside the sandbox when needed). So the technical issues of css/javascript being horrible are not the main problem.

I come from a social science background, which perhaps taints my view here. I look for the power dynamics that limit my real world ability to do things, and don't really care so much about theoretical ideas about a perfect world where everybody works together in harmony to make the web a platform that does everything you could ever need in a timely way. My issue is about power: who controls the APIs that ultimately lets software control your hardware and data? With open native platforms the answer to that is anybody. With the web it's the tech giants alone.

My one point would be perhaps the way things are now is because it's good enough. Using the web and building for it is good enough for a lot of people, the speed bumps and systems in place are good enough for the majority.

But I do agree, we've gotten to a point where a handful of corporations dictate how everyone else get to do the neutron dance and that the bleeding edge needs to be examined and worked on so that change can occur.

I do my banking in a browser. I do my email in a browser. I manage photos in a browser. I manage relationships in a browser. I do my taxes in a browser. I order goods in a browser. I ship goods in a browser. I reserve items at the library in a browser. I watch movies in a browser. I listen to music in a browser. I push apps to my smartphone in a browser. I get directions in a browser. I find phone numbers in a browser. I phone people in a browser. I video conference in a browser...

I can go on and on all day. If you really want to argue that the web is a surrogate for Gopher, this conversation is futile.

I do many of these things in a browser as well, not because the experience is so great, in fact, most of the time it's pretty horrible. Banking, photo management or video conferencing in the browser a great experience, really?

I sympathise with this article, and even though web applications have come a long way, I'm sometimes amazed by the collective cognitive dissonance that seems to be prevalent among people who develop web applications, pretending that all is fine and dandy in web application land, and we've long surpassed the point where web applications provide better experience than good native applications. They are simply nowhere near, and the fact that e.g. Google Mail (which is a great web application) is considered superior to e.g. something like Sparrow is quite frankly very amazing.

It's a good example actually. Even considering the less pretty UI, Google Mail is superior to Sparrow precisely because it is web-based. From the user's side, the way it deals with spam and search are two huge functional advantages which would be difficult to impossible in a native app. And from the vendor's side, the ability to manage updates and monetise through ads are clear benefits which keep the program running.

You can configure Sparrow (or whatever native e-mail client) to simply connect to your GMail inbox and have all the spam filtering and search capabilities that GMail has. Even the default Mail.app on OS X and iOS (which isn't exactly feature rich otherwise) does this. As much as I like GMail as a service, their web front-end is actually the part I dislike most about it, which is why I almost never use it.

>> And from the vendor's side, the ability to manage updates and monetise through ads are clear benefits which keep the program running.

Well, first of all I don't like ads and I don't care about how service providers can monetize it because it's web-based. I'd much rather pay a monthly fee for the service and/or a one-time price for the app, than having a web UI full of crap I didn't ask for. Not a very strong positive for web-apps. As far as updates are concerned, I understand that a web-based service is much more flexible in that regard, but then again, it's not really hard to have self-updating native applications either.

For that matter, why are you equating 'the web' and 'server-side'? The standads IMAP protocol stores messages server-side while also enabling effecient server-side search. The standard managesieve protocol implements support for managing server-side filters from remote clients. Tools such as SpamAssassin perform intelligent per-user filtering server-side.

At that point, the only real differences between webmail and native clients are:

- UX

- Native clients use standardized protocols by default.

Even though it caches all e-mail locally, works offline, and it is a native app?

I'd be interested to hear how those tools stack up against their native (or cappuccino) counter-parts, because implicit in your argument is that all these attempts to extend the web into the application space are better (and have 'won') over traditional approaches to application development, which I can't say has been my experience, even for the 'best-in-breed' solutions such as Google Apps.

Personally, I've found the surge of interest in native development via mobile to be invigorating, since it has meant a resurgence in applications that put user experience ahead of dogma (or even cost). I can hope that this continues to carry over to the desktop and other spheres over the next 5 years.

For many web-based tools, there aren't cappuccino/desktop analogs. They just don't make sense.

I could manage my photos in a browser, but I won't do "photoshopping" in a browser.

I watch movies in a browser, but I don't edit my home movies in a browser.

I listen to music in a browser, but I don't record or mix music in a browser.

I push apps to my smartphone in a browser, but I don't develop smartphone apps in a browser.

In general, I communicate or consume in a browser, but the worthy things - the creation - tends to happen outside of it.

Also, don't forget that all the things that consumers might ever see are just the tip of the iceberg - the vast majority of software and hardware development is done not for B2C apps/websites but for solutions that are B2B, business-process-internal or hidden in an appliance, never seen by any consumers.

That browser will probably look less like a browser - since it does everything, it doesn't really need a window.

*Except for your bank doing your banking. Of course it will be offloading the work to a dedicated application. The rest, however, will be browser-based.

But I don't like doing everything in a browser. All the things you mention are transactional, but when I'm (say) writing music I much prefer to be in a native environment because the transactional stuff is a much lower priority. It's distracting, for many tasks. At the very least, I want to run some things without a browser frame of tabs, URL bar and so on without necessarily doing so in full screen mode.

Have you ever tried a Chrome Platform App? They don't have any browser chrome--they're just regular app windows, painted with whatever the developer likes--but they're still running in a browser. Sort of similar to Air/Silverlight.

Do you know why? Because the browser version sucks ass compared to the native version someone has designed for a phone UI. It makes me sick every time I pick up my phone to transfer money in my bank account while I sitting at a computer.

Today, almost all that development has moved to the web.

>And they all fell by the wayside. They lacked in features. They lacked in agility.

No, no and no. The web "won" because its simple and the lowest common denominator was good enough for most people. The web has always been far behind in terms of features and agility (depending on what you're trying to optimize when it comes to agility). The web won solely because it was "open" and every company had a stake in ensuring no one company could sustain their monopoly. The web sucks and it did not win on its merits.

There is no one right way to build an app for the web the way there is for Android or iOS. That's a problem for both the applications authors and users. Cappuccino attempted to solve that problem in a way that did not appeal to programmers, it seems. jQuery UI succeeded to a point, and now Bootstrap seems to be the framework of choice. Perhaps a widget-based UI framework that can target the desktop and mobile devices would make sense.

The other big problem we have is that we're stuck with this idea of having cute little icons to launch things. Why can't we have icons that just launch a specific URL? Because then App Stores wouldn't make any money then would they?

Edit - Would someone care to explain their downvotes? Surely HN users wouldn't think to use a downvote to express that they just disagree, right?

That's what iOS 1.0 did. There were no native apps, just web apps that had cute icons that launched a specific URL.

People tried very hard to make that work. It didn't. The breadth and depth of mobile applications we see today only occurred once Apple provided a native SDK.

The reasons for this are simply technical ones.

Besides that, why take away the ability to create webbased apps? Could we not have the option if I know I don't care about any of the fancy stuff. There are so many apps out there these days which are just shells of an app with a WebView inside. It feels a bit ridiculous to have to buy Apple hardware to make a shell and then use our preferred dev environment to develop the site/internals of the app.

There were plenty of discussions about HTML5 vs native mobile apps. Big companies like Google and Facebook extolled HTML5, partly because they needed leverage against Apple's stronghold over the dominate ecosystem. So yes, the decision was a business one to begin with.

Then when reality didn't fit their agenda they've all since switched positions in 2012. Facebook rebuilding their iOS app with Obj-C, for example, to be as fast as possible. So then the decision ultimately became a technical one.

Maybe it'll flip flopped around soon. We did go through a period in the 90's when CD drives came out and everyone rushed in to deliver as much multimedia content on CDs as possible before that industry died and gave way to the ubiquity of the Internet.

In the future, smart phones are the CDs.

    >I feel the true 'reboot' and memory loss happened with native mobile apps. How did we ever think this would be a good idea?

Unfortunately, this argument (which tends to imply technical excellence should trump all other factors in the success of a technology) has been used in technology for a long time, but frankly, in the end doesn't matter.

Ask Betamax, OS/2, etc, etc.

But I think the open web will win in the end, not because of any inherent technical advantage (in some ways it's behind native apps still in terms of performance, look and feel etc), but because the open web has so many advantages for developers and users that in the end it will overcome its disadvantages. Performance and UIS are improving constantly on the web (contrary to the opinion of this poster), so the gap is narrowing. At some point the performance won't matter, offline web work will become possible, the network will be fast and ubiquitous enough and the advantages of the open web will come to the fore.

As a developer of web apps and mobile apps, the contrast between deploying a few fixes a day to a website, and working hard on new app versions only to have them rejected by an anonymous gatekeeper at Apple, often for inscrutable and unjustified reasons, then waiting days or weeks for approval, could not be more marked. Things are easier on the desktop, but there are still far more hurdles to deployment, and that matters a lot, as you hint above. The only thing I really miss on the web is a great language to script web pages in, but that will come (js is not my favourite language), and you can use any language you want on the backend, and no-one need know.

As a user, the advantages of the open web (i.e. not walled gardens like Facebook) will I think have an irresistible pull - advantages like linkable, shareable content, content on any device, even unforeseen ones, not having to rebuy apps but just subscribing once and accessing content from anywhere. The fact that the web is not controlled by a single vendor as most commercial operating systems or devices are is an added bonus.

Finally, I'd argue that the radical simplicity of web technology is actually its greatest strength, as it means it can be deployed almost anywhere, even with limited resources, and give at least some value to users for decades and over any new devices which come out, as opposed to the binaries being created for current platforms which in a decade will be forgotten or dumped by their vendor in favour of the newest flavour of opendoc, .Net, whatever... I find it fascinating that the web delivers consistently better results by virtue of keeping the tech simple and backwards compatible.

Worse is better after all.