Vaadin 7发布，内嵌GWT组件

Vaadin发布了基于Java的web应用框架的第七版，Vaadin 7平台是该框架自2009年以来首次重大更新。

Java web应用开发者可以发现，Vaadin 7与Wicket、JSF和Google Web Toolkit（GWT）等其他框架相比，有显著的相似性和不同点。在许多方面，Vaadin和Wicket相似；主要的区别在于Vaadin并不采用HTML模板。类似的，JSF和Vaadin之间的相似点在于都是服务端的框架，然而Vaadin应用是用纯Java编写的，无需XML配置文件。

Vaadin小组作为GWT指导委员会成员已经有五年多了，Vaadin 7现在把GWT作为核心组件包含进来。在2012年6月发布的博客中，Lehtinen建议“现在，任何使用GWT构建应用的人都可以简单的通过替换项目中的jar包来迁移到Vaadin。”使用GWT与传统的Vaadin应用相比有一些优势，这要取决于用例。GWT应用可以离线操作，支持大量（一万以上）的并发用户，服务端的状态不是必须的，并且有较低的延迟；然而，传统的基于UI的Vaadin运行在Java服务器或门户上，这对于Java开发者来说似乎更简单一些，因为它可以完全采用Java编码。

Vaadin团队除了引入GWT外，还实现了65个新特性。该框架的FAQ页面提到，Vaadin 7是一个遵守Java EE标准并采用了桌面UI编程模式的单jar文件实现，框架还得到了来自开源社区超过4万活跃注册用户的支持和反馈。

InfoQ采访了Joonas Lehtinen（Vaadin.com的CEO），来挖掘更多关于Vaadin 7的信息.

InfoQ：从新用户的角度，你能在最新发布的Vaadin中列举出5至6条最有用的特性么？

Joonas：我最向大家推荐的主要特性列在这个列表里基本都覆盖了：https://vaadin.com/vaadin7。

除此，我推荐的前五大特性如下：

1. 完全GWT的嵌入。这样我们可以更容易的支持整个包，并在你的应用中利用Google强大的Java-to-JavaScript编译器。
2. Widget扩展允许在已有的widget上像独立的扩展那样添加功能。更多信息请访问：https://vaadin.com/wiki/-/wiki/Main/Creating%20a%20component%20extension。
3. Sass编译器引入了期盼很久的主题模块化。
4. 重新设计的布局引擎使用浏览器原生布局计算来替代JavaScript计算。这彻底的降低了回流量，使得布局速度更快。额外收获是，我们现在支持全部的CSS。
5. 重新设计的windows API使Vaadin应用更像web应用，简化了http请求和网页访问。

InfoQ：“GWT的未来-2012年度报告”中提到SmartGWT、GXT和Errai扩展了GWT，而Vaadin补充了它。你能就此跟我们详细说说么？

Joonas：GWT编程模型有两个级别的抽象：

1. UI由Java编写，并编译成JavaScript。
2. 原生JavaScript。SmartGWT、GXT和Errai本质上只是在由GWT定义的编程模型下提供了更多（非常好用的）组件和帮助。

Vaadin基于GWT的编程模型添加了服务端的Java编程模型。这是更高一级的抽象，通过降低实现代web应用的软件层级数来加快开发。用GWT，需要构建UI层（浏览器内部）、RPC，还有UI服务（服务器内部）和业务逻辑（服务器内部）。用Vaadin，只需要服务端UI和业务逻辑层。这本质上削减了开发应用UI所需要的近一半代码量。如果需要更多的灵活性，Vaadin还同时支持Java和JavaScript来编写客户端UI。

InfoQ：使用GWT的开发者们抱怨说最近几乎没有关于GWT的新书。基于此背景，你怎样来解释Vaadin之书的重要性？你计划如何维护和加强当前的预览版？

Joonas：我们从2007年开始维护Vaadin之书，这已成为一项巨大的任务，但我们感到顶级的文档是任何框架的一个非常重要的组成部分。如果一个特性没有被文档化，那么它对于别人是无用的。

Vaadin之书的第一个完整版将于三月初提供免费下载。此后我们每次在框架中添加新特性时，都会将其继续更新维护到Vaadin之书。

InfoQ：如果Vaadin开发团队在分发他们正在维护的Vaadin的GWT版本，他们将计划怎样内联标准的GWT？

Joonas：我们维护的可用的GWT版本源码地址如下：

https://github.com/vaadin/gwt。

Vaadin框架的全部资源地址如下：

https://github.com/vaadin/vaadin。

我们发布的版本只有Vaadin框架（而不是GWT），但是既然Vaadin包含了GWT，它可以用来作为GWT发行包的一个替代——即使你只需要客户端的功能，这样操作也无妨。

如果你想要从架构的视角来理解GWT和Vaadin关系，请参考：

https://vaadin.com/blog/-/blogs/vaadin-7-application-architecture。

InfoQ：你们网站上的FAQ区有一个段落谈论“什么时候不宜使用Vaadin？”。企业项目规模的大小如何影响是否应该采用Vaadin的决策呢？

Joonas：有时是这样的：项目越大，Vaadin开发者受益越多。构建非常小的应用对于任何框架来说都比较容易，包括Vaadin。

InfoQ：页面“谁在使用Vaadin”显示了芬兰占了34个案例，美国占了6个案例，在列表上紧随其后。什么是Vaadin案例？170个国家的开发者使用Vaadin，做什么能够增加这些国家的Vaadin案例数量？

Joonas：我们的案例地图是非常不完整的。当我们开始收集“谁在使用Vaadin”列表时，我们只是四处打听到了一些使用Vaadin的案例。我们的总部在芬兰，所以我们在本地网络中找到了一些非常优秀的案例。

我们想要列出来自全世界的展示。我们鼓励任何使用Vaadin并且做出优秀作品的人来联系我们，并把作品加入这个列表中。

InfoQ：有没有非JVM web应用的框架当前能和Vaadin竞争的？如果有，你能介绍几个么？

Joonas：我们是非常JVM中心化的，每个在这里构建web app的开发者同时也在使用web平台，因此最大的竞争来自于JavaScript框架。虽然对一些项目来说，将前端和后端团队分离是有效的，但因分离造成的额外开销对于产业空间上的大多数项目来说并不必要。

InfoQ:有的专业的开发者也许打算为Vaadin的底层代码做些贡献，你们的团队怎样操作来遴选符合条件的贡献者？

Joonas：大多数对Vaadin项目的贡献都是插件。这个门槛很低——任何人可以贡献到Vaadin的目录，地址在：http://vaadin.com/directory。

如果想要给Vaadin核心框架贡献代码，则应该通过发行跟踪系统提交补丁程序，地址在：http://dev.vaadin.com/wiki/SubmittingBug。核心开发团队中的一员会收到补丁程序，评估测试，然后提交到我们内部的Gerrit审查系统，以保证至少能被我们核心团队的另一名开发者阅读和评估。补丁程序经常在这一流程中被部分重写至少一次。所有的贡献者都被要求签署一项贡献协议。

我们期望通过公开我们的Gerrit系统来使这一流程更简单些，并在以后开始接受来自GitHub上的拉从请求。

InfoQ：我们从你们博客上发表的路线图中获悉，Vaadin框架打算按照稳定的开发流程。这是说未来的流程规范化了么？它是什么样子的呢？

Joonas：我们最近更新了我们的开发流程——部分原因在于Vaadin 7的延迟。我们打算在继续进行现行开发的同时做些非正式的研究项目。我们希望这将使我们能更好的评估路线图，核心流程包括月度的路线图会议——我们将在未来的三个月将所有的产品路线图确认下来。内部流程作为一个整体如下图所示：

图表：Vaadin的开发和发布流程

开发周期在一到两周，这个周期取决于产品的特性。当我们开发到差不多可以对外展示一些东西的时候，我们会进行内部的开发评审，如果可以，我们会发布alpha或beta版，以来在开发流程中得到较早的反馈。

查看英文原文：Vaadin 7 Arrives with GWT as an Integrated Component

感谢杨赛对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至[email protected]。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。