|
锁定老帖子 主题：GWT用来开发web程序会不会成为趋势
精华帖 (0) :: 良好帖 (12) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-11-15
不晓得好用不 几年前在某个项目中用过 后面没有用过了 在后面 ext jq-ui dwz 等等 发现 前端 美工 + 效果 + jq + ajax 基本就自己写了 封装也不是很麻烦 前后端定义一种数据规范 测试起来还是 js 的比较给力 慢慢的我js也可以了
|
| 返回顶楼 | |
|
发表时间：2012-11-16
个人比较喜欢gwt,使用java来开发前端减少了对前台js这一块的要求，类型于java swing这样的方式来做前台！之前我所在的公司所有的管理系统全部统一gwt框架，快速高效,如果有兴趣的可以联系我一起研究探讨qq:573824145
|
| 返回顶楼 | |
|
发表时间：2012-11-29
key232323 写道 feng2356 写道 看了前面的讨论,觉得有的有道理,有的和我理解的有偏颇.
我的理解是这样.首先为什么会有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中... 对或不对,请大家指正. 单纯的“java开发人员”不会因为这些工具（gwt/zk/jsf之类）就能说自己跟上了web开发的发展（所谓的趋势）。 在一个javaer都很老鸟的web开发团队里，很多情况下是没有积累过之前的js的开发方式和代码库，所以觉得gwt/jsf是最好的选择，但如果有几个同时对js也很熟悉的javaer，我想他们的想法就是用js比用java更简单，如果积累的一些最佳实践，开发起来比java开发效率更高——不过这样的人一般都抛弃去选择ruby或nodejs了 就楼主的话题，如果换成gwt之类会不是是java web开发的趋势还有得讨论，去掉java，把php这些语言的份额都忽略了就不对了 还有就是即便去掉java，我个人以为gwt只是那些不熟悉js的团队的开发选择，也不是web开发趋势，传统的request请求式的mvc还是很主流的，js端一样也有丰富成熟的库去使用，这些库的使用用js操作比用java封装一层再去操作更容易 如果你把gwt可以更换js库当做一种有价值的用途的话（比如之前用jquery ui，后来换成dojo），那这个价值可能大多数都用不到——你在考虑jquery以后会不会流行的时候java说不定已经不流行了。。。 最后说明下，要做对比，希望能同时比较熟悉厚js开发和厚java开发的基础上通过实践再做比较（我本人比较详细了解ZK和JQuery + Css Template的开发过程的，我的结论是 ZK类方式 < Js类开发方式） 记住一点，不是谁都能像YUI那帮大牛写出来那么优雅而又保证准确度的js代码。我相信95%人没这个能力。而真正开发的时候，是根据项目复杂度来选择合适的方式。从来没有说哪个更好，只有更合适。GWT可以认为是一种web前端的中间技术，它的优秀在于起码保证你的代码在不同浏览器运行是可靠的，这个可靠不只是所谓的兼容，而是你可以花更多精力在保证业务逻辑的正确性上。就一般的公司的项目规模来讲，我相信大部分公司都没有达到RIA这种富客户端级别，那么GWT本身也不会存在太多的性能问题，恰恰相反，它反而比很多js框架更适合RIA系统的开发。而复杂的RIA产品，因为涉及到大量的js代码，这个非常考究团队的js工程师的能力。如果普通项目都没用好，性能慢，那是能力问题，不是框架本身问题。 |
| 返回顶楼 | |
|
发表时间：2012-11-29
key232323 写道 feng2356 写道 如果有一天,对于js的编辑器支持能做到java的程度,那么gwt就没有什么存在价值了,
大家考虑gwt的未来趋势,那是因为js在前端越来越重要了. IDE是浮云，优秀的jser，不需要这些IDE的 优秀的工程师，IDE是利器。 |
| 返回顶楼 | |
|
发表时间：2012-11-29
witcheryne 写道 aibozeng 写道 我2006年左右，用到2008年初，也从1.1的版本开始用到2.0左右。
1.感觉GWT比较适合开发企业管理系统里 业务逻辑比较复杂、业务操作需要大而全的模块，如：取出某个数据结构树，在树节点，进行很多操作，包括拖动，编辑多个父子表信息。 2.做互联网网站，是不太适合了。 3.最近两年，不使用GWT了，改用 JQuery、DHTML等来做页面了，但是浏览器兼容经常有问题，很恼火。很是怀念GWT编译出来的代码。 最近想做个图形化的代码生成工具，觉得使用GWT来实现是个选择。 建议不要，用什么技术都会有各种问题，专注解决问题比反复折腾技术有用。 我也从gwt过来的，现在extjs，jquery都在用。 jquery+bootstrap基本能满足日常需要。 tree组建用ztree 选择最简单的方式和最熟悉的方式是对的，当对一个框架的核心不熟悉的时候，就不要用。除非你有挑战他的能力。 |
| 返回顶楼 | |
|
发表时间：2012-11-30
hengly88 写道 key232323 写道 feng2356 写道 如果有一天,对于js的编辑器支持能做到java的程度,那么gwt就没有什么存在价值了,
大家考虑gwt的未来趋势,那是因为js在前端越来越重要了. IDE是浮云，优秀的jser，不需要这些IDE的 优秀的工程师，IDE是利器。 我说的是jser——不是所有的其他语言的开发者。 还有为什么大家都潜意识的觉得掌握javascript困难？我们最近正好在做前端的整体解决方案，又了解了一些新的js框架和设计。团队的js水平一般，通过培训完全可以在框架和规范上写出良好组织的代码，最主要的是写的代码少。 我个人觉得以java的思路解决js要解决的问题，不会比直接用js去解决更有前景——而且我赞同老赵的一个观点：java是最束缚开发者思维的一门语言——不是java本身语言如何如何，主要的是java以为自己是万能的 |
| 返回顶楼 | |
|
发表时间：2012-11-30
key232323 写道 hengly88 写道 key232323 写道 feng2356 写道 如果有一天,对于js的编辑器支持能做到java的程度,那么gwt就没有什么存在价值了,
大家考虑gwt的未来趋势,那是因为js在前端越来越重要了. IDE是浮云，优秀的jser，不需要这些IDE的 优秀的工程师，IDE是利器。 我说的是jser——不是所有的其他语言的开发者。 还有为什么大家都潜意识的觉得掌握javascript困难？我们最近正好在做前端的整体解决方案，又了解了一些新的js框架和设计。团队的js水平一般，通过培训完全可以在框架和规范上写出良好组织的代码，最主要的是写的代码少。 我个人觉得以java的思路解决js要解决的问题，不会比直接用js去解决更有前景——而且我赞同老赵的一个观点：java是最束缚开发者思维的一门语言——不是java本身语言如何如何，主要的是java以为自己是万能的 谁会以java的思路去解决js的问题？两者本身语言特性都有很大不同。面向对象的东西，本身和语言没有直接关系，间接上说，它更适合用此类方法学。java有其自己的缺陷，但是说到束缚开发者思维，这个不理解。很多人貌似连java都还没玩得顺溜，就开始说这个语言那不好，这个不好。先自己能不能搞定这些目前现有的东西再说。如果拿自己开发能力的不足来抱怨说语言问题，我觉得这个有点搞笑。比较奇怪这几年，csdn等论坛一直在PK语言上的好坏，这个有点不理解，很多人连用都没用过，甚至流于表面，就人云亦云。 |
| 返回顶楼 | |
|
发表时间：2012-11-30
hengly88 写道 key232323 写道 hengly88 写道 key232323 写道 feng2356 写道 如果有一天,对于js的编辑器支持能做到java的程度,那么gwt就没有什么存在价值了,
大家考虑gwt的未来趋势,那是因为js在前端越来越重要了. IDE是浮云，优秀的jser，不需要这些IDE的 优秀的工程师，IDE是利器。 我说的是jser——不是所有的其他语言的开发者。 还有为什么大家都潜意识的觉得掌握javascript困难？我们最近正好在做前端的整体解决方案，又了解了一些新的js框架和设计。团队的js水平一般，通过培训完全可以在框架和规范上写出良好组织的代码，最主要的是写的代码少。 我个人觉得以java的思路解决js要解决的问题，不会比直接用js去解决更有前景——而且我赞同老赵的一个观点：java是最束缚开发者思维的一门语言——不是java本身语言如何如何，主要的是java以为自己是万能的 谁会以java的思路去解决js的问题？两者本身语言特性都有很大不同。面向对象的东西，本身和语言没有直接关系，间接上说，它更适合用此类方法学。java有其自己的缺陷，但是说到束缚开发者思维，这个不理解。很多人貌似连java都还没玩得顺溜，就开始说这个语言那不好，这个不好。先自己能不能搞定这些目前现有的东西再说。如果拿自己开发能力的不足来抱怨说语言问题，我觉得这个有点搞笑。比较奇怪这几年，csdn等论坛一直在PK语言上的好坏，这个有点不理解，很多人连用都没用过，甚至流于表面，就人云亦云。 好吧，不争论了，可能是我工作不需要深入java太多，导致用java不如一些动态语言使工作能更方便。反正大家只要觉得哪个框架适用自己就好了，不用管什么流行与否的。LZ这个话题只是各抒己见么 |
| 返回顶楼 | |
|
发表时间：2012-11-30
我觉得发展方向不同吧，写前端的就js了，后端肯定是java
|
| 返回顶楼 | |
|
发表时间：2013-01-04
快乐的牛 写道 GWT不会成为趋势，除了前面各位提到的优点和缺点之外，我觉得没必要用Java来“写”Javascript代码。GWT的设计初衷，我就不赞同。
Javascript作为一门动态语言，本身就比静态的Java更灵活、更强大。Javascript的开发效率、敏捷程度，是java不能比的。 Javascript编辑器的支持的确没有Java好，但是并不妨碍，写完之后直接刷新网页，调试效率高。 没必要强求成员提示，我写Java代码就一直按ESC，不让提示，一个方法用过两次就记住了，顶多用个自动补全。 我这人比较懒，离开增量编译IDE的帮助（即时错误提示），我就一行代码也不想写。 快乐的牛 写道 至于Java强大的自动重构功能，对于Javascript更是没有必要。重构的代码，说明机器能自动写，这部分代码基本上是“死的”，需要编辑器帮忙避免重复劳动。但是用Javascript，你没有必要写那么多“死的”代码，如果你写了，说明你没有利用好动态语言的特性，或者你用了一个差劲的类库。 用过python,ruby的，都会有同感吧。 这个理论头一回听说，动态语言不需要重构？ 另外js有靠谱的unit test框架么？ 貌似测试框架不少，但还是那个问题，没有编译器帮助，写js单元测试也会很痛苦。 话说一个编程语言，一没有好的IDE支持、二没有编译器检查、三不方便重构、四难以单元测试，你拿它来写几万行代码的大项目，这不是开玩笑么？ 别跟我提那些js大牛、js牛叉框架，毕竟咱们都是普通人，公司也只能招到一些普通人， 也被跟我说那么多项目不也都这么搞出来了么，我想说你见过哪个项目不是一段IT民工的血泪史啊？ |
| 返回顶楼 | |
