Re: ClojureScript instead of CoffeeScript for complete web app development?

[thenwithexpandedwingshesteershisflight]

1. I suppose you can't call any Java library from ClojureScript if you want it to compile to JS. Can you call any Clojure library and have it translated?

If you want to use existing Java libraries then run those on the server. Clojure code will run either on the client or the server if it is not dependent on any server or client specific code (i.e. pure Clojure)
 

2. If I'd create a DSL with Clojure, could it be deployed to JS through ClojureScript also?

see above - if it is pure Clojure, yes, and lein-cljsbuild will manage such shared code for you
 

3. One of my main concerns is that what drives me to start developing client web apps is all the innovation and ideas that are being developed in the JS ecosystem. As far as I've read ClojureScript can interact with JS libraries, but seeing that the C2 library prefered to implement from scratch with ClojureScript instead of wrapping D3, makes me wonder how easy or convenient this is. I'd like to use things like Knockout but more generally any good JS library that can come out (and also WebGL, the future WebCL, etc)...

using existing javascript is easy from Clojurescript if it is written in a functional way. The reason why C2 was written in Clojurescript is probably because it's just so much more fun and faster to code in Clojure. There will certainly be Clojurescript libs for the GL/CL etc.

 

From what I've investigated, I'd love to learn Clojure, I do know it would help me have a better mental approach to the problems, but heavy client web apps being my main short term focus I wonder if it's going to be more hassle than opting for a more "direct" way using CoffeeScript with the rest of JS ecosystem.

Just read the examples for Aleph and write a small app to test the waters - you'll love it
 

[Kevin Lynagh]

Jacobo,

Using JavaScript from ClojureScript is very straightforward.
There are a few points where interop is awkward, but that wasn't the main reason I wrote a new library (in Clojure).

There were two primary motivations for that.

1) We needed a visualization library that would work on the server (to have direct database access, headless SVG rendering, &c.) as well as on the client.

2) There are some fundamental semantic limitations with D3. Specifically, mapping a single datum to multiple or nested elements is very difficult.
In C2/Hiccup, it's all just function composition and manipulation of standard data structures, so code ends up being much more succient and expressive.

As to your larger point: you will always be able to use JS libraries from ClojureScript.
Using them from ClojureScript will never be as natural as using them in JavaScript, but you may find that much of the value from such libraries---structuring your application code, manipulating collections, rich data structures, and so on---already exist natively in ClojureScript.

That said, ClojureScript is young and there aren't a lot large, open source clientside applications that you can look to for guidance.
If you are just getting into clientside web development, it might be easier to do in JS / CoffeeScript just because you can probably find some good examples that solve 90% of your specific problem = )

best,

Kevin

[Jacobo Polavieja]

Thanks a lot for your answer. I think I really have no other option than spending some time learning at least basic clojure and trying it out to see how it feels. 

[Jacobo Polavieja]

Hi Kevin,

It's great that you can answer as two talks you did are what finally left me like "maybe I've been resisting it but this should be the way to go anyway...". 

As to your first point and only to clarify, had you made it a wrapper for D3 and in a node.js application, there would still be no problem in using it server-side, am I right?

Anyway this is what contributes to my doubts... CoffeScript + Node.js is pretty standard web development right now. I don't know if throwing in things that are not directly in the JS world will actually make things harder (or add complexity) or easier in the long run. But then again, you also said that CoffeeScript won't save JavaScript pitfalls in large projects, etc.

If I go the CoffeeScript route I am going to do it with the functional underscore.js library anyway... because I believe in the functional way of doing things (and not having immutability there is one thing I hate).

So, in short I've got a toy application in mind to learn either way, but the end project in mind is a trading application on the browser (which is my main field right now) that should deploy in as many devices/OS as possible (so, Javascript again). C2 fits in just perfect.

As the intrinsic domain problem is much better expressed in a language like Clojure I think I'll opt this way... hoping that your "Javascript from Clojure is moar fun" really stands in the long run. I hope you guys don't hear too much from me ;).

Many thanks for the answer as well as the talks, which have been trully great!

Cheers!

[Kevin Lynagh]

As to your first point and only to clarify, had you made it a wrapper for D3 and in a node.js application, there would still be no problem in using it server-side, am I right?

Unfortunately, no---D3 requires a full DOM.

Node.js is just the JavaScript engine.

There are some fake DOM implementations that people use with node.js for testing and scraping, but they were very rough last time I checked.

PhantomJS is a very nice project that is a headless WebKit browser, which we've used to run JavaScript with a DOM on the serverside.

It can get a bit involved to coordinate that with other processes though...

 

So, in short I've got a toy application in mind to learn either way, but the end project in mind is a trading application on the browser (which is my main field right now) that should deploy in as many devices/OS as possible (so, Javascript again). C2 fits in just perfect.

Speaking of toy applications with C2, I just open sourced an implementation of "TodoMVC" using some new features slated for release in C2 0.2.0:

    https://github.com/lynaghk/c2-demos/tree/master/todoMVC

You might want to check this out and compare it with the n+1 existing JavaScript application framework implementations to see which you like the best.

 

Many thanks for the answer as well as the talks, which have been trully great!

Thanks!

The Conj talk was my first experience with the Clojure community, which I've found to be very friendly and welcoming.

Definitely don't shy away from posting to the list or dropping by #clojure on IRC.

Personally I'm very interested to hear about experiences of people who are new to both JavaScript and Clojure(Script).

[Jacobo Polavieja]

Oh, I didn't really think about the DOM thing... hehe!

Thanks for the TodoMVC bit, I'll have an in-depth look at it as soon as I understand Clojure better. I've already started with a tutorial to grasp the basic things and have looked for a book to complete the rest.

I'll sure be posting back with my troubles and experiences. As I haven't actually ever used Javascript I'm a good case to prove ClojureScript's ability to stay away from it :).

And the talks where great for me as you mentioned everything I wanted: functional programming benefits, Javascript/CoffeeScript VS ClojureScript, and the impact the way we display data can have (I too think programmers need to think lots more about this...)

Thanks a lot, you've been really helpful mate.

Cheers!

[Paul deGrandis]

I've been building out substantial ClojureScript apps for a few months now.
Previously I had written an HTML5 game engine, so I'm no stranger to lots of JavaScript.

My CLJS code base is smaller, easier to organize/maintain, more functional and declarative, and boasts a level of server-side interop that surpasses JS's best attempts (like meteor js).  Having the reader (and a REPL) in the browser opens up a lot of possibilities.

As Kevin stated there are a few sticky spots when working with ClojureScript, but those are quickly being solved.
If you're new to Clojure and client-side development (JavaScript), the lack of CLJS examples and documentation is going to be a hurdle for you.
Errors in the console are not obvious unless you have some idea about the implementation details of ClojureScript.  Error reporting will not tell you what line of CLJS code your error is on (or what you did wrong), you just have to look at the compiled JS source, know where in your CLJS source that code is being generated, and scan carefully until you spot the error in your code.  This was my biggest hurdle starting out.

Since you're picking up a toy project, I would choose whatever language you're most excited to learn.  Enthusiasm is a great motivator for overcoming any challenge.

Paul

[Jacobo Polavieja]

El jueves, 14 de junio de 2012 14:42:14 UTC+2, Paul deGrandis escribió:

I've been building out substantial ClojureScript apps for a few months now.
Previously I had written an HTML5 game engine, so I'm no stranger to lots of JavaScript.

My CLJS code base is smaller, easier to organize/maintain, more functional and declarative, and boasts a level of server-side interop that surpasses JS's best attempts (like meteor js).  Having the reader (and a REPL) in the browser opens up a lot of possibilities.

As Kevin stated there are a few sticky spots when working with ClojureScript, but those are quickly being solved.
If you're new to Clojure and client-side development (JavaScript), the lack of CLJS examples and documentation is going to be a hurdle for you.
Errors in the console are not obvious unless you have some idea about the implementation details of ClojureScript.  Error reporting will not tell you what line of CLJS code your error is on (or what you did wrong), you just have to look at the compiled JS source, know where in your CLJS source that code is being generated, and scan carefully until you spot the error in your code.  This was my biggest hurdle starting out.

Since you're picking up a toy project, I would choose whatever language you're most excited to learn.  Enthusiasm is a great motivator for overcoming any challenge.

Paul

 

Hi Paul, thanks for answering. It'salways good to hear from someone with battle field experience, hehe!

I've picked a toy project jus to learn but the whole point is to develop larger apps. If it was just for a little app probably CoffeeScript would be a faster way to get into it, but I'm looking into larger apps and long term future. That's why (apart from the fact that I love the truly functional paradigm and lots of Clojure's innovations) I've decided to go the CLJS route. Hope it pans out ok although having some problems is expected, obviously.

Thanks again for your input! It's good to know there are some "more than a toy" codebases out there which are getting developed ok.

Cheers!

[Jacobo Polavieja]

On Saturday, June 23, 2012 12:43:38 AM UTC+2, wingie wrote:

Since you love FP I wanted to mention another option:

LiveScript

http://gkz.github.com/LiveScript/blog/functional-programming-in-javascript-using-livescript-and-prelude-ls.html

http://gkz.github.com/LiveScript

http://gkz.github.com/prelude-ls/

It's a script that compiles down to JavaScript. Inspired by CoffeeScript but Haskell and F# as well.

Read the blog about it's FP capabilities.

It fits with all JS/CS projects.

Hope it helps.

Hi wingie, and thanks for commeting.

I indeed had a look at LiveScript, it's a very interesting project. What finally drove me far from it was:

- Small community (for now, I understand everything has to start somewhere), so in terms of being able to solve doubts, long term future of the language, or look at other code it would be harder.

- With Clojure & ClojureScript I learn a language which has many more applications than a JS one, and which is having a lot of effort behind it.

Of the languages in the style of CoffeScript, Roy, etc... LiveScript was the one that I liked the most and I think is a great project. But I was preferring something more widespreaded.

I really am liking learning Clojure... we'll see how this all plays out when the time to write some web apps comes around. I'll keep this group posted ;).

Thanks! Cheers!

[David Nolen]

On Mon, Jun 25, 2012 at 12:31 AM, Christian M. <chr...@gmail.com> wrote:

I have developed a tiny web app in Clojure/ClojureScript and have written an overview here. In general, it was an exciting experience, but I also faced several problems with ClojureScript. For example, if you compile your code to JS, then the output file (in contrast to CoffeeScript) will contain other code (~18kb or so): this code contains the Google Closure libraries, which do a lot of stuff, like accessing the DOM elements.

The bulk of the "other" code is the CLJS standard lib. We currently only use a few things from GClosure (string, object, array, etc), nothing involving the DOM.

 

Furthermore, I did experience some performance problems with ClojureScript, which I didn't investigate further, so I'm not sure, that these problems hold in general. I did some per-character computations on a very large text and it took just too long for such a primitive operation. Since my code was quite high-level I assumed, that the GC of JS engine was choked.

If you want fast string manipulating, writing very high-level code isn't going to work. Same for hand written JavaScript.

 

I think the only problem (if it is a problem at all), which won't be solved soon is ClojureScript's performance resulting from creating a lot of implicit objects in very high level computations. Something like (filter (map (reduce ... ... (map ...)))) can't be as fast and as memory-efficient for loops and in-place array operations of JS. In theory, the same holds for Clojure and Java as well, however, in contrast to ClojureScript, I never faced this problem on JVM yet.

There's lots of room for improving the performance of the high level operations. That said generating fast JS from CLJS is a goal - otherwise the data structure benchmarks would not look as good as they currently do.

I admit as with Clojure on JVM - it's not obvious how to write fast code - even though it's not difficult. A guide on how to write fast code for critical parts of CLJS application needs to be written up by someone.

David

[Ben Mabey]

On 6/24/12 10:31 PM, Christian M. wrote:
> I think the only problem (if it is a problem at all), which won't be
> solved soon is ClojureScript's performance resulting from creating a
> lot of implicit objects in very high level computations. Something
> like (filter (map (reduce ... ... (map ...)))) can't be as fast and as
> memory-efficient for loops and in-place array operations of JS. In
> theory, the same holds for Clojure and Java as well, however, in
> contrast to ClojureScript, I never faced this problem on JVM yet.
>

Does the new reducers library[1] work in ClojureScript? One of its
advantages is that it avoids the per-step allocation overhead that you
are mentioning with the chain of filters/maps/reduce calls.

-Ben


1.
http://clojure.com/blog/2012/05/08/reducers-a-library-and-model-for-collection-processing.html

[David Nolen]

reducers are already available - though further perf work needs to be done to really deliver on the performance promises. Even so I wouldn't be surprised if they already outperform many chained sequence operations.

David

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

[Jacobo Polavieja]

On Monday, June 25, 2012 6:31:42 AM UTC+2, Christian Mueller wrote:

I have developed a tiny web app in Clojure/ClojureScript and have written an overview here. In general, it was an exciting experience, but I also faced several problems with ClojureScript. For example, if you compile your code to JS, then the output file (in contrast to CoffeeScript) will contain other code (~18kb or so): this code contains the Google Closure libraries, which do a lot of stuff, like accessing the DOM elements. However, I found it *much* easier to use jQuery (through the jayq library written in ClojureScript). Hence, in my case, a lot of this additional code will be loaded for nothing. And the first-time load times are not negligible!

Furthermore, I did experience some performance problems with ClojureScript, which I didn't investigate further, so I'm not sure, that these problems hold in general. I did some per-character computations on a very large text and it took just too long for such a primitive operation. Since my code was quite high-level I assumed, that the GC of JS engine was choked.

Now to your questions

1. I suppose you can't call any Java library from ClojureScript if you want it to compile to JS. Can you call any Clojure library and have it translated?

This is right, what is supported in ClojureScript is _almost_ everything what is supported in _native_ Clojure only, so don't expect things like Integer/parseInt or all String methods to work in JS!

 

2. If I'd create a DSL with Clojure, could it be deployed to JS through ClojureScript also?

If you manage to keep it platform-independent, then of course. However, even if you'll need some platform-specific calls, you can abstract them: I had a similar problem with my web app (the problem is described in my overview) when I needed a simple hash function, which would work on the client and on the server. The problem is that you run into the platform much faster, than you assume: JS (and therefore ClojureScript) has no chars, it doesn't produce overflows, the entire String API is different and so on. What I did, I just implemented my code with dependency injections in form of higher order functions injected as arguments. Such code can be run on the client and on the server with different platform-specific parameter. This was fun.

 

3. One of my main concerns ...

I can't give more insightful answers as already given.

I know the tooling is raw at the moment and that it'll get better overtime, so I'm asking more about the fundamental problems that are hardly going to be solved in the near time.

I think the only problem (if it is a problem at all), which won't be solved soon is ClojureScript's performance resulting from creating a lot of implicit objects in very high level computations. Something like (filter (map (reduce ... ... (map ...)))) can't be as fast and as memory-efficient for loops and in-place array operations of JS. In theory, the same holds for Clojure and Java as well, however, in contrast to ClojureScript, I never faced this problem on JVM yet.

Thanks a lot Christian for passing by to comment your experience, it's of great help. I'm going to read the complete overview just now. Thank you for taking the time to write about this.

And also thanks to David Nolen for clarifying all the other things.

Cheers! 

[László Török]

Hi, 

using the reducers library also eliminates the per-step allocation of temporary results when the processing code is composed of multiple functions, AFAIK.

Las

2012/7/4 Balint Erdi <balin...@gmail.com>

Hey,

AFAIK the clojure reducers library gains its performance boost since the underlying JVM can make use of multiple cores. I wonder how this changes with Javascript being the platform. Don't JS engines have a single execution thread?

Balint

clojure+u...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

--

László Török

[Balint Erdi]

That's right. So the reducers library in ClojureScript will probably also use less memory then working with sequential operations but it will not get any speed boost since in the Javascript VM it will not run in parallel. Is that right?

Balint

László Török

[David Nolen]

On Sat, Jul 7, 2012 at 5:26 PM, Balint Erdi <balin...@gmail.com> wrote:
> That's right. So the reducers library in ClojureScript will probably also
> use less memory then working with sequential operations but it will not get
> any speed boost since in the Javascript VM it will not run in parallel. Is
> that right?
>
> Balint

Yes. But there are people involved in JS implementations who are
interested in task parellelism for JS, so maybe one day.

David