Hacker News Reader

Comment by sideproject | Hacker News Reader

Couldn't agree more. On a different topic, I've been toying with various JS MVC frameworks, but a lot of them tries to do their "magic" without actually explaining why the magic is necessary. These so called "conventions" at times hide way too many things, it actually makes it frustrating to understand. In the end, my choice came back to Backbone, which is the minimalistic framework.

Having said that, I'm trying to pick up NodeJS soon, what frameworks would you recommend to start off with? Express?

View on HN

Yes, express is very simple, and easy to learn and write. It's also the most popular web framework for node.js.

It's less like rails/django and more like sinatra/flask.

Hey guys, I wrote Sails.js. The controllers are just sets of Express middleware. The reason I did it this way is that I wanted a conventional abstraction (MVC) without the burden of a new API.

The only real "magic" here is how Sails handles Socket.io requests using the same controllers. Sails generates req/res objects for socket requests and allows you to handle WebSocket requests in the same code base as the rest of your app. If you need to do more custom stuff, you can still directly access Socket.io through sails.io, and each request object that came from a socket request contains req.socket, which gets you access to the socket which sent the message.

@sideproject Actually you can use Sails (https://github.com/balderdashy/sails) with whichever front-end framework you like. It's architected to serve a nice clean RESTful API and leave the front-end up to you.

The argument (as I see it) against choosing something like Backbone in order to avoid framework "conventions" is that you inevitably end up inventing your own conventions to fill in the gaps.

Fine if you're a one-man team (although still arguably only in the short-term), but if not, all you've done is shifted the "conventions" problem onto your co-workers, only now they have to learn yours, rather than the (hopefully) well documented and worked-out conventions of the framework you tried to avoid to begin with.

(I'm currently using Backbone by the way, but very conscious that it could be a short-sighted approach - basically I'm keeping a keen eye on Ember)!

Absolutely agree-- Backbone is a great step in the right direction, but it leaves tons of things to chance. We use Mast internally (https://github.com/balderdashy/mast) but I'm keeping a close eye on Ember and Angular. Also, if you're already doing Backbone, you might check out Marionette.

Mast looks cool! I'm going to check it out.

Yep. 'Leaving things to chance' is a good way to put it. Thanks, I'm aware of Marionette and have also used Backbone.LayoutManager [1] before which solves some of the same issues, though I am wary of the cobbled-together stack I might end-up with if I pick Backbone + Marionette + Some-Better-Router + ... That's certainly why Ember appeals, especially now they're beginning to nail the docs and there are great resources emerging like the recent Peepcode episode [2], which I'm going to have a watch a few more times through.

Very interesting work with Sails, as someone who's written (much more basic) REST scaffolding scripts before I'm especially intrigued by that angle. I'll be digging into it for sure.

[1] https://github.com/tbranyen/backbone.layoutmanager

[2] https://peepcode.com/products/emberjs

Reply on news.ycombinator.com