Cloud IDEs Are Coming!

We shop in the cloud, bank in the cloud, communicate in the cloud, but for the most part, we still develop on the desktop. Aren’t cloud capabilities useful to us as developers as well?

• Universal accessibility
• Instantaneous collaboration
• Elimination/minimization of installation and setup
• Familiar web actions and usability

Interestingly, the same developers who create cutting-edge innovative applications can be very conservative about their tools. If it works, why change it? For example, key bindings become almost subconscious. The fingers know them, but the brain can’t say what they are.

Desktop IDEs have become increasingly powerful, providing a wealth of features to the expert programmer.  The flip side of this much power is complexity. While the power/complexity trade-off is acceptable for some types of developers, it is not for many others.

Until the recent past, the cost/benefit trade-off has deterred the advent of more nimble, usable IDEs. Cheap or free enterprise-driven IDEs have been “good enough”. Developers reluctantly use a bloated IDE. Others just give up on IDEs and resort to simple editors and the command line.

The emergence of HTML5, along with a wealth of open source, is changing the dynamics. HTML5 now enables the creation of applications (including IDEs) that have been traditionally developed on a desktop operating system. Eco-systems like jQuery and node.js have a rich set of easily pluggable open source components that can be used to construct powerful applications, in a fraction of the time that it would take on a desktop operating system. Integrated web services create new opportunities for IDE capabilities and monetization.

Cloud9 is the best example of a company riding the Cloud IDE wave. Cloud9 received $5.5 million in venture funding in June. Its run control, debugging, git integration, and console make it the best node.js development environment available.  It is well on its way to becoming a multi-purpose IDE. The bundled ACE editor, a Bespin descendent, supports 26 different languages.

Several other cloud IDEs have recently emerged:

• akshell – web app creation
• erbix JS App Editor – ringo.js, an alternative server-side JavaScript framework to node.js
• shiftEdit – JavaScript/HTML/css with php including a WYSIWYG/Design mode
• Orion – Eclipse-driven Web IDE that brings the Eclipse plug-in philosophy to the web
• Neutron IDE - open source personal IDE
• jsfiddle – JavaScript snippet execution
• ideone – multiple (>40) language snippet execution

Tools for web developers to create native mobile apps is a particular niche where web IDEs are moving rapidly. Web developers no longer have a self-contained environment with their workstation and browser.  For mobile development, there are several additional complexities that an IDE can aid, including:

• Deployment
• Mobile UI frameworks
• On-device debugging
• Emulation in desktop browsers
• Conversion from JavaScript/HTML/CSS to native
• Packaging for market readiness
• Web Service APIs

Some of the emerging solutions focused on mobile apps include:

• FeedHenry – Focusing on enterprise mobile apps with desktop emulation, PhoneGap APIs, analytics
• Tiggr – Graphical builder to create jQuery Mobile/PhoneGap apps with REST service API builder
• AppMobi – Desktop emulator, PhoneGap integration, app live update, payments, authentication, push notification
• EachScape – Drag and Drop development, push notification, In-App purchase
• Application Craft - GUI builder, data connectors, PhoneGap Build integration for deployment
• Appception – weinre debugging, Android emulator
• AppLaud Cloud – (my product) PhoneGap, jQuery Mobile, Ripple Emulator, weinre debugger, instantaneous device deployment

Barriers to entry are lowering thanks to open source and clean API’s typical of web applications. For example, thanks to Ripple and weinre, it took just a few days to add emulation and debugging capabilities to AppLaud Cloud.  The jQuery UI Layout Plug-in made it easy to layout an IDE and jsTree provided a nice framework for a project view. node.js and its rich eco-system provide the building blocks for a powerful server.

Ultimately, it shouldn’t matter whether an IDE runs on the desktop or HTML5. IDEs need to meet developers’ needs. Because of the rapid pace of innovation in the HTML5 world, its inherent collaboration capabilities, and its enablement of new classes of apps, cloud-based IDEs are moving fast. If you’re not yet developing with a cloud IDE, you soon will be.

Web or Native Android Development?

Dateline May 10, 2011 : Google I/O Keynote : Android will take over the World

Dateline May 11, 2011 : Google I/O Keynote : Chrome will take over the World

If you see a disparity between the above headlines, keep reading. I’m going to delve into the implications of this seeming incongruity for the mobile developer. Others have written more generally about the colliding courses of Android and Chrome. One article is here.

Should a mobile developer use web technologies or native technologies? I’ll start by summarizing the relevant session from Google I/O.

HTML5 versus Android: Apps or Web for Mobile Development?

Google I/O had a session to compare and contrast native and web development for Android. I appreciated the combined Android/Chrome session. Unlike the individual Android and Chrome sessions, it dealt head-on with how Android native and HTML5 relate. Michael Mahemoff advocated for web apps and Reto Meier advocated for native Android apps.

Michael’s case for HTML5:

• Cross-platform
• Future-proof
• Flexible user interface model (including CSS media queries)
• Deploy once, update instantly

Reto’s case for Native:

• Deep hardware and platform integration
• Support for rapid hardware innovation
• Device and platform specific features
• Optimized Android user experience

The two concluded that the choice depends upon the particular circumstances. While they did conclude that the question should be answered with AND not OR, they did not really support their conclusion with examples of technologies that enable using the best of both HTML5 and native in a single app. A popular example is PhoneGap, which brings most of Reto’s native advantages to Web programmers. It provides JavaScript API’s to access many of the device features, including the accelerometer, camera, and contacts. In addition, PhoneGap’s plug-in mechanism provides a JavaScript mapping to any other native API.

When a question was asked about GWT and Android development, the answer was that GWT is too big of an abstraction layer, despite the convincing session the day before called Using GWT and Eclipse to Build Great Mobile Web Apps. Integrating the GWT strategy, along with Android and Chrome, is yet another challenge to creating a unified mobile web story.

Android Mobile Web Needs

It seems that Google wants to avoid mixing the Android and Chrome initiatives, even as questions about their interdependencies loom larger in the community. I’d like to see the Chrome and Android teams cooperate to provide a better platform for those interested in driving the convergence of mobile and the web. Here are some specifics :

• Expand on Michael and Reto’s session with additional clarity about Google’s mobile web positioning and plans across Android, Chrome, and GWT
• Get the Android web browser up-to-date
• Enable run-control hooks in the WebView so debugging solutions like weinre can go beyond inspection
• Fix the 2.3 emulator’s regression that breaks the Java<->JavaScript bridge
• Require console.log to be part of the compatibility suite

See also my post-Google I/O Java versus JavaScript blog

The 2011 Google I/O was another excellent developer conference. It’s great that Google provides so much information to the developer community. In this blog and its companion, I’ve explored into my biggest post-conference questions.

Java or JavaScript for Web Programming in the Large?

After attending two compelling, but seemingly conflicting, Google I/O sessions, I left with an internal debate about the relative advantages and disadvantages of Java versus JavaScript for developing large web applications. In this blog, I’ll organize my thoughts and provide insights.

GWT + HTML5: A web developers dream!
The first session was focused on GWT, a framework that helps Java developers create Web applications. GWT converts Java into multiple JavaScript/HTML/CSS packages optimized for each browser. John Labanca showed how GWT can be used to easily take advantage of the latest HTML5. Here’s the talk and outline:

• Local Storage for performance
• Visualizations via Canvas
• Audio
• Video
• Drag and Drop
• Unsupported browser versions
• CSS3

In summary, HTML5 features are very usable with GWT. When GWT is combined with Eclipse, the developer has a powerful set of tools to help with static analysis, API completion, and optimization. The tools take advantage of Java’s strong typing to provide these capabilities on-demand, so that the developer can find and learn smoothly in the development process.

It’s also nice to see that GWT has eliminated a big chunk of the acronym and tooling jungle that often occurs in enterprise-style Java solutions for web development.

So if GWT gives me a strongly typed language, superior tools, APIs to access the latest HTML5 features, and optimization for every browser – doesn’t that make programming Web Apps in Java a no-brainer?

JavaScript Programming in the Large with Closure Tools
In the second session, Michael Bolin introduced the Closure Tools and how they help JavaScript scale.

Michael opened by acknowledging the disadvantages of JavaScript compared to Java (particularly GWT). JavaScript is missing a bunch of features that simplify and speed development, especially for large applications.

• No namespaces
• No visibility controls
• No type system
• No static checking
• No built-in support for templates

Despite these shortfalls, Google still uses JavaScript for many of its major programs, including Gmail, Maps, and Docs. Michael’s slide concludes that many programmers choose JavaScript “because it is awesome.”  The reasons for it being “awesome” seemed somewhat nebulous to me. Perhaps because there are lots of available JavaScript libraries for web programming? Perhaps because of the quick feedback loop of an interpreted language? Or, the reason that resonated the most with me : JavaScript runs on the bare metal of the web.

Michael went on to describe how the Closure Tools help manage and optimize large JavaScript applications. Closure provides a compiler to optimize JavaScript into compact, high-performance code. The Closure Library provides a large set of UI widgets and controls. Closure Linter provides static checking to help follow coding styles. All of these tools combine to make JavaScript programs more manageable as they scale.

Since JavaScript exposes the raw web, it’s easy to get started, and Closure Tools address its scalability holes, isn’t it obvious that JavaScript is the language for Web Apps?

Analysis
So where are you after reading the previous sections?  I’m guessing the arguments are close enough that it boils down to experience. If you’re a Java programmer, GWT will sound good. If you’re a JavaScript programmer, sticking with JavaScript will be compelling. But what if you’re like me, a long-time C/C++ developer, who has a comparable amount of Java and JavaScript experience? Or what if you’re brand new to both?

The learning curve comparison is interesting: JavaScript provides a very gradual ramp-up experience. You can get the positive rush of seeing your code running in a browser after just a few lines of code. Then you can scale up. With Java, the learning curve is much steeper. For basic programs, you have to understand concepts like functions, typing, scoping, packaging, and object-oriented programming. On the flip-side, in Java, you won’t lose hours tracking down a misspelled variable name.

It’s great that the Closure Tools are helping JavaScript become more scalable, but are they making JavaScript into something that it isn’t? It really seems like a hack to use comments to declare types. Why not extend the language with optional declarations?

While I like the JavaScript runs on the bare metal of the Web analogy, is it like an obstinate assembly language programmer thirty years ago refusing to learn C? The best programmers understood assembly AND learned to take advantage of C’s higher level abstractions.

Of course, the argument is not that simple, since JavaScript has a rich set of libraries as well as its own higher level features, like function manipulation, dynamic typing and prototype-based inheritance. Check out Alex Russell‘s Learning to Love JavaScript session for more on the wonders of JavaScript, especially the benefits of a functional language.

Conclusion
There is not a definitive answer for everyone about whether to choose Java or JavaScript for Web Programming in the Large. In the meantime, I’d like to see the following trends accelerate :

• Better Java access to the raw HTML5
• Tooling and language enhancements to improve JavaScript scalability
• Less steep onboard ramp for Java – especially for web programming
• Better Java <-> JavaScript inter-operability so developers can find their own sweet spot of a mix

Developers will be the winners as both Java and JavaScript eco-systems compete to provide the best platform.

Like the web, mobile also has tremendous momentum. Mobile, especially the Java based Android environment, adds yet another dimension to the Java/JavaScript discussion that I explore here.

Eating Dog Food at Silicon Valley Android Developer Camp

I spent the weekend at the Silicon Valley Android Developer Camp hosted at PayPal,  presented by Silicon Valley Android Developers Meetup. I was happy to give my talk on the Mobile Web, but this blog is about the rest of the weekend. A few hundred Android enthusiasts spent a huge chunk of the weekend working in small groups tasked with developing a cool Android app.    

Our team had three members, Libby Baldwin, Anthony Hand, and myself. Libby and I did most of the programming while Anthony led the UI design. Our goal was to build a cool mobile app to visualize US first name trending, leveraging the data from the Social Security Administration. Unlike many of the groups at the camp, we implemented our app using web technologies: JavaScript, HTML, CSS – utilizing PhoneGap and jQuery Mobile. I enjoyed the break from the tools development I’ve been focused on for the last several months and directly experience mobile web app development, beyond sample code.

Name Trendz

My team’s app, Name Trendz, allows the user to search for popular American first names by gender, name, year, or generate a random list with a shake. The list results allow additional actions, including collecting favorites and mapping popularity trends. 

PhoneGap

PhoneGap performed flawlessly.  In addition to using the PhoneGap WebView JavaScript->Java bridge for bundling the web app into a native Android app :

• Used PhoneGap Contacts API to Populate a “Friends” list
• Use the Accelerometer API to generate a shake event which we used to trigger a random search

jQuery Mobile

We struggled a bit with jQuery Mobile – screen flashes on transitions, difficulty distinguishing taps and swipes, and responsiveness issues as the app scaled. However, given that it is still in alpha, it’s impressive how nice it looked and how functional it was. We made good use of the following capabilities:

• Multiple page management
• Various list templates
• The slider for year selection
• Theming
• Headers, buttons, and icons

UI Design

It was fun to work with Anthony, a professional mobile UI designer. Anthony took our vague ideas about functions and translated them into clear user workflows and page layouts. jQuery Mobile’s set of samples provide a great language for developer/designer communication.

MDS

Finally, I can’t help but talk about our MDS Eclipse plug-in :

• Tight integration with the ADT made fast device deployment easy for a quick edit/test cycle
• The Eclipse project manager made it easy to work with multiple projects and get the right jQuery Mobile components from a2 or a3
• A yellow pop-up in the editor margin from the JSLint integration gave me quick feedback about typos or incorrect JavaScript usage

Code

I’ve open sourced the Name Trendz code on github. Note, that it is incomplete, but you’re welcome to use it however you wish, especially if you’re interested in the following :

• An example of a multi-page jQuery Mobile / PhoneGap app
• Using PhoneGap to define a shake event
• Using PhoneGap to load Contacts and jQuery Mobile to display them
• Managing PhoneGap and jQuery Mobile events
• Programmatic JavaScript interaction with jQuery Mobile.

Summary

Thanks to David Cao and all the Silicon Valley Android Developers Meetup organizers and volunteers for a great event. I’m looking forward to incorporating this awesome experience into my upcoming tools projects.

* Eating your own dog food

Day of JavaScript

I attended Day of JavaScript at Google last Thursday. Thanks to Marc Grabanski and MJG International for organizing a wonderful event with a full slate of great speakers and a hearty filling of technical content. Here, I’ll share some of my learnings and insights from the event.

State of the Mobile Web Ben Galbraith & Dion Almaer

Ben and Dion started the day with a great talk about the potential of the mobile web and some of the challenges ahead.

One thought-provoking idea was Ben’s pointing out the fallacy in the parallel between the market dynamics of the 90′s Apple Mac and Microsoft Windows versus the iPhone and Android of today. As in the 90′s, Apple will stick to the high-end, high-profit 10% of the market and leave the rest to a commodity solution, like Windows then, and Android today. Ben pointed out that Apple COO Tim Cook said about the iPad “we didn’t want to leave a pricing umbrella for competition, so we got very aggressive on this.”

He went on to discuss that just as in the 90′s, we’re headed for just two major mobile players – iPhone and Android. Will we still be able to stir innovation with only two solutions?

For more on Ben and Dion’s talk, including the three important components to making a mobile web development platform work, check out Mike Rowehl’s  blog.

Sencha David Kaneda
David talked about Sencha Touch, an HTML mobile JavaScript framework that allows you to develop mobile web apps that look and feel native on iPhone and Android touchscreen devices. Sencha Touch provides a rich set of templates for UI elements including buttons, forms, lists, icons, and tabs; animations like slide, pop, fade, flip and cube; touch event handlers, and data transfer.

David’s passion for design came through loud and clear.  The Sencha Touch UI looks great, especially on the iPad and iPhone. It will be interesting to see how well David and Sencha can adapt to other platforms that may not be built with the design perfectionism of the Apple products.

SproutCore Yehuda Katz
Yehuda made the great point that a mobile web strategy shouldn’t be about porting a web page to a mobile device. Users now want to experience the web on two or more devices instead of only on their computer desktop. Thus, a mobile web strategy should enable users to experience the same content in a device-appropriate way.  With that idea in mind, web developers should create universal apps that display the appropriate views and themes for each device (phone, tablet, desktop, etc.).

Yehuda then went on to describe SproutCore in more detail. I had previously considered SproutCore to be a UI framework comparable to Sencha or jQuery. However, SproutCore is actually an application framework, that can encompass jQuery for UI. SproutCore is really focused on being a scalability solution for JavaScript programming. Good news, since as the Web becomes a first class development platform, its primary development language needs to be more scalable.

The demo illustrated how challenging scalable solutions can be. Several times Yehuda pointed out that he was taking short cuts in order to better illustrate SproutCore. Hopefully, SproutCore will create a better ramp-up experience or they’ll be challenged to attract new developers.

Titanium Mobile Kevin Whinnery

Kevin worked through a flaky wireless connection to give a nice Titanium Mobile overview. Titanium enables JavaScript developers to create native applications. Titanium provides a set of JavaScript APIs for accessing device capabilities (accelerometer, contacts, GPS, telephony, etc).  It does a translation from JavaScript to native and puts emphasis on delivering the right platform look and feel.

The open source solution PhoneGap is usually considered to be the Titanium’s main competitor. Kevin’s presentation, combined with some of the audience questions, improved my understanding of the technical differences :

Titanium	PhoneGap
Builds deployable mobile app	Builds deployable mobile app
Device API support	Device API support
JavaScript only (no DOM)	JavaScript, HTML, and CSS
Use JavaScript to create native mobile apps	Build Web Apps for mobile devices
Provides a unique JavaScript-based development environment	Provides glue for diminishing “gap” between web and mobile platforms

Web Browsers Alex Russell

Alex took us inside the world of Web Browsers.

• Described how WebKit is not actually a browser, but a browser engine
• Gave a bunch of performance tips to avoid jankiness, with justifications shown in the WebKit code itself
• Overview of graphics and WebKit

See more detailed notes from @mesh.

jQuery Mobile Scott Jehl

Like Sencha Touch, JQuery Mobile is a JavaScript user interface library and provides a comparable set of capabilities.  However, instead of initially focusing just on Apple devices, jQuery Mobile is designed from the ground up to be cross-platform. It uses progressive enhancement so that it works on feature phones, as well as iPhones.

jQueryMobile is a superset of jQuery, so that all of the jQuery capabilities that desktop web developers know are included. Scott said that he expects jQuery and jQuery Mobile to eventually converge.

Javascript on Mobile Panel

The day wrapped up with Alex, Scott, Kevin and Brad Neuberg on a panel moderated by Ben and Dion for Q&A.  Since I’ve been exploring JavaScript static analysis solutions lately, I was curious to hear the panel’s thoughts on it, especially after some of the heated discussions around jslint last week. The discussion didn’t happen, but Alex pointed out http://doctorjs.org/, that I hadn’t seen before.

Summary

The Octopus is an appropriate symbol for JavaScript and mobile today. Mobile, desktop, and web are converging and JavaScript is the language that will make it happen. We’re just getting started and I’m looking forward to many more great conferences like this one.

Mobile Developer Solutions

Four months ago, I started the open source initiative Mobile Developer Solutions. Four trends that led to MDS :

• The Web is replacing the desktop OS as a programming platform
  • GMail, Facebook, Twitter, Salesforce.com
  • JavaScript programs growing way beyond a few hundred lines
• Mobile developers are faced with dramatically different development environments
  • iOS – Objective C, Android – Dalvik Java, Nokia – Qt C++, etc
• Point solutions address different parts of the mobile web development lifecycle
  • Web to native bridging
  • Device specific APIs
  • UI frameworks
  • Build infrastructure
  • Deployment
• Mobile developers often develop with just command line and an editor like TextMate
  • Scalability challenges
    • Mobile development is more complex than desktop development
      • Deployment, packaging, signing, device management, etc
    • Web applications are getting bigger
    • More developers are moving into mobile development

Seeing these dynamics, I saw the need to provide IDE help for web developers to create mobile apps. I chose to build upon Eclipse because of Eclipse’s powerful framework for creating developer solutions. Eclipse has provided scalable, full lifecycle development environments for over ten years. Its plugin architecture makes it easy to extend.  Android is already using it for Java development.

The MDS plugin builds upon the Android Development Tool plugin, the Eclipse JavaScript Developer Tools, and the PhoneGap framework. I integrated these components with a new Eclipse project wizard to enable Web developers to create and deploy Android applications with just a few mouse clicks. The wizard also allows configuration with either the jQuery Mobile  or the Sencha Touch UI framework.

MDS 1.0 released in November. MDS 1.1 added the UI framework support and released earlier this month. It’s been great to hear the appreciative comments and see the upward trend on the site visits – now over 3200 unique visitors.

Check it out at http://www.mobiledevelopersolutions.com/