Archive: November 18th, 2014

Webiness

John Gruber quite rightly skewers a paywall-proteced “sky is falling” piece in the Wall Street Journal called The Web Is Dying; Apps Are Killing It, writing that native apps are part of the web:

They’re just superior clients to open Internet services.

This is something I wrote about earlier this year:

There’s a whole category of native apps that could just as easily be described as “artisanal web browsers” (and if someone wants to write a browser extension that replaces every mention of “native app” with “artisanal web browser” that would be just peachy).

Instagram’s native app is a web browser.

Facebook’s native app is a web browser.

Twitter’s native app is a web browser.

In that same piece, I try to define exactly what the web is:

Well, the unsexy definition I’ve used in the past is that the web consists of files (e.g. HTML, CSS, JavaScript), accessible at URLs, delivered over HTTP.

John also gives a defintion of what the web is:

There are two big four-letter “H” acronyms that powered the web from the beginning: HTML (client), and HTTP (networking protocol). Native apps are just an alternative to HTML running in a web browser (and many native apps still use HTML web views embedded within the apps themselves to render parts of their interface). Almost all native apps use HTTP/S for networking, though.

Notice the difference? Whereas John talks about two things that define the web (HTTP/S and HTML), I talk about three: HTTP(S), HTML, and URLs:

But to be honest, I don’t think that the Hypertext Transfer Protocol is the important part of the web; it’s the URLs that really matter. It’s the addressability of the files that’s the killer app of the web in my opinion.

URLs are what give the web is its reach, and that’s what’s still missing from native apps.

But John’s fundamental point that native apps and the web are not fundumentally opposed? I completely agree with that. They are complementary. Irakli Nadareishvili wrote about this false dichotomy recently in a post called Responsive Web Design or Native Mobile Apps?:

Native mobile applications are not going anywhere and the future of all websites is to be responsive. These two assertions are not mutually exclusive, they are complementary – don’t create apps when what you actually need is a website; but also don’t pretend webapps can completely replace native applications, because they can’t.

It’s also worth remembering that even if you’re using a native app—like, say, Facebook or Twitter—you’re still going to spend a lot of time following links and reading stuff that’s rendered in the app, but that lives out on the world wide web. And the reason why those apps can access those resources is because those resources have URLs.

URLs are not an implementation detail. The URI is the thing.

Perf.Rocks

A collection of performance resources: articles, tools, talks, and books.

Let’s Encrypt

This is a great development! The EFF are working on a creating a new certificate authority that will issue certs for free.

I am so happy that the certificate authority racket is getting this shake-up.

You’re such a lovely audience, we’d like to take you home with us, we’d love to take you home. #aeasf

You’re such a lovely audience, we’d like to take you home with us, we’d love to take you home. #aeasf

Steve Albini on the surprisingly sturdy state of the music industry

Steve Albini’s barnstorming keynote address at Melbourne’s Face the Music conference.

Performance Budget Metrics - TimKadlec.com

Some good practical advice from Tim on setting a performance budget.

Use rule-based metrics to make sure you haven’t overlooked simple optimizations.

Use quantity-based metrics as guides to help designers and developers make better decisions about what goes onto a page.

HTML5’s “Dirty Little Secret”: It’s Already Everywhere, Even In Mobile - ReadWrite

I’m an advocate for progressive enhancement. Tom Dale is not. But even though we may disagree on that, there’s a lot to like in his sensible, balanced answers to some sensationalist linkbaity questions.

It’s not that the pace of innovation on the Web is slower, it’s just solving a problem that is an order of magnitude more challenging than how to build and distribute trusted apps for a single platform. As we saw on the desktop, it may take a few years to catch up to all of the capabilities of a native, proprietary platform, but in terms of the impact it will have on humanity, forgive me for not losing sleep if we have to wait a few years for it to arrive.