Biggest GWT Pitfalls?我处于我们选择使用GWT实施的项目的开始/中期。 是否有人在使用GWT(和GWT-EXT)时遇到无法克服的重大陷阱？ 从性能角度来看如何？ 我们已经看到/听到的几件事已经包括：
寻找关于这些项目的任何其他反馈。 谢谢！ 首先，我是GWT的忠实拥护者，但是是的，这里有很多陷阱，但是大多数(即使不是全部)我们都能够克服： 问题：编译时间长，随着项目的增长，编译所需的时间也会增加。我听说有20分钟的编译报告，但我的平均水平约为1分钟。 解决方案：将您的代码分成单独的模块，并告诉ant仅在更改时才构建它。同样，在开发过程中，仅通过构建一个浏览器就可以大大加快编译速度。您可以通过将其放入.gwt.xml文件中来实现此目的：
其中gecko1_8是Firefox 2+，即ie6是IE等。 问题：托管模式非常慢(至少在OS X上)，并且与在编辑JSP或Rails页面之类的内容并在浏览器中刷新时获得的"实时"更改相差甚远。 解决方案：您可以为托管模式提供更多内存(我通常使用512M)，但是它仍然很慢，我发现一旦您对GWT足够好，就停止使用它。您进行了大量更改，然后仅针对一个浏览器进行编译(通常需要20秒钟的编译时间)，然后在浏览器中单击刷新。 更新：对于GWT 2.0+，这不再是问题，因为您使用了新的"开发模式"。从根本上讲，这意味着您可以直接在所选的浏览器中运行代码，因此不会损失速度，还可以进行调试/检查等。 http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM 问题：GWT代码是Java，并且与布局HTML页面的思路不同，这使得采用HTML设计并将其变成GWT变得更加困难 解决方案：您再次习惯了这一点，但是不幸的是，将HTML设计转换为GWT设计总是比将HTML设计转换为JSP页面的速度慢。 问题：GWT需要花些时间来解决，它还不是主流。这意味着大多数加入您的团队或维护您的代码的开发人员将不得不从头开始学习它。 解决方案：GWT是否会起飞还有待观察，但是如果您是一家由您控制雇用人员的公司，那么您始终可以选择了解GWT或想要学习GWT的人员。 问题：与jQuery或纯JavaScript相比，GWT是一把大锤。要使其发生，需要花更多的时间进行设置，而不仅仅是添加一个JS文件。 解决方案：将jquery之类的库用于适合于这些较小，简单的任务。当您想在AJAX中构建真正复杂的东西，或者需要通过RPC机制来回传递数据时，请使用GWT。 问题：有时为了填充GWT页面，您需要在页面首次加载时进行服务器调用。用户在获取所需数据时坐在那里观看加载符号可能会很烦人。 解决方案：对于JSP页面，您的页面在变为HTML之前已经由服务器呈现，因此您实际上可以随后进行所有GWT调用，并将它们预加载到页面上以进行即时加载。详细信息请参见此处： 通过预序列化GWT调用来加快页面加载速度 我从来没有遇到过CSS样式外框，自定义样式或自定义样式的问题，所以我不知道这是陷阱是什么意思？ 至于性能，我总是发现，一旦编译的GWT代码很快，并且AJAX调用几乎总是比刷新整个页面小，但这并不是GWT真正独特的，尽管使用时会获得本机RPC数据包。 JAVA后端非常紧凑。 我们已经与gwt合作了将近2年。我们已经吸取了很多教训。这是我们的想法： 不要使用第三方窗口小部件库，尤其是gwt-ext。它将破坏您的调试，开发和运行时性能。如果您对这种情况有疑问，请直接与我联系。 使用gwt仅填充应用程序的动态部分。因此，如果您与许多字段进行复杂的用户交互。但是，请勿使用其随附的面板。查看您现有的库存设计师提供的页面。找出将包含应用程序控件的区域。将这些控件附加到onModuleLoad()中的页面。这样，您可以使用设计师的标准页面，也可以在gwt之外进行所有样式设置。 不要将整个应用程序构建为一个标准页面，然后再动态构建所有片段。如果您按照我在项目2中的建议进行操作，则无论如何都不会发生。如果您动态地构建所有内容，则将损害性能，并为中型到大型应用程序消耗大量内存。另外，如果您按照我的建议进行，后退按钮将非常有用，搜索引擎索引编制也将如此。
其他评论者也提出了一些好的建议。我使用的经验法则是像创建标准网页一样创建页面。然后切出需要动态变化的部分。将其替换为具有ID的元素，然后使用 我们遇到的陷阱：
最后，请确保使用可以帮助您的编辑器。我使用IntelliJ-它有很多GWT智能设备。例如，如果我尝试使用JRE仿真未处理的类，则会让我知道；如果我为小部件指定了一种样式，而我尚未定义该样式，则代码会散乱地显示红色...或者，当查看CSS时，它将告诉我何时在单一规则。 (我还没有尝试过，但是我知道版本8甚至具有更好的GWT支持，例如使"本地"和"异步" RPC接口和实现保持同步。) GWT 2.0有望在未来几个月内问世，它解决了许多讨论的问题。
Google I / O上的GWT 2.0预览视频 不是"无法克服"，而是一些基本的痛苦。 日期处理：
GWT使用了已弃用的 相关问题示例：
我将在已经提到的几点上添加一些要点：
恕我直言，GWT缺少针对此"线程"中提到的所有问题的开箱即用支持的框架。 我现在正在开发一个项目，该项目使用EXT GWT(GXT)，不要与GWT EXT混淆。有所不同，EXT GWT是由ExtJS编写JavaScript库的公司实际生产的。 GWT EXT是ExtJS库的GWT包装器。 GXT是本地GWT。 无论如何，GXT仍然有些不成熟，缺乏我认为GWT EXT拥有的坚实社区。但是，未来将是GXT，因为它是本地GWT，实际上是由制作ExtJS的公司开发的。由于在ExtJS库上更改了许可证，GWT EXT受到了一定程度的损害，从而减缓了GWT EXT的开发。 总的来说，我认为GWT / GXT是开发Web应用程序的不错的解决方案。我实际上很喜欢托管模式进行开发，它使事情变得简单快捷。您还将获得能够调试代码的好处。使用JUnit进行单元测试也相当可靠。我还没有看到一个强大的JavaScript单元测试框架，我觉得它足够成熟，可以测试企业应用程序。
有关GWT EXT的更多信息：
有关EXT GWT(GXT)的更多信息：
没有我无法轻松克服的重大陷阱。 大量使用托管模式。 我的建议是在库中使用GWT的"本机"窗口小部件，这些窗口部件的功能很接近。 重新搜索引擎索引编制：是的，网站通常不会具有可导航的URL(除非您仅将小部件添加到常规网站的元素中)。 您可以执行历史记录后退/转发功能。 不久前，我在一个项目中一起使用了GWT和GWT-ext。随着Web开发的进行，我发现体验相当流畅，但是我的建议是： 不要将GWT本机窗口小部件与EXT小部件混合使用。令人困惑，因为通常名称是相同的(GWT.Button或GWText.Button？)
我发生的一件事实际上使代码比我想要的更加复杂，就是我想要一个 GWT本机面板是动态的，而Ext面板是可级联的。解？包裹GWTExt面板的GWT.VerticalPanel ...混乱。 :) 但是，它有效。 ;) 我第二次接受ykagano的评论，最大的缺点是失去了MVC中的V。尽管您可以将真正的ui类与其余的客户端代码分开，但是您不能轻易使用由图形/网页设计人员生成的HTML页面。这意味着您需要开发人员才能将HTML转换为Java。 获取所见即所得的ui编辑器，它将为您节省大量时间。我使用GWTDesigner。 GWT的最大优势在于能够忘记跨浏览器的问题。它不是100％，但是可以消除几乎所有的痛苦。结合托管模式调试的优势(相对于Firebug而言，Firebug出色但与Java调试器不同)给开发人员带来了产生复杂ajax应用程序的巨大优势。 哦，它的运行速度很快，尤其是在使用gzip过滤器的情况下。 GWT非常简单直观。 特别是随着UIBinder的发布，允许GWT小部件以XML进行布局，然后以Java进行编码。 因此，如果您使用了其他Ajax或Flash设计工具或Silverlight等，则GWT非常容易学习。 如果不是陷阱，最大的障碍就是GWT RPC。您之所以希望使用GWT是因为GWT异步RPC。否则，为什么不仅仅依靠CSS来格式化页面呢？ GWT RPC是允许您的服务器刷新服务器上的数据而不必刷新页面的元素。这是对诸如股票绩效监控(或美国当前的国家和公共债务或全球第二次流产的未出生婴儿数量)等页面的绝对要求。 GWT RPC需要花一些时间来理解，但是经过几个小时，它应该会变得很清楚。 除此之外，在努力学习GWT RPC之后，您最终发现您无法将JSP用作RPC的服务组件，除非...我的博客上有一个8部分(我认为)系列文章，介绍如何使用JSP。作为GWT RPC服务程序。但是，由于您只想问一些问题而不是寻求答案，所以我将停止发布我的博客。 所以。我非常相信，使用GWT的最大障碍/陷阱是找出如何正确部署GWT异步RPC以及如何使其能够使用JSP服务程序。 稍微偏离主题，但是在您遇到持续问题的情况下，irc上的#gwt频道非常有帮助。 我们很难将GWT代码库与从Web设计人员那里获得的HTML Web模板(由我们希望GWT管理的具有特定div ID的静态HTML页面)结合起来。至少当我们使用它时，我们无法使GWT与未使用GWT编码的网站部分集成。我们最终使它工作了，但这是一个很大的漏洞。
但是对于大型Javascript项目，这是最佳选择 GWT 2.4解决了许多上述问题，并且一个很棒的小部件库刚刚从Beta(Ext GWT 3.0.4 a.k.a. GXT)中问世，它完全用GWT编写，而不是JS库的包装。 剩余的疼痛：
关于GWT 2.4，在调试GWT时使用Firefox，它比使用chrome快得多。
另外，如果您使用的是eclipse，则在参数-> VM参数下添加以下内容： -Xmx512m -XX：MaxPermSize = 1024m -XX：PermSize = 1024m
您可以划分服务器和客户端，并在参数->程序参数下使用以下内容：
另外，为防止每次更改时刷新服务器，请使用JRebel GWT执行浏览器嗅探而不是功能检测，并且您的应用程序将无法在某些浏览器(特别是新浏览器)上运行 以下是该问题的一些参考：
以下是有关特征检测的一些参考：
摘自JavaScript框架比较-维基百科 与去年发布的GWT 2.7相比，GWT团队进行了许多重大改进。 GWT的一个主要缺点是，在GWT 2.6及更低版本中，编译需要花费大量时间。现在，GWT不再具有增量编译功能，它是超级快的，并且仅编译更改。 GWT 2.7现在具有(来源)：
一个主要的陷阱是，有时您需要为最终成为HTML元素的对象显式分配一个ID，以便能够使用某些CSS样式。例如：当给tabPanel的tabBar分配了ID并且您在那个elementId上指定了：hover时，GWT TabPanel只会将：hover悬停在tabBarItems上。 我在其他地方写了关于GWT的其他一些缺点，但是这些问题已经被rustyshelfs回答:)涵盖了。
获得可靠事实的最好方法是在gwt调查中。 GWT的最大问题之一一直是编译时间长。幸运的是，它的改进非常快，因此在不久的将来不会成为一个重大问题。另一个陷阱是，GWT的复杂性大大提高，因为Java是一种更复杂的语言，可以在每一步中抵制不良编码。另外，编译会添加一层。例如，js interop需要一些样板。根本的问题是，GWT并非设计得很简单。它是专为极其复杂的Web应用程序而设计的，整个社区始终将优先级，性能，代码质量，体系结构等置于优先于简单编码的位置。 值得注意的是，GWT 3.0将带来巨大的改进。 我最近在GWT上做了很多工作，这是我不得不说的： 我对GWT-EXT的了解不多，但是我也相信不需要包含第三方库。 祝您一切顺利：) GWT是一项技术杰作。它将客户端和服务器编程结合在一起，使其成为一个统一的应用程序-在"分层"之前编写软件的方式以及应编写的方式。它消除了不同的技能，团队成员之间的沟通不畅以及整个Web设计阶段：艺术和程序设计。这是您最接近移动设备的地方，例如Android开发。实际上，GWT旨在生成不同的本机UI，而不仅仅是HTML。尽管要确保这种解耦需要大量的纪律，但要使您的内层保持与显示无关。 您应该避免的第一个错误是我花了四年的时间才意识到，它使用的是EXT-GWT aka GXT和SmartGWT之类的第三方扩展。开始使用它们漂亮的桌面化小部件而不是投资自己的样式是非常诱人的，但是直到我最终受够了我才能告诉我SmartGWT有多少问题。简而言之，它将核心GWT功能集冻结在某个(相当过时的)级别上，然后在其之上进行构建。还请记住，当今精致的桌面外观看起来很愚蠢，更不用说性能低下，大量错误和兼容性功能-尤其是在移动设备上。您希望尽可能靠近本机浏览器控件，即下拉菜单显示为本机 由于移动趋势的发展，整个UX变得越来越简单和扁平，因此您无需做太多事情即可设计出外观鲜明的应用程序。尽管如果您想获得" 3D"外观，也可以使用渐变色。 CSS3使一切变得容易，并且GWT以不同于原始CSS的优雅的面向对象方式包装了它。因此，不要因为在GWT Showcase中看到相当丑陋的准系统控件而灰心。 GWT团队故意不提供任何样式，因为它是开发人员的工作。 其余的都是强类型Java中带有精美简洁API的常规浏览器编程。但是当然不要忘记您的代码在浏览器中运行，因此所有调用都是异步的，例如您不能在循环中调用GWT-RPC方法(以填充一些列表)，但是如果遇到这种情况，则需要递归地链接它们。 有一些自称的"反模式"，例如不使用GWT-RPC。到目前为止对我来说一直很好：十年来。简洁是关键。我什至不会为牺牲代码的优雅性和可维护性而牺牲一些性能。此外，在数据库中这不是瓶颈所在。当然，请注意您要发送给客户端多少数据。 而且，如果您找不到或设置现有小工具的样式-阅读丰富的HTML5元素集，则可以随时包装第三方工具。我使用流行的jQuery FullCalendar做到了。根本不是火箭科学。诸如Google Maps和Google Charts之类的所有其他东西都有半官方的GWT包装器。 GWT非常完美。它没有得到足够的热爱的唯一原因是，仍然影响行业的早期互联网采用者并不是来自计算机科学和面向对象的语言来欣赏它们。他们具有艺术背景(Photoshop / WordPress)或网络背景(Perl / Python)。
重用RPC服务对象。
我遇到的陷阱 |
