4 ms·

I continue to enjoy keeping an eye on these single-page style web apps for very basic content applications. I have a feeling this was pretty quick and easy for

I continue to enjoy keeping an eye on these single-page style web apps for very basic content applications. I have a feeling this was pretty quick and easy for the developers to put together. That said, a few things jump out at me that make me think this approach isn't ready for primetime (or to be more precise, takes a lot more work to make it ready for primetime) * Individual properties are not reflected in the URL, meaning I couldn't copy and paste a link to someone * This is using a plain hash instead of a hash bang, which, correct me if I'm wrong, means sub pages are not hit by search engines * If javascript is disabled and I load this, I get a blank screen. It's this kind of thing that makes me fearful of pursuing this approach for more serious projects...

shivang 15y ago
* Yes, Individual properties should have been reflected in the url. Actually if you type in the property in the search box it is creating a url which does the work, but clicking on a property is not making the link. Hope they'll refine it a bit.
deleted 15y ago
[deleted]
naa42 15y ago
Also this approach breaks keyboard navigation and accessibility. It is almost as bad as Flash.
jashkenas 15y ago
> * This is using a plain hash instead of a hash bang, > which, correct me if I'm wrong, means sub pages are > not hit by search engines. Fortunately, you're wrong about hashbangs. They were a temporary hack to allow the GoogleBot to index Ajax-driven pages before the HTML History API existed. Because of New Twitter, many sites have cargo-culted the hashbang without implementing the required "escaped_fragment" functionality on the server-side to make it actually work. It's the web developer equivalent of an SEO rain dance. Please don't use hashbangs in 2011. Use pushState() if you're a public-facing site that needs to be indexed by search engines.
- jsdalton 15y ago
  TIL. Thanks for disabusing me of the notion that this is a good idea. I have seen it used in numerous places which is what led me to assume it was the "right" way. I assume, then, that the developers of this site could have used pushState() instead of the hash? I mean, I assume that Backbone encourages this style if the developer makes use of it.
  - jashkenas 15y ago
    Backbone encourages pushState() if you can swing it -- you'll need to implement every client-side route as a server-side page as well ... so it's not possible if you're hosted in an inflexible environment. Backbone falls back to hashes for browsers that don't support the API, and transparently converts URLs between the two. But regular hashes ("#") are fine for internal single-page-apps that don't need google indexing -- of which the majority of Backbone projects probably are. It's just the hashbang "#!" that's a particular pet peeve of mine ;)
- huhtenberg 15y ago
  Can you elaborate? I don't follow how pushState (being a javascript function) replaces the need for _escaped_fragment contraption for letting crawlers fetch page snapshots in a specific state.
  - Skalman 15y ago
    With pushState you can actually push a URL without the hash. It looks like I'm GETting /about, while it's really just / with the content of /about fetched via AJAX. A HTTP GET /about should of course give the same content as the AJAX version.
    - huhtenberg 15y ago
      Right, but this still doesn't alleviate the need for "prerendering" specific pages for the crawler, which is the most tedious part of the whole thing. In other words, when a crawler requests /about, it should be getting a fully-formed About page with the content already in place, and not a bare container that ajax'es the content on page load (which is how most of pageless sites work).
kodablah 15y ago
Many single page interface sites do put the parameters in the URL in the fragment. It's kind of a hack, but the link should still work if done correctly. It is still best to use history.js or something that will only resort to fragments when the History API isn't supported. The real problem is the developer not respecting the href in the anchor and only handling onclick. This prevents you from saving the shortcut easily, opening in a new tab, etc. I like the approach Google+ and others have taken which says "use the href unless left clicked and no modifiers (i.e. ctrl, alt, shift) are pressed.
qw 15y ago
I know I'm showing my age by saying this, but I really don't see the benefit of AJAX in this case. It's basically a frameset powered by javascript, so why not just use a frameset to begin with? It would work in more browsers without issues with back-buttons and take advantage of their built in functionality. AJAX has its place, but I don't see it here. Edit: I find it amusing that the documentation for the <frameset> tag is missing :-)
- wmblaettler 15y ago
  If I am not mistaken the main problem with a frameset would be that the URL in the address bar will never change and therefore you cannot link directly to a page within the frame, i.e. where a user wants to copy the URL and share with a colleague.
  - qw 15y ago
    You could still use javascript with a hash in the URL to keep track of the current page so that it can be bookmarked.
jmarranz 15y ago
You are wrong, take a look to this demo: http://www.innowhere.com:8080/insites/ http://www.innowhere.com:8080/insites/ * You can copy and paste a link to someone * Sub pages are hit by search engines * Works with JavaScript disabled

shivang 15y ago

* Yes, Individual properties should have been reflected in the url. Actually if you type in the property in the search box it is creating a url which does the work, but clicking on a property is not making the link. Hope they'll refine it a bit.

deleted 15y ago

[deleted]

naa42 15y ago

Also this approach breaks keyboard navigation and accessibility. It is almost as bad as Flash.

jashkenas 15y ago

> * This is using a plain hash instead of a hash bang, > which, correct me if I'm wrong, means sub pages are > not hit by search engines. Fortunately, you're wrong about hashbangs. They were a temporary hack to allow the GoogleBot to index Ajax-driven pages before the HTML History API existed. Because of New Twitter, many sites have cargo-culted the hashbang without implementing the required "escaped_fragment" functionality on the server-side to make it actually work. It's the web developer equivalent of an SEO rain dance. Please don't use hashbangs in 2011. Use pushState() if you're a public-facing site that needs to be indexed by search engines.

jsdalton 15y ago
TIL. Thanks for disabusing me of the notion that this is a good idea. I have seen it used in numerous places which is what led me to assume it was the "right" way. I assume, then, that the developers of this site could have used pushState() instead of the hash? I mean, I assume that Backbone encourages this style if the developer makes use of it.
- jashkenas 15y ago
  Backbone encourages pushState() if you can swing it -- you'll need to implement every client-side route as a server-side page as well ... so it's not possible if you're hosted in an inflexible environment. Backbone falls back to hashes for browsers that don't support the API, and transparently converts URLs between the two. But regular hashes ("#") are fine for internal single-page-apps that don't need google indexing -- of which the majority of Backbone projects probably are. It's just the hashbang "#!" that's a particular pet peeve of mine ;)
huhtenberg 15y ago
Can you elaborate? I don't follow how pushState (being a javascript function) replaces the need for _escaped_fragment contraption for letting crawlers fetch page snapshots in a specific state.
- Skalman 15y ago
  With pushState you can actually push a URL without the hash. It looks like I'm GETting /about, while it's really just / with the content of /about fetched via AJAX. A HTTP GET /about should of course give the same content as the AJAX version.
  - huhtenberg 15y ago
    Right, but this still doesn't alleviate the need for "prerendering" specific pages for the crawler, which is the most tedious part of the whole thing. In other words, when a crawler requests /about, it should be getting a fully-formed About page with the content already in place, and not a bare container that ajax'es the content on page load (which is how most of pageless sites work).

kodablah 15y ago

Many single page interface sites do put the parameters in the URL in the fragment. It's kind of a hack, but the link should still work if done correctly. It is still best to use history.js or something that will only resort to fragments when the History API isn't supported. The real problem is the developer not respecting the href in the anchor and only handling onclick. This prevents you from saving the shortcut easily, opening in a new tab, etc. I like the approach Google+ and others have taken which says "use the href unless left clicked and no modifiers (i.e. ctrl, alt, shift) are pressed.

qw 15y ago

I know I'm showing my age by saying this, but I really don't see the benefit of AJAX in this case. It's basically a frameset powered by javascript, so why not just use a frameset to begin with? It would work in more browsers without issues with back-buttons and take advantage of their built in functionality. AJAX has its place, but I don't see it here. Edit: I find it amusing that the documentation for the <frameset> tag is missing :-)

wmblaettler 15y ago
If I am not mistaken the main problem with a frameset would be that the URL in the address bar will never change and therefore you cannot link directly to a page within the frame, i.e. where a user wants to copy the URL and share with a colleague.
- qw 15y ago
  You could still use javascript with a hash in the URL to keep track of the current page so that it can be bookmarked.

jmarranz 15y ago

You are wrong, take a look to this demo: http://www.innowhere.com:8080/insites/ http://www.innowhere.com:8080/insites/ * You can copy and paste a link to someone * Sub pages are hit by search engines * Works with JavaScript disabled