nodejs的精简型和全栈型开发框架介绍

总体来说你可以将Node.js开发框架归结为两类：
- 精简型框架
- 全栈型框架

下面我们就对这两种框架进行探讨。

精简型框架

精简型框架提供的是最基本的功能和APIs，这类框架本身就是被设计成用来改善Node.js开发过程中的主要方面的。但是，这些框架主要关注的方向都是提供基本的MVC开发框架功能和改善编码体验，而不是Node.js本身没有的其他功能和技术的支持。下面是一些当今流行的精简型的Node.js框架。

Express.js- 最流行的框架

Express.js毫无疑问是当今最受网络应用开发人员喜爱的Node.js开发框架了。作为一个有弹性的，轻量级的，容易使用框架，Express.js完全可以用来开发纯JS或混合型的便于扩展的移动应用。如果网上一些数据不是空穴来风的话，当今世上已经有26000个网络和移动应用是使用该框架进行开发的。其中一些有名的使用者粉丝包括 MySpace, Countly, Yummly, Mozilla Persona， 以及Geekli.st。所以，如果你是一个Node开发新手的话，也许Express.js就是你应该乘坐的快速列车。

KOA - Node.js下一代开发框架

作为一个由Express.js框架幕后开发团队进行开发和维护的另外一个Node.js开发框架，KOA是一个被热捧并冠名为Node.js的下一代开发框架的网络开发框架。因为该框架是由Express.js进化而成，所以你可以看到他们的很多相似之处，当然，区别肯定是有的了。它提供了一些额外的新功能，而该框架的中间件会把这些新功能和其他已有功能给隔离开来。另外，该框架还提供了高效开发和便于使用等功能特性来简化启动服务器和服务器相关功能的流程。

Total.js - 一个摩登的网络应用开发Node.js框架

尽管Total.js可以被认为是一个极简型的框架，但是它依然是可以作为Node.js框架的一个补充。该框架的目标用户是那些想要打造具有非常强大的可扩展性的应用的开发者。如果你现在想要打造的是一个网络应用，而该应用也许今后会进行大量的扩展的话，Total.js也许是一个完美的选择。

Sails.js

作为一个像Ruby On Rails一样的提供MVC开发模式模拟功能的框架，Sails.js其实是一个鲁棒的可扩展的Node.js开发框架。它自身是一个服务驱动(service-driven)的架构，而它的API集又是以数据驱动的方式进行提供的。它最大的用处应该就是用来打造多用户游戏，网络聊天，实时交互应用，以及企业泣别的Node.js应用。

全栈型Node.js开发框架

全栈型开发框架才是NodeJS所以发光发热的地方。大部分全栈型框架都包含了必须的应用开发基础库，完整的模版引擎，网络sockets，以及持久化的库来加速对实时可扩展的网络和移动应用进行构建。以下是当今最盛行的全栈型Node.js框架：

Meteor - 极其简单的应用开发环境

作为一个设计成集成了所有MEAN开发框架功能的框架，Meteor是一个JavaScrtip框架的集大成者，JavaScritp既可以运行在客户端浏览器中，同时也可以在服务器端的一个Node.js容器的Meteeor服务器中运行。另外，它还支持HTML代码，CSS，以及其他有用的静态工具。
所有这些功能在Meteor框架中都是非常有弹性的组织起来的，你可以很方便的用如文件目录树请求的方式进行使用。客户端和服务端各个组件的打包和数据传送都是由Meteor框架自动完成的。

Mean.IO- 完整的MEAN栈JavaScript开发框架

MEAN.IO是一个完全的JavaScript开发框架，它是专门设计成来简化以及加速开发基于MEAN栈的网络应用的。该框架自带了可以让你把MEAN框架的四个技术进行无缝接合的工具，比如，MongoDB, Express.js, AngularJS, 以及Node.js，甚至其他开创性的如Bootstrap等技术。同时它还拥有了很多HTML和CSS以及其他额外的JavaScript代码来大大的降低你的编码时间。但是，该框架最亮眼的其实是它强悍的MVC架构。你可以使用它来创建好模块化的代码，然后用其作为工具来打造出精致的网络或移动应用。MEAN.IO包是即插即用的，所以一旦有新功能包发布，你就可以像使用npm包一样来获得并使用它们。
MeanIO包系统把所有包都集成到mean项目里面，就好像这些代码本身就是mean自身的一部分一样。同时它也给开发者提供了所有必须的工具来把我们的包集成到我们的项目中。

Node.js非常适用于Web开发，但是现在无论是一个网站，还是Web App都已经成为包括很多不同部分，如前端、数据库、业务模块、功能模块等等的大型项目，使用Node.js从零开始进行Web开发，也许大中型团队能够 胜任，但对于个人和小型团队来说是不现实的。这时候框架就成为Web开发利器，对于个人开发来说几乎是必不可少。那么如何选择Node.js Web开发框架呢？
首先，我们必须要弄清楚的是，我们需要的是——
程序 or 框架？
程序是已经成型的应用，你需要的是为它搭建环境、添加配置，然后就可以运行起来；框架则是应用的骨架，你需要为它添加数据模型、业务逻辑，它才能成为应用，开始提供服务。
事实上，对于Web开发来说，程序和框架的区别正越来越模糊，比如几乎妇孺皆知的Wordpress，它是一个博客程序，但它丰富的插件以及高度的 自定义能够支持很大程度上的二次开发，在这点上它比起一些PHP框架也并不逊色。我个人认为，如果重心在于提供服务而不是掌握技术，有WordPress 这样的程序是没有必要使用框架的。
可惜的是，由于Nodejs还很年轻，目前还没有WordPress这样的程序，因此目前在Node.js开发里，如果想做出自己想要的作品，框架是必然的选择。如果是某些特定类型的应用，可以尝试一些开源的程序，比如要用Nodejs做博客，有Hexo、Ghost等。
Node.js Web框架有哪些？
Node.js里的Web框架分为API框架和Web应用框架。前者能够开发出RESTful的API，后者也能开发出RESTful API，但还包括模板、渲染等为前端所准备的功能。
API框架的使用场景是为跨平台应用提供统一的数据模型，而渲染由前端/客户端自行解决。目前比较知名的API框架有
restify（文档、Github、NPM）
ActionHero.js（官网、Github、NPM）
LoopBack（官网、Github、NPM）
Frisby（官网、Github、NPM）
Fortune.js（官网、Github、NPM）
Web应用框架顾名思义，就是为了打造Web应用所开发的框架。这里有两种风格的Web应用框架。
一个是Sinatra风格，另一个是Rails风格。Sinatra和Rails都是Ruby语言的Web框架，后者的影响力更大也更为知名。这里简单的解释一下两种风格是什么意思。
Sinatra风格是指高度可配置，注重开发的自由度。代表性的Nodejs Web框架有：
Express（官网、Github、NPM）TJ大神开发，Node.js官方推荐
 hapi（官网、Github、NPM）
koa.js（官网、Github、NPM）
flaliron（官网、Github、NPM）
total.js（官网、Github、NPM）
locomotive（官网、Github、NPM）
Rails风格则是指不重复自己和约定优于配置，以及严格遵循MVC结构开发。代表性的框架有：
Sails.js（官网、Github、NPM）
geddy（官网、Github、NPM）
CompoundJS（官网、Github、NPM） 原railswayjs
这两种风格无所谓谁优谁劣，全凭使用者的偏好。
而在这两种Web框架之外，还有更大型的框架，即全栈框架，其中的代表是MEAN。
MEAN？
MEAN指MongoDB+Express+Angular.js+Node.js，这一组合包括运行环境、数据库、Web框架和前端引擎。被称为 全栈框架（Full-stack framework）。这其中除了Node.js之外，每一个都是可替换的，目标是创建从前端到后端，全部使用javascript的Web应用。
由于这一框架的完善性，有人将其称为LAMP的接班人。LAMP即PHP的典型运行环境，Linux+Apache+MySql+PHP，被大量的用于各种虚拟主机上。
MEAN看似庞大，但事实上要构建完整的现代化Web应用，特别是SPA（单页面应用），这几个组件都是难以缺少的，并且，其中每一项几乎都是目前 情况下的最佳选择，因此用于学习和重头开始打造新的Web应用是非常合适的。但由于实际业务的独特性，很可能要替换其中的组件，比如用Mysql来替换 MongoDB，因此，学习其中的原理和架构，打造自己的类MEAN框架也是一种选择。
作为个人和小团队来说，全栈框架MEAN基本上足够了，但目前大多数全栈框架还包含一项特性，那就是实时，拥有实时功能的框架我们又称为实时框架。
实时框架好吗？
实时框架（Real-time framework）指包含了webSocket的双向通信功能，能够在服务器和客户端做到实时通信的框架。
服务端和客户端自由通信的需求一直都在，但由于HTTP协议本身的局限性，因此催生了Comet等变通的方法，但即使这样也离实时相距甚远。而当 Node.js兴起后，另一个HTML5技术webSocket也渐渐成熟，人们突然发现，实时通信一下子变得触手可及，于是webSocket技术在 Node.js中得到大量的应用，其中最为知名的模块就是socket.io，而各种全栈框架也纷纷加入实时特性来应对更广阔的开发需求。
目前有代表性的实时框架有：
Meteor（官网、Github、NPM）
MEAN.io（官网、Github、NPM）
Derby（官网、Github、NPM）
SocketStream（官网、Github、NPM）
不过说实话，目前能看到的实时通信的应用场景其实不多，其中大多集中于聊天室、to-do、实时图表、在线游戏等领域。其他领域使用实时特性不但没必要，而且是对服务器资源的浪费。因此目前是否要采用实时框架，要看具体的项目而定。
以上基本就是Node.js Web框架的现状了，相信看到这里，对于选择何种框架读者已经心里有数了吧。最后再介绍一个容易搞混的概念，和解释一下我的选择。
YEOMAN？
第一次见到这个词，我还以为它和MEAN有什么联系。事实上，它们是截然不同的两个东西。YEOMAN由YO（脚手架）、grunt（构建工具）、bower（包管理器），它代表的是一种工作流，与框架开发的思维方式完全不同。具体的介绍可见这里。
YEOMAN能够和框架达到类似的目的，都是为构建一个Web应用做好准备，但是要不要采用YEOMAN，则是见仁见智。我个人的看法是，学习 YEOMAN本身就需要不少时间，并且有一定的学习门槛。至少在目前，使用框架开发还是相对经济的，而如果以后YEOMAN这种模式推广开来，再来学习也 不迟，更何况有一定的Node.js项目经验之后再来学习YEOMAN要轻松很多。
事实上，我还是很认可YEOMAN这种Generator+package Manager的模式的，这是因为Node.js本身崇尚微模块的 概念，即无论是多么小的功能，都将它们模块化，甚至大的模块也要拆分成小的模块，然后通过搭积木的方式来构建应用。这样能够彻底的解耦，对于不容易调试的 Javascript来说，也有助于定位和修复应用中的问题。Generator就是这种理念催生下的产物，通过选择不同的配置和选项，将积木搭起来。不 过对于这种模式目前大家也还处于实验当中，不急于进行实际应用。

I started writing this article as an answer on Quora, seeing how there wasn't really any good comparison between Meteor.js and the MEAN stack (MongoDB, Express, Angular, Node.js).

Introduction

First off, I should mention there's no such thing as "the" MEAN stack or framework. The acronym (explained above) generically identifies using these technologies in combination. There are several implementations of the MEAN stack (a community fragmentation problem in itself). Meteor is actually a mature full-stack real-time web application platform (a framework plus a lot of utilities) that has been developed by a very well-funded and highly knowledgeable team since 2011 and has a very large community.

What Meteor gives you for free

Meteor gives you a lot more out of the box. The client and the server communicate data updates seamlessly and automatically, without you having to write any boilerplate data sync code.

The MEAN stack is just MongoDB, Express, Angular and Node.js bundled together, but there's nothing seamless about it. You have to do all the wiring-up yourself between MongoDB and Node.js, between Express and Angular, create REST endpoints and consume them etc. - all this just to get a basic web app going, without any features that Meteor gives you for free: hot code reload, mobile development (web, Android and iOS apps from the same code base), reactive templates that update automatically when data on the server changes (try to write code for that manually and make it run correctly over intermittent network connections, and make sure it's secure), session management, packages that can install components both on the server and on the client (e.g. server-side autocomplete - you won't find this anywhere else; Twitter's Typeahead and the like are client-only solutions).

With the MEAN stack, when you make a REST request for a table/collection, you're essentially saying "Send me the results of this query". With Meteor, you subscribe to the results of that query, and any newly created or modified documents that matched will be automatically sent to the client over a fast WebSocket connection.

Thanks to its isomorphic APIs (the same methods work on the client and the server, e.g. HTTP.call), Meteor makes it easier for one developer to build an entire full-stack app, or for a team to have a better understanding of the code base across the project. The MEAN stack adds to the separation between the server and the client due to different APIs being used.

No callback hell

Meteor's server side runs on top of Node.js but eliminates callback hell by using Fibers. Even on the client, you can avoid callbacks and even promises by using reactivity via the simpler Tracker and Reactive Method packages.

In Meteor, your server code runs in a single thread per request, not in the asynchronous callback style typical of Node. We find the linear execution model a better fit for the typical server code in a Meteor application.

7 Principles of Rich Web Applications

Guillermo Rauch, the well-known author of Socket.IO, has written an excellent article call "7 Principles of Rich Web Applications". He's also delivered a talk at BrazilJS about the principles:

1. Server rendered pages are not optional
2. Act immediately on user input
3. React to data changes
4. Control the data exchange with the server
5. Don't break history, enhance it
6. Push code updates
7. Predict behavior

Meteor implements #2, #3, #4 and #6 for the developer. #1 (server-rendered pages) and #5 (enhance history) are handled by ecosystem packages (Spiderable, Server-Side Rendering, and Iron Router). (#7 as described by Rauch, isn't really in the purview of full-stack frameworks.) By comparison, the MEAN stack needs to be coupled with Socket.IO to even have the pieces to implement these principles - Meteor already has them all glued together.

Meteor also has the entire toolchain built-in, from compiling Coffeescript automatically to minifying and concatenating CSS and JS. Within seconds from saving a file, all client web browsers will automatically reload and re-render the app thanks to hot code push (#6 above). The UI state (form inputs, scroll position, selection) is preserved (another fun thing to try to get right with the MEAN stack).

Meteor = MEAN stack + Socket.IO + grunt/gulp + Cordova + hot code reload + a lot more. Such as extremely convenient packages - one of the "Eureka" moments with Meteor is when authentication with user/password, Google, Facebook and Twitter is added just by including a package for each OAuth provider and one line of template code to indicate where to place the login widget:

meteor add accounts-facebook
// then add {{> loginButtons}} in your template to show the login UI

Meteor has over 4,3000 packages. MEAN.JS has only one module so far, for SEO. Meteor lets you deploy with one command to free hosting at yourapp.meteor.com. MEAN.io doesn't support deploying yet.

Which is easier to learn?

But isn't that a lot to take in all at once? Actually, not. Thanks to Meteor's focus on simplicity (one of its Seven core principles), Meteor in its entirety is far easier to learn than Angular alone. Many have found Angular to be a pain to learn and ended up frustrated - see An Unconventional Review of AngularJS:

Angular is... band-aids over self-inflicted wounds

You can get the basics on Meteor in just one hour - head over to http://meteor.com/try. Meteor's documentation is also very well-written. By comparison, the documentation for the MEAN.io stack is in such a shape that today I went through the Packages section and found an embarrassing number of typos in just a few minutes, all within two pages of the documentation. Packages seem to have no documentation, either. And not to discredit the authors, but you can't easily find who the core team is - the link in Credits is broken. The documentation for the alternative, the MEAN.JS fork, starts with,

After downloading the source code go over the official documentation of MongoDB, ExpressJS, AngularJS, and Node.js, then continue with the MEAN.JS Documentation.

Given that it really takes only one hour to make something useful with Meteor, from scratch, it's worth simply giving it a try first, to have a reference before starting to learn MEAN.io or MEAN.JS.

Of course, you'll still need to learn MongoDB well for a production app, but Meteor doesn't send you there to get started. The 80% most common cases of using Mongo are already explained in the Meteor documentation.

Community

Meteor also saves you from having to research what libraries to use for the various layers of the application (transport, data synchronization, API, security, CRUD operations, templating etc.). All the pieces that make up Meteor function together very well.

By contrast, when considering the MEAN stack, you start with the choice between MEAN.io and MEAN.JS. The short story is that the main MEAN.io contributor, Amos Haviv, Forked out of an open-source conflict in January 2014. You can read more about the story and differences on StackOverflow. This has split the community into ~6k GitHub stars for .io and ~2k for .js. Meteor by comparison has 23,000 GitHub stars.

On StackOverflow, right now there are over 10,000 questions tagged meteor, and about 1,100 total tagged mean, mean.io and meanjs

More more details on the community size, see the Community section in Why Meteor.

When not to use Meteor

As with any tool, Meteor is not always the right solution. I've expanded on when not to use Meteor in the corresponding section of my Why Meteor article (e.g. when you're building a client-only app, or when you require interfacing with databases other than MongoDB). To compare apples to apples, have in mind that the MEAN stack includes a server and MongoDB. So let's see when a MEAN stack might be a better choice for a new web application:

• If you already have most of the pieces of your app written using the MEAN stack. Meteor provides many extra niceties, but make sure they justify the migration cost.
• If you're only building a web service/REST API and don't need any client functionality. Meteor is a client-server platform. (Side note: if you're considering REST, consider GraphQL instead)
• If you don't really need your web app to be real-time. There is a RAM and CPU cost for providing real-time data sync between the server and subscribed clients, even though one $5/mo low-specs DigitalOcean server can handle a basic Meteor app.
• If you're building a website, rather than a web application, and it's more important to deliver the first page as fast as possible, rather than be able to prototype or develop very fast
• If you already need to scale your app to millions of users right now - though with Meteor 1.3, two new developments will help in this area:
  1. The Galaxy scalable hosting platform
  2. Meteor's Livedata system now supports tunable queries to help scale large apps.

Conclusion

I've found that Meteor saved me from a lot of analysis paralysis, besides making me a ton more productive than if I had to put together the pieces in the MEAN stack. My suggestion is to read a bit on Why Meteor could be a good choice or not, give it a try first for one hour (meteor.com/try), then look at the MEAN stacks, and see which would work best for your project.