锁定老帖子 主题:“XML应用程序”的演示程序
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2009-09-29
最后修改:2009-09-29
yipsilon 写道 pufan 写道 yipsilon 写道 pufan 写道 代码全在XML里?那Java的强类型OOP优势岂不完全丧失,IDE的编译检查、重构、调试等等岂不也荡然无存了?
既然是平台环境,那能带给程序员的好处是什么?比java(eclipse)的平台环境又有什么优势? 找个跟本想法类似的技术,那非HTML莫属,Java端只是解释器和插件实现,或许以后其他语言中也有OSGi技术了,也可以用其他语言来实现,所以这跟Java没有关系的。 调试问题之前也说过了,只要解释器做得比较完美,那调试跟踪是不成问题的。 这个想法目前我所认为直接带来的好处就是降低了学习门槛和实现快速开发能力,最起码可以快速构建简单的应用程序,或者程序界面原型。 姑且认为解释器、开发环境都已成熟,可以与eclipse相媲美了。 那么我们再看: 学习门槛有降低吗?底层用java(swing)的话是不是还得学习java(swing),另外还得学习XML的相关配置。 复用是快速开发的不二法则,配置放到哪里和快速开发关系不大,最终的代码复用岂不还是Java类。至于配置简单,我同样可以基于java class写一个脚手架,配置一样简单,同时还有ide的天生支持。 简单应用程序没有说服力,毕竟我们要做的绝不是example。那么这个开发环境驾驭复杂应用的能力又如何? 还是拿html来说明问题吧。 你应该这么比,如果实现一个Java和HTML都能做出来的界面(例如一个界面里只有一个按钮,点击后弹出对话框),用HTML快还是用Java快呢? 快速开发有两个实际过程: 第一个是构建过程,也就是说从头写代码,如果html和java都用设计器来说,效率是不差上下的,但如果是写代码,网页设计人员只需要懂得html的知识即可,而java开发人员则不仅仅需要懂得java语法,还要学会UI库,例如swing或者swt,学习门槛高了。 第二个是调整过程,也就是在原来的基础上对界面细节进行修改,这样的话,HTML与Java的开发效率就明显了,HTML只需要在文本文件里修改几项就可以搞定,而java源代码改完后,还需要重新编译,打包运行,如果想半自动化搞,还需要打开IDE。 这两个过程中,可以看出HTML和Java的开发效率差别了。这其实也是众多脚本的优势所在,只是XML语法相比其他脚本语言的学习门槛比较低,更何况也已经被大部分人接受了(在web上的html、xhtml都是其近亲)。 我认为做一个东西,要从简单的开始,哪怕最开始只是一个空白的界面,只要能运行起来,就会有动力去继续开发。当前兄台的说法,就好比拿Java 1.0版跟1.6版相比一样,从1.0到1.6演变势必要有个过程。更何况,我一直都在强调目前只是一个想法,连内部开发版都不是,不要这么较真嘛,呵呵。 需求,有求则有应,市场决定一切。 html(flex,javaFX)的市场定位很明确,满足互联网浏览的用户需要。 java(Swing,swt)的定位也很明确,满足使用桌面程序的用户需要。 你的想法的用户群是那些人呢?又有多少?目前来看,在以上两个领域挑战竞争对手难度不是一般的大,个人对此项目的前景亦不看好,除非你能找到其他蓝海领域。 其实反过来看,为什么非要是挑战,而不能是增强呢? 想要看的高,不需要长得高,踩在他人的肩膀上多好。 |
|
返回顶楼 | |
发表时间:2009-09-29
最后修改:2009-09-30
pufan 写道 需求,有求则有应,市场决定一切。
html(flex,javaFX)的市场定位很明确,满足互联网浏览的用户需要。 java(Swing,swt)的定位也很明确,满足使用桌面程序的用户需要。 你的想法的用户群是那些人呢?又有多少?目前来看,在以上两个领域挑战竞争对手难度不是一般的大,个人对此项目的前景亦不看好,除非你能找到其他蓝海领域。 其实反过来看,为什么非要是挑战,而不能是增强呢? 想要看的高,不需要长得高,踩在他人的肩膀上多好。 侠义上来讲,问题就出在没有中间市场,例如会html的人想处理一些数据然后保存到文件中,在浏览器上做显然是不可能的。 广义上来讲,脚本语言能做什么此程序就能干什么,不是么?既然JVM现在非常支持将其他脚本嵌入到java中,兄台怎么能说出是挑战而非增强的话呢(引用的粗体文字)?难道是我说的?呵呵。 市场是由应用决定的,而不是平台决定的,平台再好而没有在上面的应用,那也是没市场的。现在研究会有多少人用没有意义,如果有一些非常棒的Bundles应用,那相信会有很多人会去用的。 |
|
返回顶楼 | |