5 ms·

I could not figure out what this article was trying to say. Either I'm tireder than I think I am or it's really badly written.

• lamby 16y ago
  That #! urls are ugly. I can understand the technical necessity for them but I have no idea why you would want to redirect from example.com/foo => example.com/#!/foo -- do it the other way around instead and then the #! becomes a implementation detail of your internal AJAX-based navigation of your site rather than a public URL change. Actually, for a company whose mainstream success can be mainly attributed to citations in newspapers and the media at large, I find it surprising Twitter chose such an ugly URL scheme due to the obvious difficulties in typing URLs you've seen offline that include #!-like warts.
  • underdown 16y ago
    I think having a consistent permalink helps to encourage better linking. The more redirects you have before a link reaches it's destination URL the less juice you get. From a "going forward" perspective it makes some sense to enforce the hash bang.
    • benologist 16y ago
      Why did the hash bang make sense at all though? What was wrong with twitter.com/username that hash bangs somehow fix?
      • robryan 16y ago
        I guess the main technical reason is that if your on one page and click to another, you want the url to change so that if you copy and paste the link it's from the url of the page you are on. If you have proper separate links to the the other page I assume updating the address would trigger a new http request? In terms of just loading the ones page I don't see any reason why you couldn't use the normal structure and have js get what it needs for an ajax request from that.
        • wahnfrieden 16y ago
          You also want it to change so that you can add to the browser history -- so the back button will work. The hash is actually an outdated method now, it's important to note. HTML5 introduced replaceState and pushState which allow rewriting the parts of the URL after the domain with JavaScript. So no more hashes in the URL except for page anchors.
          • robryan 16y ago
            True, the hash method works everywhere though with little changes, if you go the new html5 method you need to support both that and the hash method for the IE7, etc.
            • wahnfrieden 16y ago
              Of course, you will just use an abstraction which detects if that feature is available and falls back to hashes. Feature detection and graceful fallbacks is par for course with JS.
• daxelrod 16y ago
  The problem is that the meaningful part of the URL is only sent to the server via JavaScript. Your browser doesn't normally send the fragment (the part after the #) when you access a page. That means there's no fallback for when the JavaScript breaks (which just happened) or for crawlers (except Google), browsers without JavaScript, etc. The site has absolutely no content without working JavaScript. The author asserts that this also breaks caching. (AFAICT, more analysis would be needed to support this, because the extra request the JavaScript makes may very well be correctly cacheable.)
  • waqf 16y ago
    Thanks. What got me was that for some reason I couldn't figure out whether I was being told why the author thought #! was a bad idea, or why Lifehacker had thought it was a good idea.
  • deleted 16y ago
    [deleted]
  • wahnfrieden 16y ago
    This article is really out of date, and only describes a problem with older browsers. This problem will be mostly eradicated with the new pushState and replaceState functions in HTML5, which allow you to rewrite the URL without needing hashes. So while the URL will be changed by JS as you navigate a web app, if someone saves the link and puts it on their own page and Google spiders the link, it will work fine (so long as you send the entire page when the request is not via XHR) because the entire URL is sent in the request, unlike with hashes. The problem is with Google visiting your site and trying to spider it. There are other solutions for this though.