1. 24 October 2013

    Dumped Cappuccino and switched to Ember

    The previous developers left us with some technology that, still today, keeps us wondering why they picked it. The manager.enstore.com, admin page for Enstore stores, was built using Cappuccino framework. According to wikipedia Enstore was one of the few products in the world that was build with this technology. Also quickly going through that list, Enstore was the only one we would say commercially deployed on a large scale. As issues with the project were piling up, we decided that replacing Cappuccino would be far better long term, than trying to fix those issues.

    Why a rewrite?

    Rewriting is always the last thing you want to do, but this time the choice was kind of obvious.

    • Maintaining a Cappuccino project is expensive.
      • Cappuccino framework is very delicately put together, any kind of web engines updates would always cause some issues for our users. We had many incompatibilities with latest browsers, Safari 5.3 and up for example.
      • The skills required to do changes involved somebody that was familiar with unrelated technologies: (XCode, Cocoa, Objective-C) on one side and (HTML, CSS and JavaScript) on the other side, and this was glued together by something called Objective-J
    • Performance:
      • Website’s loading speed was slow.
      • Requires more memory to run.
      • Performance issues when updating simple sets of data.
      • Resizing the browser window showed how badly the reflow/layout code was performing. (In today’s version they fixed this using a hack, avoiding redraws during these events.)
    • Now that we are in the era of responsive design, adjusting the website for mobile is not easy to do.
    • We have another big HTML5 project in the pipeline, so we needed to field test the current JavaScript frameworks.

    Which JavaScript framework

    To replace Cappuccino framework, we had the following short list of frameworks in mind: Ember, AngularJS, Knockout and Polymer. Why we preferred Ember, is beyond the scope of this blog post, but in short:

    • Pure: JavaScript, CSS and embraces the DOM.
    • Good template system Handlebars we weren’t fan of the AngularJS templates. Also in future it will have Web Components support.
    • Very mature framework, version 1.1.1 shipped recently
    • Many developers interested in it and good set of 3rd party examples.
    • Relative small code size.
    • Fast data refreshing, especially compared to AngularJS refresh loop.
    • Ember Data and EPF gives us good options for complex models in the future.
    • Multi-view management
    • Router: displaying templates, loading data, and otherwise setting up application state.
    • Doesn’t rely on a specific server technology (not like Batman.js and Meteor)

    Ember verus Cappuccino

    Since a few weeks ago we shipped the rewritten version of manager.enstore.com, we are in the unique position to compare Cappuccino framework against a more natural JavaScript framework.

    Project size

    We mimicked the same feature set and preserved the same look and feel, on top of that we added a lot better user experience, less clicks are required to accomplish the same tasks. The amount of lines of code required to build the admin website in Cappuccino was about 20K lines, 95% of the code was Objective-J. With Ember the same functionality was obtained in less than 3K lines of code.

    Development time

    The Cappuccino project took about 4x longer to develop, maybe obvious when you just read that the lines of source code was about 6x higher. This was our first project with Ember, we have some experience with Backbone.js, so there was some learning in the time frame. We were told that Cappuccino makes it very easy to build web apps in case you are familiar with Cocoa. But it didn’t turn out to be true in the real world. The development time difference, gave you as a developer sufficient time to take a book and some tutorials to learn JavaScript properly, and use one of the native JavaScript frameworks available at that time.


    The Cappuccino web app was about 4 MBytes, most of that needed to be downloaded before you could see something in your browser. The total download size for the Ember app is now 200KBytes, indeed 20x less to download. This makes a big difference on your mobile device on a poor connection. While running the Cappuccino app, the memory usage was of course multiple times higher than the Ember app, which drains more battery on mobile devices.


    Maintaining a project with 6x more source code is more time consuming. Adding new functionality is of course more challenging. We are now using QUnit for a series of automated tests, we were able to cut a lot of QA time. The Cappuccino version, had no automated tests.


    JavaScript is a high level programming language, than slapping another syntax on top of it, just to make the code look more like Objective-C doesn’t make much sense to us, especially because the syntax is not quite Objective-C. So you have to learn all the subtle differences. Debugging the project was a pain, because what you see in the JavaScript debugger is not the same code that you just typed out, you can see some examples here: Cappuccino Debugging

    Cocoa in browser

    Another tag line we heard was that Cappuccino framework copies the Cocoa framework, of course not completely but they are close. To get that done they added ten thousand lines of source code, but for what? Eventually you will be running in a browser, Bootstrap, Foundation and others gives the same visual end result but the download size is about 50x smaller.

    Interface Builder?

    Wow a visual tool to draw my website, sounds catchy, but once something starts mysteriously to disappear or jumping in your web browser, you can’t avoid it but start to learn the deeper fundamentals of CSS and figuring out what is going on. Just by learning proplery CSS and HTML in the first place this could have been avoided. Also by picking a visual tool like Interface Builder that runs only on Mac OS X, you are limiting your options of finding skills to maintain this project. You don’t need a person with basic CSS knowledge, when there are bugs you need somebody with very profound knowledge. If you ask a web developer to update a button and he suddenly needs to use tools that he is not familiar with. You are going to have train him in skills he won’t use every day. So any update is actually an expensive operation.

    Hello Core Member

    Because only a handful of people are working on the Cappuccino framework you automaticaly become a core maintainer of the framework. The Cappuccino framework is huge, so you will spend many hours just trying to figure out why is my code not building anymore. Also trying to find help online, good luck.

    Lessons learned

    • If you are deploying to high level technology like (HTML, CSS and JavaScript) than trying to squeeze in a low level technology, like (Cocoa and Objective-C), doesn’t that sound like a weird idea? If you look at the facts, it sure is.

    • If your code gets compiled (on the fly, optionally) to JavaScript, don’t think you will never get to learn JavaScript. Debugging code is a big portion of any large project, so debugging will be in JavaScript.

    • If your easy to use drawing tool can make you nice lookings dialogs and windows, but in the end you generate HTML and CSS, don’t assume you will never have to learn CSS.

    • Trying to fit desktop metaphors on something like a web browser, requires a big amount of patchwork. You will start to make compromises where both worlds collides. Automatically this introduces new patterns that your developers need to get familiar with. When new platforms like mobile appear you start scratching all your resources in trying to catch up.

    • When picking a framework, pick something that is simple and doesn’t add thousands lines of source code. (For something that takes 6x less lines of JavaScript.)

    • When you notice that only a few people are using the technology and your company has no interest in growing the market share of that technology, please think twice before continuing investing time in it, because in the end you will invest a lot of time in trying to make that technology work.

    • In case your deployment platform is something from a very mature level, trying to avoid using its native technology, will cost you deeply, you are not only missing out on the tremendous amount of developer tools and third party code available, you will also have to build your own alternatives or workarounds. Also you will have to invest a lot of effort in maintaining and updating that porting/bridging technology when new features are added. But it seems Cappuccino is not alone, still today more of these are build: C# on iOS, Ruby for iOS and OS X and Python on top of Cocoa