John echoes some of my recent thinking about what qualifies as a web browser and, by extension, what qualifies as the web:
We shouldn’t think of “the web” as only what renders in web browsers. We should think of the web as anything transmitted using HTTP and HTTPS. Apps and websites are peers, not competitors. They’re all just clients to the same services.
That said, I think he is perhaps underestimating the power of URLs. Addressability—particularly over an extended time period—remains the powerful feature of the web.
Some excellent research from Chris, canvassing opinions on whether there’s a difference between web “apps” and web “sites”. His conclusion:
Almost none of the points above ring true for me. All I see are exceptions and gray area.
If nothing else, the fact that none of the proposed distinctions agree with one another show how pointless the phrase “web app” is—if people have completely differing ideas on what a phrase means, it is completely useless in furthering discussion …the very definition of a buzzword.
This leads me to think perhaps the “web app” moniker (certainly the newer of the two) is simply just a fashionable term. We like the sound of it, so we use it, regardless if it truly means anything.
But all of this is, I think, missing the more important point: why? Why would you want to separate the cornucopia of the web into two simplistic buckets? What purpose does it serve? That’s the question that really needs be answered.
If we could pin down a super accurate definition that we agreed on, even then it might not be particularly useful. And since we can’t, I argue it’s even less useful.
Coming from anyone else, this glorious vision might seem far-fetched, but Anne is working to make it a reality.
Dan Bricklin—co-creator of the original VisiCalc spreadsheet—turns his attention to responsive design, specifically for input-centric tasks.
Scott gives us an excellent State Of The Web address, looking at how the web can be central to the coming age of ubiquitous computing. He rightly skips through the imitation of native apps and gets down to the potential of just-in-time interactions.
This a great proposal: well-researched and explained, it tackles the tricky subject of balancing security and access to native APIs.
Far too many ideas around installable websites focus on imitating native behaviour in a cargo-cult kind of way, whereas this acknowledges addressability (with URLs) as a killer feature of the web …a beautiful baby that we definitely don’t want to throw out with the bathwater.
Dan is collecting all of those product demo videos aimed squarely at young white single males with iPhones.
I share Tom’s frustration with news apps that should be websites:
I wouldn’t download a BBC app or an NPR app for my computer. Why would I want one on my phone?
There’s some great practical advice for building accessible mobile web apps here.
This post is ten years old, but I think it might still be the best attempt to demarcate a difference between web “sites” and web “apps”: think of them as stories and tools.
It’s also remarkably prescient about the need for an effort exactly like HTML5:
A widely-distributed, standards-compliant, browser and platform-independent library of functions that would perform the basic user interface functions for a web-based tool, relying on the server side only for the logic and data sourcing.
This is kinda funny (because it’s kinda true).
Taking apps out of phones and embedding them in the world around us …there’s a lot of crossover with what Scott Jenson has been writing about here. Good stuff.
Some future-friendly musings on mobile from Mozilla and Yahoo.
Brent Simmons follows up on that Dave Winer post with some future-friendly thoughts:
If I had to choose one or the other — if I had some crazy power but I had to wipe out either native apps or web apps — I’d wipe out native apps. (While somehow excluding browsers, text editors, outliners, web servers, and all those apps we need to make web apps.)
That’s not the case, though. Nothing has to get wiped out.
The great thing about the web is linking. I don’t care how ugly it looks and how pretty your app is, if I can’t link in and out of your world, it’s not even close to a replacement for the web. It would be as silly as saying that you don’t need oceans because you have a bathtub.
An excellent point from Jonathan: both native apps and web apps require an internet connection …and both native apps and web apps can be made to work without an internet connection.
This might sound obvious, but the myth that “only native apps can work without an internet connection” is surprisingly widespread.
A real-world anecdote from Jonathan illustrates some of the misconceptions around using HTML instead of going native. A lot of people don’t realise that web apps can store data offline.
An excellent article that examines the supposed benefits of publishing through someone else’s app store instead of the web.
Scott writes up some of the things he talked about at the Breaking Development conference: the just-in-time interactions that are inevitable in a heavily-instrumented world.
A quick overview and explanation of web intents.
It’s a provocative title but I certainly agree with this post’s premise. And the situation it describes is all too familiar.
I agree with this. I like it. I plus one it. So to speak.
A beautifully readable subset of the HTML spec, with an emphasis on writing web apps (and with information intended for browser makers has been removed). Very handy indeed!
John Allsopp calls bullshit on the notion that native apps are intrinsically better than web apps. I concur.
Here's a little piece of web history: the proposal that was presented and rejected at the 2004 W3C workshop that led to the formation of the WHATWG.
I'll be sitting in judgement on the entries to this neat competition which harks back to the good ol' days of 5k.org.
A nice collection of free apps for your mobile device. No app store required, thanks to offline storage.
PPK proposes a new buzzword for standards-based mobile development: HTML5 Apps. Definition: "an iPhone app that works on several other platforms, too, and doesn’t have to go through the app store approval process."
PPK offers a rebuttal to Paul Graham's attack on Apple's App Store policies by placing the blame firmly at the feet of developers who refuse to embrace web technologies.
This sounds like Yahoo's answer to Facebook Platform for single web pages or (spit!) widgets. We'll see if the reality matches the hype. "The Yahoo! Application Platform allows you to build and launch open-social applications to the largest daily â€¦
David Recordon shares his first impressions of Google App Engine.
Looks like Apple are trying to redefine the term "web app" to mean sites created for the iPhone. The revisionism is completely barefaced.
The first public alpha release of Apollo is out. Grab the runtime and then play around with some of the sample apps (none of which are that impressive but it's the thought that counts).
I used to think that Mike Arrington was a dick. Now I know he is.
The Future of Web Apps gets a write-up on the BBC site.
Danah Boyd's talk at ETech 2006.
The W3C proves that it can move with the times: "The mission of the W3C Web API Working Group is to develop specifications that enable improved client-side application development on the Web." This is very good news indeed.
CNET's News.com explains why web services are so cool.