[mekoka]

> tl,dr: this encourages single-page apps which will be the death of the web.

The first sentence of the "Web Apps" section is Web ap­pli­ca­tions are not doc­u­ments. This is a motto that I believe a lot of people who think the way you do should take pause and reflect upon.

After years producing web apps, I came to the conclusion that non-js web apps are some of the craziest ideas ever. The browser without js is a tool to consume and, to some very minimal extent, produce documents. I consider most non-js apps on the browser to be huge hacks at best, that do what they can to circumvent the shortcomings of that technology. And heaven knows that shortcomings are a dime a dozen (lack of http method on anchors, limited to GET and POST, to only name a few).

If you do embrace building apps with js, then you need to stop thinking in the document-oriented paradigm, otherwise you'll be making some unnecessary compromises at the expense of your end users, and you'll be making your life harder as a developer. For instance, some actions that the standalone or native version of your application does with a single click might require 3 or 4 user interventions on the browser version, simply because you wish to remain true to some dogma.

A while back I've embraced the idea that web apps aren't documents. It freed me as an app developer to make choices that were otherwise unthinkable in a previous mindset. My APIs make more sense, my interfaces are more intuitive and my users are the happier for it.

[prodigal_erik]

"Web app" is usually a misnomer. The world-wide web is the linked universe of addressable documents (resources). An app which is not just some behavior added to that core architecture is not capable of becoming a part of the web. It's a ghetto of single-purpose data, exactly like the client/server apps from the 1980s, only this time with a deployment model that gets it past gatekeepers in IT. It shouldn't be called a "web app" simply because its installer is delivered via HTTP, and people working on such projects ought to be aware that the network they're building is competing with the web for content while being far more hostile to hacking and mashups.

[coldtea]

>is not capable of becoming a part of the web. It's a ghetto of single-purpose data

Sorry, but with the exception of screen-scrapping, 99.9% of the web IS single-purpose data.

Some people imagine a magical unicorn world where webpages inter-operate etc, but that never was the case. And I don't want my Gmail data messing with my Adobe Kuler data, my Amazon data, or my eBay data anyway.

For inter-operation, we have RSS, REST, AJAX, JSON and co. Web pages themselves, as served to the end user, are not were it should be expected to be (and never was there in the first place).

[mekoka]

I think the "web" in "web app" is for web browser app, not world wide web app. Whether it should or shouldn't be called differently is by now besides the point. It's certainly not the first concept to be allegedly ill named and it won't be the last. The most important thing is to understand the nuances when creating resources to be consumed or produced over http.

> people working on such projects ought to be aware that the network they're building is competing with the web for content while being far more hostile to hacking and mashups.

On the contrary, case in point APIs: they're often distributed using formats such as JSON or XML, which weren't designed to be particularly web friendly the way HTML is. They're still much more suitable to hacking and mashups, because they go beyond the conceptual limitations of the web to fully embrace the potential of HTTP.

The only thing required for any app, even js intensive ones, to be part of the web is to provide some urls that resolve to web friendly versions of their resources and that really isn't that complicated.

[dragonwriter]

> The world-wide web is the linked universe of addressable documents (resources).

"Documents" and "resources" aren't even approximately equivalent. "Resources" are more "things that can be described by nouns" than just "documents".

A document may be a representation of a resource, but the two are not equivalent.

[Intermernet]

I think the problem is that most single page apps are badly designed.

Each resource must have a unique URI or the original web model (as envisioned by TBL) is broken.

This can be, and in many cases has been (google plus for instance), solved. It's just a matter of good design.

[monkeynotes]

The HTTP protocol is designed to consume documents. I guess this is why it's so hard for people to get their head around web apps not being documents.

[ako]

POST, PUT, DELETE are just as much part of HTTP as GET...

[monkeynotes]

Those were all designed for posting, putting, and deleting discrete hypertext resources - which I am calling 'documents'.