|
锁定老帖子 主题：GWT用来开发web程序会不会成为趋势
精华帖 (0) :: 良好帖 (12) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-01-12
这么说吧，随着我们项目的不断进展，感觉GWT还是给我的思想带来了一定的冲击，
让我体会到一种全新的编程方式，这点感觉挺爽的，无论以后他发展的是好是坏， 它的思想是我们可以借鉴的 |
| 返回顶楼 | |
|
发表时间：2012-01-12
gwt访问太慢，互联网根本用不了，做企业级项目还行
|
| 返回顶楼 | |
|
发表时间：2012-01-12
georgezeng 写道 GWT其实蛮不错的，基本上让不懂javascript的开发人员也可以很轻松的开发前端了，当然这不是重点。一种东西总有优缺点，而优缺点也总是相对而言的，GWT提供了java开发环境，这使得代码的管理和维护以及可读性都变得很简单，很多人可能会说它的UI很难用，那么我反过来问，为什么要去用它的UI呢？它提供的UI组件只是让你更好的去为页面进行开发，但是你完全可以自己做到所有的东西都可控，并且让这些东西变得比以往的前端可重用性更高。而且你可以引入所有你想要引入的js工具库，比如jquery，或者dojo，或者其它的，它其实并没有限制任何东西，应该说它只是改变了开发模式。再者对于一般的web应用，最麻烦的是前端数据与后台的交互，你可能会用json，或者其它的东西来封装，但无论用什么，你都需要自己封装，自己解析数据，而GWT，它只需要你定义的是一个POJO，然后使用它的RPC，够了，前后端一致，你不需要任何其它的改动。你可以说它的编译很慢，是的，但是开发的时候也不是时常需要编译的。还有人说它没办法对生产环境进行维护？答案是否定的，它提供了非常好的方式来对生产环境进行调试，就是它的debug工具，而且可以直接debug你的生产环境，跟你在浏览器debug一样，但是它提供了eclipse这样更好的debug环境，何乐而不为呢？但是它确实也有缺点，就是编译确实很费时间，而且有一定的学习坡度，但是官网的资料非常齐全，你需要的只是耐心的去阅读：）
赞同！ 我毕业设计时临时学了几天，然后运用到毕业设计中，也算是体验了一下使用GWT的开发模式吧，感觉就是除了编译时很耗时外，其他方面都非常好用，而且对与不喜欢js的人来说，绝对是好事。 |
| 返回顶楼 | |
|
发表时间：2012-01-12
yiran9937 写道 说一下我的体会。
我没使用过GWT，但是我了解过，也理解过它的开发模式。我总结，技术框架封装的越好越强大，灵活性肯定越底，可通用性也降低，这个是封装的代价，这个是必须的哲学道理，但是相应的开发肯定很容易模式化，也就意味着开发效率会得到提高。 所有有被商业使用过的技术，都有其优势，所谓存在必然有其道理。当然肯定会有弊端，关键在于在什么环境下，发挥它的优势，削减它的弊端。 所以没有一个完全通用所有软件项目而且在所有方面都能做到最好的框架技术。技术太多，了解技术在各种环境下的利弊，才是学习技术的根本，这样才能在需求与技术中取得平衡。我相信，用同一个技术框架使用4年来做项目，肯定在有些时候将就过框架，也就是说没有选择技术的考虑，而是让项目跟着框架走了。将就框架必然带来的是痛苦。 总结，多了解一些技术框架的利弊及使用环境，然后再回身看一下自己长久使用的技术，也许你会发现你使用的技术其实有很多优势，当然也会了解到它的劣势。有了对比就会对事物看的更真切。 以上是我5年程序员，2年项目管理的总结。 说得好，学习了! |
| 返回顶楼 | |
|
发表时间：2012-01-12
学习ExtJs就行了，又不是很难，为什么要用GWT
|
| 返回顶楼 | |
|
发表时间：2012-01-12
公司以前用过gwt，如果公司还在用的话，我估计我早辞职了！
|
| 返回顶楼 | |
|
发表时间：2012-01-12
蛋疼，正在搞GWT的项目
|
| 返回顶楼 | |
|
发表时间：2012-01-13
key232323 写道 witcheryne 写道 GWT我是放弃了...
从 1.5 用到 2.0.2. Gxt 从1.2.3 用到 2.1 太折腾... GWT对于Java开发人员来说很不错。js模块管理，代码压缩，各种浏览器优化都省了。基本上是用开发Swing的思想来做Web. 适合One Page App. 对前端的单元测试也可以使用Java的方式来作，这点感觉很爽(我没用过)... 不爽的地方: 代码都被压缩过，一但发布版本出问题，基本看不出来bug在哪儿.编译的时候可以不压缩，不过变量名是com_company_project_model_className_variable的方式命名,绝对看的人蛋疼. 编译时间太长，如果你使用持续构件，或者一个很牛x的开发机器（维护GWT的同事直接上的8核CPU） 为什么觉得他是趋势: 就如同C语言代替汇编一样。 GWT是把js,css,html等技术当成汇编，用Java这种成熟的静态语言来代替之。现在可能感觉不出他的优势，从大趋势上来看，的确有一统前端的可能。 GWT是把js,css,html等技术当成汇编，用Java这种成熟的静态语言来代替之。 这句话，类比不当，看团队，有的喜欢js的，肯定把Java当汇编的——优秀的前端开发者维护js/css/html应该比一个javaer维护GWT更游刃有余些，因为GWT不透明的，虽然成本大了点 谈趋势，js才是web开发的趋势，GWT/JSF之类的暂时提供给Javaer过度下罢了 "GWT是把js,css,html等技术当成汇编，用Java这种成熟的静态语言来代替之。" 只是说他能为趋势的可能点。GWT 有 JSNI, 可以直接写js, 也可以直接调用js, 之间没有什么竞争关系。我用GWT封装过Pushlet, 底层依赖还是javascript。 js调用通过JSNI进行. key232323 写道 谈趋势，js才是web开发的趋势，GWT/JSF之类的暂时提供给Javaer过度下罢了 没这么绝对，适用场景不同。 javascript更广一些 |
| 返回顶楼 | |
|
发表时间：2012-01-14
我个人认为，html+js+css这种原始的组合才是趋势。为何非要把它们用java给封起来?gwt真的好用么?反正我看过没用过。
|
| 返回顶楼 | |
|
发表时间：2012-01-15
看了前面的讨论,觉得有的有道理,有的和我理解的有偏颇.
我的理解是这样.首先为什么会有GWT呢.就像google自己说的.是因为支持js编辑的工具没有java的IDE那样功能完备.eclipse对java语言的编写支持粒度很好,而js的编辑工具(包括eclipse插件)对js的编码支持就相对弱,于是有人设想,如果用java编写js,那么就很好的弥补了这一缺点.事实上,由此带来的一系列优点.比如说跨浏览器,js的性能自动调优等. 另外,GWT的设计也有几大优点,一是对第三方js组件的支持;一是扩展性强,灵活度高;再就是API通俗易懂,接近AWT或者flex等命名和使用方式.有过相关经验的人,尤其是有过js开发经验的人,上手容易. 再来看看GWT的缺点.第一个缺点要数UI组件的缺乏.否则也不会有gxt等等这样的项目,也不会在gwt项目里使用较多第三方js组件了;第二个缺点类似flex等浏览器插件,就是和界面的交互性不好,举个例子,在一个html界面里,有两个div,一个div里用gwt来实现,另一个div里用其他方式(比如直接js编码或者html),那么要想在二者之间做一个交互动作,相当麻烦,尤其是在gwt项目已经成型后,想在gwt项目外做这件事,非常困难.换句话说,如果gwt项目开发前没有考虑做模块化接口设计,你想在html页面通过js来达到控制gwt生成的代码,很困难.第三个缺点呢就要算gwt的工程部署,编译了.稍微复杂了些,耗时些 既然它有这么多特点,到底gwt是好是好,市场前景如何呢,我是这样看的. 第一,gwt的出现,肯定为java程序员开发js代码带来福音,提高了效率.尤其解决了跨浏览器和性能调优的问题. 第二,gwt的UI,这个也是我主要想谈的,gwt的发展肯定有一个过程,一个从无到有从小到大的过程,用1.5版本的人再用2.4.就会发现,gwt在UI方面也不是没有建树,也是在一点点做.但是界面UI本身是一个比较复杂,灵活度要求高的东西,要想完善出一套美观易用扩展性强的UI来,不是一件容易事,ext做了这么多年,我想对人的审美疲劳也是一种考验,美观不是说换了皮肤可以解决的,有些时候要换的是架子,一个表格,换一种风格,换一种分页样式,甚至换一种布局方式.我用tab组件,我想把它变成操作系统任务栏的方式行不行,容易做吗,都是我们面临的问题.gwt能做吗,不知道,但是gwt的扩展性强灵活性高目前我们看得到,我可以用一个ext的组件组合一个DHTML组件,只要gwt里你做的接口合理,完全可以做到耦合度低的完美契合.gwt的这个优点弥补了它UI不足. 第三,对于gwt,它有另外一个特点,就是可以模块化,类似jar,但也有不同,一个项目积累的代码,你设计的好,可以完全独立或者部分独立,是可以随时打包带着走到其他项目里的.而gwt还有另外一个特点,那就是源码,它的模块化是必须带源码的,否则无法进行编译.很多公司现在在用gwt,累积的界面UI也会有一些,这些东西放出来,是不能加密的,否则用不了.这点让我们程序员对ext之流解除了些担心. 至于gwt的其他缺点,我觉得并不重要,比如说gae,这个可以不用,有什么关系呢.比如说编译时间长,在项目中,开发快和出一个版本耗时长一个小时两个小时的,哪个重要呢.当然我也深刻理解上线时微小变动带来漫长编译问题的痛苦(可以分工程啊,分成几个gwt工程,编译时就好办多了,不过设计时要想好,具体不谈了),框架搭建不容易?前期一个人做好,后面所有的人都不关心的事情,也是可以容忍的.我们做的一个项目,前期搭好框架,组员到位后,简单说了下工作方法(都是java开发老鸟),后面没有人觉得麻烦,反而有的人觉得很神奇.我相信随着gwt的发展,这些问题也会慢慢的解决. 最后,我要深恶痛绝gwt一个问题,那就是编译时的bug.就是运行时正常,编译后在浏览器上就有问题了,在操作dom组件数组时,有些情况下会有这个问题.调试这类问题,异常吐血.还好不多,一个项目能遇见一两个.也算在容忍之列. 此外.对于当前web2.0思潮下的前端开发,gwt思想完全符合这个潮流.对于所见即所得模式下的工厂式开发,使用插件方式,也完全可以做到gwt式的拖拉拽组建页面布局.gwt的插件虽然不完善,但是现在有些公司已经在开发类似的插件了(不过我看下来,由于gwt几无UI可言,也部分用自定义或者第三方js组件,并非完全gwt). 总之,我觉得,gwt尽管有这样或者那样的缺点,但是目前在业内,也的确找不到一款比gwt更好的给java开发人员编写js的工具了.felx在移动终端的世界里命运,gwt+html5?呵呵,可以简单畅想一下,呵呵,YY中... 对或不对,请大家指正. |
| 返回顶楼 | |
