Live data from Hacker News

Tower.js - JavaScript Framework for Node.js modeled after Ruby on Rails

towerjs.org

111–118 of 118 posts

Re: Tower.js - JavaScript Framework for Node.js modeled after Ruby on Rails

#111

Earlier quoted context omitted.

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…

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…

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

Re: Tower.js - JavaScript Framework for Node.js modeled after Ruby on Rails

#112

Earlier quoted context omitted.

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…

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 detr…

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.

Re: Tower.js - JavaScript Framework for Node.js modeled after Ruby on Rails

#113
post #78

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/serv…

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/

Re: Tower.js - JavaScript Framework for Node.js modeled after Ruby on Rails

#115

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

Re: Tower.js - JavaScript Framework for Node.js modeled after Ruby on Rails

#116

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

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

Re: Tower.js - JavaScript Framework for Node.js modeled after Ruby on Rails

#117

Earlier quoted context omitted.

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…

"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 a…

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.

Re: Tower.js - JavaScript Framework for Node.js modeled after Ruby on Rails

#118

Earlier quoted context omitted.

"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 a…

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…

Ah okay. I thought you were referring to Rails, my mistake.
Post reply on HN