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.
- 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.
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:
- 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
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.
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.
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.
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.
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 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