Ten Things I Wish Were Better About IBM Worklight

I fully expect IBM Worklight (recently re-branded as IBM MobileFirst) to be the dominant player in the enterprise Mobile Application Development Platform (MADP) space for the foreseeable future. Certainly the IBM name carries a lot of weight in the halls of financial institutions and other large corporations (the old canard about nobody ever being fired for choosing IBM is just as true today as it was twenty years ago).

One of Worklight’s key selling features is that it directly speaks to a problem that enterprises have historically been obsessed with: keeping the long-term maintenance cost of applications low. The big scary aspect of building mobile apps is the idea that you have to build two to five completely different copies of your app for the different mobile OSes: iOS and Android are absolutely required to play in the mobile space; Blackberry 10, Win Phone 8 and Windows Surface might also be a wise investment, depending on the type of user base you have. Most enterprises see that idea as a maintenance nightmare: how many skill sets will they need to train in their support staff? How will defects get fixed consistently across that many codebases?

Enterprises generally accept that 80% of the cost of an app, during its full lifetime, will be spent during maintenance. What’s more, the special demands of mobile make the investment costs look especially dire from an ROI perspective.

But this maintenance problem is exactly the thing that MADPs promise to address: a single codebase, with processes to build for multiple platforms, and — in the case of some MADPs — using common skills like HTML and JavaScript. Together with IBM’s ability to impose its products on the market effectively market and sell, IBM Worklight seems poised to dominate the enterprise MADP space. I fully expect Worklight to displace other enterprise players like Kony.

The only problem that I have with all of this is that I wish IBM Worklight were a better tool than it is. And clearly Worklight represents an uncomfortable marriage-of-convenience for IBM: they obviously fell much more in love with Kony and wanted to tie the knot, but never managed to succeed in the wooing stage. So they hitched up with Worklight instead.

I can see why Worklight appeals to enterprises, and as a mobile consultant for enterprise IT organizations, it’s certainly an important tool to have in my wheelhouse, but as someone who loves working with really clever and useful development tools, I can’t help but find myself longing for more.

Here’s my list of ten things that I wish were better about IBM Worklight.

Worklight Studio

1. Realistic Target Dev Boxes

My biggest complaint about IBM Worklight is a complaint I’ve had about a lot of IBM’s developer IDE products: namely, that IBM’s tool developers never really consider the kind of developer machine a typical enterprise customer is using. Invariably, they design tools with an unrealistic expectation of processor speed, memory and other performance indicators. When these developer products are being used in real-world enterprise environments, they’re slow as molasses.

Worklight Studio is no exception to this trend.

On a recent project, we built what I would consider to be an average-sized enterprise mobile application for a large financial institution. We expected the user base for this app to number in the hundreds of thousands. Our Worklight project was configured with all the target environments (iPhone and iPad, Android, Windows 8/Surface, Win Phone 8, and Blackberry 10, with an extra skin for the Q-series). This is, after all, the exact selling point of a MADP: the ability to manage multiple environments. Many of our developers were using brand-new, top-of-the-line MacBook Pros with 16 Gig of RAM, and they found Worklight Studio to be underwhelming. IBM says that, on Mac OS X, Worklight requires 3GB of RAM, with 4GB being recommended. Uh, no. Worklight brought my 8GB MacBook Pro to a crawl at times.

Our counterparts from the financial institution, by comparison, were using significantly more underpowered Windows XP laptops (the laptop resources were also being consumed by embedded security lock-down software and corporate spyware). It was nothing short of painful to watch them try to use Worklight Studio.

One of the claims frequently trotted out by analysts who talk about the mobile-readiness of different organizations is that IBM really understands the enterprise client. And there’s a way in which that’s true. They understand how the enterprise purchaser makes decisions, and they understand the needs of the production monitoring software really well. But it’s often felt to me like they don’t really understand the enterprise programmer, and they’ve frequently overestimated what the standard enterprise developer machine looks like.

2. Need Better Developer Tools

It would be one thing if the only complaint was that the tools were slow. We also need better development tools.

As I’ll discuss, below, the various types of preview tools should be obviated by an incremental build process. Important tools that are missing include a remote DOM inspector, a remote console log, and a JavaScript shell to allow a developer to send ad hoc commands to the app running on device. One can often suffer through with just the console logging that the iOS and Android offer natively. But if you have the misfortune of doing Blackberry or WinPhone development, tools like this could spell the difference between a successful project and a development team suicide pact.

3. Hand-off to Simulator

Here’s a pretty common scenario: you have an iPhone app, and you’ve tested it in your browser, but you want to test some of the plugin features that give you access to native code. Usually, you’d want to launch the iOS simulator to see how the app behaves.

Worklight requires you to go through a couple of steps, here. First, you need to build the iPhone environment in Worklight Studio and launch XCode (it seems strange to me to go from one IDE to another). Next you build and run your app in XCode, targeting the appropriate simulator.

If you discover that you need to make a change, you have to repeat this process again and again. If you’re lucky, you might be able to skip some steps, but in the worst case, you have to start at the beginning again.

This seems especially dreary when compared to the tight integration between IDE and Simulator of some of Worklight’s competitors. Appcelerator Titanium, for example, has a nice “launch in iOS simulator” button available in their Eclipse-based IDE. Although I understand the technical reasons for why that’s harder for Worklight, I don’t think that IBM shouldn’t be avoiding the hard problems, here.

4. Bugginess and Instability

IBM really needs to fix up some of the buggy aspects of Worklight Studio.

I’d hate to try to count up all the development hours my team lost to the mysterious “WLJQ is not defined” error for example. Every once in a while (but on average, I’d say once a week), Worklight would stop inserting references to standard Worklight scripts (such as the Worklight version of JQuery — WLJQ) into the HTML that it serves. Once it’s in this state, we have no choice but to shut down Studio, clean up some temporary files, and then restart Studio, clean the workspace and re-launch the server.

On a fast machine, that’s about half an hour of time lost. On a slow machine, it’s a lot more than that. And it’s about once a week for every developer. That’s too many developer hours lost, over the course of the project development plan. That was our most common and best-understood Worklight Studio glitch. If only it was the only one we encountered!

5. Bundled Cordova

I confess that I’m underwhelmed by the way IBM has bundled a very specific version of Cordova with its versions of Worklight. Too often I’ve gone hunting for the solution to a particular defect, only to discover that it’s a problem fixed in a later version of Cordova — a version that Worklight doesn’t yet offer.

In some ways, I feel like I’m back in that ugly world of Visual Age for Java in the year 2000, when Visual Age came bundled with a very specific version of Java. IBM grew to understand, then, why that bundling strategy for a developer tool didn’t work; it surprises me that it has returned to something very similar.

I get that Worklight is built on top of Cordova, but IBM needs to cut the umbilical cord. I should be able to upgrade Cordova without needing to wait for IBM to ship a new version of Worklight Studio.

Build Paradigm

6. Append to End Model of “Building”

Worklight uses a fairly unsophisticated model for supporting multiple UIs. Consider the following scenario: you have a mobile app, and your UI design strategy includes matching certain UI elements to the native device. This means that some UI elements will appear differently on an iPhone versus and Android device.

Worklight primarily encourages UIs to be created in HTML5. The majority of HTML, JavaScript and CSS is located in a “common” folder, but platform-specific files can be placed in an ‘iphone’ folder or an ‘android’ folder. When Worklight builds an app for a specific platform, it looks for similarly-named files/directories in the ‘common’ and platform-specific folders. Thus it decides that the ‘iphone/styles/myapp/main.css’ file contains platform-specific additional information for a file named ‘common/styles/myapp/main.css’. As it builds the iPhone-specific version of the app, it appends iphone directory’s contents to the end of the corresponding files in the common directory (HTML files are handled differently; in that case, an HTML file in the iphone directory, if it exists, replaces a correspondingly-named HTML file in the common directory).

This strategy avoids the need for any specialized editors or Worklight-proprietary file type or syntax, and it’s fairly easy to make sense of. My complaint is that I believe that it’s a build pattern that really doesn’t support a wide variety of modern HTML5 development practices.

For example, these days, most JavaScript is currently being written using some kind of component framework. If you’ve read Crockford’s book, JavaScript: The Good Parts, you’re probably limiting the scope of many JavaScript functions in a way that emulates private or internal methods in OO programming languages. The key consideration of this kind of JavaScript code is managing the scope of your methods. Or perhaps you’re using a framework like require.js to define scoped components that can be injected into other components. Both of these programming models depend on some kind of outer scoping block — in the latter case, the scope is managed inside of a “define” function call.

In these kinds of programming paradigms, the assumption that you can just add extra stuff to the bottom breaks assumptions about scoping. Any function that you want to override must be exposed in a globally-accessible scope. That’s certainly not impossible, but it reflects the kind of programming that was common 5 years ago; it looks rather dated, today. And, frankly, it makes me feel like Worklight is targeting and encouraging a kind of programming model that’s out-of-date.

As an aside, I suspect that the “append to end” build model is one of the reasons why IBM promotes JQuery Mobile over component-based frameworks like Dojo or Sencha Touch. IBM clearly favoured Dojo at one point in time, but now they seem to have hitched their wagon to jQuery Mobile — unfortunately, the kind of programming that jQuery encourages is exactly the kind of programming that’s leading JavaScript experts into the arms of component-based frameworks.

CSS fares a bit better in this “append-to-the-end” build model, but not perfectly so. Earlier this year, Thoughtworks’ technology radar clearly positioned manually-created CSS as a programming activity that should be ended. The move is clearly toward a SASS- or LESS-based approach. While SASS and LESS support the “append to end” model better than component-based JavaScript, there are still some areas that don’t fit that model well, such as SASS’s support for nesting. More worrying is that neither SASS nor LESS are natively supported by Worklight, which will probably mean some trial-and-error fitting the SASS/LESS precompilation step into the overall Worklight build process.

This is, in my opinion, the biggest failing of Worklight: it’s built for an HTML development approach that’s a thing of the past.

7. Incremental Build

And while we’re on the topic of building the app, why doesn’t Worklight build the app files incrementally? I mean, Worklight Studio is an add-on to Eclipse which, along with its predecessor, VisualAge for Java, was the poster-child for incremental building. Instead of giving me a bunch of different heavy-weight previewers that assemble the files as the browser requests them (including appending files as necessary), why can’t Eclipse just incrementally build the resources by generating the necessary HTML, CSS and JavaScript whenever the files are saved. Throw in a SASS compiler as part of the mix, and Worklight would be smokin’.

The Worklight build engine is such a relic of the past; it really needs some love if IBM wants developers to report positive things about the tool.

Worklight Server

8. Adapter Deployment

IBM heavily promotes the value of Worklight adapters, and to be fair, in concept they’re fairly powerful. The idea that you can quickly build a database-driven adaptor, or a SOAP to REST adapter quickly and easily seems like a useful thing.

But one of the weirdest oversights of Worklight Studio is the absence of a “Deploy all adapters” function. I If I have 30 adapters, I need to deploy each one, one at a time? Really? This seems to be a major oversight by IBM’s User Experience people…

Or is the truth really a lot more sobering: does IBM not expect people to use adapters very often?

9. Limitations of Rhino

I like the fact that Worklight supports adapters written in JavaScript — an acknowledgement that, given that HTML5 developers are likely already using JavaScript, it would be good to be able to use that on the server as well. The sad part is that IBM’s current implementation of JavaScript adapters use Java’s Rhino JavaScript interpreter.

In general, I have no objection to Rhino, but there are consequences that need to be considered. For example, the Rhino adapter API makes it really hard to implement “common logic” in adapters. Say, for example, you’re building a payment system, and most of your adapter requests include a client card number. It’s surprisingly difficult to implement a common card validation function, and have that available to a number of different adapters. I can’t really wrap my head around an adapter implementation that hasn’t foreseen the most basic programming idioms.

Another (relatively minor) irritant of Rhino is its support for certain JavaScript extensions that don’t exist in other JavaScript implementations. In particular, Rhino supports Ecma-357, which adds additional support for XML literals. One of the downsides of using this extension is that adapters become harder to write unit tests for: one must find a unit test framework that runs in the same Rhino or Rhino-like environment, and that tends to exclude the most popular frameworks.

Yes, I know that it’s entirely possible to elect not to use an extension in the JavaScript interpreter, but as IT consultants, that choice isn’t always in our hands. IBM hands out code samples and guidance about how to build adapters that make use of these extra features, and our enterprise clients seem to adopt those samples as architectural standards because, well, IBM recommended it. Unsurprisingly, those code examples never seem to come with corresponding unit tests.

10. XML to JSON Conversion Weaknesses

One of the most common adapter types that enterprises are likely to build are XML to JSON adapters. Enterprises who’ve bought into the SOA mantra, and built SOAP/XML interfaces to their backend systems are now eager to simplify those APIs into REST/JSON calls that are more wieldy for mobile front-ends to consume. (Accenture argues that the drive to right-size SOA APIs for the needs of mobile will be an exercise comparable in effort and importance to Y2K. So, y’know, that’s not trivial).

Unsurprisingly, IBM provides some utilities and code samples to automatically convert XML to JSON. My concern is, of course, that the default conversion utility results in some pretty dreadful JSON. Some types of “dreadful” are, admittedly, things that offend my sense of aesthetics: JSON objects with attributes named “CDATA”, for example. I’m also not wild about all the namespaces information polluting my JSON output, and the SOAP/HTTP status codes being dumped into the JSON as well. I could, I suppose, just hold my nose and learn to love the bomb. And I have had to do that. But where things go from “bad aesthetics” to “problem just waiting to happen”, for me, has to do with getting structurally inconsistent output.

Consider the following example: imagine that I have an API call to get client data. One of the attributes of the client data is the “phone numbers.” In XML terms, one can have zero or more <phoneNumber /> tags on the <client /> tag. That’s not an uncommon pattern. But try to convert that into JSON. Worklight’s convertor makes annoying default choices: if you have exactly one phoneNumber, you’ll get something that looks like this:

	“phoneNumber”: “416-555-1234”

and if you have multiple phone numbers, you’ll get something that looks like this:

	“phoneNumber”: [ “416-555-1234”, “416-555-9876” ]

Now the structure of my JSON varies depending on the actual data. In my front-end code, I need to add additional checks to ask, “Is this field an array? If not, I probably should convert it to an array.” The scarier question is, “Do I trust all the developers that I’m working with to always make that check in their code?” Because if they base their code only on the one example they’re currently seeing, the JavaScript will behave badly when a different case happens.

Again, this would be a situation where I’d be inclined to say, “don’t use the default converter.” Except, again, this decision isn’t always mine to make. It doesn’t help that IBM tells our enterprise clients that this is the ideal way to build adapters and get rootin’-tootin’ performance out of Worklight. It’d be an understatement to say that I’m frustrated when I have to work with the results of one of these types of adapters.


As I said, I fully expect Worklight to dominate enterprise mobile development shops for the foreseeable future. Nonetheless, I’ve already seen instances of Worklight driving enterprises back into the more forgiving arms of native development and multiple codebases. That’s a pretty significant way to fail.

I think it’s within IBM’s power to fix many of these issues with Worklight. The problem — and this is so often the problem with IBM developer tools — is that I don’t see much evidence of a will to fix these issues. I’m not sure IBM even recognizes that there’s a problem. And that’s the scariest part of it all.

It's only fair to share...
Share on Facebook
Tweet about this on Twitter
Share on LinkedIn