A drawback is that the content isn't directly crawlable by search engines.

I made an app earlier that uses Javascript to make static sites dynamic using Javascript, but got lots of comments saying that it's anti-seo:

http://news.ycombinator.com/item?id=2830429

Hence I offered a secondary PHP option.

SEO is fine when pre-loading the content and hiding it.

Hmm, how would you use Javascript to preload content that is crawlable by search engines?

This is really nifty. One nit that I'd pick, however. The urls break without the hash.

With the demo, for example, these urls produce two different results:

http://cmpolis.github.com/Pagify/#about http://cmpolis.github.com/Pagify/about

The first url has the full content and structure of the page, while the second url only has part of the content of the page.

I realize that this is partially what makes the plugin so simple, and maybe it's fine for most applications. But this would be extra cool if the urls were more consistent. :)

Good point. The first URL is really how the page is intended to be accessed.

I'm going to work on an option to enable using pushState for navigation which would use hashless URLs. The only downside is that users would have to enter the site through the base URL or some JS would have to be included in each content page.

Thanks for the feedback, really got me thinking about how to add pushState support!

This should really be handled on a server side with a set of redirects, and Twitter would be a good example to follow. Their redirect setup is this:

  http://.../_escaped_fragment_=PAGE  ->  http://.../PAGE

The _escaped_fragment_ URL is what is crawled by Google as per [0] and the redirect ensures that PAGE gets recorded in Google as /PAGE. Then they also do this:

  http://.../PAGE   ->   http://.../#!/PAGE

but only for logged in users and, I would assume, NOT for requests that have _escaped_fragment_ in the Referer (sic). This ensures that regular URLs work as expected, including those picked up by the users from Google.

[0] http://code.google.com/web/ajaxcrawling/docs/specification.h...

Using the hash allows for all the content to exist within a single resource -- in this case, a single HTML page using jQuery to hide/show content based on the fragment identifier. What you want can't really be achieved without something on the server-side (rewrite rules with Apache, routes with Rails) and it outside the scope of what this plugin is trying to do.

> What you want can't really be achieved without something on the server-side (rewrite rules with Apache, routes with Rails)

That's true, but the rewrite rule could be very simple. Have all pages of the form http://site.example/* serve up the entry page (which then uses JS to parse the URI and load the appropriate page content), and special case http://site.example/pages-directory/* or something to serve the content for specific pages.

Almost as easy as just, you know, creating a website. Obviously, the simplified example is simplified, but can you sketch a case where this would actually be useful? Or, even better, point to a site where it is actually in use?

EDIT: Just to clarify, what I'm wondering is, where would a single-page site that consists of pages of content (rather than an app) be useful?

The single page aspect is mostly just for 'slickness' - content is displayed instantly, animations are used and the page only needs to be loaded once. It is becoming more popular among the web; many portfolio sites that I come across are on a single page. The portfolio, business card, resume, etc... type site is well suited for a single page since they are simple, slickness is fairly important and search engine rankings aren't as important.

A side benefit of Pagify is that it DRYs up what would otherwise be duplicated elements in content sites with static HTML pages, i.e. header, navigation and footer - and without any serverside processing.

That being said, a single page and this plugin in particular, certainly aren't the best option for all sites. The reason I made this was to make the development cost virtually the same for developing single page sites.

Had the same thought. Nice, but Y?

Why not simply make one HTML page and a couple of anchors for navigation. That would yield a simple site without the need to code anything.

-jsl

Is it just me or does this not work on iPad?

Not just you.