I interpreted the talk as the tool viewer was a proof-of-concept in order to advocate the benefits of using the nav and datafy protocols. I believe Stu is not claiming its particularly novel, but instead wants to inspire tool makers to use the protocols and make better tools, hence his mentioning of his curiosity of what the Clojurescript guys could make. I mean I had the idea of a data viewer with some partial implementation with no knowledge of GT, and another person in this thread has been working on a similar idea, the tool concept isn't that novel (based on the features you describe). On the other hand, Clojure being a dynamic language by default makes any open source dataviewer written in Clojure automatically "moldable". Further, because of the protocols, its easy to swap between different people's implementations of the viewers. Clojurescript in particular is at an advantage because of the vast web resources and Clojurescript can compile itself.
Comments
I interpreted the talk as the tool viewer was a proof-of-concept in order to advocate the benefits of using the nav and datafy protocols. I believe Stu is not claiming its particularly novel, but instead wants to inspire tool makers to use the protocols and make better tools, hence his mentioning of his curiosity of what the Clojurescript guys could make. I mean I had the idea of a data viewer with some partial implementation with no knowledge of GT, and another person in this thread has been working on a similar idea, the tool concept isn't that novel (based on the features you describe). On the other hand, Clojure being a dynamic language by default makes any open source dataviewer written in Clojure automatically "moldable". Further, because of the protocols, its easy to swap between different people's implementations of the viewers. Clojurescript in particular is at an advantage because of the vast web resources and Clojurescript can compile itself.