Flash has gotten a lot of bad press over the past couple of years. Without getting into ideological discussions, we wanted to explain why we chose Flash as the technology we use for our web app.
Flash was “killed” prematurely.
Steve Jobs would have everyone believe that Flash is dead. “HTML5 is better than Flash.” We don’t need Flash anymore. Yadda yadda. You can read arguments for and against all over the web. I’m not interested in arguing the point. From my point of view, technology is simply a tool, and the best tool should be used for any particular job.
The problem with the whole Flash debate is that people get very emotional about it, and don’t take the technology for technology’s sake.
One of the best posts I’ve seen on the subject is this one by Grant Skinner.
Yes. HTML and HTML5 have their strong points, and Flash is not without problems. However, the fact remains that neither the tools nor the frameworks for HTML5 were there yet when Steve Jobs decided to wage a war against Flash. My personal opinion is that bad experiences people have had with Flash is not Flash itself but bad apps. Look around. You will find very few complex apps out there that utilize HTML5. Yes. New apps are coming out all the time and the tools and frameworks for HTML are catching up, but in some areas Flash is the undisputed king.
Browser Discrepancies
Anyone who designs web sites knows you need to test your website in every browser available because it will be rendered differently in every browser. This is particularly true when it comes to text. Every browser has its own rendering engine, and it’s not going to look the same across browsers. It does not take a rocket scientist to realize that you have a problem if you want to accurately render text in the browser for consistent output.
Lack of Development Frameworks
Okay. Standard browser rendering is out. We cannot use that. Then what? We need a browser-independent rendering engine. Okay. HTML5 has canvas. You can pretty much draw what you want in canvas.
Ah. But therein lies the problem. We need a fully Unicode compliant text engine that renders text faithfully to the rendering achieved in InDesign. Writing such an engine from scratch is a monumental undertaking, and this is just one of the hurdles that must be overcome. Can it be done? Probably. But in how much time? Is it cost effective if we want to release a usable product in a reasonable time-frame? Not at all.
It’s no wonder you don’t see WYSIWYG HTML5 apps out there…
Flex is Good!
Instead we chose Flash with Flex, which has many well-developed frameworks all ready to be used. The most important of the frameworks is probably TLF (Text Layout Framework) which offers a very complete and logical framework for using the Flash Text Engine. It has full unicode support including right to left and Far Eastern features. Rendering is identical across browsers. While not perfect out-of-the-box, TLF allowed us to get the rendering very close to InDesign rendering with minimal effort.
Without going into the rest of the issues we faced during development, suffice it to say, using Flash allowed us to deliver a superior product in record time.
Looking to the Future
One of the most common question we get is whether we are working on an HTML version of our design tool.
The answer is not a simple yes or no.
The question is strongly related to how much of a need there actually is. Who are the end users? How are they using our product? There’s a lot of emotions around the need for mobile/tablet support, but how much is emotions and how much is actual need? Will anyone be doing online editing of graphically rich documents on a smart phone? Doubtful. What about tablets? More likely, but exactly how will they be used? How many users need it? Will a web app or native app be a better fit? It really depends on exactly what the tablet demand will be.
If you have data on the subject that might affect our decision, feel free to let us know!
We are constantly monitoring advancements in HTML5 frameworks and we’re doing constant analysis of how/when we could delivery an HTML5 version or native version of our app with at least close to feature parity. However, our primary focus at the moment is to implement some important additional features to our current web app. More on that in a future blog post.
We are not yet 100% sure which route we’ll take, but we definitely have tablet support on our road-map.