Live data from Hacker News

Why JavaScript web applications should embrace traditional URLs

9elements.com

1–10 of 45 posts

Re: Why JavaScript web applications should embrace traditional URLs

#5
I like some of Jeremy Ashkenas work (in fact I use some of it daily), but he has jumped the shark with this one.

Another bad sign is that he also removed lo-dash (a better underscore.js clone, that fixes several issues, is faster, passes all the same tests AND also strives to support Backbone.js) from the backbone docs.

Re: Why JavaScript web applications should embrace traditional URLs

#6
The fundamental problem with attempting to transparently support querystrings on the client-side -- touched on a bit in this article, but not explained completely, is this:

Querystrings are a server-side convention for URLs containing parameters -- the browser doesn't traditionally parse them. If you ask for document.location.search, you'll get back an opaque string containing the query part that you'll have to parse yourself.

The point of Backbone's router is to be able to transparently support both pushState-based routing, with real URLs, as well as onhashchange-based routing, for older browsers that can't do real URLs via JavaScript. So, if you add querystring generation and parsing support to Backbone's router (as some plugins do), and use pushState, everything starts off looking peachy. But as soon as you run into an older browser, and try to fall back to the hash-based URL equivalent, you run into trouble:

    /app?query=string#home?query=other
... now you have the possibility to have to merge two different sources of query string, and still keep transparent redirects working back and forth between the two schemes.

I'd be more than happy to merge an implementation that supports them -- but that implementation needs to solve this particular problem, and have a relatively bulletproof way of supporting the querystring logic parsed out of real URLs and transferred to the fragment, and vice-versa ... and also has to have a strategy for dealing with URLs of the above breed. The devil, as always, is in the details.

Re: Why JavaScript web applications should embrace traditional URLs

#7
I'm getting rank sick of the growing number of websites killing the functionality of the back button. That, combined with Chromes senseless refusal to implement opening clicked urls that are on another domain in a new tab, means I'm often forced to click-and-hold the back button to get somewhere. Incredibly annoying.

Re: Why JavaScript web applications should embrace traditional URLs

#8
post #5

I like some of Jeremy Ashkenas work (in fact I use some of it daily), but he has jumped the shark with this one. Another bad sign is that he also removed lo-dash (a better underscore.js clone, that fixes several issues, is faster, passes all the same tests AND also strives to support Backbone.js) from the backbone docs.

To try and nip this particular thread in the bud -- I think that forks in general, and Lodash in particular, are great. As CoffeeScript has Coco, Redux, Kaffeine, and LiveScript; as Backbone has Spine; Underscore has Lodash. They're fertile ground for exploring different approaches.

My problem isn't with the Lodash project, just with the unfortunate fact that the maintainer has had some incredibly toxic behavior with respect to cooperating around open-source. Without getting into details, as soon as he's ready to collaborate in a pleasant and productive fashion, he's welcome to have his commit access back to Underscore, and merge in whatever he likes.

Re: Why JavaScript web applications should embrace traditional URLs

#10

The fundamental problem with attempting to transparently support querystrings on the client-side -- touched on a bit in this article, but not explained completely, is this: Querystrings are a server-side convention for URLs containing parameters -- the browser doesn't traditionally parse them. If you ask for document.location.search, you'll get back an opaque string containing the query part that you'll have to parse…

> now you have the possibility to have to merge two different sources of query string

Not really:

  if hashMode and queryStringInHash
    parseQueryStringFromHash
  else
    parseRealQueryString
You don't have to merge. Just if you modify the query string and are in "hashMode" then just push the "real querystring" elements you parsed first into the "hashquery string".
Post reply on HN