AIR, 我已经对你彻底失望了.

这不是一篇客观全面的评论 只是一种情绪的表达.

希望大家不要只注意我文中“愤青”的一方面，而忽视文中提到的那些AIR和adobe的问题。

最近我打算写一篇 比较详细的“AIR到底哪些地方不好 以及 我期望的AIR应该是什么样子”
虽然 也是以 我自己的视角来看 但是一定会比这篇更客观 摆事实讲道理
敬请期待。
另： 我从来没想过打击flashbuilder 和 flex ，我对他们没什么感觉。



BTW :
vii779 ltian znjq  等几位朋友的跟帖讨论 要比主贴更精彩
建议关注flex 开发的同学看一下.
(虽然我主贴是关于 AIR的 但是我不介意在这里讨论 flex的问题 呵呵
因为关于flex 其实我也有很多话想说)

我关于AIR的具体的分析贴 打算在AIR 2.0正式推出 并且我使用过之后再写.
但是不管怎样 如后面一位朋友所言 我对AIR更多的是一种恨铁不成钢的感觉 而没有绝对的恶意.



adobe 有了 AIR这样一个 好东西(至少想法和创意是好的), 但是眼看着一个好东西被adobe糟蹋了.
成天 flash flash flash...完全无视 html ajax 开发人员在 AIR下的诉求

同样是 webkit 内核 效率比 chrome safari 低了不是一点半点.

而且很多很基本的功能都不肯实现.

作为国内 比较早的一批使用 AIR+ajax模式搞开发的程序员 我很失望.

最初AIR带给我的惊喜正在一点点的消失.

我实在不理解adobe是怎么想的.

================================


我在twitter上曾经说过:

引用

AIR的伟大之处在于可以让广大熟悉html编程的人也可以快速的掌握开发客户端软件的能力. 这是好事.熟悉html开发人员要比熟悉SWING .net(桌面开发)的人多很多


苹果有浏览器 有操作系统 有硬件，google有浏览器 有操作系统 有硬件，微软亦然。所以他们在谈论起在“互联网应用的UI要使用什么技术”时 明显有更大的话语权和更足的底气。而Adobe能拿得出手的只有需要寄人篱下的“flash”。所以AIR对于adobe的意义还是很大的。


虽然外界一直把HTML5当做 flash的对手偶.但是adobe千万不能这样看,adobe应该把html5变成自己的武器,让旗下的产品加强对html5的支持...好吧,我承认我太过迷恋AIR+Ajax的开发模式了...
(从最新发布的cs5的特性来看 adobe已经意识到这点了 GJ! XD)


我在AIR里用js+html5 canvas开发一个动画示例,在chrome safari中能跑到每秒90帧左右,在AIR里勉强18帧(且很不稳定).抱怨一下.我实在是没地方抱怨了


突然发现 我搞AIR+Ajax开发好尴尬. 纯Web开发流 纯Native桌面应用开发流 都不待见我.而Adobe流又都是搞flash的 更是一副跟我势不两立的架势.我好无辜...


google chrome捆绑flash也只是暂时的，当他发现这么做并不会帮助他进一步扩大市场占有率时 他随时都可以放弃这种捆绑


adobe的flash需要运行在别人的浏览器和操作系统里 而且这个“别人”还是adobe的竞争对手…那被别人耍被别人欺负被别人当作博弈的筹码就不足为奇了.

....

我在推特上的话 可能只是一些牢骚 只是一些主观视角强烈的妄语,但是至少说明我----一个曾经的AIR坚决的拥护者 已经开始对它厌倦了.

================================

ExtJS 的官方IDE已经抛弃AIR了 使用了 QTWebkit

google的chrome 开始支持 native client技术了 html5 webgl也来了

摆在我面前的选择真的很多 AIR 我是不是应该放弃你了?

================================
adobe 如果想在未来的互联网领域内占有一席之地 拥有一定的话语权.
AIR 应该是一部很关键的棋子

用更加开放的态度去拥抱HTML5才是王道.

(例如让AIR 和 dreamweaver更好的支持html5的特性 开发出基于html5 canvas/svg的动画制作工具 等等,
甚至做一个 浏览器 --- AIR都可以做出来 做浏览器自然也不是问题...)

================================

好吧 我承认我的担心有点多余.

靠着ps ai pdf 这些东西 adobe 就已经可以把自己喂的很饱了.

好吧 我知道我的牢骚很傻很BI ,

闪客们靠着"世界上98%的计算机都装有flash插件"这句话 就可以让自己心满意足 高枕无忧了

恩 各位 adobe的粉丝们 无视我吧.


====================

补充:

我本人 不会flash (只会一点as3 摆弄过一阵flex), 也不打算深入学习这项技术
但是我 对flash并没有敌对情绪  我一直觉得 flash在很多领域是无法被替代的.

就算未来浏览器很NB了 可以在浏览器里面看电影 听音乐 玩使命召唤, 那flash也不会消亡.
而且会活得很长很长, flash的寿命绝对比目前所有的闪客们的职业生涯要长久.

但是 adobe 必须面对html5的挑战
不管flash的卫道士们 怎样高喊"HTML5不是flash杀手" "flash无法被替代", "html5的到来还很漫长" "html5的统一化 标准化更漫长"...
html5 都是adobe无法回避的.

与其酸酸的去说  "html5将把互联网带入黑暗"(详见这里) 不如用开放的胸怀去接纳它.

评论

58 楼 fins 2010-04-14  

ltian 写道

vii779 写道

关于setStyle的问题，都建议尽量不要调用，会导致性能低下。

假设我写了一个renderer,里面有一个lable组件，我希望根据数值的大小显示不同的颜色，比如大于100显示红色，小于100显示蓝色，很自然的我会这么写

<mx:Label text="{data}" color="{data>100?0xff0000:0x0000ff}"/>

很遗憾这样是行不通的，首先样式是不支持值绑定的。好吧，hack一把让样式支持值绑定，然后你又会被告知setStyle会带来低下的性能问题。

我想这是一个再普通不过的需求了，解决这个问题会有好几种办法，要么写复杂的AS3代码，要么再冗余一个Label，但是不论哪一种都不如上面来的直接简单和自然。如果setStyle没有性能问题，如果样式支持值绑定，整个世界就变的清净了。话说回来了，这个世界又那会有十全十美的东西，要么您就期待Flex一点一点慢慢改进吧，要么您就去封装自己的组件库吧。

顺便一提，Flex默认的几个Renderder都是用As3写的，创建和布局逻辑代码不少，如果你想继承一下扩展一把，那是不行地，里面几个关键的变量和方法都是私有的。期望Flex以后在设计API的时候，能够抱着更加开放的态度，以利于大家扩展，才有可能形成一个成熟的组件库市场的氛围。

原来您是这样理解Flex组件开发的，难怪！

vii779这么理解有什么不妥吗? 你是怎么看的?


BTW :
vii779 ltian znjq  等几位朋友的跟帖讨论 要比主贴更精彩
建议关注flex 开发的同学看一下.
(虽然我主贴是关于 AIR的 但是我不介意在这里讨论 flex的问题 呵呵
因为关于flex 其实我也有很多话想说)

我关于AIR的具体的分析贴 打算在AIR 2.0正式推出 并且我使用过之后再写.
但是不管怎样 如后面一位朋友所言 我对AIR更多的是一种恨铁不成钢的感觉 而没有绝对的恶意.

57 楼 ltian 2010-04-13  

vii779 写道

关于setStyle的问题，都建议尽量不要调用，会导致性能低下。

假设我写了一个renderer,里面有一个lable组件，我希望根据数值的大小显示不同的颜色，比如大于100显示红色，小于100显示蓝色，很自然的我会这么写

<mx:Label text="{data}" color="{data>100?0xff0000:0x0000ff}"/>

很遗憾这样是行不通的，首先样式是不支持值绑定的。好吧，hack一把让样式支持值绑定，然后你又会被告知setStyle会带来低下的性能问题。

我想这是一个再普通不过的需求了，解决这个问题会有好几种办法，要么写复杂的AS3代码，要么再冗余一个Label，但是不论哪一种都不如上面来的直接简单和自然。如果setStyle没有性能问题，如果样式支持值绑定，整个世界就变的清净了。话说回来了，这个世界又那会有十全十美的东西，要么您就期待Flex一点一点慢慢改进吧，要么您就去封装自己的组件库吧。

顺便一提，Flex默认的几个Renderder都是用As3写的，创建和布局逻辑代码不少，如果你想继承一下扩展一把，那是不行地，里面几个关键的变量和方法都是私有的。期望Flex以后在设计API的时候，能够抱着更加开放的态度，以利于大家扩展，才有可能形成一个成熟的组件库市场的氛围。

原来您是这样理解Flex组件开发的，难怪！

56 楼 matt.u 2010-04-13  

Flex的SDK封装得的确让人很恼火，官方的SDK就像大家说的“从性能、体积、灵活性和可扩展性这几方面都不理想”，想自己在Flex中实现一个可拖拽的组件，还没写逻辑，一继承UIComponent就是一两百k，让人郁闷。只希望adobe在Flash Builder上多下点功夫，真正让Flash Builder可以用起来。

55 楼 vii779 2010-04-13  

关于setStyle的问题，都建议尽量不要调用，会导致性能低下。

假设我写了一个renderer,里面有一个lable组件，我希望根据数值的大小显示不同的颜色，比如大于100显示红色，小于100显示蓝色，很自然的我会这么写

<mx:Label text="{data}" color="{data>100?0xff0000:0x0000ff}"/>

很遗憾这样是行不通的，首先样式是不支持值绑定的。好吧，hack一把让样式支持值绑定，然后你又会被告知setStyle会带来低下的性能问题。

我想这是一个再普通不过的需求了，解决这个问题会有好几种办法，要么写复杂的AS3代码，要么再冗余一个Label，但是不论哪一种都不如上面来的直接简单和自然。如果setStyle没有性能问题，如果样式支持值绑定，整个世界就变的清净了。话说回来了，这个世界又那会有十全十美的东西，要么您就期待Flex一点一点慢慢改进吧，要么您就去封装自己的组件库吧。

顺便一提，Flex默认的几个Renderder都是用As3写的，创建和布局逻辑代码不少，如果你想继承一下扩展一把，那是不行地，里面几个关键的变量和方法都是私有的。期望Flex以后在设计API的时候，能够抱着更加开放的态度，以利于大家扩展，才有可能形成一个成熟的组件库市场的氛围。

54 楼 znjq 2010-04-13  

做一些不是很个性化的数据展现类型的企业应用,flex开发比较快,也比较方便.
涉及到一些个性化以及类似图文展现的应用,就只能自行写as来开发组件,或者用一些hack的方式来处理.
UIComponent确实感觉冗余了点,动不动一个类就上万行的代码,让人吐血.
至少从代码模型上和ExtJs还差很多,Ext也有Ext的问题...

53 楼 ltian 2010-04-13  

vii779 写道

Flex 中的list，dataGrid，下拉列表框，tree 是比较常用的了，在呈现大量数据的时候，的确有一定性能上的优势，因为它的renderer是复用的。如果仅仅是简单的数据呈现，也没什么问题。但是实际应用中，renderer都是比较个性化的，当你精心构造好了一个renderer交给list呈现的时候，性能的问题就来了，创建要白屏一会，滚动的时候开始变卡。不要告诉我你应该优化你的renderder让它变的尽量简单，事实是flex组件创建速度太慢，应该优化的是flex组件。后来还是自己实现了，性能和功能还算比较理想。Flex组件性能的提升空间还是很大的，不过其生命周期过于复杂，整个就是奔着一重量级方向去的，期待其轻量化，也是不太可能了。

个人感觉Flex组件在应对一些个性化界面方面有些心不从心，如果去扩展现有组件，性能上绕不过去，整个框架限制的比较死，可扩展的余地也不是很大。

列举一下Flex使用中感觉不顺的地方，可能有些地方已经有比较好的解决办法了，罗列一下，仅供参考。

1 mxml编译速度过慢，在同时编写多个模块的时，等待编译的时间比较折磨人。
2 css 选择器实在太弱，给开发增加了不必要的代码量，此情况在Flex4中已有所改善
3 tree组件没有横向滚动条，是有意为之，还是有待完善
4 dataGrid横向滚动会卡
5 label组件的文本截取算法效率太低，整个把文本全扫描了一遍，应该换为更好一点的二分查找算法
6 tooltip的消失延迟时间是全局的，不能单独定制
7 richeditor整个就是封装死的，你想扩展都无从下手，当然可以通过一些hack手段可以做到
8 基于list的组件如dataGrid,tree等在可变行高情况下，滚动条的算位不准
9 UICompoent的生命周期过于复杂，导致组件创建速度偏慢，创建50个checkbox，就能开始感到短暂的白屏，后来学乖了，在有大量界面组件的时候，不敢再用Flex组件的，改用flash的simplebutton，性能提升显著。
10 renderder不能写的太复杂，会有性问题，严重限制了创意的表达，后来改为自己实现组件
11 一些需要文本呈现的地方，如list,datagrid,tree,tooltip如果能直接支持html格式会更实用一些，虽然做一些扩展也能做到
12 对html格式支持的比较弱，在做html呈现的时候，不太理想。
13 repeater组件超难用

FLex组件生命周期理解透彻了可能某些问题会得以解决。如果在组件代码中使用setStyle方法，会导致性能奇慢。

52 楼 vii779 2010-04-13  

Flex 中的list，dataGrid，下拉列表框，tree 是比较常用的了，在呈现大量数据的时候，的确有一定性能上的优势，因为它的renderer是复用的。如果仅仅是简单的数据呈现，也没什么问题。但是实际应用中，renderer都是比较个性化的，当你精心构造好了一个renderer交给list呈现的时候，性能的问题就来了，创建要白屏一会，滚动的时候开始变卡。不要告诉我你应该优化你的renderder让它变的尽量简单，事实是flex组件创建速度太慢，应该优化的是flex组件。后来还是自己实现了，性能和功能还算比较理想。Flex组件性能的提升空间还是很大的，不过其生命周期过于复杂，整个就是奔着一重量级方向去的，期待其轻量化，也是不太可能了。

个人感觉Flex组件在应对一些个性化界面方面有些心不从心，如果去扩展现有组件，性能上绕不过去，整个框架限制的比较死，可扩展的余地也不是很大。

列举一下Flex使用中感觉不顺的地方，可能有些地方已经有比较好的解决办法了，罗列一下，仅供参考。

1 mxml编译速度过慢，在同时编写多个模块的时，等待编译的时间比较折磨人。
2 css 选择器实在太弱，给开发增加了不必要的代码量，此情况在Flex4中已有所改善
3 tree组件没有横向滚动条，是有意为之，还是有待完善
4 dataGrid横向滚动会卡
5 label组件的文本截取算法效率太低，整个把文本全扫描了一遍，应该换为更好一点的二分查找算法
6 tooltip的消失延迟时间是全局的，不能单独定制
7 richeditor整个就是封装死的，你想扩展都无从下手，当然可以通过一些hack手段可以做到
8 基于list的组件如dataGrid,tree等在可变行高情况下，滚动条的算位不准
9 UICompoent的生命周期过于复杂，导致组件创建速度偏慢，创建50个checkbox，就能开始感到短暂的白屏，后来学乖了，在有大量界面组件的时候，不敢再用Flex组件的，改用flash的simplebutton，性能提升显著。
10 renderder不能写的太复杂，会有性问题，严重限制了创意的表达，后来改为自己实现组件
11 一些需要文本呈现的地方，如list,datagrid,tree,tooltip如果能直接支持html格式会更实用一些，虽然做一些扩展也能做到
12 对html格式支持的比较弱，在做html呈现的时候，不太理想。
13 repeater组件超难用

51 楼 ltian 2010-04-13  

fins 写道

ltian 写道

fins 写道

flasheep 写道

一种技术而已 开发者的目的是完成客户的需求 手段不重要 也没有什么完美的和一劳永逸的东西 发这样的文章好奇怪

你这种抽象 宏观 毫无破绽的论调 跟谁学的? 学点有用的好不好? 假大空的套话少说点 多去学学技术.

向楼主这样关心具体技术是值得学习的，但是抽象宏观也是一种能力，我觉得生命力持久的技术真的还在于抽象和宏观的东西，他们和具体语言及开发工具IDE关系不大：诸如：
1.企业核心语义模型（ESM）。
2.面向对象的设计模式。
3.有关权限，工作流，消息，任务，排程，定价、图形组态等公共的技术平台类模型。

我们中国当前在计算机方面专研微观领域的人很多，学语言学的很精的人也很多，但是我们在抽象模型方面研究的太少了，同样是一个新的语言或开发工具出来之后，没多久，老外的公司就会拿出一套非常强的产品。比如Flex/Flash的仪表盘组件（ILOG公司开发的东西），还有像做EMS、ERP或者其他领域的一些产品。而我们却迟迟不能拿出自己的东西，并不是我们对语言工具不熟，而是我们对该领域模型不熟悉，所以我们拿不出什么核心产品。我们精通C语言，C++语言的人很多，又多少人熟悉编译原理和编译器的模型呢？有多少人熟悉数据库操作系统模型呢？我们不掌握核心的模型和方法论，这才是中国技术落后的根本原因。如果把抽象宏观的东西当成了毫无用处的东西，那么我觉得是很危险的，我们需要一流的程序员，也需宏观抽象能力很强的架构师，二者之间没有高下之分。
   话又说回来，关于Flex，我认为它只是一套SDK及其开发ＩＤＥ，它不可能圆满地解决所有领域的东西，就Flex组件库本身来说，如果做图形化的工作，直接从Flex　SDK下继承确实效率较低，开发者可以从Flash 的SDK下继承开发。但是针对数据输入展示的控件，比如dataGrid，下拉列表框，tree等的效率还是不错的，至少客户是能够忍受的。我们的团队从2007年9月开始使用Flex开发电力企业应用，在这个领域，Flex组件的体积、运行效率等问题并不突出，据使用过Flex和ExtJs提取大量数据在表格中展示的同事们报告说，Flex的执行效率远高于ExtJs的。所以本人认为在企业开发领域，Flex的优点是显著的，在图形化和BI领域，使用Flash的类库也会使得问题得以解决，因此完美的技术解决方案几乎是不存在的。我个人在企业应用开发领域是推崇Flex，确实它能带来极高的开发效率和良好的用户交互体验，目前还没有更成熟的产品能超过Flex。
   当然，Flex仅仅是展现层的一种开发技术，对我个人而言，我认为企业核心语义模型、应用系统架构的分层，系统、应用、模块、组件及服务之间的模型和关系更为重要。如果这些底层的东西做的好的话，换一个展现层的东西是不会伤筋动骨的。   一家之言，仅供参考。

看来不管我怎么努力 话题还是不可避免的被引到 flex上.
其实 flex在现阶段唯一可取的就是 在处理大数据量时带来的性能优势了.
而flex在开发时所表现出来的优点我觉得也无外乎以下几条:
1 有好的开发工具
2 as3 可以是强类型的 可以在开发期纠错
3 基于标签的UI编码方式 (这个说它是优点 主要是让熟悉html 和 jsptag的开发人员用起来更习惯)

而一但需求稍微复杂一点 扩展flex的控件 就是一件很头疼的事情.
大量的as避免不了.

当然 我说的这个缺点主要还是集中在 "Flex自带的组件不够多 组件的接口和事件不够丰富 扩展不够方便"
是的 最大的不足就在这里

组件化程度不高 我反复的强调过很多次这个问题. 而企业级开发中 这个问题是很重要的.

直接牵涉到快速开发 后期维护 系统一致性 等很多问题.

记得以前有个 第三方的flex扩展组件库 可惜后来死掉了
如果它能够很好的发展 作为flex一个有效的补充 也许flex的情况就会好很多.


关于flex组件化程度 你可以拿flex和extjs中 同样的组件做个对比 看看extjs的组件所提供的接口 事件 用户体验以及扩展方式.
对比一下就知道了 flex作为一个世界级大公司的 重要产品 它应该感到羞愧的.

关于Flex组件化我是看了其组件化源码的，对其生命周期是很了解，我不了解ExtJs的组件模型，所以我不敢说二者谁强谁弱，但是我以前用Delphi开发过组件，很明显组件化开发要比Dlephi强很多，简单很多。如果您对FLex组件生命周期也很了解的话，我相信你说的是客观的。对于ExtJS到底谁更适合企业应用的UI层开发，希望更多人进行讨论，有人用过Flex吃过亏，也有人用ExtJs吃过亏，大家多讨论，多ＰＫ，问题才能阐述清楚，感谢楼主提供了一个可以引起大家兴趣的帖子。

50 楼 fins 2010-04-13  

ltian 写道

fins 写道

flasheep 写道

一种技术而已 开发者的目的是完成客户的需求 手段不重要 也没有什么完美的和一劳永逸的东西 发这样的文章好奇怪

你这种抽象 宏观 毫无破绽的论调 跟谁学的? 学点有用的好不好? 假大空的套话少说点 多去学学技术.

向楼主这样关心具体技术是值得学习的，但是抽象宏观也是一种能力，我觉得生命力持久的技术真的还在于抽象和宏观的东西，他们和具体语言及开发工具IDE关系不大：诸如：
1.企业核心语义模型（ESM）。
2.面向对象的设计模式。
3.有关权限，工作流，消息，任务，排程，定价、图形组态等公共的技术平台类模型。

我们中国当前在计算机方面专研微观领域的人很多，学语言学的很精的人也很多，但是我们在抽象模型方面研究的太少了，同样是一个新的语言或开发工具出来之后，没多久，老外的公司就会拿出一套非常强的产品。比如Flex/Flash的仪表盘组件（ILOG公司开发的东西），还有像做EMS、ERP或者其他领域的一些产品。而我们却迟迟不能拿出自己的东西，并不是我们对语言工具不熟，而是我们对该领域模型不熟悉，所以我们拿不出什么核心产品。我们精通C语言，C++语言的人很多，又多少人熟悉编译原理和编译器的模型呢？有多少人熟悉数据库操作系统模型呢？我们不掌握核心的模型和方法论，这才是中国技术落后的根本原因。如果把抽象宏观的东西当成了毫无用处的东西，那么我觉得是很危险的，我们需要一流的程序员，也需宏观抽象能力很强的架构师，二者之间没有高下之分。
   话又说回来，关于Flex，我认为它只是一套SDK及其开发ＩＤＥ，它不可能圆满地解决所有领域的东西，就Flex组件库本身来说，如果做图形化的工作，直接从Flex　SDK下继承确实效率较低，开发者可以从Flash 的SDK下继承开发。但是针对数据输入展示的控件，比如dataGrid，下拉列表框，tree等的效率还是不错的，至少客户是能够忍受的。我们的团队从2007年9月开始使用Flex开发电力企业应用，在这个领域，Flex组件的体积、运行效率等问题并不突出，据使用过Flex和ExtJs提取大量数据在表格中展示的同事们报告说，Flex的执行效率远高于ExtJs的。所以本人认为在企业开发领域，Flex的优点是显著的，在图形化和BI领域，使用Flash的类库也会使得问题得以解决，因此完美的技术解决方案几乎是不存在的。我个人在企业应用开发领域是推崇Flex，确实它能带来极高的开发效率和良好的用户交互体验，目前还没有更成熟的产品能超过Flex。
   当然，Flex仅仅是展现层的一种开发技术，对我个人而言，我认为企业核心语义模型、应用系统架构的分层，系统、应用、模块、组件及服务之间的模型和关系更为重要。如果这些底层的东西做的好的话，换一个展现层的东西是不会伤筋动骨的。   一家之言，仅供参考。

看来不管我怎么努力 话题还是不可避免的被引到 flex上.
其实 flex在现阶段唯一可取的就是 在处理大数据量时带来的性能优势了.
而flex在开发时所表现出来的优点我觉得也无外乎以下几条:
1 有好的开发工具
2 as3 可以是强类型的 可以在开发期纠错
3 基于标签的UI编码方式 (这个说它是优点 主要是让熟悉html 和 jsptag的开发人员用起来更习惯)

而一但需求稍微复杂一点 扩展flex的控件 就是一件很头疼的事情.
大量的as避免不了.

当然 我说的这个缺点主要还是集中在 "Flex自带的组件不够多 组件的接口和事件不够丰富 扩展不够方便"
是的 最大的不足就在这里

组件化程度不高 我反复的强调过很多次这个问题. 而企业级开发中 这个问题是很重要的.

直接牵涉到快速开发 后期维护 系统一致性 等很多问题.

记得以前有个 第三方的flex扩展组件库 可惜后来死掉了
如果它能够很好的发展 作为flex一个有效的补充 也许flex的情况就会好很多.


关于flex组件化程度 你可以拿flex和extjs中 同样的组件做个对比 看看extjs的组件所提供的接口 事件 用户体验以及扩展方式.
对比一下就知道了 flex作为一个世界级大公司的 重要产品 它应该感到羞愧的.

49 楼 ltian 2010-04-13  

fins 写道

flasheep 写道

一种技术而已 开发者的目的是完成客户的需求 手段不重要 也没有什么完美的和一劳永逸的东西 发这样的文章好奇怪

你这种抽象 宏观 毫无破绽的论调 跟谁学的? 学点有用的好不好? 假大空的套话少说点 多去学学技术.

向楼主这样关心具体技术是值得学习的，但是抽象宏观也是一种能力，我觉得生命力持久的技术真的还在于抽象和宏观的东西，他们和具体语言及开发工具IDE关系不大：诸如：
1.企业核心语义模型（ESM）。
2.面向对象的设计模式。
3.有关权限，工作流，消息，任务，排程，定价、图形组态等公共的技术平台类模型。

我们中国当前在计算机方面专研微观领域的人很多，学语言学的很精的人也很多，但是我们在抽象模型方面研究的太少了，同样是一个新的语言或开发工具出来之后，没多久，老外的公司就会拿出一套非常强的产品。比如Flex/Flash的仪表盘组件（ILOG公司开发的东西），还有像做EMS、ERP或者其他领域的一些产品。而我们却迟迟不能拿出自己的东西，并不是我们对语言工具不熟，而是我们对该领域模型不熟悉，所以我们拿不出什么核心产品。我们精通C语言，C++语言的人很多，又多少人熟悉编译原理和编译器的模型呢？有多少人熟悉数据库操作系统模型呢？我们不掌握核心的模型和方法论，这才是中国技术落后的根本原因。如果把抽象宏观的东西当成了毫无用处的东西，那么我觉得是很危险的，我们需要一流的程序员，也需宏观抽象能力很强的架构师，二者之间没有高下之分。
   话又说回来，关于Flex，我认为它只是一套SDK及其开发ＩＤＥ，它不可能圆满地解决所有领域的东西，就Flex组件库本身来说，如果做图形化的工作，直接从Flex　SDK下继承确实效率较低，开发者可以从Flash 的SDK下继承开发。但是针对数据输入展示的控件，比如dataGrid，下拉列表框，tree等的效率还是不错的，至少客户是能够忍受的。我们的团队从2007年9月开始使用Flex开发电力企业应用，在这个领域，Flex组件的体积、运行效率等问题并不突出，据使用过Flex和ExtJs提取大量数据在表格中展示的同事们报告说，Flex的执行效率远高于ExtJs的。所以本人认为在企业开发领域，Flex的优点是显著的，在图形化和BI领域，使用Flash的类库也会使得问题得以解决，因此完美的技术解决方案几乎是不存在的。我个人在企业应用开发领域是推崇Flex，确实它能带来极高的开发效率和良好的用户交互体验，目前还没有更成熟的产品能超过Flex。
   当然，Flex仅仅是展现层的一种开发技术，对我个人而言，我认为企业核心语义模型、应用系统架构的分层，系统、应用、模块、组件及服务之间的模型和关系更为重要。如果这些底层的东西做的好的话，换一个展现层的东西是不会伤筋动骨的。   一家之言，仅供参考。

48 楼 fins 2010-04-13  

pzwsquare 写道

小胖是不是看太多乔布斯平击adobe的文章了，不要人云亦云，air这些东东毕竟都是收购来的，不像原生的PS这些东东受重视。

你也误会我了 jobs抨击的是 flash
我对flash无感

我说的是air  我气愤的是adobe 对air+html的开发方式的不重视 和对air整体的不作为.
前面有位朋友说的很对 我对 air是一种 "恨铁不成钢"的感觉.

另外 就算我和别人观点一致了 也不能说我人云亦云吧 难道我就不能是切身体会吗?

47 楼 fins 2010-04-13  

flasheep 写道

一种技术而已 开发者的目的是完成客户的需求 手段不重要 也没有什么完美的和一劳永逸的东西 发这样的文章好奇怪

你这种抽象 宏观 毫无破绽的论调 跟谁学的? 学点有用的好不好? 假大空的套话少说点 多去学学技术.

46 楼 pzwsquare 2010-04-13  

小胖是不是看太多乔布斯平击adobe的文章了，不要人云亦云，air这些东东毕竟都是收购来的，不像原生的PS这些东东受重视。

45 楼 flasheep 2010-04-13  

一种技术而已 开发者的目的是完成客户的需求 手段不重要 也没有什么完美的和一劳永逸的东西 发这样的文章好奇怪

44 楼 bookong 2010-04-13  

最近在学Flex，用它做了个工作流定义的东西。感觉用起来真的挺不爽的（AS3.0)。

43 楼 BlueMeteorolite 2010-04-13  

Adobe不是太了解开发人员的想法.对软件开发平台真正需要的理解也怪怪的.

fins 写道

vii779 写道

znjq 写道

lordhong 写道

BlueMeteorolite 写道

adobe占着FLASH垄断似的安装量。不思进取。

不思进取说得太好了，和乔帮主说的一样

Flex当年不开源不免费，后来出了jQuery，YUI，prototype等一大批开源JS框架，急得立马开源免费了，可惜太迟了。

看Flex的源码才真是个杯具!

对Flex组件彻底失望了，用Flex已经一年半了，从性能、体积、灵活性和可扩展性这几方面都不理想。Flash的速度还是可以的，被Flex一封装，搞的组件创建效率慢了好几倍，现在但凡复杂的界面，都是自己用AS3来做，Flex组件压根满足不了性能上的需求。功能不全也就算了，想扩展一下吧，祖先类好多关键的方法和变量都是私有，叫你欲哭不能。看Flex源代码的确是个杯具，代码的确写的中规中矩，但就是缺乏灵气，死板教条不说，一个组件写的啰哩啰嗦，过渡的设计了，只考虑大而全了，性能、灵活性、可扩展性都丧失了。一些细节地方做的也不到位（或许是还不成熟吧）。和ExtJs比起来，不说功能如何，单就代码的质量、细致之处、和作者的灵气相比，感觉是差了一个档次的。

最后不得不提的是富文本处理能力，Flash10依旧处理的的不完善，api复杂难用也就罢了，咱都可以封装。可是性能还是提不上去，这个才是杯具中的杯具！

不思进取，确实有这样的感觉，也许是投入的精力还不够吧。

知音!  红色字部分我个人狂赞同!

42 楼 znjq 2010-04-12  

vii779 写道

znjq 写道

lordhong 写道

BlueMeteorolite 写道

adobe占着FLASH垄断似的安装量。不思进取。

不思进取说得太好了，和乔帮主说的一样

Flex当年不开源不免费，后来出了jQuery，YUI，prototype等一大批开源JS框架，急得立马开源免费了，可惜太迟了。

看Flex的源码才真是个杯具!

对Flex组件彻底失望了，用Flex已经一年半了，从性能、体积、灵活性和可扩展性这几方面都不理想。Flash的速度还是可以的，被Flex一封装，搞的组件创建效率慢了好几倍，现在但凡复杂的界面，都是自己用AS3来做，Flex组件压根满足不了性能上的需求。功能不全也就算了，想扩展一下吧，祖先类好多关键的方法和变量都是私有，叫你欲哭不能。看Flex源代码的确是个杯具，代码的确写的中规中矩，但就是缺乏灵气，死板教条不说，一个组件写的啰哩啰嗦，过渡的设计了，只考虑大而全了，性能、灵活性、可扩展性都丧失了。一些细节地方做的也不到位（或许是还不成熟吧）。和ExtJs比起来，不说功能如何，单就代码的质量、细致之处、和作者的灵气相比，感觉是差了一个档次的。

最后不得不提的是富文本处理能力，Flash10依旧处理的的不完善，api复杂难用也就罢了，咱都可以封装。可是性能还是提不上去，这个才是杯具中的杯具！

不思进取，确实有这样的感觉，也许是投入的精力还不够吧。

to:vii779

hi,好久不见你了.
我也深有同感,flex的这些问题也是我重写ui组件的出发点.
自己写的体积可以控制的非常小,性能也很好.

41 楼 fins 2010-04-12  

vii779 写道

znjq 写道

lordhong 写道

BlueMeteorolite 写道

adobe占着FLASH垄断似的安装量。不思进取。

不思进取说得太好了，和乔帮主说的一样

Flex当年不开源不免费，后来出了jQuery，YUI，prototype等一大批开源JS框架，急得立马开源免费了，可惜太迟了。

看Flex的源码才真是个杯具!

对Flex组件彻底失望了，用Flex已经一年半了，从性能、体积、灵活性和可扩展性这几方面都不理想。Flash的速度还是可以的，被Flex一封装，搞的组件创建效率慢了好几倍，现在但凡复杂的界面，都是自己用AS3来做，Flex组件压根满足不了性能上的需求。功能不全也就算了，想扩展一下吧，祖先类好多关键的方法和变量都是私有，叫你欲哭不能。看Flex源代码的确是个杯具，代码的确写的中规中矩，但就是缺乏灵气，死板教条不说，一个组件写的啰哩啰嗦，过渡的设计了，只考虑大而全了，性能、灵活性、可扩展性都丧失了。一些细节地方做的也不到位（或许是还不成熟吧）。和ExtJs比起来，不说功能如何，单就代码的质量、细致之处、和作者的灵气相比，感觉是差了一个档次的。

最后不得不提的是富文本处理能力，Flash10依旧处理的的不完善，api复杂难用也就罢了，咱都可以封装。可是性能还是提不上去，这个才是杯具中的杯具！

不思进取，确实有这样的感觉，也许是投入的精力还不够吧。

知音!  红色字部分我个人狂赞同!

40 楼 fins 2010-04-12  

javaeyebird 写道

fins 写道

在CB上看到"Adobe Flash CS5可将动画转为HTML5 Canvas"时 我很激动.看来adobe早已意识"要把html变成自己的武器,而不是flash的敌人",并且早已经付之于行动了.GJ!
(也许这条新闻早就有了 由于我对flash关心甚少 所以今天才知道 可能火星了)

我认为这是adobe要让flash运行到iphone上，和air支持html/ajax没有太大关系

我也没说有关系啊

我高兴是因为看到了 adobe对html5开发的态度

39 楼 vii779 2010-04-12  

AIR对Html和js支持的不好，也没什么好失望的。对于最终用户来说，并不关心你是用什么技术实现的，能切实满足用户的需要才是最重要的。如果你是用Html和js技术来开发应用，还是选择一个对html和js支持的比较好的平台吧，没有必要和Air较真，它支持的不好，自然有比它支持好一些的。况且Air普及率那么低，即便你能做出应用来，用户也不见得能完全接受的。还是务实一些比较好，现阶段不要期望Air能对Html和js支持的多好，谁不努力，谁不用心去做，自然会被慢慢淘汰出局的，一切还是用户说了算。