{:keys [jayq waltz fetch crate monet]} pinot

3,525 views
Skip to first unread message

Chris Granger

unread,
Feb 4, 2012, 5:15:36 PM2/4/12
to clj-...@googlegroups.com
Hey folks,

By popular request I've finally broken pinot apart into pieces and have added two new libraries as well: a statemachine library and a jquery wrapper. All of these are still early and subject to lots of change, but they do all work and let you build some really interesting things :) Documentation will come over time, and I'll likely do an official release sometime early march.

jayq - pronounced "jake" is a jquery wrapper that makes jquery objects work just like normal clojure collections. 
waltz - a state management library that lets you build very complex interactions without ending up in the tar pit.
fetch - a library to make client/server interaction painless. Includes the pinot.remotes stuff as well as the start of a lazy-store implementation that works like a map where the values are fetched from the server lazily.
crate - my hiccup over dom object implementation
monet - a visual library for ClojureScript to make it easier (and performant) to work with canvas/visuals.

Enjoy guys!

Cheers,
Chris.

Nick Bauman

unread,
Feb 4, 2012, 9:04:44 PM2/4/12
to clj-...@googlegroups.com
Awesome, thanks! I'm a bit overwhelmed (that's a good thing)!

Mark Rathwell

unread,
Feb 4, 2012, 10:55:31 PM2/4/12
to clj-...@googlegroups.com
Chris,

This stuff looks great, as always. A few questions (I'm sure some of
this will be in the coming documentation, but asking just in case):

1. I didn't see anything for event handling, is Pinot still the
preferred method there?
2. Is Pinot effectively being deprecated otherwise?
3. What is the preferred method for including these dependencies?
4. Does using jayq rule out advanced compilation?
5. Would you consider a wiki for documentation, editable by approved
members, or even public? The documentation on github and your branded
sites has been great, but it might be nice for many to have one
location to access overviews, tutorials, examples, and api
documentation for the "Chris Granger Collection", as well as easily
being able to see how all of these projects interrelate for web
development.

Thanks again, I'm looking forward to getting into this stuff deeper.

- Mark

Chris Granger

unread,
Feb 4, 2012, 11:03:03 PM2/4/12
to clj-...@googlegroups.com
Hey Mark,
  1. I've been using jayq for event handling. The goog library's support for things like event delegation is non existent and my solution was pretty hacky :(
  2. Yep.
  3. You can pull them down with lein if you use either cljs-watch or lein-cljsbuild they'll mostly just work :) You'll just need to specify the extern for jquery if you use jayq with advanced compilation.
  4. Not at all :) I will write a rationale thing for the readme on jayq, but basically I've come to the conclusion that all the reasons that were given for not using jquery we're non-arguments. Advanced compilation will work just fine and the size difference is measure in bytes.
  5. I think that's a great idea, right now I feel like the ecosystem is a little too dependent on me, and I would like to open it up some more. If we have some solid proposals for that, I'd love to hear them. Like with all my things this group of stuff will eventually get a branded site and much better documentation, but there are a few other things that are more pressing on my plate right now. I just didn't want people to have to wait for me to start playing/seeing this stuff :)
Cheers,
Chris.

Chris Granger

unread,
Feb 5, 2012, 12:09:51 AM2/5/12
to clj-...@googlegroups.com
readme updated with rationale: https://github.com/ibdknox/jayq

Cheers,
Chris.

Mark Rathwell

unread,
Feb 5, 2012, 9:15:41 AM2/5/12
to clj-...@googlegroups.com
> If we have some solid proposals for that, I'd love to hear them.

I don't think the need is pressing, but the thought was more of down
the line, something that provides a big picture view, and can handle
multiple versions of noir/jayq/fetch/crate/monet/korma/etc, would be
very beneficial, and may be more work than one person wants to take
on. While all of these packages are great standalone, they also work
great together, and having one place where people can discover all of
the pieces available in this collection, where they fit in the web
development puzzle, and which pieces they would like to use might be
nice. And with respect to multiple versions, as more people are using
noir, et al, in production, and as these packages advance, there will
necessarily be multiple versions in use, and having the documentation
available for multiple versions may be necessary.

I was thinking something along the lines of clojuredocs.org, where
people can add examples and comments for the entire api, but really my
comment was more about planting the seed for something down the road.

- Mark

Linus Ericsson

unread,
Feb 5, 2012, 9:17:40 AM2/5/12
to clj-...@googlegroups.com
Why not just ask if it's possible to add them to clojuredocs? It would be of great value!

I'll see what I can do!

/Linus

2012/2/5 Mark Rathwell <mark.r...@gmail.com>

Chris Granger

unread,
Feb 5, 2012, 12:17:22 PM2/5/12
to clj-...@googlegroups.com
Clojure docs is really good for things that are useful at the function level, I'm not so sure it solves our problem here though. I agree with Mark that the biggest thing missing is sort of a place where people can talk about and show off possibilities in the combinations of these things. That sounds more like long-form documentation with examples and such, where people can comment and discuss. A wiki seems like a reasonable first-pass solution to it.

Cheers,
Chris.

Chris Granger

unread,
Feb 5, 2012, 12:20:06 PM2/5/12
to clj-...@googlegroups.com
That came off as me not wanting to be on Clojuredocs, which isn't true at all. Having some of the API docs up there would be very cool and I'm curious what you find out Linus :) I just think something else might be needed too.

Cheers,
Chris.

Linus Ericsson

unread,
Feb 5, 2012, 12:27:08 PM2/5/12
to clj-...@googlegroups.com
I totally agree, but from my experience wikis tends to vaporize and get out of sync if not anyone curates it quite aggressively. I think clojuredocs.org gives a good base (it has a rudimentary commenting system as well). I just sent a question to the clojuredocs mailinglist.

/Linus

2012/2/5 Chris Granger <ibd...@gmail.com>

Murphy McMahon

unread,
Feb 5, 2012, 12:42:12 PM2/5/12
to clj-...@googlegroups.com
One idea for executing a "long-form documentation with examples" is
something akin to ClojureScript One: a git repo that integrates the
basic libraries (Noir, Korma, the CLJS Suite) in a simple project, a
nice little landing page, and a wiki with articles explaining
rationales, etc. A huge undertaking, to be sure, but Chris could
probably throw it together in a weekend or two. ;)

One possible extension of the One model would be to include on the
branding site an incubator page where people who have extended or
modified the examples can put up short descriptions/tutorials with
their own variations. That would allow Chris' work to benefit from a
little crowd-sourcing and be a potentially awesome resource.

Thanks for releasing this CLJS code, Chris. Already read most of it
and learned a lot.

Daniel Jomphe

unread,
Feb 7, 2012, 7:09:24 AM2/7/12
to clj-...@googlegroups.com
Chris, thanks for the great work you've given us in the past months! I was eager to know your plans for the future of Noir + Pinot, especially in relation to ClojureScript One.

jayq - Bringing back jquery to the _masses_ of ClojureScript developers! I was surprised when you said jquery is the most battle-tested library out there; but obviously, you must be right. Although GClosure is battle-tested in Gmail and other big-name Google applications, I understand you feel that jquery is much more battle-tested thanks to its usage in almost everything else that's displayed in our browsers nowadays. One thing I'm sure, though, is that Google absolutely needed advanced compilation a while back to be able to make Gmail's javascript footprint not blow IE6's limits. That said, I understand that you consider we generally don't have such constraints, and wouldn't be using ClojureScript in the first place if we had them. So in the end, I definitely relate to your thinking; jquery is inevitable nowadays and GClosure doesn't feel as approachable and usable. Moreover, if Google ever migrates Gmail and their other big apps to a GClosure-over-Dart, they will obviously stop investing in the GClosure-over-JS that we know today.

waltz - I would feel that you believe what is proposed in CS One could become unwieldy in bigger applications, and thus you prefer to start your applications on the grounds of a FSM. I'm really interested in your rationale here.

fetch - nice!

crate - You must know that CS One uses the normal Hiccup from Cljs, as a big macro. Why is it preferable to not use the real hiccup as a macro in Cljs, but instead reimplement it like that?

Sorry if I turned out sounding like I was pitting most of your new libs against CS One's usage patterns; I suspect you weren't really doing all that for the sake of doing something else than what those guys are doing with One ;) Overall, your life must be a lot of fun recently; you work on amazing stuff. Thanks again!

Yesudeep Mangalapilly

unread,
Mar 7, 2012, 4:45:25 AM3/7/12
to clj-...@googlegroups.com


On Tuesday, February 7, 2012 5:39:24 PM UTC+5:30, Daniel Jomphe wrote:
Chris, thanks for the great work you've given us in the past months! I was eager to know your plans for the future of Noir + Pinot, especially in relation to ClojureScript One.

jayq - Bringing back jquery to the _masses_ of ClojureScript developers! I was surprised when you said jquery is the most battle-tested library out there; but obviously, you must be right. Although GClosure is battle-tested in Gmail and other big-name Google applications, I understand you feel that jquery is much more battle-tested thanks to its usage in almost everything else that's displayed in our browsers nowadays. One thing I'm sure, though, is that Google absolutely needed advanced compilation a while back to be able to make Gmail's javascript footprint not blow IE6's limits. That said, I understand that you consider we generally don't have such constraints, and wouldn't be using ClojureScript in the first place if we had them. So in the end, I definitely relate to your thinking; jquery is inevitable nowadays and GClosure doesn't feel as approachable and usable. Moreover, if Google ever migrates Gmail and their other big apps to a GClosure-over-Dart, they will obviously stop investing in the GClosure-over-JS that we know today.

Google Closure may not be suitable for everything, 
but it is highly unlikely that Google will stop investing into Closure 
and JavaScript given the amount of investment it already has into it. =)
 
[snip]

Cheers,
Yesudeep.
Reply all
Reply to author
Forward
0 new messages