Re: Animation libraries for clojurescript?
Hi, I have looked at quite a few Javascript 2D graphics libraries. The ones I found particularly interesing are paper.js[1] and fabric.js[2]. At least paper.js is in active development and works fine with ClojureScript. Depending on your requirements SVG might also be a good alternative. I've found that SVG + one of the new React based CLJS wrapper libs is an excellent fit (see my experiments in reagent[3] and om[4]). There are also js libs for working with SVG such as Raphael[5] and the newer Snap.svg[6] (which is by the same author as Raphael). /Jonas [1] http://paperjs.org/ [2] http://fabricjs.com/ [3] https://github.com/jonase/elements [4] https://github.com/jonase/om-svg-tests [5] http://raphaeljs.com/ [6] http://snapsvg.io/ On Sunday, April 20, 2014 12:19:17 AM UTC+3, puzzler wrote: Are there any javascript 2D animation libraries that are particularly well-suited for use from clojurescript? I'm especially interested in a library that uses a scenegraph to store graphical objects in hierarchical relationships to one another. Thanks, Mark -- 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.
Animation libraries for clojurescript?
Are there any javascript 2D animation libraries that are particularly well-suited for use from clojurescript? I'm especially interested in a library that uses a scenegraph to store graphical objects in hierarchical relationships to one another. Thanks, Mark -- 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.
Re: Libraries for ClojureScript.
Thanks for your responses Creighton and Kevin. D3 looks cool, so should cljs-3D be, ditto for Enlive / Enfocus. All the best for your efforts, Manoj. -- 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
Re: Libraries for ClojureScript.
One other concern to keep in mind is that many JavaScript libraries aren't compatible with the Closure compiler's advanced optimizations. Advanced optimizations are awesome---I'm working on a Clojure data visualization library similar in spirit to D3, and for many static visualizations the compiled JavaScript (including the ClojureScript runtime itself) is less than half the size of minified D3. This is both the bane and the beauty of clojurescript. Having gclosure compiler produces great results for clojurescript code. But there is an army of developers creating some great js code that will never be gclosure compatible. every jquery plugin comes to mind. you can bring this in - but you cant use advanced compilations. And, if you don't use advanced optimisations - generated code is...well...plump. This problem comes from gclosure, not a clojurescript directly. Also - even if a library is gclosure compilable - you still may not want to use it because interop mentioned above... In my opinion - you can do things in clojurescript much better and faster than in js. But this does not help if the clojurescript library scene is small. More ClojureScripters required... and Google - are you listening out there? - please get on board and put some backing to clojurescript! - It is the best way to use your tools. D -- 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
Re: Libraries for ClojureScript.
Manoj,
I wrote a ClojureScript wrapper around the D3 JavaScript library,
https://github.com/lynaghk/cljs-d3
and took some liberties with the D3 API to make it more concise and
otherwise Clojure-like.
For instance, you set attributes in D3 like
d3_selection
.attr(x, 5)
.attr(y, 10)
.attr(fill, blue)
and I added a macro that would expand a map literal into multiple attr
calls so in cljs-d3 people could write
(- d3-selection
(attr {:x 5, :y 10, :fill, blue}))
One difficulty I had in building a ClojureScript facade for D3 is that
it wasn't clear when to coerce between JavaScript and Clojure
datatypes.
For instance, D3 has some higher level functions that return things
like scales or calculate histograms.
Some D3 layouts take these functions as arguments, but they can also
be used stand alone.
Should the wrapped call to D3's histogram function return the
original, native JavaScript array (for compatibility with D3 layouts),
or a ClojureScript seq (for the ClojureScript programmer who wants the
histogram itself)?
One other concern to keep in mind is that many JavaScript libraries
aren't compatible with the Closure compiler's advanced optimizations.
Advanced optimizations are awesome---I'm working on a Clojure data
visualization library similar in spirit to D3, and for many static
visualizations the compiled JavaScript (including the ClojureScript
runtime itself) is less than half the size of minified D3.
best,
Kevin
On Jan 15, 5:23 pm, ckirkendall ckirkend...@gmail.com wrote:
Manjo,
I think there is considerable benefit in keeping certain APIs similar
between ClojureScript and Clojure. In places where the intent is the
same I would suggest going with a familiar API. I took this approach
with enfocus by basing it on enlive. It sped up my development
because I didn't have to ponder if the semantics were usable. In the
places where my feature set didn't line up, I found myself working and
reworking the apis because they weren't clean enough or they seemed
confusing. All of that being said, ClojuresSript is very young and I
don't think we have a right way to do things yet. Right now I would be
willing to try any testing library regardless if it matched
Clojure.
Creighton Kirkendall
On Jan 15, 12:37 am, mmwaikar mmwai...@gmail.com wrote:
Hi,
My question is about design of libraries for ClojureScript.
So for ex, there is clojure.test which has some public API. Now assume one
has used it and is comfortable with its API.
Now he has to write some ClojureScript code and wants to write some unit
tests as well.
Obviously, he'll use some pre-existing JS library / framework, but it will
have its own API.
Now -
1) Does it make sense to write a ClojureScript wrapper over existing JS
libraries (as there are wrappers over many Java libraries / frameworks)?
2) Does it make sense, or is it better if this ClojureScript wrapper,
exposes the same (as far as possible) or similar API to that of one of the
Clojure libraries? The obvious advantage being the programmer has to get
accustomed to just one API, which works for Clojure as well as
ClojureScript.
Please let me know your views.
Thanks,
Manoj.
--
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
Re: Libraries for ClojureScript.
Manjo, I think there is considerable benefit in keeping certain APIs similar between ClojureScript and Clojure. In places where the intent is the same I would suggest going with a familiar API. I took this approach with enfocus by basing it on enlive. It sped up my development because I didn't have to ponder if the semantics were usable. In the places where my feature set didn't line up, I found myself working and reworking the apis because they weren't clean enough or they seemed confusing. All of that being said, ClojuresSript is very young and I don't think we have a right way to do things yet. Right now I would be willing to try any testing library regardless if it matched Clojure. Creighton Kirkendall On Jan 15, 12:37 am, mmwaikar mmwai...@gmail.com wrote: Hi, My question is about design of libraries for ClojureScript. So for ex, there is clojure.test which has some public API. Now assume one has used it and is comfortable with its API. Now he has to write some ClojureScript code and wants to write some unit tests as well. Obviously, he'll use some pre-existing JS library / framework, but it will have its own API. Now - 1) Does it make sense to write a ClojureScript wrapper over existing JS libraries (as there are wrappers over many Java libraries / frameworks)? 2) Does it make sense, or is it better if this ClojureScript wrapper, exposes the same (as far as possible) or similar API to that of one of the Clojure libraries? The obvious advantage being the programmer has to get accustomed to just one API, which works for Clojure as well as ClojureScript. Please let me know your views. Thanks, Manoj. -- 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
Libraries for ClojureScript.
Hi, My question is about design of libraries for ClojureScript. So for ex, there is clojure.test which has some public API. Now assume one has used it and is comfortable with its API. Now he has to write some ClojureScript code and wants to write some unit tests as well. Obviously, he'll use some pre-existing JS library / framework, but it will have its own API. Now - 1) Does it make sense to write a ClojureScript wrapper over existing JS libraries (as there are wrappers over many Java libraries / frameworks)? 2) Does it make sense, or is it better if this ClojureScript wrapper, exposes the same (as far as possible) or similar API to that of one of the Clojure libraries? The obvious advantage being the programmer has to get accustomed to just one API, which works for Clojure as well as ClojureScript. Please let me know your views. Thanks, Manoj. -- 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
