4 ms·

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 her

by matt2000 15y ago

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!

adamrmcd 15y ago
Second. While I'm no expert, I did attend a Node.js Bootcamp this past weekend. One of the topics brought up was Coffeescript and how unwieldily it can be, especially if you mix it with straight-up Javascript, and by extension jQuery. 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.)
- chc 15y ago
  I have no clue what these people were talking about. Unwieldy how? What kind of conflicts? CoffeeScript is totally compatible with JavaScript — in fact, it bends over so far backwards to be compatible with JavaScript that it falls way short of its potential. This all sounds like FUD from some antihipster who just likes to hate on new things. (Which is not to say he or she isn't a smart person overall — everybody has some area where they're irrational.)
- jashkenas 15y ago
  Then I'm sorry to inform you that some FUD did indeed rub off on you at your Node.js Bootcamp... 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-languages-that-compile-to-JS 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.
  - MatthewPhillips 15y ago
    Come on Jeremy, this is so disingenuous. > 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".
    - jashkenas 15y ago
      No, I'm actually trying to be completely ingenuous. I agree with you that Tower and Batman.js should both have "extends" functions built-in (*Ahem: http://backbonejs.org/#Model-extend 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.
      - phleet 15y ago
        So I agree (for the most part) that using them together is not a problem, but I think there still is some justification for the "unwieldly" argument - which may or may not have been what was discussed at the bootcamp. 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.
wavephorm 15y ago
You'd have to already know CoffeeScript and Rails to benefit from this framework. I've used neither so personally I'd have a lot of trouble and a steep learning curve. 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.
- omgsean 15y ago
  When I'm unfamiliar with most of the items being discussed in an article here I usually refrain from commenting.
  - andypants 15y ago
    Items that are relevant to the link: * 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.
- tjholowaychuk 15y ago
  Not necessarily, it's effectively no different than if you were to support the same feature-set in the single library
blindhippo 15y ago
In addition to matt2000's question - I'd also like someone to explain when a node.js rails inspired framework would a better option then a standard rails or symfony based application.
- yeswecan 15y ago
  When you have programmers who are more proficient in writing JavaScript than Ruby or PHP. Better a PHP expert using PHP than a cowboy coder using Node just because it is the new hotness.
- eagsalazar 15y ago
  Assuming this framework is as mature and full featured as Rails (which I doubt), then hell yes this would be awesome compared to using Rails. Also you have to assume you (and other devs) are equally proficient in both languages. 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.
weixiyen 15y ago
It's basically as advertised, RoR for Node.js. This means it has an ORM, has scaffolding, etc. Looks like it takes advantage of express.js and is an abstraction over it. 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)

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!

adamrmcd 15y ago

Second. While I'm no expert, I did attend a Node.js Bootcamp this past weekend. One of the topics brought up was Coffeescript and how unwieldily it can be, especially if you mix it with straight-up Javascript, and by extension jQuery. 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.)

chc 15y ago
I have no clue what these people were talking about. Unwieldy how? What kind of conflicts? CoffeeScript is totally compatible with JavaScript — in fact, it bends over so far backwards to be compatible with JavaScript that it falls way short of its potential. This all sounds like FUD from some antihipster who just likes to hate on new things. (Which is not to say he or she isn't a smart person overall — everybody has some area where they're irrational.)
jashkenas 15y ago
Then I'm sorry to inform you that some FUD did indeed rub off on you at your Node.js Bootcamp... 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-languages-that-compile-to-JS 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.
- MatthewPhillips 15y ago
  Come on Jeremy, this is so disingenuous. > 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".
  - jashkenas 15y ago
    No, I'm actually trying to be completely ingenuous. I agree with you that Tower and Batman.js should both have "extends" functions built-in (*Ahem: http://backbonejs.org/#Model-extend 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.
    - phleet 15y ago
      So I agree (for the most part) that using them together is not a problem, but I think there still is some justification for the "unwieldly" argument - which may or may not have been what was discussed at the bootcamp. 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.

wavephorm 15y ago

You'd have to already know CoffeeScript and Rails to benefit from this framework. I've used neither so personally I'd have a lot of trouble and a steep learning curve. 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.

omgsean 15y ago
When I'm unfamiliar with most of the items being discussed in an article here I usually refrain from commenting.
- andypants 15y ago
  Items that are relevant to the link: * 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.
tjholowaychuk 15y ago
Not necessarily, it's effectively no different than if you were to support the same feature-set in the single library

blindhippo 15y ago

In addition to matt2000's question - I'd also like someone to explain when a node.js rails inspired framework would a better option then a standard rails or symfony based application.

yeswecan 15y ago
When you have programmers who are more proficient in writing JavaScript than Ruby or PHP. Better a PHP expert using PHP than a cowboy coder using Node just because it is the new hotness.
eagsalazar 15y ago
Assuming this framework is as mature and full featured as Rails (which I doubt), then hell yes this would be awesome compared to using Rails. Also you have to assume you (and other devs) are equally proficient in both languages. 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.

weixiyen 15y ago

It's basically as advertised, RoR for Node.js. This means it has an ORM, has scaffolding, etc. Looks like it takes advantage of express.js and is an abstraction over it. 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)