Why do people who are clueless about Flash feel a driving need to write about it?
This must be some sort of hidden epidemic: It appears that people who are clueless about Flash feel the need to write articles bashing it. Excuse me but I thought that was our job! Personally, I feel offended when someone who knows nothing but XML and Java feels the need to encroach on the turf of hard-working Flashers by criticizing Flash using myths and misinformation when we can do a much better job of bitching about things using actual facts! :)
The article I'm talking about is the one that JD blogged about called SVG: Imaging`s[sic] Pot of Gold? (It seems that someone has to teach the editors at DevArticles the difference between an apostrophe and a single opening quote.)
In it you will find such nuggets of misinformation like:
"Flash might be wonderful for many graphics tasks, but SVG can do everything Flash can do and more."
One can only wonder whether Ted Long, the article's author, has ever so much as launched the trial version of Flash when he makes such a brazenly incorrect statement with the literary equivalent of a straight face. Ted, sorry, but you're wrong, wrong, wrong!
You are comparing apples to oranges (and heck, you don't even have the common decency to do it on Slashdot, where such things are accepted!)
Debunking Ted
To start with, let me answer the "SVG can do everything Flash can do and more" claim:
Flash has video, SVG does not. (SVG 1.2 will support it but there are no final players that currently do and SVG 1.2 is currently a working draft. Adobe's next player should, based on the technology demo.)
Flash supports sound (SVG 1.2)
Flash allows socket communications, SVG does not. (Again, the SVG 1.2 spec does propose an implementation for this.)
Flash maintains state on the client, SVG does not.
Note: Flash supports all these now, not sometime in the future based on a draft proposal.
"The real bonus comes on the disk scale, however. Vector graphics weigh in for less than high-quality raster (pixel) images."
Wrong: Although I've never heard of the "disk scale" before, as Flash developers who have been working with vector graphics since the earliest days of Flash, we know that the size of vector graphics can mushroom based on their complexity and that this can also have a real affect on processing and playback performance. This, coupled with how much (and what type of) compression is used in the bitmap image can mean that bitmap images come out smaller than vector graphics. This sweeping statement, thus, is inaccurate.
To prove this, take a look at the GIF of this Tiger illustration (71kb) and compare it to the size of the SVG file (95kb). (Of course, we could debate until the cows come how as to what constitutes a "high quality" raster image 0% compression? Subjectively the GIF of the Tiger illustration is "high quality" through it may not be fit for large-scale print. Then again, we're talking about web-based applications here.)
Now let's move on to answer the inaccurate claims on the "taking aim at Flash" page:
"Both require browser plug-in; SVG will get built-in browser support (e.g. Mozilla)"
It may well be that SVG gets built-in browser support but right now, that's not the case and the Flash player is ubiquitous. How long should developers have to wait until this happens? Should we put our project on hold for a month, year, two years? I'm running the latest FireFox right now and I can't view SVG content.
"Easy-readable plain-text vs. binary format"
Easily-readable if you're the type of person who hacks Linux kernel code, maybe. Have you ever tried to "read" through a complex SVG file? Here's a part of the SVG from a tiger image:
<g style="fill: #ffffff; stroke:#000000">
<path d="M-129.83 103.065C-129.327 109.113 -128.339 115.682 -126.6 118.801C-126.6 118.801 -130.2 131.201 -121.4 144.401C-121.4 144.401 -121.8 151.601 -120.2 154.801C-120.2 154.801 -116.2 163.201 -111.4 164.001C-107.516 164.648 -98.793 167.717 -88.932 169.121C-88.932 169.121 -71.8 183.201 -75 196.001C-75 196.001 -75.4 212.401 -79 214.001C-79 214.001 -67.4 202.801 -77 219.601L-81.4 238.401C-81.4 238.401 -55.8 216.801 -71.4 235.201L-81.4 261.201C-81.4 261.201 -61.8 242.801 -69 251.201L-72.2 260.001C-72.2 260.001 -29 232.801 -59.8 262.401C-59.8 262.401 -51.8 258.801 -47.4 261.601C-47.4 261.601 -40.6 260.401 -41.4 262.001C-41.4 262.001 -62.2 272.401 -65.8 290.801C-65.8 290.801 -57.4 280.801 -60.6 291.601L-60.2 303.201C-60.2 303.201 -56.2 281.601 -56.6 319.201C-56.6 319.201 -37.4 301.201 -49 322.001L-49 338.801C-49 338.801 -33.8 322.401 -40.2 335.201C-40.2 335.201 -30.2 326.401 -34.2 341.601C-34.2 341.601 -35 352.001 -30.6 340.801C-30.6 340.801 -14.6 310.201 -20.6 336.401C-20.6 336.401 -21.4 355.601 -16.6 340.801C-16.6 340.801 -16.2 351.201 -7 358.401C-7 358.401 -8.2 307.601 4.6 343.601L8.6 360.001C8.6 360.001 11.4 350.801 11 345.601C11 345.601 25.8 329.201 19 353.601C19 353.601 34.2 330.801 31 344.001C31 344.001 23.4 360.001 25 364.801C25 364.801 41.8 330.001 43 328.401C43 328.401 41 370.802 51.8 334.801C51.8 334.801 57.4 346.801 54.6 351.201C54.6 351.201 62.6 343.201 61.8 340.001C61.8 340.001 66.4 331.801 69.2 345.401C69.2 345.401 71 354.801 72.6 351.601C72.6 351.601 76.6 375.602 77.8 352.801C77.8 352.801 79.4 339.201 72.2 327.601C72.2 327.601 73 324.401 70.2 320.401C70.2 320.401 83.8 342.001 76.6 313.201C76.6 313.201 87.801 321.201 89.001 321.201C89.001 321.201 75.4 298.001 84.2 302.801C84.2 302.801 79 292.401 97.001 304.401C97.001 304.401 81 288.401 98.601 298.001C98.601 298.001 106.601 304.401 99.001 294.401C99.001 294.401 84.6 278.401 106.601 296.401C106.601 296.401 118.201 312.801 119.001 315.601C119.001 315.601 109.001 286.401 104.601 283.601C104.601 283.601 113.001 247.201 154.201 262.801C154.201 262.801 161.001 280.001 165.401 261.601C165.401 261.601 178.201 255.201 189.401 282.801C189.401 282.801 193.401 269.201 192.601 266.401C192.601 266.401 199.401 267.601 198.601 266.401C198.601 266.401 211.801 270.801 213.001 270.001C213.001 270.001 219.801 276.801 220.201 273.201C220.201 273.201 229.401 276.001 227.401 272.401C227.401 272.401 236.201 288.001 236.601 291.601L239.001 277.601L241.001 280.401C241.001 280.401 242.601 272.801 241.801 271.601C241.001 270.401 261.801 278.401 266.601 299.201L268.601 307.601C268.601 307.601 274.601 292.801 273.001 288.801C273.001 288.801 278.201 289.601 278.601 294.001C278.601 294.001 282.601 270.801 277.801 264.801C277.801 264.801 282.201 264.001 283.401 267.601L283.401 260.401C283.401 260.401 290.601 261.201 290.601 258.801C290.601 258.801 295.001 254.801 297.001 259.601C297.001 259.601 284.601 224.401 303.001 243.601C303.001 243.601 310.201 254.401 306.601 235.601C303.001 216.801 299.001 215.201 303.801 214.801C303.801 214.801 304.601 211.201 302.601 209.601C300.601 208.001 303.801 209.601 303.801 209.601C303.801 209.601 308.601 213.601 303.401 191.601C303.401 191.601 309.801 193.201 297.801 164.001C297.801 164.001 300.601 161.601 296.601 153.201C296.601 153.201 304.601 157.601 307.401 156.001C307.401 156.001 307.001 154.401 303.801 150.401C303.801 150.401 282.201 95.6 302.601 117.601C302.601 117.601 314.451 131.151 308.051 108.351C308.051 108.351 298.94 84.341 299.717 80.045L-129.83 103.065z"/<
</g>
Ten points to Ted, if he can "easily read" and let me know which part of the tiger that code draws.
"$50,000 Flash Generator license for creating large-scale dynamic graphics vs. inexpensive packages such as PHP, XSLT, JSP and others"
Where have you been the last few years, Ted? Generator has been discontinued and you can do nearly everything Generator could in the Flash client these days. Oh yes, and those weird things you see out on the street are called au-to-mo-biles!
"Both allow embedding of typefaces (fonts); SVG allows multiple SVG documents to reference same SVG font file"
Flash allows the same thing using Shared Fonts.
"SVG supports Photoshop-like filter effects on vector graphics; Flash doesn't support filter effects"
True, Flash doesn't currently support filter effects but, according to Kevin Lynch's demo in Tokyo, the next version will. Could this be the one true statement in the whole article?
"SVG is a truly open and extensible format; anyone is welcome to add functionality; Flash is controlled by Macromedia; you can't extend the format without violating their patents/copyright"
Again, you are wrong. The SWF file format is open. The FLA isn't, the Flash IDE isn't and the Flash Player isn't but last I checked neither was Adobe SVG Viewer or Adobe Illustrator. I want my open-source Adobe Illustrator now, you hear?! Darn that closed SVG format!
Where Flash and SVG differ markedly is that we have not one but two professional IDEs (Flash and Flex) that make it simple to create Flash applications. Show me a comparable IDE for SVG. And no, Notepad just doesn't cut it!
The tools that do exist for SVG development don't even register on the features scale when compared to Flash MX 2004 or Flex Builder. Let's take a look at Adobe Illustrator, the self-professed "premier tool for generating SVG content." Its SVG Interactivity palette, for example, would have any Flash developer begging to use Flash 4 instead!
Another tool, Jasc WebDraw from Corel boasts: "Standard illustration tools", "Gradients" and "Bitmap images" as three big features on the first page of its features section. For some reason, that just doesn't get me excited! Could it be because we've had those primitive features in an easy-to-use IDE for the longest time and have moved on to things like Flash Remoting, Flash Communication Server and pattern-based Rich Internet Application development using ActionScript 2?
Ted's article would have been timely and perhaps even somewhat accurate if it had been written in the Flash 3 days (if we had had SVG back in those days, of course.) Today, it is antiquated, inaccurate and, quite frankly, a waste of good bandwidth.
I hope the next article I read that criticizes Flash is at least written by someone who has a clue as to what Flash really does. I criticize Flash all the time but for a different reason: I love Flash and want to see it improve. It's tough love, I admit, but the truth of the matter is that currently there's nothing out there for building rich-client web applications that is as powerful, easy-to-use or just downright as much fun to work with than Flash.
Comments
However, SVG does have it's advantages (usually in pure data visualiztion applications where you can control the desktops that it's running on--ie, enterprise apps). Until the SVG plugin base exceeds 70% there is no point in even thinking about it for consumer facing websites.
by Tim Scollick on 2005-01-12 11:35:24
So, I think it's worth it to say it again, "Thank you, Aral!"
Now I shall proceed to trackback your article in an effort to boost your page rank, thus discrediting (not that he didn't just discredit himself by writing such drivel) Ted R. Long's incorrect statements.
by JesterXL on 2005-01-12 13:11:53
by Aral Balkan on 2005-01-12 13:40:37
The point regarding Generator is hilarious. Those were the days :o)
by ralf.siegel on 2005-01-12 15:47:51
Seriously though, it's really incredible at the level of misinformation some techies have regarding Flash, considering it's been around for years since the banner ad only days! Is it going to get any better? Let's hope so!
by richardleggett on 2005-01-12 15:49:07
-LAH
by Last ActionScript Hero on 2005-01-12 16:34:57
"Easy-readable plain-text vs. binary format"
he is definately right with his statement, and that fact is a major disadvantage of swf. i have "read" through complex svg files, and easily changed text, styles, rearranged/copy-pasted shapes etc. using notepad. you can't do that with swf (except maybe if you use tools like kinetic fusion to convert the swf format to xml - but that would mean i need additional specialized software to do so)
"$50,000 Flash Generator license for creating large-scale dynamic graphics vs. inexpensive packages such as PHP, XSLT, JSP and others"
he is right. i can't create create swf using "php, xslt, jsp and others". there are a few free options, but again, i need additional software and a flexible hosting that allows me to install that software to solve that issue. i don't need that for generating svg.
"SVG is a truly open and extensible format; anyone is welcome to add functionality; Flash is controlled by Macromedia; you can’t extend the format without violating their patents/copyright"
he is right. the swf format may be open (as we get the file specs months after the player/ide is released) but is *not open at all* in respect to extensibility. macromedia, and macromedia alone specifies what will be included in the next version of the file spec. svg is open for extensibility by design, plus everybody can participate in the svg working group to suggest new features, even without being a member of the w3c. if your suggestions are solid and useful, the wg will likely add them to a future version.
again, i agree with you that that article is fud, that svg may not be ready for mainstream browser use and that you can't fully compare svg and flash anyways, but you can't deny that the svg spec offers advantages over swf (also, 2d features of svg are way more advanced compared to what we have in swf today, and even what we will have in maelstroem tomorrow - read the spec and get enlightened).
just my 2 centavos.
respectfully,
claus.
by claus wahlers on 2005-01-12 17:06:25
"i have "read" through complex svg files, and easily changed text, styles, rearranged/copy-pasted shapes etc."
You can do the same with ActionScript, which should in any case be kept in external text files. To tell you the truth, i'd much rather go through a well-organized codebase, arranged neatly into packages then to search through an endless tree of XML code to find where someone may have dropped a piece of code.
I also do not want to read through lines of code telling me how to draw a complex image and have all that mixed in with my business logic, etc. It's a mess. When I load in a bitmap, I don't really care what the color value of each pixel is -- I just want to display a bitmap. With Flash, I don't ever get bothered by these details.
"i can't create create swf using "php, xslt, jsp and others"
Yes, you can. In PHP, at least, you can use Ming. Since the file format is open, you can create your own solution in your language of choice for rendering Flash. At the end of the day, however, Flash is a *state-maintaining* client and thus rendering it on the server *does not make sense*. This is a gripe I have with Flex as well. SWFs should be compiled client-side not server-side.
"svg is open for extensibility by design, plus everybody can participate in the svg working group to suggest new features, even without being a member of the w3c. if your suggestions are solid and useful, the wg will likely add them to a future version."
Yes, but unfortunately things appear to be progressing at a snail's pace (and a particularly lethargic snail at that.) All the goodies that are in the draft spec for 1.2 are just that: *draft*. It will be ages before there are stable implementations, if any, and before those see widespread approval, if ever.
There's a very big difference between a spec and tools you can work with today. Flash gives us tools to work with today and people are using it to create things. The SVG draft proposal for 1.2 gives us, possibly, hope for tomorrow.
by Aral Balkan on 2005-01-12 17:37:18
you are comparing apples with oranges. we are talking about the swf file format vs the svg file format here, not about dynamic client side shape generation (which you can do in the exactly same fashion in svg as in flash, even with the advantage that you can rely upon (really) open standards, like dom, but that's not the point). the point is that the swf format is not readable by humans, and you can't deny that fact (even if you personally don't want to do that, for whatever reasons that may very well make sense for you).
"In PHP, at least, you can use Ming. Since the file format is open, you can create your own solution in your language of choice for rendering Flash"
no i can't, because the client i work for doesn't have ming installed, and can't install it without a high cost, as his server is cerified by some institution and the ming package is not. my client has xslt installed though, and other basic technologies that are available anywhere and that allow me to generate svg very easily.
"Yes, but unfortunately things appear to be progressing at a snail's pace (and a particularly lethargic snail at that)"
yes they are (if you are refering to mainstream browser applications), but again, that's not the point. the point is that swf is not extensible. it is not, and will never be. plus, how many years did we have to wait for realtime photoshop vector effects in flash? and reliable rich text rendering? and accessibility for all platforms/clients? and proper support for rtl text? the list goes on and on. i'm still waiting.
"There's a very big difference between a spec and tools you can work with today. Flash gives us tools to work with today and people are using it to create things"
i'm not at all denying that, if you read my previous post carefully.
respectfully,
claus.
by claus wahlers on 2005-01-12 18:05:04
"the point is that the swf format is not readable by humans, and you can't deny that fact"
I'm not denying the fact that you cannot read the SWF file format. I am merely saying that it is of no practical importance.
I do not want to read the SWF file format. Nor do I want to read Java bytecode. What's important is that the *source* is easy to read.
It just so happens that you do not compile SVG into bytecode and thus it *is* the source.
So when comparing readability, you have to compare the SVG source with the Flash source, which, in our case, is ActionScript (and ActionScript 2) and the FLA. Now again, to "read" the FLA, you do not use a Hex editor but look at how easy it is to see the structure and assets of an application. Using the Flash IDE, you can, at a glance (and visually) see the structure of your application and your assets. This is an infinitely better workflow than hunting through a huge XML file for this and that.
"no i can't, because the client i work for doesn't have ming installed, and can't install it without a high cost"
Well, I wasn't stating that you *should*. As I said earlier, SWF generation belongs on the client, not the server. Flash can maintain state on the client and carry out data exchanges and even socket and remoting connections. If you must generate simple dynamic graphics and things, and insist on doing it on the server, I guess you can always use SVG! :)
"the point is that swf is not extensible. it is not, and will never be."
Again, let's take a practical approach: Do I really care whether or not the SWF file format is extensible? Or do I care whether or not I can *extend Flash* I can easily do the latter by building my own components and Flash, at least on the desktop, currently has more features than you can shake a stick at with more being added every day. I'd rather have Macromedia, who has an economic incentive to make Flash better in a timely manner, respond to my feature requests than have them debated in the high academic corridors of the W3C!
"how many years did we have to wait for realtime photoshop vector effects in flash?"
To tell you the truth, this was never high on my wish list. It's great that it's coming but we could always fake those effects if need be. When will SVG support remoting? EcmaScript 4? When will it give me the advantages I have with Flash Communication Server today?.. The list goes on.
Flash gives me the tools I need to work with today and has been doing so since the turn of the century, if not before. SVG appears to be all about promises.
by Aral Balkan on 2005-01-12 18:43:38
so i guess i could write another followup on your points (i don't agree to some of them), and we could continue endlessly.
real world examples are current clients of mine, clients, that chose open standards as their technology of choice, because they work best for them. clients, that are capable of, and willing to develop useragents to render those file formats (user agents that certainly won't make it to the public at all), and invest in business logic to support them. clients, that won't ever invest in proprietary de-facto standards and tools because they have no control over them and, effectively, don't "have the choice".
different entities have different needs. can we agree upon that? ;)
respectfully,
claus.
by claus wahlers on 2005-01-12 19:56:13
Most definitely! :)
by Aral Balkan on 2005-01-12 20:47:19
You made my day! Thanks for posting this.
Some people think XML will save the world, end the wars and poverty and all. I don't.
SVG has its uses. SWF is a global standard that works today and rules. period.
Best regards,
Burak
by burak on 2005-01-12 21:49:15
Don't get me wrong SWF is great but in the spirit of this article I think you should correct your statement about flash openness.
by huh on 2005-01-13 05:26:34
Macromedia's File Format Specification License Agreement does state that the specification may only be used to "output swf".
However, Macromedia has not taken any action against developers whose software opens SWFs. For an example, see Burak's ASV. From what I've seen, Macromedia has actually been *supportive* of Burak's efforts.
Our very own Optimizer software opens, looks inside and modifies SWFs and, again, we have gotten nothing but support from Macromedia.
I believe that the restrictions that exist are there so people do not start creating different Flash player versions. I personally would not want this because it would kill user trust in the Flash Player. (What if Person A put out an incompatible Flash player with security holes, etc?)
As far as I'm concerned, I don't want anyone but Macromedia to put out Flash Players. Look at what happened when Microsoft decided to "improve" Java by putting out its own, incompatible, virtual machine (that's what the Flash Player is too, a virtual machine.) I applaud Macromedia's foresight in not allowing this.
It doesn't make the SWF format any less open, it just makes practical sense.
by aral on 2005-01-13 06:11:53
by propecia price on 2007-05-24 04:45:52
by Generic levitra. on 2007-06-28 04:28:01