4 ms·
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 explain
by sideproject 14y ago
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?
- andypants 14y agoYes, 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.
- mikermcneil 14y agoHey 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.
- nilliams 14y agoThe 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)!
- mikermcneil 14y agoAbsolutely 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 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.
- 33degrees 14y agoMast looks cool! I'm going to check it out.
- nilliams 14y agoYep. '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 https://github.com/tbranyen/backbone.layoutmanager [2] https://peepcode.com/products/emberjs https://peepcode.com/products/emberjs
- NikolaTesla 14y ago@sideproject Actually you can use Sails (https://github.com/balderdashy/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.