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...

This was my initial reaction as well, but I appreciate the qs/hash sugaring:

    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)

I think that's a bit too much functionality to put down as "sugar".

Agreed, this is the way to do it. The only caveat is that IE has a bug where it omits the leading / on the pathname. You can normalize it with a simple one-liner: http://stackoverflow.com/a/6168370/172322

> Agreed, this is the way to do it.

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.

Not the same thing. jQuery is worth it if you're doing lots of DOM element selection. If the entirety of your usage of jQuery is a single $("#foo").bind(...) call, then it's probably not worth loading the entire library for that.

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.

Extracting Host, Subdomain and TLD from a url is hard. And they clearly oversimplified it.

  $.url('host', 'http://www.google.com.br');  // 'com.br'
  $.url('sub',  'http://www.google.com.br');  // 'www.google'
  $.url('tld',  'http://www.google.com.br');  // 'br'

It will work for simple cases where the TLD has only one field like (www.google.com) or (www.usa.gov), but it will fail for any other tld with country codes.

That is partially incorrect. There is no such thing as a TLD with more than one field. In "http://www.google.com.br, "br" is, in fact, the TLD, while "com" is the SLD[1]. So the 'tld' behavior is fine.

The "sub" behavior is awkward, however. It would make more sense to just have a numeric way of accessing the domain parts by index, just like they do with extracting the path elements.

As for "host", well that is just completely the wrong behavior. Since the parameter is "host", you would expect that to give the hostname. But the hostname corresponding to an internet URL is simply the fully qualified domain name. I have no idea how the behavior implemented would be useful in the first place, but it certainly shouldn't be called "host".

[1] http://en.wikipedia.org/wiki/Country_code_second-level_domai...

Domain parsing is hard. PublicSuffix service seems to be the best way of doing it. http://stackoverflow.com/questions/288810/get-the-subdomain-...

I like, but I'm curious why this is a jQuery plugin.

Looking at the source, it looks like there's only one line that calls jQuery on line 37 (and I don't think it should be using the short calling convention without a wrapper -- if you rename jQuery to '_' or something else it won't work):

    else if($.isNumeric(arg)

There's no native JavaScript equivalent to it if I recall correctly, but there's a bunch of alternatives to it as well.

It should be easy enough to extract out the logic and repackage it. Maybe I'll fork it tomorrow and do the changes myself.

jQuery simply does this:

  isNumeric: function( obj ) {
    return !isNaN( parseFloat(obj) ) && isFinite( obj );
  }

I think a good alternative would be just to accept a number. url(1) instead of url('1')

No clue, but it's nice to have a namespace for it, rather than mucking up the global context with a simple utility method. Might be better off shimmying up to underscore (perhaps only if it's already detected, otherwise go global?), however there are lots of similar jquery 'plugins' of this nature..

Modules are the way to go, not polluting an arbitrary namespace.

I presume to allow for idiomatic use in code that already uses a lot of jQuery:

    var file = $('a#interesting').url('file')

vs

    var file = url($('a#interesting'), 'file');

I don't see what DOM has to do with URL parsing.

this has nothing to do with jquery, stop the madness! haha

https://github.com/component/component/wiki/Building-better-...

https://github.com/component/url

Well I really wasn't expecting this much feedback for this little library. I threw it up for kicks and went out for a movie, when I came back I was surprised to see all the interest. It's just a simple parser I wrote for my projects, so it doesn't get too crazy with exact definitions of "tld" and support for IPv4/IPv6 addresses as mentioned in the comments. Might be better to create a secondary more heavyweight version for things like that.

Anyway, I've fixed/updated a bunch of things from the comments, if anyone finds any other bugs or missing features probably best to leave me an issue on the github project page here: https://github.com/websanova/js-url/issues.

The project has also been un-jquery-ified and renamed to js-url (thanks to Jay Adkisson : https://github.com/jayferd)

Thanks

Parsing url is difficult and prone to errors. How $.url() compares to furl? There are two furl(s) on github:

(1) https://github.com/stricaud/furl

and

(2) https://github.com/gruns/furl

furl(1) seems to handle a lot of edge cases when the URL is containing an IPv4/IPv6 address or when the URL is partial (e.g. without the protocol). furl(1) aims is to be fast. furl(2) seems to be more flexible and used for inline modification of the URL.

I actually renamed the furl project into faup, for 'Finally An Url Parser' ;-) That should solve the problem. API and command line tool will follow.

Nice little utility, just a couple of issues that should be easy to fix:

- Breaks for protocols other than http/https, including protocol-relative urls.

- Breaks query string values that contain '='.

Nice. And prezjordan has a good question. Why is it a jquery plugin?

As others have suggested, jQuery is overkill for this.

The best lightweight js library I've found/used in the past is parseUri:

http://blog.stevenlevithan.com/archives/parseuri

Obviously, if you only need to analyze the current URL, you can use window/document.location, but there are times when you want to parse a URI for a page you aren't on. For instance, if you are analyzing har data, and want to break URI "components" into columns so they are sortable.

I have a hard time seeing why, these days, an extra 1.2k for something that makes a task simpler and more consistent is ever "overkill".

jQuery is not 1.2k.

And this library doesn't have a strong reason to tie itself to jQuery. It doesn't need jQuery's DOM operation or AJAX. It's like making a program depending on third party library without actually using any of the feature.

Or rather it's using the jquery namespace for a utility function much like many of those provided by jquery, like isnuneric for example.

It uses just one function from jQuery, `isNumeric`, which is a function that is a one liner.

And if you follow the project again, you will see that it has become a regular non-jQuery library.

It looks like this has been moved and is no longer a jQuery plugin, which is awesome. It's now, however, creating a global variable named `url` which is dangerous to say the least.

I have OCD about code cleanliness... No semicolon at the end of line 26? Please excuse me as I proceed to gag.

But me being a douche aside, I'm not sure why you needed to extend from/bake into jQuery for this.

If the url doesn't contain the required component, it will throw errors. Why not return an empty string like urlparse does?

How it compares against http://code.google.com/p/jsuri/ ?

I would be interested too to see a comparison with jsuri. I was about to say that jsuri is not maintained anymore but looking closer on http://code.google.com/p/jsuri/ I saw that now the project is active on github: https://github.com/derek-watson/jsUri with the latest version being 1.2.2

There's also an attempt I made, https://github.com/theozaurus/jsurlify which tries to keep the usage as terse as possible. It would be great to see what strengths / weaknesses all these different libraries have and try to join efforts where sensible.

Thanks for having the link go directly to examples.

You might find this useful: https://developer.mozilla.org/en-US/docs/DOM/window.location...

to quote my favorite seen from the lion king reference: "http://www.imdb.com/character/ch0000591/quotes "look harder". You can parse URL's in JavaScript using window.location or anchor.href, both provide solutions for parsing URL's... someone else from this thread referenced: http://stackoverflow.com/questions/6168260/how-to-parse-a-ur... (above i believe)...

.. and I still have to roll my own library or inline code for parsing apart GET params. No thanks.