Stop pushing redux

My Stop pushing the web forward post got quite a few reactions. It’s time for a redux.

Counting Twitter reactions, it struck me that there were far more people who agreed with me than who disagreed. Sure, this is anecdotal data, but I didn’t expect it — I’d hoped for 50% or so agreement at most. There was disagreement as well — some of it dickish, but most quite polite. (At a certain point I had a sad about the dickishness, but looking back it was not all that bad, just the inevitable consequence of saying something that’s — so far — outside the mainstream of web thought.)

The big pushback against my feature moratorium idea came from Jake Archibald with an assist from Bruce Lawson (who also provides a list of other reactions), while Aaron Gustafson tried to find a middle ground. This response mostly focuses on Jake’s piece.

Emulating native

Jake starts by remarking that expectations of the user experience become higher and higher — and I feel that's at least in part because of native. Although he’s right, adding new features to browsers is not the solution.

In fact, there is no solution. The web cannot match a native UX feature for feature, and web UX will always remain inferior to native UX. Sure, eventually browsers will support everything native apps support now, but by that time native apps will support even more features, and the web will still be behind. I think we’re wasting our time here.

Jake uses the metaphor of a road race. “If we stand still, we go backwards.” If our purpose is to overtake native apps he’s right: we can’t afford to lose any time. However, I deny that that is our purpose. Instead, I say that, on that crossroad we passed a little while back, we shouldn’t have headed straight on but instead gone elsewhere. Since the web’s destination is not the same as native’s we have to back up and change roads.

So that’s the crux of the matter: do you believe we should speed up to overtake native, or do you believe that we’re on the wrong road altogether and we should back up to the last crossroads, which means stopping entirely, turning around, and going in a wholly different direction?

Not emulating native

Some thought I said that we should not copy any native feature. That’s not what I meant, though the blame for the confusion is mostly mine — I was unclear on this point.

An example will clarify what I wanted to say.

I’m a big fan of a series of features that would create local, offline web apps that users can install on their homescreen. They currently appear to be called Progressive Apps or Installable Web Apps. I worked with such apps back in 2009, and although there were a lot of technical problems back then, I became convinced this is the way forward for the web on mobile.

This, of course, is a near-one-to-one copy of native features. I’m fine with that. I find it defensible that the web should copy these particular features. I also accept that their implementation would be postponed by the moratorium I proposed.

The next step would be to make those local web apps shareable over Bluetooth or another peer-to-peer connection. I have a nice app, I show it to you, you want it, so I open a Bluetooth connection to your phone and just send you the app. (I’ve done this. Back in 2009 I sent a web app written for Symbian over Bluetooth to a Windows Mobile phone and it worked!)

This, now, is not a copy of a native feature. No native app ecosystem allows peer-to-peer exchange of apps because it would diminish the control of the central app store — and because of security. Web or native, there’s a big security issue here.

Still, this sort of peer-to-peer sharing is inherently webby and non-native to me. It would be a good destination for the web on mobile, quite distinct from native’s destination. It also mixes features copied from native with wholly webby features. This is the sort of thing I’d like to see more of.

And yes, this feature, too, would be hit by the moratorium. I’m fine with that. I waited six years, so I can wait a seventh, if the extra time allows browser vendors and web developers to think about these issues on a fundamental level.

Thinking about features

This example shows that I don’t disapprove of new features in principle. However, I wouldn’t mind a little more thought on whether or not to implement a certain feature. Jake mentions appcache, and that’s an excellent example. A little more forethought a few years ago would have prevented an unusable feature that has to be rewritten. The same goes for one of the local storage solutions (indexDB? I forget).

Michael Mahemoff said: if new features are so important, give us vertical centering. Web developers have been asking for it forever, but it’s still impossible in most situations. Good point.

Let’s think about such matters a bit more. Far from forcing us to spend a year twiddling our thumbs, a moratorium would give us the time to do so. So propose new features, by all means, and discuss them. Just don’t implement them yet.

Disagreeing with the Jake

Jake said one more thing I have my doubts about:

Is the web platform too big? For one person, yes. Is it a problem? No. No one can be an expert in the whole web. Surgeons aren't experts in all types of surgery, scientists aren't experts in all of science, web developers aren't experts in all of web development.

He’s got a point, and part of my resistance to this idea is that I remember the old days when I could actually enumerate the features of each of the three browsers. (OLD days, I said.)

Still, I have more serious doubts as well. Surgeons and scientists aren’t expected to know everything about all types of surgery or science. Some web developers, on the other hand, are expected to know all about the entire web.

One of the besetting unsolved problems of the web is that it’s nearly impossible for small businesses to get a good website. Good web developers, especially in teams, are too expensive, and cheap web developers usually aren’t good enough — partly because they’ve lost the overview of everything that’s possible on the web.

I feel that giving up on the idea that every web developer knows every browser feature (at least by name) could lead to a world where creating websites will become the prerogative of big, wealthy companies even more than it is today.

(In general, you don’t pay surgeons and scientists — somebody else does. But you do pay your web developers.)

Also, we need a curated list of current and proposed browser features studded with useful links. That would allow us to look things up when we need them, and will help web developers who work on their own.

Disagreeing with the Bruce

Bruce Lawson said one thing I disagree with:

We know that the fastest growing mobile phone markets don’t use apps, so by artificially slowing the pace of evolution on the web, we’re deciding that these people should get a second-class online experience.

I respectfully reject this argument. Why don't people in these markets use apps? Because they can't afford the necessary hardware.

So their hardware forces them to use the web. Worse, their hardware, and the sub-optimal browsers it requires, will make sure that any site that uses loads of JavaScript, or even advanced features that aren’t universally supported, will display badly — because “of course” the developer didn’t consider such sub-optimal browsers. (Progressive enhancement is for unrealistic hippies.)

What will happen once people in these markets get more money and/or modern phones drop in price? They’ll start to use apps and the web just like we do, and will encounter the same problems and opportunities. I don’t think that the current state of affairs in emerging market tells us anything we can use in this discussion.

Moratorium?

I now think I’ve made my case for a feature moratorium. Jake and Bruce made their case against — though maybe they want to react to my reaction.

Now it’s your turn. What do you think? This is one of the four big issues that we need to solve before we can take the web anywhere.

(And what about the other three issues? My next article will summarise them.)

This is the blog of Peter-Paul Koch, web developer, consultant, and trainer. You can also follow him on Twitter or Mastodon.
Atom RSS

If you like this blog, why not donate a little bit of money to help me pay my bills?

Categories: