flex开发的2份源码

1 我的看法还是和以前一样，要么纯flex做的东西一定是图形化的东西占有主导地位，如果是以文本类为主导的东西，flex不宜大规模使用

交互性强的网站flex也可以大显身手,文本方面 adobe已经注意这个问题了,开发了textlayoutframwork,现在集成到flex4sdk中.


2 所以对于做社区类、电子商务等互联网应用，flex还是不能极端，适当的使用，确实不能大规模使用

这个基本同意.

3 未来还是html为主，flex做辅助性、锦上添花的东西，大规模的flex开发，无论是开发效率和后期维护和c++有一拼， 除非你拿as做一个纯图形化的社区，和游戏一样，这才划得来

锦上添花？我觉得用词不当,完全是侧重点不同.我们公司做的fx系统从一开始的flash到目前的flex都很成功,而且就flex来说我没有发现它的开发效率低还有后期维护困难的问题.


4 坏就坏在flex的有状态上，维护这些状态是件很不爽的事，还有如果整个前端用了flex做模板后，那么将享受不到后端提供的一毛钱的好处，比如在模板中嵌套一些jsp啦，一些ruby啦，基本完全隔离

状态。。adobe一直宣传ria,没有状态还怎么做富客户端？我不明白flex做模板的概念.

谁规定的ria的客户端必须是有状态的？

新的技术都饱受争议，这无可厚非，有争议才有发展嘛

RIA市场还有很大的成长空间，我们可以在适应中慢慢跟随点滴的变化。

没有一种技术是一上来就很完美的，还有很长的路要走呢，不是么，呵呵

大家说得都有理，只不过各说各的，侧重点都不同，痛处也不同而已。

1 我的看法还是和以前一样，要么纯flex做的东西一定是图形化的东西占有主导地位，如果是以文本类为主导的东西，flex不宜大规模使用

不是图形占主导，图形占主导就用flash了。应该是表单，图表，表格等占主导的应用

2 所以对于做社区类、电子商务等互联网应用，flex还是不能极端，适当的使用，确实不能大规模使用

这点基本同意，不过ebay已经有了全flex实现的电子商务。

3 未来还是html为主，flex做辅助性、锦上添花的东西，大规模的flex开发，无论是开发效率和后期维护和c++有一拼， 除非你拿as做一个纯图形化的社区，和游戏一样，这才划得来

做网站可能是html为主，flash flex为辅。但是如果是企业级应用，那flex占主导是不需要有任何异议的。不要把浏览器打开的东西都叫做网站哦。有了好的框架和开发模式，我个人的体验是开发相当快的，维护也不吃力，因为都以模块划分了嘛。
当然如果你期望有好的特效，良好的用户体验，那么你可能在flex的ui开发上要投入比传统ui设计更多的精力。这点我觉得在开发过程中占了很大一块比重。

4 坏就坏在flex的有状态上，维护这些状态是件很不爽的事，还有如果整个前端用了flex做模板后，那么将享受不到后端提供的一毛钱的好处，比如在模板中嵌套一些jsp啦，一些ruby啦，基本完全隔离

什么是有状态？不懂。前台享受后台好处？更加不明白你的意思了。

大型的企业应用，诸如ERP，是非得用些这样的技术的，比如Oracle EBS，用的是Applet，可能是历史原因，这玩意实在是长得难看。要么就像我们用Eclipse RCP。其他的JS之类的都白扯。Flex是个很好的方向，在看我看来就是新时代的Applet。

显然你不是这个领域的，所以你肯定不能明白。

目前 extjs 或者 flex 必须选一个，比较倾向于flex，如果说两三个星期就可以上手开发那时相当诱惑..

你说话不用过脑？现在是到底是js还是flex占主导地位？你不知道YUI？不知道EXT？不知道javaFx？

前台享受后台好处？这个你不能理解就算了。

我就纳闷了，你连什么叫做有状态什么是无状态都不知道？

相对js ,flex几乎在各个方面都有优势（易学习性，组件丰富，强大的IDE支持,良好的跨浏览器特性）。flex的潜力很大，adobe发挥的空间还很大。

这句话，你只说维护这些状态很麻烦，最好能举例说明怎么个麻烦法？会带来什么具体问题。我想你可能指的大量互联用户访问页面时会有因为维护状态而带来的性能问题。我看完所有回复，我想大家都不太明白你指具体是什么?

我们以前用delphi、vc做企业应用的时候是不是也有这样的问题？当然，互联网应用和企业应用的着眼点不太一样。