Coffeescript and JS.Class: some information about how to integrate (or not) each other

[Francesco Belladonna]

Well, I like coffeescript and the way it's written, but I feel that writing in coffeescript while using JS.Class "collides" a bit (expecially class definition). I'm ok to write "new JS.Class(...)" instead of "class Xxx" (the coffeescript way to make a class), but I'm not sure if it's a good idea to mix coffeescript and JS.Class

Have you ever done it? Is it a good idea (or worst ever)? Any suggestion?

I'm a bit afraid of performance, I've never done a project with JS.Class so I really don't know what will come out. In another post, I've read that you mention that JS.Class is "heavy" while loading, but after all classes are loaded it should be painless. For me that's a really good point, I don't mind loading a bit more time, however I'm not sure if it's a good idea to use it on small websites (I really like the library so I would like to use even for small websites, just to wrap up some jQuery code or something similar). If you have any experience about it, can you please share it, so I can avoid making disasters?

[James Coglan]

On 2 February 2013 15:31, Francesco Belladonna <francesco....@gmail.com> wrote:

Well, I like coffeescript and the way it's written, but I feel that writing in coffeescript while using JS.Class "collides" a bit (expecially class definition). I'm ok to write "new JS.Class(...)" instead of "class Xxx" (the coffeescript way to make a class), but I'm not sure if it's a good idea to mix coffeescript and JS.Class

Have you ever done it? Is it a good idea (or worst ever)? Any suggestion?

Anything that's legal in JavaScript, you can do in CoffeeScript. Yes, CS has its own class syntax, but any legal JS function call can be reproduced in CoffeeScript. Making a class looks like this:

Foo = new JS.Class 'Foo',

  initialize: (a, b) ->

    @a = a

    @b = b

    # etc.

  doSomething: (some, args) ->

    # etc. 

I'm a bit afraid of performance, I've never done a project with JS.Class so I really don't know what will come out. In another post, I've read that you mention that JS.Class is "heavy" while loading, but after all classes are loaded it should be painless. For me that's a really good point, I don't mind loading a bit more time, however I'm not sure if it's a good idea to use it on small websites

Although JS.Class is one of the more complex JS object systems, I've not found its performance to be a bottleneck in anything I've built. The performance problems are usually in the app itself.

The primary reasons I use it these days are:

* I use the package system to load various things

* I use JS.Test for all my JS projects, even non-JS.Class ones

* I use core.js when my app benefits from a sophisticated object system, but for smaller projects I just use JS constructors+prototypes

* The collections classes -- Enumerable, Set, Hash, Range -- are often useful to me

So I don't use it for everything, and use some bits way more than others, but those are my main reasons. 

[Francesco Belladonna]

Thanks, this is quite useful and looks nice too. Also the feedback
about performance is really interesting. And yes,
enumerable/set/hash/range are really helpful things that javascript
should have!

2013/2/2 James Coglan <jco...@gmail.com>:

> --
> You received this message because you are subscribed to the Google Groups
> "jsclass-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jsclass-user...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>