Show HN: Joosy, the rails-tied browser app framework(borisstaal.com)
borisstaal.com
Show HN: Joosy, the rails-tied browser app framework
http://borisstaal.com/post/24401343976/joosy-alternative-approach-to-browser-frameworks
12 comments
Agreed. It's planned already in fact. Just need some more hours in a day :)
Perfect. Keep up with the great work!
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 :)
If you don't, please take a moment to share your thoughts with me :)
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.
Other than that I'm liking what I see so far.
Fixed! Thanks for the catch! :)
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.
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.
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
Please actually use a tool before you condemn it.
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
Please actually use a tool before you condemn it.
Just 18KiB is not a big price for really comfortable replacement of poor standart library
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).
Note: requires ack installed (like grep, but typically much faster and nicer to use, for me at least).
ack -l "Deterimes" | xargs perl -pi -E "s/Deterimes/Determines/g"
Note: requires ack installed (like grep, but typically much faster and nicer to use, for me at least).
What a dumb joke it would be %). Fixed, thank you.
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.
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.
I'm looking forward to trying this.
Also, happy to help w/ some quick copy editing. Is the joosy.ws site in github somewhere?
Also, happy to help w/ some quick copy editing. Is the joosy.ws site in github somewhere?
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 :).
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 :).
Ok. I started with the Getting Started guide and just submitted a pull request. I'm sbc on GH.
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.
"Joosy interface was designed to get best out of CoffeeScript."
I think you accidentally a word.
I think you accidentally a word.
Wow - this looks really awesome. The ability to use haml is a nice touch too.
yeah yeah, that's what javascript needs! let's make all your javascript code more non-reusable.
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?
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.
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.
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.
Except of using Coffee instead of JS your comment has no sense.
Github is not a rich web app for me. See Google Spreadsheets to figure out what a client-side framework should be helpful for.
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.
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.
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.
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?
wat?
> 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.
It does? Hm, I guess Twitter is wrong then.
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 ;)