我是否设计了基本的框架HTML,并通过Java代码插入组件和操作从那里开始？
通过使用java代码设计细节,计划将整个东西构建为java程序？
还是有一种我不了解的更好的方法？
除此之外,维护代码有多容易或复杂？
我是GWT的新手,我知道非常基础.
提前感谢您的意见.
我在 GWT/Seam 项目工作一年后的见解。我认为没有现有的网站意味着您可以从头开始。如果有的话，我建议您尊重您的遗产，并通过有选择地将 GWT 小部件插入现有 html 页面的特定位置来改进它（更多详细信息请参见此处）。
我们的开发过程大致可以概括为以下步骤（反馈循环、站立会议等省略，你知道的）：
功能请求：包含所需功能的高级描述
线框：一个高级用户界面，可以给最终用户留下关于如何向最终用户提供功能以及如何将其集成到现有应用程序中的第一印象（没有任何附加功能）
最终设计：由我们的设计师创建的新功能的最终扩展 UI（仅 Photoshop，无 html 骨架，无 css）
实施和测试：我将重点关注实施并描述它在一年内发生的变化
我们从 GWT 1.6 开始我们的项目，它缺乏UiBinder的任何支持。所以决定是 1) 使用 GWT（即 java 代码）构建我们应用程序的整个客户端，或者 2）使用 JSF 构建我们的页面（因为我们使用的是 Seam）并使用 GWT 小部件扩展它们。我们决定采用第二种选择，主要是因为我们喜欢将大部分状态推送给客户端并让他们进行处理的想法。凭借我们在 Java 开发方面的强大背景，一切都在 Java 中进行，这是有希望的。
实现业务逻辑一点也不麻烦。花费我们最多时间的是构建 UI：用 java 编写页面布局和样式设计既耗时又容易出错。最终 html（基于第 3 步的设计）和 GWT 小部件之间的差距太大。
切换到 UiBinder 是 GWT 2.0 发布时我们采取的第一步。由于无论如何我们都必须重新编写大部分客户端代码，所以我们也采用了MVP 模式。此后，生产力显着提高：一名开发人员正在实现业务逻辑（主要是 MVP 的演示者部分），而另一名开发人员则忙于构建视图部分（.ui.xml 和小部件）。单元测试也变得更加容易，因为主要功能现在在演示者部分中很好地分离（并且 GWTTestCase 是过去的一部分）。
我们目前正在做的下一个主要步骤是从我们自己的 MVP 实现切换到更详细的实现（即gwt-platform）。这个决定背后的理由：通过 GIN 进行 DI（依赖关系清晰，代码变得更清晰），对浏览器历史记录的良好支持（我们鲁莽地忽略了它 - 一个巨大的错误！），代码分割支持，异步调用的命令模式等等。
经过一年的经验，我的结论是：UI 部分使用 UiBinder，并采用干净的 MVP 架构。学习曲线可能很陡峭，但沿着许多 GWT 开发人员所走的道路走下去肯定会花费您更多的时间。
...我的 2 美分:)