Steven Vachon

Flash vs. HTML

0 comments

Let’s get one thing out of the way, Flash is very cool. If used properly, there’s definitely a lot you can do with it. However, Flash has its place. Despite popular belief in the Flash community, it’s not meant to replace HTML.

There are many reasons mentioned by others as to why Flash cannot replace HTML. Reasons such as “it’s just a box in the page” and “it can’t be indexed by search engines”. Both of those have been overcome. So what remains? Principle. All too often is it proven that many full-Flash sites simply should have been written in plain HTML. And yes, just that – plain. No fancy JavaScript replacements for Flash. For over 100 years, messages have been written on and read from paper where animation cannot exist. For that amount of time we have been reading easily legible text. Until recently, that was the case in all text mediums. But now in the post-Internet boom era, it’s become trendy to annoy our audience.

It won’t be for a number of years before our newspapers are animated with OLED (Organic Light Emitting Diode). Though even then, it wouldn’t be as annoying as many of today’s full-Flash sites.

Sure, animation is pretty. But it’s also very distracting. Especially if you’re trying to read a 20 page document. Not only is it a distraction, but it’s stalling. How many seconds should you have to wait to read the content that brought you to a particular site while eye candy zooms across your screen? 10 seconds? 3 seconds? The answer is zero. Only a small percentage of Internet users are web designers, and most aren’t interested in wasting their time with “fluff”. Good page design is a must, and some eye candy is good, but overdoing it doesn’t belong everywhere. Flash often causes designers to go overboard and bloat their pages.

Along with animation comes longer download times. Lengthy content sites written in HTML can have hefty file sizes. With Flash, that number can exponentially rise with or without proper optimization. However sometimes it can be smaller than HTML.

Although there are other factors to be brought into consideration. For the sake of this argument, let’s say a developer created a full-Flash content site that defied all the common misconceptions and stereotypes of Flash sites and was small in file size. “What problem could remain?”, you might be asking. The simple answer is low frame rates and excessive amounts of CPU and memory usage. The complex answer is found in my previous article, Flash for the Masses.

So where does a full-Flash site belong? On smaller scale sites and applications. “Small” being under 20 pages worth of text. Not lengthy content or e-commerce sites.

Related Links



Comments

Top

Comments are currently closed.