I have had the chance to play with Sails and I really like it. Just a warning, this is a great tool for simple web apps. I wouldn't take the Sails path if you are going to do something a little more tailored, (like Nodejs + PostgreSQL w/ Sequelize + Redis for sessions + memcached + MongoDB for analytics + passport w/ Oauth2 + etc.. ), I would leave that to express + express-routes. I would definitely chose Sails for demo'ing a product idea or personal projects I want to get up and over with as quickly as possible, and Sails is REALLY quick.
I can't wait to see how Sails evolves, they are some damn good dev's.
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.
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.
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
Which should install into your ~/local directory after running 'make && make install'.
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.
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.
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?
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.
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.
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...
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.
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
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?
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.
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.
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.
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.
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.
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.
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.
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 ...
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.
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.
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.
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.
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 ?
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).
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.
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.
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.
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)
You are right. Having not gone through what Sails was, I have mis-represented it a bit. Its more RoR than Sinatra (Express) as others have expressed here.
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.
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.