Below you find the last seven QuirksBlog entries.
Fair warning. You’re going to hate this one. I want to stop pushing the web forward for a while. I want a moratorium on new browser features for about a year or so.
Recently I’ve been having serious doubts about the whole push the web forward thing. Why should we push the web forward? And forward to what, exactly? Do we want the web to be at whatever we push it forward to? You never hear those questions.
Pushing the web forward currently means cramming in more copies of native functionality at breakneck speed — interesting stuff, mind you, but there’s just too much of it.
Quick, name all the new features browsers shipped in 2015! You see? You can’t. That’s the problem.
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.
I don’t think this is a particularly good place to push the web forward to. Native apps will always be much better at native than a browser. Instead, we should focus on the web’s strengths: simplicity, URLs and reach.
The innovation machine is running at full speed in the wrong direction. We need a break. We need an opportunity to learn to the features we already have responsibly — without tools! Also, we need the time for a fundamental conversation about where we want to push the web forward to. A year-long moratorium on new features would buy us that time.
Last week the news broke that Acadine Technologies, a Hong Kong start-up led and peopled by mostly ex-Mozillians, raised venture capital to create H5OS, a Firefox OS fork. I believe the political motivations behind this move have been underreported.
Two weeks ago I heard that a person close to me is seriously ill. I spent too much time in the hospital lately, but fortunately the situation has improved all the way to serious but not hopeless. Let’s hope it improves again from there — not impossible at all, but not a certainty, either.
Well, last week’s article generated quite a few hits, and even some useful responses. It’s time to respond to the responses — and note one interesting coincidence.
I feel it’s time to revisit the web vs. native debate, and concede defeat — or, at least, concede that the web cannot, and should not, compete with native when it comes to complex, app-like structures.
I feel we’ve gone too far in emulating native apps. Conceding defeat will force us to rethink the web’s purpose and unique strengths — and that’s long overdue.
I feel that our desire to take on native heads-on has given rise to unnecessarily complex toolchains that slow down what could be simple websites. I’m especially thinking of struggling news sites here, and will argue below that they should go native all the way and forget about the web.
Seems Facebook (which I don’t use) has put out a new product that allows iPhone users (and only them) to read news articles without leaving Facebook. John Gruber wrote an as-always thought-provoking article about why this could be bad for the web as a whole.
Although I don’t agree that the web is in danger (we hear this story every week, it seems), John makes an important and valid point:
Daring Fireball pages load fast, but the pages I link to often don’t. I worry that the inherent slowness of the web and ill-considered trend toward over-produced web design is going to start hurting traffic to DF.
After last week’s rant about, among other things, the W3C Device Adaptation spec, one of the spec’s authors asked me to clarify my critique. Fair enough. Here’s my take on the current specification.
My critique of Device Adaptation consists of three main themes:
- The spec does not address the actual current situation at all, while all browsers actually support my theory of the layout, visual, and ideal viewports decently, and I’ve already done the heavy lifting.
- The spec is obscure about what its most important components actually mean; I’m especially thinking of the initial and actual viewport. A simple schematic would have helped a lot here, and it’s fairly easy to produce.
- Although the spec treats relevant media queries as well as the meta viewport and the
devicePixelRatio. That latter, especially, could do with some specification.
Even older entries
See the April 2015 archive and beyond.