我在考虑使用Java创建自己的网站，并试图决定使用哪个框架。然而，快速搜索Java框架返回了50多个可供选择的选项！
我的网站一开始只是为了自己的乐趣而建，但如果它变得受欢迎，它应该具有一些可扩展性，或者至少能够为此重新设计。
这些流行框架之间的主要区别是什么？是否存在某些情况下一个框架明显优于其他框架？例如，高流量企业应用程序与低流量小应用程序之间的区别。我还想知道是否有些框架比其他框架更容易学习和使用。
是否有人有使用这些框架的经验并能给出推荐？这么多选择只是提醒我们尽可能避免使用基于Java的Web开发吗？
我曾广泛使用过Tapestry 3、Wicket、Echo和JSF。 我非常建议您查看它们并选择最适合您的方式和工作习惯的框架。
在它们中，对我来说最舒适的是Wicket，因为组件构建的轻量化以及页面模板的简单性。如果您正在使用自己的数据库代码而不是Hibernate或其他框架，则更加如此（我从未完全满意Wicket Hibernate或Spring Integration）。
Echo非常适合您如果您不介意用Java编写所有的布局。我知道现在已经有所不同了，但我仍然认为该产品的市场比较狭窄。它们似乎每个主要版本都会改变开发模式。
Tapestry是一个很棒的产品，但是它在开发模式上显然与其他框架非常不同，因为它主要由一位大佬引领。Howard Lewis Ship无疑非常聪明，但我对他们每个版本都忘记向后兼容的决定感到失望。尽管如此，对于您的需求来说，这可能并不重要，而且我总是发现Tapestry的产品非常令人愉悦。
JSF已经发布多年了，但仍然感觉像是一个Struts的开发者为解决所有Struts的问题而构建的东西。并没有真正理解Struts的所有问题。虽然该产品显然非常灵活，但它仍然有一种未完成的感觉。我使用它并对它有些喜爱，希望未来能有更好的发展。我认为下一个版本(2.0)将在JEE6中发布，它将通过新的模板语法(类似于Facelets)和简化的组件模型(自定义组件仅需1个文件...终于)实现真正的进步。
当然，还有许多小型框架和工具，它们各自拥有自己的追随者(Velocity用于基本需要，原生JSPs，Struts等)。我个人偏好组件导向的框架。
最后，我建议只需看看Tapestry、Wicket和JSF，并选择最适合您的那个。您很快就会发现一种方式适合您。
我最喜欢的是Spring框架。2.5版本的Spring MVC非常酷，有新的注释、约定优于配置等功能。
如果你只是做一些超级简单的事情，也可以尝试使用常规的Servlet API，不必使用框架。
我建议使用面向组件的Wicket框架。它允许您使用纯Java代码编写Web应用程序，您可以将POJOs用作所有组件的模型，而无需处理庞大的XML配置文件。
在我发现Wicket并看到Web应用程序开发有多简单之前，我已经成功地使用Struts开发了一款在线银行应用程序！
最近我开始使用 Stripes Framework。如果你正在寻找一种基于请求的框架，易于使用，但不会限制你在做什么方面的话，我强烈推荐它。
它类似于Struts，但远远超越了它。甚至有一些插件项目，可以让你用非常少的配置来使用 Hibernate 或 JPA。
虽然有很多好的框架，但我听说 Wicket 也是一个不错的选择，但我没有使用过。
虽然我自己还没尝试过，但我认为
具有很大的潜力...
作为一个来自php和classic asp的人，这是我第一次听说一个听起来很有前途的java web框架...
更新：Tapestry 5.2已经发布，因此它不是被放弃的，之前似乎是这样的。我的经验是在Tapestry 4上，而不是5，所以可能会有所不同。随着多年的经验，我的观点已经改变了；我修改了这篇文章以反映这一点。
我不能再像以前一样推荐Tapestry。虽然Tapestry 5似乎有很大的改进，但我对Tapestry的主要问题并不在于平台本身；而是与背后的人有关。
历史上，每个Tapestry的主要版本升级都远远超出了预期的向后兼容性破坏程度。这似乎是由于结合了需要重写的新编码技术或技术所致。
Howard Lewis Ship（Tapestry的主要作者）确实是一位杰出的开发者，但我不能说我喜欢他对Tapestry项目的管理。Tapestry 5的开发几乎是在Tapestry 4发布后立即开始的。据我所知，Ship几乎完全将自己致力于此，把Tapestry 4交给其他贡献者，我觉得他们没有Ship那么能干。在从Tapestry 3到Tapestry 4的痛苦转换之后，我感到自己几乎被抛弃了。
当然，随着Tapestry 5的发布，Tapestry 4成为了传统产品。如果升级路径不是如此残酷，我就不会有问题 again.。因此，现在我们的开发团队处于相当尴尬的位置：我们可以继续使用基本上被放弃的Web平台（Tapestry 4），进行可怕的升级到Tapestry 5，或者放弃Tapestry并使用另一个平台重写应用程序。这些选项都不是非常吸引人。
Tapestry 5据说是为了从现在开始减少更新破坏而编写的。一个很好的例子就是页面类：在之前的版本中，页面类源于Tapestry提供的一个基础类；这个类中不兼容的API更改是导致大量向后兼容性问题的原因。在Tapestry 5中，页面是普通的POJOs，通过注释在运行时进行增强。只要注释的契约得到维护，Tapestry的更改就不会影响页面类。
如果这是正确的，那么使用Tapestry 5编写新应用程序可能会取得良好的效果。但就我个人而言，我不想再次将手放在火上。
Spring MVC 用于表示层和控制器层（不使用 Spring Webflow，因为我的流程基于 ajax）
jQuery 用于所有客户端功能
Spring Security 用于安全方面
Hibernate / JPA2
Jetty 用于连续性（comet）
作为项目负责人，我必须考虑人力资源，Java 开发人员比 Scala 开发人员更容易找到
对于我的团队中的大多数开发人员来说，Scala 的函数概念虽然很好，但很难理解
