Sails.js – Real-time MVC Framework for Node.js(sailsjs.org)
sailsjs.org
Sails.js – Real-time MVC Framework for Node.js
http://sailsjs.org/
21 comments
Great stuff.
Whilst getting in to Node from Rails (& Meteor) I've found the lack of backend, structured MVC frustrating. Apparently it's not 'Nodey' to make a big framework like Rails, but I'd rather figure that out myself in due course rather than using Express and having no idea what to do after the trivial stuff you see in tutorials…
Whilst getting in to Node from Rails (& Meteor) I've found the lack of backend, structured MVC frustrating. Apparently it's not 'Nodey' to make a big framework like Rails, but I'd rather figure that out myself in due course rather than using Express and having no idea what to do after the trivial stuff you see in tutorials…
Correct me if I'm wrong, but isn't Meteor built on top of Node? Though I suppose it does, as far as I remember, completely hide the Node container. (Or did I misparse your sentence?)
Yup, but it's super abstracted — I run the London Meteor meetup but still have no idea how Fibers work :)
I've now written a couple of production apps with Meteor but it always feels like I'm writing frontend JS with a magical backend (and a couple of server methods) ala Parse, rather than building apps with Node.
I've now written a couple of production apps with Meteor but it always feels like I'm writing frontend JS with a magical backend (and a couple of server methods) ala Parse, rather than building apps with Node.
Not sails-specific, but
sudo npm -g install sails
Why do so many projects require sudo? Why are we writing to any area which would require root write privileges? Why do we not default to just writing stuff in to user home directories and patching off that?
Possibly naive question, but one which is increasingly bugging me.
sudo npm -g install sails
Why do so many projects require sudo? Why are we writing to any area which would require root write privileges? Why do we not default to just writing stuff in to user home directories and patching off that?
Possibly naive question, but one which is increasingly bugging me.
The -g option in NPM means "install globally" (i.e. system wide) instead of in this projects modules directory. You will always need root privs for that, for any module.
Without the -g option sudo is usually not required.
Without the -g option sudo is usually not required.
That depends on how you install your node/npm. For nvm installs the default is ~/.npm which doesn't require root privileges but is user specific.
As a best practice you could use a package.json file [1], IMHO.
[1] https://npmjs.org/doc/json.html
[1] https://npmjs.org/doc/json.html
You can always change the destination directory. I usually store my project dependencies locally, so this command works fine:
npm install sails
This command would store the libs in ./node_modules directory [1].
[1] http://blog.nodejs.org/2011/03/23/npm-1-0-global-vs-local-in...
npm install sails
This command would store the libs in ./node_modules directory [1].
[1] http://blog.nodejs.org/2011/03/23/npm-1-0-global-vs-local-in...
I think on github
https://github.com/isaacs/npm/issues
is the right place to ask this, or tho add a feature request.
"-g" ist for global installations and you want a "-l" for user local installation.
"-g" ist for global installations and you want a "-l" for user local installation.
-l does not mean "local". -l means "--long" and has no relevance to the install command.
Local is the default state. If you want to force non-globalness, you can do `--no-global`
Local is the default state. If you want to force non-globalness, you can do `--no-global`
If you want to install npm for user-specific installations (such as when you don't want to require root access when installing an npm module, or that the computer is shared), you can download the NodeJS tarball, and run
./configure --prefix=/home/user/local
My understanding is that npm defaults to putting its install directory somewhere that requires root access. So you see this with the -g option since that puts it in the root npm directory.
[deleted]
GET requests to create users. What could go wrong?
This is in development mode for quick prototyping. You can turn it off in production and only use POST requests.
Yea, it's no real REST. Better then Metors 'server methods' though.
How did you manage that? o.0 Re-wiring the routes?
I believe he's refering to this
# Create a new user
http://localhost:1337/user/create?name=Fisslewick
(or send an HTTP POST to http://localhost:1337/user)
The back button is broken and it doesn't appear to support HTML5 history by default in browsers that support it. (uses hash for tracking pathing)
That's really more of a concern for your front-end framework than your back-end framework, though.
It doesn't have associations between models yet but it does have amazing branding.
I just recently split out the ORM, Waterline into a new project. The first step was to get API compatibility with the current ORM and a bit of sugar like lifecycle callbacks and custom instance methods.
Associations are next on the list of to-dos. It's still a very new ORM but I'm working on making it better. Check it out I'd love feedback or better yet pull requests.
https://github.com/balderdashy/waterline
Associations are next on the list of to-dos. It's still a very new ORM but I'm working on making it better. Check it out I'd love feedback or better yet pull requests.
https://github.com/balderdashy/waterline
I don't think you're forced to use their model layer.
Technically you're not forced to use Sails.js at all. I'm not sure that's the point though.
Totally off-topic and maybe even trollish, but I noticed the cute little illustration here:
http://sailsjs.org/#getStarted
Interesting that the female is skinny, with a trendy little mid-riff baring shirt, and attractive (so far as a stylized comic character can be). One of the male characters is a pudgy dude with glasses. It seems the norm in characterizing girls in tech is "you can be a developer, but stay sexy - you don't have to be a nerd!" Does this risk marginalizing normal women?
Interesting that the female is skinny, with a trendy little mid-riff baring shirt, and attractive (so far as a stylized comic character can be). One of the male characters is a pudgy dude with glasses. It seems the norm in characterizing girls in tech is "you can be a developer, but stay sexy - you don't have to be a nerd!" Does this risk marginalizing normal women?
Hm under closer inspection, they don't have any Asian developer on the boat either! Does this mean Asian developers can't use Sails? And why is the Indian man is the one rowing the boat - without the ability to see might I add? Clearly this is racially insensitive. /s
For one thing, that's not really analogous. The analogous situation would be e.g. if they had a drawing of an Asian who was furiously working on solving an equation.
For another thing, I believe you will find that Indians are, in fact, Asians.
For another thing, I believe you will find that Indians are, in fact, Asians.
The analogy was that the brown person is happily pulling the workload while the Caucasians sit around and do nothing - an appropriate stereotype regardless of whether he is Indian or Hispanic. Amazing how a forum once about tech is now more concerned with pedantic politically correctness.
I wasn't taking issue with the rowing part of the analogy, since that works fine for your purpose of ridiculing "political correctness". I don't agree with you, but that was a fine jab. But the "there isn't an Asian" jab doesn't work because it's not equivalent to a problematic portrayal.
For the record, I don't think that the illustration they used is a huge deal. But it is not a coincidence that the female drawing is the only one that's sexualized, and it's not like it's an isolated case.
For the record, I don't think that the illustration they used is a huge deal. But it is not a coincidence that the female drawing is the only one that's sexualized, and it's not like it's an isolated case.
How do you know the man is Indian? The clothing style is more suggestive of him being Hispanic or African-American.
One of the two designers who worked on it is a woman-- feel free to ask her:
https://twitter.com/KallunaLovegood
https://twitter.com/KallunaLovegood
Whether or not a woman did the design isn't the point. This particular design wasn't even the point. I was questioning what seems to be a trend.
The person you're responding to didn't say that a woman designer was the point.
They said you can feel free to ask her your question.
I wish you would too, because I can't stand coming into a thread about some cool new technology and having it turn into a melodramatic women's study.
They said you can feel free to ask her your question.
I wish you would too, because I can't stand coming into a thread about some cool new technology and having it turn into a melodramatic women's study.
If women weren't brainwashed to (generally) serve men, strive to be skinny, pretty and dutiful, they'd soon realise women don't need the male half of the species to survive.
SO, let's leave the stereotypes be, or risk the evolutionary extinction of males...
SO, let's leave the stereotypes be, or risk the evolutionary extinction of males...
egg, meet face
Hmm seems to be broken currently on OSX. (Not sure if sails or node is the problem) Following the steps on getting started guide.
Also from a UX standpoint I would point the user to another page where they can continue learning about the framework after the download is finished.
Right now it states "Now, let's get Sails to do cool stuff." and leaves the user hanging with nowhere to navigate to.
brew install node
sudo npm -g install sails
sails new testProject
Also from a UX standpoint I would point the user to another page where they can continue learning about the framework after the download is finished.
Right now it states "Now, let's get Sails to do cool stuff." and leaves the user hanging with nowhere to navigate to.
I know nothing about the framework (and I don't see any examples or anything that tells me why it's any good), but that is a beautiful landing page.
It does look amazing, and maybe its just my PC but on Windows 7, the bullet text below is almost impossible to read. Could also be my display. It looks fine on my Nexus 4, and is ok on Ubuntu.
Maybe my font aliasing is just messed up. Thin fonts have never really looked great on windows for me.
Maybe my font aliasing is just messed up. Thin fonts have never really looked great on windows for me.
Have you got Cleartype disabled?
Especially with Javascript off ... it's white ,empty and beautifull , I learned nothing about what the framework was about.
Then turn it on. Why are you browsing the web with JS off in 2013? Do you want web developers to make _two_ sites, one for the 99% using JS and another for the Stallman's out there using lynx for browsing? /rant
No, he wants it to work without JS, like any site should. Developers should build one site, and use JS for progressive enhancement.
Why should any site work without JS? Especially the site for a front-end JS framework. Are you similarly angry when a photo gallery doesn't work without images turned on? Or when a video site doesn't work when you disallow video from playing?
Those images better have alternative descriptions, and that video better have a transcript.
So you would rather a video weren't posted at all than that it be posted without a transcript?
Yes, honestly, because lots of times I just don't have headphones and don't want to disturb folks around me. But other times I can read faster than I can watch the video.
If you made the video with care, then you probably already have a script you used.
If you didn't, https://castingwords.com/ is really, really cheap and does a good job.
If you made the video with care, then you probably already have a script you used.
If you didn't, https://castingwords.com/ is really, really cheap and does a good job.
A blind person might.
A government agency would rather not post a video to it's own site without a transcript (Section 508).
Many people would. For me it depends on the video. I often would rather read the transcript than watch. So yeah, it'd be better for me that the video wasn't even posted so I wouldn't have to waste my time searching for a transcript that didn't exist.
A government agency would rather not post a video to it's own site without a transcript (Section 508).
Many people would. For me it depends on the video. I often would rather read the transcript than watch. So yeah, it'd be better for me that the video wasn't even posted so I wouldn't have to waste my time searching for a transcript that didn't exist.
While this used to be the common wisdom, it's not clear to me that it should still be. Designing a site which smoothly gains features as your browser does seems ideal, but often takes half again as long. Doing that for the tiny percentage of people who browse with JS off seems perverse when most of the modern web is broken or invisible to them anyway.
It really doesn't take that long.
Sure, a modern web application, or a site with lots of interactivity, is never going to work without JS. But this is some static content on a page; it would not be hard to make this work without it.
Although the time would probably be better spent optimising the page somewhat. 3MB of assets and 85 HTTP requests (including 24 individual stylesheets!) makes for an unpleasant experience.
Sure, a modern web application, or a site with lots of interactivity, is never going to work without JS. But this is some static content on a page; it would not be hard to make this work without it.
Although the time would probably be better spent optimising the page somewhat. 3MB of assets and 85 HTTP requests (including 24 individual stylesheets!) makes for an unpleasant experience.
The most common reason discussed was screen readers, which can now parse JS powered sites just fine.
"just fine" is not even close to true.
Developers have to code it right or it doesn't work right.
JavaScript-based sites are as accessible as Flash-based sites - the developer has to know how to make it accessible, or it isn't.
Developers have to code it right or it doesn't work right.
JavaScript-based sites are as accessible as Flash-based sites - the developer has to know how to make it accessible, or it isn't.
> JavaScript-based sites are as accessible as Flash-based sites - the developer has to know how to make it accessible, or it isn't.
How is that the case? The text is on the screen like any other website would be. It's not an image or in a binary format like it would be with Flash.
How is that the case? The text is on the screen like any other website would be. It's not an image or in a binary format like it would be with Flash.
Screen readers can read text in Flash movies if it's bade available as text.
and with JavaScript, if it's injected after page load, rather than during, the screen reader may not get notified that the page has changed, so it doesn't know to read it.
This is what WAI-ARIA and other things are about.
Thankfully JAWS and WindowEyes have free trials, and NVDA is free, so we can actually test things instead of talking about them on HN.
and with JavaScript, if it's injected after page load, rather than during, the screen reader may not get notified that the page has changed, so it doesn't know to read it.
This is what WAI-ARIA and other things are about.
Thankfully JAWS and WindowEyes have free trials, and NVDA is free, so we can actually test things instead of talking about them on HN.
Welcome to 2013, where people want to hold us back with their 90's browsing habits.
JS blocking does not mean "BAN ALL JAVASCRIPT GRRRR" it means "I will decide which sites can run code on my computer".
So if you have a web app - a page that needs to run code to provide its value - you have to let it do that.
But if you have a document that is strictly informative then REQUIRING that you run some code just to read some text is simply counter-intuitive. A document shouldn't need to run code to provide its value, NOR SHOULD IT DO SO TO LOOK NICE.
So if you have a web app - a page that needs to run code to provide its value - you have to let it do that.
But if you have a document that is strictly informative then REQUIRING that you run some code just to read some text is simply counter-intuitive. A document shouldn't need to run code to provide its value, NOR SHOULD IT DO SO TO LOOK NICE.
This is a strange definition of "should". If 2% of your users are browsing with JS turned off, "should" you really spend valuable time maintaining the no-JS path at the expense of working on how the site works for the other 98%?
You should never have to develop two paths. Web development boils down to forms that post and links that get. It's not difficult to make all that work and then apply JS on top to intercept things.
But it's getting harder to do that as we embrace frameworks we don't understand that do it all for us.
But it's getting harder to do that as we embrace frameworks we don't understand that do it all for us.
When you put JS on top of it to intercept, you are creating two paths. That may be easier than a totally separate code base, or maybe not (I have seen compelling arguments either way), but it still boils down to a different code path in terms of potential for different bugs, different cross-browser issues, and more testing.
In addition, developing that way (instead of with JS in mind) also has a cost which in the end means that you are sacrificing resources developing for those 2% instead of the other 98%. Regardless of whether that approach leads to an easier situation in terms of maintaining JS vs. non-JS, it certainly does not lead to an easier situation than ignoring non-JS altogether.
In addition, developing that way (instead of with JS in mind) also has a cost which in the end means that you are sacrificing resources developing for those 2% instead of the other 98%. Regardless of whether that approach leads to an easier situation in terms of maintaining JS vs. non-JS, it certainly does not lead to an easier situation than ignoring non-JS altogether.
Not for the kind of applications that this framework is designed to build, so that statement is bound to attract a lot of crows.
there is a reason why the option to turn JS off has been removed from Firefox 23. Javascript is a big part of todays web. Better spend your time working on your JS powered App rather than to make it work for 1% who have turned it off.
thanks awavering ,it's hard to be surrounded by Javascript fanatics when the point is just to be able to read a doc about a framework. A txt file should be sufficient but no, today developers want to get fancy and throw at you every stunt they can pull ...
You can always read the README on GitHub. no markup there.
https://raw.github.com/balderdashy/sails/master/README.md
https://raw.github.com/balderdashy/sails/master/README.md
This looks like an awesome project and the overall design is absolutely great, kudos. One thing that amuses me though is how part of bootstrapping the Node user base was built upon a lot of Rails-bashing, only to find out a few years later that most of the frameworks are basically trying to recreate some form of Rails in Javascript.
All the best to the authors nonetheless.
All the best to the authors nonetheless.
It looks pretty well thought-out, which is a big +1 when I'm framework shopping. However: use pushState/replaceState! Or at least fix your buggy back button. Your hash-based navigation totally breaks the back button to a point where I can't believe you shipped this.
Thanks for the bug report! In particular, what back button issues were you having? I can't replicate any issues just now, but feel free to submit a PR if you see a fix.
Shipping a customer site is way different than "shipping" the website for an open-source framework. Unfortunately, we don't get paid to work on Sails, and we're completely bootstrapped, so we only get to work on stuff like the public-facing website when we get spare time.
Shipping a customer site is way different than "shipping" the website for an open-source framework. Unfortunately, we don't get paid to work on Sails, and we're completely bootstrapped, so we only get to work on stuff like the public-facing website when we get spare time.
Also: don't forget to use manifest files to concatenate your compiled CSS :)
Or you could just use LESS and @import your styles. LESS @import for other LESS files works much like C's #include, rather than simply converting to a CSS @import line.
He's using rails, so he can use SASS (which personally I like better than LESS, but they accomplish the same things). Manifest files are better though, because with LESS's @import, you might import more files than you actually want. I believe you also have the recursive import issue, just like C. Manifest files give you more granularity by existing outside of the actual stylesheet.
Hey if anyone's curious about what this is, here's my video:
https://www.youtube.com/watch?v=GK-tFvpIR7c&feature=youtu.be
This Sails.js tutorial is really good: http://net.tutsplus.com/tutorials/javascript-ajax/working-wi...
This word real-time. I do not think it means what you think it means.
But.. Socket.io is built in sooo realtime ... Right?
Yes, it is. We are mostly professionals here and understand the limitations of technology, specifically when talking about latency and implementations ranging from websockets to long polling. We look past these minutiae and get to the real subject of getting data to the user as soon as possible. Generically, this is referred to as "real time".
I actually wish we called this something else like say "persistent". Real-time systems have a very specific meaning for many people and while yes we all get it, it is probably a point of distraction for a lot of people to hear this term constantly misused.
How does sails handle assets, do you have something similar to sprockets that can be added to this?
[deleted]
In the upcoming v0.9.0 release we are using Grunt for assets.
Off topic, but the choice of port for a Sails app is quite interesting, "1337" [1].
[1] http://sailsjs.org/#getStarted
[1] http://sailsjs.org/#getStarted
Hi! I've tried a couple of days ago and after running the getting started, noticed that none of the tutorials in the right column were available. Did this changed ?
I'm not too versed in Node frameworks : is Sails a direct competitor to Meteor ? If so how is it different ?
Meteor is a full stack (backend and frontend) framework that focuses on live data binding from database up to the dynamic frontend layer. Also it is not a traditional Node stack (does not use NPM).
Sails is more like RoR, it is like a traditional backend framework except that it's API-centric and has websockets built in. Sails is frontend-agnostic, and lets you use any dynamic framework you want (Backbone, Angular, Knockout, etc).
Sails is more like RoR, it is like a traditional backend framework except that it's API-centric and has websockets built in. Sails is frontend-agnostic, and lets you use any dynamic framework you want (Backbone, Angular, Knockout, etc).
Probably could be considered a competitor. This offers socket.io built-in, but doesn't seem to have the reactive data binding templates like meteor. This looks to be a Ruby on Rails for node.
I did not see the difference, only that Sails has a smaller scope.
With Meteor you can change all frontend-data of connected clients "in realtime", but Sails did not have this key feature.
So iam not sure why i should use Sails, when i can have more with meteor?
Because Meteor front-end bindings suck terribly. With sails you can use any of the tried and true front end frameworks like angularjs or emberjs etc instead of meteor's crap.
Disclaimer I haven't used Sails so this is not an endorsement for sails, just a reflection of my experience with meteor.
Disclaimer I haven't used Sails so this is not an endorsement for sails, just a reflection of my experience with meteor.
Warning, this is a rant.
I've started a Meteor.js Project 3 Weeks ago and I'm regretting it. It's an architectural nightmare. It uses global variables for everything. One would think the news, that this is a bad idea, would have spread since the 70's. Unit tests are not possible in this style. You can do integration tests with the Laika Framwork though.
The next problem is a severe case of "note invented here" syndrome. Packaging, data access, Templating - Meteor.js has it's own. For example, they have their own version of Handlebars which I did not realize until yesterday. It has some documented and some undocumented differences to the original one. I had lots of fun with some custom Handlebar helpers that I wrote. I tested them against the original Handlebars and they passed all my unit tests. In the project however they did not work at all.
As KaoruAoiShiho said the bindings suck terribly. Well, they don't exist really, you just use jQuery. (Thank god, they don't roll their own version of that.)
The elephant in the room is data access. If you're a MongoDB fan like I am they will lure you in with the fact that you can use MongoDB directly form the client. Don't fall for that, it's a terrible idea. It's such a terrible idea, that they introduced 'server methods' to kind of fix all the problems with it. Server methods are not REST. Server methods are RPC style web APIs. Welcome to 10 years ago. They dislike REST because it's stateless. (at least that's what i've taken form this talk: http://www.youtube.com/watch?v=NnMqMAYmTuo) As you might have realized by now these guys just LOVE state. State and global variables.
If you're a Haskell programmer and you are not jet curled together into a ball and crying, id's suggest to quickly read a monad tutorial before continuing.
Dependency management is also a big problem. You can't just use nodes good old `require` and `module`. The order in which files are loaded is determined by their name and position in the directory structure. I shit you not.
They have also their own build tool. (who would have thought...) It watches your files and compiles them. Which works great most of the time. You can't have includes in your SASS/LESS/Stylus files tough. I guess the notion of having a proper module system scares it a little. I found this thing to be the best aspect of my whole Meteor experience. Not as good as Grunt though.
Per default, there is no routing. There is an unofficial routing package which works good, but is by far not as feature rich as the Express one. It also introduces some more global variables in true Meteor.js spirit.
In my opinion Meteor is good for prototyping. You can get a small app up in no time. Just don't build anything real with it.
I've started a Meteor.js Project 3 Weeks ago and I'm regretting it. It's an architectural nightmare. It uses global variables for everything. One would think the news, that this is a bad idea, would have spread since the 70's. Unit tests are not possible in this style. You can do integration tests with the Laika Framwork though.
The next problem is a severe case of "note invented here" syndrome. Packaging, data access, Templating - Meteor.js has it's own. For example, they have their own version of Handlebars which I did not realize until yesterday. It has some documented and some undocumented differences to the original one. I had lots of fun with some custom Handlebar helpers that I wrote. I tested them against the original Handlebars and they passed all my unit tests. In the project however they did not work at all.
As KaoruAoiShiho said the bindings suck terribly. Well, they don't exist really, you just use jQuery. (Thank god, they don't roll their own version of that.)
The elephant in the room is data access. If you're a MongoDB fan like I am they will lure you in with the fact that you can use MongoDB directly form the client. Don't fall for that, it's a terrible idea. It's such a terrible idea, that they introduced 'server methods' to kind of fix all the problems with it. Server methods are not REST. Server methods are RPC style web APIs. Welcome to 10 years ago. They dislike REST because it's stateless. (at least that's what i've taken form this talk: http://www.youtube.com/watch?v=NnMqMAYmTuo) As you might have realized by now these guys just LOVE state. State and global variables.
If you're a Haskell programmer and you are not jet curled together into a ball and crying, id's suggest to quickly read a monad tutorial before continuing.
Dependency management is also a big problem. You can't just use nodes good old `require` and `module`. The order in which files are loaded is determined by their name and position in the directory structure. I shit you not.
They have also their own build tool. (who would have thought...) It watches your files and compiles them. Which works great most of the time. You can't have includes in your SASS/LESS/Stylus files tough. I guess the notion of having a proper module system scares it a little. I found this thing to be the best aspect of my whole Meteor experience. Not as good as Grunt though.
Per default, there is no routing. There is an unofficial routing package which works good, but is by far not as feature rich as the Express one. It also introduces some more global variables in true Meteor.js spirit.
In my opinion Meteor is good for prototyping. You can get a small app up in no time. Just don't build anything real with it.
Thx for that huge info! I only read about meteor and their informations on the webpage, i want to use it in some weeks for a smaller project, but now i will look closer at meteor before i use it.
I keep reading it as "snails". It looks like fun, though. I look forward to playing with it.
I don't think "real time" means what you think it means.
So how is it different from Express.js?
Express isn't really much of a client side MVC framework. It is still a very clean and simple framework.
If you want to drink the cool aid of single page apps, 'rich' client side etc, you have to invest into some MVVC/MVC frameworks like Angular, Ember or now Sails, which works well with Node.js apparently.
If you want to drink the cool aid of single page apps, 'rich' client side etc, you have to invest into some MVVC/MVC frameworks like Angular, Ember or now Sails, which works well with Node.js apparently.
Express is not a client-side MVC framework at all-- in fact it's completely shrugged off view engines to other modules since 3.x (which is supported in Sails 0.9-- I'm releasing that very soon)
expressjs is a more minimalist framework, taking a lot more inspiration from sinatra than rails. This wants to be rails for javascript.
edit: Actually, just checked the package.json, and express is listed as a dependency, (probably for the controller middleware?) so in essence you're using both.
edit: Actually, just checked the package.json, and express is listed as a dependency, (probably for the controller middleware?) so in essence you're using both.
Sails is based on top of Express. Like if Rails had Sinatra at the core
A better analogy is the way Padrino has Sinatra at the core.
It's sugar on top of Express. This ties in a bunch of other things you need, authentication, authorization, building APIs and generators in a more cohesive way. Still hard to be plain old Express.
I can't wait to see how Sails evolves, they are some damn good dev's.