Telerik blogs
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


Brian Rinaldi is the Developer Content Manager at Telerik
About the Author

Brian Rinaldi

Brian Rinaldi is a Developer Advocate at Progress focused on the Kinvey mobile backend as a service. You can follow Brian via @remotesynth on Twitter.

Comments

Comments are disabled in preview mode.