Why Am I Doing This? (The Decline of Flash)

I would probably be much more of a user interface (UI) guy if the tools didn't cause me to tear out handfuls of my now-precious thinning hair. Every single time I try to find a new and better way to do UI I run into everything from edge cases that the language designers didn't think were important, to downright bad design.

For quite awhile I've felt that programming Flash with Flex was going to be the good solution, because they started from scratch to specifically solve the UI problem, and "adapted" to the browser via a virtual machine (VM). Through one of my conferences, I knew about Flex before Adobe bought the company that created the technology, and it always seemed promising. For a time I was even writing and speaking about Flex.

Now that I examine my feelings a bit more deeply, I realize that my intuition was telling me, "Yes, but." As in, "But it's not going to work out in the long term." (My intuition is very mysterious and there's no logic to how it knows things. If there was logic, I guess I wouldn't need intuition).

This is not the fault of Flex, but rather an accumulation of occurrences (things like those I try to puzzle through in Reinventing Business). Of course a big change happened when Flash didn't keep up with handheld devices and it became clear that Flash was a drain on batteries (if we'd gotten better battery technology then things might have gone a different way, but even then manufacturers would probably just have made smaller devices. On handhelds, code efficiency is going to be an issue for a long time). Worse, Steve Jobs declared "no Flash on iOS." It's hard to ignore the direction of Apple these days. I know that Adobe is working on a solution for this, translating Flex into some kind of HTML5; perhaps this will pull the fat out of the fire but that remains to be seen.

Friends have been reporting stability issues with Flash. I've had it lock up the Chrome browser a couple of times. Basic quality control issues on such a (relatively) old (and essential) piece of software is a troubling development.

One of the big nails in the coffin for me happened when Adobe decided to drop support for Flex on Linux. It's not just the fact that they've backed away from a promise, it's the deeper implication: it means that bean counters rather than technologists are setting the goals for a technology company, and that has never turned out well.

I've declared elsewhere that "Trust is the first law of the Internet," and this is an example of that. If I can't trust that Adobe will support Flash on all platforms, then I can't get boxed into it. Thus I must start moving away from Flash as a general-purpose solution. As heinous as the alternative is (HTML/CSS/JavaScript), it seems we are doomed to it for the near term.

I still do like Flex and see it as a solution when you can control where it's being used, but if I was trying to build a general-purpose application that had the remotest chance of being used on handhelds (and these days, when is that not a possibility?) I'd have to use HTML5.

I do notice Adobe seems to be branching out; there's now a FlashBuilder 4.5 for PHP, although I have no idea what it even means to build Flash for PHP, unless it creates the front end as Flash and automatically connects it to a PHP back end and writes the necessary communication code for you. And FlashBuilder 4.5 is supposed to create apps that run on Flash-hostile handhelds like iOS, so all might not be lost in the Flash world.

I'd sure love to see Adobe use its formidable talents to create the ultimate HTML5 development environment. With their ability and reputation for tools, they could charge well for it and make a lot of money (after this article was written, Adobe announced an HTML5 tool for animation). I'm not holding my breath, but I'd strongly suggest they consider it. (The only recommendation I've gotten so far for an HTML5 IDE is Aptana so I don't yet know this space very well).

JavaScript is an Abomination

The first time I had to do something in JavaScript the experience made me recoil in horror. The syntax of the language varied across browsers! That was some years ago and things have improved (as long as you can assume more modern browsers), but it left a bad taste in my mouth.

I recently came across the lecture Javascript: The Good Parts by Douglas Crockford. He has studied JavaScript long and hard from a language scholar's perspective. He invented the JavaScript Object Notation (JSON) which has become an often-nicer-than-XML alternative for passing data around (there's even JSON-RPC for remote procedure calls; the Go language has this in their standard library whereas they have yet to implement XML-RPC). Crockford also created the very useful JSLint tool that checks your JavaScript for the legion of possible bad coding practices. Everyone should be using this.

Based on his lecture, I went out and bought his book of the same name. If you must work with JavaScript, this book is required reading -- it's not an introduction to the language, but it's necessary in order to understand the countless pitfalls and idiocies of the language.

If you have any doubts (or outrage) about my use of the word "abomination," Crockford's book will eliminate these. As you go through the book (which will probably require repeated readings if you are a serious JavaScript developer), your forehead will become red and splotchy from all the facepalming you do.

Seriously, it's incredible how bad this language is. And the deep irony is that there are now legions of programmers whose first experience has been writing JavaScript, typically copied from equally terrible "view source" examples they've seen on the web.

Crockford's book teaches you deeper ideas in the language and ways to (barely) bring it under control, but he shows you again and again how troubled and flawed this language is. And I love his arrogance; in the lecture he says that you can learn the wrong way to do things by reading "any other book on JavaScript."

The lecture Learning to Love Javascript by Alex Russell is a little more hopeful and gives you additional perspective on the language. Russell is on the committee and tells you how they're trying to improve things. He also works for Google, who seem to be adopting some variant of JavaScript to be used for scripting.

Closures and Why They're Essential in JavaScript

Closures appear to be the most misunderstood language feature I've ever seen. I cannot count the number of times I've seen writers equate closures to anonymous functions. This confused me for the longest time when I was trying to figure them out, and the propagation of this idea has confused many others as well (I suspect that a huge number of people in the Java community have been actually asking for anonymous functions when they've been saying closures).

Closure means that a block of code "closes over" variables defined outside that block. More importantly, those variables persist even after they would ordinarily have gone out of scope and disappeared. The closure captures and retains surrounding variables.

Javascript has no linker and this means there must be global variables. This is one of the worst things about the language. If you're creating small toy examples or simple scripts, this is tolerable. But JavaScript is used within your browser, which is an accumulative environment which assembles lots of code from lots of servers to present a page. And each piece of code makes its own global variables and functions which can collide -- at the time you load the page, so there's virtually no way to predict it -- with all the other code that's been loaded. Loading a page becomes a fantastic, spectacular war.

The solution is to use closures to create variables that are essentially private. Once those variables have gone out of scope (a tricky term in JavaScript, which has a different idea of scoping), they become unavailable and invisible except to the closure that captured them (often this closure happens to be an anonymous function, which contributes to the confusion about the term).

This is just one of the problems that you must solve in order to turn JavaScript into a tolerably controllable language. Crockford's book is all about these things, and once you read it you begin to understand why it's taken so long for AJAX libraries to appear -- first, enough people had to understand both the problems and the solutions and the need to standardize those solutions.

It also becomes clear that the only reasonable way to develop pages using JavaScript is to find and use the best AJAX libraries (at this point, I'm a novice and don't know what those are). Using JavaScript with AJAX seems to be much like programming in a slightly different language.

The Lack of Leadership

One thing that's very frustrating is how long we've been doing this, and how many opportunities that the various committees have had to try to fix things. I'm going to guess that there's been too much at stake and pressures from corporations have prevented anything useful from happening.

I don't know who to blame for the way that this has all happened. W3C, I suppose. It doesn't really matter. I can't imagine how we've managed to collect and save all these worst-possible decisions, but it looks like we're totally stuck with this mass of mess.

Really, after all this time there's no way to include standard headers and footers on a web page? And CSS -- who thought that was a good idea? (They couldn't even make a uniformly-adopted standard). It doesn't seem like complaining is going to do any good, either. These standards, as far as I can tell, are created in some kind of weird vacuum.

There is one way out that I can imagine. As the saying goes, the solution to all programming problems is to add another layer of abstraction. In this case, that means that we need a virtual machine for languages as part of the foundation for all browsers. Obviously, the default language distributed with browsers would be JavaScript with all its bad parts, but the virtual machine would allow the addition of many other options -- initially, as downloads but eventually as standard browser distributions. This way we could evolve to much more civilized and powerful languages.

The other layer of abstraction we need is a pluggable DOM. Again, this would allow much better DOMs to replace the crippled one that we must cope with now. Both the VM and pluggable DOM would be tricky to design and implement because of both backward compatibility and the need for cooperation within a single page. But it's important, because the browser is arguably the single most important piece of software in the world -- it's becoming the OS for the user -- and this problem needs to be solved.

The Rise of Alternatives

If I had to program in JavaScript for web apps, I would take a serious look at CoffeeScript (also recommended by Alex Russel). I hope we'll see more of these near-term alternative solutions to the problem.

Interestingly, the Google Apps Scripting language appears to be a (civilized) form of JavaScript, and it looks very powerful, so following my intuition and learning this could actually pay off in the short term. But I also suspect that I will (eventually) have no choice but to roll up my sleeves and wade into the muddy, messy morass that is HTML/CSS/JavaScript. I'm only hoping that, by finding the right tools, I can keep the mess below my knees. Well, below the waist, maybe.