And like you say, it starts to look like a traditional native app, so why not just create a native app, if you're working in a domain that requires...whatever benefit you're getting here. It seems like you're just trying to approach a similar appearance to the user, while simultaneously wrestling with lots of technologies that don't suit the idea (CSS for example).

1. You need to have a non-JavaScript version. That is your main page index.html is a full functioning page without JavaScript. When JavaScript is enabled, it turns the page into a Web App.

2. A simple loader will solve the problem. You might not be able to show the progress for the moment.

There is (thankfully) no law which say that your service must be usable for people who turn javascript of.

Edit: Graceful degradation should be a tenet of web development. Having no provision for a person who doesn't have javascript enabled seems bizarre to me, and being bullish about the requirement seems even more bizarre...maybe i'm just getting cranky with age or something.

It is one thing if we were talking about a webpage ala 1995 for joes autoshop. At most it will have a comment field (or, the horror, a guestbook) and each url will map logically to a specific public part of the site. Most likely there will be no concept of users at all.

The same thing goes for a blog although you won't get the auto updating twitter feed and, if the blog uses diques, you may have to click a couple of links to see them.

But a webapp is more like Google writer. It just lose all meaning to make it work without Javascript.

Your second point has merit. However I'd counter it thus: * You can load a HTML page first, containing a representation of the end content, so you can avoid the flash * You can show some sort of loading indicator on page load. Users are usually fine with waiting for the initial page load - it's only subsequent interactions that need be fast.

In other words, there's no reason why the page need be blank.

And while people can build crawlers that can fetch Javascript rendered pages, these scripts will have to drive real browsers with rendering engines, not just simple HTTP clients. And this is a problem, because fetching millions of web pages will require serious infrastructure work, versus a crawler using libev that can fetch dozens of pages in parallel without a sweat.

Also, that spec you gave is not exactly how Google operates. That's the advice Google gives for making web apps compliant, but the reality is that Google is smarter than that and it takes Google a good amount of effort to fix other people's screwups.

Accessible to crawlers doesn't mean Google-only and you should be careful not to throw the baby along with the bathwater.

Also, if search engine referrals is all you're interested in, if Google drops you from their index, your website might as well not exist, right? As I said, be careful not to throw the baby with the bathwater. Google is not what made the web great, but a Google dependency might break it and website authors can be blamed for this.

It's not a future-proof solution.

IE 9 comes close, and can be considered modern.

This is because the # in an URL is supposed to be an identifier of a element in the page, not an actual resource.

This sounds like a huge imposition to implement -- so much so that I seriously doubt anyone will bother for anything even moderately complex. Not only do you have to produce an API for the client-side javascript to call, but you also have to render static HTML for Google to index.

FYI.

I have been wondering if we might see the rise of a general purpose JSON/RESTful API that plays the same role for these kind of apps as general purpose database engines did for the old thick client model.

... with all the security/privacy problems that go with that, and then some.