It’s embarrassing to me that Adobe, of all companies, would release such a poorly produced promo video. At this point it feels like they’re saying “what’s the point?”
Category Archives: Flash
Yawn and Wow
File this one under “Who Cares?” but Google announced Swiffy. It’s a service that will convert the simplest of SWFs into HTML5 documents. As long as the SWFs are targeted at Flash Player 8 or earlier and use ActionScript 2. In that case, it might work. Best results are for SWFs targeted at Flash Player 5 and scripted with ActionScript. The first ActionScript. From 2000. In other words, you can take Flash content that was cutting edge over ten years ago and maybe get a working HTML5 document out of it. Sadly, I’m failing to come up with an analogy that explains just how pointless this is. Sure, it’s a nice bit of engineering work to create this utility. But, beyond on, who cares? Probably just uninformed jackasses who will use this to support their claim that HTML5 can do anything Flash can do.
File this one under “Awesome.” The iMac image gallery on the Apple site is one of the best examples of well executed HTML5 work I’ve ever seen. Seriously cool. I first saw it on my computer. Later on I figured I’d test it out on my original iPad to see how well it works. To my dismay, the back/next buttons on the gallery were M.I.A. on the iPad. Hmm… Turns out, the gallery is even slicker on the iPad because you move from image to image with a swipe. And if you swipe slowly, you can control how quickly the elements of each slide comes in and out of the frame. It even has a bounce effect when you reach the end of the line. It’s hard to describe without playing with it. It also works great on an iPhone and, I’d assume, any decent Android device. Check it out.
HTML5 is the new LCD
The shift from Flash to HTML5 for rich, immersive, interactive sites and website modules reminds me of the shift from CRTs to LCDs over the past decade. LCDs had some advantages over CRTs from the beginning: they were sharper, had a more attractive and convenient form factor, and used less power. But they couldn’t touch CRTs with regard to color quality, viewing angle, and refresh rate.
But it didn’t matter.
CRTs were on the way out and LCDs were replacing them. There was no denying it. There was really no fighting it. LCDs were the future, even if they weren’t better for everyone and every situation. But, even today, there are certain people and certain situations that demand a CRT instead of an LCD. This is an ever-shrinking segment, but it’s still there. Barely. LCDs that have the color quality demanded by some photography and print pros are available, but their prices are still staggeringly high. And how many companies are making CRTs?
Today, HTML5 can do a lot of what used to only be possible with Flash. It can’t do everything and when it comes to complex animation and interactivity, building something with Flash will be faster and cheaper.
But it doesn’t matter.
HTML5 is the future. There’s no denying it. There’s no fighting it. Flash is getting replaced by HTML5, even if it’s not better for every situation. If you make something with HMTL5 instead of Flash, it can be viewed properly on modern browsers and mobile devices. And, today, that’s enough to make it the better choice. Even if the end result looks and acts better and takes less time to develop and test with Flash, HTML5 is going to be used in place of Flash for many applications. As it should. Because it is the better choice. But there are certain times where Flash is still the way to go. And it’s going to be that way for years to come.
Choosing the better option isn’t always the best choice. (Yes, that’s meant to be a brain twister.) Just as the image quality of LCDs couldn’t touch the image quality of CRTs, LCDs won. Digital cameras outsold film cameras before digital cameras actually took better pictures than film cameras. The fact that the pictures weren’t as good and they had frustrating shutter-lag didn’t matter.
Digital won before it was better.
What’s my point? Maybe just that someone who says that HTML5 is better than Flash is like someone saying, five or six years ago, that LCDs are better than CRTs. In what way? Maybe yes, maybe no. I’ve always been and remain more interested in the absolute quality of things. Especially visual things. So it hurts a little to see the look and feel of the web degrade a little bit in the name of progress.
I’m just musing. This blog is titled Erik’s Brain, and this is the thought that popped up there just a few moments ago. Onward to the next though: I need lunch.
Hype is Hype
Hype, a new tool for making “beautiful HTML5 web content” is out. Based on what I see in the gallery, they couldn’t have picked a better name for it.
To see my favorite part in their marquee demo:
- Click the WHERE button
- Then Scenic Route
- Then Long Route
Ah yes… This reminds me of bad Flash sites from ten years ago. Also note: The back button doesn’t work. Awesome.
Really, this one is worthy of being featured as a demo? Refresh the page if you missed the coolness.
This lens flare thing is just horrible. It’s like Flash from twelve years ago. At least add some blurs to those circles. HTML5/CSS3 does support blurring, right?
The best part? It’s $30! (That exclamation point indicates incredulousness, not excitement.) I thought maybe this was a new open source framework for making HTML5 animations. Nope. It’s a commercial product.
Maybe they need to put this tool in the hands of people who can make things that are actually impressive. But these demos are sad. I predict the links in this blog post will be dead in a matter of weeks when better stuff crops up and they try to hide what they are showing off now.
John Gruber said “Fire up their gallery of examples on your iPad or iPhone and get a glimpse of the future.” I agree that HTML5 (and related technologies) is the future of the web. No doubt. But the future doesn’t need to look and act like bad Flash. There is a ton of great HTML5 stuff out there. But this? Based on the demos they are showing off? It’s a tool for making crap.
Flash isn’t the enemy
I’m following Gruber’s lead and trying to run without Flash. It’s interesting so far — most notably, Safari is much faster and more stable without it.
It wasn’t until Apple started their big anti-Flash push that Safari started to get crappy on me. I never had an issue with Safari crashing before Safari 5. That’s when they set it up so that plug-ins ran as a separate process, apart from the browser. The reasoning behind that was that Flash was the #1 reason that Safari crashed. So with Safari 5′s new design, Flash would crash on its own and Safari would continue to run.
BUT, up until that point, Safari almost never crashed on me. Now I get “Flash has crashed” freak-out messages from Safari once or twice a week1. And if Flash is crashing in Safari 5, that means the entire browser would have crashed if I was running Safari 4, right? But Safari 4 didn’t crash once or twice a week. I’m not going to get all conspiracy theorist on you, but it just seems like Apple is going out of their way to make Flash look worse than it is. And have you seen this bug where, under certain situations, text rendering can look horrible if a SWF is embedded in the page? It’s a Safari-only thing. And it seems to only be with Safari 5 under Snow Leopard. This one is totally on Apple. I wonder if they’ll fix it or just tell us that it’s Flash that’s breaking the page.
This whole “Flash is killing my browser” pity-party isn’t total bullshit, but what are these anti-Flash, HTML5-loving geeks going to do when Flash is banished and all of these horrible banner ads are created with HTML5 code instead? If you think that Flash is hard on CPUs but HTML5 animation isn’t, you are really drinking the Kool-Aid.
Oddly enough, you want to know what makes Safari crash and crash hard? Quicktime. That recent live streaming of the Apple event killed Safari three times in less than 90 minutes. Oh the irony.
It seems that one of the biggest reasons that people hate Flash is because there is so much bad Flash out there. I’m not going to argue with that. I’m sure I’ve made at least a SWF or two that’s contributed to that. But removing Flash from the web isn’t going to remove bad taste from the web. You can ban spray paint because spray paint is used to tag personal and public property. But that isn’t going to stop people from defacing things. Unless you want to ban web publishing, there is always going to be crap on the web and the crap is always going to outnumber the good stuff.
This whole anti-Flash bandwagon is like the web’s equivalent of the Tea Party movement.
1 This is an estimate. The vast majority of Flash crashes are due to MLB.tv, which is the worst web service I’ve ever used in my life. Crash-tastic. Yes, it’s built with Flash, but it’s the fact that the developers don’t know what they are doing that make it crash-tastic, not the technology behind it.
Jeff Rock – Down the Memory Hole
Jeff Rock – Down the Memory Hole.
The use of the word “flash” was pretty over the top. It felt totally intentional in yesterday’s presentation and it wasn’t lost on me.

The Adobe/Apple Brouhaha – My Thoughts
Flash CS4 is a bit of dog. I’ve documented a few of those issues. When I first heard that Adobe was adding the ability to create iPhone apps with Flash CS5, I rolled my eyes and thought, “Why are you working to add this major feature, the ability to make shitty iPhone apps, when you should be FIXING the Flash IDE?”
So, while I think it’s a shady move for Apple to ban the ability to write iPhone apps using tools like Flash, I also don’t really care that much. And there are probably some good reasons for it. I really didn’t have any interest in using Flash CS5 to make iPhone or iPad apps. My gut tells me that you won’t be able to make top-notch apps with Flash CS5. If you want to make a really solid iPhone app, you’ll need to create it with the native languages. This partly comes from my experience with Adobe Air apps. I gave up on them pretty quickly because they were pretty laggy and generally gave a poor user experience. This had as much to do with the nature of the technology as it did with the developers. Meaning, it isn’t really the developer’s fault that Air apps are slow and laggy and just don’t feel like native desktop apps. But, since Air apps look and feel different from native apps because they aren’t written created with the native frameworks for the OS, they are automatically NOT going to feel right.
By the way, the whole concept of “write once, deploy everywhere” is an idiotic pipe dream. Making something for a 3-1/2 inch touch screen is not the same as making something for a 10” touch screen which is not the same as making something for a 24” desktop PC. You can do it (most websites only exist in a single version that runs everywhere) but at best it won’t be ideal and at worst it will make people want to punch you in the face.
Oh, Flash CS5 does have some cool new features. The most exciting to me is the uncompressed XFL format, which will make Flash source files (FLAs) play nicely with version control systems. Score.
Mercurial and FLAs
I’m starting to play around with Mercurial and wanted to see how well it handled FLA files. Mainly I wanted to know how much the repository would balloon as your revised and committed the FLA. So I did a simple test where I made an FLA, committed, added a big image to it, committed, made some other changes, committed, etc. Based on this very quick, simple and unscientific test, Mercurial does a pretty good job storing FLAs efficiently.
Start with empty FLA:
FLA is 57K, .hg is 53K
Added a single image to the FLA (+ the .hgignore file):
FLA is 381K, .hg is 274K
Embedded a font in the FLA:
FLA is 385K, .hg is 283K
Added another image to the FLA:
FLA is 1.1MB, .hg is 1MB
Converted image to MC, added to stage, blurred it:
FLA is 1.1MB, .hg is 1MB (977K)
Changed the blur on the MC:
FLA is 1.1MB, .hg is 1MB (989K)
Made another MC, added to stage, blurred it:
FLA is 1.1MB, .hg is 1.1MB (1010K)
So essentially Mercurial is storing 7 different versions of the same FLA and the repository is only 1.1MB (it’s actually smaller than the FLA it’s been tracking).
Just thought you might like to know.
TextField.onSetFocus and onKillFocus weirdness
I had to make a quick form using ActionScript 2 today. I wanted to add a quick little feature where the default “filler” text would be wiped out when someone clicks on the text field to start editing. Also, if the user left the text field without typing anything, the “filler” text would come back.
Simple stuff. And the code goes like this:
var startTextFirstName:String = "First Name"; tfFirstName.onSetFocus = function (obj:Object) { if (tfFirstName.text == startTextFirstName) tfFirstName.text = ""; } tfFirstName.onKillFocus = function (obj:Object) { if (tfFirstName.text == "") tfFirstName.text = startTextFirstName; }
I did that for three text fields. But it only worked for one of them. Weird.
Turns out the fix was simple. I had the uncooperative text fields set as MULTILINE input text fields. Change them to SINGLE LINE fields and all was well.
Gordon – Open source Flash runtime written in JavaScript
Check out the demos.
Does it do anything besides play back linear animation? If not, WHO THE FUCK CARES?!
