Posts Tagged‘javascript’

Google’s Peculiar Flash Obsession.

Google is one of the biggest proponents of an Internet that’s unencumbered by proprietary standards, patents and non-neutral traffic routes. That’s been a great boon to us Internet users as their advocacy on our behalf means that as long as they stay in business we’re likely to continue to have an Internet that stays true to those ideals. Of course like any company they’re not entirely perfect, at times attempting to forward their own agenda under the guise of openness, but overall their contribution to keeping the Internet free and open has been positive. It seems rather odd then that Google has an obsession with Adobe’s Flash product, to the point where I wonder if there’s something going on that I don’t know about.

Back in March last year Google announced that they were integrating the Flash plugin directly into their Chrome browser. This was at the height of the web standards war that was raging between Apple and Adobe so it was easy to construe Google’s support of Flash as them taking Adobe’s side in the matter. That notion was further reinforced by the fact that Google’s Android platform fully supported Flash as well. This level of support for a proprietary plug-in for a company that prides itself on being a big supporter of open standards seems rather hypocritical, but there are some reasons as to why they’re doing it.

One of Google’s main objectives in developing the Chrome browser (and subsequently releasing the vast majority of its source code) was to improve the Internet experience for the end user. A lot of effort was focused on developing a much faster JavaScript engine, dubbed V8, that would significantly speed up many of the JavaScript heavy websites that now dominate the web. The integration of Flash into Chrome then was the next step in making the Internet as a whole more usable as the liberal use of Flash on many websites can bring even the most powerful PC systems to their knees. The same sites wreck absolute havoc on mobile handsets so it was definitely in Google’s interest to get more closely acquainted with Flash, if only to make it more usable.

Recently though it appears that Google’s support of Flash was actually leading up to a much more ambitious goal, transitioning the web from Flash to a HTML5 future:

Google is enabling developers who use the Adobe Flash Professional developer tool to convert their animations to HTML5 via an extension based on Google’s Swiffy conversion technology.

“One of our main aims for Swiffy is to let you continue to use Flash as a development environment, even when you’re developing animations for environments that don’t support Flash,” said Esteban de la Canal, Google software engineer, in a blog post. “To speed up the development process, we’ve built the Swiffy Extension for Flash Professional. The extension enables you to convert your animation to HTML5 with one click (or keyboard shortcut).”

Now it’s interesting that Google would go ahead and do something like this when Adobe had already made their play in this field with their Wallaby product. The big difference here is that Wallaby was specifically targeted at Flash Ads only and didn’t support many of the features that made Flash so versatile, like ActionScript. Swiffy on the other hand does support ActionScript and several other features that weren’t present in Wallaby. It would seem then that Google thinks they can do better than Adobe at their own game which they very well could especially when Adobe just recently announced that they weren’t working on mobile Flash any more.

Of course the transition from native Flash to Flash rendered through HTML5 doesn’t necessarily mean we’re looking at a future web that performs better. The main problem with Flash wasn’t so much the platform it was the developers on that platform. The Flash ads were the biggest culprit, often laden with gobs of unnecessary and bloated code that were the source of the performance problems people encountered. Transitioning such ads to HTML5 won’t make that code go away (there is a chance to optimize, but automated tools can only go so far) and the result will more than likely be just as bad as the original Flash it came from. It’s a step in the right direction yes, but it’s not going to be an all roses future like some would have you believe.

It’s quite interesting to see the kind of games that Google plays in order to make the web better for everyone. At times they may seem to be on the wrong side but it’s becoming clear that they’re playing the long game for a better web for everyone. It will be interesting to see how common Swiffy converted Flash files become and whether they’re still the performance hogs that their predecessors are but knowing Google they won’t let it lie until they’ve optimized it to the nth degree. Adobe’s reaction to Swiffy will be telling as well considering they’re now competing directly with Google on their home turf. The end result will be a better, more open Internet for us all something I think we can all agree is a good thing.

So Long Flash and Thanks for all the Vids.

You’d be forgiven for thinking that I was some kind of shill for Adobe what with all the pro-Flash articles I’ve posted in the past. Sure I’ve taken their side consistently but that’s not because of some kind of fanboy lust for Adobe or some deep rooted hatred for Apple. More it was because the alternatives, HTML5 with CSS3 and JavaScript, are still quite immature in terms of tooling, end user experience and cross platform consistency. Flash on the other hand is quite mature in all respects and, whilst I do believe that the HTML5 path is the eventual future for the web, it will remain as a dominant part of the web for a while to come even if it’s just for online video.

Adobe had also been quite stalwart in their support for Flash too, refusing to back down on their stance that they were “the way” to do rich content on the Internet. Word came recently however that they were stopping development on the mobile version of Flash:

Graphics software giant Adobe announced plans for layoffs yesterday ahead of a major restructuring. The company intends to cut approximately 750 members of its workforce and said that it would refocus its digital media business. It wasn’t immediately obvious how this streamlining effort would impact Adobe’s product line, but a report that was published late last night indicates that the company will gut its mobile Flash player strategy.

Adobe is reportedly going to stop developing new mobile ports of its Flash player browser plugin. Instead, the company’s mobile Flash development efforts will focus on AIR and tools for deploying Flash content as native applications. The move marks a significant change in direction for Adobe, which previously sought to deliver uniform support for Flash across desktop and mobile browsers.

Now the mobile version of Flash had always been something of a bastard child, originally featuring a much more cut down feature set than its fully fledged cousin. More recent versions brought them closer together but the experience was never quite as good especially with the lack of PC level grunt on mobile devices. Adobe’s mobile strategy now is focused on making Adobe AIR applications run natively on all major smart phone platforms, giving Flash developers a future when it comes to building mobile applications. It’s an interesting gamble, one that signals a fundamental shift in the way Adobe views the web.

Arguably the writing has been on the wall for this decision for quite some time. Back at the start of this year Adobe released Wallaby, a framework that allows advertisement developers the capability to convert Flash ads into HTML5. Indeed even back then I said that Wallaby was the first signal that Adobe thought HTML5 was the way of the future and were going to start transitioning towards it as their platform of the future. I made the point then that whilst Flash might eventually disappear Adobe wouldn’t as they have a history for developing some of the best tools for non-technical users to create content for the web. Indeed there are already prototypes of such tools already available so it’s clear that Adobe is looking towards a HTML5 future.

The one place that Flash still dominates, without any clear competitors, is in online video. Their share of the market is somewhere around 75% (that’s from back in February so I’d hazard a guess that its lower now) with the decline being driven from mobile devices that lack support for Flash video. HTML5′s alternative is unfortunately still up in the air as the standards body struggles to find an implementation that can be open, unencumbered by patents and yet still be able to support things like Digital Rights Management. It’s this lack of standardization that will see Flash around for a good while yet as until there’s an agreed upon standard that meets all those criteria Flash will remain as the default choice for online video.

So it looks like the war that I initially believed that Adobe would win has instead seen Adobe pursuing a HTML5 future. Its probably for the best as they will then be providing some of the best tools in the market whilst still supporting open standards, something that’s to the benefit of all users of the Internet. Hopefully that will also mean better performing web sites as well as Flash had a nasty reputation for bringing even some of the most powerful PCs to their knees with poorly coded Flash ads. The next few years will be crucial to Adobe’s long term prospects but I’m sure they have the ability to make it through to the other end.

Silverlight May Die, But the Developers Won’t.

You’d think that since I invested so heavily in Silverlight when I was developing Lobaco that I would’ve been more outraged at the prospect of Microsoft killing off Silverlight as a product. Long time readers will know that I’m anything but worried about Silverlight going away, especially considering that the release of the WinRT framework takes all those skills I learnt during that time and transitions them into the next generation of Windows platforms. In fact I’d say investing in Silverlight was one of the best decisions at the time as not only did I learn XAML (which powers WPF and WinRT applications) but I also did extensive web programming, something I had barely touched before.

Rumours started circulating recently saying that Microsoft had no plans to develop another version of the Silverlight plugin past the soon to be released version 5. This hasn’t been confirmed or denied by Microsoft yet but there are several articles citing sources familiar with the matter saying that the rumour is true and Silverlight will recieve no attention past this final iteration. This has of course spurred further outrage at Microsoft for killing off technologies that developers have heavily invested in and whilst in the past I’ve been sympathetic to them this time around I don’t believe they have a leg to stand on.

Microsoft initially released Silverlight back in 2007 and has release updates to the platform every year or so since then. Taking that into consideration you’d figure that the latest release of Silverlight has 1 or 2 years in it before other technologies (most likely HTM5 and JavaScript) overtake it in terms of functionality. In that time Windows 8 will be released along with WinRT, the framework that will be instantly familiar to any Silverlight developer. Sure the code might not be directly translatable to the new platform but considering the design work is done in XAML and C# is a supported language I’d struggle to find any Silverlight developer who wouldn’t be able to blunder their way through with a couple Google searches and a StackOverflow account.

All of Microsoft’s platforms are so heavily intertwined with each other that it’s really hard to be just a Silverlight/WPF/ASP.NET/MFC developer without a lot of crossover into other technologies. Hell apart from the rudimentary stuff I learnt whilst in university I was able to self learn all of those technologies in the space of a week or two without many hassles. Compare that with my month long struggle to learn basic Objective-C (which took me a good couple months afterwards to get proficient in) and you can see why I think that any developer whining about Silverlight going away is being incredibly short sighted or just straight up lazy.

In the greater world of IT you’re doomed to fade into irrelevance if you don’t keep pace with the latest technologies and developers are no exception to this. Whilst I can understand the frustration in losing the platform you may have patronized for the past 4 years I can’t sympathize with an unwillingness to adapt to a changing market. The Windows platform is by far one of the most developer friendly and the skills you learn in any Microsoft technology will flow onto other Microsoft products, especially if you’re proficient in any C based language. So whilst Microsoft might not see a future with Silverlight that doesn’t mean the developers are left high and dry, in fact they’re probably in the best position to innovate out of this situation. 

Flow, Optimization and Making Progress.

I believe everyone is familiar with the concept of being “in the zone”, I.E. that state you attain when you’re so intensely focused on something that time becomes irrelevant and all you’re focused on is achieving some certain goal. I personally find myself in this state quite often usually when I’m writing here, gaming or programming. Whilst I knew it was a common phenomenon I only learnt recently that its also recognised as a part of psychology, where they’ve termed it Flow. The concept itself is interesting an most recently I’ve started to grapple with one of the more subtle aspects, defined as point number 8 of conditions of Flow or “The activity is intrinsically rewarding, so there is an effortlessness of action”.

Now this weekend just gone past saw me back, as I almost always am, coding away on my PC. Now since I’m somewhat of a challenge junkie I’ll always seek out the novel parts of an application first rather than the rudimentary and the first day saw me implementing some new features. This always goes well and I’ll be firmly in Flow for hours at a time, effortlessly jumping through reams of documentation and masses of Google searches as I start to nail down my problem. Once the new feature is done of course then I’ll have to choose another to start work on, thereby maintaining my Flow and project progress.

However I’ve found that certain programming challenges are like kryptonite to achieving Flow. I discovered this on the second day of my weekend when I sat down to start work again, only to notice one of the tasks in my TODO list was to rework one of the earlier pages I had built to use less JavaScript and more ASP.NET Razor. The reasons behind this are simple: I’m really atrocious at JavaScript. The page in question looked good and did the job it was meant to but much of the content of the page was generated by some JavaScript code I had found on the Internet and hacked into working for me. This meant maintaining it was going to be an issue, so I set out to optimize it.

Of course the optimization process was fraught with the perils of trying to replicate into Razor what I had hacked into JavaScript with only a half understanding of what I was doing at the time. That meant untangling the mess of code that someone else had wrote and then translating that into another language that was more maintainable for someone like me. From a Flow perspective this kind of work isn’t very rewarding since I’m not going to achieve anything new and the benefits will only be realised by future me, that jerk who’s always off in some indeterminate time in the future. However the perfectionist in me knows that time saved at this point could mean multiples more saved later on, but therein lies the conundrum.

There’s a great quote by Donald Knuth (of The Art of Computer Programming fame) that says “Premature optimization is the root of all evil” which is basically a warning to avoid over optimizing your code when its still in the early stages. I’m a firm believer in the idea that you shouldn’t act like you have problems of scale until you have them but there are some fundamental differences between regular and scalable code that could prove to be incompatible with your codebase should you not make the decision early on in the piece. Of course optimization comes at the cost of progress on other pieces of work thus a balancing act between the two is required if your code is ever to see the light of day.

I guess I find it strange that optimizing my own code was so detrimental to achieving that state of coding nirvana. It’s quite possible that it was just the problem that I was working on as a previous optimization I had done, developing a cache system for a web service I was querying, seemed to have no ill effects. However that particular challenge was quite novel as I hadn’t created anything like it previously and the feedback was quite clear when I had finally achieved my goal. Unfortunately I have the feeling that most of the optimization problems will be more like the former example than this one, but so long as I write half decent code in the first place I hopefully won’t have to deal with them as much.

Windows 8: The Death of the Silverlight Ecosystem?

It’s only been just over a week since Microsoft demoed their latest iteration of the Windows platform but in that short amount of time it’s already managed to stir up quite a bit of discussion from friends and foes alike. The foes were quick to call out the new OS’s tablet envy, conveniently forgetting Microsoft’s rhetoric that the next version of Windows after 7 was going to have a much more web centric focus, with the possibility of it being entirely cloud based. More interesting however is the discussion arising from long term developers on the Microsoft platform, and it’s not the kind of adulation and praise you’d normally expect.

During the D9 conference Microsoft said that the new tile mode in Windows 8 was based around HTML5 and Javascript applications. Whilst they did mention that all current apps built on the .NET platform should run as intended when running in the familiar desktop mode they made no mention of whether or not the .NET and Silverlight platforms could be used to create applications in the new style of interface. With Microsoft traditionally being quite favorable to developers the notion of having to re-skill to HTML5 and Javascript (not to mention reworking existing codebases) came as quite a shock to a lot of developers and their reaction was akin to an open revolt on the forums.

Rampant speculation soon followed and wasn’t helped by the fact that Microsoft has asked everyone to remain calm until their BUILD developer conference in September. It’s not the first time this sort of thing has happened either, a similar level of hubbub was roused when Microsoft was coy about Silverlight’s future when talking about Internet Explorer 9 and it’s dedication to web standards. They soon came out saying that they still saw a future in Silverlight, especially for the Windows Phone 7 platform, but many of them were left unconvinced. It’s then quite likely that this second round of doubt that Microsoft has cast over their third party developer’s futures was the straw that broke the camel’s back and all the blame is being leveled squarely at Microsoft.

For what it’s worth I feel their concerns are valid if the reaction to them is somewhat overblown. Microsoft has a long history of eating its own dog food and many of their client facing applications are built upon the technologies that so many are worried are going to disappear in the near future. The best example of this is their Windows Azure management console which is built entirely on Silverlight. Couple that with the fact that Microsoft has many partners with a very heavy investment in the platform and I find it hard to jump on the “Silverlight is dead” bandwagon, but that doesn’t necessarily mean Microsoft is committed to bringing Silverlight into the Windows 8 tablet world.

Sure it would be great to be able to create Silverlight applications on the new Windows 8 tile system and Microsoft would be leveraging off a lot of preexisting talent to help drive adoption of the platform. However it would also hinder Microsoft’s adoption of web standards, as many developers would favor using proprietary Microsoft technologies instead of attempting to reskill. They’d then be the slave of two masters: on the one hand the Silverlight crowd demanding ever more features and tools that are constrained to that platform and on the other the web standards crowd that has been Microsoft’s bug bear ever since alternative browsers started to gain real market traction. It’s not like Microsoft doesn’t have the resources to deal with this though, but I can understand their motivations should they want to eschew Silverlight in favour of a more standard environment.

So is this the end of the line for the Silverlight ecosystem and the developers who built their skills around it? Hard to say, with Microsoft being mum on it for the next few months we’ll just have to play it by ear until we get more information from them. In all honesty even if they do end up dropping Silverlight for HTML5 and Javascript I’d expect that the next release of Visual Studio would bring enough tools and resources with it to make the transition much easier than everyone is making it out to be. Hell if Adobe can build a Flash to HTML5 converter then it’s quite possible for Microsoft to do the same for Silverlight, even if that’s just a band-aid solution to satisfy developers who refuse to reskill.

 

Procrastination Takes Many Forms.

I really can be my own worst enemy sometimes. It’s been almost a month since I got back from the USA and despite the best of intentions I haven’t really done that much work on Lobaco apart from a little work on the API and web UI. Whilst I was pretty sure I wasn’t going to hit the code hard immediately after touching back down in Australia I still thought that after maybe a week or two of lazing about the coding bug which had firmly bitten me before I left would take a hold once again, pushing me to build on the momentum I had set up. Sadly it wasn’t to be and instead I just resided myself to feeling guilty about what I should’ve been doing and pulling the meter tall weeds that had grown in our front yard.

Partly to blame is that sense of perspective I get whenever I take time away from a project to work on something else or to just have a break. Usually the first thing that pops into my head is “why the hell should I bother” and I’ll spend a good chunk of time focusing on the negative aspects of whatever I’m doing. After a while though I’ll just try to do a feel small things, a few quick wins to get me back into the mindset of getting things done. After that it’s usually pretty easy going (this usually takes about 2 weeks) until I hit a wall again or I feel like getting my weekends back for a while so I can relax and get my head back together. The last few iterations of this cycle are what lead to the 3 major revisions of what is now Lobaco.

This time however was different. After being back for 2 weeks and being firmly thrust back into the world that had barely changed since I had left (even though I expected it to be wildly different,  for some reason) I still really couldn’t get into coding without feeling like I should be doing something else. My usual routine of getting a couple quick wins with the API and web UI didn’t translate into jumping back onto my MacBook and smashing out some iPhone code. Instead I started wondering whether or not a native client was the way to go and the possibility of doing a web based client for the phone itself. I had been down this road before and ultimately found that whilst iPhone programming was a world away from I’d done before the progress I had made with only a couple weeks of effort was far more encouraging than the same amount of time spent trying to wrangle HTML5 and Javascript into something workable.

Then along came Sencha.

I was going through my 700+ post backlog of Techcrunch articles when I came across this one about Sencha, a web startup that just released their Touch framework which provides the basis for building native looking applications in HTML5 and Javascript. Thinking this might be my salvation to writing native clients for all handsets I quickly downloaded the framework and started hacking around to get something workable. I was able to get the example running in one weekend and made a few modifications but I didn’t get into the real meat of it until last Friday night. After managing to replicate the UI I had built in objective-c within the Sencha framework I uploaded it to my web server to see what it would look like on the iPhone and instantly I realised what was wrong.

This client was just an elaborate way of procrastinating.

Now whilst the client looked decent and didn’t take too much to set up it didn’t look anywhere near as good as my native app nor could it hold a candle to its performance. Sure my hack job probably ensured that the performance wasn’t as good as it could be but in comparison to the native client hack job I did it was pretty stunning. After coming to that realisation I booted up my MacBook to start getting acquainted with Xcode again and spent last weekend coding up some performance improvements¹ for it which I had put off before I left for the USA. I’m sure this won’t stop me from looking at going down that path in the future but I can at least rest easier now that I’m feeling the urge to program once again.

It’s been a weird learning experience for me since I’m usually pretty good at knowing when I’m procrastinating. Usually I have a good reason for it (like having 1 bit of work to do and not doing it since it’s not due for months) but this is the first time I caught myself doing something I thought was useful when really I was just making excuses for doing the work I knew needed to be done. With a good week of holidays coming up over the Christmas/New Year period this realisation couldn’t have come at a better time and I’m looking forward to making the most of my time off with the hope that the momentum will carry me on into the new year.

¹I’m going to do a big post about this hopefully tomorrow. I hit some really, really esoteric problems getting everything to work but I have and the results are, to put it bluntly, bloody amazing.

When Features Trump Security: Twitter’s Ongoing Security Concerns.

There were so many times when I was coding up early versions of Lobaco that I didn’t give any thought to security. Mostly it was because the features I was developing weren’t really capable of divulging anything that wasn’t already public so I happily kept on coding leaving the tightening up of the security for another day. Afterwards I started using some of the built in authentication services available with the Windows Communication Framework but I realised that whilst it was easy to use with the Silverlight client it wasn’t really designed for anything that wasn’t Windows based. After spending a good month off from programming what would be the last version of Geon I decided that I would have to build my own services from the ground up and with that my own security model.

You’d think with security being such a big aspect of any service that contains personal information about users that there would be dozens of articles about. Well there are but none of them were particularly helpful and I spent a good couple days researching into various authentication schemes. Finally I stumbled upon this post by Tim Greenfield who laid out the basics of what has now become the authentication system for Lobaco. Additionally he made the obvious (but oh so often missed) point that when you’re sending any kind of user name and password over the Internet you should make sure it’s done securely using encryption. Whilst that was a pain in the ass to implement it did mean that I could feel confident about my system’s security and could focus on developing more features.

However when it comes down to the crunch new features will often beat security in terms of priority. There were so many times I wanted to just go and build a couple new features without adding any security into them. The end result was that whilst I got them done they had to be fully reworked later to ensure that they were secure. Since I wasn’t really working under any deadline this wasn’t too much of a problem, but when new features trump security all the way to release you run the risk of releasing code into the wild that could prove devastating to your users.

No example of this has been more prolific than the recent security issues that have plagued the popular micro-blogging service Twitter. Both of them come hot on the heels of the release of the new Twitter website released recently that enables quite a bit more functionality and with it the potential to open up holes for exploitation. The first was intriguing as it basically allowed someone to force the user’s browser to execute arbitrary Java script. Due to the character length limit of Twitter the impact this could have was minimised, but it didn’t take long before malicious attackers got a hold of it and used it for various nefarious purposes. This was a classic example of something that could have easily been avoided if they sanitised user input rather than checking for malicious behaviour and coding against it.

The second one was a bit more ugly as it had the potential to do some quite nasty things to a user’s account. It used the session details that Twitter stores in your browser to send messages via your account. Like the other Twitter exploit it relied on the user’s typical behaviour of following links posted by the people they follow. This exploit can not be squarely blamed at Twitter either as the use of link shortening services that hide the actual link behind a short URL make it that much harder for normal users to distinguish the malicious from the mundane. Still Twitter should have expected such session jacking (I know I have) and built in counter measures to stop them from doing it.

Any large public system will attract those looking to exploit it for nefarious means, that’s part and parcel of doing business on the web. The key then is to build your systems with the expectation that they will be exploited rather than waiting for an incident to arise. As a developer I can empathise that developing code that’s resistance to every kind of attack is next to impossible but there are so many things that can be done to ensure that the casual hackers steer clear. Twitter is undergoing a significant amount of change with a vision to scale themselves up for the big time, right up there with Google and Facebook. Inevitably this will mean they’ll continue to have security concerns as they work to scale themselves out and hopefully these last two exploits have shown them that security is something they should consider more closely than they have in the past.

How Long Can Apple Hold Out on Flash?

Before I get this tirade underway let me preface it with this, I’m not a fanboy of either of these companies. Apple, in recent times, has grown from the hipster chic underdog to Microsoft 2.0 in its attempts to create a massive walled garden and Adobe has been doing similar things for the past decade. I respect both of their prowess in their respective fields and have used products from both companies for quite some time. It was only a couple weeks ago when I posted my thoughts on the current PR war waging between them on the whole Flash thing which quickly turned into a full blown geek fight over web standards, but even after writing that I still feel like there’s a lot more to be said on this topic. It seems even more relevant since they just released yet another device that will defy the current norms of the Internet.

Apple’s, well Jobs’, position on Flash is no secret and in his statements there are some points that deserved to be talked about. However whilst the apparent motivation appears to be solely focused on user experience it’s something far more obvious than that. I am of course talking about Apple’s bottom line. You see for all the belly aching going on it all boils down to Jobs’ walled garden in which he reigns supreme and reaps all the benefits. From a capitalist point of view I wholly support this motivation as realistically most of Apple’s direct competitors are doing the exact same thing. It makes even more sense when you realise that at its heart Apple is actually a hardware company, with every other endeavour they’ve undertaken done to drive sales of their iProducts. Whilst the App Store might be an extremely lucrative side business its main focus was to drive sales of the iPhone and subsequently provide a massive install base of applications for the iPad.

Flash in this case would undermine their current efforts to drive additional hardware and software revenue through other channels. Whilst I’m sure there wouldn’t be a mass boycott of the App Store there it would definitely see a drop in sales for some channels, particularly games. Additionally once one of these platforms is allowed on you’ll have all the others screaming for their own native implementation on Apple devices, further undermining their revenue streams and increasing their support overhead. It then comes as no surprise as to why Jobs’ has been so outspoken on this since realistically the support he’d gain by implementing Flash would end up costing him quite a lot in real terms. Whilst they’ve managed to generate some decent good will in the past (non DRMed songs anyone?) they’ve only done so when there was a positive impact to their bottom line (that upgrade fee was a bit rough ey?), and Flash really doesn’t have a monetization stream that Apple can realise.

Still their alternative of HTML5 + JavaScript + CSS3, whilst applauded for being an open alternative to the wholly propeitary flash, may in fact end up being their undoing. Apple’s latest volley at Flash was to release a set of HTML5 technology demonstrations hoping to prove to everyone that HTML5 was more than capable of wholly replacing Flash. Strangely however they required you to download their Safari browser to be able to see them which should strike you as suspicious. Whilst any company should take every opportunity to peddle their products when Apple did it here they were not so subtly admitting quite a lot of things and the tech community has been quick to pick up on this.

You see the HTML5 specification is still in draft and will be for quite some time. This means that whilst a lot of browsers support a good chunk of the specification it’s still subject to change and review, meaning things could be added or removed in future versions. Additionally there are many aspects of it that would class as still being in submission status, I.E. they’re not even part of the draft specification yet. Most of these are vendor specific augmentations, some of which have come from Apple. The tech demos they have put out rely on vendor extensions specific to the WebKit framework they have developed, meaning that only Safari and Chrome are capable of rendering them accurately. Many of the demos do work under FireFox (you can trick Apple’s site into thinking you’re a Safari user using this) however the current proprietary extensions based demos will fail in some way.

For Apple HTML5 offers them a comparable level of functionality that Flash provides with the added benefit of being partially under their control. Apple is well known for its iron fist like rule over its App Store and allowing Flash onto their devices would mean relinquishing much of it. With HTML5 they can at least mould parts of it in ways that support their strategic plans, letting them chip away at the functionality that Flash provides with submissions to the new web standard. Additionally it then lets them leverage their current captive audience of developers to put pressure on others to develop HTML5 based sites for their iDevice line, further widening the walls of their garden and swelling their bottom line.

However there’s a storm brewing on the horizon. For every piece of functionality that gets adopted into the HTML5 standard another step is taken towards being able to replicate Flash entirely. Right I’ve alraedy said that but think about that closely for a second there. If the potential is there to mimmic Flash is there also potential to emulate it? Funny I should ask that since it appears that some interpid coders have come up with solutions to run Flash objects in HTML5 and JavaScript, the exact technologies that Jobs would see proliferate all over the web. It doesn’t stop there either with Adobe partnering up with mobile advertising network Greystripe to develop technology to transcribe Flash ads to HTML5, effectively circumventing the restriction. Adobe is poised to take on Apple’s restrictions with devastating gusto and if I were Apple I’d be seriously reconsidering my position.

You see many of the aspects that Jobs mentioned in his thoughts on Flash will unfortunately apply to not only Flash apps transcribed into HTML5 but also native HTML5 applications. Since it’s currently in its infancy HTML5 is not much of a threat to Jobs’ current direction and that, in addition to my previous points, is why his support is behind it. Whilst it might look like Adobe is bending over backwards to satisfy Apple’s restrictions its more likely that whilst Apple will win the battle of getting people to transition to HTML5 they’ll lose the war of keeping their garden walled. With the increased capability of HTML5 comes the potential for all the problems that Flash has to infect the iDevice platform, thereby rendering his current stance completely moot. Just to prove my point go and run some of those HTML5 demos and watch the CPU usage on your computer (the text one is great for this), that alone proves that HTML5 is capable of destroying a mobile device in many of the same ways as Flash.

In the end it all comes down the bottom line of both Adobe and Apple and how willing they are to go to further it. Apple will more than likely continue its stance of no Flash for as long as they have devices capable of browsing the web. Adobe on the other hand seems poised to innovate their way out of this, with the additional help of many skilled programmers who see Flash on the iDevices as a simple programming challenge. I’ll be very suprised if Apple wins out in this one as they’re already laying the ground work for this to blow up in their faces, with Adobe priming the explosives.

Maybe we’ll have Jobs writing a Thoughts on HTML5 post in the future when he bans it from the iPhone.