☆─────────────────────────────────────☆
   eharisma (咖啡时光) 于  (Tue Sep 20 13:27:54 2005)  提到:

zz from http://www.jonathanboutelle.com

Flash RIAs vs. Javascript RIAs

Javascript RIAs (aka AJAX) are don’t come close to the interactivity that developers can implement using technologies like Flash or Java. For example, there is no easy way of integrating with audio and video content, there is no ready-made toolkit of application widgets (tree-views, data-grids, etc). There are undeniable advanatages to the JavaScript RIA approach, however. So how do you decide whether a Javascript RIA (or “AJAX”, if you must) or a Flash RIA is right for the project you’re working on?

Download Size
Clearly DHTML pages will end up being smaller (on average) than Flash SWF files or Java applets (assuming a rich approach that doesn’t repeatedly download the html). If your client may be using a slow internet connection, a JavaScript RIA will have advantages. Similarly, if you’re application is going to be deployed on a very popular site (like google!), reducing downloads will also save you a lot of money on bandwidth.

Politics and Such
XMLHttpRequest is an API that belongs to Microsoft and is not part of the JavaScript standard. Given that Microsoft is NOT interested in open web-based standards becoming more powerful, there is a risk that the next version of IE will break XMLHttpRequest in a subtle or perhaps, not-so-subtle way. They wouldn’t even be guilty of violating a real standard if they did this, just a de-facto standard. And you can bet they would love to break all that cool code that google just finished writing!

Of course, if you do Flash or Java development, you are at the mercy of Macromedia or Sun, and the changes they make to their browser plugins. So which company you trust to “do the right thing” becomes a relevant question. In general, Java and Flash JVMs have been backwards-compatible, and Microsoft has an established history of keeping standards in constant flux to cripple their competition (a tactic that Joel Spolsky aptly calls “cover fire”). Draw your own conclusions.

Staffing
It is definitely easier to hire “vanilla web developers” than people who can do real engineering using Flash. Drew McLellan writes

"It's hard to find good people who are also prepared to work with tools like Flash. I'm sure they exist, but finding someone who's a good Flash developer and is also geographically close and available for work is hard."

I’ve despaired at hiring good Flash engineers, and resorted to hiring Java Developers and retraining them. This approach works if you can keep your Java Developers involved and invested in Flash. But you just don’t face these kinds of staffing issues with JavaScript: there will always be web developers.

Integration with multimedia
One of the big advantages of Flash is that it natively supports streaming audio and video, something that obviously isn’t a part of DHTML. If you’re working with multimedia, Flash is definitely the RIA platform to build your application on.

Availability of UI toolkits
Flash and Java come with UI toolkits for such things as tree views and data grids. These components are absent in the Javascript world (although enterprising companies are moving in to fill the gaps: look for some introductions to the newer players in this space shortly on my blog). If that's important to you, that either Flash or Java are a much better option comparted to developing a JavaScript RIA.


Maintainable Code
Javascript development in general requires writing code that runs on different browsers and “degrades gracefully”. For example, there is a reasonable chance the XMLHttpRequest object won’t be present in a given browser: your code has to handle this. As jibbering writes:

“Even in IE the XMLHttpRequest object can often be blocked by slightly raised security settings (popular due to the commonly exploited holes of course)”

Writing this kind of code (in order to work on all browsers and degrade gracefully, everything is implemented two or three times) is annoying. Maintaining this kind of code is a real nightmare. When you depend on a plugin like Flash, compatibility problems are all but eliminated: as long as your client has the right plugin, your code should work.

On the other hand, writing maintainable Flash code is no picnic either. Actionscript (unlike JavaScript) is an object-oriented language, so there is the potential for extremely elegant and maintainable code. But unless you abandon the Flash IDE entirely (and good luck finding a Flash designer who can work without it) you will end up with a big binary FLA file that is hard for maintenance programmers to deconstruct and understand (see Flash Better Practices for the gory details). Here I’m going to give Flash the advantage, but it’s not a knockout blow: it's more of a judgement call.

Conclusion
I hope this article provides a beginning framework for deciding whether to implement your next RIA in JavaScript or Flash. The two technologies have very different profiles, and in many ways compliment each other, so both are likely to be quite important to web developers for the conceivable future. so there should be room for both approaches: no need to be a technology bigot! A nice debate on the topic is currently perolating in the Flash forums, and the discussion continues on Slashdot and elsewhere. As always, the space below is for feedback and discussion.





☆─────────────────────────────────────☆
   eharisma (咖啡时光) 于  (Tue Sep 20 13:28:22 2005)  提到:

Previous Comments

Thanks for continuing this conversation, and particularly this attempt at setting out a series of metrics for comparing two technologies for a job. I'm still waiting for the morning coffee to do its work and want to print this page out for closer study. One thing caught my eye at this stage, though:

"Clearly DHTML pages will end up being smaller (on average) than Flash SWF files or Java applets" I would have assumed the opposite (single instructions vs multiple branches, binary vs text). What evidence were you considering...?

(For total download time, the sheer number of HTTP requests is also signficiant. I don't think we've seen "SWF vs DHTML" stats because it has been a non-issue for so many years, and these "AJAX" projects seem to avoid discussing production or distribution costs.)

tx, jd/mm
Posted by: John Dowdell at March 3, 2005 09:10 AM

Hey John!

My evidence for flash download size being bigger is as follows:

I've never seen a "preloader" for a dhtml page.

I've never seen a thriving market for expensive dhtml compression tools, the way that there is a market for swf compression tools.
http://www.eltima.com/products/flashoptimizer/
http://www.swishsoft.com/optimizer_new.htm

The RIA I'm working on right now has a swf download of half a meg. I've never seen an html page that big.

Theoretically, a binary format should reduce bloat (and boy, html has a lot of redundancies: even a custom text format would cut out a lot of fat). Why this doesn't seem to happen in practice is a bit mysterious to me.

re: httprequests: JavaScript and Flash RIAs would both request data asynchonously when the client-side engine requested it, so I don't see how the number of httprequests would be very different in the two cases.
Posted by: jon at March 3, 2005 10:13 AM

Whilst Flash does an amazing compression job with internal images, once a dynamic Flash piece picks up external .jpgs any real advantage is lost.

Also, components in a Flash piece instantly increase fileize, from 25k+, dependent upon the type and number of components. Whilst this is becoming less of an issue with increased download speeds it is still a factor when choosing the technologies to use in a RIA.
Posted by: Fraser Campbell at March 3, 2005 10:34 AM

re: re: httprequests: I think it matters because the majority of Flash files you see that are bloated are ones that have all the data (heck, maybe an entire site) built right into them. In cases where they both make the same number of requests, file sizes are likely smaller, in which case that argument changes.

Can anyone speak on the size difference in a standar "AJAX" request (especially one with lots of XML) versus remoting? Joey Lott and others have pointed out that the binary Remoting data transfers can be significantly smaller. Just curious as to the real numbers here.
Posted by: Jed Wood at March 3, 2005 11:03 AM

Jed,

Thanks for stopping by.

Agreed, often you're doing a big download in the beginning to avoid downloads later. This is dumb, especially if resources can be downloaded in the background.

Flash in general DOES often tend to be a big download (subjectively: I have no data on this). Maybe it's because swf is a vector graphics format: there tends to be much more geometry in your average swf than in a dhtml app (which really only has rectangles to play with)? I'm not sure.

Fraser, excellent point on components. I think that's another component (sorry for the pun) of the "big download" problem.
Posted by: jon at March 3, 2005 12:22 PM

Actually...

Last I checked JavaScript had fairly robust object support. Either that, or constructors and the protoype property are just figments of my imagination.

Going point-by-point:

Download time: depends on what you're trying to do. The advantage goes to Flash for animation or video, of course. Outside of those realms - even for image-intensive apps like Google Maps - I would say that JavaScript's lower barriers to entry give it the advantage; it will take less training for a web developer to optimize something in JavaScript/"Ajax" as well as could be done in Flash.

Politics/survivability: XMLHttpRequest is indeed at Microsoft's mercy, and its status as an ActiveX widget complicates things even further. But you have the iframe approach, which I first used almost five years ago (for an internal project management app, sans XML), which is much less likely to be broken by any moves that Microsoft makes. I dunno why, but it's always mentioned as an afterthought, I'm guessing because of developer biases (frames are evil, XML is sexy).

[For these same reason I PREFER the iframe approach to "Ajax" implementation.]

Staffing: what you said.

X-media integration: This is a nightmare non pareil without Flash.

Tool availability: Tools? JavaScript? If such things exist elsewhere, I want a ticket to that elsewhere. ..

Maintainability: reusable DOM code requires crazy skillz to write, and even then is rarely lightweight. But if I'm willing to tailor my code to the architecture of a single site or app, things get a lot easier because I can rely on native methods (especially getElementById). The whole x-platform issue is unavoidable, though. If sponsor expectations of platform support verge on the unreasonable, then Flash is (perhaps unfortunately) the winner.

In short: the more interactivity you've got, the better off you are using Flash. If, however, your application is focused on data easily expressed as XML, then "Ajax" looks steadily more attractive.

jon b: compression makes bloated markup less painful. application/x-gzip-compressed, anyone?

John D: "distribution" costs? Ambiguous. As for production costs, man hours are managed just as well or as badly as sponsor expectations.
Posted by: ben at March 3, 2005 01:08 PM

Is anyone talking about time to market?

Given a particular RIA project, the Flash guys must have finished and gone home before the AJAX guys gets to the middle.

And writing different codes (the types that degrade gracefully) is no fun. The advantage Flash has is that it has a platform that is same across all OS. As long as you keep away from fancy OS dependent client objects, you dont care whether target client is Win, linux, Mac ét al.

And for code protection, Flash is nicer. You dont want your competitor to easily rip your code apart (AJAX) and come up with something better. Not that ActionScript are that safe (I know software that could rip that apart too) but it is not rampant.
Posted by: Adedeji Olowe at March 3, 2005 09:35 PM

Great point-by-point ben! Really like your point about the iframe approach. Can you post some links with good tutorials on it (or write one if there aren't any ;->). I learned that frames were evil and never looked back. It certainly sounds like a hack (i.e. it's obviously not what frames were intended for), and that may be why devs stay away from it.

Adedeji, the problem is that we're lacking hard evidence about time to market. Probably because the Flash people and the AJAX people don't talk, which is why I wrote this posting. It certainly seems to me that writing a real application (talking to database, using datagrid and treeview in non-trivial ways) in Flash takes a lot longer than it should (maybe it's just me).

re: Code Protection: the same companies that are in the flash compression business have flash decompilers that can show anyone your code.
http://www.eltima.com/products/flashdecompiler/

If anyone knows a good FLA / Actionscript obfusticator I'm actually looking for one right now.

administrivia: I've opened up this thread so that people can post without me being a gatekeeper. Hopefully we won't get too much comment spam.
Posted by: jon at March 4, 2005 11:24 AM

re: Code Protection, yes, JS RIA AJAX forces you to be open source. Google Maps/Suggest/Gmail workings were deconstructed and described in like 2 internet days.

But, from a technology platform adoption standpoint, that's actually a feature. HTML took over the world because it enabled everyone to learn, rip, mix and tweak from everbody else's interesting web tricks. "How did they do that?" Just View Source for free for the answer.

View Source means JS RIA victory is inevitable even though it technically lags compared to Flash.

http://www.shirky.com/writings/evolve.html
Posted by: Steve Yen at March 5, 2005 12:47 AM

    Great point-by-point ben! Really like your point about the iframe approach. Can you post some links with good tutorials on it (or write one if there aren't any ;->). I learned that frames were evil and never looked back. It certainly sounds like a hack (i.e. it's obviously not what frames were intended for), and that may be why devs stay away from it.

    Tutorials? They ain't no steenkin' tutorials. There is in general a need for accessible documentation on closures, DOM scripting, and Ajax, and I've been wanting for the past six weeks to devote some serious time to the task, but don't know to whom to pitch the copy. ALA's already covered it as much as they're likely to, SitePoint's and ORA's editorial policies are at odds with my style ('sides which I've no contacts at ORA), and while I've got carte blanche at WaSP I would be constrained by the need to do everything in a compliant context - atop the fact that we're in the early stages of a redesign, so I don't want to get my ambition on there 'til the redesign's done. I could approach Lockergnome, but their audience isn't the one that really needs it IMO. (If you have any ideas, e-mail me.)

    If we think of iframes and framesets as a way of opening up separate documents in the same viewport, no more no less, then yes, applying them to Ajax is a hack... but x-frame scripting has had arguably excellent support since the 3.x browsers shipped. (One of my earliest scripts imitated layer swaps by abusing document.write() in a sibling frame.) That level of support implies rather strongly an early consensus that this technology ought to be available.

    Abedeji: maybe yes, maybe no on time-to-market. Each API has strengths and weaknesses. Further, if leveraging Flash's rich media strengths becomes a required objective in a Flash RIA project, Flash has just lost most of its time-to-market advantage hands-down.

    And, uh, source protection? MWAHAHAHA!!! These are all just ideas, people. Given enough resolve, they can and will be reverse engineered.

Posted by: ben at March 5, 2005 08:11 AM

the main difference I see between the different approaches is this:
flash is a vitual machine and fails to achieve perfect emulation of operating system level widgets while
the browser is able to use the native forms and text rendering of the operating system. While it may seem like a small issue the "feel" of flash applications is somewhat lacking
Posted by: Derek at March 8, 2005 01:09 PM

Three quick comments:

First ActionScript is converging on JavaScript 2.0 compliance - so the two have roughly comparable object development capabilities - assuming ECMA finally gets JavaScript to 2.0 status. Admittedly ActionScript has many more prebuilt objects. But watchout on XML - E4X recommended ECMA standard extension from BEA is a real boon, but slow being adopted by major JavaScript players like MS, Adobe, Macromedia, etc.

Second, there are some great JavaScript UI toolmakers out there right now:
Dynamic Drive - calendars, tabs, menus
dynarch.com - very good open source calendar
softcomplex.com - treeview, menu, scroller, tabs, etc
navsoft.com - menus, scrollers, etc
activewidgets.com - data grid
codethat.com - grid, table, sidebar, treeview, etc

Check out www.theopensourcery.com/ostutor.htm for
the pick of the JavaScript UI litter and
hotscripts.com for 1600 free JavaScripts.


Third:, regarding security of code there are some useful JavaScript obfuscators but Flash allows for code encryption.
Posted by: Jacques Surveyer at March 9, 2005 07:00 PM

Jacques,

1)Standards don't matter unless they're implemented by the browser vendors. Just sayin'.

2)Thanks for the heads-up on the JavaScript UI toolkits.Seperating the signal from the noise is one of the hardest tasks when shopping APIs: you've probably saved dozens of people hours of work just by posting that list.

3)I had no idea you could encrypt your actionscript code. How?
Posted by: jon at March 9, 2005 07:11 PM

AJAX: promise or hype is a nice meta-blog posting that sythesizes a lot of the current debate. The author doesn't know what RIAs are (or what Ruby on Rails is, for that that matter), but it's not a bad summary and provides some excellent links...
Posted by: jon at March 13, 2005 02:48 PM

I was just looking at a JavaScript library that provide AJAX-style functionality as well as rich widgets etc - the sort of things you'd need to 'compete' with Flash and it's just under 370Kb. I think I read somewhere that Google Maps is a 300Kb download (or maybe that was Gmail?). Given that, I'm not sure that you can assert "Clearly DHTML pages will end up being smaller (on average) than Flash SWF files".

There are certainly a large number of factors involved in these sorts of decisions tho' and I think that overall it's very healthy to see a broader debate about the great experiences that Rich Internet Applications can offer.
Posted by: Sean Corfield at March 23, 2005 10:48 AM

Good point Sean,

There's a little bit of a mismatch in this debate about file size. Comparing applications of equivalent functionality / interactivity is the only was to get a true read on whether initial file sizes are smaller in javascript.

Does anyone know how the Laszlo (flash-based) email client compares to gmail's/oddposts download size? That would seem the clearest one-to-one comparison in this space.
Posted by: jon at March 23, 2005 11:00 AM
【 在 eharisma (咖啡时光) 的大作中提到: 】
: zz from http://www.jonathanboutelle.com
: Flash RIAs vs. Javascript RIAs
: Javascript RIAs (aka AJAX) are don’t come close to the interactivity that developers can implement using technologies like Flash or Java. For example, there is no easy way of integrating with audio and video content, there is no ready-made toolkit o
: ...................



☆─────────────────────────────────────☆
   zms (来福) 于  (Tue Sep 20 14:48:21 2005)  提到:

各有特色吧
前端界面是  dhtml vs flash  , 都是有组件概念得
通讯层是    xmlhttprequest vs flash remote，都是基于http得
后端是     和其它server script得集成  vs  flash gate way
比较好得实现，比方说  bindows vs flex

【 在 eharisma (咖啡时光) 的大作中提到: 】
: zz from http://www.jonathanboutelle.com
: Flash RIAs vs. Javascript RIAs
: Javascript RIAs (aka AJAX) are don’t come close to the interactivity that developers can implement using technologies like Flash or Java. For example, there is no easy way of integrating with audio and video content, there is no ready-made toolkit o
: ...................



☆─────────────────────────────────────☆
   eharisma (咖啡时光) 于  (Tue Sep 20 23:43:29 2005)  提到:

个人感觉如果应用强调媒体交互的功能那么用flash
如果focus在data的运用上，而且可能具有很大的访问量，那么用ajax
【 在 zms (来福) 的大作中提到: 】
: 各有特色吧
: 前端界面是  dhtml vs flash  , 都是有组件概念得
: 通讯层是    xmlhttprequest vs flash remote，都是基于http得
: ...................



☆─────────────────────────────────────☆
   zms (来福) 于  (Wed Sep 21 13:12:30 2005)  提到:

flash不方便之处可能还不是flash的制作，而是as的写作
【 在 eharisma (咖啡时光) 的大作中提到: 】
: 个人感觉如果应用强调媒体交互的功能那么用flash
: 如果focus在data的运用上，而且可能具有很大的访问量，那么用ajax




☆─────────────────────────────────────☆
   creese (终于...要进村了) 于  (Wed Sep 21 13:13:53 2005)  提到:

写as比写js要好点把
好歹有个现成的IDE环境可以用
【 在 zms (来福) 的大作中提到: 】
: flash不方便之处可能还不是flash的制作，而是as的写作




☆─────────────────────────────────────☆
   zms (来福) 于  (Wed Sep 21 13:17:52 2005)  提到:

一般来说，熟练掌握了一门技术后，学另一门同样的技术时，会有排斥
毕竟掌握js的人多多了
【 在 creese (终于...要进村了) 的大作中提到: 】
: 写as比写js要好点把
: 好歹有个现成的IDE环境可以用




☆─────────────────────────────────────☆
   creese (终于...要进村了) 于  (Wed Sep 21 15:15:12 2005)  提到:

能用JS写Javascript App的人太少了
光一条调试的难度就够恶心人了

【 在 zms (来福) 的大作中提到: 】
: 一般来说，熟练掌握了一门技术后，学另一门同样的技术时，会有排斥
: 毕竟掌握js的人多多了




☆─────────────────────────────────────☆
   eharisma (咖啡时光) 于  (Wed Sep 21 15:22:42 2005)  提到:

没用过flash，as学起来很难的？
那么从开发时间和开发成本来看，用ajax是不是好些？

【 在 zms (来福) 的大作中提到: 】
: flash不方便之处可能还不是flash的制作，而是as的写作




☆─────────────────────────────────────☆
   cais (潜心修炼) 于  (Fri Oct 14 13:13:07 2005)  提到:

用flash的话，后端一定要是flash gateway吗？
不能用普通的Web Server?
【 在 zms (来福) 的大作中提到: 】
: 各有特色吧
: 前端界面是  dhtml vs flash  , 都是有组件概念得
: 通讯层是    xmlhttprequest vs flash remote，都是基于http得
: 后端是     和其它server script得集成  vs  flash gate way
: ...................





☆─────────────────────────────────────☆
   creese (终于...要进村了) 于  (Fri Oct 14 13:44:02 2005)  提到:

当然可以用WebServer
【 在 cais (潜心修炼) 的大作中提到: 】
: 用flash的话，后端一定要是flash gateway吗？
: 不能用普通的Web Server?




☆─────────────────────────────────────☆
   zms (来福) 于  (Thu Oct 20 10:05:19 2005)  提到:

flash gateway应该算是一个小标准
一般来说，是web server上的一个插件或者应用
mm公司有自己的实现，也有其它的开源实现
【 在 cais (潜心修炼) 的大作中提到: 】
: 用flash的话，后端一定要是flash gateway吗？
: 不能用普通的Web Server?