GWT是一个软件堆栈,可将Java代码和Java Runtime类库的子集转换为JavaScript代码。
与JavaScript工具包相比,GWT在本质上和用途上似乎疏远了,并且过于复杂以至于无法完成简单的事情,从而直接使用JavaScript会占用很多细粒度的控件。
为什么Web开发人员会选择使用GWT之类的工具,而不是使用纯JavaScript和JavaScript框架和工具包,而该工具使用的是最初不面向Web的语言?
它可测量地更好,并且基于什么标准?
GWT是一个软件堆栈,可将Java代码和Java Runtime类库的子集转换为JavaScript代码。
与JavaScript工具包相比,GWT在本质上和用途上似乎疏远了,并且过于复杂以至于无法完成简单的事情,从而直接使用JavaScript会占用很多细粒度的控件。
为什么Web开发人员会选择使用GWT之类的工具,而不是使用纯JavaScript和JavaScript框架和工具包,而该工具使用的是最初不面向Web的语言?
它可测量地更好,并且基于什么标准?
Answers:
太棒了:
它可以及早发现错误。(如果您愿意的话,Google Closure可以解决这一问题,同时使开发人员可以进入JavaScript世界)。
GWT 比您(对于大型应用程序)编写比您更快,更紧凑的JavaScript,并且使您可以确定发送到客户端的内容比使用等效的完整JS解决方案更容易。
它为大型应用程序提供了良好的关注点分离,而精巧的MVC或MVP架构已经动手可得。
GWT提供了有趣的库,并通过动态捆绑包加载轻松(轻松)地构建了启用I18N的应用程序。
从Eclipse IDE和命令行使用JUnit。这与我的第一点有关。您还可以在GWT项目上使用一些Java的代码质量工具(用于源代码检查,而不是字节码检查,因为没有)。
GWT并非适合所有人。它提高了某些人的工作效率,并为非JS开发人员提供了一个很好的工具,使他们可以构建具有动态前端的专业Web应用程序,而无需使用过多的JavaScript。但是,如果对您不起作用,请使用其他方法。
如果您需要以上大部分内容,但又不想使用Java,则可以查看Google Closure或Dojo Toolkit。
如今,JavaScript世界(通常是Web前端技术)非常活跃,因此情况正在不断发展。但是仅仅几年前,情况还没有那么光明。LESS / SASS并不那么流行,jQuery尚未成为出厂前的JS库,JavaScript库并不是每隔一周就产生一次,并且工具通常也不是那么好。
但是,对于具有动态前端的专业和大型Web应用程序的需求已经日益增长,因此要填补空白以提高开发人员的生产率。JavaScript有很多陷阱和怪异之处,您需要意识到,也许最好不要去关心它们。因此,像GWT这样的工具的利基市场。
从那时起,其他的出现了(想到的是CoffeeScript,Dart即将到来,还有大型的JavaScript框架,Node.JS等服务器端JS的革命,以及JavaScript的“足够好”的强势回归。种语言,不仅可以在客户端使用,还可以在业务堆栈的其他部分使用。
当然,您可以使用Firebug调试GWT代码,但理想情况下,您可以直接从Eclipse IDE的调试器进行调试,该调试器现在提供实时代码调试支持。
但是,Firebug它仍然可用,尽管您需要牢记GWT会生成经过优化和压缩的JavaScript,这可能并不容易调试。
是的,当然,您仍然需要自己编写CSS代码。不过,您将GWT项目与其他工具(例如SASS)相结合,则或多或少地很容易。
不要把GWT误认为不是它:您不会编写Java代码以Java字节码的形式直接在客户端运行。您可以使用Java语言编写代码,然后将其翻译为JavaScript以提高效率并允许您使用高级语言(或者至少是那样的用法)。
可以说,就抽象级别而言,Java和JavaScript可以视为可比的。但是,Java具有一些优点(上面有详细介绍),因此,在无需重新编写现有工具的情况下获得了好处。Google的开发人员只有一个聪明的主意,那就是可以重用现有的面向Java的工具,但实际上可以开发JavaScript应用程序。
此外,他们还解决了另一个问题,即双语言Web应用程序通常很麻烦的管理,其中JavaScript和Java代码被分别处理。GWT的使用使开发过程的双方都能达到一定程度的融合。
在使用GWT开发Web应用程序多年后,我认为GWT具有如此严重的缺点,以至于如果我不被迫放弃,我将永远不会再使用它。
DOM树
尽管JavaScript性能可能会更好,但是呈现的DOM树通常不必要地复杂。例如,Tree实现使用13+个DOM元素,其中每个元素都包含一个<table>。使用大树(大约10000项)只会冻结浏览器。一个纯JavaScript / HTML / CSS树可以轻松处理相同数量的项目。
发展历程
纯JavaScript / HTML / CSS源的修改尝试周期无法被克服。您只需保存源文件并在浏览器中刷新页面。这是生产力的关键因素,即使使用代码服务器,GWT也无法竞争。
使用Chrome或Firebug的调试器,调试JavaScript绝对是一件轻松而愉快的事情。
锤子专家
在所有方面都使用Java的想法是给“锤子专家”的开发人员使用的。他们是锤子的主人,所以一切都是钉子。我认为这种方法是非常错误的。使用GWT还需要CSS和HTML的知识。没有GWT,开发人员经常会遇到几乎无法解决的问题,而具有HTML / CSS经验的人可以提出解决方案。如果开发人员需要这种能力,他们可以通过HTML开发变得更容易。
我的观点是,与纯JavaScript / HTML / CSS开发相比,GWT提供的大多数优点至少值得怀疑,而缺点则更为严重。
我想到的使用GWT的好处很少(更多详细信息,请参阅我的博客http://www.pandurangpatil.com/2012/09/benefits-of-using-gwt.html)
由于GWT客户端应用程序是用Java编写的,因此有一个机会在编译时捕获相同的语法错误(因为它不支持所有JRE类,因为浏览器本身不支持这些功能)。让我们举一个例子来了解我在说什么。如果使用纯JavaScript库拼写错误的JavaScript变量名。捕获此类错误的唯一方法是运行应用程序并测试所需的结果。泛型和注释之类的Java功能已全部使用,可以在您的应用程序中使用。
一个人可以利用现有的可用库,也可以根据需要轻松地编写一个库来生成代码,因为需要生成的代码必须是Java。GWT编译器负责编译并将其转换为JavaScript。
代码管理变得更加容易。
可以简单地编写一些通用的业务逻辑,使其可以在GWT客户端代码以及Java的服务器端代码中使用,例如数据验证或一些通用实用程序功能。
通过使用GWT eclipse插件,您可以轻松地用Java调试用于业务逻辑的客户端代码。
随着GWT编译器编译您的客户端Java代码并从中生成JavaScript。您需要将其部署到服务器上,并在请求时在用户浏览器中提供并执行。在生成此JavaScript时,它将进行一些优化。
它在生成JavaScript时不会考虑无效代码,当我说无效代码时,我的意思是说“存在但未从主流调用的代码”。依次减少最终JavaScript代码的有效大小。
它负责混淆生成的JavaScript代码。
它会最小化生成的JavaScript代码。
更重要的是,它将分别生成针对浏览器的优化代码。当我分别说时,它将生成特定于浏览器的单独JavaScript,当从给定浏览器收到相应请求时,将使用该JavaScript。这反过来减少了为特定浏览器下载的JavaScript代码的大小,因为它在一个代码中并未包含所有针对浏览器的处理方式。
如果您要使用GWT的国际化功能编写不同语言的应用程序,例如英语,印地语,马拉地语等。生成JavaScript代码时,它会按语言和浏览器组合创建副本。对于给定的语言和浏览器组合,这使得生成的JavaScript代码是最佳和小巧的。
如果需要使用可以从Java GWT代码调用的直接JavaScript,则可以使用JSNI(JavaScript本机接口)来实现。甚至可以从JavaSctipt回调GWT Java代码。
如果要创建具有书签功能的页面,则可以使用GWT的“历史记录”功能。
如果要使用JSON作为数据格式进行通信和操作,则它具有非常好的功能,称为JavaScript覆盖类型。
GWT的Deferred Binding功能是一个很好的功能,由于Java,我想可以提供。
您可以使用Java Swing样式的GWT可用小部件来构建用户界面。您甚至可以非常轻松地创建自定义窗口小部件。
如果要以纯HTML样式构建用户界面(网页),则可以使用GWT的声明性UI功能。我觉得这是GWT的主要功能之一。这使开发人员更容易构建纯HTML样式的页面。我想比Swing样式编码更容易维护。最重要的是,您仍然可以使用Java编写逻辑,而仅使用纯HTML编写演示文稿。(注意:无论您使用哪种方法(声明性UI或Swing风格)最终都只会是HTML,但与众不同的是您编写和维护它的方式)。
GWT的Client Bundle功能使管理其他Web资源(如CSS,图像和其他文本内容)变得非常容易。
单元小部件:要显示分页数据收集,GWT提供了单元小部件。有一些小部件,例如CellTable,CellList,CellTree和CellBrowser。
通过GWT客户端代码与服务器通信。它支持多种方式来实现客户端服务器通信。
如果您不关心用于数据传输的协议,则使用GWT RPC机制。集成客户端代码以与服务器进行数据传输非常容易。您可以在客户端代码中定义自定义DTO(数据传输对象),甚至可以在服务器端代码上使用。服务器端实现接受相同的DTO作为参数或返回值。GWT RPC框架会处理所有其他事项。它甚至会将客户端代码中从服务器端代码引发的异常传播到客户端代码(前提是您需要在客户端代码包中定义这些Exception类。GWTRPC内部使用AJAX调用及其自定义协议进行数据传输。
如果您不想使用GWT RPC,则可以使用Request Builder调用服务器AJAX来从服务器获取数据。这也更容易实现。它还具有有趣的功能Request Factory。使用此功能,可以使您的DAO或服务层公开以从客户端代码调用。为此,您需要为服务和自定义数据类型定义一些接口集。使用这些接口,您可以从客户端代码访问那些服务。我已经编写了maven插件来生成这些接口。如果您使用一些必需的注释来注释DAO层,请参考(https://github.com/pandurangpatil/gwt-mvn-helper),请参阅其中的mvn-helper-test模块进行使用。Request Factory的目标是与服务器上的JDO或JPA之类的ORM层集成。它支持从客户端代码在给定实体上调用持久化。最重要的是,当您调用persist方法时,它会计算并仅将更改(增量)发送到服务器进行保存。
如果要进行跨域JSONP调用,可以执行相同的引用。