Would some node.js experts mind weighing in here with pros and cons of this framework as they see it? I'm too new to node to really understand the tradeoffs here. Thanks!
Personally, this was how I was creating sites 3 years ago. I made my own framework that does pretty much the exact same thing.
I've completely dropped this in favor of using bidirectional message passing, because imo that's what Node really excels at and it's not something you can get with RoR. If you are using Node.js, it's a good thing to have a framework that does bidirectional real-time communication out of the box. I'm not sure if tower.js supports this or not.
At a very basic level, this is all I need to think about in terms of the API to get some data passed around in my current workflow. I've yet to find something more suitable for myself personally.
CLIENT (mobile or web)
// request data
request = messenger.request('get me a list of things', message);
request.success (response)->
// listen for events from server
messenger.on('someone got something', (message)->
SERVER
// listen for data
messenger.on('get me a list of things', (message)-> message.reply(data)
// emit data
messenger.send('someone got something', data)
While avoiding any new FUD, and since Tower.js is Coffeescript and jQuery top heavy, wouldn't this inevitably lead to conflicts?
(Side note, at the bootcamp the framework recommended was Express.)
CoffeeScript semantics are just JavaScript semantics, which means that CoffeeScript can seamlessly use any JavaScript library, and vice versa, without any special effort needing to be made. This is perhaps the most significant difference between CoffeeScript and most other compile-to-JS languages (https://github.com/jashkenas/coffee-script/wiki/List-of-lang...).
The one feature that you might find yourself relying on in a project like Tower.js is easy access to the prototypal inheritance found in CoffeeScript's "class" keyword ... but you can easily have your library expose that as a helper function.
> CoffeeScript semantics are just JavaScript semantics, which means that CoffeeScript can seamlessly use any JavaScript library, and vice versa, without any special effort needing to be made.
> The one feature that you might find yourself relying on in a project like Tower.js is easy access to the prototypal inheritance found in CoffeeScript's "class" keyword ... but you can easily have your library expose that as a helper function.
Those two statement contradict each other. People who make libraries for CoffeeScript don't go to the trouble of writing a helper function. This doesn't. Batman.js doesn't.
So to consume this a JavaScript user needs to write (or use an existing) extends function. Not hard, but definitely qualifies as "special effort".
I agree with you that Tower and Batman.js should both have "extends" functions built-in (*Ahem: http://backbonejs.org/#Model-extend). It would be a line or two of code for them to add, and make it easier for folks that don't have other library or CS support for setting up prototype chains.
The point is that because CS classes are the same thing as JS prototypes + constructor functions, it all just works together ... in a way that fancier class systems built on top of JavaScript do not.
1. Some people seem to be under the impression that since they're interoperable, it's fine if half your team is doing raw JavaScript and the other half is using CoffeeScript. At some point, one of the JavaScript authors is going to try to modify the generated JS, which will likely be checked in if there's no asset packaging (I've seen this in practice).
2. The way that people design APIs in CoffeeScript and JavaScript is very different, because the things that are easy in CoffeeScript and easy in JavaScript are different. Namely, CoffeeScript libraries tend to leverage the OO capabilities in a way that makes them ugly to use in raw JS. For example, the `@field "title"` stuff would have to expand in a way that's not particularly obvious or concise.
Another example would be trying to use an API like CoffeeKup in JavaScript - the `->` is not visually distracting in CoffeeScript, but having `function() { }` everywhere in the JavaScript code completely destroys the concise nature of the API. In JavaScript, it might be more natural to implement it as an object literal as opposed to nested callbacks.
The reasons:
- DRY! Use the same templates/models/controllers/i18n/validations on server and client! I can't underestimate how awesome that would be.
- One fewer languages to learn and switch back and forth between
- Team flexiblity. No such things as "front end guys" or "back end guys" (sorry girls)
- MASSIVE improvement in debugging. Debugging in Ruby is just bizarrely crappy. Really WTF? How is this possible. Anyway it sucks badly but is pretty decent in JS. (assuming stack traces were decent, this is easy to screw up in js)
Plus there are the inherent benefits of using node (arguable) where you could do push notifications/websockets/etc trivially and in a well integrated way instead of having to... use node (or faye/whatever) or running some other server.
Some people might argue that js/coffee script suck compared to Ruby and cite that as an advantage but I for one love js (and ruby but less so) so I don't care.
This builds on top of two other frameworks (Connect and Express) so I imagine the dependency stack for this framework is really long which might make debugging painful.
* JavaScript * Node.js * Connect * Express * CoffeeScript
He is unfamiliar with just one of those.
Why the downvote? His comment contributes to the discussion, unlike yours.