matryer

Would this involve a timeout or maximum plugin count? Something like that? Please do open a ticket.

I use this to brag about my open-source impact.

I use it to keep track of the current BitCoin values on Coinbase.

var obj = {

  /**
   * Says something in the console.
   *
   * say(msg) - Says something once.
   * say(msg, times) - Says something many times.
   */
  say: Over(
    function(msg$string){
      console.info(msg$string);
    },
    function(msg$string, times$number){
      for (var i = 0; i < times$number; i++) this.say(msg$string);
    }
  )

};

... and vice-versa

We just thought it did too much for what we needed. It's a great library, and if I were parsing URLs in my apps I'd use it. But we just wanted a single get() interface and support for complex objects in the URL.

Arg.js turns an object like this:

    {
      tags: ["one", "two", "three"],
      deep: {
        nested: {
          objects: true
        }
      }
    }

into this:

    #?tags[0]=one&tags[1]=two&tags[2]=three&deep.nested.objects=true

for nested data - I 100% agree. I'd do that and use params for things like ordering or filtering on other fields:

    http://mystore.com/electronics/computers/manufacturer/apple/type/laptop#?order=-price&size=medium

Also - the `#` is nice for when you don't want to reload the page.

Ohh that sounds good... I've never done it before - fancy giving me a pull request? :)

URL parameters ARE RESTful and I agree that your use case is exactly where parameters are useful.

... I do like the 'routing all paths to one page' idea though.

I love that style too actually - and always prefer it when I can. Sometimes, you just need parameters.

But more and more I'm writing apps with no backend (Stretchr makes it easy to do so) in just HTML5 and JavaScript... and serving pages like that tends to be more difficult.

I use a simple web server (like Thru http://github.com/stretchr/thru) that doesn't do any routing or path parsing etc.

I agree actually - I prefer to keep them separate, which is why we included the hash() and query() methods too. I'd say pick one and stick with it. Arg.js has to care about both, because people use both.

We wanted to support OAuth2 in Go and it was tricky to do in a TDD way, so we built Gomniauth. Today it supports Google and Github, but it's VERY easy to add providers. It's also general enough to support beyond OAuth2, so it'll likely grow as the community uses it and decide what they need. It also plays very nicely with our Goweb package - http://github.com/stretchr/goweb, and we've included an example app that you can copy to get going. We'd love any feedback, issues, pull requests etc. and think this is a step towards making web development in Go a realistic option.

I need this