7 ms·

Show HN: Joosy, the rails-tied browser app framework

91 points by inossidabile 14y ago

combataircraft 14y ago
yeah yeah, that's what javascript needs! let's make all your javascript code more non-reusable.
- cheez 14y ago
  wat?
- inossidabile 14y ago
  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 14y ago
    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.
    - inossidabile 14y ago
      You just take it and use it. Joosy doesn't make to write you code in some special way (except CoffeeScript but it can be used with node.js). What's for binding parts (pages, layouts), I doubt you will ever want to use browser parts in node. So this is not the case.
      - combataircraft 14y ago
        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.
        inossidabile 14y ago
        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.
    - alerticus 14y ago
      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?
    - sandrew 14y ago
      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 14y ago
        Github is not a rich web app for me. See Google Spreadsheets to figure out what a client-side framework should be helpful for.
jenius 14y ago
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 14y ago
  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 14y ago
    If you don't, please take a moment to share your thoughts with me :)
    - rjsamson 14y ago
      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 14y ago
        Fixed! Thanks for the catch! :)
gregwebs 14y ago
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 14y ago
"Joosy interface was designed to get best out of CoffeeScript." I think you accidentally a word.
rjsamson 14y ago
Wow - this looks really awesome. The ability to use haml is a nice touch too.
amalag 14y ago
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 14y ago
  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.
MattRogish 14y ago
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.
danmaz74 14y ago
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 14y ago
  Agreed. It's planned already in fact. Just need some more hours in a day :)
  - danmaz74 14y ago
    Perfect. Keep up with the great work!
sic1 14y ago
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.
- sandrew 14y ago
  Just 18KiB is not a big price for really comfortable replacement of poor standart library
- inossidabile 14y ago
  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 http://borisstaal.com/post/24270017179/please-use-sugar-js). And you just can't live without both, raw JS is too poor.
  - sic1 14y ago
    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 14y ago
      " 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-permitted-extending-built-ins-5211542 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 http://sugarjs.com/native Please actually use a tool before you condemn it.
nkwiatek 14y ago
> 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.
haar 14y ago
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 14y ago
  What a dumb joke it would be %). Fixed, thank you.
geekfactor 14y ago
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 14y ago
  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 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 14y ago
    Ok. I started with the Getting Started guide and just submitted a pull request. I'm sbc on GH.

91 points by inossidabile 14y ago

combataircraft 14y ago

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

cheez 14y ago
wat?
inossidabile 14y ago
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 14y ago
  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.
  - inossidabile 14y ago
    You just take it and use it. Joosy doesn't make to write you code in some special way (except CoffeeScript but it can be used with node.js). What's for binding parts (pages, layouts), I doubt you will ever want to use browser parts in node. So this is not the case.
    - combataircraft 14y ago
      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.
      - inossidabile 14y ago
        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.
  - alerticus 14y ago
    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?
  - sandrew 14y ago
    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 14y ago
      Github is not a rich web app for me. See Google Spreadsheets to figure out what a client-side framework should be helpful for.

jenius 14y ago

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 14y ago
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 14y ago
  If you don't, please take a moment to share your thoughts with me :)
  - rjsamson 14y ago
    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 14y ago
      Fixed! Thanks for the catch! :)

gregwebs 14y ago

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 14y ago

"Joosy interface was designed to get best out of CoffeeScript." I think you accidentally a word.

rjsamson 14y ago

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

amalag 14y ago

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 14y ago
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.

MattRogish 14y ago

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.

danmaz74 14y ago

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 14y ago
Agreed. It's planned already in fact. Just need some more hours in a day :)
- danmaz74 14y ago
  Perfect. Keep up with the great work!

sic1 14y ago

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.

sandrew 14y ago
Just 18KiB is not a big price for really comfortable replacement of poor standart library
inossidabile 14y ago
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 http://borisstaal.com/post/24270017179/please-use-sugar-js). And you just can't live without both, raw JS is too poor.
- sic1 14y ago
  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 14y ago
    " 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-permitted-extending-built-ins-5211542 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 http://sugarjs.com/native Please actually use a tool before you condemn it.

nkwiatek 14y ago

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

haar 14y ago

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 14y ago
What a dumb joke it would be %). Fixed, thank you.

geekfactor 14y ago

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 14y ago
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 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 14y ago
  Ok. I started with the Getting Started guide and just submitted a pull request. I'm sbc on GH.