Sails.js vsmeteor – 两者的优点是什么？
我一直在阅读Nodejs及其框架，并最近完成了我的第一个完整的JavaScript前端（使用Angularjs）。
我已经决定，我的下一个宠物项目将是一个Nodejs冒险使用这两个框架之一：
- Sails.js
- meteor
我已经阅读了这两篇文章，但是仍然不能很好地理解它们之间的差异，为什么我应该select一个。 所以请戴上你最好的推销员帽子，挑选一个框架，然后卖给我。
我的宠物项目需要的一些function是：
- 现场比分
- 类似Reddit的线程，实时
- 维基百科的页面版
- 用户/angular色
我不能说Meteor，但是我可以帮助提供一些关于Sails的背景，因为我创build了它。
tldr; 风帆并不是所有networking问题的灵丹妙药 – 但我相信Node.js是。 Sails的目标是为开发基于node.js的完整，可扩展，启动和企业友好的应用程序提供一个实用的框架。 我开始使用Balderdash的问题“我们可以使用Node.js做什么？”。 帆是答案。
从我们的新文档 ：
Sails当然是一个Web框架。 但退后一步。 那是什么意思？ 有时候，当我们提到“networking”时，我们的意思是“前端networking”。 我们想到像Web标准或HTML 5或CSS 3的概念; 和Backbone，Angular或jQuery等框架。 帆不是一个Web框架的“那种”。 Sails与Angular和Backbone非常相称，但是你永远不会使用Sails而不是那些库。
另一方面，有时当我们谈论“networking框架”时，我们的意思是“后端networking”。 这唤起了像REST，HTTP或WebSockets这样的概念; 并build立在诸如Java，Ruby或Node.js之类的技术之上。 “后端networking”框架可以帮助您完成构buildAPI，与数据库交互，提供HTML文件以及处理成千上万个并发用户等事情。 Sails是Web框架的“那种”。
几年前，我承诺将Node.js用于一切， 这是一见钟情 。 我在Express和Socket.io的基础上构build了Sails，因为它们是各自用例中最完善的Node模块。 Sails中的请求处理代码与Express兼容，另外还有对Socket.io的隐式支持。
Sails旨在兼容您在Angular，Backbone，iOS / ObjC，Android / Java中构build前端的任何策略，甚至只是提供一个原始API供其他Web服务使用，或者您开发者社区。 如果你最终改变了你的方法（例如从Backbone转换到Angular）或者完全build立一个新的前端（例如构build一个Windows Phone原生应用程序），你的Sails应用程序仍然可以工作。 正如你可能已经知道的，有些人把这种方法称为面向服务的体系结构（SOA）（ Joe McCann在这个主题上有很好的一套）。
同样，Sails还为构buildWeb服务器维护了其他熟悉的约定 – 标准的MVC结构，创build干净的API的能力以及可打开，可configuration，可扩展甚至可交换的核心模块。 这意味着Sails可以根据用户的需求进行定制，因为它是必要的低级别。
在2013年，这个框架受到了很大的普及，我们的咨询业务也在增长。 其余的核心维护者和我扩大了我们的重点，尽可能快速和直接地使后端开发。 由于我们的核心团队和（不断扩大的）Sails社区的努力，去年的Sails（插件），testing和文档等Sails的相关方面都走了很长一段路。 我们还在研究大量的路线图项目，但是我相信Sails是目前在Node上进行稳定，可维护的MVC开发的最佳select。 我和其余的团队都致力于持续的维护和function开发，而且由于我们将其用于所有客户项目，因此不在任何地方。
我正在致力于使Sails成为最好的Web框架，但从不牺牲Node.js。 核心团队和我一直致力于增强Node生态系统，这就意味着采用NPM，利用现有的Node技术和最佳实践等等。不仅因为它更合理，而且因为我们是Node.js开发人员。 我们所有努力的动机是使节点更易于访问，而不是取而代之。 所以，如果在某个奇怪的平行宇宙中，我被赋予了将Sails转换成其他语言，或者完全抛弃Sails但仍然可以使用Node的Faustianselect，我会select后者。
其他资源：
常见问题 | 帆101 | 原始的screencast | 贡献指南 | 堆栈溢出
Google群组 | | 路线图 | IRC：Freenode上的#sailsjs 构build状态
我已经与meteorbuild立了几个项目，还没有与Sails合作过。 所以我的意见肯定是有偏见的，希望它有帮助。
构build前端
meteor提供了自己的名为Blaze的前端框架 – 将被包含在即将到来的0.8版本中。 meteor照顾从您的集合绑定数据到您的意见。 正因为如此，你不必担心告诉你的观点更新，他们只是这样做。
另一方面，Sails只提供一个后端框架，你将不得不自带前端框架。
与大多数Node.js框架不同，Meteor是同步的
meteor运行循环，如果你想使用Node.js包，你将不得不做一些额外的工作 ，以确保他们在meteor正常运行。
Sails似乎是一个简单的MVC Node.js框架，所以当你仔细观察的时候不应该有太多的惊讶。
你应该用meteor使用MongoDB
是的，你可以使用其他数据库与meteor，但他们没有任何地方接近MongoDB相同的支持。 而对于Sails，看起来他们有几个数据库的ORM。
性能
对于大规模的应用，Meteor 可能performance不佳 。 为解决这个问题已经做了很多工作，到2014年底，我们可以期待Meteor的解决scheme。
稳定性
meteor还是很新鲜的，还没打到1.0。 您应该期望在接下来的几个版本中做出一些改变，这将会打破向后兼容性。 如果你正在开始使用它，那么你可能要考虑使用0.8-rc0分支。 这就是说，一些在pipe道中的function是非常好的，将使1.0版本非常诱人。
最后的想法？
我喜欢meteor，因为它的特质。 你将不得不学习meteor的做法，但一旦你开始这样做，你觉得你已经喝醉了的助手。 由于数据绑定到视图的方式，服务器和客户端之间的线路并不遥远。 meteor代表了应用程序架构的范式转变，如果你还没有尝试过，我会推荐它。
PS 检查路线图以了解即将发生的事情。
我只能对风帆发表意见。 我是一位非常有经验的Javascript开发人员，自90年代以来一直在构build基于JavaScript的embedded式机顶盒应用程序。
事情起了很好的作用 – 入门非常好，我感到非常的支持 – 学习曲线非常短，有一个健康的社区背后的风帆 – 初步的学习后，很容易创意快速
可以改进的地方 – 复杂的数据结构很难实现 – Passport.js集成是痛苦的，因为没有干净的参考资料
build议 – 庞氏编码器有一个很好的教程，它真的帮助我去https://www.youtube.com/user/ponzicoder – 知道更多关于快递和吃水线将有助于当你尝试更复杂的数据挑战
总的来说，我会推荐帆船。
我目前使用meteor，并没有使用Sails.js。
meteor一直非常愉快的工作，我认为这将是一个很好的select实时networking应用程序。 关于用户/angular色，您可以查看集成的帐户包，也可以在Atmosphere中search社区贡献的angular色/权限包。
最终，我会build议用这两种技术尝试一个小项目，看看你更喜欢哪一个。
