我们正在尝试为Web应用程序选择用于客户端开发的框架。这些是我们申请的关键点。
1）富文本应用程序，用户在客户端中执行许多活动。
2）我们正在寻求使用Java技术进行开发
3）服务将以云计算提供。
4）需要移动支持。
5）可扩展性也是一个主要问题。
我在线观看了很多文档和信息以及此视频http://twit.tv/show/floss-weekly/187，现在已经离开了 Vaadin 和普通GWT 。我在GWT的开发方面有一点经验，但在Vaadin中没有（我只在Vaadin中编写了几个示例程序）。请帮助我理解一些事情。
1）如果我必须在Vaadin中编写一个新的小部件，那要完成它是多么容易或困难？
2）Vaadin小部件或概念是否存在明显问题，可能会阻碍任何应用程序？
3）如果明天我们决定切换回GWT，那么鉴于Vaadin适用于所有服务器代码逻辑，这是否可行？
4）Vaadin方法是否每次都关注部署在云上的应用程序服务器？
5）最后但最重要的是，论坛支持和未来发展如何？
非常感谢。请注意，我已经阅读了很多关于这些讨论的文章和链接，但是至少在某些时候对这些东西有真正经验的人感到很高兴。再次感谢。
答案 0 :(得分：2)
我认为你应该根据每个人的架构做出这个决定，因为这是他们差异最大的点。
Vaadin遵循Half-Object Pattern，因此与Eclipse RAP（和ZK）相比，与GWT相当。您基本上有一个服务器应用程序，您可以从浏览器控制它。想象一个简单的Button，它的状态在服务器上保存，在浏览器中你可以看到它的表示。每次Button的状态发生变化时，都必须与服务器通信才能更新它的状态。所以每个小部件都适用。
我必须说我对Vaadin或RAP没有太多经验，但想象一下，当你有许多小部件和许多同时使用它们的用户时，你的服务器将需要处理多少个状态。这可能不是云中的一个大问题，但可能在资源有限的传统服务器上。
那就是说，你可以想象这种方法对移动设备也不是很友好。每次状态更改都会导致服务器往返，但在移动设备上，您可能连接不良甚至根本没有连接。 在这里，我显然更喜欢纯GWT，因为它可以完全在浏览器中运行，也可以“离线”使用。
你的另一个问题是关于小部件。确实，GWT不提供与Vaadin一样多的小部件，但是有很好的Widget库来补充库存GWT小部件。问题是，你不能从Vaadin开始，然后决定切换回GWT，因为用Vaadin编写的Widgets不能用于纯GWT。但另一种方式是工作，GWT Widgets和自编的小部件可以在Vaadin中使用。
我建议从简单的GWT开始，用UiBinder编写自己的Widgets，这非常容易。如果您觉得要使用一些更复杂的小部件，请查看小部件库，如GWT-Bootstrap或Sencha GXT，它们与纯GWT非常相似。
答案 1 :(得分：2)
现在剩下Vaadin和普通的GWT。
Vaadin 7和Vaadin 8（现在称为Vaadin Framework）都是围绕Google Web Toolkit (GWT)的基于Java的包装器。
您可以为业务逻辑和UI创建编写纯Java代码。此Java代码在Java Servlet web container的服务器端JVM中运行。当Vaadin使用GWT自动生成必要的HTML，CSS，JavaScript，DOM，AJAX，XML和JSON，WebSocket和Push代码以在用户的客户端Web浏览器中呈现Web应用程序的用户界面时，魔术就发生了。
因此，服务器端使用纯Java，客户端端使用纯Web标准技术（客户端上没有Java）。
Vaadin 10（现在称为Vaadin Flow）用新兴的Web Components标准技术代替了GWT的内部使用。新一代是Vaadin的主要重写，尽管其目的和许多概念，例如data-binding保持不变。
通过利用Web组件技术，应该更容易构建Vaadin窗口小部件。而且，将未明确为Vaadin设计的现有基于JavaScript的组件提供给服务器端Java代码应该相对容易。这就是Web组件的重点：制作可在各种Web框架工具中使用的基于Web的小部件。
尽管Vaadin Ltd.十分高兴和自豪地发布了Vaadin 10 Flow，但他们仍然致力于Vaadin 8 Framework。 Vaadin 8正在积极开发中，其路线图计划至少要持续到2022年。
富文本应用程序，用户可以在客户端执行许多活动。
如果您用字体，颜色等表示“富文本”，则应研究RichTextArea小部件bundled with Vaadin 8并检查Vaadin Directory以获得其他附加组件。该小部件并未移交给Vaadin 10 Flow，但是如上所述，Web组件的使用可能使其他现有的此类工具可用于基于Java的Vaadin应用。我看到了one already in beta。
如果您的意思是具有企业级可靠性的专业外观，面向业务，桌面样式的Web应用程序，那么这就是Vaadin的目的。
我们正在寻求使用Java技术进行开发
那是Vaadin的 raison d'être：编写纯Java来利用Java工具和库的广阔生态系统，同时具有安全性，性能和可靠性的所有优势。时间使用网络标准技术在网络浏览器中自动呈现您的应用。
需要移动支持。
Vaadin的小部件集合已经发展为支持触摸表面手势。
Vaadin Ltd公司以前提供了一个特殊的移动支持程序包，称为 Vaadin Touch 。常规Vaadin小部件中对触摸手势的内置支持使该软件包过时且不必要。
服务将在云中提供。
可伸缩性也是主要问题之一。
您基于Java的Vaadin应用程序确实存在于服务器端的JVM中。每个当前用户由会话对象表示。浏览器中出现的所有用户界面小部件在服务器上的Java对象中都有一个对应部分。您可能会在服务器上的其他Java对象中保留更多数据和功能。您可能也从该服务器端调用JDBC或Web服务等。
因此，所有这些都会占用服务器上的内存和CPU周期。您确实需要了解您的程序在进行缓存并将其他负担加到服务器上。用户之间共享的任何资源都必须是线程安全的，因为Java Servlet环境在设计上是多线程的。
可能需要强大的服务器硬件（内存，内核），具体取决于应用程序的具体情况。或者，如果您真正拥有一个拥有大量用户的大型应用程序，则可能需要多台具有粘性会话负载平衡的服务器。
Vaadin Ltd公司已经模拟了Vaadin应用程序的使用，该应用程序支持数千个同时进行的用户会话。您可以联系他们以咨询您的具体情况。
尽管可伸缩性是要考虑的问题，但不要一味得出结论。仔细考虑，并做一些实验。
如果我必须在Vaadin中编写一个新的小部件，那么完成它有多么容易或困难？
在Vaadin 8中，您确实可以创建自己的小部件。但是，这样做需要学习GWT的用法。确实可行，从Vaadin Directory中数百种已发布的加载项中可以看到。但是仍然需要认真的工作。 Vaadin Ltd.提供了有关此方面的培训。
在Vaadin 10 Flow中，Web组件的使用应该使您自己的窗口小部件的创建更加容易。查看this starter project免费提供的入门指南。请参见教程Creating A Simple Component Using the Element API。在Vaadin 10 Flow中创建小部件的关键概念：
Vaadin窗口小部件或概念是否存在任何明显的问题，可能会阻碍任何应用程序？
不确定您的意思。我建议通读出色的Vaadin教程和手册。它会引导您使用Vaadin中的各种功能。
Vaadin在桌面应用程序中使用了其他快速应用程序开发环境，因此对我来说一直很有意义，适合我的思维方式和处事方式。
对于Vaadin Flow，要知道Web组件仍然是新的，并且有些前沿。 Web组件实际上是技术的集合。并非所有浏览器制造商都完全支持所有这些功能。因此，仍然需要一些填充料。
Vaadin Flow还利用了最终到达CSS的这对现代页面布局功能： Flexbox 和 Grid Layout 。
只有最新版本的浏览器才接近对所有这些功能的良好支持。有关详细信息，请参见CanIUse.com。
Vaadin的目的之一是填补各种浏览器的不同版本之间的空白，以使我们使用Vaadin的开发人员与世隔绝。因此，在某些浏览器中您可能不会遇到问题，但是可能再次出现。
此外，Vaadin Flow并不完全具备Vaadin 8的所有功能。有些正在开发中，有些正在计划中。
结果：如果您希望尽快发货，并且不能坚持要求用户更新到最新的浏览器，请使用Vaadin 8而不是Flow。
如果明天我们决定只改回GWT，考虑到Vaadin与所有服务器代码逻辑一起工作，那可行吗？
如果您想使用GWT，并且想用Java编写该服务器端逻辑，那么Vaadin 8 Framework是您的理想工具。我看不出您将如何离开Vaadin。
但是，如果您确实离开了Vaadin，您将不再具有将浏览器中的GWT与服务器上的Java代码连接起来的粘合剂。 Vaadin为您提供的就是这种胶。当然，您可以编写Java后端业务逻辑以直接不了解Vaadin。实际上，Vaadin Ltd为此目的提供了基于Maven的多模块原型。 backend模块保存您的业务逻辑和数据库访问（等）代码，与包含面向Vaadin的代码的ui模块分开。
使用Vaadin每次访问服务器的方法是否对部署在云上的应用程序有所关注？
您将需要进行一些实验和分析，以查看特定应用程序所需的内存和内核。 Vaadin可能如上所述需要服务器资源。
但是从技术上讲，云部署没有任何技巧或技术限制。在JVM中仅运行纯Java代码。任何可以运行Java Servlet web container的东西，例如Tomcat，Jetty，Glassfish / Payara，WildFly / JBoss，这样的东西都可以运行Vaadin应用。
如果您担心网络流量，是的，这里有流量。当用户使用诸如单击按钮或在字段中输入数据之类的小部件时，系统会通知您的服务器端Java应用程序，以便您的应用程序可以使用业务逻辑进行响应。因此，这意味着频繁的网络遍历。
您确实可以选择在不需要时不立即通知服务器端。这样，您就可以控制部分流量。例如，您可以选择是在字段中输入文本时，还是在击键之间使用every single keystroke时，还是仅在{{3}之后，通知服务器端occasionally such as a pause（并作出反应） }。请参阅手册中的[配置价值变更事件的粒度]（user has completed entry部分。
从Vaadin开始，我确实担心Internet性能会出现问题。但是我可以说，根据我自己的经验，我发现这对我来说不是问题，对此我感到非常惊喜，真的很惊讶。例如，在美国，只有一台Mac mini装在威斯康星州的可乐中，通过运行Vaadin 7或8应用程序的非常快速的Internet连接，对访问西雅图，佛罗里达州和加拿大的家庭DSL和有线电视连接的客户几乎立即做出反应。从香港访问时，只有一点点延迟，通常在数据输入应用程序中是无法察觉的。
当然，您的里程可能会有所不同。我上面的示例是一台专用计算机。相反，云提供商以CPU可用性以及网络延迟或延迟的波动而臭名昭著。
最后但最重要的是，论坛支持和未来开发者如何？
https://vaadin.com/docs/v8/framework/components/components-textfield.html似乎是一家非常健康的开源公司。他们销售附加产品，支持，咨询和培训。该公司一直在成长，雇用了更多员工，并在其总部设在Vaadin Ltd（赫尔辛基图尔库）的海外总部（美国，德国）建立了办事处。
各种Vaadin产品的开发工作非常繁重，有许多增量版本，预发布版本，并且很快就会推出Finland。定期为他们的发展计划发布路线图。他们还在Long-Term-Support versions中提供有关业务和技术问题的定期更新。
Vaadin Ltd公司拥有非常活跃的their blog。他们的员工和其他用户也都积极使用Stack Overflow。
答案 2 :(得分：1)
如果你想要未来的开发，请诚实地使用jsf。它不是最好的选择，但你至少容易受到死亡框架的攻击。</ p>
在我们的项目中，我必须使用Vaadin，我不会这样决定。我更喜欢ZK（http://www.zkoss.org/）或GWT。
关于你的问题，我可以回答。
我个人认为您必须深入思考该框架以及它是否符合您的需求。 在选择一个大框架之前，请考虑一下，如果你愿意的话 - 服务器端编程（ZK，Vaadin，） - 服务器和客户端（GWT） - 使用标记语言和逻辑（JSF）
您的环境设置是什么，例如应用程序服务器，数据库等？
即使Vaadin是一个好产品，如果我可以自由选择，我也不会使用它。
侨
答案 3 :(得分：0)
最好选择客户端技术（例如HTML，Javascript）或更高级的UI框架（例如ReactJS，Angular），而不是服务器端技术。服务器端框架的性能很慢，并且很难针对浏览器问题进行调试。