I watched part of the Adobe MAX presentation yesterday in which Adobe said that they are acquiring Nitobi, the company behind PhoneGap. PhoneGap is essentially a competitor to Titanium. Not a complete competitor, but read on. This development is likely the harbinger of changing the game entirely. Here’s why.
Further reading: Ars Technica | Adobe Acquires Nitobi
Adobe Flash lost as a web application development standard, and Adobe knows it. They are spending tons of cash right now in a game of catch-up and expect to be the leader in web development again (they were just a short 5 years ago). After their initial, bitter battle with Apple and running Flash apps on iOS, they turned things around and you can now use Adobe tools to deploy apps on iOS. They already released a beta of a complete IDE for building HTML5/JavaScript5/CSS3 applications. It’s called Adobe Edge.
With the power and capabilities of Edge growing with every release (because their customers are demanding it) it is most likely that PhoneGap will be tightly integrated as the de facto framework for building applications in the tool. Much like when Appcelerator purchased the Aptana IDE and converted it into Titanium Studio which allows us to code, build and deploy applications from one tool, Adobe Edge will be a complete IDE for HTML/JS/CSS application development.
Further reading: CNET | Adobe Sharpens Edge
Now, if you are building desktop apps, PhoneGap is not an option because it is exclusively mobile. It’s the main reason that Titanium Desktop became so successful. Unfortunately, Titanium Desktop seems to be an abandoned, or at least orphaned, child in the Appcelerator roadmap. The few Appcelerator employees that I talked to at the conference two weeks ago did not have any answers as to how their desktop product fit into their future plans. They are currently focused 100% on their mobile application development tools. This is most likely because Appcelerator is resource strapped and simply giving all of its focus to what customers are demanding RIGHT NOW.
Adobe has no such limitations. Their AIR Runtime already allows developers to build HTML/JavaScript applications that can run on any desktop OS. Unfortunately, it could not run on every mobile OS, so it will most likely be abandoned and replaced with the eventual PhoneGap successor for mobile apps. I don’t see Adobe abandoning the desktop because they already have a dedicated presence there, and with the (finally) released information about the Microsoft Windows WinRT API in which you can author complete applications with JavaScript, it plays right into the hands of Adobe.
It’s highly probable that Adobe Edge has AIR integration for desktop applications before the official 1.0 release.
So what this gives us is more than one option for every environment. The source code for the GUI would continue to be in one language, but then could be built, or interpreted, to any platform. It will be interesting to see what Adobe does with the PhoneGap platform in the next year.
JavaScript
I find it interesting when I talk to developers who are focused on Java and .NET platforms about how JavaScript will soon replace a huge chunk of what they currently have to do when making applications with a user interface. I would think it would be a source of jubilation – no more worrying about cross-platform UI issues in compiled code – but I find there’s still a lot of resistance and denial even though the facts are all right in front of us.
This next generation of application development is going to be fun, not only because we can reduce the amount of code we need to write, but also because the entire industry is moving away from the immobile desktop and towards the mobile device platform.
On October 5th, Brian Cavalier will be presenting his work on Asynchronous Module Definition API and CommonJS modules. It will be a very interesting presentation and should generate some great conversation.
Event Link: AMD and CommonJS modules
On October 11th, we’ll be covering Appcelerator’s Titanium framework which is an open-source framework that allows you write an application in JavaScript and then build native apps for iOS and Android (and Blackberry soon). You can also deploy the application to the desktop – whether it be Windows, OSX or Linux. One source code library to deploy to 6 platforms!
Event Link: Appcelerator Titanium Framework
On October 25th, we’ll be discussing how to build a JavaScript application and deploy it in the Adobe AIR runtime. With Adobe AIR, JavaScript developers can use their existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web.
Event Link: JavaScript and the Adobe AIR runtime
Now that I have some solid WPF coding under my belt, I felt like speaking out a little about how it compares, in my mind, to developing in Flex and Actionscript.
First, and foremost, I have to say [BINDABLE] FTW!! That one thing alone sums up the rest of my ramblings below, and you can probably skip the rest of this article if you wish after you read the next opinion.
The cultures of Adobe and Microsoft are best reflected in how you accomplish any development feat – Adobe did its best to make sure the “little stuff” is handled behind the scenes so that development can be done as quickly as possible, while Microsoft assumes absolutely nothing and requires you to write dozens of lines of code to achieve even the simplest of development goals.
If you want absolute, iron-gripped control over every single feature of your application, and want to hand-craft almost every piece of customization or abstraction that is needed, then the Microsoft stack is definitely for you – the uber geek, the one who takes tremendous pride in his mastery of every aspect of his application.
Unfortunately, WPF still has a little ways to go to catch up with the power and features of Flex. Of course, WPF is for desktop apps and runs as a native assembly, and doesn’t need a third party installation that is, admittedly, more bloated and use a bit more memory.
If you want to focus on functionality, and get products/updates released as quickly as possible, and could care less what magic goes on when you bind a Collection to a DataGrid, then the Adobe stack is for you – the quasi geek, the one who needs to do the design, the architecting, the development and the support, and doesn’t have time to spend hours hand-crafting simple tasks that the software should obviously be doing for you.
However, I think the folks at Adobe heaved a huge sigh of relief when Microsoft announced that Silverlight’s focus will now be for mobile development only. Given time, Silverlight would have been a superior product to Flex (on Windows).
For me, I much prefer the Adobe ideology. Perhaps it’s the Star Trek geek in me. My philosophy when it comes to development stems from years of watching Star Trek: The Next Generation. Does that make me an uber geek anyways? Perhaps.
When critical software and systems needed to be modified on the Enterprise, did you see Jordi sit down at a computer terminal, bring up a development environment and figure out how to expose the correct property change event, make sure it implemented the correct interface, open another file to map the property to the system, and then open another file to make sure it looked right (all in a proprietary language that NO ONE ELSE uses)?
No. By the 25th century, they finally get it. Superior engineers – whether they work on software, or warp engines – want the basic tasks done for them if possible. It saves time, and makes work a lot more fun. If I can add a new column to a dataset and have it displayed in my interface in 1 minute, then I’m all for it.
Sure, there are still people in the world who would rather take the 30 minutes to do it “right” by writing every single line of code needed to perform the task.
Sorry, not me. I got shit to do.
It’s been a bit hectic at work in the last 2 years. Well, perhaps hectic isn’t the perfect word, but it’s close. Since I started working here, we’ve gone through two complete development technology stack switches.
Back in the halcyon days of 2007, I had the unenviable task of shoring up some very hastily written applications (by database developers and a couple of hacks who were here before me) using ColdFusion and HTML/Javascript. I beefed up the corporate offerings by implementing industry-accepted practices and patterns, used well-established libraries and got upgrades to the ColdFusion servers.
Then, in late 2008, the decision was made to scrap any future development of HTML/Javascript user interfaces and use Flex instead. That was exciting because of two reasons:
Fast forward to 2010 and now the entire company is rolling over to the .NET stack. Now I get to brush up on my rusty C# skills which I haven’t used in almost 4 years; I get to learn the ASP.NET MVC architecture; I get to have fun learning how to connect our .NET applications to our Oracle databases; lastly, I get to estimate how long it would take to convert our entire ColdFusion code base to .NET.
I’ll still get to work in ColdFusion from time to time, but .NET is the future…. for now. Perhaps 2012 will be the year we convert everything to Java!
I’m all for rolling with the punches and evolving my skill set to match what is needed for the organization to be successful, but I’m also no longer 24 years old with oodles of free time at my disposal (or the accompanying mental agility). Doing these massive switches takes a little more time at my venerable age.