Tower.js - JavaScript Framework for Node.js modeled after Ruby on Rails
towerjs.org
towerjs.org
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.
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.
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.
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.
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.
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.
A side note, am I the only one that has noticed an increase in downvote-readiness here lately?
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
If you love being ignorant of CoffeeScript enough to publicly form your identity around it then stop being in denial about your tone.
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.
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.
Oh man!
I guess I don't know any programming languages whatsoever.
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.
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.
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..
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?
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 think OP will get by without your career advice pretty well.
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, 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 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.
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
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 wish you the best regardless of your scripting language of choice! :)
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.
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.
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.
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.
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.
Maybe it is a good idea to have the value of downvotes diminish the more you use them.
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.
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.
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.
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.
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');
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.
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.
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.
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.
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.
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.
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.
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);
I still think it ought to decide whether it wants to be a CoffeeScript or JavaScript framework, though.
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...
But, a framework that spans client/server could be really interesting. Have you seen Derby? http://derbyjs.com/
I hope this grows. I'd love to contribute too.
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.
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.
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.
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)
Source for towerjs.org (written with Tower.js) - https://github.com/viatropos/towerjs.org
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.
It's strictly focused on the backend, and remains strongly view and database agnostic.
Here's the project repo: https://github.com/1602/express-on-railway
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?
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.
Tower.coffee - CoffeeScript Framework ...