The roadmap for progressive web apps from Microsoft; not just their support plans, but also some ideas for distribution.
I really, really like what Ember is aiming for here:
That’s how you get the holy grail of resilience and performance:
Subsequent visits and interactions are therefore nearly instantaneous, because they don’t rely on the network.
I sincerely hope other frameworks are paying attention to this layered approach.
Oh, and I also like this observation:
There’s an age-old argument about the difference between “web pages” and “web apps”. In reality, there’s a continuum between the two.
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.
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.
I’ve said it before: if your client-side MVC framework does not support server-side rendering, that is a bug. It cripples performance.
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.
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.
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.
James attempts to tackle the thorny question of what makes something a web “app” (rather than a web “site”). It reminds of the infamous definition of obscenity:
I know it when I see it.
In short, the answer to the question “what is a web app?” is “fuck knows.”
A quick overview and explanation of web intents.
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!
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.
The latest creation from Simon and Nat. It's surprisingly addictive and useful — play around with it for a bit and you'll see what I mean. Lovely stuff.
A very nice take on the to-do list app.
The sign up process is using the Huffduffer model. Good to see more human forms in the wild.
Shaun's new RSS reader looks sweet (and smart).
An in-browser code editor from Mozilla Labs.
Garrett has launched his bug-tracking web app. Looks lovely.
A great narrative by Peter Nixey detailing the ups and downs of launching a web app (Clickpass in this case).
Garrett's bug tracking software is one step closer to completion.
A nice simple little app for saving URLs to read later. This kind of simplicity is remarkably hard to achieve.
Looks like Apple are trying to redefine the term "web app" to mean sites created for the iPhone. The revisionism is completely barefaced.
A browser-based IM client from AOL. You heard it here first folks.
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.
It's here... Patrick and Dan have unveiled their event management system and pretty sweet it is too.
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.
A web app for reading RSS feeds. Pretty nice, but I'll stick with Adactio Elsewhere for now.
CNET's News.com explains why web services are so cool.