What’s Wrong with the Web?

heartbeat_header

All of the recent debate invoking the death of the web reminds me of a classic scene from the movie Top Secret.

Anyone whose been around web development for a while has seen the web declared dead numerous times. Wired alone famously declared it dead in 2010 and then, years afterwards, assured us in 2014 that it was very much, well, not dead.

More recent headlines seem to indicate that if the web isn’t quite dead, it’s at least on its death bed. In this post, I want to put some context around these recent arguments as they seem to be based on two separate but not entirely unrelated issues – performance and innovation. Let’s break down the problems first, and then I want to explain why perhaps focusing on innovation can help fix the problems caused by performance.

The Web is Slow

Facebook’s Instant Articles launch has spurred on the debate that the web, and, more specifically, the mobile web is too slow to compete with native apps.

The overall state of the mobile web is so bad that tech companies have convinced media companies to publish on alternative platforms designed for better performance on phones. – Nilay Patel, The Mobile Web Sucks

But, as many have pointed out, Instant Articles and other similar services such as Flipboard, don’t have some magical new protocols for retrieving and posting content. They still use HTTP to transfer the content and HTML to display it, so what exactly does it rely on to offer the supposedly dramatic performance improvements?

Nilay Patel argues that it is mobile browsers, and specifically mobile Safari that is the culprit. However, TJ VanToll does a good job of debunking that argument.

The Problem with Advertising

TJ actually had laid out the argument that the issue wasn’t browser performance but “cruft,” mostly in the form of advertising, that was at the root of the performance benefit for services like Facebook Instant Articles and Flipboard. In fact, Nilay himself seems to tacitly acknowledge the impact of advertising, while also claiming it is unavoidable.

According to Les Orchard, viewing a single page on the Verge entails “over 9.5MB across 263 HTTP requests” (though these numbers drop on mobile). Of course, these authors are picking on the Verge because of Nilay’s article, but the Verge is not alone. Tammy Everts notes how page bloat affects mobile users.

In 2011, the average page served to mobile was just 390 KB — which, if you can remember that far back, actually seemed pretty big at the time. Today the average page is more than three times larger than that. – Tammy Everts, Mobile page bloat: The average page served to mobile is 3X bigger than it was four years ago

What are her top two problems facing mobile web site performance? Images and excessive resource requests. While she does not specifically blame advertising for either, it is very easy to see the potential for a connection.

I actually argued many months ago that the content model of the web is broken. Ads on the web pay terribly and require such a high volume of traffic, it is hard for most sites to survive. But, as Ben Thompson points out, the issue is compounded on mobile.

…Mobile display ads stink. Unlike a PC browser, which has a lot of space to display ads alongside content, content on mobile necessarily takes up the whole screen (and if it doesn’t, the user experience degrades significantly, making quality a casualty once again). This results in mobile ad rates that are a fraction of desktop ad rates (and remember, desktop ad rates are already a fraction of print ad rates) – Ben Thompson, The Facebook Reckoning.

Rene Ritchie is the editor in chief at iMore, so he should know a thing or two on this topic, and listen to what he says.

Just as desktop ads pay far less than old-fashioned print ads, mobile ads pay far less than desktop. Because phone displays are smaller than desktop, ads are also far harder to ignore. They’re not off to the side or a small strip on a big screen. They’re in our faces and in our way.

As more and more people move to mobile, revenue goes down, and the typical response is to amp up the ads in an attempt to mitigate the loss. That, of course, just makes them even more annoying. – Rene Ritchie, Content blockers, bad ads, and what we’re doing about it

Their solution – build a native app.

Even ignoring the rates, the “ad spend” for mobile doesn’t even line up with the time spent, meaning there is less pie to slice anyway.

Mobile-Internet-Trends-Mary-Meeker-2015-2

Image Courtesy of: KPCB

Essentially, the problem with advertising is twofold:

  1. Consumers (generally) won’t pay for content;
  2. Poor ad performance and a misalignment of dollars to time spent, means advertising doesn’t pay for content;

There’s no easy fix for #1, so sites have opted for fixing #2 by creating more (and typically lower quality) content and filling those pages with ever more ads, making the experience, especially on mobile, slow and poor.

Emulating Native

Ads, and their associated cruft, are not the only culprit being blamed for the poor performance of the web. In fact, ad-related cruft really only affects a subset of sites, mostly around news and media. Performance has become a problem even on sites without ad-related problems. For this, blame has fallen on two issues:

  1. The ever growing list of web platform features and the libraries needed to deal with these features across browsers;
  2. The growth in web frameworks like Angular, Ember and React.

In both cases, the arguments have centered around the impulse of web developers to try to emulate native app features in the browser in order to compete.

The big takeaway from Instant Articles is that we learned the wrong lesson from the rise of mobile and the app ecosystem. We’ve spent far too long trying to compete with native experiences by making our websites look and behave like apps – Jim Ray, Lessons From Instant Articles

The Ever-changing Browser

The desire to emulate native has led to a raft of new APIs in the browser that attempt to allow access to device features or recreate UI interactions that are common in native applications. Developers, eager to use these features, end up relying on tools and polyfills to ensure that they work across browsers and versions.

We get ever more features that become ever more complex and need ever more polyfills and other tools to function — tools that are part of the problem, and not of the solution. – PPK, Stop pushing the web forward

In fact, PPK has called for a moratorium on new browser features for a year. He says that web versus native is a false dichotomy.

The web cannot emulate native perfectly, and it never will. Native apps talk directly to the operating system, while web apps talk to the browser, which talks to the OS. Thus there’s an extra layer web apps have to pass, and that makes them slightly slower and coarser than native apps. This problem is unsolvable. – PPK, Web vs. native: let’s concede defeat

This issue is not new though. The idea that the web could be the operating system has been around for some time. For instance, as early as 1997, Peter Kropf, John Plaice and Herwig Unger proposed a web operating system(PDF). While the nature of the debate has changed, the fundamental desire of web developers to have full access to native OS functionality remains.

The Framework Binge

We complained for years that browsers couldn’t do layout and javascript consistently. As soon as that got fixed, we got busy writing libraries that reimplemented the browser within itself, only slower. – Maciej Cegłowski, Web Design: The First 100 Years

I’d argue, the rise of frameworks has been less specifically about the need to emulate native apps and more about the desire to emulate native development. As developers flocked to the client-side JavaScript development from other languages like Java, Ruby and PHP, they brought with them concepts on developing applications that had no ready counterpart on the web. Many of the popular frameworks take inspiration from frameworks that were widely used in server-side languages.

But, in many cases, frameworks have become a crutch. New developers don’t often learn “web development” as much as they learn “Angular development” or “Ember development,” all the while remaining entirely unaware of the potential issues they are inviting into their applications.

I think it’s also true that web developers tend to rely heavily on frameworks, sometimes without understanding the cost/benefit tradeoffs in order to use them judiciously. – Chris Wilson, The Web is not Poor Man’s Native

This can lead to unintended and needless consequences, as Baldur Bjarnason notes:

The web doesn’t suck. Your websites suck.

All of your websites suck.

You destroy basic usability by hijacking the scrollbar. You take native functionality (scrolling, selection, links, loading) that is fast and efficient and you rewrite it with ‘cutting edge’ javascript toolkits and frameworks so that it is slow and buggy and broken. You balloon your websites with megabytes of cruft. You ignore best practices. You take something that works and is complementary to your business and turn it into a liability. – Baldur Bjarnason, Facebook and the media:
united, they attack the web

The framework problem can be compounded by an increasingly type of developer that Christian Heilmann has recently termed the “Full StackOverflow Developer.” The answer to the the StackOverflow question invariably invokes a framework or library:

The entire culture dominant among web developers today is bizarrely framework-heavy, with seemingly no thought given to minimizing dependencies and page weight. Most times I land on a Stack Overflow page with a simple Javascript question, the highest-voted answer is “Just include [framework X] and then call this function,” even though a few posts beneath it is a perfectly suitable, standalone 10-line function. – Marco Arment, PPK on web-development tools

Duncan Wilcox concurs, but thinks it’s HTML and CSS fault for making web development seem easy and approachable.

As much as it might sound like a paradox, HTML and CSS are holding the web back, not because they’re badly designed or managed (though I believe they are), rather because they project the perception that web development is easy and approachable even with a half hour online course and frantically searching stackoverflow when you need to work around a browser bug. – Duncan Wilcox, HTML and CSS are holding the web back

A Lack of Innovation

It seems clear that the cruft that has built up in recent years due to a combination of ads, libraries and frameworks is hurting the web. Even the people who work on the web no longer seem to enjoy it.

As you can see from the many quotes throughout this article, there seems to be a pervasive pessimism about the direction and future of the web. Perhaps this is partly the reason why the web, today, seems boring. As I said in that post, the contradiction is that “the web was actually much more fun back when it was also horribly slow (most of us were on dial-up after all).”

Innovation seems to be happening in apps. The list of popular services that went with a native app is long and ever-growing – Periscope, WhatsApp and Instagram, to name just a few. In many cases, services that do have fully-functional web sites still insist on pushing you to their native app alternative nonetheless.

Innovation seems to be happening in devices. I’m not talking the Apple Watches, but the many things, from connected home devices to any number of internet-connected toys and accessories. Just browse Kickstarter and you’ll see what I mean.

These areas have inherited the fun, experimental spirit of the early web. They have a similar ethos to what Amber Case reflected in discussing the early(ish) years of the web:

These early adopters brought this spirit with them when they helped power earlier tech booms in the mid- to late ’90s, and you can see it reflected in many websites from that period — the Web as a playground, full of interesting (if sometimes silly) experiments, toys and DIY inventions. – Amber Case, Why We All Need to Make the Internet Fun Again

Perhaps, as she says, web development has just become a career opportunity – a paycheck. But maybe therein lies a solution to the malaise that is affecting the community. Maybe, the solution to the problems plaguing the web is to focus on what we want to build again – rather than how we are building it. Most of the debate has centered on how we build things – use a framework; don’t use a framework; use new APIs; there’s too many APIs. What if the problem lies in the fact that we aren’t building things we love?

Call me a naive idealist if you want, but maybe if we get back to building fun and exciting things again, the rest will solve itself.

Header image courtesy of Duane Schoon

Comments

  • Excellent. Your last sentence is the answer.

    “Call me a naive idealist if you want, but maybe if we get back to building fun and exciting things again, the rest will solve itself.”

    I was just writing almost exactly this in a thread on Facebook about What’s Wrong With Twitter.

    “There are a lot of things that could be done to shakeup twitter and provide users with some fresh functionality to explore. Because that’s what I think we all loved about Twitter, the chance to do new things. I love the network, the combination of people, software, ideas and data. Twitter got stagnant. That’s the real problem. Almost any change that opened up new functionality for people to explore that allowed them to connect with other people in new interesting and meaningful ways would rekindle the spark that twitter used to be.”

    You could just do a global replace “Twitter” with “the web.”

    I want smart people to play with. Basically that’s it.

    Dave

  • burkeholland

    Man – that was a good one.

    Developers get bored if we don’t have something to bitch about and proclaim the death of. We have a morbid obsession with being the first to say “See! I told you you were doing it wrong”.

    Since we run this site together, let me also point out that proclaiming the death of the web, or telling people to stop adding features or saying that the web sucks is incendiary. Which means, as authors and publishers, we can get all of the developers looking for the next apocalypse to show up and read our content. Which in turn helps our traffic, which is ultimately what we want: more attention.

    I just wanted to point out that if we’re being honest here, each of these proclamations is predicated mostly on circumstantial evidence that is largely a matter of opinion. Your last statement is the one that is what we should be doing, and that’s building amazing things for the web. Negativity and creativity make terrible bedfellows.

  • roger tubby

    The web is really just becoming
    another client-server model with JS/CSS replacing the old 1980-style
    apps with web-based ones. The presentation may be supplied by HTML or
    on-the-fly rendering in the browser and the old proprietary data streams
    with new (proprietary) JSON/etc. streams. Native apps (20xx-style)
    naturally have better capabilities at the cost of re-implementation
    every time the platform or major version changes. I remember working on
    old 24×80 “intelligent” screens (3270, etc.) that saw an awful lot of
    changes in the 20+ years that they were around.

    I bet we’ll continue to see this leap-frogging of capabilities and resource demands
    as long as there are humans, UIs, and computers. It’ll be fun to look
    back in another 20.

  • I hate the web emulating native apps. But unfortunately it isn’t going to stop in near future…

  • sublevel.net is a lightweight social network that is innovative in all sorts of ways. So, yeah, the web is still alive and well.

  • Richard Lerner

    I agree. The web has stopped being useful and there are so many things being loaded on when you open a page that I am starting to dread when I want to see what’s happening in the world.

    The web started off as a place to do things efficiently and now it has become a circus tent of distractions.

    • Mr. D

      Use “noscript” add-on, for Mozilla Firefox. It enables me to allow one script and deny all other 30 scripts which increase page load time by ten folds.

  • … that the issue wasn’t browser performance but “cruft,” mostly in the
    form of advertising, that was at the root of the performance benefit for
    services…

    Indeed! To the point that several services had become almost unusable on my computers in that they took so long to [re]load and were auto-refreshed, even with an upgrade to my wireless internet connection bandwidth. I was making repeated virus scans and hardware checks to determine the reason for the continual slowdown and was considering the replacement of my computers when I came across an article about ad [and more] blocking browser ad-ins. Most of these are free for the download . These seem to have solved my computer performance problem.

    The one I use is Ghostery, but there are many others.
    https://www.ghostery.com/en/try-us/download-add-on/

  • MichelChartrand

    What really helps compound the problem are those websites that insist on showing one image per page, like ‘here are 25 things you should be doing…’ and each page is so cluttered with ads and crap.

  • Brian_Balke

    Somehow I have the dark feeling that the desire to “build cool things” is what drives the proliferation of cruft and native functionality. The former because it’s how salaries are paid, and the later because there’s always something cool that could be done “if only…”

  • the real problem with the web is the fact that people who do not know what to do with it started not only using, but also building things for it… it should have stayed a tool for researchers and people who actually know what to do with a computer.

  • jmetcher

    Maybe the web is in trouble because we’re using a crap language on horrifically bad runtimes? Sorry, but someone had to say it.
    When my web browser uses more memory and CPU than a full Windows VM running SQL Server, that’s got to tell you something. The JS library bloat is real, but you could hardly claim that Windows is paragon of hand-tuned efficiency either.
    BTW, nice article. I do agree with most of the points raised.

  • Pingback: Brian Rinaldi looks at the recent debate and asks "What's Wrong with the Web?" http://developer.telerik.com/featured/whats-wrong-with-the-web/()

  • Pingback: Revision 230: CSS input modality und die Unzufriedenheit mit der Gesamtsituation | Working Draft()