| A web site can be Javascript-heavy[0] without being a web application[1]. There's a big difference. If you just need auto-completion, modal dialogs and similar features then you shouldn't build a web application, and you definitely should make your site work without Javascript. On the other hand, if you are building Google Maps, then you should build a web application. Google Maps doesn't work when you disable Javascript. Supporting clients without Javascript in web applications often doesn't make sense. If it does, you should consider building a standard web site. Just imagine building Google Maps without Javascript. Or better yet, imagine using a version of Google Maps without Javascript. I'm sure that there are people that could pull that off and still end up with something good but it's not the case for most teams (not enough time, resources or skill) building web applications. [0]: What's considered Javascript-heavy anyways? I think that including support for standard stuff like auto-completion, modal dialogs or even just including bootstrap's javascript these days makes your site Javascript-heavy. [1]: By this I mean a single page web application that uses Javascript for state management/routing, rendering, communication with the backend, etc. You should be able to deploy an application like this on S3 and it should work. That's not a requirement but I'm just trying to point out that it's an application built completely with Javascript, with no backend support (except for the api that it communicates with). |
The "web application" label you use here means what? That it's okay to ignore web development best practices like progressive enhancement, because "web application"?
That Google Maps ignored progressive enhancement is not a good reason for labelling it as a web application.
Is Fix My Street (http://fixmystreet.com/) a web application? It uses a Google Maps type interface so you can report broken street lights, fly tipping:
https://www.mysociety.org/2011/07/08/technical-fixmystreet-m...
> it's an application built completely with Javascript, with no backend support (except for the api that it communicates with).
It's a circuitous definition. Surely an API requires a backend? And surely that API predominantly uses HTTP?
There isn't much difference between returning structured data, and returning an HTML view of structured data. That's just a twiddling of views from a controller (assuming a well-structured codebase). Both deal with an HTTP request and emit an HTTP response, one just does an extra step of rendering HTML.