我应该使用Vaadin框架吗？
我只是试图玩Vaadin框架 ，在我看来很容易使用。 另外我喜欢他的框架是它build立在Google Web Toolkit（GWT）之上。
你怎么看，我应该继续使用这个框架，还是坚持使用GWT？
嘿。 作为一个免责声明，我为公司开发Vaadin工作。
Vaadin使用GWT的方式是它有一组预编译在GWT中的组件。 当然，如果你愿意的话，你可以另外制作你自己的组件。 但是，这套组件是相当完整的，而且通常可以根据您自己的需要进行定制。 这意味着，每次更改应用程序时，都不必将代码从Java重新编译为JavaScript。 您只需将已有的组件组合在一起即可。
这个框架是由服务器驱动的，所有的逻辑都是在服务器端处理的。 组件有两部分，客户端和服务器文件。 客户端只是组件的虚拟“视图”。 一旦你和它交互，它就会向服务器发送一个消息，表示这个或者那个被按下/写入/等等。 服务器然后决定应该做什么。 这是为了提高安全性，因为你不能“破解”逻辑，因为在JavaScript中只有一个用于发送请求的小API。 这在某些情况下可能与应用程序的速度有一定的折衷，但我不认为它是如此糟糕。 最糟糕的速度颠簸通常是数据库查询往返等，这与UI框架的select没有任何关系。 build议的演示的缓慢可能是因为你远离服务器或目前有很高的用户命中。 尝试在自己的环境中，closures你的应用程序的最终应用程序，看看它的performance如何。 有一些准备好的应用程序，您可以部署来testing它。
我想这个select归结为你正在做的事情。 Vaadin适用于Web应用程序，因为您可以构build一个普通的Java应用程序并轻松地为其创builddynamicWeb UI。 如果你做更多的传统网站，用户只能浏览网页 – 而不是积极地与网站互动，那么Vaadin并不是最好的select。 去一些其他免费的框架，如铁轨或PHP框架等。我认为你更多的是做一个应用程序，因为你build议你现在使用GWT，所以Vaadin应该是好的。
在Vaadin论坛或irc频道#vaadin @freenode上提出更多的问题，也许有人可以给你更多的理由为什么或为什么不使用Vaadin。
经过将近一年的时间，开发了一个不那么庞大的GWT应用程序，使用了我从MVP，EventBus，CommandPattern等最后的Google I / O中学到的所有最佳实践。我从心底说这个：让我的团队和客户在技术上和视觉上都想要的东西，甚至在UiBinder发布之后，Vaadin就像隧道尽头的灯光一样来到了我的面前。
在为命令模式编写了近千个样板动作之后，还有另外1000个主持人和视图以及另外的1000个事件处理程序等等。无需处理几乎75％的这些类，仍然保持良好的模式方法（appfoundation add-on），一点networking开销是可以接受的。 通过Vaadin，您可以获得很好的小部件，分页，数据绑定，完美的布局。 所有这一切是为了什么？ 在服务器端消耗更多的内存。
我想我可以说这是可以接受的，因为我没有build立下一个Facebook或其他东西。 我仍然可以在每台中型服务器上同时处理数千个用户，同时保持低延迟的往返。
借助Vaadin，我可以用几乎一半的代码构build一个不错的应用程序，而且应用程序似乎更完整。 🙂
！ 更新2011年2月23日：我不能强调如何应该知道每个框架的限制。 Vaadin也不例外。 应该意识到，Vaadin会抽象出任何forms的HTML或JavaScript。 此外，由此产生的HTML是非常沉重的，你应该自己照顾历史状态的变化。 所以，当你build立你的项目时要注意这些开销。
免责声明 ：我与以下提到的所有图书馆都没有关系，但恰巧知道我的方式。
和你一样，我在思考用于新项目的堆栈/框架时偶然发现了这个post。 我玩了一些可靠的经验！ （好吧，在斯卡拉，但这不是相关的），但引人注目的小部件和他们与服务器端+ Swing像开发的无缝集成确实激起了我的兴趣。 那是在2010年末，因为答案让我想给Vaadin一个尝试，所以我决定回来，写下我希望在这里阅读的答案，尤其是在这里。 因为这个问题今天仍然是有关的。 与此同时，Vaadin从第6版到第7版进行了一些必要的改进，Play！ 从版本1到版本2，我（+一个小团队）用这两个框架完成了一小部分成功的项目。
我认为比较是有趣的，因为这两个框架
- 运行在JVM上，可以利用其丰富的生态系统
- 在他们的Web应用程序的方法和你作为一个开发人员应该关心的方面不会有更多的不同
- 在较小程度上，它们与Java EE的关系如何。
赞美
一句话，如果您发现将桌面应用程序移植到浏览器的想法，而完全从底层的HTTP请求/响应机制中抽象出来，那么Vaadin可能就是您制作Web应用程序的候选人。 Swing类似于编程的方法对于那些离开HTML和JavaScript低层次最开心的人来说是一件轻而易举的事情。 对您的应用程序的新请求确实启动了一个新实例，其余的stream程取决于您和您的逻辑。 链接恢复到旧的button导航，你可以自由地使用许多内置的模板组成你的布局，而无需调整HTML或CSS。 这个API通常是相当一致的，并且被公认是有据可查的（ Vaadin之书是一个强制性的阅读，可以随时随地获得许多东西，比如将bean绑定到组件和validation器上）。 这些小部件具有良好的跨浏览器兼容性，从而确保您的应用程序在广泛的客户端上保持一致的行为。
现实检查
我们有一个很好的时间来开发和testing我们的Vaadin应用程序。 当我们发布第一个版本并开始收集反馈时，事情变得更加清晰和细微。 我们意识到， 我们实际上有一些基本的偏见 ，即：
-
在201x年，大多数用户使用networking的历史已经很长了，其中几乎没有人再使用桌面应用程序。 这里的关键点在于， 浏览器使用超文本链接，后退，前进和重载button，无处不在的选项卡和有时窗口来标准化UX交互，以及大多数操作触发HTTP请求并等待响应的基本思想 。 这是网站遵循的隐含契约，并且是围绕它们构build的。 因此，当用户抱怨他们不能像以前那样使用后退/前进button，或者标签没有以预期的方式工作时，我们不应该感到惊讶。 我们同意了。 我们打破了无形的契约绑定用户和浏览器。 实际上，我们自己是隐式地不使用我们的浏览器与Vaadin应用程序的方式，我们使用它的任何其他网站。 当然，您可以回到前面提到的那本书，仔细阅读关于复制URL片段的Web导航体验，您会发现它实际上比预期的更复杂， 因为Vaadin应用程序是有状态的 。 而且，MVC或MVP范例只是松散地强加给开发者，而不是Play！ 实际上没有其他select。 不要轻易采取这一措施，但是在更换页面之后，您的大脑已经习惯了显示的白色屏幕。 当用户点击并期望获得新页面时，浏览器通过显示沙漏（或其变体）来确认。 使用AJAX，请求被放置在幕后。 现在有些地方，小型的，几乎手术的AJAX罢工已经成为常态，但是对于主要的UI更新还没有。
-
有状态的应用程序带来了他们面临的挑战…和麻烦。 负载平衡（如果你担心）比较复杂。 事务的概念是完全不同的，因为Vaadin会话跨越了许多请求，因此与基于REST的方法相比较长，但在用户体验方面却相对较短。 事实上，用户回到他们几小时前开始完成任务的forms并不罕见。 理论上，这也可以和Vaadin一起工作，但是你必须保持会话很长很长一段时间，而且一直在记忆被阻塞，并仔细考虑这个问题，这可能会影响并发用户。
有状态的页面也很难分享给用户，更不用说书签（假设你处理的是URL片段）。
-
最后，我们分享这样一种印象：用户界面通常比服务器上的逻辑更加缓慢。 当然，你可能总是创build一个装载了客户端JavaScript的小部件来减less往返次数，但是你将不得不在服务器上做一些UI更新。 在我的经验中，JS已经非常沉重，并且在移动设备上体验的更less（我知道TouchKit，但移动设备上的HTML5应用程序并不能为我所用）。 另外，请记住，UI线程在发布请求（即客户端的用户操作，类似于提取UI更新）后处于活动状态，并且可以通过各种监听器访问。 但是，从后台线程更新UI更为复杂（例如推送更新）。 Vaadin 7改善了这方面的情况，特别是在生成相对较轻的HTML的情况下。 通过简单地打开HTTP压缩，UI显着改进就显而易见了。
结论
所以我们暂停一下，想知道在Vaadin方法中我们发现如此有吸引力。 最初的发展是一个相对平稳的过程，产生了快速的结果，但重新devise一些概念以适应networking用户体验的期望给了我们一个反潮stream的强烈印象。 我们的结论是，从HTTP请求/响应机制中抽象（被遮蔽）的诱惑的想法certificate是一把双刃剑，揭示了Web应用程序和桌面应用程序之间的实际阻抗不匹配。
我们不要假装networking又是一个层次，我们强烈地感觉到应该采用它的工作方式， 并且以一个以URL为中心的应用程序 （Rails / Django / Play所强加的）开始。 你可能听说有人说数据超出了应用程序。 如今数据被URL资源引用，所以人们可以放心地说，URL超过了数据。 毕竟，他们是什么人的书签，不是吗？ 因此，在这个层面上，基本的关注点也应该适用。 这可能就是为什么网站如此受欢迎的原因。 因此，我们重新审视了我们的应用程序，以便更多地围绕一个中央控制器来响应在不同的资源path上进行的操作。
现在我们正在维护我们的Vaadin应用程序，但是由于其中一些限制和基本的范例转变，我们不会用它开始新的项目。 然而，要build立一个技术上一致的，有凝聚力和有据可查的360°Java Web框架的团队，需要很less的Web内部工作知识。 另一方面，他们甚至支持一家销售咨询服务的公司。 我很感激这样的经历，以及如何让我重新评估我对web应用程序的看法。 我将密切关注其发展，但我们肯定需要更多的控制和粒度。
希望有一天，Vaadin将从它所依赖的整个Servlet体系结构中释放出自己的HTTP服务器。 更好的是将会是一个更深入扎根于框架的MVCdevise。 但在可预见的未来，这种情况不太可能发生，因为它似乎已经find了一个利润丰厚的企业爪哇大猩猩谁赢得了利润丰厚的利基谁发誓。 闪耀。
TL; DR ：我认为Vaadin错过了webapps的意义，更重要的是，他们应该如何performance。 这是关于时间程序员拥抱networking和用户如何与它交互（即后退button，重新加载button，标签和书签）。 Web应用程序越贴近HTTP请求和语义（动词），就越有可能匹配用户的期望。 这是关键。
编辑 ：如果你有任何Python的经验，我强烈build议尝试Flask也得到一个以networking为中心，基于REST的Web应用程序编程的味道。
编辑2 ：如果因为任何原因，你觉得你必须使用一个完整的Vaadin样框架，然后给meteor尝试。 这是一个基于JavaScript的（前端和后端）框架，在Node.js上运行，通过WebSocket发生asynchronous通信（因此比请求/响应更小的延迟），默认情况下是反应。 在meteor中，我不喜欢Vaadin中的一些东西。 例如，用户界面更新的逻辑运行在客户端上，这使得它比Vaadin更有响应。 JavaScript和Java社区中的人们并不相交，但是当我第一次听到这个消息的时候，与Vaadin并驾齐驱的就是我。 它目前在社区中有相当的动力，原因与那些使Vaadin受欢迎的原因类似。 能够制作类似桌面的networking应用程序。 如果您也意识到Java不属于未来Web应用程序的图像，或者您已经厌倦了刷新刷新所需的长时间部署周期，请尝试一下。 但在将整个应用程序绑定到一个库之前，请三思而行。
关于Vaadin的常见说法涉及到小部件的设置，并担心客户端和服务器之间的往返通信。
但在我看来，这忽略了Vaadin最重要的（也许是革命性的）方面：它完全消除了devise和实现AJAX应用程序通常需要的客户端 – 服务器通信的任务（AJAX中的“A”和“X”）， 。
借助Vaadin，您可以完全忘记DTO（数据传输对象），基于协议的安全问题，Hibernate延迟加载exception等。
从某种意义上说，您只需编写一个常规的Java Swing桌面应用程序，只有您使用的是Swing中的其他UI工具包。
从我的经验来看，GWT需要大量的样板代码，并且在构build丰富的UI时会很慢。 通常我们处理相当复杂的应用程序模型，这些应用程序模型包含许多可持久的域对象 要将所有这些数据带到客户端，您需要引入单独的客户端模型并提供数据转换机制。 我们使用Dozer来达到这个目的，并且需要花费很多时间来映射每个字段，创build自定义转换器并testing所有这些东西。
另一方面，如果不陷入过度工程，如果应用不是很复杂，可以利用客户资源，减轻服务器负担。 这样你就可以大大减less与服务器的通信，并获得更多的响应式软件。
瓦丁看上去很开心:)但是我有点害怕对服务器“大规模的AJAX攻击”。 我在ZK方面有经验，而且当UI上的微不足道的操作工作缓慢时，我们经常遇到性能问题，因为它需要与服务器通信。
Wicket是另一个很好的框架，但它更适合于网站。 它可以使用和不使用AJAX，可以被search引擎索引。 而且它处理干净的HTML代码的最有吸引力的事情 – 没有自定义标签，没有控制结构，关注严格分离，只有组件的特定wicketid namigs。
它主要取决于你的需求：
- 如果您需要超快速和简单的应用程序 – 使用GWT并利用客户端资源
- 如果你的应用程序比Vaadin看起来更复杂，
- 如果你的应用程序是公开的，你需要一个能力来索引search引擎优化比selectWicket。
Wicket使用会话来pipe理组件状态和可扩展性类似于关于Vaadin和服务器端处理的争论。 在过去的十年里，我已经了解到，Java社区通常对如何衡量Web框架的潜力（等等）是错误的。 从JSF到Grails，通常需要几百GB的内存和至less一打开源的jar文件，这些jar文件重叠和低效的function才能让生产应用程序运行。 看看周围，你会看到大多数的networking托pipe公司不提供一个实际的Java选项，因为Java技术已经采取的Web框架的不稳定path。 由于编译速度的原因，GWT 2.1仍然是一个痛苦的使用，而且对于从一开始就应该存在的MVP和数据表来说，它正在变得越来越严重。 我喜欢Wicket，但Vaadin看起来很有前景……但是知道Java框架如何走，我相信他们会在某个时候开始自己的脚步，但是我怀疑这是因为服务器端处理繁重。
事情是，对于严重的发展，你不能忘记任何东西，更不用说dtos了。我正在开缝，而服务器端的ui概念只是因为我希望更好的控制电线上发生的事情.. vaadin的问题给我恰恰是，在服务器端有状态..
为了构build好看的用户界面，我会说这是要走的路。 另外它是非常有据可查的。
我已经使用了几个星期，我真的很喜欢它。 代码是坚实的，docs一个好的，非常合乎逻辑的结构，最终结果是优秀的。
我喜欢它与Hibernate结合在一起来整理所有的数据库的单调乏味。
Plus – 易于部署（使用Tomcat，您只需通过Web界面上传一个.WAR文件，简单易行）
用Maven看一下Vaadin的演示版本： http : //asolntsev.blogspot.com/2009/11/vaadin-demo.html
将Apache Wicket作为面向组件的Java Web UI框架的强大替代品也值得考虑。 Vaadin听起来不错，我不想减损这个讨论，但select是一件好事。 有几个源代码与主页链接的例子，在WicketStuff站点更多，Manning的优秀书籍形成了很好的第三方文档。
我认为Wicket是前进的方向，直到我试图使它有效地工作，并开始一个抑郁症（笑话）。 然后，我切换到GWT，这看起来不错，但有太多的锅炉板代码写和文档是不是很伟大… – >光来自Vaadin：简单，可操作，没有错误到目前为止… ！
在我们这个以Java为主的大型公司中，我们有机会创build一个新的基于networking的产品。这是一套产品，在三个国家有很多团队正在开发这个产品。 当谈到我们的团队时，我有select使用Vaadin来利用我们的Java开发经验。我search了Google来帮助我做出决定。 我也读过这个post; 但是我select了反对使用Vaadin，尽pipe其他很多团队select了Vadin。 以下是我在发布产品之前发送的邮件的原因（To Vaadin or Not）。 这是从我个人的angular度来看的，总的来说，对框架的不信任总是在不同程度上。 所以只是想给读者另外提一下这个问题。
那么，我们继续学习HTML，CSS，CSSselect器，一个精彩的语言JavaScript和JS库，JQuery和YUI学习狂欢，并创造了及时的networking产品与全面的graphics用户界面和性能合规性; 我个人很高兴，球队和用户一样好。
其他一些采用Vaadin方式的团队也会及时创build他们的产品，我猜也同样开心（只有他们不知道JavAScript的缺失:)。
正如有人所说，所有的抽象都是抽象的抽象，当他们必须从Vaadin 6迁移到Vaadin 7时，他们必须做一些重新工作，花费的时间比任何人想象的要多。 虽然他们当然设法磨碎它， 由于这个原因，还是有一点延迟。另外我猜InvientCharts插件有一些问题，它不支持Vaadin 7，导致团队购买（$$）相关的Vaadin图表插件，并改变了….
对Vaadin或不
借助Vaadin，底层的JavaScript，HTML和CSS似乎是从Java Swingtypes应用程序dynamic生成的。 从一个偏颇的，可能愚蠢的纯粹的angular度来看，这样的一个“我会为你生成代码”标语不会给出好的devise气味。 除非你需要一个抽象，为什么要与另一个框架结合。 就像任何代码生成框架一样，它应该适用于Vdin所想到的抽象，但不是很灵活。 我觉得，如果我们使用networking技术，最好是使用技术引发的工具和语言，即HTML，CSS和JavaScript / JavaScript库，而不是依赖另一个抽象层次 – Vaadin框架。 对于专家GWT或Vaadin开发人员来说，这可能是天真的，因为我猜测Google编译器会生成最优化的JavaScript，而不是您的手写代码，这有助于在多个团队之间更好地pipe理代码（但主要是在开发相当大的Web应用程序时）生产力，更容易的debugging等。然而，编写用于Vaadin的Java组件，然后自动转换到JS是我觉得不对，因为我们的许多开发人员永远不会学习一个非常重要的编程语言 – JavaScript的Web开发（并获得服务器端 – Node.js）。 当依靠框架来获得你的JavaScript的权利，那么你永远不会擅长这种语言。 我想对于一个基于产品的公司来说，学习第一手的networking语言非常重要。 正如有人评论说，Java已经成为了过去一年的COBOL，为了学习像JavaScript这样的其他重要语言，build立起来的能力势在必行。 然而，在JS中工作了很短的时间，我已经注意到，如果我们编写一些规则（模块模式），testing所有的逻辑 – JavaScript单元 – JSTestDriver，并运行JSHint，它是一个相当强大的语言来处理一旦掌握，生产力就会比Java更好。 另外，大多数重要的组件示例 – OpenLayers都是用JS编写的，如果你需要扩展这些或者以最优的方式工作，你需要了解JavaScript，或者像D3.js这样的强大的库。总之，尽pipe有很多优势在使用Vaadin和框架时，从长远来看，使用JavaScript很重要？
我也使用Vaadin。 虽然这个应用程序并不大，但是我真正喜欢的是这个API是一致的，一般都有很好的文档logging，而且由于我正在开发一个新的工具，所以我能够为一个非常苛刻的客户提供相同的东西，或者在某些情况下，比我以前使用的工具更好的时间表。
很less有问题。 现在唯一一个客户坚持使用IE 7（不要问），一些爱好者的眼睛糖果在附加组件 （图表）中不能完全工作。
顺便说一句，我不为Vaadin工作:-)
我已经试过了Wicket和Vaadin，如果你真的尝试了一段时间，在一个月内你会知道Vaadin是要走的，而不是Wicket。 – Dheeraj G
我们看过Wicket工作，但是我们发现，而不是9000个文件，我们可以有超过30,000。 我们的核心金融服务应用程序拥有近1000个屏幕，尽pipeWicket看起来不错，但将Struts 1.3代码转换为Wicket非常困难。 我们的build筑师做了一个POC项目，只有3个屏幕添加了几百个类（许多是重复使用）。 由于你的html必须匹配Java代码，所以用Wicket原型input屏幕也是困难的，反之亦然。
Vaadin看起来很有前途，但这对团队来说将是一个难言之隐。
PS不pipe框架有多好，如果不在行业中使用，没有人会学到它。 Wicket已经有一段时间了，但很less有公司使用它。 我所交谈的大多数开发人员都关心学习一个在简历上毫无用处的新框架。
关键是Vaadin使用类似Swing的devise，而且我使用Swing开始使用Java。
我曾经用Vaadin在我工作的公司（而不是Vaadin）开发一个礼品顾问。
Vaadin允许您构build真正的组件化Swinglike Web应用程序。
如果你担心每次点击的客户端 – 服务器往返，我有这样的说法：我创build了一个鼠标hoverbutton，它改变了button的外观，鼠标hover。 为此，框架必须到服务器并返回。 它的工作速度足够快。 看到http://www.cadeau.nl/sophie看看我的意思。;
我喜欢Vaadin，它满足了我的需求，使networking开发变得轻而易举。
关心，罗布。
我只是在两天前开始使用Vaadin，并能够在OSGi上构build一个完整的模块化，数据绑定和OSGi服务的小型CRUD应用程序，以实现持久性。 一个非常好的事情是我的完整UI只有118行代码，并支持一个简单的java bean结构的完整的CRUD操作。
Vaadin在OSGi中完美工作也是很好的。 这已经是一个捆绑，我发现了一个从Neil Bartlet的桥梁，使得vaadin非常容易在OSGi中使用。
请参阅任务列表Vaadin示例
我不介意在服务器端使用状态。 它服务于它的目的。 随着云计算现在一天存储和带宽变得便宜。 但是，从devise的angular度来看，我可以看到你的观点，特别是如果你想重新使用你的应用程序。 但是我相信对于Vaadin之类，有更多的利弊。 一件重要的事情，你不必为特定的浏览器调整大量关于你的networking应用程序，让它称为IE浏览器，为JavaScript / CSS错综复杂 – 特别是如果你像我一样面向后端。 所有的web应用程序都可以在浏览器中兼容，而不必担心任何事情。 记住，开发者的时间比存储和带宽更贵。 那是我的意见。 =）
