vaadin_为什么我仍然爱Vaadin

vaadin

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

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

使用Vaadin的好处

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

易于入职

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

1. Java
2. Jakarta EE API， 即 Servlet和JAX-RS或Spring框架
3. REST原则
4. AJAX用于浏览器与服务器之间的互通
5. HTML
6. CSS
7. JavaScript（或TypeScript）
8. 一个前端框架：最受欢迎的竞争者是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将其存储在服务器上。 只有两种其他选择：

1. 将其存储在数据库中。 我需要详细说明为什么这是一个坏主意吗？
2. 将其存储在客户端上。 在客户端上存储与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