Hi Joel, Thanks for your feedback. Off topic, but Garden is awesome and Ankha has been indispensable when developing Om applications! Thanks for those.
I didn't complain or suggest a patch because, aside from Bidi, I didn't find a Clojure or ClojureScript routing library that I could conceive of fitting *my criteria* without fundamental, completely breaking alterations -- alterations that warrant a new library, not a new version number. I care about compatibility, extensibility, bidirectionally, purity, transparency, and decoupling -- which is why I wrote Silk. Since you brought up Secretary as a routing library that could potentially be made isomorphic, I'll compare it to Silk as I did with Bidi. I am not as familiar with Secretary as I am with Bidi, and it looks to have changed since I last used it, so please do correct me if I say anything incorrect or misleading. In terms of commonalities with Silk, Secretary obviously works in ClojureScript and has named routes. It is also somewhat extensible via protocols. In terms of differences, Secretary is obviously incompatible with Clojure, couples route definition with route handling, uses a complex macro to define routes instead of using data structures, can only match URL paths, and is impure. While I value all of these features that Secretary lacks, I think that last one, impurity, is the most significant. I love Clojure's pragmatic philosophy; it is mostly pure but very practical. Mutation is always possible, but uncontrolled mutation is frowned upon and intentionally difficult. Where we draw the line between functional purity and impurity is unclear and very open to interpretation, but it is my strong opinion that route creation and matching should sit firmly on the pure side. The public interface for defining routes in Secretary is `defroute`, a macro which only sometimes defines something but *always* mutates a global atom. When using Secretary, how does one know the order in which routes are matched? I assume it is in dependency order as determined by the Google Closure compiler, but it is unclear to me. What about if Secretary is ported to Clojure and you hot reload namespaces as you develop with it? You could potentially change the routing order from what it would be at runtime. Component <https://github.com/stuartsierra/component> is extremely useful for development and its popularity is well warranted, but Secretary's design fundamentally precludes compatibility with Component or anything that requires that mutation be limited and controllable. Silk is also, in many ways, lower level than Secretary. Secretary could be built on top of Silk without much additional effort since extending Silk to match paths specified with Clout/Secretary syntax ("/path/to/:param") would be trivial. On the other hand, building Silk on top of Secretary would be extremely difficult. It is not my intention to lambast Secretary and I hope it doesn't come across that way. Solving front-end routing problems is difficult and is a different beast altogether from back-end routing because it lacks the established Ring model (adapters, requests, etc.) and even lacks the HTTP request/response model. Secretary did a good job at solving these difficult problems. We share a desire to bring an end to the saturation of routing libraries. I just don't think that retrofitting a library designed for one paradigm will work without causing significant pain to users. At some point, it just makes sense to start fresh. Silk is designed from the ground up to work on both platforms, be extremely extensible, and include all of the best parts of the various routing libraries that I have used and examined. These strict flexibility requirements led to a design which, I think, is very simple and fairly low-level while remaining reasonably convenient. I appreciate your invitation to help you work toward the goal of making Secretary isomorphic and would be happy to talk to you about it. However, I don't think that Secretary or any other routing library can easily replace Silk. Therefore, I also invite you to help improve any deficiencies you see in Silk. I would greatly appreciate constructive criticism. I'll take you up on your offer to email you privately. :) Cheers, Dom On Tue, Aug 5, 2014 at 7:35 PM, Joel Holdbrooks <cjholdbro...@gmail.com> wrote: > Awesome work. It's fantastic to see a library that's interested in > targeting both the front-end and the back-end. This is the type of attitude > I would love to see more often in the Clojure community. > > OTOH, it would have been awesome to have heard your thoughts WRT the > concept of isomorphic routing on the Secretary issue tracker. > > You said you couldn't find something suitable, why didn't you complain or > suggest a patch? We would have been happy to have supported your endeavor > in making that possible and your ideas. In fact, we would have been willing > to make breaking changes for them! > > Many of us want this! > > Originally, several people - myself included - were interested in seeing > Clout be the library that everyone used both on the client and on the > server. Unfortunately, James never merged the pull requests (two of them) > for ClojureScript support. AFAICT it was because he wasn't clear on the > role it would serve. James is also a busy man. :-) > > I'm not trying to call you out; the work you have done is fantastic > (there's already a few things I'd like to steal!). Rather, I am trying to > bring up a more important issue within our community WRT this topic: > routing. We now have at least 4 libraries designed for this task (most of > them targeting the server). > > We should not burden the community with dozens of choices. Instead we > should enrich the community by working together to improve it. Fewer, well > designed choices surely outweigh many "okay" solutions. > > So enough talk. Personally, I would love to work together on the issue of > an isomorphic router. Secretary is a well known choice for the client and I > think together we could make it better by supporting the server. We have > three core team members on Secretary, and speaking for the team, I think we > would love to bring an end to this saturation of routers in the > ClojureScript world. Would you be interested in joining our team and help > us work toward this goal? > > I don't mean to put you on the spot publicly but this is, partly, a public > NIH issue and a tweet won't hold this. > > Email me privately if you desire. :-) > > -- > Note that posts from new members are moderated - please be patient with > your first post. > --- > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojurescript+unsubscr...@googlegroups.com. > To post to this group, send email to clojurescr...@googlegroups.com. > Visit this group at http://groups.google.com/group/clojurescript. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
