We don’t need Flash on the iPad, we need better tools to build HTML5 sites

The recent discussion about whether the web needs Flash or not was overdue. My opinion is this: Yes, we need an alternative to Flash Player, and HTML5 could soon replace it in most cases. But most of all we need a good IDE to develop content for modern browsers.

Flash has two critical shortcomings that make it hard to use for many projects, not only on mobile devices:

  1. Flash Player is an alien in the browser. You just need to look at the strange code that is necessary to embed it to know that. You can’t use your browser’s “Find” function to search its text. The browser can’t save passwords you’ve entered in a Flash form or even fill out a form with the data you’ve entered on other sites. Flash wouldn’t trigger special input tools of a device like mobile Safari’s Picker UI or work with the tap-to-zoom feature. You can’t use the browser’s controls to increase the font size used inside Flash Player. And there are many other examples. I wouldn’t create a complex UI for the browser with Flash anymore because of this.
  2. Flash needs too many system resources. Thats’s something I always thought would get better over time with faster CPUs, but it never did. I don’t know if it is because of Adobe’s laziness or because content keeps getting heavier as well (more pixels per videoframe, more complex video codecs, more 3D objects, bigger screen sizes etc). All I know is that a site that makes heavy use of Flash burns my 2.4 GHz Core 2 Duo today just as it did with Flash Player 4 and my 500MHz Pentium III ten years ago. And that’s why I think Flash Player will never really work on a mobile device.

But today, using HTML5/Canvas for rich clients instead of Flash is no option either as it is not widely adopted by the browsers yet. You would end up in browser hell again. So what can you do as a Flash Developer to solve this situation in the next years? I think it depends on the type of project you are creating:

  • If you create one of these FWA CPU burners: Don’t care at all, make it full Flash as always. Nobody could enjoy it on a mobile device anyway because of the smaller screen size. Wear your blue lego shirt with pride! ;)
  • If you build a video/audio player, a slideshow or interactive charts: Use the Progressive Enhancement technique. Build a Canvas/JavaScript/CSS-based solution and implement a switch to replace it at runtime with a Flash version, if the browser doesn’t support the tags you’re using. Yes, that means extra work, but you can tell your client that he gets an “iPad version” for free! He will love it.
  • If you develop games: Most Flash games can’t be simply ported to mobile devices, even if they run Flash Player. That’s because you have different input controls. You don’t have a keyboard on the iPhone for example (btw: HTML5 games like this one suffer from the same problem). So you have to decide which platform you want to build for anyway. Or try to design your game to work without a keyboard and mouse over gestures etc. In that case you can hopefully run it on Android with the upcoming 10.1. player and probably port it to the iPhone as a standalone app with the upcoming Flash CS5 exporter.
  • If you develop a regular website: Try not to use Flash at all. Especially don’t use Flash only because you can. I did that a lot in the past and instantly regretted it when the Eee PC and the iPhone came out. If you have to integrate media content that can only be displayed on IE with Flash, use Progressive Enhancement. It’s the only way to ensure a good experience across all devices and browsers without creating a special version for each platform.

So chances are you have to learn some JS/CSS/HTML5. But probably you’d have to learn that anyway in the next years. And it can be fun, because nowadays JavaScript-Frameworks like jQuery will do the dirty DOM-work for you. The only problem is that you won’t be able to continue working with the tools you’ve got used to. There’s no IDE for building HTML/CSS/JS-based interfaces that is as easy to use as FlashBuilder/Catalyst or the Flash IDE. Today, I’d say the best thing about Flash (besides AIR, which is a totally different story) is AS3 and the IDE. And the biggest problem most Flash developers will face when they start to create HTML5 is probably JavaScript and the lack of a truly integrated IDE.

If Adobe wants to keep their customers happy they should stop whining about the iPad and start creating a great IDE for developing HTML5 apps. And by that I don’t mean copy/pasting SVG snippets from Illustrator to Dreamweaver. What about coding with AS3 and converting it to JavaScript in a cross-compiler manner, like the Google Web Toolkit does? What about introducing concepts like Skin States or the Timeline to HTML5 development? What about drawing your SVG graphics and cropping images within your coding environment? Automatically creating CSS sprites from your designs?

I definitely want that more than a Flash Player for the iPad.

16 thoughts on “We don’t need Flash on the iPad, we need better tools to build HTML5 sites”

  1. Great post, I totally agree. The tools for creating HTML5 sites aren’t that great right now, but hopefully as the iPad and iPhone get into the hands of more people, developers will come up with better solutions.

    I think it also has a lot to do with education and documentation. A lot of the features of mobile Safari and even HTML5 aren’t well documented in a lot of places yet.

    Lastly, I can understand why people are upset about there not being Flash on the iPad, but I think that’s just because they don’t understand how capable mobile Safari really is. For example: http://doctype.tv/mobile [video]

  2. > CPU usage
    There’ll always be sites pushing the limits, using a lot of resources. That won’t change with HTML5. I’m afraid it’s a popular myth that HTML5 has a better performance than Flash – just watch your CPU usage on some demo sites.
    There was a very nice HTML5 demo winning an FWA recently – 100 particles … using about 50% of my CPU. Using Flash instead would bring that down to 0%.
    But every Flash dev would then go for 10000 particles, again burning your CPU.

    Dunno.. getting rid of all gimmicks and effects might make batteries last longer, but wouldn’t life be a bit boring then? ;-)

    >don’t use Flash only because you can

    Wholeheartedly agree to this one though!

    Cheers, Dan

  3. @Dan
    You’re right, HTML5 sites can also burn your CPU and there will always be programmers who try to max out your CPU. And I think trying to push the limits is a good thing, too!

    I just believe that for most everyday web apps like video, charts etc. there will be a performance advantage with HTML5 pretty soon. One reason is that HTML/JavaScript doesn’t run within a sandbox in the browser and the browser can manage the system resources needed by HTML apps far more efficiently (I just say web workers). Another reason is the strong competition between the browser manufacturers. It has led to absolutely amazing performance improvements since Google has started to build apps like Docs and Maps. I’m convinced that Apple, Google, Mozilla (and maybe even MS) won’t stop to push the JavaScript performance before web apps are on par with their desktop counterparts.

    And I’m afraid that Flash will not benefit from this at all.

  4. There are TOO tools for doing the kinda of things you do in flash in dhtml. Check out http://www.openlaszlo.org/ . This includes animation, complex GUI interaction, etc.. Though we don’t suggest you do so, my company’s flagship producs, webtop, written in openlaszlo, works pretty well on the iphone – albeit SLOW and not particularly well optimized for use on that platform.

  5. Your remark that flash needs to many system resources is not entirely correct.

    For one thing: Mac OS X does not (yet) provide direct access to the video card/gpu, and that’s why the flash player on the mac uses so much CPU. Flash player 10.1 promises to fix a lot of these mac os x cpu problems.

    But more importantly: a full-fledged application with many running processes and complex interactions cannot be compared to a static text-based web page. Of course the application will use more CPU!

    When HTML5 becomes more capable of building real applications, you will see the same increase in CPU usage. I even read somewhere that HTML5+javascript+CSS3 actually needs MORE cpu to accomplish the same functions as flash.

    Another problem with the increasing complexity of HTML5+Javascript+CSS3 is the wild variety of standards, and the lack of a real application development environment.
    As long as you’re building static text pages this isn’t a big problem, but when you build a complex app in html, the code really becomes quite inaccessible.

  6. @Dorian
    I know what you mean and you may be right. Or not. I don’t know. ;-)
    You’re talking about the future now but that’s speculation, none of us has a crystal ball.

    I merely wanted to point out that today Flash is a lot faster.
    Exept on Macs but that’s old news.
    There’s a lot of misinformation spread about this these days.

    I think us media pros have an obligation to cut through the hype and provide a balanced view.

    Both browsers and Flash will continue to improve, they’re all under competition. We might well see one browser becoming really fast and maybe catch up with Flash, but what about the other browsers then?
    At least Flash currently means consistency for the largest possible audience.

    > (and maybe even MS)

    Quite nonchalant ;-) that’s 50% of your audience.

    Totally agree that all technologies have pros and cons and you should pick the right tool for the job. But if you’re after a rich experience today and recommend against Flash cause tomorrow browsers might catch up.. that seems adventurous.
    And the meaning of “everyday apps” is constantly shifting, today it’s video, tomorrow it’s HD video and so on.

    Cheers, Dan

  7. To all you HTML5 newbies, it is AJAX all over again. People said AJAX will kill flash and here we are not one of your posts talks about AJAX. The problem with HTML5 is vendor implementation. You end up having to debug your app for each an ever single browser and browser version. Been there done that. But you if newbies want to try it be my guest. I am sticking with Flash.

  8. rmunix, to be fair JS libraries these days do a good job of abstracting browser idiosyncrasies away. When people talk about how JS has “matured” what they really mean is there are libraries to battle the mess, JS itself hasn’t changed for ten years. Libraries aren’t ideal if you’re after high performance though.
    But still, yes… HTML devs spend a lot of time working around detail issues with layouts and CSS in various browsers.
    HTML development generally tends to be more expensive than Flash.

  9. “Flash needs too many system resources.”

    I think the reason this is an issue is because of poor programming. sue flash uses more resources, but it does WAY more than other technologies.

    if a developer writes clean code that includes clearing out your objects and events when you are finished with them, this should not be a problem.

  10. html5 is pretty good, but it has nowhere near the power or browser penetration that flash has.

    also, apple doesn’t allow html5 to perform to it’s full potential. they disable javascript calls to the audio elements for one.

    IMO they do not want any technology to threaten their app store business. I’d gladly build iphone apps if there weren’t so many restrictions on what you can build. why spend months or even years building apps that could be denied by apple.

    I don’t like wasting my time or being censored.

    I love apple desktops. I wouldn’t use anything else for developing, but they need to let creativity and innovation be more free on their mobile platforms.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>