While many challenges remain, the good news is … it’s progressive. Developers can already see the benefits by sprinkling in these technologies to their existing websites and proceed to build on them as browsers and operating systems increase support.
Remy sums up the psychological end goal of progressive apps (HTTPS + Service Worker + manifest JSON file) prompting an add to home screen action:
This high bar of entry will create a new mental model for our users.
If I add this app to my home screen, it will work when I open it.
It’s a shame that this charge to turbo-boast the perception of the web on mobile is a bit one-sided: I would love to see Apple follow Google’s lead here. But if Android succeed in their goal, then I think iOS will have to follow suit just to compete.
A fascinating slice of ethnographic research in Myanmar by Craig. There’s no mention of the web, which is certainly alarming, but then again, that’s not the focus of the research.
Interestingly, while Facebook is all omnipresent and dominant, nobody is using it the way that Facebook wants: all the accounts are basically “fake”.
What I found fascinating are the ways that people have found to bypass app stores. They’re basically being treated as damage and routed ‘round. So while native apps are universal, app stores would appear to be a first world problem.
Now if there were only some kind of universally accessible distribution channel that didn’t require any kind of installation step …hmmm.
A response to a rant I linked to recently.
I couldn’t agree more. The tools have evolved and we now have frameworks and practices that allow us to render from the server and use the same code to render on the client, progressively enhancing from a solid robust base.
The problem is that I don’t see a willingness from developers to embrace this way of thinking. Instead I see it dismissed as being unrealistic or more expensive.
Still, it always takes time for behaviour to change so maybe things will only get better. I certainly hope so.
I really, really want to like this article—it’s chock full of confirmation bias for me. But it’s so badly-written …I mean like, just the worst.
Here’s an actual sentence:
So with a capable, HTML-based platform and a well-designed program that makes good use of CSS, one site could support phones, tablets, PCs, and just about anything else with one site.
So, yeah, I’m still linking to it, but instead of it being for the content, it’s because I want to lament the dreadful state of technology writing.
A hands-on look at building a progressive web app with Service Workers, manifest files, HTTPS, and all that good stuff. This is nice and balanced, extolling the virtues but also warning about the potential difficulties in implementing this stuff.
One nitpick though: there’s talk of graceful degradation, and while I get that that’s the outcome, I think it’s better to think in terms of progressive enhancement, which is the approach.
Following on from that last link, here’s an in-depth run-down of what you can do in mobile browsers today. I think a lot of people internalised “what you can’t do on the web” a while back—it’s well worth periodically revisiting the feature landscape to revise that ever-shrinking list.
Perhaps the biggest advantage the web has over native apps is how quickly users are able to engage. All that’s between the user and your content is one click.
Bruce gives a great run-down of what’s involved in creating one of those new-fangled progressive apps that everyone at Google and Opera (and soon, Mozilla) are talking about: a secure connection, a service worker, and a manifest file.
Crucially, in browsers that don’t support it, you have a normal website. It’s perfect progressive enhancement.
Funnily enough, this here website—adactio.com—is technically a progressive app now.
At their simplest, Progressive Web Apps are application-like things hosted on your web server. If you’re as old as me, you might call them “web sites”
Outlining the architectural thinking required to create what the Google devrel folks are calling progressive apps.
Browsers without service worker support should always be served a fall-back experience. In our demo, we fall back to basic static server-side rendering…
…but this is only one of many options.
Hmmm. In my opinion, sending usable HTML on first request isn’t an implementation detail—it’s crucial. But on the whole, this approach is very sensible indeed.
Why Atavist is betting on the web. See also:
It’s not about technology, performance and APIs – it’s about people.
Apps must run on specific platforms for specific devices. The app space, while large, isn’t universal.
Websites can be viewed by anyone with a web browser.
And that doesn’t mean foregoing modern features:
A web browser must only understand HTML. Further, newer HTML (like HTML 5) is still supported because the browser is built to ignore HTML it doesn’t understand. As a result, my site can run on the oldest browsers all the way to the newest ones. Got Lynx? No problem. You’ll still be able to find matches nearby. Got the latest smartphone and plentiful data? It’ll work there, too, and take advantage of its features.
This is why progressive enhancement is so powerful.
My site will take advantage of newer technologies like geolocation and local storage. However, the service will not be dependent on them.
Sensible words from Christian.
Web applications don’t follow new rules.
And frameworks will not help:
A lot of them are not really fixing fundamental problems of the web. What they do is add developer convenience. … This would be totally OK, if we were honest about it.
But as people spend more time on their mobile devices and in their apps, their Internet has taken a step backward, becoming more isolated, more disorganized and ultimately harder to use — more like the web before search engines.
This page does a great job of explaining Mozilla’s thinking behind “pinned apps”—an idea that would be great for the whole web, not just Firefox users.
The Web Manifest spec is still very much in draft, but it’s worth reading through Bruce’s explanation of it now. Basically, it will provide a way for us to specify in one external file what we currently have to specify in umpteen meta tags and link elements.
An astute comparison of the early years of the web with the early years of the app store. If there’s anything to this, then the most interesting native apps are yet to come. App Store 2.0?
With the usual caveat that I wish this were published on Craig’s own site, I particularly like this passage:
Apps, too, are ephemeral. Some of the most ephemeral software we’ve ever produced. Ephemeral if for no other reason than because of their gated homes. Our apps cower below the fickle whim of App Store Gods, struck down for no reasonable reasons or for very reasonable reasons. It doesn’t matter which, the end result is always the same: gone, forever.
I, for one, don’t welcome our applinks overlords.
So, you’re checking out your news feed on your Facebook app and you see a CNN post that you want to read. After reading the post on CNN, you decide you want to to read the source article on TMZ…
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?
Why mobile Web accessibility matters - best practices to make your mobile site accessible | mobiForge
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.