vaadin_为什么我仍然爱Vaadin

vaadin

事情按顺序出现很有趣。最近，在三个不同的场合，我偶然发现了一些问题，询问人们使用哪些前端技术。每次，我的答案都是Vaadin 。不幸的是，某些地方（例如 Twitter）太局限了，无法深入解释我的回答。在此博客中，我没有任何限制。

一句话，Vaadin是一个框架，可以使用纯Java或与此相关的任何基于JVM的语言来创建GUI 。一个用Java开发，并且框架通吃其余的工作：这包括客户端代码的生成，并在浏览器的客户端代码和服务器上的后端代码之间的通信。

使用Vaadin的好处

该体系结构具有以下优点。

易于入职

Vaadin的第一个也是最重要的特征是，不需要了解其他技术。让我们考虑一下由REST API和JavaScript前端组成的“标准”应用程序需要哪些技能：

Java
Jakarta EE API，即 Servlet和JAX-RS或Spring框架
REST原则
AJAX用于浏览器与服务器之间的互通
HTML
CSS
JavaScript（或TypeScript）
一个前端框架：最受欢迎的竞争者是Angular ， Vue.js或React 。

这不少于8种完全不相关的技术。而且我特别慷慨：我将省略所有其他JavaScript库以及构建前端工件所需的构建工具。但是，要从TypeScript转换为JavaScript，或从最新的JS版本转换为大多数浏览器支持的版本，则需要后者。

使用Vaadin时，该列表将仅限于Java ...和Vaadin。

如果您读了这篇文章，您可能会认为这并不是一个巨大的好处，因为您被10倍的开发人员所包围（无论如何）。我的经验截然不同：我作为承包商工作了15年以上，为许多不同的客户服务。大多数开发人员都是普通人，乐于工作9到5，然后回到家过上自己的生活。他们既无意愿也无时间在办公时间之外学习另一种技术。

在需要在办公时间内进行培训的前提下，更少的技术意味着更少的培训时间，以及更多的时间用于开发应用程序。

没有整合阶段

Vaadin提供的简单性还有其他好处。如果一个应用程序的架构分为通过REST API进行通信的前端和后端，则有两种策略可以组织一个团队：

每层开发: 该策略基于两个专业团队，即前端团队和后端团队。它们在自己的堆栈中非常出色。它们都在各自的堆栈中并行工作。在最慢的工作完成后，他们将各自的工作整合在一起。

我的经验表明，在并行阶段，这项工作很快就完成了。相反，集成阶段需要很多时间。我的经验是，它占用了第一阶段所花的时间-实际上使开发时间加倍。最糟糕的是，包括项目经理在内的大多数团队都低估了第二阶段。
每个用例的开发: 此策略基于全栈开发人员。这种开发人员可以在前端和后端都可以工作。每个开发人员都被分配了一个用例/用户故事，然后需要了解它周围的业务，然后才能够开发从GUI到数据库的整个流程。

我个人认为，全栈开发人员是管理人员提出的使开发人员可互换的概念。这样，任务计划对他们来说变得非常容易。无论如何，让我们承认这样的独角兽确实存在。如果一个人熟练掌握许多技术，那么他们应该有时间学习它们。这使我回到了上面提到的观点：大多数开发人员的工作都离不开生活。当然，有极客，但是在这种情况下，必须相应地支付。不幸的是，普通公司预算不足：他们可能负担得起，但没有一支完整的独角兽团队。

在这方面，Vaadin允许非摇滚明星开发者使用^第二种策略来开发应用程序。它还使他们可以将更多的时间花在业务方面，而将更少的时间花在技术问题上。

后端与前端开发之间的并行化

默认情况下，Vaadin允许不兼任图形设计师的开发人员开发外观可接受的GUI。但是，碰巧产品负责人有要求-有时甚至是预算-来定制设计。

使用传统方法，设计人员可以使用HTML和CSS来实现。他们将设计特定HTML模板和CSS类。然后，将要求开发人员使用它们。

如果需求在中途发生变化，则开发人员将需要停止工作以集成设计人员所需的更改：开发人员的工作流程与设计人员之间的依赖性很高。诸如JSP，JSF和Thymeleaf之类的某些技术允许开发人员按原样重用设计师的工件。在这种情况下，两者都需要处理相同的工件。当人们不能完全掌握上游变化时，Git合并冲突总是很有趣。

Vaadin引入了两个抽象来分离开发人员和设计人员的工作：主题和组件。

主题是CSS（和Sass ）的集合。因为Vaadin生成HTML，所以设计人员知道所需的结构，因此可以相应地设计CSS。

默认情况下会应用Lumo主题。开箱即用地提供了另一个主题“ 材料 ”。生态系统提供了其他主题，每个主题都可以作为JAR使用，只需要添加到类路径中即可。设计师也可以创建自己的设计。

请注意，可以通过一个简单的方法调用来切换主题。
组件既有HTML模板，又有在服务器端代表它的Java类。这样的组件可以将其他组件放置在布局中。 Java类将它们作为属性进行管理时，HTML模板负责布局。这样，开发人员在Java类（或使用它的任何其他类）上的工作与设计人员在模板上的工作完全相互隔离：它们可以完全并行执行。

专为“业务”应用程序而设计

最后，Vaadin的核心是开发业务应用程序。

在UI端，组件包括经常在此类应用程序中使用的小部件，例如字段，组合框，表单，表格等。
大多数组件显示数据。这些组件的设计在组件及其数据之间引入了抽象。有不同的说法：
1. 对于标量值，例如在字段中显示的电子邮件
2. 对于集合值，例如 组合框中显示的国家/地区列表
3. 二维值例如表格数据显示在一个表

我听说反对使用Vaadin的论点

在所有这些年中，我已经听到很多反对使用Vaadin的争论。他们大多都归结为以下两个。

“但是规模吗？”

您可能想知道这个问题是在会议上显得聪明的10个技巧的一部分（＃6 ）。

更严肃地说，扩展无疑值得一试。Vaadin存储服务器端组件的状态。随着组件数量的增加以及客户端数量的增加，这导致了内存的指数消耗。在这方面，传统应用程序与Vaadin应用程序没有太大区别。

首先，我们需要了解，绝大多数应用程序都是有状态的。但是，它们之间的区别因素在于存储状态的位置 。如前所述，Vaadin将其存储在服务器上。只有两种其他选择：

将其存储在数据库中。我需要详细说明为什么这是一个坏主意吗？
将其存储在客户端上。在客户端上存储与UI相关的数据非常有意义。但是，这里有一个不小的警告：如果打开了多个选项卡，则需要以某种方式在服务器端进行处理。

Vaadin通过在最初呈现页面时放置一个隐藏令牌来管理多个选项卡。当用户与页面交互时，将检查令牌，然后将新令牌再次发送到浏览器。

虽然有超过一万个并发用户，但我可能会开始考虑Vaadin以外的其他选择，低于这个数字的任何事情都是公平的。占所有应用程序的99.99％。

不是API优先

我听到反对Vaadin的另一个论点是它不是API优先的。优秀的软件开发人员/架构师始终会开发API，以允许使用不同类型的客户端：浏览器，还包括本机客户端以及其他服务（内部或第三方）。

不幸的是，我认为这是从众心理。在多个客户端的情况下，API-first是可取的。我从事的大多数业务应用程序只是CRUD应用程序，其上面或多或少地应用了业务逻辑。

但是，如果将来有必要增加客户数量怎么办？亚尼！如果这样做了，请记住，Twitter能够将其完整的信息系统从Ruby on Rails重写为Java：迁移应用程序的GUI层是在可能的范围之内。

无聊

最后，尽管我从未听到过这样的消息，但我相信Vaadin如此不受欢迎或不广泛的原因之一是因为它太无聊了。它已经存在超过15年了，它可以按预期运行，并且围绕它的大多数挑战已经解决。不幸的是，这不适合从事Résumé-/ Hype- / Ego-Driven Development的开发人员。

结论

我在十多年前发现了Vaadin，那是一见钟情。实际上，我立即开始修改它，并尝试将其与我的另一个迷恋者Spring框架集成。

第10版对框架进行了大规模重写。产品管理将其引导到更多的Web功能，例如Web组件，路由的引入等。我相信此举是为了吸引更多Web开发人员。公平地说，我对这些更改并不满意。

但是，这并不能改变我仍然是框架的忠实拥护者的事实。我承认这不像JavaScript框架那样大肆宣传。另一方面，与任何其他炒作相比，开发业务应用程序时，生产率得到了极大的提高。

翻译自: https://blog.frankel.ch/why-love-vaadin/

vaadin