检票与Vaadin
我们之间的武器和vaadin撕裂。 我开始一个微型ISV，需要做出一个Web框架的select。 我已经把我的select缩小到了检票口和检票口。 我已经使用这两个框架，我爱他们两个。 但是我需要做出select。
如果我selectvaadin：
- 我不必担心外观和感觉。它带有很好的主题
- 我会尽我所有的Java编程，这是非常擅长的，而不会花时间捣乱CSS不是很好
- 我需要的商业应用程序的大部分组件包括桌面，如布局，工具提示，键盘快捷键，带有可拖动和可折叠列的表格等等。 如何，如果我去vaadin的方式：
- 我将失去声明式创buildUI的能力。
- 如果浏览器不支持javascript，我不会有后备function – 例如大多数非webkit移动浏览器。
- Vaadin公司正在销售一些组件，例如JPAContainer，所以我不确定公司会致力于提供完整的开源框架。 企业的利益永远是第一位的。
- vaadin应用程序将主要用于Intranet。 不太适合用networking外观和感觉的互联网。
如果我走的方式：我将不得不风格我的应用程序，我几乎不能给他们一个桌面的外观和感觉。
任何build议。 任何一个在任何一个框架上有经验的人都会亲切地告诉我这些利弊，以及你是如何做出决定的。
我想我已经为这两个框架投入了一些时间。 我真的很喜欢这两个，因为他们带来了类似Swing的编码到网页开发。 我不知道更容易的人（虽然有点击，但我不喜欢速度模板的东西）
是的，有分歧。
我不必担心外观和感觉，它带有很好的主题
没错，但是每一个认真的公司都会以不同的方式来devise它的应用（除非你正在做原型）
我会尽我所有的Java编程，这是非常擅长的，而不会花时间捣乱CSS不是很好
那么Vaadin会变得更好。
我将失去声明式创buildUI的能力。
那有什么好处呢？ （顺便说一句：你可以在groovy中声明代码;-)）
但是没问题。 我知道你的意思：如果你能做到这一点，一个单独的devise师可能会比'wicket'更好。
我几乎不能给他们一个桌面的外观和感觉。
为什么不？ 或者你在这里是什么意思？ Wicket支持Ajax，并且有支持“类似桌面”的东西的组件（ajaxlink，lazycomponent，autocompletion，progressbar，参见wicket stuff + extensions）。 好吧，对于任何更复杂的组件，你将不得不在JavaScript代码，但顺便说一句，你知道你甚至可以在检票口内使用GWT
一些小的经验：
Vaadin肯定是更快的编码（没有CSS，HTML的东西）。 但是，如果你去生产，请记住，编程的简易性可能会导致客户端的性能成本：例如，如果使用“Horizontal / VerticalLayout”这样的错误布局，JavaScript的大量使用可能会减慢下来旧的浏览器。
但Vaadin不慢！ 使用适当的布局，如CssLayout或FastLayout，旧的浏览器也可以使用它。 （虽然如果你使用CssLayout，你的编码风格实际上是类似于wicket的。）
Vaadin的一个问题是，configuration文件有点困难，因为你不能很容易地看到客户端需要所有的CPU，嵌套的div得到了隐蔽的id名。
Wicket的一个伟大的事情是它的持久整合
（Guice可以集成在Vaadin和Wicket中）
用Vaadintesting用户界面应该很容易（虽然我没有发现unit testing的东西）， 用wicket很容易。
最后但并非最不重要的创build列表/表是Vaadin相比，检票非常容易。
我已经与Wicket广泛合作，但我还没有任何与Vaadin的经验，所以这可能是（一点）的偏见。
我build议Wicket的原因很明显，但你可能感兴趣的是Wickets的开放性。 正如Gweebz正确地指出的那样，Wicket使用基本的HTML标记作为基础，因此任何结构或外观变化通常都是微不足道的。
就个人而言，我真正喜欢的工作之一就是前端展示和数据后端之间的stream程，我们实现了Spring和JPA / Hibernate，这意味着前端的任何更改都可以转换回数据库用一行代码感谢Wickets基于模型的架构。
对于Vaadin从来没有使用过的东西，我再也不能多说了，但是如果你正在寻找架构来开始，我还build议你看看GWT。
（从第一个Wicket相关答案的评论继续）
Vaadin和Wicket之间的主要区别在于如何编写UI组成和客户端代码。 借助Vaadin，您通常无需使用任何模板或HTML就可以构build您的UI，并且可以获得一个圆滑的完全Ajax化的UI。 但是，如果您更喜欢模板方法，只需使用CustomLayout即可。
客户端编码是很less需要的，但是当你使用基于Java的GWT这样做的时候，比用手写Javascript好得多。 此外，使用GWT，您将自动获得跨浏览器兼容的解决scheme，而不必自己处理这些问题。
在比较框架时，您还应该查看社区活动和文档。 Vaadin这两个都很好。 还要注意Vaadin目录，它目前包含100多个非常有用的UI组件和其他插件。
我每个人的经验都是有限的，但我更喜欢Vaadin。 它使我正在开发的Web应用程序有更丰富的体验。 卖给我们的主要好处是在我们的UI类中编写unit testing是多么容易，确保在以预期的方式进行交互时组件正确运行。 Wicket也是可以的，但是在我的经验中，这样做更困难。
我也会提到这两个框架都需要一些样式。 Wicket以普通的旧HTML开始，Vaadin默认启动了一个类似于MacOSX的主题，但几乎所有的Web应用程序都需要至less一些定制。 考虑到这一点，定制一个Wicket应用程序的CSS比Vaadin更容易，因为你控制标记的原因很简单。 Vaadin隐藏了您的标记，并生成具有奇怪ID和结构的元素，因此很难自定义外观。 请记住这一点，当你作出决定。
我目前正在与Wicket合作，而且我曾经和Vaadin一起合作过。 在我的观察中，我将很短暂：
- Vaadin有权获得自由，但IMO不是那么漂亮。 如果您需要支持，帮助以及遇到的那些棘手难题的文档，那么您会因为与Apache Wicket相比没有那么好的文档/社区而被搞砸了。 Vaadin有人帮助你，但你必须付钱。
- 要在wicket中编程，你需要成为一个强大的程序员。 Vaadin也需要良好的Java知识，但是如果你愿意，你可以轻松地做一些意大利面代码（只是说，不做）。
- Apache Wicket确实将Web技术（Javascript，HTML等）从框架技术（Java）中分离出来。 Vaadin也试图做到这一点，但IMO并不那么优雅透明。
从这个angular度来说，我们正在谈论两种不同types的框架，两种不同的方法，我们build议您search和比较，看看真正适合您需求的优点和缺点。
编辑：哦，关于外观和感觉，例如，你总是有Wicket Bootstrap
另外请注意，尽pipeVaadin基础框架是免费的，但对于一些额外的function，您可能需要购买扩展。
例如 – 如果您需要整合一个好的图表解决scheme（如Highcharts），您必须付费购买vaadin图表扩展（即使免费提供高分辨率的自由/开放源码软件应用程序，构build于其上的vaadin图表插件也不会免费FOSS应用程序）。
