The death of Flash is pretty much official now.

There was a period of a few years on the internet where it looked to many of us like Flash could be the future. I invested some time in becoming a moderately proficient Flash developer, in the earliest years of the new millennium. I even drove to Boston in a suit (a rare and loathed activity for me) to win a Flash contract once.

It seemed to solve so many problems. The weighty tyranny of the bitmap (vector graphics! wow…). The video codec problem (which is still a problem). The Javascript implementations problem (which, thanks to libraries like jQuery, is no longer much of a problem).

Flash looked like the solution to all these things and more, and customers loved sites that were, well, flashy. If they could afford them.

I abandoned Flash a number of years ago for a couple of reasons, neither of which is the actual reason Flash is dying. I was never comfortable getting my development tools and runtime environment from a single vendor. And development time was simply too great in Flash. Sure, you got a shiny object at the end, but polishing that object ad nauseam was for designers, not all-purpose geeks like myself. Most of the projects I get focus on function more than form.

So Flash, I bid you adieu. Yes, I know you still enable the charting rendering a couple of my apps, but not for long, my friend. I’m getting in iPad soon and I’d like to see those charts on that, too… so it’s back to HTML (HTML5? Canvas?) and Javascript solutions. Luckily those have come a long way this past decade.

It was fun while it lasted, Flash.
———

UPDATE: if your biggest aspiration was to be the new Flash? You’re also dead.

I’ve used way too many different documentation systems in my time including RUNOFF, nroff, DECdocument, Interleaf, TeX/LaTex, and PageMaker, just to name some of the older ones. These days my documentation tends to be either just plain old text, org-mode (emacs), HTML, or Perl POD. I find myself, however, once again looking for the ultimate solution for my document formatting needs in anticipation of having to create a lot of documentation for a major project.

At first I was thinking of standardizing on org-mode since that is what I tend to use by default now. Its table editor rocks and the syntax is very readable like Markdown, and other similar lightweight markup languages, with very easy export (for an emacs user) to HTML or LaTex. But I’m concerned about picking an Emacs-centric choice in deference to other maintainers, and the fact that org-mode’s own manual is formatted using GNU’s Textinfo gives me pause.

After casting about, including looking at Texinfo, DocBook, Muse (emacs), and reStructuredText, I find myself gravitating to Markdown and most likely the eventual adoption of Pandoc.

Here’s an article that I found particularly helpful. My current thinking is that the learning curve for Markdown is very shallow so I’m not making an unreasonable assumption for other maintainers, and I can start generating documentation now and worry about pretty formatting, structure and presentation later. I’m also trying to avoid this problem out of the gate…

I’m not happy about putting off the overall document architecture till later, but I’m burning daylight.