Joeflash’s Enigmacopaedia

Flash vs The Open Web: The FUD Continues

Posted in AJAX/DHTML, Browsers, Flash Platform by Joeflash on the April 27th, 2010

The thing that isn’t being said in all of this, in every debate I hear of “Plugins vs The Open Web” is the assumption that somehow, because it’s open, it’s somehow better. Better for whom?

Thing is, users, who at the end of the day are the major consumers, don’t give a damn if something is open or not, just that it works, that it’s interesting, that it captivates their attention, that it allows them to do what they have come to expect to be able to do, which is admittedly a floating target.

Developers, on the other hand, have a more complex set of priorities. What makes a technology good or bad for developers IMO is based a lot more on the perception of that technology vs its actual performance than one might think. That perception is fuelled by developers, but also by evangelists and tech pundits who each have their stake in the acceptance of a given technology.

Just look at the FUD generated by Apple recently around the Flash Player: Steve claims, in sum, that Flash is a crappy technology, and despite such assertions being proven utterly false, others believe it because of the trust Apple has built up around is products. Likewise, many Flash developers (of which I count myself) have decided that Apple is now an evil company who is against them, simply because Apple is protecting their platform’s market share from an incumbent.

So I’m not going to talk about which is actually “better,” because it’s a meaningless conversation. Each has its uses.

The problem I have is with the FUD generated over this issue.

In discussing “Flash vs the Open Web,” I’ll never understand why so many otherwise intelligent and tech savvy people go all soft in the head and completely miss the distinction between a language and a runtime.

People talk about the Open Web as if somehow browser makers Google or Mozilla or Apple or Microsoft or Opera are completely “open” about how they develop their own products. That somehow the W3C or ECMA establishes their standards (which browser makers may or may not implement) based on the feedback of a community of open source developers (which they don’t, BTW).

So how is that different from Adobe being the sole director of how the Flash Player is built?

(And yes, like Mozilla, Google, etc., Adobe does actually solicit feedback from industry and developers on what to include — and like Mozilla, Google, etc., they alone decide the direction of the technology.)

If we apply the same metrics to the Flash Platform as the Open Web, we find that ActionScript (a distant cousin of JavaScript) was “openly” guided by the ECMA, until Microsoft stepped in and played its trump card, derailing the development of ECMAScript 4 forever. Flex, like AJAX, is an open source framework, as are the dozens of open source MVC frameworks and libraries out there. And just as WebKit and SquirrleFish are open source runtime “components” of many browsers, Adobe has released part of the Flash Virtual Machine as open source under the Tamarin project, and AIR 2.0 uses both WebKit and SquirrelFish Extreme.

The only distinction I can see between the Flash Platform and the “Open Web” is that HTML/JavaScript interpreters are built into browsers, and the Flash Player is currently an “add-on” to browsers. But that is changing.

So tell me again how the Flash Platform is different from the “Open Web”?
I don’t see it.

Update: As Ted Patrick tweeted recently on Google’s Andy Rubin:

Sometimes being open “means not being militant about the things consumers are actually enjoying.”

Amen to that.

The Future of Crash Reporting For The Flash Player

Posted in Adobe, Flash Player, FP10, Flash Platform Community, Flash Platform by Joeflash on the February 12th, 2010

Lately Adobe and Flash have taken a lot of heat over the real and perceived instabilities of the Flash Player. Depending on who you talk to, these are due to the Flash Player itself, or the fault of poorly developed applications. But how would Adobe know the difference, other than through us developers painstakingly filing Flash Player bugs (and bugging Adobe to fix ‘em)?

Kevin Lynch recently discussed Adobe’s views and improvements in bug reporting and Flash Player performance. Mike Chambers chimed in to confirm these changes to the Adobe Bug system. And just today, Tinic Uro, Flash Player engineer from whom we have not heard from in over a year and whose articles are amongst my most prized links, treated us with an article on Apple Core Animation vis Flash Player performance.

And with the inclusion of the much anticipated (and debated) Global Error Exception Handling (FP-444) in Flash Player 10.1, Adobe has shown that the community is being heard (eventually).

This is a good first (and necessary !!!) step, but what the Flash Player needs is better automatic crash and exception error reporting.

My colleague Matt Fabb and I have put together three feature requests that I believe hold the key to making the Flash Player a much more robust development platform.

  1. In the right-click context menu include a link to the player’s bug system
  2. Automatic crash reporting built into all versions of the Flash Player
  3. Flash Player API hook to allow for custom automatic exception error reporting

(PS: Vote for these FRs!!)

The first allows people to submit a bug to Adobe’s (now open) Bug Reporting system, which Matt has eloquently described on his blog.

The second feature request would have a second process “monitor” the health of the Flash Player and send an automatic crash report to Adobe if and when the player process crashes through a fatal exception (which most of the time also takes down the browser). This will give Adobe invaluable insight as to why so many users bitch about claim that the Flash Player is unstable on certain OS/browser configurations, without Adobe relying solely on an army of QA engineers.

The last feature request would allow for an addition to the global exception API (as requested in FP-444 and detailed in the livedocs), to allow developers to specify a server to automatically send uncaught exception data, in the eventuality that the application itself crashes, which would prevent it from otherwise being able to send such a report.

Vote for these three feature requests, and get a glimpse of what the future may hold.

Does Flash Need Saving? Nahh…

Posted in Adobe, Browsers, Flash Platform Community, Apple, iWhatever by Joeflash on the January 31st, 2010

Flash isn’t on the iPhone. It isn’t on the iPad, either. And for this, everyone is losing their minds.

Flash haters are coming out of the woodwork proclaiming the death of Flash, eager to feast on the dead flesh of another technological casualty while they bow in fealty to their white shiny god (Apple, dummy! :). Silverlight lovers, usually so vocal against Flash, are conspicuously absent from the debate.

But I think it’s a little premature to announce the demise of Flash. As my estimable colleague Derrick Grigg pointed out, there are so many things that Flash can do that are specialized and unique that no other web technology can do well.

As to the criticisms of the Flash Player: it crashes on OSX, it’s unstable, it’s insecure, it’s a resource hog. All potentially true, on the surface. But like a fixed TV debate subject to concision, 140-character tweets and troll rebuttals cannot give the whole story.

Flash does not work as well as it can on OSX because Apple and Adobe aren’t working well together, for whatever reason. Whether it’s Adobe being lazy in not utilizing Carbon in innovative ways, or Apple will not cooperate with Adobe in helping them develop better integration, I don’t particularly care who’s at fault. And it doesn’t look like it’s going to improve anytime soon. It looks like the two have declared war on that issue.

Runtimes like the Flash Player are more akin to browsers than the language which runs in them. So comparing HTML5 to the Flash Player is like comparing apples and oranges. It would be a more equal comparison if the Flash Player runtime were compared to Firefox, or Chrome, in that the Flash Player is the engine that renders [a SWF file containing] the language. Saying that HTML5 is better than Flash is like saying Javascript is better than Firefox. Huh? Say what?

Why Flash is Not on The iPad

Posted in News, Adobe, Flash Player, Mobile Flash, FP10, Flash Platform Community, Apple, iWhatever by Joeflash on the January 30th, 2010

There is a polarizing debate going on between “iPad - Flash = Epic Fail”, and “Flash is dumb/crashes/obsolete/ads/porn/who cares,” bordering on the religious. Problem is, many of the cons against Flash are the same tired HTML fanboy arguments one hears, as if by trolling force alone millions of sites will go dark overnight. There’s only one reason why Flash is not on the iPad, or the iPhone for that matter.

It’s not 3G bandwidth. If Rogers or AT&T has oversold its network capacity and cannot deliver 1/10th of its advertised 7.2Mbps with a clear signal in a major urban environment, they deserve to be taken to court for false advertising. Even then, I am on a wireless connection at home, and during peak hours the connection can slow to dial-up speeds. When that happens, I click on FlashBlock, and only click to enable the Flash content I know I want to watch. So tell me one good reason why Apple could not disable all VM plugin content by default, and enable them by a click on the little blue lego. No, I can’t think of a reason either.

It’s not performance. As Lee Brimlow, Flash evangelist for Adobe comments, Adobe is willing to work with Apple on improving the performance of the Flash Player for this mobile device, as they have with every other major manufacturer. The fact of the matter is, Apple will not let Adobe play in their sandbox. And yes, I will concede, Flash could be better engineered to run on a Mac, as John Gruber claims — but that is besides the point, because we’re talking about a completely different product and OS here. As Peter Elst mentions, “With the iPad we’re talking about a different device, a processor that clearly is capable of high performance rendering”.

It might be about the fact that Flash will allow content that cannot be sold on the App Store, but that does not hold water either. App store revenues of millions a year do not threaten a billion dollar revenue base.

There is only one reason I can think of that makes any sense why Apple would do this.

The Age Barrier Myth in The Flash Community

Posted in Business, Inspirations, Employment, Flash Platform Community by Joeflash on the December 9th, 2009

A very interesting question, or rather comment, was raised a few weeks ago in a LinkedIn discussion titled,

“Why Am I in Demand?” - Personal Branding for Mature Workers

The problem with this question, other than being a blatant grab for eyeballs, is that it’s not targeted in the least towards the Flash community. But it does underlie a perception I’ve noticed amongst some Flash designers & developers who may be just starting out, or are looking at stepping up their profile in the community and the job market.

I’ll save you the tedium of watching this video blog: according to the author, there are 5 questions you need to ask yourself:

1. What makes me tick?
2. What can I deliver?
3. How do I make my workplace better?
4. Why am I in demand?
5. Why should you hire me?

First, if you’re interested in becoming an office drone, with a job as exciting as the monotone delivery of the author’s video blog post, then by all means answer these questions. But if you want to have a kick ass job or a freelance business that you’ll love, ask yourself this:

1. How well do I communicate, verbally and on paper?
2. Do I have the chops to get the job I want, and if not how do I acquire them?
3. Do I care about sharing my discoveries and fostering a sense of community?

Second, the very idea that a person would be reading a blog dedicated to “Personal Branding for Mature Workers” is just wrong. I’ll tell you why:

It doesn’t matter how old you are in this industry. That’s a myth.

Surviving as a Flash Platform Component Maker

Posted in Business, Flex, Community MX, Adobe, Best Practices, Components, Flash Platform Community by Joeflash on the October 17th, 2009

There is no doubt: making it as a commercial component maker is a tricky business, what with open source competition on the one hand, and Adobe being possible competition on the other. Now that we’ve defined the kinds of commercial components in the previous post, with these roadblocks, how do you make it in the current commercial ecosystem?

While reviewing recent discussions over at Grant’s blog while writing my previous post, I was reminded of a few things about successful component companies, which I recently discussed in an email conversation with Jeffry Houser over at Flextras about the matter, who encouraged me to blog about some of the points I brought up.

Now keep in mind I’ve never built a business model around making money developing Flash components, so take this part for what it’s worth; however there are a few things I’ve observed over the last decade in the Macromedia/Adobe/Flash industry about successes and failures in this area.

Most commercial Flash component makers start in one of two places:
a) they begin offering mid-level components
b) they have a successful but related business, and offer commercial components to go with their existing proprietary SAAS or server technology.

We won’t even talk about throwaway commercial components, because as I mentioned in the previous post, they should be open sourced anyways.

Starting a commercial component business based solely on mid-level components, as some have done, offers the benefit of relatively little startup capital (basically sweat equity), which gets you up and running very quickly. However, mid-level components can be challenging to hang a business model on, for a few reasons:

a) If they are “extensions,” (i.e. AcmeEnhancedDataGrid) Adobe could, tomorrow if they feel like it, come along and incorporate those ideas into the next version of the framework. In other words, your components may at some point come into conflict with FOSS components of similar functionality.

b) Which means that someone else could also, if they put in the effort, rip off your ideas, at least functionally, and present unwanted, even “illicit” competition, depending on how much they copied you.

c) The lack of phone support and strict licensing means that IT departments, used to spending big bucks to have added functionality at a minimum of fuss, might not regard it/them as serious candidates for an enterprise app, and may not even bother to dig into the API to find out if it has green threading or loose binding functionality.

Competition in the Commercial Flash Component Ecosystem

Posted in Business, Flex, Adobe, Frameworks, Components, Flash Platform Community by Joeflash on the October 17th, 2009

There has been some discussion recently as to whether FOSS competes with commercial component offerings, and whether Adobe is unfairly competing with its own developers. Well, the answer is maybe, and maybe. The confusion is partly due to a lack of definition as to what constitutes a commercial Flash component, which lies at the heart of the matter. In the case of Adobe unfairly competed with Grant Skinner, well… read on.

Whether FOSS constitutes competition with commercial components, it all depends on what type of commercial components we are talking about, which is the crux of the matter.

First, let’s define what is not a commercial component. Components developed under no license, or under a FOSS license is not commercial, whether they be pre-compiled SWC-type component, a component with sourcecode, or a component which is really just part of a larger open source library.

Types of Commercial Flash Platform Components

1. Amateur or ‘Throwaway’ Components:

A throwaway component is more of the “Monster Template” or what I derogatorily call “FlashKit”-style components. It’s more of a one-shot use component, often with an incomplete API, sometimes not very great encapsulation, little documentation, no support, and cheap. Great if you’re a beginner-to-intermediate developer and you need a quick fix, but not very useful otherwise. Most times these components should be released open source, if not due to their incompleteness, then because even if it is just a few bucks, often you’re just paying for some-dude’s-experiment. Commercial software needs to be up to certain standards IMO, or it should be free, and even then.

There is no question that FOSS and future Adobe framework offerings will compete with these kinds of components — but did you honestly think anyone would actually pay for them anyways? So they’re not really a factor.

Most of the controversy about competition, either from Adobe or from FOSS, is due to a confusion in the difference between what I call a “mid-level” and an “enterprise” component.

2. Mid-level Components:

A mid-level component, in my view, can be either a mashup widget, in that its innovation or rather uniqueness lies in doing something new in the realm of webservices or connectivity, like a Google Map widget. It is also common for mid-level components to be enhancements or extensions of existing Flex or Flash components, including some media players, because they enhance what an existing component architecture already does, or provides a better version of an existing Adobe or open source component.

There is a big difference between a throwaway and a mid-level component: mid-level components often have a well-crafted API, sound documentation with examples, sometimes even the source is included. And with some of the better companies, responsive help forums, and/or email support is present.

3. Enterprise-level Components

Don’t Panic: The Rebranding of Flex Builder

Posted in Flash, Flex, Adobe, Workflow, Flash Builder 4, Flash Platform Community by Joeflash on the May 24th, 2009

I’m going to throw my hat in the ring here: I think naming Flex Builder as Flash Builder is a good thing overall. Part of the challenge for developers today is that there are now so many interconnecting technologies under the umbrella of the Flash Platform, that some of the naming needs to catch up with technology, and I believe that’s what’s happening here.

The Flash Platform now consists of a technological system comprised of multiple runtimes, tools, frameworks, and languages, so that simple words such as “Flash” and “Flex” no longer suffice to differentiate what we’re talking about anymore. In fact, I personally wrote an entire chapter in our book Professional Flex 3 on describing the Flash Platform and the “Flex ecosystem of technologies” just to clear the matter up.

Personally, associating the word “Flex” with an SDK (consisting of a framework and a compiler), a development tool, a framework and an overall development methodology, in my experience has led to a lot of confusion. Using the word “Flash” generically has also lead to a lot of confusion — is it a runtime, an IDE, the file you run in the browser, or an approach to rich media development? What is Flash? What is Flex?

I think the time has come to drop the generic use of the words “Flash” and “Flex”. Or at the very least, for the sake of tech pundits and journalists who may not have the in-depth knowledge of us designers and developers, to assign the word “Flash” as meaning “the Flash Platform” or “the Flash Player”, and have “Flex” mean either “the Flex framework” or “Flash Platform enterprise/RIA development.” That would be my vote, and how I have come to think of those two words in generic terms.

In rebranding Flex Builder to Flash Builder, what we are seeing here is a move away from using the word “Flex” as describing “enterprise or RIA development in the Adobe technology space” (amongst its other uses) toward using the word to describe simply the Flex framework and associated tools. By moving back toward the use of the term “Flash,” Adobe is slowly rebranding Flex as being a subset of the Flash Platform, not a complete technological ecosystem in and of itself, which on the whole is a lot clearer and more balanced. And I’m all for making things simpler and clearer for clients to understand and adopt the technology.

The Case Against Ignorant Tech Analysts

Posted in Flash, Business, Flex, Publishing, Flash Platform Community by Joeflash on the February 28th, 2009

It seems to be a recurring trend amongst amateur or ill-informed tech pundits to take aim at misuses of Flash as an argument against using the technology as a whole. And once and a while this mis-aimed cannon of vapid sophistry also takes aim at Flex. And quite frankly, I’m tired of it.

I mean, as a Flash developer for over 10 years (now a Flex developer too ; ), I’m never shy to admit that Flash Platform applications have their limitations and misuses. There is definitely a place for XHTML applications, instead of or as a complement to a Flash-based presence, and skip intros are a no-no. And as I’ve stated before, if you’re going to publish a site in Flash with lots of text, make sure that that text is at least accessible. But if you’re going to provide an argument against using a particular technology, don’t do it as a transparent attempt at promoting your own product at the expense of another, or creating attention grabbing headlines just to get a few more eyeballs to your site. You’ll land up looking foolish, and it’s bad karma besides.

Just recently someone posted a comment on this blog in response to what he probably thought was an “anti-Flash” post. Big mistake. First, as I indicated in my response, while his initial arguments had validity, his conclusion was way off. And it seems to be common occurrence for some bloggers to post comments on other people’s blogs in an effort to garner support for their arguments without considering the point of view of the blog they’re posting on, so the argument falls flat. I’m not opposed to a little healthy debate and free speech, but this tactic is getting tiresome: I see it used so often that, aforementioned comment notwithstanding, I sometimes wonder if some of these posts are provoked by corporations as a “web 2.0″ anti-marketing smear tactic.