Cappuccino developer conference(cappcon.org) |
Cappuccino developer conference(cappcon.org) |
That's the major thing that would stop me from using Cappucino over SproutCore... I don't mind learning a new language if there's a compelling need for it, but I just don't see the point here. I'd love to be proved wrong though.
Also, objj is an extension to js, so "learning" it is not some monumental task, kind of like learning the latest additions made by ecmascript 5.
I think there's a tension right now in the web platform community about whether we're in the post-HTML+js world yet. Cappuccino, GWT, jqueryui, etc are all moving in that direction. But there's a tension between libraries that want to treat HTML+js like dumb rendering layer, and libraries that keep HTML+js as the developer-level workspace, and just extend it by adding API.
There are a lot of things that work really well in HTML+js (links, urls, scrolling, etc) that get screwed up as you add more post-HTML widgetry. So the developers of post-HTML tools eventually end up rewriting everything HTML did in their new toolkit. The toolkits get better and better, but I have yet to see one that didn't break something that HTML did well.
So it becomes an either/or proposition. Either I jump fully into Cappuccino, accept that it will break things about HTML and I will not be able to fix them, or I stay in the land of HTML, and I try to implement the cool stuff Cappuccino does (windowing, OO, advanced widgetry, etc) with HTML+js and whatever JS libraries I can find, but generally sick with The HTML Way wherever possible.
The thing is, I know what HTML sucks at. I have no way to know what Cappuccino breaks that HTML does well until I am waist-deep in a Cappuccino app. I think that makes it hard for me to jump.
And so my preference (although it's just a preference) is for small tools that add one thing to HTML+js, but they do it really well. So if I want to make a mobile app for iPhones, I want to start with a JS library that lets me make touch-slideable panes, that's incredibly fast and smooth, and that's it. I don't need it to create a whole complex windowing model, or re-implement HTML buttons in javascript, or anything like that.
But I feel like the tide is slowly turning... the post-HTML frameworks are getting better. At some point one will be good enough that I really can leave HTML behind. Maybe I'll try out Cappucino for my next weekend project and see how it goes.
Cappuccino the framework is open source.
Objective-J is just a language that adds what we consider to be a lot of nice things to JS. You can use it and still keep HTML/CSS/etc (much like you would use CoffeeScript). Similarly, you can use it to, say, write command line apps for the terminal and never touch any web technology at all.
Separately, there is Cappuccino. I do not personally believe the situation to be either or (or not necessarily anyways). I think HTML and CSS are very powerful tools, given the right task (presenting documents). However, if I wanted to write super mario brothers, I would not miss lists and links, but would want strong graphical abilities. HTML has basically conceded this by adding the canvas element (which if you think about it goes against everything HTML is about -- semantic meaning). In the end, you should use the best tool for the task. For example, our GitHub issues app builds its chrome using Cappuccino, and displays the actual bug report as an HTMLView. No re-implementation of all of HTML, just literally loading HTML when we want it (Similar to how Mail's chrome is Cocoa, and the actual mail message rendering is an HTML WebView).
And, as you say at the end, of course it is only a matter of time until everything is "post HTML/JS". The fate of every language or framework is to either die or to be built on top of and abstracted away, there is no "last technology".
Interestingly enough we started working on NOLOH in 2005, and released it to the public in a beta in 2008, and wide-release in 2009. One of the core premises of NOLOH, was that it should not break your existing HTML, JS, CSS, if you choose to use it, but rather allows you to incorporate it nicely while allowing NOLOH take care of the messy plumbing, such as race-conditions, syncing, etc. Even though, you can still use 3rd party tools, widgets, etc, without necessarily doing everything the "NOLOH" way, which might be similar in feel to the GWT way, or Cappucinno way, there's always resistance from those that feel that somewhere, somehow, some legacy thing will break and they won't have control over it, which is never the case in NOLOH, as even in a worst case scenario, everything is easily overrideable and customizable, but the problem still persists. So, now in 2011, where the proliferation of browsers and mobile devices each with their own set of quirks and issues, make something like NOLOH even more necessary, how do you get people to take the plunge to a development platform, whether it's NOLOH, or something else, that handles all the things that computers can do very well, and allow the developer to develop and focus on their application? This is especially frustrating, as I use Opera as my primary browser, and almost every day I'll encounter some site, or web app from some big co, or small development shop that doesn't work in Opera, and if they were using NOLOH, or something similar, this would never happen. There's just no reason for a modern browser to not work in a form submit (looking at you Crysis 2).
Interestingly enough the least resistance is in businesses, enterprises, and small developer shops, with the most resistance among individual developers and the "elite", who I feel have the most to gain. However, we have observed that when this particular group does take the plunge, usually after spending a significant amount of time researching, playing around, etc, they become very dedicated to the tool, and can't imagine developing without it. The problem then is when do we reach that tipping point, where no longer will you have to read how to x,y, or z, in HTML, JS, etc, or spend hours fighting with yourself over whether you should use a particular tool and allow the platform makers to worry about it, while you worry about your application.