The Announcement
With the recent announcement from Adobe that Flash Player for Mobile Web Browsers would not be further developed, there has been quite a bit of concern among Flash and Flex Developers about the viability of the Flash platform moving forward. Companies who have millions invested in Flex Applications are now worried that Adobe may not support Desktop Flash moving forward; leaving these companies with products they won’t be able to distribute to their customers.
The emerging, long-term concern about Flash Player availability is due to:
- browser vendors choosing not to support the Flash Plug-in, or…
- Adobe choosing not to evolve the Flash Platform, creating an anemic pool of developer resources, a lack of documentation, tooling, and a lacking eco-system.
Customer Reach
How do you reach your customers when you are limited to Desktop and Laptop machines for browser-based Flex applications? While you can create an AIR application to target Mobile Devices, companies now have to maintain a separate code-base if they need to target smaller Form Factors.
Most companies who need to support multiple Form Factors (Mobile Phones, Tablets and Desktop Browsers) will choose HTML5. Public Sector applications will have to move to HTML5 to ensure they can reach as many citizens as possible, including those on the least expensive computers (such as phones and tablets).
Now, forgive me if you stumbled upon my blog with the hopes that I would have something positive to say about Flash on multiple form factors. I remain indifferent about supporting multiple form factors, because most of the projects I work on are monolithic, enterprise applications with highly complex client-side logic. I care most about Doctors and Executives who carry around laptops or sit at their desk entering information into 1000s of fields. I care about the traffic that comes primarily from Desktop and Laptop computers My concerns are solely focused on the future of Flash on the Desktop. And if you share my concerns, stay with me, because I will propose what I believe is the biggest factor that contributes to the staying power of Flash in the Browser.
Before we begin, let’s begin by talking about why I don’t want to become an HTML5/Javascript developer. Let’s talk about why I’m fighting what others suggest is a natural evolution:
The Career Impacts of moving to HTML5 from Flex
As a Flex Developer, I have my own concerns about moving to HTML5. While Actionscript and Javascript both descended from the same EcmaScript standard, Actionscript surpassed Javascript by offering a static, compile-time language that grew more robust than it’s sister (picture, if you will, Marcia Brady vs. Jan Brady, first, as infants, and then as we remember them best).
Actionscript offered accessor types, packages / namespaces, and strong-typing. The aforementioned are important when you’re building Object-Oriented, scalable, monolithic enterprise software.
Most organizations (and I do mean most), would prefer to add less-experienced, less-OOP-centric, less-expensive labor to a large project. It’s not usually by choice, either. As a manager, I learned that it was often a necessity to add low-talent labor because it’s really difficult to find senior developers and architects for the client-side of an enterprise stack. The senior developers and architects you do find are often unlikely to show any enthusiasm for building cutting edge technologies that offer magazine layouts, smooth transitions, video, and the visual feedback that drive the user to the conversion goal your marketing people have been focused on for the quarterly sales-goal (sounds a little clinical, doesn’t it?).
HTML5, and some of the beautiful libraries like EXT and JQuery, offer companies choice and flexibility, not just choice in how their products are distributed, but also in terms of their labor-pool.
As a Software Engineer, moving to a dynamic, typeless, non-object oriented language, with a lower barrier of entry, I’d be facing competition from a greater number of less experienced developers, with less applicable enterprise experience (a greater language divide between the Java Developers and Client-side developers). I’d be working in a larger team of client-side developers, with more hands in the cookie-jar, more opinions, more coding styles, and less ownership over key decisions. I’d make less money. I’d have less influence. I’d enjoy my job less.
Understanding the Future
HTML5. The Great Equalizer of Public Perceptions
One of the current hopes is that the death of Flash will bring about a more civilized Web. A web where advertisements with animations no longer distract and taunt the user. Once the web matures and more people have browsers capable of supporting HTML5, the advertisements that intrude on the user-experience with videos and animations will move to HTML5. Some tools, such as Adobe Edge and Apple’s iAd Producer, will help designers at ad agencies to create Flash-Like ads in HTML5. The annoying YouTube videos with ads that disrupt your favorite Top Gear clips will move to HTMl5, and come with advertisements as well. I mention this not to detract from everything HTML5 will offer, but to remind Flash Developers that the great equalizer is upon us: The loathing of Flash among the general public will lessen when HTML5 offers the distractions and annoyances that people associate with Flash in general.
What is the Future of Flash as a Browser Plug-in?
It’s hard to imagine companies investing in a platform for large, transactional applications when there’s always an underlying concern about plug-in Support from the Browser vendors. Adobe is taking the right approach by trying to create public demand for the Flash Player by offering a compelling web-platform for gaming. Mozilla is looking to provide a 3D gaming platform as well, which suggests Mozilla believes the Desktop market will continue to stay a dominant player in gaming. With Adobe’s move to a multi-threaded video player, support for Dolby 7.1, and improvements to their DRM, they are likely to remain a dominant force in video-delivery, and likely to grow their share of the gaming market on the Desktop. Content distributors wo want to control their content and offer an excellent experience will continue to use Adobe Flash.
So, Adobe has helped to ensure there’s likely to be consumer demand. But the viability of the Plug-in depends on far more than just great gaming and video. Ensuring Browser vendors and Operating System vendors continue to support Flash is crucial, and many developers and companies are now anxious that Apple might not support Flash on OSX going forward, and there’s concern about the long-term accessibility of Flash on the well-reviewed Windows 8, since Flash will not be accessible on Metro (although the Flash plug-in will still be accessible on Windows 8 through Internet Explorer).
What is the Future of the Enterprise Client-Side Platform?
A few languages have emerged that emulate Java and Actionscript. These languages offer a strongly-typed approach to development, and they try to cover for various browser quirks. Google’s GWT and CoffeeScript are two such examples. GWT allows you to write client-side code in Java that gets compiled down to Javascript. There are frameworks emerging that allow Enterprise developers to create HTML5 projects with greater ease. If you’re an Enterprise Flex Developer, looking for an alternative, some alternatives exist. Since these languages compile down into HTML5, developers can build relatively complex client-side software, and deploy to multiple operating systems and form-factors.
So, given solid alternatives to Flex for building robust, client-side software, and the probability that HTML5 will eventually catch-up to Flash in terms of 3D Gaming, DRM, and High-Quality Video delivery, it’s only a matter of time before the Browser plug-in is axed, right?
Maybe. But there’s one more, long-term hope. A hope, for all plug-ins who wish to secure a fair-shot at giving companies and users choice regarding what content they choose to produce and consume.
What is the Future of the Browser Plug-in?
A quick history lesson is in order. So bare with me for a second.
Adobe made many concessions with the Actionscript language in order to gain acceptance of the platform as the foundation for the upcoming EcmaScript (read JavaScript) standard known as “Harmony”. Back in August of 2008, the Javascript Standard’s Body rejected Adobe’s proposal in favor of small, incremental changes to JavaScript. Adobe proposed a standard that was more robust than the one agreed to by the Standard’s Body. With Adobe’s proposal rejected, Actionscript and the Flash Platform became part of a propietary platform. And it wasn’t just Adobe who likely felt snubbed by the decision to make small, incremental changes to the EcmaScript Spec…
How Languages Affect Revenue-Generating Products
Google wants to compete with Microsoft’s Office Suite of products. There is a lot of money in the Enterprise. Once an organization has bought into a technology stack, or changed to a service provider, they rarely change course, and the revenue is consistent. In order to offer products that can compete with Microsoft’s best, Google needs to offer a few gargantuan, rich internet applications that look and behave just like they would on the desktop. Google needs to offer products that rival what Microsoft has fine tuned into wonderful tools, such as Outlook, Word, Excel, and PowerPoint. These products have to be so amazing, and so impressive, that users forget they’re actually using a web browser. Unfortunately, they’re not quite there, yet, and it’s not known how close Google will be able to get to producing wonderful software on the web using HTML5 and Javascript.
So what to do?
Google has embarked on a quest to offer a platform that exceeds the capabilities of both GWT and HTML5 with Dart. An internal Google document from October 2010 provides some insight about Google’s future strategy with Dart (allow me to spare you the long-read and paraphrase). Just like Flash, Dart would run as a VM in the browser (albeit, with the option of translating Dart into Javascript). Dart would have syntax familiar to Enterprise Java Developers, and Enterprise Flex Developers. As a VM, Dart would overcome many of the limitations that are part of the current EcmaScript standard.
If Google is successful with getting other Vendors to adopt Dart as a VM, it bodes well for the future of Browser plug-in support. Yet, some may argue that there’s no compelling reason for Mozilla, Apple and Google to offer Dart as a plug-in.
But a problem awaits for browser vendors who choose not to offer plug-in support and move to an agreed-upon, ‘pure standards based, completely open’ platform. If other vendors choose not to support Dart, Google would be able to [presumably] offer products that meet the basic needs of most Office Users, while always giving a gentle nudge (if you haven’t seen the ‘nudge’, try opening up google.com with Internet Explorer. Google prompts you to update to their Chromium Browser) to adopt Chromium, where users would then be able to experience the Full-Featured version of their product that Dart offers. By not offering Dart as a VM, other browser vendors would risk users abandoning their browsers in favor of “tools” that do offer ‘premium’ content.
It’s rare for users to switch browsers. Most users use the default browser that came with their system, and those users are often unfamiliar with how to switch to “another internet”. Users can be ‘nudged‘ from one browser to the another browser that suits their personal needs. That’s pretty easy. And for the rest of the users whose browser suits their personal needs just fine, companies may help make the decision for them. Given the price difference between Google Docs and Microsoft Office per employee, the savings could be considerable to the enterprise.
The referrals for advertising dollars that come from using a specific vendor’s browser creates a compelling case to offer the very best browser, with the absolute best support for content that users actually want. This is likely to be a big reason why FireFox, a browser built on contributions from the developer community, is working so hard to become a major player for 3D gaming.
The type of content that each browser is capable of delivering will influence which browsers flourish and which browsers parish. That drive to offer the best content will drive the browser vendors to pursue their own interests, splintering the HTML5 community, and creating openings for write-once, deploy-on-any-browser VMs, which standardize development.
If Google Chrome continues to seamlessly offer one VM which provides first-class video and 3D gaming, and can provide another VM that offers desktop-quality office software, other browser and OS vendors will either follow suit and offer a plug-in capable solution, or they will risk losing the treasures that come with not being the user’s default browser.
Flash development may be dead on the Mobile Browser battlefield, but the Desktop Browser war is still undecided, and there are billions of dollars at stake.
