The End of the Web? Don’t Bet on It. Here’s Why

Posted on Dec 19, 2011 | 111 comments

The End of the Web? Don’t Bet on It. Here’s Why

Fred Wilson recently posted a great video on his blog with the CEO of Forrester Research, George Colony. The money slide is the graphic below.

The chart shows three scarce resources and their improvements over time. The top line is available storage (S), the middle line represents processing power (following Moore’s law) or (P) and the bottom line is the Network (N).

In it he asserts that the web is dying and in its ashes will see the rise of the “App Internet.” The App Internet is different than the HTML Internet (aka The Web, WWW and in the mobile arena “The Mobile Internet” or short-hand HTML5) because the “presentation layer” and “client side” functionality are defined by applications that run on your mobile device and connect into the open Internet back-end to exchange information with other web services.

He’s right about this. But only temporarily in my view. And while the App Internet is currently more powerful than the Mobile Internet it has fundamental flaws. It isn’t open in either its standards or in the way that applications are marketed and distributed. I will cover this in my post.

Colony’s presentation is intriguing (and worth a watch if you have a few minutes) because I love to see when informed people make arguments that are different than you ordinarily hear (and different from my own views). In the end, my bet is that George’s bets will largely prove wrong. This blog post lays out my case. If anybody from Forrester reads this I hope they won’t see it as an attack on George’s presentation, which I found enlightening, well argued and interesting. My views are just a data point in the debate.

In the end, Seth Godin’s comments on Fred’s blog post said it best:

“His black swan is showing.

The problem with just about every prediction made by industry firms like Forrester (all the way back to 1985 when these firms said that the Commodore 64 was going to change the world–until the VCR interrupted to become the next big thing) is that they are based on sophisticated analysis of what’s in the rear-view mirror. 

A tough way to drive.

The trends are legit, but we have no idea what unexpected breakthrough in human interaction is going to change everything.”

In other words, nobody can really assert authoritatively what the future of tech or the Internet will hold. I have some educated guesses.

George’s Arguments

1. The web is dying and will be replaced by “the App Internet.” He says that since storage & processing are growing at a much more rapid rate than the network we’ll be at a point where not having apps on devices will greatly under utilize the power of the devices in our hands. In other words, our mobile devices are all powerful and the network that they connect into sucks.

2. Social networking is peaking. He cites that we have reaching a saturation of social networking in which nearly everybody is already using social networks (85+% in most developed countries and in urban environments in the developing world) and the amount of time dedicated to social activities already exceeds many other important tasks such as exercise and is even approaching the same amount of time we dedicate to child care. He argues for a world he calls POSO (post social) in which we will only use social applications which drastically cut down our time involvement and/or increase our productivity.

3. Social media will be pervasive in the enterprise and is primarily driving by customer interactions. He shows data that the overwhelming majority of major enterprise in the US is currently adopting or looking to adopt social networking technology. When asked what their objectives are they cite some form of “improving customer communications” by a long margin.

A (Very) Brief (and Selective) History in Computing
To understand my perspective you have to rewind to the late 80’s / early 90’s in business computing. As a software developer I wrote code on what was called a “dumb terminal” because it literally had no processing capability. It is the opposite of the world that Colony describes. The local computer had no processing capability, the network did its job and the central computer was the master.

We wrote programs that existed solely on a centralized computer (a mainframe), all of our data was stored centrally and all processing was centralized. When we wanted to compile our programs (turning human programming language into an executable file that the computer can read) we had to submit them to the mainframe and wait for them to be processed in sequence along with everybody else’s code.

In busy times compiling a program could take more than an hour, so we obviously didn’t submit often and if our program had errors and was unable to compile it was devastating. Things got so bad on one project that we ended up doing split shifts with teams of people programming from 8pm-6am and the next team arriving at 8am.

Throughout the 90’s the PC became much more popular in corporate environments, so companies began to replace dumb terminals with PCs. We ran software on the PCs called “terminal emulation” that allowed us to act like a dumb terminal to interact with mainframes and to act like a PC (with word processing, spreadsheets, etc. the rest of the time.

In this era the computing model known as “client / server computing” was popularized. What this model said was that since we now had really powerful processing on our desktops we should split the computing responsibilities between the PC (the client) and the mainframe (the server). Initially the computer did basic functions like “screen validation” (making sure that you didn’t enter non-sensical data into fields, for example) and could take over functions like compiling your software code so you could check for errors before submitting it to the mainframe.

Over time the PCs began to do more and more. They took over the “presentation layer” of computing. As a society we got used to the windows metaphor of computing. So suddenly we had “drop down” boxes that gave us multiple choice selection of data, we had dialog boxes that would prompt us with “Are you sure you want to proceed? Y/N.” This initially took on what was called “thin clients” because the server did most of the work.

The more the processors on our PC improved, the more we expected our PCs to do and everybody gushed about this new era where we had much better user interfaces and we had way more individual device power. Centralized computing was giving way to smart, distributed devices.

Sound familiar?

It was wonderful. For 5 minutes. Then the unintended consequences started cropping up.

  • How much data was acceptable to sit on local devices? Few had considered what happened in a world in which the data was distributed. Suddenly you had security risks, confidentiality problems, privacy concerns (think about your medical records being distributed), etc.
  • What happened when you submitted a processing request to a central server (think, I’d like to transfer money from my bank to yours) but the transaction didn’t complete? You could be in a situation where your local computer had assumed the money was transferred and it wasn’t. We had to develop whole frameworks of “middleware” to deal with this problem. We had to come up with “two phase commits” and “rollbacks” and other data tricks to keep our devices in sync.
  • We started to realize that that most expensive part of computing was actually manpower. Manpower to develop all of these applications, manpower to maintain them, and manpower to deal with all of these devices, which added great complexity to our IT environments. For example, on any software upgrade for a typical client/server enterprise package it would take up to 50% of the overall development budgets to deal with testing the software in heterogenous environments.

So having powerful devices with decentralized computing is not always a panacea.

Enter the World Wide Web (WWW).

As George appropriately describes in his video, the Internet and the Web are two different, but related things. The Internet represents what you might think of as “plumbing.” It defines how data gets moved around on networks, how files get located, how files get transfered between devices, how packets of data get sent via routers, etc. The WWW is the presentation layer. It’s central standard was HTML (hyper text markup language) that described how we would show data on computer screens.

When web browsers (the programs that can read and interpret HTML) were popularized they were “dumb.” It was literally like returning to the old days of computing. On the Web almost all of the processing was centralized and your browser was your input / output device. As an example of how dumb they were (for those that don’t remember) whenever you changed one field in a browser-designed program the entire screen had to refresh. It was a terrible user experience.

But for software developers like my company the web was a blessing. We were able to crank out software code at a much greater pace than was ever possible for. We designed our code and tested it in a Firefox browser and once we had working code we then had to figure out how to make the clunky Internet Explorer work. But the heterogenous environment was practically eliminated. We didn’t have to worry about which computer you were on. we didn’t have to support 3 database types, worry about network configurations, etc.

We flirted for a brief period with building some client-side applications (mostly for offline use) but abandoned those efforts when we realized how much overhead it took to maintain – especially as we release new versions of our code and had to always keep the local, offline software in sync with our releases.

We adopted an ethos that all of our development would be web only and that eventually browsers would become more powerful and make the user experience much better. And that’s what happened. A series of standards emerged known as “AJAX” (asynchronous javascript and xml) that gave the web-based designer much more control over the browser. Suddenly you could update small portions of the browser without refreshing the whole screen.

AJAX was one of the major drivers of the “dot com renaissance” that became known as Web 2.0. As people realized streamlining client-side development really matters to cost-effectively build software, new tool sets emerged to streamline the process. Libraries like jQuery have emerged that lower the effort to build front-end code.

Web & Social Change the Landscape of the Web

Prior to the popularization of smart phones and Facebook we were in a pretty good place on the Web. The one big concern many people had was how to constrain the total dominance of Google. Every startup (every company, really) was beholden to the traffic god that was Google search. One change in Google’s algorithm and whole businesses could be wiped out as chronicled in this excellent book by John Battelle called The Search.

The growth of social networking (er, the growth of Facebook) along with the growth of the iPhone have changed the landscape dramatically.

In this chart from Silicon Alley Insider you can see the first major trend to affect the open Web – the growth of Facebook. And Facebook’s popularity has only increased in the past year.

Why does the rise of Facebook affect the web? Because it isn’t a part of the open WWW. Facebook exists behind a walled garden. You need to log in to use it. Content or software developers who want to build products that work in Facebook have got to develop inside of Facebook’s framework rather than working on open, Internet standards.

Brands, celebrities and even individuals like you who produce information inside this walled garden are subject to the rules & conditions set upon you by a private company – Facebook. This isn’t a case against Facebook, it’s just a statement of fact.

As more people consume Facebook pages, less people are consuming open Web pages.

I wrote about this previously here and spoke about it on YouTube with Howard Lindzon here & here. (if you’re not that familiar with the topic it’s worth a 20-minute watch)

Is the App Emerging as the Winner?
The App Internet had a clear advantage in the past few years. Why? Because the mobile devices had a series of new features for which mobile browsers were not optimized. Examples include the camera, GPS, the accelerometer and the small screen sizes.

And importantly when developing games that require high-end graphics to handle game play you need to make use of the iPhone’s PowerVR GPU (graphics processing unit).

So Apps were inherently more powerful than browser-based applications.

It also had two other huge advantages.

1. Apple had a mechanism for charging users for apps and because most people already had an iTunes account it was simply 1-click to purchase an item. This meant that small teams could create games and make real revenue whereas on the Web this was much harder because you either had to build (or license) your own billing infrastructure, convince consumers to get out their credit cards (which they don’t like to do) or you had to sell enough advertising to make it worth offering your product.

2. Apple had a store. For early game developers this made it easier for your application to be found on the limited “shelves” in the iPhone App Store. Now that there are MANY more apps out there – this isn’t such an easy game. But in the early days the App Store was very appealing to new entrants.

Round 1 clearly goes to the App Internet.

Will the App Metaphor Hold for Mobile?
This is where my disagreement with many starts. I think the allure of Round 1 has convinced people that in mobile, apps are better. I’m not so sure.

1. Workarounds are developed. The surest sign of a market inefficiency is when solutions emerge to help developers get around the bottlenecks of platform development. This is what is happening in mobile. Developers are now able to build apps in native languages such as Javascript or HTML5 that can run in multiple platforms.

There are companies that develop “wrappers” that in essence handle all of the functionality needed to control each individual device that “abstracts” the programmer from having to build in device specific code. Some of the companies that do this include PhoneGap, Appcelerator, Strobe and RhoMobile.

2. Browsers will catch up. Just as in the first round of the web when everybody complained that web browsers weren’t powerful enough to build applications on, many of us believed that open systems would win. Eventually standards will emerge that will make it easier to build natively into browsers. Effectively either the wrapper developers become browsers or the browsers build wrappers or the two groups merge.

Also note that AJAX finally took off when Google open-sourced a bunch of its internally built AJAX frameworks. I wouldn’t be surprised if big innovations from Facebook and others in the mobile web eventually see there way into open-source mobile initiatives.

3. The costs of multi-platform development are too expensive. The costs for developers to build for multiple platforms is too great, the gatekeepers are too powerful and the outcomes ultimately limit innovation as happens in any system when a few players are a choke hold on distribution.

If you want to do a deeper dive on why I believe this is bad overall for the system despite the short-term allure of iPhone’s beautiful products please see my post “App is Crap, why Apple is bad for your health.” And before Fanboys slam me, please note that I own 3 Mac laptops, 2 iPads, 5 iPod devices & Apple TV. I love the products. That doesn’t mean I think it’s great for our future as an industry to have a close distribution system.

4. Distribution becomes a stranglehold. Fred Wilson talks about this in his “mobile gatekeepers” post. The early allure of empty shelves in the App Store is making way to the over-crowded shelve (currently tallied at more than 500,000 SKUs). This leads to all sorts of games by developers to get into the rankings, most of which favor companies with more cash.

Also, whenever we see distribution strangleholds we tend to see slower innovation and more resistance by the distributor to change. Think about the following examples:

  • mobile phone companies who controlled our crappy phones prior to the iPhone breaking that hegemony
  • cable & satellite companies who have controlled our paid TV through set-top boxes that make it impossible for innovation on the TV set
  • radio stations that controlled the music we listened to until music could achieve wider distribution on the Internet

Choke points are never good for innovation.

5. Data, data, data. Just as when we first went from mainframe computing to client-server computing we forgot that data leakage and data management across multiple devices is a big issue. The App Internet creates the potential for many more data issues. That doesn’t mean they can’t be solved, but it’s not as easy as saying, “powerful apps on our mobile devices is the best answer.” More power, more distribution = more data problems.

6. TCO. There is an acronym we use in computing called TCO or Total Cost of Ownership. It is often used in ROI calculation on projects to estimate a build vs. buy decision. Often people who build apps internally at their company calculate only the costs of the initial build rather than the total costs of maintenance of the project. Maintenance often greatly exceeds the development costs when you consider both human costs of maintenance plus the loss of productivity of not having an app that innovates as fast as the market solutions do.

I think there’s a TCO argument to be made against the proliferation of the App Internet. The more companies build their own apps, the more maintenance work they’ll need to do, the more employees they’ll need to maintain their apps and the further the innovation drain. I know this is a harder concept to quantify and intellectualize but I’ve seen it first hand in 20 years of working with large corporation on “legacy” IT projects. The App Internet opens the door to many more legacy apps.

This argument never features into any young developers mind because it takes years to see the decaying effect of legacy infrastructure in corporations (plus, many app developers prefer the sexy world of consumer apps).

To be clear … I think that the App Internet won’t disappear overnight. I also think certain apps will always be more effective built natively. But the same is true of today’s non-mobile computing. Still, most apps need not exist. Long live the Mobile Web.

And What about Colony’s Assertions about Social?
I’m going to save that for a future post. Coming soon.


“If I had more time, I would have written a shorter letter.”

Marcus T Cicero

Sorry for the uber long post. Given more time I could make it concise. And I’d have fewer typos. But I valued getting my ideas out there. If you think there are any inaccuracies I’d be glad to meet you in the comments section and I’ll gladly amend any mistakes (rather than differences of opinion)


    I would disagree. But two different view points (yours and mine) are always a good thing.

  • Mike H

    Yep, only have had my android phone for 4 months and already replaced some apps with mobile page bookmarks. Used to have a weather app installed, now just use mobile web site – it is just as quick, and I don’t need to know the temperature all the time, just in relevant bursts.  Though as a developer (first on desktop, then migrated to web) I wonder if the same cycle of security concerns will take place moving from apps to web as we saw from desktop to web? For some compelling ideas, you need a lot of access to the phone OS. But eventually that works out. Gmail notifies me of new mail just as nicely as Outlook did. And why would I install an app that I didn’t use daily and mostly presents data (weather, sports, news, social, stocks…). 

  • globetrotter

    This is the view of a developer writing certain kinds of code. The answer is more complex. There is no yes or no answer to browser vs app internet. 
    The browser is good for interactive documents, where the core of the experience is a rich document, but with some twists and turns in terms of additional logic to make the document more interactive.
    Apps are good for cases where interactivity is first and laid out data as rich documents second.
    Use the wrong tool and each case will suffer. 
    If you (try) build a highly interactive solution in the browser, you pretty much will kill yourself in trying to get it done in AJAX. No matter how much you try, the experience will always suck…simply because the browser is an environment designed for data driven layout, not for interactive finesse. 
    Then again, if you try to build an internet savvy app that spends most of its time laying out pages, you will also get killed on R&D costs. 
    Native Apps got an undeserved bad rap because of Windows App Installs, that could any time sink the system. Just because Windows was flawed, people started to say that native apps are stupid. This is naive. 
    Apple proved that if you have a civilized app distribution (walled garden) and install model, apps can provide a killer user experience. True, app developers hate to be scrutinized or regulated, but users benefit hugely by using products that have gone through some screening. 
    In the end, users decide and they say that great user experience goes first, app developer productivity goes second…

  • Shayn Baron

    Good read, thanks for sharing. 

    Hollywood should invest in tech and learned how to see through the eyes of a developer. They could hop on that horse and ride into the future instead of being left behind..

    I think Apps accent the Web. When I’m on the go, I go to my Apps. When I’m home I use the Web. I believe they both can and should coexist.

    Building an App in native IOS works well, Flash sucks, and html 5 has the potential to lead when it matures.

  • Jlregez

    I agree on this analysis. But I miss some discussion about the cost of mobile connectivity. As a single consumer who has to pay the telecom costs, this make a big difference as to what I will use.

  • billybigpotatoes

    I can not believe that in 50 years time – we will using a once size fits all browser (HTMLx, Javascript, CSS) application as our primary interface to the web.  That said I do not expect the browser to vanish completely either. 

    HTML was never designed to be the solution for this – it is extremely impressive how it has evolved over time – but a page centric view of the world is very limited.  Just as we had internet tools before the www – (bulletin boards, gopher etc.) The HTML age will also pass – I expect a legacy of APIs and URIs will live on.

    That said – there is a great deal invested in this current model – I expect there will be a great deal of inertia to to the next great thing(s) – most will come from incumbent business models being challenged.

    Ironically this could be an area where Google could be very exposed – at least in terms of search and page ranking – but then again there is nothing stopping them  solving the new problems in terms of search, recommendation and discovery for any new technologies – but there advantage would be significantly reduced compared to where they are today.

    There is one constant in technology – it never stops evolving.

  • Keith West

    Apps are a pain. I don’t want to read a magazine or newspaper on an app, just look at the moblie website. The only time I care about apps are for very specific things that offer a better user experience than the web. For me that’s weather radar, games, and things that relate just to the phones features and only incidentally connect to the web. In short, I’ll vote with you over George.

  • Robert Kabwe

    Apple, Facebook etc have grown and thrived on the back of the open web, not in opposition to it.

    Never say never. Browsers are catching up. Native client and direct canvas anyone?

    Millions of artists and creators without overriding profit motives will continue to contribute to the growth of an open web because it rewards with the knowledge one is empowering, and empowered by, open standards that ultimately benefit the many and not jut the few.



  • Lenticular Image Printing

    I really enjoyed this article. It is always nice when you read some thing that is not only informative but entertaining.

  • TenMoreMinutes

    Excellent insights.  Also, please work on the grammar – all the mistakes painfully dilute the power of the article.