The logo on the front page makes me feel old ...
jQuery rockstar anyone?
lol for anyone else like me who didn't remember the reference, it was back in '08: http://blog.jquery.com/2008/08/29/death-to-javascript-rock-s...
Sails.js: Realtime MVC framework for Node.js
81–90 of 107 posts
Re: Sails.js: Realtime MVC framework for Node.js
#82I think old RailwayJS now CompoundJS has similar goals to look like Rails, yet bring goodness of NodeJS to the masses. http://compoundjs.com/ I tried it before when it was RailwayJS and it was really good and fast. I didn't do any major projects in it.
I really enjoy using CompoundJS for quick prototypes. Wish there was a larger community though; well, really, I wish any of the MVC nodeJS frameworks had the kind of community that Rails and Django have.
Re: Sails.js: Realtime MVC framework for Node.js
#83Re: Sails.js: Realtime MVC framework for Node.js
#84I think old RailwayJS now CompoundJS has similar goals to look like Rails, yet bring goodness of NodeJS to the masses. http://compoundjs.com/ I tried it before when it was RailwayJS and it was really good and fast. I didn't do any major projects in it.
I really enjoy using CompoundJS for quick prototypes. Wish there was a larger community though; well, really, I wish any of the MVC nodeJS frameworks had the kind of community that Rails and Django have.
I agree. It will probably take someone making successful site and the word will get out. My experience with it was that it was super fast, very responsive, so I imagine it can handle more trafic then rails I am currently using. It is no rails as rails has features that are out of this world, but you often don't need those...
Re: Sails.js: Realtime MVC framework for Node.js
#85Earlier quoted context omitted.
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 (hopefull…
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.
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.
Re: Sails.js: Realtime MVC framework for Node.js
#86The whole point of Node/npm/Express (as a popular module) is its modularity. Node is not just about JS on the server, it reflects a paradigm shift -- a movement away from too much abstraction and magic back to lean and simple systems. And it's unbelievable fast. Sorry to say but such frameworks and ideas are from the last decade (Rails was the main reason why I switched to Node).
The whole point of Node is evented I/O in JavaScript. That's it - it doesn't take a stance on frameworks.
The point of npm is ... to be a package manager.
Express is a framework. I admittedly don't know much about it, but I believe it basically has pluggable middleware, like Rails.
Not sure these things share the "point" you are claiming they do.
It's great Node has both framework choices and a wealth of small modules that do one thing. I think there's room for both.
Re: Sails.js: Realtime MVC framework for Node.js
#87This looks great! The automatic API generation is a killer feature that makes me want to try this out sometime soon. Only thing that seems strange to me is adding the /create, /update, and /destroy GET endpoints -- why not keep it RESTful?
It does look exciting, but I can't trust a framework that promotes saving data on a GET request.
Why not?
Re: Sails.js: Realtime MVC framework for Node.js
#88Earlier quoted context omitted.
I can see the desire to be able to execute non-GET commands via the browser's address bar. Another way Sails could accomplish that would be to accept "?method=PUT|POST|DELETE" to mimic the desired HTTP method.
I don't think that solves the underlying problem of side effect-ful/dangerous GET requests that may be easily exploited via CSRF attacks. You really don't want to expose POST/PUT/DELETE actions via GET.
How common are CSRF attacks? My sites are not protected at all but I don't know if it's worth the hassle to fix. It just doesn't seem like a big deal and very unlikely to happen.
Re: Sails.js: Realtime MVC framework for Node.js
#89This looks great! The automatic API generation is a killer feature that makes me want to try this out sometime soon. Only thing that seems strange to me is adding the /create, /update, and /destroy GET endpoints -- why not keep it RESTful?
I can see the desire to be able to execute non-GET commands via the browser's address bar. Another way Sails could accomplish that would be to accept "?method=PUT|POST|DELETE" to mimic the desired HTTP method.
I'll rephrase something I read this morning on SO about the difference between GET and POST:
"GET request are not supposed to imply any modification on the serveur."
Remember C++ constness?
Re: Sails.js: Realtime MVC framework for Node.js
#90This looks great! The automatic API generation is a killer feature that makes me want to try this out sometime soon. Only thing that seems strange to me is adding the /create, /update, and /destroy GET endpoints -- why not keep it RESTful?
I can see the desire to be able to execute non-GET commands via the browser's address bar. Another way Sails could accomplish that would be to accept "?method=PUT|POST|DELETE" to mimic the desired HTTP method.
> I can see the desire to be able to execute non-GET commands via the browser's address bar.
I can certainly see the desire for that as a browser feature; using GET for actions that are neither safe (no impact other than retrieval) nor idempotent is probably not a good way to workaround the lack of such a browser feature, since per the HTTP/1.1 spec, GET should be safe and is defined as idempotent. (See Secs. 9.1.1 and 9.1.2 of RFC 2616.)