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.
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".Not impossible by any means, but, as Jeremy points out, it involves subtle details :)
var querystring = {};
//add actual querystring (prior to #) parameters
//add hash's querystring, overwriting any already defined keys
return querystring;
It's not that hard.This is your opinion--why should it rule the way a browser works for everyone? I think hover navigations are annoying--should Chrome break those too?
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.
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.
It's unfortunate he's chosen to spread FUD instead of going head to head on features, compat, perf, dev needs/concerns, or any other relevant area of project comparison :/
Had I known, I wouldn't say that. Perhaps an open statement from you regarding the issue would help (this HN thread will be lost to the depths of the intertubes after a few days, and it doesn't give more details of what transpired).
Built using patterns from this Backbone.js example:
Whether a link opens in a new tab without user intervention is up to the link, and is way overused IMO.
In addition, some folks currently like to mount their Backbone.js applications at a root URL that contains a query string, for example:
todolist.com/app?org=nsa#locationThat seems like the root of the problem. It seems like querystrings could otherwise be solved, but this case would certainly introduce a problem for pushState-incompatible browsers.
Is there a reason this kind of app root URL isn't considered bad practice that doesn't need to be supported? Everything about it seems wrong - now you're trying to put part of the path after the querystring.
"Then don't do that."
It seems mighty unfair that we can't have nice things because Microsoft took so long to roll out push state.
Ick. I hate doing two-finger taps as it is. I don't believe one should need anything other than a pointing device with one button to browse the web effectively. Needing to hack in ways to simulate extra buttons is bad design. Why not use a keyboard then?
Even if Chrome always opened external links in a new tab with a left click, you'd still want middleclick functionality to browse the web effectively; I constantly open multiple tabs from the same domain- for instance, to open a HN comments section without navigating away from the front page.
People shouldn't have to specify which links are external and which aren't, it should be inferred from the URL being accessed. In the rarer cases where the server is saying to open an external link in the current tab or an internal link in a new tab, that should be specified in the HTML. For the people that want specific global behavior. i.e. all new tabs to be opened in current tab, that should be a configuration option in the browser.
I think you're confusing links and tabs. I think you're trying to throw a lot of extra logic into the browser that doesn't belong there.