I didn't have the time to study the project in depth, but it looks very promising, well documented, and it also looks like an approach that I was looking for in other frameworks. Thanks!
Seeing the care you put into your website, I would suggest an addition. If you could create a video like the classic "a blog in 10 minutes" - or "a TODO list in 10 minutes", considering that that is the reference for js frameworks - and feature it in the home page I think it would really help. In my opinion you should give the demonstration of your benefits first, and the theory later ;)
On a completely different note, I think this looks fantastic. There are so many javascript frameworks out there but none of them have really approached the cleanliness and simplicity of rails so I've been reluctant to pick them up - this is definitely the closest I have seen. I will give it a shot for sure - props to the authors on good work!
I agree - none of the other frameworks I've tried have felt right, but this looks like a great fit with Rails - we'll see if I feel the same way after using it though :)
One quick thing I noticed playing around creating a demo app - the generator seems to have generated some incorrect haml in the layout that it creates. First, it has "javascript:" instead of ":javascript" for the filter, and once that was fixed I noticed that I had to change 'window.preload' to 'window.joosy' to get things to work.
I dig this. I've been using Ember + Rails and it still feels like client-side frameworks are reinventing a lot of server-side wheels because you still need a server-side layer for security, optimization, etc. I've been adding a lot of shims to "just work" in the Rails-world, and having a tightly integrated JS framework for Rails seems like a fantastic idea.
Models on the client are likely to be slightly different (I wouldn't do image resizing on the client, for example) and so the one-size-fits-all approach (Node.js Models running on server OR client, magically) doesn't work either.
I can't get past this (let alone the why of another MV*) - Why sugar.js? 6731 lines of bloat. This is going to turn off a great number of developers out the gates.
Take Ember for example. Joosy is only 2-3kb more including Sugar. Compare the profit. One framework can not (and should never try to) address everything. Sugar beats Underscore without a hope (http://borisstaal.com/post/24270017179/please-use-sugar-js). And you just can't live without both, raw JS is too poor.
I'm obviously opinionated on this point (backbone/underscore user), it just seems like it comes with so much i wont ever user - and could easily add via a mixin on a per project basis (in a nice functional manor). I also can't get over extending the native prototypes. Dealing with too many moving parts in modern web apps to go and start extending things that weren't built that way - maybe in the ruby world it just feels better to have it on the prototype directly. I suppose im getting off topic tho.
This lib (joosy) was built to satisfy your particular set of needs, and it seems that it does so well. Cheers to that.
" it just seems like it comes with so much i wont ever user - and could easily add via a mixin on a per project basis"
You could easily add the simple helpers in underscore too, they're not complex, but the idea is you use a library so you can work at a higher level of abstraction. Why write your own array intersection method? Why write your own camelcase function? Sugar opens a lot of doors that are just a little much effort to normally be bothered with (and underscore does too, but to a lesser degree).
"…start extending things that weren't built that way?"
It's ok to extend the prototypes, so long as a) you own the objects and b) you only extend the prototypes from a single module (e.g. sugar). c) Don't extend Object.prototype (unless you're really brave). http://blip.tv/jsconf/jsconf2011-andrew-dupont-everything-is...
The major risk is in collisions, and if you follow those rules you reduce the chance of this occurring to a minimum. If you're worried about for-loops, the way sugar handles extending the object prototype makes this a non-issue. http://sugarjs.com/native
Congratulations on this. I love the idea of tying the back end and front end. I can't see a reason not to integrate with Rails! And it is awesome that you have the in depth guides, that is very refreshing! Will this work with Slim? I like using slim and not having to worry about the HAML % all over the place.
It will work with any Rails JST binding. Just use .jst.slim instead of .jst.hamlc (remember to use JS version and not Ruby one :D). Everything that has a proper binding to Rails should work out of box.
For everything else, it has an abstraction layer so you can attach any template engine. We are woking on a guide that describes this process.
The site itself (joosy.ws) is hosted on a company server. The repo is on github but it's private. However, Guides are in public repo (hosted at Github Pages).
Joosy seems to be missing real 2-way data binding of Angularjs/Knockout.js/Serenade.js/Batman.js, even if it can automatically re-render views.
Looks like it still keeps the boilerplate to a minimum though and a great option for Rails devs though.
Reusability is a thing that comes from your hands and not a framework. Of course, framework can influence it a bit. But we promote correct encapsulation at each layer. What exactly you think is wrong?
All the JavaScript and templating code should be reusable by other platforms with no effort. It's required for testing, optimization and being able to move from one technology to other easily. This is the challenge programmers should solve. There has been already dozens of very good client-side frameworks that let us create very cool UIs with no effort but none of them is still good enough since the core idea is bad.
While you have a point, you seem to miss the original problem of browser frameworks. Browsers work _differently_. This is not the problem of a framework. Moreover nothing can stop you from using node.js + DOM mock to test anything you want. Unfortunately most of these tests will stay useless. So it's not about a possibility to write them. It's about a sense.
And btw, we are going to implement node.js tests to use Travis very soon.
Sorry, but what are you going to do with the DOM related or browser oriented code on your NodeJS? In fact, Joosy is framework for the browser apps, this hasn't been told?
> On another hand, it makes your backend to have exactly one function – to be a simple REST provider. That leads to easier development support and improves the scalability greatly.
Seeing the care you put into your website, I would suggest an addition. If you could create a video like the classic "a blog in 10 minutes" - or "a TODO list in 10 minutes", considering that that is the reference for js frameworks - and feature it in the home page I think it would really help. In my opinion you should give the demonstration of your benefits first, and the theory later ;)