In previous blog posts I mention that Bidi and Silk are essentially equivalent. I don’t believe this anymore. I now prefer Silk and I can show you why with a little example. First, let’s define some routes:

(def silk-routes ( [[:home-page [[]]]
                                     [:about [["about"]]]]))

(def bidi-routes ["/" {""      :home-page
                       "about" :about-page}])

When it comes to defining routes, I find both a bit cryptic. Bidi feels a bit easier to read but I found it was harder to write in some scenarios.

Let’s parse some paths:

(bidi.bidi/match-route bidi-routes "/")
; => {:handler :home-page}

( silk-routes "/")
; => { :home-page, {:path []}, #object[ 0x7a46e3be ""],{:scheme nil, :user nil, :host nil, :port nil, :path [], :query {}, :fragment nil}}

(bidi.bidi/match-route bidi-routes "/about")
; => {:handler :about-page}

( silk-routes "/about")
; => { :about, {:path ["about"]}, #object[ 0x7a46e3be ""],{:scheme nil, :user nil, :host nil, :port nil, :path ["about"], :query {}, :fragment nil}}

So far I would consider them equivalent. Silk gives you more information about the route but is also more noisy. I personally dislike the namespaced keywords, but that’s easily solved with:

(defn sanitize-silk-keywords [matched-route]
  (rename-keys matched-route {    :name

The real difference, for me, comes when I try to parse /about?,which should be the same as /about and some lazy URL handling libraries emit the former rather than the latter. Silk first:

( silk-routes "/about?")
; => { :about, {:path ["about"]}, #object[ 0x7a46e3be ""],{:scheme nil, :user nil, :host nil, :port nil, :path ["about"], :query {}, :fragment nil}}

No surprised there. What about Bidi:

(bidi.bidi/match-route bidi-routes "/about?")
; => nil

Oops, what happened here? A bit of digging around lead me to the issue Why are query parameters not supported anymore? Essentially, Bidi’s design is that you shouldn’t route on query arguments (which I would agree in principle) and thus it relays on others to separate the two, something I don’t like at all. In a ClojureScript application it would requiring some pre-parsing of the URL, while Silk does it for you.

Silk also seems to support, if not routing, at least reporting port, host, user, scheme and even fragment. This can come in handy at some point. If you want to learn more about using Silk and Pushy, take a look at the blog post No-hashes bidirectional routing in re-frame with Silk and Pushy.

Picture by


2 thoughts on “Bidi vs Silk

  1. Good article. I think it would be nice if bidi properly stripped away any query string from the URI when matching. I still don’t believe the query string should be used in routing, but you’re right that this shouldn’t require pre-processing work on behalf of the developer. I’ve raised a bidi issue #88 for this. Articles like this which provide feedback on use in real projects serve to improve libraries, and are very helpful.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s