1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
|
Earlier this summer, noted web developer Peter Paul Koch, author of The Mobile Web Handbook, published an article entitled "<a href="http://www.quirksmode.org/blog/archives/2015/07/stop_pushing_th.html">Stop Pushing the Web Forward</a>". As the title suggests, Koch argues that the relentless pace of new features on the web isn't helping the web and that we -- developers, along with browser makers -- would do well to put on the brakes for a few months.
It's not that Koch is opposed to progress, or new features for the web (though he does decry the trend toward slavishly emulating every new feature of platform natives apps), just that perhaps the pace is a bit fast. So fast in fact that developers and browser makers are just driving the web forward -- there's no direction beyond that.
In other words, in a world where forward progress is the only goal, Koch wants to talk about where the web is going and why. Koch thinks it would be nice to freeze the development of new browser features for a while, giving developers more time to understand and use the features the web already has and that in turn would give us a better idea of where the web is lacking -- compared to what? -- and how to fix it.
This, predictably, earned him quite a bit of backlash. Questioning one of the most fundamental tenants of modern existence -- progress is good -- typically gets you some pretty vehement feedback.
In this case though, while Koch's suggestion is obviously never going to happen, it has at least inspired some rational discussion as well, especially with regard to the latest trend in new features for the web -- emulating the features that platform-native applications enjoy. This means things like APIs that allow sites to access device hardware or effects like the proposed <a href="https://docs.google.com/document/d/17jg1RRL3RI969cLwbKBIcoGDsPwqaEdBxafGNYGwiY4/edit?pli=1#heading=h.pcll678prpwu">Navigation Transitions</a> spec which makes page-to-page navigation smoother and more like what happens in native mobile applications.
But does the web need these things? "We’re pushing the web forward to emulate native more and more," writes Koch, "but we can't out-native native."
Indeed, native apps will by definition always be ahead of those emulating their features. The quest to make websites behave more like native applications is thus doomed to perpetual failure.
Google's Jake Archibold <a href="https://jakearchibald.com/2015/if-we-stand-still-we-go-backwards/">counters</a> Koch's argument against native emulation, writing that "we should add features using evidence, and native is a great source of evidence."
Archibold goes on to cite some specific examples: "Through native, we've seen users benefit from push messaging, offline data access, GPS, speedy payments. Through native we've also seen store management harm openness, packaging hurt linking, and up-front permissioning harm security and privacy."
Prior to native mobile platforms the web was often measured against competing technologies like Flash, which provided the impetus for native audio and video tags taken for granted today.
While his argument is a good one, Archibold glosses over the fact that often the web's version of features on native platforms are half-baked and have been for ages. Consider the Geolocation API, possibly the most useful HTML API out there. A mobile device in your hand can let a website know where you are and tailor information you might need -- maps, nearby friends, the closest restroom and so on -- to where you are. And of course it comes with the broader reach of the web, no building multiple apps for different platforms. Write once, run on the web. It sounds perfect.
You might think a company like Uber would jump on the Geolocation API. But Uber's service is currently only available through an app.
Opera's Bruce Lawson, <a href="https://dev.opera.com/articles/on-a-moratorium-on-new-browser-features/">writing in response</a> to Koch's article says that's understandable "because sometimes the Geolocation API is not very accurate on the web, and really accurate location info is critical to a taxi hailing service."
Lawson says that's not reason to put browser features on hold though, writing that "that’s an argument for making the Geolocation API better, rather than stopping development."
Indeed it is not so much that the web is moving too fast, but that there has been seemingly no effort whatsoever to fix things that have long been broken. The Geolocation API has been available in most browsers for many years now and it hasn't become any less buggy or unreliable.
It's not the pace of feature development, it's the quality. But development resources are finite and if browsers were to stop creating new features for a while and focus those finite resources on documenting, debugging and fixing those half-baked features like Geolocation support instead, wouldn't that in fact be pushing the web forward?
Forget the more complicated APIs even, what if developers could do something as seemingly basic as reliably style form elements across browsers? Wouldn't that be pushing the web forward?
This is the core of Koch's argument, not that the web doesn't need new features for developers and users, but that new features at the expense of effort spent improving what we have quickly becomes pointless. Broken or half-complete emulations of native features are worse than no features at all.
It seems reasonable to argue then that what the web needs is not a year long moratorium on new features, which, let's face it, will never happen anyway, but something akin to what Ubuntu Linux developers call "<a href="https://wiki.ubuntu.com/One%20Hundred%20Papercuts/Mission">paper cut bug"</a> fixes.
A paper cut bug is defined as "a trivially fixable usability bug that the average user would encounter on his/her first day of using a brand new installation." In other words, a bug that isn't difficult to fix, but causes real problems in day to day use.
Perhaps, since the web is currently semi-broken in more ways than one, it would be wise to throw out the "trivial" criteria and just take some time to fix what's broken. If that means new features are delayed by a few months will that mean the end of the web as we know it? Probably not. In fact it might just mean the beginning of the web as we want it.
|
