
Tower.js - JavaScript Framework for Node.js modeled after Ruby on Rails - jot
http://towerjs.org/
======
eldude
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.

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

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

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

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

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

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

------
thelastnode
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:

    
    
        require('coffee-script');
        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.

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

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

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

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

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

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

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

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

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

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

    
    
      javascript:(function(e,a,g,h,f,c,b,d)%7Bif(!(f=e.jQuery)%7C%7Cg%3Ef.fn.jquery%7C%7Ch(f))%7Bc=a.createElement(%22script%22);c.type=%22text/javascript%22;c.src=%22http://ajax.googleapis.com/ajax/libs/jquery/%22+g+%22/jquery.min.js%22;c.onload=c.onreadystatechange=function()%7Bif(!b&&(!(d=this.readyState)%7C%7Cd==%22loaded%22%7C%7Cd==%22complete%22))%7Bh((f=e.jQuery).noConflict(1),b=1);f(c).remove()%7D%7D;a.documentElement.childNodes%5B0%5D.appendChild(c)%7D%7D)(window,document,%221.6.1%22,function($,L)%7B$.getScript(%22http://cdnjs.cloudflare.com/ajax/libs/coffee-script/1.2.0/coffee-script.min.js%22,function()%7Bvar%20a;a=$(%22code.coffeescript%22);a.each(function()%7Bvar%20a;a=$(this).text();return%20$(this).text(CoffeeScript.compile(a,%7Bbare:!0%7D))%7D);return%20a.each(function()%7Breturn%20prettyPrint(this)%7D)%7D);%7D);
    

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.

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

~~~
thenduks
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/>

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

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

~~~
jashkenas
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...](https://github.com/jashkenas/coffee-script/wiki/List-of-languages-
that-compile-to-JS)).

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

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

------
mutewinter
GitHub Repo - <https://github.com/viatropos/tower>

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

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

------
rgbrgb
Unfortunate naming conflict... <http://towerjs.com/>

------
alttab
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?

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

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

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

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

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

~~~
zzzmarcus
Looks like it may have been abandoned. Last commit was 5 months ago.
[https://github.com/anatoliychakkaev/railwayjs.com/commits/ma...](https://github.com/anatoliychakkaev/railwayjs.com/commits/master)

~~~
mcantelon
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>

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

------
elliottkember
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?

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

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

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

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

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

------
drumdance
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?

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

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

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

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

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

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

------
copremesis
Title update:

Tower.coffee - CoffeeScript Framework ...

------
nathan_f77
This looks amazing.

------
jsavimbi
Looks interesting. I will download and have a look.

------
tjholowaychuk
moar rails? moar coffeescript?

