

Show HN: Joosy, the rails-tied browser app framework - inossidabile
http://borisstaal.com/post/24401343976/joosy-alternative-approach-to-browser-frameworks

======
danmaz74
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 ;)

~~~
inossidabile
Agreed. It's planned already in fact. Just need some more hours in a day :)

~~~
danmaz74
Perfect. Keep up with the great work!

------
jenius
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!

~~~
rjsamson
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 :)

~~~
inossidabile
If you don't, please take a moment to share your thoughts with me :)

~~~
rjsamson
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.

Other than that I'm liking what I see so far.

~~~
inossidabile
Fixed! Thanks for the catch! :)

------
MattRogish
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.

------
sic1
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.

~~~
inossidabile
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.

~~~
sic1
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.

~~~
secoif
" 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...](http://blip.tv/jsconf/jsconf2011-andrew-dupont-everything-is-permitted-
extending-built-ins-5211542)

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>

Please actually use a tool before you condemn it.

------
haar
You have several typos in the Joosy website (unless it's part of a joke I'm
unaware of, as they repeat the same incorrect \n correct pattern).

    
    
        ack -l "Deterimes" | xargs perl -pi -E "s/Deterimes/Determines/g"
    

in your root if you don't want to search for them manually.

Note: requires ack installed (like grep, but typically much faster and nicer
to use, for me at least).

~~~
inossidabile
What a dumb joke it would be %). Fixed, thank you.

------
amalag
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.

~~~
inossidabile
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.

------
geekfactor
I'm looking forward to trying this.

Also, happy to help w/ some quick copy editing. Is the joosy.ws site in github
somewhere?

~~~
inossidabile
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).

Here they are: <https://github.com/roundlake/joosy-guides>

If you want to modify something at welcome page, I can share the repo. But it
doesn't contain a lot actually. Just one page :).

~~~
geekfactor
Ok. I started with the Getting Started guide and just submitted a pull
request. I'm sbc on GH.

------
gregwebs
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.

------
tjdetwiler
"Joosy interface was designed to get best out of CoffeeScript."

I think you accidentally a word.

------
rjsamson
Wow - this looks really awesome. The ability to use haml is a nice touch too.

------
combataircraft
yeah yeah, that's what javascript needs! let's make all your javascript code
more non-reusable.

~~~
inossidabile
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?

~~~
combataircraft
What the fuck is going to happen when I need to reuse my JavaScript code on a
different platform e.g NodeJS, vert.x etc?

I'm sorry for negative comments but, what ruby and .net communities produce
for JS is shit. It's even more harmful then IE6 for our future.

~~~
sandrew
A couple of months ago GitHub released a coding guideline for Javascript. It
has the first point: "Use CoffeeScript".

Except of using Coffee instead of JS your comment has no sense.

~~~
combataircraft
Github is not a rich web app for me. See Google Spreadsheets to figure out
what a client-side framework should be helpful for.

------
nkwiatek
> 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._

It does? Hm, I guess Twitter is wrong then.

