URI.js is a facility for working with URLs | Hacker News Reader

URI.js is a facility for working with URLs

medialize.github.com

109 pointswslh43 comments

I and Timo Tijhof wrote a similar library which is now shipping with MediaWiki. It does a lot less, but it's about 1/4 the size.

source: https://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/reso...

tests: https://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/test...

Been meaning to make a Github repo for this. Any interest?

According to Google's Closure Compiler URI.js is compiled down to 11.81KB (3.38KB gzipped) Including punycode.js and IPv6.js you get 15.03KB (4.87KB gzipped) added your link to the alternatives section in README.md

Sorry for threadjacking. Just my regrets about not packaging mine sooner.

http://medialize.github.com/URI.js/docs.html#normalize-searc...

So the current behaviour is to turn "?&foo=bar&&foo=bar" into "?foo=bar". I've coded a few client-side scripts where removal of unneeded ampersands was useful, but at the same time I needed to keep both repeated name-value pairs (for more advanced form submissions).

I would suggest making normalizeSearch less destructive - i.e. only targeting the unused question mark and ampersands - and splitting the name-value pair deduplication into a separate method.

Liking the jQuery-style method chaining.

Github has a nice little feature called issue tracking. Feel free to post your thoughts there. I'd be happy to figure something out. URI.js wasn't intended to limit anyone in what they were trying to do. It just never occured to me that ?foo=bar&foo=bar could be intentional.

This is NOT "jQuery style". This is an actual decent use of OOP and Method Chaining.

jQuery does use Method Chaining but it actually discourages the use of good JS OOP.

I figured more people understand "jQuery-style" than "fluent interface" / "method chaining". Pretty much like you call a tissue "Kleenex" (or "Tempo" in German).

I honestly think that HackerNews readers would understand "fluent interface."

Do you honestly think I ever thought about my dimwit-no-rocket-science URI.js ending up on hacker news? But, to satisfy hacker news readers, I added the terms "fluent interface" and "method chaining" (while preserving "jQuery-like" for normal folk…)

Not to be dismissive, but I feel that if you're a jQuery user, you shouldn't be calling it jQuery-like|style|whatever suffix either. The purpose of terms like fluent interface is so that we can identify a pattern and speak a common language.

Cool work none the less, I didn't give you props in my original post.

You can't google "jquery-style" and get helpful information.

Calling it URI.js is a bit namespace-squatty, no? Also, calling everything after the ? the search is a little weird. I used http://code.google.com/p/jsuri/ to build it up on PlaceSteal.

+1 : http://www.ietf.org/rfc/rfc3986.txt

Referring to the query as "search" makes no sense whatsoever.

According to the docs[1], search() is an alias of query(). They should use query instead of search, atleast on the landing page. Also, they should put hash() method on the homepage too, I thought they forgot to implement it.

[1] http://medialize.github.com/URI.js/docs.htm

they just fixed it…

Maybe they used search because of "window.location.search".

It makes sense if you're trying to stick with the window.location.search convention. https://developer.mozilla.org/en/DOM/window.location#section...

I actually groaned when I figured out what "search" was.

"search" is the term for "query string" used throughout javascript. I prefer "query" (as in "query string"). I use query(), but made search() available to those, who are used to window.location.search

for some more groaning, have a look at http://tantek.com/2011/238/b1/many-ways-slice-url-name-piece... ;)

> "search" is the term for "query string" used throughout javascript.

Huh? Where?

window.location.search - https://developer.mozilla.org/en/DOM/window.location#Propert...

and decomposed IDL - http://www.whatwg.org/specs/web-apps/current-work/multipage/...

You can do a lot of URI parsing without a library at all -- it's built into the DOM of every browser, even IE6.

  var temp = document.createElemenet('a');
  temp.href = 'http://www.google.com/search?q=foo#blah;
  alert(temp.hostname); // www.google.com
  alert(temp.hash);     // #blah
  alert(temp.protocol); // http:
  alert(temp.search);   // ?q=foo
  temp.search = '?q=baz';
  alert(temp.href);     // http://www.google.com/search?q=baz#blah

  // assuming this is running on http://www.example.com:
  temp.href = '/asdf.html';
  alert(temp.href);     // http://www.example.com/asdf.html

That is noted in README.md of URI.js - you can also find a (very simple) performance comparison here: http://jsperf.com/idl-attributes-vs-uri-js

Does the IDL stuff work in non-browser Javascript (like node.js)?

Node has http://nodejs.org/docs/latest/api/url.html built-in.

URI.js could be really useful for developers building web apps that need to do a lot of URL parsing or manipulation. But developers who only need basic functionality outside of performance-critical loops would probably be better off using built-in functionality.

Is anyone aware of a directory of all the js libraries cropping up? If not, shouldn't we crowdsource one?

http://microjs.com/

What is it with these giant fonts? Why the useless scrolling when you could fit three times the information on one screen? I see this nonsense all over the place...

The select box almost gave me a heart attack when I opened it.

What I would do for JSAN to be all it could have been :-/

One of the things I found building up the PlaceSteal magical library was I needed an actual build/compilation step for turning the various external Javascript libraries I had in to one that would happily go through the Google compiler.

This included a whole bunch of hand-added patches for - for example - moving object-key specification in to one of dot notation or []notation. There were also a bunch of random patches to make things do what I wanted them to do, that didn't seem to be easily done via subclassing or poking around on the insides.

I'm pretty worried about the consequences when I have to upgrade one of the constituent libraries.

I've been working on one as I've got something of a hobby of "collecting" JS libraries - http://resjs.com

It's JSON powered similar to microjs.com (a great site, just not all inclusive) and I've still just got some work to go in terms of adding all the data I've got collected. If there's any interest, I could throw it up on Github and accept contributions to the data.

(One thing that may not be clear at this stage is that each lib will be tagged by license, dependencies, link to source code and/or documentation depending on availablility and have a short description)

Would love any general feedback too.

Closure Library also has a class for doing this:

http://www.google.com/codesearch#epIciakqvFc/trunk/closure/g...

what is really needed is a good and well documented/tested javascript library for parsing and comparing URLs

I have a bunch of functions (parse_params, get_host, etc.) across a number of projects and always find new bugs with weird URLs that are out in the wild.

URI.js now has a feature to test equality of URIs - medialize.github.com/URI.js/docs.html#equals - is that what you were looking for?

yes - thank you! I will take a look at it this weekend and if I have anything in my set of functions that isn't there and might be useful I will submit a pull request.

I have been looking for something like this in PHP, any ideas?

PHP's has mature URI parsing using several built-in functions that provide very similar functionality.

parse_url http://us.php.net/parse_url for getting URI components

parse_str http://us.php.net/parse_str for getting query string variables

These two functions take care of the vast majority of my URI parsing/creation tasks.

Of course it would be nice to have a fluent interface like URI.js via a PHP class. And the URI normalization functions.

Tnx, I knew about those, I am currently building the fronted for the Solr powered search engine (adding/removing facets from the url) and sometimes it gets pretty messy.

I was hoping there are some existing resources before I start porting this...

Funny… URI.js is more or less a port of my PHP URL class. Zend Framework has one. look at https://gist.github.com/1499238 to get you started. (Not a chainable API and not as powerful as URI.js either). The path resolving can be taken from the code I wrote for Smarty a couple of months ago: http://code.google.com/p/smarty-php/source/browse/trunk/dist... - lemme know if/when/how you're done… interested in using the PHP version myself ;)

facility = library, header, class, precompiled binary?

Please save me having to visit your repo by using accepted terminology if possible...

.js = javascript. it's a javascript library for manipulating URIs.

replaced "facility" by "library"…

why is this licensed under GPLv3?

It is dual-licensed, MIT and GPL. Choose the MIT License to do what the fk you like. Choose the GPL License if you're building some GPL software yourself, and need all the components to be GPL-licensed as well. Maybe have a look at http://en.wikipedia.org/wiki/Multi-licensing

Reply on news.ycombinator.com