Hacker News new | comments | show | ask | jobs | submit login
Tower.js - JavaScript Framework for Node.js modeled after Ruby on Rails (towerjs.org)
221 points by jot on Feb 27, 2012 | hide | past | web | favorite | 112 comments

Thanks for the efforts and the framework. Unfortunately, I cannot properly appreciate it for the following reason:

Please don't call something JavaScript if it's actually all in CoffeeScript (even if it's just the documentation). A lot of us have not bothered to learn CoffeeScript and a good many of them have no intention of doing so. My time was wasted following a link that says "JavaScript", a language I know well, only to discover it was in CofeeScript, a language I have not bothered to learn, nor do I plan to anytime soon. I would down vote this if I could merely for the mislabeling. If you love CoffeeScript enough to use it as you obviously have, own it, advertise it openly and stop being in denial that CoffeeScript as a written language is different from JavaScript as so many CoffeeScripters seem wont to do.

To the down voters:

My comment is civil and explannatory. You may not like my sentiments, but down votes are not intended for unpopularity. Not only that, but in this case, my comment serves to reinforce the standards of HN regarding mis-titling of links and it is being downvoted.

A house divided against itself cannot stand.

I have to apologize. I fat-fingered the down vote when I originally meant to up vote your original comment. I think that my mistaken down vote was the one that initially sent your comment into the gray. This was unfortunate as yours was a remarkably civil post on a subject that can be somewhat controversial at times.

I am currently working on two projects written predominantly in CoffeeScript, and I completely agree with your original post. It is a mistake to think of CoffeeScript as simply another Javascript, and it is a mistake to make the assumption that people that are comfortable with Javascript will be comfortable within a CoffeeScript project.

CoffeeScript is more than just Javascript with a small sprinkling of syntactic sugar. There is a definite learning curve between Javascript and CoffeeScript. List comprehensions, extended regular expressions, and splats - these are just a few of the things that make up that learning curve. The changes in variable scoping that CoffeeScript makes is another.

I think that perhaps the best practice for publishing a CoffeeScript project should probably be to append a .coffee to the name rather than the usual .js. This would go a long way towards eliminating the kind of misunderstanding that you refer to in your OP.

+1 for the idea of calling it tower.coffee instead of tower.js

Your original comment did come across as a bit harsh but it didn't deserve anyone's downvote. I think your stance can be summed up similar to mine: Just because I haven't learned Coffeescript doesn't mean I don't plan to, or at the very least, doesn't mean I am against it. I (like you) would like to see the site's documentation in Vanilla because, after all, both Coffeescripters and Javascripters can read pure Javascript.

A side note, am I the only one that has noticed an increase in downvote-readiness here lately?

"a language I have not bothered to learn, nor do I plan to anytime soon"

That's why I down voted you. Is a JS compiler beneath you? Fine. Then post about that. Don't try to slip it into a veiled complaint about title accuracy.

His statement is factual, I see no veiled complaint in the text you've quoted.

So it is fair to call any library written in C an ASM library? C compiles to ASM (in most implementations) after all...

Oh, come on. How can you be at all familiar with JS and not be able to figure out what a CoffeeScript snippet is doing? It's not quite the difference between C and assembly.

That's not the point of his comment. It's labeled javascript when it is actually coffeescript. Call it tower.coffee, not tower.js.

If I can't fork and contribute to the project in javascript, but instead have to set up my environment for coffee script to contribute, then it's not javascript.

This isn't just about readability and comprehension, it's about contribution as well.

If the compiled javascript is bundled in there and I can read it, fair enough. If you can't accept patches and code contributions in javascript, then that's not javascript.

...you know JavaScript well and haven't bothered to "learn" the second-most-popular dialect? Take ten minutes right now and read through the CoffeeScript reference-- poof, you learned it. It is just JavaScript.

Really, no one's forcing you to write it. But if you have a working understanding of JavaScript and you can't read CoffeeScript fluently, it's because you aren't trying. Just swallow your pride and deal with it already.

you know JavaScript well and haven't bothered to "learn" the second-most-popular dialect?

Come on, what kind of percentage are we talking about here? Tiny. Absolutely tiny.

Take ten minutes right now and read through the CoffeeScript reference-- poof, you learned it. It is just JavaScript.

Well, you haven't learned it unless you memorised absolutely every aspect of it, which you're unlikely to do on a first read. And it isn't "just" JavaScript- it has significant whitespace, different object notation, etc. etc.

Don't get me wrong, I've started using CoffeeScript and I like it. But it's a tiny, tiny minority language. There are a ton of JavaScripters out there that haven't learnt it because they don't need or want it. That's their choice.

For better or for worse, not so "tiny, tiny" anymore: http://redmonk.com/sogrady/2012/02/08/language-rankings-2-20...

I wonder how much of CoffeeScript's prevalence on Github can be contributed to existing projects ported from JavaScript. Either way it's not a particularly important point as CoffeeScript is a "dialect" as everyone likes to say and not a language, so this will likely always more or less be the case, surprising nonetheless.

>Well, you haven't learned it unless you memorised absolutely every aspect of it

Oh man!

I guess I don't know any programming languages whatsoever.

With significant white space, brace insertion and other things happening, it's not the easiest language to read. I say this as someone who has written his share of applications in CoffeeScript.

The irony of course being that you could have learned the basics of CoffeeScript in the time it took you to write that.

If you love being ignorant of CoffeeScript enough to publicly form your identity around it then stop being in denial about your tone.

It was the coffeescript that put me off too. I dont have anything against CS, i just dont want the additional overhead of having to learn it

learning is the overhead with the best return on investment.

not everybody wants to jump into learning solutions that solve other people problems, prefer to learn the ones that solve theirs. if someone doesn't need coffeescript, there's no ROI.

But you really don't need to learn CS... It's just a slightly different syntax that you can learn literally in 20 minutes, but makes your code more robust and clean (eg; no more comparing against "undefined" and then nil, just put a ? after variable name - it saves you time and you don't accidentally forget about it. It makes your code better)

Nobody would argue about his comment if CS wasn't such an easy language to learn. If you know PHP, you can learn writing in ASP.net in a week, but if you know JavaScript, you can sing in CoffeeScript in an hour.

If you think that tower may solve your problem and the only obstacle is that it's written in coffeescript, then learning coffescript is now solving your problem.

I'm going to reply to my own comment in order to address the numerous responses all at once.

First, I'll establish some modest authority on the subject by pointing out that I've worked directly with Tim Caswell, who helped create CoffeeScript, at multiple jobs now. He's explained to me how they developed it and we've discussed the merits of it.

Second, I don't believe CoffeeScript is lacking merit. I make no claims of such. I'm actually happy that CoffeeScript exists in that I hope it brings more people into the JavaScript fold so long as it does not detract in ways like this.

Third, I understand what CoffeeScript is and how it works, but have chosen not to learn it. That's my prerogative and I make no claims to the superiority of that choice apart from my choosing it.

Fourth, I _could_ talk about how time is not free. Installing a CoffeeScript compiler, learning CoffeeScript, undertaking the mental frame of reference change necessary to switch between context, are equally not free, but I don't feel the need to further this defense as it has been made many _many_ times before, especially here on HN.

In reality, this is about none of the above. This is labeled as JavaScript when _it is not_. I repeat, CoffeeScript is _not_ JavaScript. To the many responses this will incite, I'd direct you to my points above. This is not intrinsically a bad thing. Far from it, if CoffeeScript was not different, it would not be relevant. It is its difference that makes it relevant. I will likely eventually learn CoffeeScript when it becomes necessary or worth it. In fact, I attempted to previously, but setting up auto-compilers, etc... took about 20 minutes too long, and given the insufficient value proposition, I didn't bother to finish learning it.

I come across many node/JavaScript/Github projects regularly and don't have the time to bother learning or using 90% of them, but I bookmark them because they are intriguing and I hope to have them if and when I do need or want to use them. That's 9/10 _JavaScript_ projects that I don't get to just because I don't have the time.

I'll repeat my main point because that is all my original comment was ever about, if CoffeeScript is not different, there's no point in it existing; if it is different, then it's a positive reason otherwise it would receive no attention; if it is positively different, then why not market it as such? It's obvious that those who point out that CoffeeScript is a dialect and compiles to JavaScript so it is therefore an acceptable mis-labeling are attempting to have their cake and eat it too at the expense of people like me that either have not taken the time to learn it yet, or do not care to for _numerous_ philosophical reasons which I defend are quite valid, though being a pragmatist, ultimately will not factor into my reasoning.

What I as one of your downvoters argue is that it doesn't take more than an hour to learn CoffeeScript. I don't believe anyone is arguing that it should be labeled as JS when it's CS.

What made me downvote both your original and this comment is that I can't accept that you (seemingly) write a lot of code in JS, but don't want to spen just 1 hour to learn CS properly (I know it takes this short, because I just did it a while ago. I haven't written any JS code since I was 14 - 6 years ago - but started reading coffeescript.org and in 3 hours was able to do everything I wanted in CS. So for a JS master like yourself it wouldn't take longer than an hour to master CS too).

To me, your comment sounded like an abacus master who doesn't want to learn Arabic numbers and multiplication table, because he's too busy. And again, I have nothing against you and downvoting a comment on HN !== hating you and/or disagreeing with everything you say or think.

This pervasive assumption of CoffeeScript's superiority as a foregone conclusion is ridiculous. There are so many excellent JavaScript programmers that choose not to program in CoffeeScript for so many reasons, that it's surprising to see the extent of this assumption. Defend the merits of CoffeeScript all you want, I'm not even bothering to argue with you about them, and _I even conceded already that it does in fact have merit._ However, if at JSConf this year, I start seeing a bunch of projects presented in CoffeeScript, but advertised as JavaScript, I'm going to simultaneously be incredibly annoyed at the presumptions of such behavior while I learn CoffeeScript in order to follow along because it will have crossed the threshold.

My original point still stands that this is a mislabeled title. If this is JavaScript, and I know JavaScript, then I'd be able to understand the code without learning something else. Yes, again, I _could_ go learn that thing and thus understand the documentation as I almost certainly eventually will, but how disingenuous of the CoffeeScript community to refuse to call CoffeeScript by its name, expecting _everyone else_ to learn CoffeeScript in order to treat it as equivalent, when it very clearly is not. Just be straightforward and call it CoffeeScript _because you think CoffeeScript is awesome_.

Why on earth is this disturbingly so objectionable?


I've never disliked the fact that it was built, everyone has fun playing around with little transpiler things but it's turned into some retarded religious warfare. The show-stopper for me is when it gets to the point of pull-requests containing "Add coffeescript support". Once you go that far it's just flat-out wrong

People who write libraries and frameworks want to advertise them, get good SEO from the larger JS community. So they'll call their projects Blah.js.

It's also easier to remember JS libraries as Blah.js instead of having to worry that it's Blah.js or Blah.coffee.

Yes it is somewhat dishonest. But users of a lib or framework should not be reading its code in most circumstances. Otherwise it's crap API/documentation.

With CoffeeScript you can use the lib from JavaScript seamlessly. It is essentially Blah.js. If the lib was written in Ojb-J or ClojureScript that's another story. Then lib authors couldn't say it's Blah.js.

If you need to read coffee code as JS for some reason, compile it. If you need to submit a patch, doing it in CoffeeScript will indeed be a minor inconvenience. Not so for Clojure, Obj-J or whatever else will come along.

---- And on another note. These languages compiling to JS are essentially causing fragmentation. If ClojureScript gets as popular as CoffeeScript is now it won't be pretty. I'll bet that CoffeeScript will reach critical mass at some point. The newest libs and tutorials will all be Coffee. JS.next should adopt as many features as possible or promote it as the new standard to stem the tide and make fragmentation less obvious. CoffeeScript would be more stable as a language, hard to make JS semantics prettier.

>Why on earth is this disturbingly so objectionable?

Ruby dev here with limited JS/CS knowledge. Are there any sections of CS where the semantic mapping to JS is not obvious? It took me about five minutes to figure out what was going on.

I completely agree with you about the title, as I've said it twice already (thrice, including this one!). What I completely disagree is the other parts of your original comment.

I wish you the best regardless of your scripting language of choice! :)

You end by saying that downvoting !== hating him or disagreeing with everything he thinks, yet I can't find a worse reason to downvote than the explanation you gave right before: you literally downvoted him because of a personal decision he makes in his life that affects no one else regarding the learning of a programming language, and not at all for any factual inaccuracy in his comment.

He never said anyone else should not learn CoffeeScript nor that CoffeeScript was bad, but that for whatever reason in his own personal life it hasn't become valuable enough to do so. And yet still, the point of his comment had nothing to do with that, and instead simply requests that stories be labeled accurately. Seems completely uncontroversial to me.

Of course I downvoted him because I disagreed with what he was implying! Downvotes are not just for burying trolls, but meant to be a mean of expressing how much you agree with a comment (the opposite of an upvote).

in the last part, my emphasis was on the word everything. If you divide that comment into two different comments (first being 'misleading article' and second, (implicitly) 'I don't want to learn CS, though I write code in JS regularly'), I'd up vote the first and down vote the second comment.

It is true that his decision does not affect anyone else, but I don't believe that even such decisions can't be criticized. And I'm arguing that his decision of not wanting to learn a dialect of a language he uses on a daily basis (that would take a very short time) is not a good one, and is un-hackerish. If he had taken time to learn and have decided that CS is not for him, I neither would've down-voted him, nor would I comment on his decision.

I'm sorry if I wasted your's or any one else's time by my comments on this unimportant matter. I know that HN's comment section is meant to be a place for constructive arguments, but I couldn't help it. I read that an unseen friend is doing something that I think is really wrong, and I can't help mentioning it.

In my three years of being on this website, I haven't had to downvote anything except spam or deliberate trolling. And that too, rarely.

Maybe it is a good idea to have the value of downvotes diminish the more you use them.

Second that. Before maybe about half a year ago, I rarely observed downvotes on comments that are not rude, worthless, ot totally offtopic. Now the fluctuation of up/downvotes on comments (including mine) got out of hand and people use it to 'disagree'. It's stupid. I wouldn't mind if pg removed downvoting at all.

I think of downvotes as opposite of upvotes. If you agree with the gist of a comment and find it informative or useful, you upvote it. If you really disagree, you downvote it (and if possible, drop a line to say why you disagree). If I'm wrong and that's not the way things are being done here, I apologize from OP.

I think another way could be to decrease a users karma by 1 for every 5 downvotes he makes... and also limit the number of downvotes a user can make in a day.

It's not just an hour to learn. There's also the time to set up tools and environment. It's added complexity up front, and that alone is enough to turn people off because there is nothing so wrong with javascript to warrant the effort.

If you know javascript well and are familiar with it's many gotchas and you know how to use your text editor well with javascript, the coffeescript really doesn't add more than it detracts.

So, with something like Tower.js the code is written in coffee to start with (https://github.com/viatropos/tower/tree/master/src), but in the repo (and in npm) you'll actually get the resulting JavaScript as well (https://github.com/viatropos/tower/tree/master/lib and https://github.com/viatropos/tower/tree/master/dist).

This is generally true of most CS projects. I can't speak specifically to whether or not you can use Tower.js without coffee, just saying don't discount a project because the author wrote it in CS. Spine.js (http://spinejs.com) is a great example of what I'm talking about.

Are you arguing the HN title or the site description?

The HN title. It feels like a bait-and-switch when I click a "JavaScript" project link and see CoffeeScript documentation.

Wow, a lot of people are really defensive about coffeescript.

Likewise, I care not for, nor to learn, PHP, Ruby, Java, Python etc., but I can understand whatever I need to.

If you're a half-way decent js dev, it's hard to believe CoffeeScript could be a cognitive stumbling block for you. Inferring custom baked inheritance in js libraries surely is more difficult.

Of course CS isn't for everyone, but a hard stance that a CS lib can't be considered 'JavaScript' seems more of a political stonewalling than an intelligent conversation. But, I've come to expect such thorny defenses cultivated by a coterie of stern acolytes who have devoted themselves to a particular flavor of programming.

It generates JavaScript. If you want to read JavaScript, it's there for you to do.

I think you'll have a hard time running their documentation through the Coffeescript compiler.

I know, I must have been reading way too quickly. I thought he believed the actual code had to be in CoffeeScript, so I was explaining that it can compile to relatively readable JavaScript. When I came back and reread my comment, I wanted to edit or delete it, but it was already past the two-hour mark. I do agree, it seems rather silly to have the docs for a JavaScript framework written in CoffeeScript.

As sort of an apology, I wrote up a little bookmarklet to translate the page into JavaScript at http://news.ycombinator.com/item?id=3641217

No offense to your original statement, what you said makes sense--the link was mislabeled in a common way.

I just want to point to this comment and its children as the reason that HN should have comment thread collapsing.

There's no reason the majority of people checking the comments for this link should have to see the language debate. It's not relevant to the Tower framework. The only reason this debate is so high up is because people chose to upvote the original comment.

CoffeeScript directly compiles into JavaScript. The fact that the source code is written in CS does not mean you can't use it with JS.

By comparison, think about Python. Some libraries use C for performance gain. Does that mean you can't use them with Python? No. These are still perfectly valid Python libraries.

That's a terrible argument. I still write and read Python with libraries that use C (for example: the entire standard library). If you want an example that fits the point you are trying to make, consider Lua/C, where you _can_ mix the two easily.

The point is still flawed, though - CoffeeScript is not JavaScript, and I have no interest in learning it (I'd rather spend the time learning to write better JS myself). I, and everyone else with my mindset, has their time wasted by this mislabelling; we would not have clicked through if the title said CoffeeScript.

But who said you had to use CoffeeScript? You can perfectly use this library by writing standard javascript.

The author decided to write the source code of the library in CoffeeScript, which then compiles to perfectly valid javascript that you can import.

The analogy about Python is that you don't have to know C to be able to use a Python library written in C..

If I had the ability to downvote your post I would have. Your comment "I have not bothered to learn, nor do I plan anytime soon" goes against everything I believe in as a web developer.

Sure, I may not be proficient in everything, but I try to have a working knowledge of all of the latest popular technologies so that I am not ignorant to what's going on around me. Like others have stated, 30min is all you need to really grasp what's going on in coffee script. Is that kind of time investment really that challenging to come by?

I didn't downvote him because of his civil comment about misleading comment, but because of his un-hackerish tone about him not planning to learn something that is completely relevant to his career (his description in his page is: I'm a JavaScript and Node nerd). Maybe I shouldn't have done it, but I really have nothing against him. I truly wanted him the best and downvoting his (IMO) wrong comment was an effort to make him understand that what he is doing is wrong.

We are all online friends and friends ought to warn each other when they see their friend is doing something stupid (I really think writing any script longer than 20 lines in JavaScript instead of CoffeeScript is stupid).

> I really think writing any script longer than 20 lines in JavaScript instead of CoffeeScript is stupid)

I think OP will get by without your career advice pretty well.

You can never know! That's what I'm saying. it's not like learning a new programming paradigm (like functional) that will take days or weeks, it will take 10 minutes reading www.coffeescript.org front page to see if my career advice is right or wrong. You can't call yourself a nerd without knowing the most thriving dialect of that language... Specially if you're young and reading a hacker website.

I realy don't want to get into a virtual pointless argument, but just out of curiosity: do you know CoffeeScript? Because it's very strange to me that someone might be against using CoffeeScript and condemning it like that (its debugging is worse than JS, but on every other front it's the clear winner). if you're not familiar with it, I suggest you take a look at CoffeeScript.org to see how and why it differs from JavaScript.

First of all, I'm not condemning using CS. Frankly, I couldn't care less if you use it or not. If it fits your needs, good for you. Second, OP is probably a big boy and can decide for himself (as can I) what tools to use to get stuff done. Pissing contests like 'you are not a nerd if...' are not for me, so let's not 'get into a virtual pointless argument'.

So I see the rage is all about dissing Rails as often as possible these days, more often than not in the Node community. Yet Tower is a virtual copy and paste of the popular Ruby web framework and it's pure awesome.

There is something of a schizophrenic behavior at work here. I am a Rails dev, I love the framework for all its strengths and would choose to live with its (relative) shortcomings any day but I think there's something not healthy about how it seems that a new (web framwork|language|paradigm|whatevs) always has to (kill|take a dump on) the competition to claim the spotlights.

The two technologies can co-exist without a problem, there are many pieces of software to fill that gap without having to reinvent the wheel where Rails does the job just fine.

And to anyone saying Rails has become "bloated", quit the catchphrases-based rhetoric already, a Rails project is nothing more than a set of conventions and classes, the developer (that's you) has a choice of tools every step of the way, so if your app is bloated, stop producing bloated code or hopelessly waiting for a silver bullet, IT IS NOT HAPPENING. NEVER. NODE WON'T BE IT EITHER.

Three years from now, some clever dude will come up with a new fresh concept, Node will suddenly be so 2012 but deep down you'll know.

You'll know it's the same old caper below the latest layer of paint and glitter.

Props to the people who worked hard on Java frameworks who make tons of people happy in the heavy infrastructure enterprise realm, props to the people behind PHP and associated frameworks, props to Rails dev for pushing the envelope and making me enjoy programming again and props to Ryan Dahl, Google and Joyent for making Node happen and shaking the bottle once again.

It does NOT have to be X VS Y VS Z.

Regarding the Coffeescript-Javascript difference, Coffeescript and Javascript can be used transparently in node. Once require('coffee-script') is run, the module replaces the require function with one that can load both Coffeescript and Javascript.

This means that if there is a file ./lib/foo.coffee, the following code in bar.js will work:

    var foo = require('./lib/foo');
Yes, some people may not like Coffeescript anywhere in their project, but this functionality makes it easy to add Coffeescript to an existing Javascript project or use Coffeescript modules as a blackbox in a Javascript project.

That's pretty cool. I didn't know that worked so seemlessly.

Nonetheless, in order to use a library, you must either read the documentation or the source. The biggest issue is that most CoffeeScript projects document with CoffeeScript. Technically, you could read the compiled source, but that's usually a non-starter unless I truly need your project. Otherwise, I'm more likely to find someone else that's solved the same problem, but has written their docs / source in JavaScript.

am i the only who is not excited by any "RoR"-like framework?

i like node because it lets me build small standalone programs/apps which i can link together to act like on big project.

i - for one's part - found that having one master-overlord framework kills a lot of the joy of programming.

ok, there is the "it's much more manageable" argument, but well, my experience is that big apps on RoR need much more maintenance work then similar programs on much uglier stacks (i.e. webprojects using LAMP)

said that - after reading some of the docs - i will probably give towerjs a try.

The bulk of today's web devs are coming from Rails and it's nice to have that hand-holding when you're trying to cross that chasm. Besides, a lot of the concepts that RoR were built on are sound (i.e. don't reinvent the wheel every time you make a new project), even if Rails has become as bloated as the technologies it replaced (J2EE, .NET).

>The bulk of today's web devs are coming from Rails

Ahem, you're exaggerating there just a little bit. There are probably around a dozen web frameworks that are competing for the spotlight right now. With Zend, CI, Django, Symfony, Struts, Cake, etc. all equally if not more popular it's hard to say Rails has the "bulk" of today's web devs. I wouldn't even go as far as saying that the bulk of today's web devs appreciate MVC.

Who cares how many people use these frameworks, most of them are using the same MVC structure and are just stealing features from each other.

Some of the Node people like things small but when applications get bigger putting things into an MVC structure often makes your code more organized. Until someone comes up with a better idea that takes off this is how things will be done and I think it's great that Node has a few choices now to do this.

There's a difference between using an MVC pattern (which is easy with Express, but is completely optional) and relying on an ORM (which the project forces on you). One of the great things about minimilist frameworks like Express is that you can build it out and customize it like you need.

The types of projects that benefit from being in node.js instead of Rails, Django, etc, don't really benefit from having all those decisions made in advance. If the "Rails Way" works for your project, you'll probably benefit from doing it in rails. There's certainly more library support and it's easier to find more experienced developers for Rails than node.js.

There's a tendency to put all kinds of projects in node now, just because it's "hot". Some projects benefit from node, and some would be easier to do in some other language/framework. If you're experienced with Rails and are working on a project that fits that style, you're probably better off just doing it in Rails rather than switching to node and using a Rails flavored framework.

"relying on an ORM (which the project forces on you)"

By the project, I presume you mean Rails. Because Rails doesn't force ORM on you. It assumes that by default, but if you don't want to use an RDBMS and ORM, you simply remove the inheritance from ActiveSupport::Base from your model class and write a class that talks to whatever you prefer.

Rails makes the reasonable assumption that most people will be talking to an RDBMS. It could omit that and instead you could "build it out and customize it like you need", but that way lurks 7,000 line XML config files and all the other crap lots of Rails folk were trying to escape from. The point of convention over configuration is that for some baseline assumption of normal, it comes ready to rock and roll.

No, the Rails inspired node.js framework forces an ORM on you. My advice throughout this thread has been to stick with Rails if the Rails conventions do it for you. There's certainly nothing broken with that approach. I don't think Rails is the right tool for every problem, but for the ones that it is, people will probably be better served using that, rather than re-implementing it in node.

I'm neither anti-Rails or anti-ORM. But the types of projects that actually benefit from being in node, rather than Rails generally benefit from not being tied to those conventions. If what you're doing fits the Rails pattern, that's probably a better solution than anything in node. If you're doing a project that doesn't fit that, and you need lots of customization, you're probably better off doing that from scratch (or with a minimal un-opinionated framework).

I think both have their places. It really depends on the project.

Ah okay. I thought you were referring to Rails, my mistake.

For anyone turned off by the CoffeeScriptiness of the page, here's a bookmarklet that will compile the CoffeeScript into JavaScript:

Aside from CoffeeScript's __hasProp and __extends boilerplate at the top of each code sample, it's pretty readable if anyone's interested.

I still think it ought to decide whether it wants to be a CoffeeScript or JavaScript framework, though.

Who cares?

There is express, geddy, railwayjs, djangode, drty, Locomotive, spludo and probably a few others that I missed. All of them are modeled after rails/django.

The last thing the node-ecosystem needs is yet another half-baked rails-clone.

This may come across harsh but I really don't understand why people keep beating that dead horse instead of tackling the node-vision: Build a framework that spans client/server. Make it good. Start by not pouring your time into yet another rails-clone...

I disagree that node doesn't need more projects like this. And I disagree that express/geddy/etc are 'modeled after rails/django'.

But, a framework that spans client/server could be really interesting. Have you seen Derby? http://derbyjs.com/

The best part about this in my opinion is that the controller system works on both the client and server. I've been waiting for this, was planning on building it myself if no one figured that out.

I hope this grows. I'd love to contribute too.

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!

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

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

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

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

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.

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

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


// listen for data

messenger.on('get me a list of things', (message)-> message.reply(data)

// emit data

messenger.send('someone got something', data)

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.

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.

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.

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.

Not necessarily, it's effectively no different than if you were to support the same feature-set in the single library

When I'm unfamiliar with most of the items being discussed in an article here I usually refrain from commenting.

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.

GitHub Repo - https://github.com/viatropos/tower

Source for towerjs.org (written with Tower.js) - https://github.com/viatropos/towerjs.org

Is there any way to share models with the client and the server ?

I'm not sure a pure MVC (or a Model2) is the best way to architect node web applications. The config part looks great, I'll read that more carefully tonight.

Unfortunate naming conflict... http://towerjs.com/

I'm admittingly a little ignorant when it comes to node, but isn't making it more like Rails a step in the wrong direction?

Node isn't an application framework, it's an event-driven javascript-based server. This is totally an acceptable way to handle it, so long as it takes advantages of Node's event-based system.

Locomotive is another option writing MVC web applications in Node, using the familiar structure from Rails: http://locomotivejs.org/

It's strictly focused on the backend, and remains strongly view and database agnostic.

I "like" how there are currently 96 comments in this thread and not even one touches the subject, discussing merits of tower.js.

I thought of the same as well, would really like some constructive discussion on the differences.

Another Rails-inspired Node framework built on Express: http://railwayjs.com/

Looks like it may have been abandoned. Last commit was 5 months ago. https://github.com/anatoliychakkaev/railwayjs.com/commits/ma...

That is the repo for the project's website, not the prohject itself.

Here's the project repo: https://github.com/1602/express-on-railway

It is not, it was moved to this repository https://github.com/1602/express-on-railway for some reason.

This looks good. I've messed around with Railways http://railwayjs.com/ but some parts are funky and the docs haven't been updated since they opened the project. Also looked at Matador http://obvious.github.com/matador/ and actually was re-writing it in coffeescript to use CS' classes instead of the Klass plugin, but lacked docs. Zappa http://zappajs.org/ is written CS but really isn't an MVC. This looks well documented and it's in CS which I like. +1

I got really excited about this, thinking it was a Rails-style front-end framework. It's still really cool as a server-side framework, but I'm totally hankering for a full Rails stack in the browser.

I've used Backbone and played with Spine - I just can't help but feel as though they could go all the way. I wonder whether that's viable?

I had a similar endeavor having it built on top of Express.js ecosystem: https://github.com/umbrellacorporation/umbrella/

Why don't you put the link to the source code[1] on the website? I have to actually search it via google.

[1] https://github.com/viatropos/tower

Link is on the upper right of the page. 'Fork me on GitHub'.

This has turned into a debate on coffeescript. Would love to get more explanation from a Rails developer point of view about how the integrated javascript client/server model works.

Geddy is another framework for node that is "rails-like" - the models work on the client side too. http://geddyjs.org

I have an API in rails that I'd like to move to Node without having to re-write all the ActiveRecord code as SQL. Am I right to assume this is a good tool for that?

Has anyone tried deploying a tower.js app to Nodester yet? Let me know if you need a hosting coupon - chris@nodester.com

Where/how do events fit within this framework? Couldn't find any explanation of it on the project page (or here...).

i don't see why you should force someone to use coffeescript though

While I agree with some others here that calling it a JavaScript framework is a bit of a stretch, there are legitimate reasons to do this in coffeescript as opposed to javascript.

In particular, the Rails-y way of doing things requires particular concise classical OO abstractions that are difficult to provide in a pure prototypal JavaScript way without introducing your own class library (which there are far, far too many of).

For example, if you look at the definition of the App.User here: http://towerjs.org/models, trying to do the same kind of thing where you can quickly declare a class that extends a base class and adding things to it can become quite awkward.

You'd have to manually construct the prototype chain (or use the library-specific class DSL) and have to repeat the class name in order to call the "field" method there.

TL;DR Rails uses mixins and classical OO extensively, CoffeeScript facilitates this, JavaScript makes it difficult.

Thank you for taking the time to explain that, I hadn't even thought about it like that, the venom in some of the other responses to people who are skeptical of coffeescript is really alarming.

Nice and finally a Node.js framework I will be able to understand.

Title update:

Tower.coffee - CoffeeScript Framework ...

This looks amazing.

Looks interesting. I will download and have a look.

moar rails? moar coffeescript?

Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact