t*****n
发帖数: 1589 | 1 用gwt compile成javascript这样比直接写出来的javascript更新robust，而且load
更快，srrc code 也更加scalable 因为ui and logic are separated
更加clean，唯一不好就是java thick 一点而已
为什么不用java写前端，而都在讨论用javascript写后端，没有任何优势啊，code少几
行，程序员写得快，这算不上什么优势吧 |
t*****n
发帖数: 1589 | 2 why no comments, too trivial or sth?
load
【在 t*****n 的大作中提到】
: 用gwt compile成javascript这样比直接写出来的javascript更新robust，而且load
: 更快，srrc code 也更加scalable 因为ui and logic are separated
: 更加clean，唯一不好就是java thick 一点而已
: 为什么不用java写前端，而都在讨论用javascript写后端，没有任何优势啊，code少几
: 行，程序员写得快，这算不上什么优势吧
|
c*******9
发帖数: 9032 | 3 前端本来就有性能问题，还用java生成肿的code?
【在 t*****n 的大作中提到】
: why no comments, too trivial or sth?
:
: load
|
t*****n
发帖数: 1589 | 4 生成的javascript会把不用的code remove掉，gwt也有些优化，性能上不比直接写
javascript差差
【在 c*******9 的大作中提到】
: 前端本来就有性能问题，还用java生成肿的code?
|
t*****n
发帖数: 1589 | 5 javascript写的人没啥，读的人很费力，scalability也有问题
【在 t*****n 的大作中提到】
: 生成的javascript会把不用的code remove掉，gwt也有些优化，性能上不比直接写
: javascript差差
|
r****y
发帖数: 26819 | 6 现在不同啦，现在就要说是写的人自己有问题了。
【在 t*****n 的大作中提到】
: javascript写的人没啥，读的人很费力，scalability也有问题
|
n****1
发帖数: 1136 | 7 理论上我同意前端用java写是个好方案。 可固执是人的天性， 你把整个paradigm都变
了，他们接受不来. 他们只相信successful business cases, 不相信vision.
所以只能一点一点地在js里面加料， 每加一点还能引起欢呼雀跃。 c++/dart/c#这些
四不像就这么来的。 |
l*********s
发帖数: 5409 | 8 太落伍了，起码也得是dart吧，连zhoce这样写了十几年java的资深大牛都被勾引了。 |
g*****g
发帖数: 34805 | 9 这不是常见的写法。java在前端的一个短板是静态语言，需要重新编译。前端调个像素
就这么折腾，效率低。
当然现在有jrebel，能好一点。
load
【在 t*****n 的大作中提到】
: 用gwt compile成javascript这样比直接写出来的javascript更新robust，而且load
: 更快，srrc code 也更加scalable 因为ui and logic are separated
: 更加clean，唯一不好就是java thick 一点而已
: 为什么不用java写前端，而都在讨论用javascript写后端，没有任何优势啊，code少几
: 行，程序员写得快，这算不上什么优势吧
|
t*****n
发帖数: 1589 | 10 gwt 有debug mode,刷新一下就可以看效果了
【在 g*****g 的大作中提到】
: 这不是常见的写法。java在前端的一个短板是静态语言，需要重新编译。前端调个像素
: 就这么折腾，效率低。
: 当然现在有jrebel，能好一点。
:
: load
|
|
|
b***e
发帖数: 1419 | 11 这样说吧，我基本肯定你没有严肃的做过前端。你真做两年full stack就知道，GWT完
全就是一个反人类的屎逼。一般编译是吧C编译成Assembly。GWT基本上是吧Assembly编
译成C的套路。
load
【在 t*****n 的大作中提到】
: 用gwt compile成javascript这样比直接写出来的javascript更新robust，而且load
: 更快，srrc code 也更加scalable 因为ui and logic are separated
: 更加clean，唯一不好就是java thick 一点而已
: 为什么不用java写前端，而都在讨论用javascript写后端，没有任何优势啊，code少几
: 行，程序员写得快，这算不上什么优势吧
|
t*****n
发帖数: 1589 | 12
【在 b***e 的大作中提到】
: 这样说吧，我基本肯定你没有严肃的做过前端。你真做两年full stack就知道，GWT完
: 全就是一个反人类的屎逼。一般编译是吧C编译成Assembly。GWT基本上是吧Assembly编
: 译成C的套路。
:
: load
|
t*****n
发帖数: 1589 | 13 。。。现在的项目看着还挺好。没任何问题，
【在 t*****n 的大作中提到】
|
y****e
发帖数: 23939 | 14 gwt还是弱，简单的要求还可以。稍微复杂一点的就不行了。要不怎么有一个收钱的
smart gwt |
t*****n
发帖数: 1589 | 15 什么复杂的？你说那些fancy的效果之类的，卖衣服的网站那些确实
【在 y****e 的大作中提到】
: gwt还是弱，简单的要求还可以。稍微复杂一点的就不行了。要不怎么有一个收钱的
: smart gwt
|
c*********e
发帖数: 16335 | 16 gwt之流就是给那些不会写javascript的java engineer用的。写简单的可以，但是难以
深入，难以继续发展。
【在 y****e 的大作中提到】
: gwt还是弱，简单的要求还可以。稍微复杂一点的就不行了。要不怎么有一个收钱的
: smart gwt
|
d****i
发帖数: 4809 | 17 前端还是应该正正规规用前端的de facto official language-JavaScript来写，否则
还是有点隔靴挠痒的感觉。
【在 c*********e 的大作中提到】
: gwt之流就是给那些不会写javascript的java engineer用的。写简单的可以，但是难以
: 深入，难以继续发展。
|
n****1
发帖数: 1136 | 18 不觉得GUI上js能有啥优势, android不也是用java做UI, 不一样好好的.
虽然gwt很弱, 但不代表这个思路行不通吧. 我觉得最关键的是社区里面前端的人多是
js背景, 没人去开发java 的UI库.
【在 d****i 的大作中提到】
: 前端还是应该正正规规用前端的de facto official language-JavaScript来写，否则
: 还是有点隔靴挠痒的感觉。
|
P********l
发帖数: 452 | 19 你这么问肯定因为没用过. 鉴定完毕.
load
【在 t*****n 的大作中提到】
: 用gwt compile成javascript这样比直接写出来的javascript更新robust，而且load
: 更快，srrc code 也更加scalable 因为ui and logic are separated
: 更加clean，唯一不好就是java thick 一点而已
: 为什么不用java写前端，而都在讨论用javascript写后端，没有任何优势啊，code少几
: 行，程序员写得快，这算不上什么优势吧
|
g*****g
发帖数: 34805 | 20 web上唯一浏览器广泛支持的语言，优势自然是很大的。
【在 n****1 的大作中提到】
: 不觉得GUI上js能有啥优势, android不也是用java做UI, 不一样好好的.
: 虽然gwt很弱, 但不代表这个思路行不通吧. 我觉得最关键的是社区里面前端的人多是
: js背景, 没人去开发java 的UI库.
|
|
|
n****1
发帖数: 1136 | 21 我越来越觉得js像web assembly lang, 就跟x86机器码样的. 的确是广泛支持,但不值
得用手写.
【在 g*****g 的大作中提到】
: web上唯一浏览器广泛支持的语言，优势自然是很大的。
|
p*****2
发帖数: 21240 | 22
JS不是关键，关键是要有更好的framework出来。像meteor这种，使得开发简单化。
【在 n****1 的大作中提到】
: 我越来越觉得js像web assembly lang, 就跟x86机器码样的. 的确是广泛支持,但不值
: 得用手写.
|
l**********n
发帖数: 8443 | |
p*****2
发帖数: 21240 | 24
大牛现在用着最顺的是哪个framework呀？client端的？
【在 l**********n 的大作中提到】
: 后端为什么不能用js写？
|
g*****g
发帖数: 34805 | 25 最大问题是轮子太少。以前js都写不了后端，要攒出像样的轮子怎么也得个5年。
【在 l**********n 的大作中提到】
: 后端为什么不能用js写？
|
d***i
发帖数: 19 | 26 It's OK if your web are "traditional" type, which most front-end business
logic sits on the server side as well as the work-flow controlling logic,and
server returns content to browser from page to page.
The user expectations on Web UI getting higher and higher which people
always compare a Web UI with a Desktop UI in terms of look and feel.
One trend for Web UI to go is to go "Single Page Application", which need to
put flow controlling logic sit in the browser and many front-end logic is
shifted from server side to browser. You need finer control in the browser
which using the generated codes(such as GWT) might have problem with. |
F*M
发帖数: 104 | 27 你说的小程序可能可以。有些大型项目前台分模块分库就很烦人了。还有编译出来的东
西可performance不一定优。
【在 t*****n 的大作中提到】
: gwt 有debug mode,刷新一下就可以看效果了
|
F*M
发帖数: 104 | 28 这个我觉得是正解。
BTW, GWT好像已经成为一个被淘汰或即将被淘汰掉的东西。
【在 g*****g 的大作中提到】
: 这不是常见的写法。java在前端的一个短板是静态语言，需要重新编译。前端调个像素
: 就这么折腾，效率低。
: 当然现在有jrebel，能好一点。
:
: load
|
p*****2
发帖数: 21240 | 29 前端以前本来是Java的，自己不争气被小弟JS给赶跑了。 |
c*******9
发帖数: 9032 | 30 那时候web强势，不管适合不适合，都争相恐后上web。结果搞的复杂操作的也用web，
用js。
这样失败的项目不少，因为js debug太困难，难做复杂些项目。
现在是很多web前端又纷纷app化。。。
【在 p*****2 的大作中提到】
: 前端以前本来是Java的，自己不争气被小弟JS给赶跑了。
|
|
|
t*****n
发帖数: 4908 | 31 隔靴搔痒总是不解决问题。
【在 p*****2 的大作中提到】
: 前端以前本来是Java的，自己不争气被小弟JS给赶跑了。
|
t*****n
发帖数: 4908 | 32 有个1B的投资结果给废了，就是用的web+java。。。。
【在 c*******9 的大作中提到】
: 那时候web强势，不管适合不适合，都争相恐后上web。结果搞的复杂操作的也用web，
: 用js。
: 这样失败的项目不少，因为js debug太困难，难做复杂些项目。
: 现在是很多web前端又纷纷app化。。。
|
c*******9
发帖数: 9032 | 33 你说的是前端java？ 后端就没有必要用web了。
java swing也是比较繁琐，尽管灵活性高些。
【在 t*****n 的大作中提到】
: 有个1B的投资结果给废了，就是用的web+java。。。。
|
g*****g
发帖数: 34805 | 34 我看随着html和js client lib增强，server前端迟早会小众。包括node, django, ror
都要玩完。
后端直接出个webservice，html5/js 和 mobile app就给消费了，要这些server ui
framework干啥？
【在 p*****2 的大作中提到】
: 前端以前本来是Java的，自己不争气被小弟JS给赶跑了。
|
p*****2
发帖数: 21240 | 35
ror
node是server ui framework?
你说的趋势不错，不过这不正是node的优势吗？
【在 g*****g 的大作中提到】
: 我看随着html和js client lib增强，server前端迟早会小众。包括node, django, ror
: 都要玩完。
: 后端直接出个webservice，html5/js 和 mobile app就给消费了，要这些server ui
: framework干啥？
|
c*****4
发帖数: 1777 | 36 这里用JavaScript的就没有做过复杂的界面。
我曾经的一个产品就是这样做的。有几百页，每一页的UI对象都以千计。这个产品的特
点是没有程序员（开发framework和compiler的不算）。自己开发的编译器生成界面代
码（Java），GWT再将此代码编译成HTML。前后台代码加起来在100万行以上全部是生成
的，不用一个程序员。
缺点是浏览器的兼容性差。由于浏览器不断升级，维护旧版本的成本太高。产品须保证
10年有效，但是总不能要求别人用旧版本用IE 6。而且这样转出来的界面和其他平台（
如Windows下）不完全一致。
现在的方案是用Silverlight。问题是不支持平板。
准备重新上HTML5+SVG。但是Deskop上还不好解决，因为谁也不想做两套产品。
Silverlight的优点就是只有一套。
load
【在 t*****n 的大作中提到】
: 用gwt compile成javascript这样比直接写出来的javascript更新robust，而且load
: 更快，srrc code 也更加scalable 因为ui and logic are separated
: 更加clean，唯一不好就是java thick 一点而已
: 为什么不用java写前端，而都在讨论用javascript写后端，没有任何优势啊，code少几
: 行，程序员写得快，这算不上什么优势吧
|
n****1
发帖数: 1136 | 37 非常同意这个,俺的chromebook上面现在好多离线app都做的堪比传统桌面程序了, 也就
是说web界面已经达到不需要前端服务器辅助的地步了.
这些ror/django/asp.net/node本质上就是server side MVC, 是当年浏览器能力低下的
情况下不得已为之的方案. 现在浏览器都快成操作系统了, server-side MVC自然会成
了夹心饼干.还有就是随着用户量的增长, server side MVC再快也终究会吃不消, 最后
还得把计算量推给浏览器.
@peking2
node相对其他几个还是有点优势的, 就是在server前端消失后还可以回来开发客户端,
其他几个就一个子都不剩了.
ror
【在 g*****g 的大作中提到】
: 我看随着html和js client lib增强，server前端迟早会小众。包括node, django, ror
: 都要玩完。
: 后端直接出个webservice，html5/js 和 mobile app就给消费了，要这些server ui
: framework干啥？
|
p*****2
发帖数: 21240 | 38
,
node本质上就是server side MVC
我强烈鄙视你这句话。
【在 n****1 的大作中提到】
: 非常同意这个,俺的chromebook上面现在好多离线app都做的堪比传统桌面程序了, 也就
: 是说web界面已经达到不需要前端服务器辅助的地步了.
: 这些ror/django/asp.net/node本质上就是server side MVC, 是当年浏览器能力低下的
: 情况下不得已为之的方案. 现在浏览器都快成操作系统了, server-side MVC自然会成
: 了夹心饼干.还有就是随着用户量的增长, server side MVC再快也终究会吃不消, 最后
: 还得把计算量推给浏览器.
: @peking2
: node相对其他几个还是有点优势的, 就是在server前端消失后还可以回来开发客户端,
: 其他几个就一个子都不剩了.
:
|
c*****a
发帖数: 1638 | 39 谁说不用？vaadin就是这个
很好用，当然，只限于做APP类型的内部产品 |
t*****n
发帖数: 4908 | 40 都有。而且是面向工程的。出了半成品，工程师不买账，废了，layoff了所有程序员。
【在 c*******9 的大作中提到】
: 你说的是前端java？ 后端就没有必要用web了。
: java swing也是比较繁琐，尽管灵活性高些。
|
|
|
g*****g
发帖数: 34805 | 41 vaadin写个内部应用确实不错，写外部性能和花哨都不够。
【在 c*****a 的大作中提到】
: 谁说不用？vaadin就是这个
: 很好用，当然，只限于做APP类型的内部产品
|
f****p
发帖数: 18483 | 42 真的是一份付出一分收获。其实java code很烂的。 |
g*****g
发帖数: 34805 | 43 Node就是js vm罢了。但基于node的东西一般可以认为是server架构。
纯粹的html/js，就是一堆静态文件，随便一个http server就可以host. 要node干啥？
【在 p*****2 的大作中提到】
:
: ,
: node本质上就是server side MVC
: 我强烈鄙视你这句话。
|
p*****2
发帖数: 21240 | 44
how about websocket?
【在 g*****g 的大作中提到】
: Node就是js vm罢了。但基于node的东西一般可以认为是server架构。
: 纯粹的html/js，就是一堆静态文件，随便一个http server就可以host. 要node干啥？
|
n****1
发帖数: 1136 | 45 websocket不就一个类似于端口转发的东西吗？ 连apace/nginx这种静态服务器都能做
到。
你提的东西越来越底层， 直接把node下降到静态服务器的地步, 离后端服务越来越远
了。
【在 p*****2 的大作中提到】
:
: how about websocket?
|
p*****2
发帖数: 21240 | 46
不知道你再说什么
【在 n****1 的大作中提到】
: websocket不就一个类似于端口转发的东西吗？ 连apace/nginx这种静态服务器都能做
: 到。
: 你提的东西越来越底层， 直接把node下降到静态服务器的地步, 离后端服务越来越远
: 了。
|
h******k
发帖数: 388 | 47 哪位科普一下Node到底是做什么的？我的理解其中一个用处是代替web server (apache
or tomcat for example).所以Node可以做web services的host?
【在 p*****2 的大作中提到】
:
: 不知道你再说什么
|
Y**G
发帖数: 1089 | 48 Android app算前端吧，大多数人是用Java写的。
load
【在 t*****n 的大作中提到】
: 用gwt compile成javascript这样比直接写出来的javascript更新robust，而且load
: 更快，srrc code 也更加scalable 因为ui and logic are separated
: 更加clean，唯一不好就是java thick 一点而已
: 为什么不用java写前端，而都在讨论用javascript写后端，没有任何优势啊，code少几
: 行，程序员写得快，这算不上什么优势吧
|
z****e
发帖数: 54598 | 49 没有十几年哦
dart还需要时间
但是dart的产生是因为非oo无法作出相应的优化
所以才需要oo
dart替代掉js只是时间问题
我相信googlers的能力
【在 l*********s 的大作中提到】
: 太落伍了，起码也得是dart吧，连zhoce这样写了十几年java的资深大牛都被勾引了。
|
z****e
发帖数: 54598 | 50 是，我也有这个感觉，越做越底层，不胜其烦
等于把轮子给定制了，vert.x我只是觉得用来统一多语言modules好用
其它的作为server，我觉得用apache/tomcat蛮好
【在 n****1 的大作中提到】
: websocket不就一个类似于端口转发的东西吗？ 连apace/nginx这种静态服务器都能做
: 到。
: 你提的东西越来越底层， 直接把node下降到静态服务器的地步, 离后端服务越来越远
: 了。
|
|
|
z****e
发帖数: 54598 | 51 就是监听一个port
然后作出相应的response
比传统的http server多了点监听端口
还有就是，你response的时候，可以自由选择框架
就是一个很低级的封装，为了单线程和异步而搞的
理解这个理论比单纯去用这个产品更重要
apache
【在 h******k 的大作中提到】
: 哪位科普一下Node到底是做什么的？我的理解其中一个用处是代替web server (apache
: or tomcat for example).所以Node可以做web services的host?
|
z****e
发帖数: 54598 | 52 动态，脚本
都是后端的死穴
能写的话，php早搞定了
还需要等到现在
【在 l**********n 的大作中提到】
: 后端为什么不能用js写？
|
z****e
发帖数: 54598 | 53 swing是因为m$还有sun本身的人就很书呆
不懂gui最重要的是客户体验，过于关注跨平台而不愿意针对平台做优化
swing比起c++来说还是容易写
javafx蛮好，不过需要时间
【在 c*******9 的大作中提到】
: 你说的是前端java？ 后端就没有必要用web了。
: java swing也是比较繁琐，尽管灵活性高些。
|
z****e
发帖数: 54598 | 54 呵呵，我写过哦
我觉得mimisoft说的那个robovm很好
已经开始收费了
【在 c*****4 的大作中提到】
: 这里用JavaScript的就没有做过复杂的界面。
: 我曾经的一个产品就是这样做的。有几百页，每一页的UI对象都以千计。这个产品的特
: 点是没有程序员（开发framework和compiler的不算）。自己开发的编译器生成界面代
: 码（Java），GWT再将此代码编译成HTML。前后台代码加起来在100万行以上全部是生成
: 的，不用一个程序员。
: 缺点是浏览器的兼容性差。由于浏览器不断升级，维护旧版本的成本太高。产品须保证
: 10年有效，但是总不能要求别人用旧版本用IE 6。而且这样转出来的界面和其他平台（
: 如Windows下）不完全一致。
: 现在的方案是用Silverlight。问题是不支持平板。
: 准备重新上HTML5+SVG。但是Deskop上还不好解决，因为谁也不想做两套产品。
|
z****e
发帖数: 54598 | 55 java可以写
js很垃圾，写起来很苦逼
gwt算是解决了一部分问题
但是浏览器上的应用本身就是苦逼到死的工作
没多少人乐意干
还有浏览器和app上的整合
omg
总有人尝试只做一个界面然后自动跨所有平台，包括浏览器
但是现实总是会证明，你还不如针对不同平台都做一个来得省钱省力
简单说就是gui没那么容易搞，政治斗争太激烈了
load
【在 t*****n 的大作中提到】
: 用gwt compile成javascript这样比直接写出来的javascript更新robust，而且load
: 更快，srrc code 也更加scalable 因为ui and logic are separated
: 更加clean，唯一不好就是java thick 一点而已
: 为什么不用java写前端，而都在讨论用javascript写后端，没有任何优势啊，code少几
: 行，程序员写得快，这算不上什么优势吧
|
