类似于this question，“我正在寻找每个框架的利弊，以及为什么一个框架对另一个框架特别有用”（但主要是Flatiron所提供的，因为Express是已经在那个问题中详细说明了。）
从我对Express的轻微体验，它似乎只涵盖了你需要的东西，而不是更多。 Flatiron似乎这样做，但更简约。如果你检查他们的website，你会发现他们提供了大约5-7个主要功能，与Express中包含的许多其他功能相比。
最后，对于高度可扩展的Web应用程序而言，这似乎是最有希望的，为什么我应该使用这个或那个框架而不是使用框架呢？
答案 0 :(得分：12)
在问到这个问题一年半之后有些更新：
将Express与Flatiron进行比较时首先想到的是，Express是一个服务器端框架，而Flatiron被宣传为同构，包括服务器端和客户端以及因此应该适合开发传统的服务器端应用程序，客户端单页面应用程序以及介于两者之间的所有内容（很像例如。Derby或Meteor）。但是，我没有找到Flatiron客户端使用的任何示例，而不是没有尝试。
有an issue on GitHub提供一个简单的TODO应用程序示例，该示例已打开两年以上（根据我的理解，阅读那里的评论）您无法单独使用Flatiron构建客户端应用程序，而无需添加内容像jQuery，Backbone等，因为Flatiron的客户端方面似乎还没有准备好（“我们正在努力。我们还有更多的步骤去做它完全同构。“）这似乎是一个试图从一开始就是同构的框架的真正问题。 （另请参阅相关的TodoMVC问题：Add FlatIron example）。
结论是Flatiron尚未准备好。当它准备就绪时，它可能涵盖了比Express更多的Web开发领域，但如果一个简单的TODO app example多年没有被提供，那么很难说它可能是什么时候。
与此同时，有大量的Node框架并且很难跟踪它们，所以我现在和将来建议做的就是在GitHub上的Joyent / Node wiki上查看the list of Web frameworks并进行比较它们到TodoMVC项目的客户端框架 - 这两个列表相交的将是覆盖服务器和客户端的框架，并且能够在其中编写一个简单的TODO应用程序 - 希望包括Flatiron一个一天。
答案 1 :(得分：6)
我的感觉是，快递是最小的，而熨斗似乎更完整/更复杂。 缩放的最佳选择是一个难题，因为两者都没有做任何事情来提高应用程序的扩展能力。他们通过提供简单的方法来添加路径（而不是让自己因为错误的正则表达式而疯狂），从而使开发应用程序变得更容易。
就个人而言，我已经开始喜欢所有的小连接和表达中间件，以及dynamicHelpers（用于模板），这似乎不受flatiron的支持（是的，他们有中间件，但它似乎不是如果你可以使用连接中的那些。编辑;事实证明，Union，这是flatirons中间件处理程序兼容连接，所以你可以使用connect的中间件）。
我建议有人在熨斗上使用快递，但是再次;我希望被证明更好。
答案 2 :(得分：1)
在我看来，Express与Flatiron的战斗显然是由Express赢得的。
Flatiron框架ATM没有积极的开发。
请参阅GitHub存储库：https://github.com/flatiron/flatiron。 最新版本是2014年9月16日的0.4.2。
官方熨斗网站http://flatironjs.org/已关闭。