6 ms·

The author does his point a disservice by being under-informed, imo. I agree that Gawker's redesign is horrible, and share his hate of needless javascript (why

by ZoFreX 16y ago

The author does his point a disservice by being under-informed, imo. I agree that Gawker's redesign is horrible, and share his hate of needless javascript (why re-implement half the browser stack?), but his suggestions for improvement would actually be a reduction in functionality. He suggests using real URLs - instead of "/#!5753509/hello-world-this-is-the-new-lifehacker" we would have "/5753509/hello-world-this-is-the-new-lifehacker". Sounds great, but what happens when you click to a new article, which is loaded with AJAX? > Engineers will mutter something about preserving state within an Ajax application. And frankly, that’s a ridiculous reason for breaking URLs like that. Is it? Let's try things all possible ways (with the assumption that content is loaded via AJAX) and see what happens. Firstly, the current state: Address bar: "/#!5753509/hello-world-this-is-the-new-lifehacker", click on a link, now it's "/#!downloads/5753887". I can bookmark this, send the link to a friend, etc etc. Option two is to not track this at all, after all preserving state isn't that important, right? Address bar: "/#!5753509/hello-world-this-is-the-new-lifehacker", click a link, it doesn't change. I can't bookmark the new page, I can't send the link to a friend, my back button won't work properly. Third option is to use real URLs as he suggested... we need to track state (otherwise we hit the same problems in option 2) so let's try that: Address bar: "/5753509/hello-world-this-is-the-new-lifehacker", click a link, it now contains "/5753509/hello-world-this-is-the-new-lifehacker#!downloads/5753887". Oops. That's even less clean. Conclusion: If you must load content with AJAX, using URL fragments to track state is the most functional and cleanest-URL option available.

Isofarro 16y ago
"The author does his point a disservice by being under-informed, imo." I admit my Google searching turned up no useful results about hash-banging URLs for new websites, only Google's attempt to index sites that ignored progressive enhancement and hid all content behind Ajax calls. "Sounds great, but what happens when you click to a new article, which is loaded with AJAX?" If you want to load the content in via Ajax, you start with a valid and direct URL to a piece of content. You can then use JavaScript on the click handler to mangle the URL into a hash-bang, and then proceed as you wish. You get all the benefits of hash-bang without the downside of uncrawlable URLs. "now it's "/#!downloads/5753887". I can bookmark this, send the link to a friend, etc etc." * Bookmark it to a third party service - yes (assuming they don't truncate fragment identifiers!) * That service then retrieves the content of that article (for summarising, entity recognition, extracting microformatted data). no. The hash-bang URL is not a direct reference to the piece of content. The indirection shenanigans isn't part of HTTP/1.1 or RFC-2396. So it's not Restful for starters. "after all preserving state isn't that important, right" That can be done without making all links on the page non-traversable with a crawler. "Conclusion: If you must load content with AJAX, using URL fragments to track state is the most functional and cleanest-URL option available." a clean URL would not be an indirect reference that would need to be reformatted into a direct reference before being curled. State can be done without mangling URLs in this way.
- ZoFreX 16y ago
  > You can then use JavaScript on the click handler to mangle the URL into a hash-bang, and then proceed as you wish I wish, unfortunately this is only supported in the very latest browsers (I've literally seen one website do this [1]). You can only change the portion of the address bar following the "#" with javascript, which is why you see URLs like "/content/30485#!content/9384" in some places. The short of it is, if you insist on using AJAX to load your primary content, and to power your primary navigation, then the way they do it is the best method at our disposal at this time. Personally, I don't think the best method is good enough, but right now there is no better solution - imo, the only way to avoid this nastiness is not to load your content using AJAX in the first place! I don't see the benefit in throwing away half of HTTP, all of REST, breaking inter-operability and SEO, requiring javascript, and having ugly URLs, in order for... what? It's hard to see the plus side to be honest, this is categorically the Wrong Way to make a website and I wish people would stop doing it! [1] http://www.20thingsilearned.com/ http://www.20thingsilearned.com/
  - deleted 16y ago
    [deleted]
  - Isofarro 16y ago
    "I wish, unfortunately this is only supported in the very latest browsers (I've literally seen one website do this [1]). You can only change the portion of the address bar following the "#" with javascript, which is why you see URLs like "/content/30485#!content/9384" in some places." Okay, you are clearly missing the solution here. This is what the html looks like: <a href="path/to/page">Page</a> Then add a click handler to the link (using your preferred JavaScript library): $('a').click(function(e) { this.href = "#!" + $(this).get(0).href; }); So this code mangles your URL into a hashbang with JavaScript when the link is clicked. Now the rest of your code remains exactly the same, and updates the window.location.hash the same way as before - it gets the same value as before. Except the benefit is that with no JavaScript - like a crawler - sees a working URL. And the JavaScript then mangles the URL appropriately, leaving your framework blissfully unaware of the difference. This is progressive enhancement - using JavaScript to mangle links that are only meant to work when JavaScript is available (and in Gawker's case, make it to the browser). If you're quite confident in your JavaScript skills, you can mangle all the links on the page in one go right at DOMReady. The key is not expecting JavaScript to be running. And when JavaScript is indeed running, then mangle links to your heart's content.
sjs382 16y ago
He suggests using real URLs - instead of "/#!5753509/hello-world-this-is-the-new-lifehacker" we would have "/5753509/hello-world-this-is-the-new-lifehacker". Sounds great, but what happens when you click to a new article, which is loaded with AJAX? Well you've already confirmed that the client is running Javascript so: 1. Use JavaScript to rewrite the existing clean URLs into JS function calls (or however you want to handle that) 2. Use window.history.pushState to push the clean (canonical) URL for the page you're viewing to the browser. I'm not sure why this isn't obvious...
- gnubardt 16y ago
  history.pushState() and history.replaceState() are introduced in the html 5 spec, so not all browsers support it yet.
  - sjs382 16y ago
    Test for the API and fall back to the hashbangs if it isn't available. Check out this example in an old browser and a modern one: http://www.asual.com/jquery/address/samples/express/portfolio http://www.asual.com/jquery/address/samples/express/portfoli...
    - ZoFreX 16y ago
      My point was the degradation to hashbang (which is what most users are going to see) is absolutely horrid, to the point that I would actively avoid it.
      - sjs382 16y ago
        You're concerned about /content/123/#!/content/456/, right? Well, if the client isn't modern, 301 them to #!/content/456/ and proceed as you would. Either way though, all this is terrible for a blog, or even Twitter.
sjs 16y ago
> He suggests using real URLs - instead of "/#!5753509/hello-world-this-is-the-new-lifehacker" we would have "/5753509/hello-world-this-is-the-new-lifehacker". Sounds great, but what happens when you click to a new article, which is loaded with AJAX? I would deliver the page with plain old HTML links to other pages. On page load I'd use JavaScript to see if the new pushState[1] API is available, and if so fetch the JS required to update the page dynamically and then update the link elements to do the AJAXy thing. Seems like it would degrade gracefully in old browsers and keep the URL current in new browsers. [1] https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history https://developer.mozilla.org/en/DOM/Manipulating_the_browse... edit: is sjs382 my doppelganger?! (or vice versa)
- sjs382 16y ago
  edit: is sjs382 my doppelganger?! (or vice versa) Haha, not at all. Just my old university ID since "sjs" was taken here ;)
  - sjs 16y ago
    sjs can be a hard handle to get. had to resort to _sjs on twitter, and that was in 2007 :)
    - nailer 16y ago
      Well now you know who to blame :^).
      - sjs382 16y ago
        Not me. :p I'm sjstrutt on Twitter
- ZoFreX 16y ago
  Yes, if I were forced to use JS for loading the primary content I would do that too. There are a couple of options for doing so if you don't want to roll your own (and you don't - it is actually a very complex thing to get working cross browser), JQuery History [1] which is nice and simple, and JQuery BBQ if you need a bit more control. Personally I think it's a little early for pushState, and degrading to #! is really ugly, so for now I would say just use normal page loads like everyone else unless you have a really good reason (good reason: GMail. bad reason: glorified blog.) [1] http://tkyk.github.com/jquery-history-plugin/ http://tkyk.github.com/jquery-history-plugin/ [2] http://benalman.com/projects/jquery-bbq-plugin/ http://benalman.com/projects/jquery-bbq-plugin/

by ZoFreX 16y ago

Isofarro 16y ago

"The author does his point a disservice by being under-informed, imo." I admit my Google searching turned up no useful results about hash-banging URLs for new websites, only Google's attempt to index sites that ignored progressive enhancement and hid all content behind Ajax calls. "Sounds great, but what happens when you click to a new article, which is loaded with AJAX?" If you want to load the content in via Ajax, you start with a valid and direct URL to a piece of content. You can then use JavaScript on the click handler to mangle the URL into a hash-bang, and then proceed as you wish. You get all the benefits of hash-bang without the downside of uncrawlable URLs. "now it's "/#!downloads/5753887". I can bookmark this, send the link to a friend, etc etc." * Bookmark it to a third party service - yes (assuming they don't truncate fragment identifiers!) * That service then retrieves the content of that article (for summarising, entity recognition, extracting microformatted data). no. The hash-bang URL is not a direct reference to the piece of content. The indirection shenanigans isn't part of HTTP/1.1 or RFC-2396. So it's not Restful for starters. "after all preserving state isn't that important, right" That can be done without making all links on the page non-traversable with a crawler. "Conclusion: If you must load content with AJAX, using URL fragments to track state is the most functional and cleanest-URL option available." a clean URL would not be an indirect reference that would need to be reformatted into a direct reference before being curled. State can be done without mangling URLs in this way.

ZoFreX 16y ago
> You can then use JavaScript on the click handler to mangle the URL into a hash-bang, and then proceed as you wish I wish, unfortunately this is only supported in the very latest browsers (I've literally seen one website do this [1]). You can only change the portion of the address bar following the "#" with javascript, which is why you see URLs like "/content/30485#!content/9384" in some places. The short of it is, if you insist on using AJAX to load your primary content, and to power your primary navigation, then the way they do it is the best method at our disposal at this time. Personally, I don't think the best method is good enough, but right now there is no better solution - imo, the only way to avoid this nastiness is not to load your content using AJAX in the first place! I don't see the benefit in throwing away half of HTTP, all of REST, breaking inter-operability and SEO, requiring javascript, and having ugly URLs, in order for... what? It's hard to see the plus side to be honest, this is categorically the Wrong Way to make a website and I wish people would stop doing it! [1] http://www.20thingsilearned.com/ http://www.20thingsilearned.com/
- deleted 16y ago
  [deleted]
- Isofarro 16y ago
  "I wish, unfortunately this is only supported in the very latest browsers (I've literally seen one website do this [1]). You can only change the portion of the address bar following the "#" with javascript, which is why you see URLs like "/content/30485#!content/9384" in some places." Okay, you are clearly missing the solution here. This is what the html looks like: <a href="path/to/page">Page</a> Then add a click handler to the link (using your preferred JavaScript library): $('a').click(function(e) { this.href = "#!" + $(this).get(0).href; }); So this code mangles your URL into a hashbang with JavaScript when the link is clicked. Now the rest of your code remains exactly the same, and updates the window.location.hash the same way as before - it gets the same value as before. Except the benefit is that with no JavaScript - like a crawler - sees a working URL. And the JavaScript then mangles the URL appropriately, leaving your framework blissfully unaware of the difference. This is progressive enhancement - using JavaScript to mangle links that are only meant to work when JavaScript is available (and in Gawker's case, make it to the browser). If you're quite confident in your JavaScript skills, you can mangle all the links on the page in one go right at DOMReady. The key is not expecting JavaScript to be running. And when JavaScript is indeed running, then mangle links to your heart's content.

sjs382 16y ago

He suggests using real URLs - instead of "/#!5753509/hello-world-this-is-the-new-lifehacker" we would have "/5753509/hello-world-this-is-the-new-lifehacker". Sounds great, but what happens when you click to a new article, which is loaded with AJAX? Well you've already confirmed that the client is running Javascript so: 1. Use JavaScript to rewrite the existing clean URLs into JS function calls (or however you want to handle that) 2. Use window.history.pushState to push the clean (canonical) URL for the page you're viewing to the browser. I'm not sure why this isn't obvious...

gnubardt 16y ago
history.pushState() and history.replaceState() are introduced in the html 5 spec, so not all browsers support it yet.
- sjs382 16y ago
  Test for the API and fall back to the hashbangs if it isn't available. Check out this example in an old browser and a modern one: http://www.asual.com/jquery/address/samples/express/portfolio http://www.asual.com/jquery/address/samples/express/portfoli...
  - ZoFreX 16y ago
    My point was the degradation to hashbang (which is what most users are going to see) is absolutely horrid, to the point that I would actively avoid it.
    - sjs382 16y ago
      You're concerned about /content/123/#!/content/456/, right? Well, if the client isn't modern, 301 them to #!/content/456/ and proceed as you would. Either way though, all this is terrible for a blog, or even Twitter.

sjs 16y ago

> He suggests using real URLs - instead of "/#!5753509/hello-world-this-is-the-new-lifehacker" we would have "/5753509/hello-world-this-is-the-new-lifehacker". Sounds great, but what happens when you click to a new article, which is loaded with AJAX? I would deliver the page with plain old HTML links to other pages. On page load I'd use JavaScript to see if the new pushState[1] API is available, and if so fetch the JS required to update the page dynamically and then update the link elements to do the AJAXy thing. Seems like it would degrade gracefully in old browsers and keep the URL current in new browsers. [1] https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history https://developer.mozilla.org/en/DOM/Manipulating_the_browse... edit: is sjs382 my doppelganger?! (or vice versa)

sjs382 16y ago
edit: is sjs382 my doppelganger?! (or vice versa) Haha, not at all. Just my old university ID since "sjs" was taken here ;)
- sjs 16y ago
  sjs can be a hard handle to get. had to resort to _sjs on twitter, and that was in 2007 :)
  - nailer 16y ago
    Well now you know who to blame :^).
    - sjs382 16y ago
      Not me. :p I'm sjstrutt on Twitter
ZoFreX 16y ago
Yes, if I were forced to use JS for loading the primary content I would do that too. There are a couple of options for doing so if you don't want to roll your own (and you don't - it is actually a very complex thing to get working cross browser), JQuery History [1] which is nice and simple, and JQuery BBQ if you need a bit more control. Personally I think it's a little early for pushState, and degrading to #! is really ugly, so for now I would say just use normal page loads like everyone else unless you have a really good reason (good reason: GMail. bad reason: glorified blog.) [1] http://tkyk.github.com/jquery-history-plugin/ http://tkyk.github.com/jquery-history-plugin/ [2] http://benalman.com/projects/jquery-bbq-plugin/ http://benalman.com/projects/jquery-bbq-plugin/