您对GWT有什么看法?[关闭]


11

由于我是在这段时间学习Java的,所以我刚刚完成了教程,所以我认为我准备开始为一个项目做贡献了(因为我从经验中知道这是真正学习的最佳方法)。

我看过GWT,看起来很有趣,所以我想尝试一下。但是我在想,由于GWT在JavaScript中部署了Java应用程序,为什么当我可以学习实际的东西(这就是JavaScript)时,为什么应该学习GWT。我的问题:值得吗?如果他们想构建JS应用程序而不是使用Java和GWT,那么有人会更好地学习JavaScript吗?我意识到用GWT构建某些东西可能会更容易,但最终值得吗?

谢谢。


3
但是人们直接学习C而不是直接用机器代码编程系统。
haylem 2010年

Answers:


6

GWT本质上是本机代码的编译器,就像Visual Studio将源代码编译为字节码或机器语言一样。

这使程序员可以抽象化基础架构中的差异,就像Visual Studio用户无需担心字长,寄存器数量以及在为32位或64位代码进行编码时调用操作系统的确切约定方面的差异一样位。

这是一件好事,因为它使您可以将一些维护负担转移给其他人。由于这是Google,您知道他们拥有比您更多的开发资源,因此,您实际上是在免费带来额外的人力。


2
另一个好处是托管模式调试。因此,您可以通过客户端和服务器端以及调试器中的所有工具来调试应用程序的逻辑。
杰里米

5

我不喜欢

使用它可以做的所有事情,没有它就可以做得更干净。


同意。但是,您正在编写包含多个图像的页面,每个图像一个文件。对 ?

1
@Rocket:我不明白“多张图片,每张图片一个文件”的含义。
乔什·K

4
@Rocket:我看不到图像与GWT有什么关系。如果要启用精灵,可以,否则可以,您有多个图像。
乔什(Josh K)2010年

1
@Josh我的猜测是,您添加小的动画等而不是编写大型的复杂动画。脚本语言仅限于小型任务,而静态类型的语言用于大型任务是有原因的。
mP01 2011年

2
一言以蔽之。与许多可用的Java相比,没有人为javascript编写过真正可比的编辑器。
mP01 2011年

2

GWT之所以选择Java作为源语言,是因为JS(Ecmascript)很难使用。GWT只是将编程引入Web /浏览器的一种好方法,而以前是不可能的。

在GWT之前,曾尝试过在浏览器中编程某些东西(Ajax,dojo,纯JavaScript)是徒劳的。但是那里的自然力量太猛烈了,所以一切都崩溃了(浏览器不断变化,它们从不相同,人们说不同的语言,人们认为15张图像实际上应该是15个文件,等等)。

所以答案是:如果我要编写Internet Ocean锅炉代码(这不是我的工作),那么我会选择GWT。

PS另一个想法。JS由Netscape制作。公司已经死了很久,但语言没有完成,而且腐烂


6
-1 ECMAScript是不断开发的;ECMAScript 5去年才问世,而Flash的语言ActionScript ECMAScript。

16
-1。编写JavaScript 并不是 “非人道的困难”。您会发现JavaScript困难,您很可能不是很聪明。在GWT之前,有些人知道他们在做什么。在GWT之后,有些人无法编写JavaScript(并使用GWT),而有些人却可以(并且不使用GWT)。最重要的是,JavaScript已经超越了浏览器,看看Node.js和MongoDB。使用SpiderMonkey或V8编写独立于平台的脚本。
乔什·K

3
@JoshK。我还认为Visual Basic 6比JS更难编程。Java比Basic简单50倍。而且CSharp可能比Java容易2倍。所谓困难,是指要进行实用的,复杂的应用程序,这些应用程序可维护,成组创建并出售给客户。我不在乎语法糖的差异。而且我认为,如果您需要非常聪明地使用语言,那么该语言就有问题。

3
JavaScript非常容易设计团队构建的大型可维护应用程序。我做完了 除了人们决定不做之外,编写模块化代码没有什么困难。
乔什·K

不要将DOM与JavaScript混淆。问题不是JS。
Andrew T Finnell,2012年

2

赶上GWT的一些好理由:

  • 每种技术都有生命周期。GWT处于上升期。学习GWT将为您在未来的较长时间内提供技术优势。
  • 使用Java的GWT为Web应用程序带来了结构。JavaScript更适合脚本编写。在Java的支持下,GWT更适合大型应用程序。如果您已经注意到JavaScript之上的框架/工具包,那么您可能会得出结论,就像我所做的那样,JavaScript本身不足以满足严肃的项目。所有这些框架都为应用程序开发带来了结构。GWT是这些框架之一,并且将是盛行的。
  • 移动应用程序是软件界的一场革命。革命目前尚处于初期。越来越多的软件将移至移动平台。GWT现在是您可以找到的最全面的跨平台应用程序开发工具。

话虽如此,GWT实际上与Google或sun(servlet)的Web服务框架并没有紧密的联系。由于Google或Sun的业务性质,集成工具更多地侧重于与其服务器的集成。为了利用GWT的技术力量,应该或多或少忽略某些服务器集成超级。只需将GWT用作客户端应用程序工具,它​​将对您的未来职业更加有益。


1

这取决于您要执行的操作(对于大多数工具而言)。

如果您想了解Web开发的细节,请使用许多(有时是不同的)浏览器环境技巧,并使用它们的最新功能,请勇敢地尝试一些小技巧,使您的Web应用“看起来很酷”,GWT永远都是您的方式:如果您有时间和经验,那么您可以用手做更多的事情。是的,还有许多其他工具包可以帮助您进行JavaScript编程。

但是,如果您想为应用程序制作一个“不太花哨”但稳定的GUI,“应该”,并且在大多数情况下确实做到了这一点,并且在各种浏览器中看起来都一样,那么GWT是个不错的选择选择,这是我所知道的最好的。说明:Google一定会保持与大多数浏览器和最新技术同步的动力,并且肯定有足够的资源来做到这一点。是的,您坚持自己的目标,而不是自己做。问题:你的工作是什么?通过最小的工作量通过Web界面为最广泛的用户提供相同的服务-或创建一个闪亮,出色的Web门户,该门户在最新平台上具有最酷的功能。

+1原因:我认为将您的应用程序保留在一种代码库和一种语言中是有益的。您可以在数据库脚本中完成巧妙的工作-但您将自己锁定在该数据库服务器上。您可以使用shell脚本或批处理文件来做外部工作-但您只能将自己锁定在操作系统上。您可以在JavaScript中实现某些控制器逻辑,以在浏览器中提供富客户端接口-但您可以将自己锁定在一个浏览器中。对于所有情况,要使它们与核心应用程序数据结构和需求保持同步并不容易(也许最困难的是不断变化的浏览器+ JS工具环境)。我坚信,如果核心应用程序是Java,则所有内容都应使用Java-在极少数情况下,您实际上必须将一部分逻辑放入另一个环境中。

我选择GWT的原因是我对上述问题的回答-它确实达到了我想要的目的:安装后大约两周,我有了一个可接受的用于内部服务器监视系统的Web界面-尽管我有使用Swing的经验。(不,我没有使用默认的外观,是的,我使用CSS和类来表示逻辑信息:-))

检查您当前和计划中的任务-并为它们选择合适的工具

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.