我应该使用Vaadin Framework [关闭]

问题

我只是试着玩Vaadin Framework,在我看来它很容易使用。另外我喜欢他的框架是它建立在Google Web Toolkit (GWT)之上。

你怎么看,我应该继续使用这个框架还是最好坚持使用GWT?


#1 热门回答(121 赞)

嘿。作为免责声明,我为开发Vaadin的公司工作。

Vaadin以一种在GWT中预编译的一组组件的方式使用GWT。当然,如果你愿意,你还可以另外制作自己的组件。但是,这组组件非常完整,通常可以根据你的需要进行定制。这意味着每次更改应用程序时都不必将代码从Java重新编译为JavaScript。你只需将已有的组件组合在一起。

该框架是服务器驱动的,因此所有逻辑都在服务器端处理。组件有两部分,客户端和服务器文件。客户端只是组件的虚拟"视图"。一旦与它进行交互,它就会向服务器发送一条消息,指出这个或那个被按下/写入/等等。然后服务器决定应该做什么。这是为了提高安全性,因为你无法"破解"逻辑,因为在javascript中只有用于发送请求的小API。在某些情况下,这可能与应用程序的速度有一点权衡,但我不认为它是如此糟糕。最糟糕的速度颠簸通常是数据库查询往返等,这与UI框架的选择没有任何关系。所建议的演示的低迷可能是因为你离服务器很远或者目前用户受到很大的打击。在自己的环境中尝试,关闭应用程序的最终应用程序,以查看它的执行情况。你可以部署一些现成的应用程序来测试它。

我想这个选择归结为你想要做的事情。 Vaadin适用于Web应用程序,因为你可以轻松构建普通的Java应用程序并为其创建动态Web UI。如果你更多地使用传统网站,用户只能查看页面 - 而不是主动与之交互,那么Vaadin不是最好的方式。与其他一些免费框架(如rails或php框架等)一起使用。我认为你正在做一个应用程序,因为你建议你现在正在使用GWT,所以Vaadin应该是好的。

在这里,在Vaadin论坛或irc频道#vaadin @freenode上提出更多问题,也许有人可以给你更多理由为什么或为什么不使用Vaadin。


#2 热门回答(119 赞)

经过近一年的时间开发一个不那么庞大的GWT应用程序,使用我从上一个Google I / O中学到的所有最佳实践,如MVP,EventBus,CommandPattern等。我从内心深处说出这一点:经过几天的努力为了让我的团队和客户在技术上和视觉上都想要的方式工作,即使在UiBinder发布之后,Vaadin就像隧道尽头的灯光一样来到我身边。

在为命令模式编写了将近一千个样板操作,另外一千个演示者和视图以及另外一千个事件处理程序等之后。不必处理这些类中的近75%并且仍然保持良好的模式方法(appfoundation add-on),一点网络开销是可以接受的。使用Vaadin,开箱即用,你可以获得良好的小部件,分页,数据绑定,完美的布局。这一切都是为了什么?服务器端的内存消耗量更多。

我想我可以说这是可以接受的,因为我没有建立下一个Facebook或其他东西。我仍然可以为每台中型服务器处理数千个并发用户,同时保持低延迟往返。

使用Vaadin,我可以使用几乎一半的代码行构建一个不错的应用程序,但应用程序似乎仍然更加完整。 :-)

!更新2011年2月23日:我无法强调应该如何了解每个框架的局限性。 Vaadin也不例外。应该知道Vaadin抽象出任何形式的HTML或JavaScript。此外,生成的HTML非常繁重,你应该自己处理历史状态更改。因此,在构建项目时要注意这些开销。


#3 热门回答(60 赞)

免责声明:我与以下提到的图书馆没有任何联系,但碰巧知道我的方式很好。

和你一样,在考虑用于新项目的堆栈/框架时,我偶然发现了这篇文章。我对Play有一些扎实的经验! (好吧,在Scala,但这不相关)但是令人信服的小部件和它们与服务器端的无缝集成Swing就像开发一样激起了我的兴趣。那是在2010年末,当答案说服我试试Vaadin时,我决定回来写下我想在这里读到的答案,特别是。因为这个问题今天仍然有用。与此同时,Vaadin从第6版到第7版,需要一些显着的改进,Play!从版本1到2,我(一个小团队)用两个框架完成了少量成功的项目。

我认为比较有趣,因为两个框架

  • 在JVM上运行,可以利用其丰富的生态系统
  • 对于Web应用程序的处理方式以及开发人员应该关注的内容,以及
  • 在较小程度上,它们与Java EE的关系。
    赞成
    在一句话中,如果你发现将桌面应用程序移植到浏览器同时完全从基础HTTP请求/响应机制中抽象出来的想法,那么Vaadin可能是你制作Web应用程序的候选者。对于那些最喜欢HTML和JavaScript低级别的人来说,它的Swing编程方法可以轻而易举。对你的应用程序的新请求确实正在启动一个新实例,其余的流程由你和你的逻辑决定。链接恢复到良好的旧按钮导航,你可以使用许多内置模板自由组合你的布局,而无需调整HTML或CSS。 API通常是非常一致的,并且公认有充分的文档记录(Book of Vaadin是强制性的阅读。尽管很多东西都很容易获得,例如将bean绑定到组件和验证器,......)。这些小部件具有良好的整体跨浏览器兼容性,从而确保应用程序在各种客户端上的一致行为。
    现实检查
    我们在开发和测试我们的Vaadin应用程序时度过了愉快的时光。当我们发布第一个版本并开始收集反馈时,事情变得更加清晰和细致。我们意识到我们实际上已经在一些基本方面存在偏见,即:
  • 在201x年代,大多数用户使用网络的历史悠久,其中很少有人实际上不再使用桌面应用程序。这里的关键点是浏览器使用超文本链接标准化UX交互,后退,前进和重新加载按钮,无处不在的选项卡和有时窗口,以及大多数操作触发HTTP请求并等待响应的基本思想。这是网站所遵循的隐含合同。因此,当用户抱怨他们不能像以前那样使用后退/前进按钮,或者标签不能按照预期的方式工作时,我们不应该感到惊讶。我们同意了。我们破坏了隐形合约绑定用户和浏览器。实际上,我们自己隐含地没有使用我们的浏览器和Vaadin应用程序,就像我们在任何其他网站上使用它一样。当然,你可以回到前面提到的书籍并仔细阅读使用URL片段复制Web导航体验,你会发现它实际上比预期更多,因为Vaadin应用程序是有状态的。而且,与Play相比,MVC或MVP范例只是松散地强加给开发人员!几乎没有其他选择。不要掉以轻心,但是在页面更改后,你的大脑会被用于亮白屏幕,只需几秒钟。当用户点击并希望获得新页面时,浏览器通过显示沙漏(或其变体)来确认。使用AJAX,请求被置于幕后。今天有些小型,几乎是外科手术的AJAX罢工已成为常态,但尚未针对主要的UI更新。
  • 有状态的应用程序带来了他们的挑战......和麻烦。负载平衡(如果你担心)一个更复杂。事务的概念完全不同,因为Vaadin会话跨越了许多请求,因此与基于REST的方法形成鲜明对比,但在UX方面却相对较短。实际上,用户回到他们几小时前开始完成任务的表格并不少见。从理论上讲,这也可以与Vaadin一起工作,但是你必须长时间保持会话活动,并且内存一直被阻塞,并仔细考虑这将会扩展w.r.t.并发用户。有状态页面对用户来说也更难分享,更不用说书签了(假设你处理了URL片段)。
  • 最后,我们分享了一般用户界面的印象服务器上的逻辑更加缓慢。当然,你可能总是创建一个加载了客户端JavaScript的小部件来减少往返次数,但你不可避免地必须在服务器上进行一些UI更新。 JS在我的体验中已经非常沉重,并且在移动设备上的体验较少(我知道TouchKit,但仍然是:移动设备上的HTML5应用程序并没有为我剪掉它)。另外,请记住,在发布请求后UI线程处于活动状态(即客户端的用户操作,类似于拉动UI更新),并且你可以通过各种侦听器访问它。但是,从后台线程更新UI更复杂(例如,推送更新)。 Vaadin 7改善了这方面的情况,特别是在生成相对较轻的HTML时。通过简单地打开HTTP压缩,可以明显改善UI反应性。
    结论
    所以我们暂停并想知道我们在Vaadin方法中发现了什么如此吸引人。最初的开发是一个相对平稳的过程,产生了快速的结果,但重新设计一些概念以适应Web用户体验的期望给了我们一个强烈的游泳逆潮流的印象。我们的结论是,从HTTP请求/响应机制中抽象(模糊?)的诱惑理念被证明是一把双刃剑,揭示了Web应用程序和桌面应用程序之间的真正阻抗不匹配。

我们强烈认为应该采用它的工作方式187763401而不是假装网络是另一层,而这开始于拥有以URL为中心的应用程序**(由Rails / Django / Play强加)。你可能听说过有人说数据超过应用程序。现在,数据由URL资源引用,因此可以安全地说URL比数据更长​​。毕竟,他们是人们的书签,不是吗?因此,基本的关注点分离也应适用于此级别。这可能就是为什么网络首先变得如此受欢迎。因此,我们重新访问我们的应用程序,以便围绕中央控制器更好地构建它,以响应不同资源路径上的Playmade。

目前我们正在维护我们的Vaadin应用程序,但由于这些限制和基本范式的转变,我们不会用它开始新的项目。然而,那些团队建立了一个技术上连贯,有凝聚力且记录完备的360°Java Web框架,需要对Web内部工作知之甚少。从好的方面来说,他们甚至还通过销售咨询服务的公司支持他们的框架。我很感激这次经历以及它如何重新评估我对网络应用程序的看法。我将密切关注它的发展,但我们肯定需要更多的控制和粒度。

希望有一天Vaadin会从整个Servlet架构中解放出来,它依赖于它拥有自己的HTTP服务器。更好的是MVC设计更深植于框架中。但在可预见的未来,这似乎不太可能,因为它似乎在经验丰富的企业Java大猩猩中找到了一个利润丰厚的利基,他们只是发誓EE。闪耀。

TL; DR:我认为Vaadin忽略了Webapps的重点,更重要的是,它们应该如何表现。这是程序员接受网络以及用户如何与之交互的时间(即后退按钮,重新加载按钮,标签和书签)。 Web应用程序越接近HTTP请求和语义(动词),就越有可能匹配用户期望。这是关键。

编辑:如果你有任何Python经验,我强烈建议你尝试使用Flask来获得以网址为中心,基于REST的Web应用程序编程。

编辑2:如果出于任何原因你觉得你必须使用类似全栈的Vaadin框架,那么试试Meteor吧。它是一个基于JavaScript的(前端和后端)框架,在Node.js上运行,通过WebSocket进行异步通信(因此延迟比请求/响应更小),默认情况下它是被动的。在流星中已经解决了我在Vaadin中不喜欢的一些事情。例如,UI更新的逻辑在客户端上运行,这使得它比Vaadin更具响应性。 JavaScript和Java社区中的人们并没有多少交叉,但是当我第一次听到它时,与Vaadin的并行立刻让我感到震惊。它目前在社区中享有相当大的动力,其原因类似于使Vaadin流行的原因,即。能够制作类似桌面的Web应用程序。如果你也意识到Java在未来的网络应用程序中并不是很重要,或者如果你厌倦了那些长时间的部署周期,那么就应该试一试。但在将整个应用程序绑定到一个库之前要三思而后行。