Just FYI, most, if not all, of this is built into javascript already, via the DOM. http://www.joezimjs.com/javascript/the-lazy-mans-url-parsing...
http://www.domain.com/path/index.html?query1=test&silly=willy#test=hash&chucky=cheese
$.url('?'); // query1=test&silly=willy
$.url('?silly'); // willy
$.url('?poo'); // (an empty string)
$.url('#'); // test=hash&chucky=cheese
$.url('#chucky'); // cheese
$.url('#poo'); // (an empty string)This sounds like arguing that we should use getElementById&al, addEventListener, and array.length with for loops instead of $('selector').on 'foo' and .each(). While this lib's inner code leaves to be desired in a number of ways, I really appreciate the readability and the lack of need to instantiate a full-blown DOM element then read a property to obtain a simple single result or two.
URL parsing, for 90% of uses, tends to be a one-off need that doesn't really justify the addition of another library. Making decisions about what library to include is about trade-offs; this library is worth it if you need the query string sugaring or are doing lots of URL parsing. But "instantiating a full blown DOM element" to parse a single URL is over-stating the cost of the activity, especially when compared to adding an additional library to your application.