与纯JavaScript框架相比,诸如GWT之类的工具具有哪些公认的优势?


11

GWT是一个软件堆栈,可将Java代码和Java Runtime类库的子集转换为JavaScript代码。

与JavaScript工具包相比,GWT在本质上和用途上似乎疏远了,并且过于复杂以至于无法完成简单的事情,从而直接使用JavaScript会占用很多细粒度的控件。

为什么Web开发人员会选择使用GWT之类的工具,而不是使用纯JavaScript和JavaScript框架和工具包,而该工具使用的是最初不面向Web的语言?

它可测量地更好,并且基于什么标准?

Answers:


27

包含电池

Java的工具

太棒了:

  • IDE:即使某些IDE支持JavaScript,支持水平也无法比拟。尝试在大型代码库(例如40K + LOC)上重构JavaScript代码并哭泣。
  • 单元测试:尽管在最近几年中有所增加,但在Java世界中它也变得更加成熟。
  • 持续集成持续检查
  • 文档生成:确保您拥有JSDoc和其他一些文件

静态类型

它可以及早发现错误。(如果您愿意的话,Google Closure可以解决这一问题,同时使开发人员可以进入JavaScript世界)。

优化的JavaScript

GWT 比您(对于大型应用程序)编写比您更快,更紧凑的JavaScript,并且使您可以确定发送到客户端的内容比使用等效的完整JS解决方案更容易。

建筑

它为大型应用程序提供了良好的关注点分离,而精巧的MVC或MVP架构已经动手可得。

体面的图书馆

GWT提供了有趣的库,并通过动态捆绑包加载轻松(轻松)地构建了启用I18N的应用程序。

单元测试

从Eclipse IDE和命令行使用JUnit。这与我的第一点有关。您还可以在GWT项目上使用一些Java的代码质量工具(用于源代码检查,而不是字节码检查,因为没有)。

都是关于你的!!

GWT并非适合所有人。它提高了某些人的工作效率,并为非JS开发人员提供了一个很好的工具,使他们可以构建具有动态前端的专业Web应用程序,而无需使用过多的JavaScript。但是,如果对您不起作用,请使用其他方法。

如果您需要以上大部分内容,但又不想使用Java,则可以查看Google ClosureDojo Toolkit

当时是个好主意:历史很重要!!

如今,JavaScript世界(通常是Web前端技术)非常活跃,因此情况正在不断发展。但是仅仅几年前,情况还没有那么光明。LESS / SASS并不那么流行,jQuery尚未成为出厂前的JS库,JavaScript库并不是每隔一周就产生一次,并且工具通常也不是那么好。

但是,对于具有动态前端的专业和大型Web应用程序的需求已经日益增长,因此要填补空白以提高开发人员的生产率。JavaScript有很多陷阱和怪异之处,您需要意识到,也许最好不要去关心它们。因此,像GWT这样的工具的利基市场。

从那时起,其他的出现了(想到的是CoffeeScript,Dart即将到来,还有大型的JavaScript框架,Node.JS等服务器端JS的革命,以及JavaScript的“足够好”的强势回归。种语言,不仅可以在客户端使用,还可以在业务堆栈的其他部分使用。


补充笔记

关于您关于Firebug使用的原始问题(现在已编辑)

当然,您可以使用Firebug调试GWT代码,但理想情况下,您可以直接从Eclipse IDE的调试器进行调试,该调试器现在提供实时代码调试支持。

但是,Firebug它仍然可用,尽管您需要牢记GWT会生成经过优化和压缩的JavaScript,这可能并不容易调试。

关于您的原始(现在编辑)关于CSS的问题

是的,当然,您仍然需要自己编写CSS代码。不过,您将GWT项目与其他工具(例如SASS)相结合,则或多或少地很容易。

这只是一个工具!

不要把GWT误认为不是它:您不会编写Java代码以Java字节码的形式直接在客户端运行。您可以使用Java语言编写代码然后将其翻译为JavaScript以提高效率并允许您使用高级语言(或者至少是那样的用法)。

可以说,就抽象级别而言,Java和JavaScript可以视为可比的。但是,Java具有一些优点(上面有详细介绍),因此,在无需重新编写现有工具的情况下获得了好处。Google的开发人员只有一个聪明的主意,那就是可以重用现有的面向Java的工具,但实际上可以开发JavaScript应用程序。

此外,他们还解决了另一个问题,即双语言Web应用程序通常很麻烦的管理,其中JavaScript和Java代码被分别处理。GWT的使用使开发过程的双方都能达到一定程度的融合。


进一步阅读:


“可以说,就表现力而言,Java和JavaScript可以被视为具有可比性。” 玩笑?Java中的等效功能大约是其5倍。
凯文·克莱恩

@kevincline:是的,我不是要表达表现力,而是要说抽象层次。感谢您发现它(凌晨2点...)
haylem 2012年

6
@kevincline:再加上我确实说了“有争议的”,一种语言或其他语言的顽固狂热者会争论任何事情:)
haylem 2012年

1
除了@Halem的项目外,我还想说JavaScript的基于原型的OO对于来自Java之类的基于类的系统的人来说可能有些奇怪。方法的一致性通常很有用。
马修·弗林

@MatthewFlynn:反之亦然:这就是为什么纯JS开发人员肯定很难上GWT潮流,或者使用更多的重量级框架或多或少地复制基于类的OO范例。
haylem 2012年

6

在使用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提供的大多数优点至少值得怀疑,而缺点则更为严重。


2

并没有更好的结果。
对于日常使用,请考虑使用jQueryAmpleSDKhtml5 polyfill

GWT有很多开销:实际的概念上的。

如果您有一个Java应用程序或一些服务器端Java代码要移植到Web前端,则可能会很有用。


您的意思是ClojureScript。Clojure本身是针对JVM的基于LISP的语言。ClojureScript是生产JS代码的一种。
haylem 2012年

是的,无论如何已经编辑了。保持简单。
ZJR 2012年

2

我想到的使用GWT的好处很少(更多详细信息,请参阅我的博客http://www.pandurangpatil.com/2012/09/benefits-of-using-gwt.html

  1. 由于GWT客户端应用程序是用Java编写的,因此有一个机会在编译时捕获相同的语法错误(因为它不支持所有JRE类,因为浏览器本身不支持这些功能)。让我们举一个例子来了解我在说什么。如果使用纯JavaScript库拼写错误的JavaScript变量名。捕获此类错误的唯一方法是运行应用程序并测试所需的结果。泛型和注释之类的Java功能已全部使用,可以在您的应用程序中使用。

  2. 一个人可以利用现有的可用库,也可以根据需要轻松地编写一个库来生成代码,因为需要生成的代码必须是Java。GWT编译器负责编译并将其转换为JavaScript。

  3. 代码管理变得更加容易。

  4. 可以简单地编写一些通用的业务逻辑,使其可以在GWT客户端代码以及Java的服务器端代码中使用,例如数据验证或一些通用实用程序功能。

  5. 通过使用GWT eclipse插件,您可以轻松地用Java调试用于业务逻辑的客户端代码。

  6. 随着GWT编译器编译您的客户端Java代码并从中生成JavaScript。您需要将其部署到服务器上,并在请求时在用户浏览器中提供并执行。在生成此JavaScript时,它将进行一些优化。

    • 它在生成JavaScript时不会考虑无效代码,当我说无效代码时,我的意思是说“存在但未从主流调用的代码”。依次减少最终JavaScript代码的有效大小。

    • 它负责混淆生成的JavaScript代码。

    • 它会最小化生成的JavaScript代码。

    • 更重要的是,它将分别生成针对浏览器的优化代码。当我分别说时,它将生成特定于浏览器的单独JavaScript,当从给定浏览器收到相应请求时,将使用该JavaScript。这反过来减少了为特定浏览器下载的JavaScript代码的大小,因为它在一个代码中并未包含所有针对浏览器的处理方式。

  7. 如果您要使用GWT的国际化功能编写不同语言的应用程序,例如英语,印地语,马拉地语等。生成JavaScript代码时,它会按语言和浏览器组合创建副本。对于给定的语言和浏览器组合,这使得生成的JavaScript代码是最佳和小巧的。

  8. 如果需要使用可以从Java GWT代码调用的直接JavaScript,则可以使用JSNI(JavaScript本机接口)来实现。甚至可以从JavaSctipt回调GWT Java代码。

  9. 如果要创建具有书签功能的页面,则可以使用GWT的“历史记录”功能。

  10. 如果要使用JSON作为数据格式进行通信和操作,则它具有非常好的功能,称为JavaScript覆盖类型。

  11. GWT的Deferred Binding功能是一个很好的功能,由于Java,我想可以提供。

  12. 您可以使用Java Swing样式的GWT可用小部件来构建用户界面。您甚至可以非常轻松地创建自定义窗口小部件。

  13. 如果要以纯HTML样式构建用户界面(网页),则可以使用GWT的声明性UI功能。我觉得这是GWT的主要功能之一。这使开发人员更容易构建纯HTML样式的页面。我想比Swing样式编码更容易维护。最重要的是,您仍然可以使用Java编写逻辑,而仅使用纯HTML编写演示文稿。(注意:无论您使用哪种方法(声明性UI或Swing风格)最终都只会是HTML,但与众不同的是您编写和维护它的方式)。

  14. GWT的Client Bundle功能使管理其他Web资源(如CSS,图像和其他文本内容)变得非常容易。

    • CSS资源使在CSS内具有条件逻辑成为可能。您还可以从GWT客户端Java代码访问一些动态值。
    • 它还会处理混淆CSS类的问题。最重要的是,GWT可以从css文件自动生成接口以使用css类。
    • 图像资源使开发人员更容易以易于维护的方式在应用程序中使用图像。简单地说,是指您想使用GWT Java代码中的图像而不是使用硬编码的URL时,可以使用图像资源。使用图像资源的好处是,如果您要更改位置或使用其他名称不同的图像,则只需在一个位置进行更改。图像资源更重要的功能是将CSS资源作为精灵使用。它将使该图像成为行内数据uri或与sprite一起使用。我并不是说不可能在其他框架上做到这一点,更重要的是您可以快速,轻松地完成它。GWT为您简化了一切。
    • 数据资源为数据文件(如.pdf)添加了一些优化,以便根据文件内容对文件进行重命名,以使其可被浏览器高度缓存。小数据文件可能会转换为嵌入式数据uri。
    • 通过将Client Bundle用于其他Web资源,以及是否正确地将应用程序结构化为不同的模块。它可以与所有资源一起成为完全可重用的模块。可重用模块有什么大不了的?如果您通过某个模块中的直接URL使用图像,则效果很好。并且,如果您将该模块包含在其他模块中,并尝试使用在该模块中创建的组件,则仍然需要将这些图像复制到最终应用程序的公共URL中。如果您将这些图像用作图像资源,则不必这样做。
    • 通过使用CSS和图像的客户端捆绑包创建小模块可以实现其他优化。您可以选择在最终模块中仅包含必需的模块。这将使最终模块JavaScript有所不同,即使您只想使用模块的一小部分,其他资源也将仅包含必需的内容,而不包含全部内容。
  15. 单元小部件:要显示分页数据收集,GWT提供了单元小部件。有一些小部件,例如CellTable,CellList,CellTree和CellBrowser。

    • CellTable旨在以分页表格格式显示数据,它具有可以在其中更改给定单元格内容的功能。它支持客户端和服务器端的分页,它支持按列排序,还支持选择一个或多个记录并为其生成事件。
    • CellList可用于以列表格式显示数据,并且项目可以自定义格式显示。它还支持客户端和服务器端分页以及一个或多个记录的选择,并生成事件以供选择。CellTree和CellBrowser可用于以树格式显示数据。
  16. 通过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调用,可以执行相同的引用。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.