Today we are extremely excited to announce Cappuccino 0.9.5, featuring over 90 new features and improvements in addition to numerous bug fixes. Here are some of the new features we think you’ll really like.
Modern scrollbars
Cappuccino now features new scrollbars which fade away automatically when not in use, giving more space for the content of your scroll views. If the user’s browser does not support or use overlay scrollbars, Cappuccino automatically detects it and falls back to old style scrollbars.
Documentation Overhaul
The Cappuccino documentation has not only been extended but also visually refreshed. Many more classes and methods are now in the documentation and it’s an easier read.
Popover Widget
A popover control is a small window that appears to ‘come out’ of a part of your user interface, and which remains attached to it until the user dismisses it. It’s an easy way to ask for extra information when that ‘create’ button is clicked, or to show a list of individually selectable downloads when the ‘downloads’ button is clicked.
CPPopover originating from a button.
Level Indicator Widget
A level indicator shows a discrete graduation from ‘empty’ to ‘full’, useful for certain gauges like space usage. Level indicators can also be editable and can be placed inline in table cells.
Level indicators, some in a ‘warning’ state.
Predicate Editor
Predicates are powerful tools for encoding ‘search patterns’, and combined with the power of Cappuccino’s Array Controller class they make it incredibly easy to create user searchable tables or other views. The new predicate editor allows users to create their own saved searches with almost no work for the developer.
Tooltips
A much requested feature has been tooltips. We didn’t want to release something that wasn’t as powerful and flexible as everything else in Cappuccino and we don’t think we will disappoint. Cappuccino tooltips can be attached to any control, position themselves intelligently and support multiline tips.
Stronger Interface Builder Integration
If you want to easily create and edit your user interfaces using a visual editor, you have the best tool in the market available for use with Cappuccino: Interface Builder. Every aspect of the nib2cib experience has improved, with better support for fonts, smarter realignment of widgets to match Cappuccino sizes and support for more controls than ever before. Best of all, the new XcodeCapp application automatically creates an Xcode project out of your Cappuccino project and lets you place UI components with ease.
New Installer
The new bootstrap installer is much simpler to use and installs all the packages you will need by default.
You know you want to.
Notable Improvements
There are too many improvements to list them all here but here are some highlights:
CPNumberFormatter with CPNumberFormatterDecimalStyle.
More powerful objjc CLI.
CPButton continuous mode.
Keyboard navigation, improved submenu handling and auto validation in CPMenus.
Support for pattern fills when drawing using CG.
Many new bindings features and optimisations, including CPNullPlaceholderBindingOption, CPContinuouslyUpdatesValueBindingOption and better object controllers.
CPUserDefaultsController which can be used to easily bind controls to user default keys in Interface Builder or elsewhere.
CPColorWithImages convenience function to quickly create a `CPColor` from single, 3-part or 9-part images.
Support for autosaving and collapsing views towards the right in CPSplitViews.
The first ever Cappuccino conference was a massive success. CappCon 2011 had a diverse set of attendees from six different continents and included both speakers and sponsors from Pixar, Google, Sofa, Push Pop Press, Shopify, and many others. The overall theme of the conference was “Design, Develop, Distribute”; everything you need in order to build a successful app. The talks explored this theme and covered a huge breadth of knowledge, while each one explored its topic in satisfying detail. In addition, all seven members of the core team were in the same room at the same time to answer questions from the community.
Two of our favorite reactions were “this is the best conference I’ve ever been to” and “CappCon was better than WWDC.”
Announcements
Perhaps the most exciting part of the event was the amount of projects revealed and released! If you didn’t follow the event on Twitter, here is a quick overview of announcements made:
Language.js: Objective-J author Francisco Tolmasky has open sourced his new parser generator. Language.js gives you first class error reporting as well as unprecedented speed. This new parser generator will be the basis for Objective-J 2.0, which will open many unheard-of opportunities for the language. Language.js on GitHub
CoreText and CPTextView: Cappuccino core team member Nick Small showed off his new implementation of CoreText and CPTextView. These amazing new controls for rich text represent the first time ever we will have desktop-class rich text on the web, which also offers feature parity with Cocoa’s NSTextView. CPTextView will be available soon, but CoreText is open source now, in its own branch in Cappuccino mainline.
Aristo 2.0: Sofa has worked hard to provide a new version of the already best-in-class Aristo theme that we have already started to implement in Cappuccino. Aristo 2.0 accomplishes some new goals, mainly to “under-promise and over-deliver,” something we’ll talk more about in the coming weeks. Preview of Aristo 2.0
Frappuccino and RunKit: Austin Sarner and Mark Davis will be open sourcing their physics-based animation toolkit, and alternative UI framework.
The Future
Of course there were many more announcements and talks, and the videos and slides for every talk will be available in the coming weeks. The atmosphere at CappCon was infectious; people were thrilled to attend, learn, talk, and interact.
Most importantly, everyone present was a part of the future of Cappuccino. The takeaway from the event is that Cappuccino is stronger than ever, and with some incredible things in the pipeline, it’s poised to get even better.
Thanks to everyone who could attend, and we hope to see everyone again next year!
We’re really excited to announce the next major release of Cappuccino, Version 0.9. This massive release includes several killer new components, exciting new features for existing components, and of course a number of bug fixes. Here’s a brief overview of some of the compelling things you’ll find in Cappuccino 0.9:
Bindings
One of the most exciting features of this release is full Key Value Bindings support. Team members Klaas Pieter, Alexander, Ross, and of course many members of the community have put a tremendous amount of work into getting bindings ready for this release. With support for most major components, CPObjectController, CPArrayController, and undo/redo, bindings are already a killer feature. But we’ve gone one step beyond that and included support for bindings in nib2cib! So not only can you build your Cappuccino interface in Interface Builder, but you can now configure interface bindings in it as well.
CPTableView and CPOutlineView
We were incredibly excited to introduce table views—one of the most important and versatile components in any widget set—in our 0.8 release. In 0.9, we’ve matured the table view to production quality and added its supplemental component, the outline view. CPOutlineView lets you build tables that provide hierarchical data and it inherits from CPTableView, so it already benefits from all the additional work that has gone into the table view.
CPOutlineView
Table views now support bindings, group rows, inline editing, column reordering and resizing, and a whole slew of other features. Perhaps the most requested feature that is now supported: variable row heights.
CPTableView Variable Row Heights in an upcoming Cappuccino demo app
One of the most important aspects of our table view is performance; we have been very careful not to sacrifice speed for any of these new features. CPTableView will still scroll like butter, even with hundreds of thousands of rows.
New Components
This release also introduces several new features to Cappuccino. You’ll find more controls from Cocoa and some new additions specific to Cappuccino. While there are too many to mention them all here, here are some notable additions:
CPAlert: Totally rewritten for ease of use and featuring a new UI designed by Sofa.
CPBrowser: We’re shipping a great implementation of CPBrowser with this release of Cappuccino. CPBrowser provides columnar layout for displaying hierarchical data. This is very similar to the column view in Mac OS X’s Finder.
CPCursor: A simple API for changing the user’s cursor. The class supports a number of cursors from the start or allows you to load your own images.
CPPredicate: The CPPredicate school of classes gives you a very powerful way to filter through your data. A future release may include robust controls for users to visually edit predicates.
CPStepper: A control that allows users to incrementally step through values.
CPTokenField: A powerful text field subclass with support for autocomplete, CPTokenField allows you to build unique token managers, like the address fields in Mac OS X’s Mail.app.
NativeHost: We announced NativeHost a few months ago, but this is the first time we’ve included it with a release of Cappuccino. NativeHost lets you build your Cappuccino application for desktop platforms and distribute it like any other desktop app. Support for Mac OS X is currently included, with Windows and Linux support coming soon.
CPAlert
The Future
We’re extremely proud of this release and all the time and work that has gone into it. We couldn’t have made it to this point this without all our contributors (67 and counting!), and a huge thank you goes out to everyone involved. The core team has grown considerably as well, now composed of 7 team members. We also want to thank everyone who has battle hardened this release through rigorous testing and feedback.
But what’s next? We have a ton of updates in the pipeline, and the master branch is already far ahead of 0.9. Cappuccino has been open source for over 2 years now, and it has been an amazing ride. The framework has vastly matured and a lot of people would have already slapped the 1.0 sticker on it. However, we’ve had a concrete goal of quality and completion in mind from the beginning, and can finally see the light at the end of the tunnel. Stay tuned in the upcoming weeks as we discuss our final roadmap toward Cappuccino 1.0!
JavaScript has some real problems. Anyone who has programmed for the web can attest to that. And anyone familiar with what we’re doing with Cappuccino will recognize that we’re not afraid to tackle those problems head on. When we created Objective-J we set out to create a set of true enhancements to the JavaScript language that would add powerful new dynamic features to the language, like advanced automatic dependency resolution, truly dynamic message passing, and familiar classical inheritance. By all accounts it has been a tremendous success.
Lately, though, we’re beginning to realize that we didn’t quite go far enough. Memory issues have long plagued JavaScript developers. Because the garbage collector is opaque to the developer, and nothing like “finalize” is provided by the language, programmers often find themselves in situations where they are forced to hold on to an object reference for too long (or forever) creating a memory leak.
Just as we’ve done before, when we tackled this problem we decided to look at what has worked in the past. Finding inspiration in the elegant simplicity of C, we knew we’d found the right solution. And so, we’re pleased to announce the immediate availability of a manual memory management system in Cappuccino.
A lot of Cocoa developers disparaged garbage collection when it came to Objective-C, and we’ve come to realize they were absolutely right! Why rely on machines to solve problems for us when we can do it by hand. So, we’ve taken the Cocoa reference counting system and implemented it in JavaScript. We’ve replaced the existing no-op -retain, -release, and -autorelease methods with fully working implementations. When an object’s release count reaches 0, the object’s dealloc method will be called, and the memory will be able to be reclaimed. Now you have a clear way to clean up unwanted references when an object is no longer being used. Just make sure you do your reference counting correctly!
To do this right, we’ve created a global object table. These objects aren’t going anywhere on their own! If you don’t release an object, it will stick around forever, ensuring you’ll always have it when you need it. This global table acts as a lookup table for any object, allowing us to finally implement pointers in JavaScript. Since $ has become the coolest way to do completely non-standard lookups in an almost indecipherable way, we thought we’d jump on the bandwagon. Pass any pointer to $ and you’ll get the associated object! How do you get a pointer you ask? $$ of course! For example:
var o = [CPobject new]; // +new returns with a retain count of 1!
var p = $$(o); // returns a pointer to o
o === $(p); // we dereference the pointer and get the right object!
Zombies come standard, too! Just set OBJJ_ZOMBIE_DETECTION to true and objj_msgSend will throw an exception if you ever message an object that’s been dealloc’d.
We’ve even take the time to properly -autorelease all objects returned from class methods in Foundation, but we’ve made absolutely no effort to properly retain those objects in Cappuccino code that uses them yet. So we need your help. Every line must be scrutinized (but we shouldn’t to automate this process, as it would surely be too error prone). Rather than focus on developing new features or fixing bugs in the issue tracker, we hope that all Cappuccino contributors will spend their time writing memory management code so that we can fully realize this web development revolution!
We’ll be including these exciting new features in a future release, so you should get started adding manual memory management code to every single line of Cappuccino you’ve ever written! In the meantime, check out the working code on Github.
We’re really excited about the ways Atlas could change the process of developing web applications. Atlas will allow developers to worry less about boilerplate user interface and glue code, just as the Cappuccino framework gives developers many common features expected by users, letting them focus on the ones specific to their applications.
Furthermore, Atlas allows non-programmers, such as many graphic designers, to join in on the process of actually building an application, rather than just providing mockups that must then be replicated in code by a developer.
Atlas will be available this summer. Sign up for updates on 280atlas.com and we’ll let you know of the progress on Atlas.
In a recent post by John Resig, and in many of the comments, there seems to be the mistaken belief that Objective-J was designed to allow existing Objective-C programmers to write code that runs on the web. It’s been compared to GWT, where developers program almost exclusively in Java and are allowed to “circumvent” JavaScript. This however is not the case with Objective-J at all. For starters, Objective-J is simply a language addition to JavaScript, and exists separately from the actual Cappuccino framework (which I’ll discuss a little later). It does not directly have anything to do with the DOM or AJAX, etc. The purpose behind Objective-J was to facilitate the development of Cappuccino, and when we originally set out to do that we simply wanted to add a few key missing features to the existing JavaScript “standard”. In other words, Objective-J is our take on JavaScript 2.0.
Now, this is usually the point at which someone chimes in that JavaScript is perfect, and that I just don’t understand it (you know, despite the fact that I’ve been using it for upwards of 10 years and have worked on its implementation in a major shipping browser). However, I think most people in the community can agree that there are some pretty big holes remaining in JavaScript. JavaScript is being used in increasingly larger projects, and in these projects some of its weaknesses are beginning to show. This is precisely why we have things like the (now dead) ECMAScript 4 proposal, Harmony, and Adobe’s ActionScript. And the truth is, had JavaScript 2.0 come around and been widely implemented and supported, we would have built Cappuccino without Objective-J. But the problem is that JavaScript 2.0 didn’t come around. I started working on what would eventually become Objective-J and Cappuccino three years ago, and in that time there have been no significant improvements or changes to the JavaScript language. Yes, certain browsers have taken it upon themselves to add a few nice features here and there, but for people writing real applications that need to run on most browsers, its simply not practical to rely on them. For the most part, we’re writing the same JavaScript today (language-wise at least) that we were 5 years ago. And that doesn’t seem like its going to change anytime soon.
Everybody is writing “abstractions” around JavaScript
And I don’t just mean projects like Pyjamas and GWT. I mean EVERYBODY, including Prototype, Dojo, and jQuery. Yes, you read correctly, all the major JavaScript frameworks are essentially doing the same thing we are to some degree or another — we’re really not that original. The sole difference between their approach and ours is that when they add new language features to JavaScript, they’re not taking the extra step of introducing new syntax. Don’t believe me? Take a quick look at an example right out of the Prototype tutorials:
// when subclassing, specify the class you want to inherit fromvar Pirate = Class.create(Person,
{
// redefine the speak methodsay: function($super, message)
{
return $super(message) + ', yarr!';
}
});
What we’re seeing here is the introduction of classical inheritance to the JavaScript language. This has always traditionally been a language feature, but due to its absence in JavaScript, the folks at Prototype have chosen to make it a library feature. The important thing to realize here is that it requires as much work to learn about the Class function as it would to learn about a new class keyword. And the same is true of Dojo:
dojo.declare("Employee", Person,
{
constructor: function(name, age, currentResidence, position)
{
// remember, Person constructor is called automaticallythis.password="";
this.position=position;
},
login: function()
{
if (this.password)
alert('you have successfully logged in');
else
alert('please ask the administrator for your password');
}
});
Once again, dojo.declare might as well be a new keyword since its shoehorning classical inheritance right into JavaScript. The jQuery UI widgets do something very similar to this with the “widget” factory method:
$.widget("ui.sortable", $.extend({}, $.ui.mouse,
{
_init: function()
{
var o = this.options;
this.containerCache = {};
this.element.addClass("ui-sortable");
//...
At the end of the day, it doesn’t really matter if you’re a JavaScript expert, all these libraries have quite the learning curve and if its your first time with any of them, you’re going to have be referring to documentation a lot. And that’s not a bad thing. My point is simply that in JavaScript, more so than anywhere else, libraries need to first define what is essentially a new mini-language before they can begin to do anything useful. This is a bit unfortunate, because it ends up tying language additions to library features, despite there being no necessary connection between the two. This makes it particularly hard to use the different libraries together in an efficient way. Sure, you can use all three in the same project, but there are some clear walls between them since each one decides to do classes a little bit differently. Not to mention the fact that you now have pretty redundant code your site. This is what happens when a language is clearly missing features. Individual frameworks in the .NET, Objective-C, Java, and so forth world don’t suffer from core incompatibility in the way they choose to do something as fundamental as defining class hierarchies. This is part of the reason we built Objective-J as its own standalone entity. If all you want is some of the cool language features that Objective-J adds (without any of the design patterns in Cappuccino) then you can just use Objective-J, there is no “all or nothing” contract.
OK, so how is Objective-J different?
As we’ve now seen, there is a general tendency to add language features to JavaScript. Now, in my personal opinion, I prefer language features as fundamental as these to be part of the syntax, not part of a library. Let’s look at what Objective-J inheritance looks like:
To me this code reads a little more naturally, and at the very least it’s no harder to pick up than the numerous library functions required in the other libraries. This approach also has the added benefit of making it absolutely trivial to write new syntax modules so that my text editor of choice can actually know what is going on in my code. You’ll also notice that creating a new syntax gives us great flexibility and allows us to add a few nifty features that wouldn’t otherwise be possible, such as optional static typing and code importing. But again, this isn’t as “out there” as some people would have you believe. It has even more benefits as we’ll soon find out, but before we do, let me answer the question that I’m sure many of you are asking right now:
Why Objective-C style syntax?
Again, we didn’t start off saying “lets port Objective-C”! In fact, our first versions of Objective-J looked very similar to Java or C++:
However, this approach had some serious issues. To better understand them, we have to take a look at what the principal design goals of Objective-J actually were:
First off, it had to be a strict superset of JavaScript – meaning all existing JavaScript had to work. Believe it or not, we do like JavaScript, and we didn’t want to break it or create a trade-off of features. Not to mention we wanted the existing plethora of libraries to still work.
Secondly of course, we wanted to add a number of “key” features. Some things as crucial as being able to import code and built in support for classical inheritance. We also wanted some features inspired by languages like Ruby, such as method_missing.
And lastly, we wanted to keep the ease of use of JavaScript, which meant not adding an extra “compilation” step, but instead allowing developers to still pound out some code and hit refresh and see it run.
The problem with adding language features in a way that would be more “familiar” to most developers, like the Java approach above, is that it would break backwards compatibility with existing JavaScript. This is because a lot of the keywords we wanted to use are actually reserved words in JavaScript, despite not being currently used. There is good reason for this though, because at some point they may actually mean something, and we wanted to make sure Objective-J kept working when JavaScript (finally) got a real update. Of course, we could have just chosen different keywords, like “Class” instead of “class” for instance. This however also breaks backwards compatibility because someone may have used the Class identifier in their code already.
The other problem with this approach is that it made it next to impossible to add harder features like optional static typing or dynamic dispatch of methods (thus allowing for method_missing) without having a full blown compiler. There’s no way to “intercept” a method call in JavaScript. So once again, we were stuck.
Luckily for us however, a group of people ran into these same issues about 25 years ago when trying to improve the C language. These were the folks at Stepstone who developed Objective-C. Just like in our case, Objective-C had to be a strict superset of C (unlike C++ which does NOT always play nice with C). Also lucky for us is that JavaScript syntax is very close to C syntax, so their language additions translated very naturally to JavaScript. And perhaps now it is obvious why our keywords start with the “@” symbol, because in this manner there is no possibility of ever clashing with future JavaScript keywords or predefined user variables and functions. In other words, we can now add to the language as much as we want without the fear of breaking compatibility with existing JavaScript.
Similarly, the new method passing syntax allows us to have firmer control of how messages are sent:
object.jsMethod();
[object objjMessage];
This is the famous bracket syntax. What you may not realize is that this makes it perfectly clear when you are using Objective-J style message dispath, allowing us to “hook in” and add things like method_missing, etc. There are a whole bunch of other cool things that this enables which are outside the scope of this post, but I encourage you to check out the other tutorials on our site to learn about them. All this, without breaking any existing libraries and without requiring the user to compile before every run. Pretty impressive for a langauge that is supposedly “completely different” from JavaScript.
The Part About Leaky Abstractions
On top of Objective-J, we’ve built the Cappuccino framework, which is designed to help developers write desktop class applications on the web. One of the many things Cappuccino does is “abstract away” the DOM, and I’ll get into why we do this in a moment. But before I do, I think I should take a second to address this whole “leaky abstractions” business, because there seems to be a fair bit of confusion regarding this as well. If you haven’t already read it, or even if you have, I recommend you take a look at Joel Spolsky’s original article on the subject.
When people refer to this article, it is usually to criticize some “abstraction” because it will “inevitably” be leaky, and then oh boy you better watch out! But this was not Spolsky’s thesis. He didn’t end the article with “and thus avoid abstractions at all costs”. He was not somehow suggesting that we stop abstracting altogether. Quite the contrary, its clear that although these “leaks” are an unfortunate and unavoidable consequence, abstractions are still incredibly worthwhile: hence the conundrum. In every single example given in the article, it was never implied that the abstraction was somehow bad or invalid because of its leak: Just because certain SQL queries are slow doesn’t mean you should manually read in tab delimmeted files and scan them yourself. Just because TCP can fail if you unplug your computer doesn’t mean you should do IP transfers yourself. It just turns out that, big surprise, nothing is perfect. Joel put it best himself:
Indeed, the abstractions we’ve created over the years do allow us to deal with new orders of complexity in software development that we didn’t have to deal with ten or fifteen years ago, like GUI programming and network programming.
And the truth of the matter is that the problem of leaks is overstated. I find it particularly hilarious when JavaScript programmers bring this up, since JavaScript, being a garbage collected dynamicinterpreted language, is quite possibly one of the biggest abstractions of all. And yet, most of us can see that the benefits of JavaScript far outweigh the “leaks”. I think few JavaScript programmers have had to learn “the whole stack” once they’ve encountered one of JavaScript’s many leaks, whether it be performance issues (from being interpreted) or perhaps large memory consumption (from being improperly garbage collected in some browsers). No one has had to go and open up WebKit’s source code to figure out these problems. Most of the time you simply Google your concern and learn the workaround. Not that big a deal.
Leaks are just something we all have to learn to deal with in every facet of programming, because programming is abstraction. Abstraction is basically all programmers ever do, from pushing electrons across a wire, to turning C into assembly, to interpreting JavaScript in your browser, every step in computer science has been an exercise in abstraction. There is nothing inherently wrong with abstraction. I can understand if someone disagrees with a particular abstraction for well defined reasons, but simply waving your hands and referring me to the law of leaky abstractions is not a valid argument.
To suggest that we shouldn’t abstract because of Joel Spolsky’s Law that all abstractions are inherently leaky is to suggest that we shouldn’t debug because of Murphy’s Law that all code will remain inhrerently buggy.
Back to Cappuccino and the DOM
Cappuccino doesn’t just abstract away the DOM, it abstracts away HTML, CSS, VML, the JavaScript DOM API, etc. Why? Because as you can see there are just too many technologies with overlapping responsibilities. It’s never really clear whether you should create a button in HTML or in JavaScript code, and whether you should style it in a CSS files or apply styles manually in JavaScript, or whether you should just use Canvas to draw everything. Not to mention that on top of having to sort through all these technologies, you have the additional challenge of having to accomodate for every slightly different flavor that exists in every browser. Sometimes its relatively simple, but othertimes it can be quite complex, as is the case with Canvas and VML. The other problem is that these technologies were simply not originally designed to handle the tasks they are now performing. HTML was designed for laying out documents, not creating applications.
We look at these technologies completely differently. To us, HTML, CSS, Canvas, the DOM, etc all represent the “rendering engine” of the web, in the same way that graphics cards are the rendering engines for your computer. It’s too difficult to learn the intricacies of every graphics card on the market, so developers instead use technologies that hide these details like OpenGL. In the same way, Cappuccino defines a common way to “draw” for the web. Internally, it figures out whether its more efficient to make a div, or draw to a canvas, or use VML. This is a fantastic time saver today, because it allows Cappuccino to worry about things like performance and allows you to just get a button on the screen. But its going to be even better as time goes on. This is not only because the underlying code will get better, but because web applications today look like this:
But tomorrow, when enough browsers finally support SVG, they may look like this:
Or, for all we know, like this:
The important thing is that when this happens, and it will eventually happen, people who invested heavily in todays technologies will have to spend a great deal of effort updating, but we will just swap out the guts of Cappuccino and your code will inherit the benefits of SVG or whatever new technology is out there.
Conclusion
To me what we’ve done with Objective-J and Cappuccino seems inevitable. Even the most conservative major JavaScript libraries can’t get away without adding features to the language, and we’ve simply taken the next logical step with Objective-J. Similarly, Cappuccino is a tool that allows you to stop thinking about web pages and browser incompatibilities, and instead focus on the complex problems presented by the challenge of creating full-on applications on the web. As we’ve said countlesstimes, Cappuccino isn’t for everything. All of this abstraction isn’t necessary if you’re simply trying to add dynamic elements to a site like bankofamerica or digg. Cappuccino is for building rich applications in the browser, a small minority in the web world today. We believe that this is where things are headed, and we designed Cappuccino specifically to get us there.
