Cappuccino (YC Winter 08) Brings Cocoa-Like Programming To The Web
techcrunch.comSo, in order to layout an interface you programmatically create it? And so a designer has to learn yet another language for layout?
We made the mistake of adopting GWT a while back and it's been nothing but headaches.
Now instead of the designers being able to directly design in HTML (which they all have a familiarity of), they're required to download our entire project, edit the layout classes, recompile, just to see their work.
We've tried to have the developers take the designers mockups and translate them into working code, but the app seems to lose that designer "touch" in the process.
Designers need to be able to work with a familiar canvas.
In Cocoa you use Interface Builder to "draw" the UI. Does Cappuccino have its own IB equivalent?
BTW, do desktop GUI apps have non-programmer designers?
BTW, do desktop GUI apps have non-programmer designers?
Well, not non-programmers, but programmers who know the particular layout libraries of the platform better than the programmers writing the data access layer, for example. I'm not saying this is universally true, but when I worked for a larger team focuses on a single product, that's pretty much how it worked.
In Cocoa you use Interface Builder to "draw" the UI. Does Cappuccino have its own IB equivalent?
I was under the impression that part of the point of copying cocoa was that you can use the Cocoa IB to make Cappuccino UIs, also. I would be cool, but I might be wrong.
We've got a couple things we're working on to address this. There's already some hints in the public repository... (look for stuff about "NIB"s)
I agree about Google Web Toolkit. GWT is, at best, a way for hidebound Java programmers to feel comfortable making interfaces for the web. I have not looked at Obj-J very closely, but it seems like the same thing: a way to give Mac programmers a way to express themselves comfortably on the web. Encouragingly it looks a lot more fluid than a Java mudball.
It may also be a better and more compact way to build "rich" web apps, but that remains to be seen.
"it seems like the same thing: a way to give Mac programmers a way to express themselves comfortably on the web."
As a designer, every time I've seen Obj-J, I've thought about it being possibly useful as a bridge in the other direction: as motivation to learn Cocoa and go from the web to desktop and iphone.
I've been interested in developing native OS X apps for a while but haven't had the time or inclination to pick up a set of skills that are parallel and disconnected from web development, so finally being able to develop in a similar language for multiple platforms is very enticing.
Personally, I wouldn't mind letting go of the html/css if I could get pixel perfect precision in a different manner (can you get do that with Cappuccino?) that would also translate across platforms. I don't care about recycling skill sets - it's not like I can 1) use stylesheets on native apps today, other than for gimmicky crap like Dashboard widgets, or 2) will forget the html/css that's been hammered into my brain over the years, especially since I'll still be using it for informational and content-centric websites as opposed to web apps.
That's because a GWT app is not a web page. It's an application. In order to create a GUI for it you will need to be able to work with components and events, the same way you construct a desktop application, which was always the domain of programmers.
I assume Cappucino is targeting the same type of next generation web applications.
"And so a designer has to learn yet another language for layout?"
I've pretty much had to do that already to work with Flash. That's been a pretty limiting sandbox - we've been hearing "next year is the year Flash finally goes big on mobile and desktop" for a few years now, even from my buddy at Adobe on the Flash Light team - so I'm much more motivated to pick up a parallel set of skills for something that would be actually useful in the present day for something other than web development.
There is a GWT project for this very purpose (html template), but it's as simple as RootPanel.get(id) to get an element from a page. What's so hard about that? It works just like wicket.
COBOL was a familiar canvas at one point.
Designers were writing COBOL?
So was Fortran but I don't see anyone building web frameworks on top of it.
Honestly I need to dig more but I'm not sold on this route. Creating a new abstraction layer (Objective-J) on top of Javascript seems like some Architecture Astronautics to me. Why not just write this on top of JS (maybe with something like jquery?) Sites down right now or I'd try to make a more reasoned statement but sproutcore seems a better alternative.
I also wouldn't rule out Google rolling out something similar as well as they unify the widgets and windowing type stuff they've got from docs and spreadsheets (and Zenter for that matter).
Yeah, I think I'm one of those developers that will never grasp the need for things like this.
Then again I've been in a text editor for the past seven years and have just recently started developing in Objective C (I'm about half way through "Cocoa Programming for Mac") and I must admit that I was impressed with the intuitive nature of building applications in Xcode and Interface Builder.
I'm still amazed that they pulled it off. I loved Objective-C when I first learned it a few years ago and loved it even more when I wrote a few apps with it. I'm glad that its essence (in Objective-J) is gaining more traction.
Random notice/question: Since V8 is increasing the efficiency of property references for JS objects via hidden class objects, does that mean that Cappuccino's message routing will gain a huge speed increase?
Man, I just love the circular nature of this: ex-Smalltalk developers wrote the JavaScript implementation which in turn, will run Smalltalk-like message passing.
With Safari (especially with the offline features in Snow Leopard) and now Google Chrome, we have the browser technology to make rich, desktop-like webapps built with Cappuccino and Sproutcore shine.
I think this marks an evolution of web interfaces. I'm exited to see what people build using Cappuccino.
I think this marks an evolution of web interfaces. I'm exited to see what people build using Cappuccino.
I don't think mimicking desktop UI's counts as "evolution".
Actually, I think it does. Desktop UIs have evolved and are designed for interaction, and web UIs have evolved for display of information (that is, until very recently). There are no universally common standards for interactive controls in web UI elements as there are for desktop apps.
Obviously, webapps should not copy desktop UIs entirely. But any evolution of web app UI toward better interaction is certainly good for everyone. And because desktop apps have had a lot of time to evolve efficient interaction controls, mimicking them shouldn't be a bad thing.
I'm looking forward to spending my weekend with Cappuccino. My main desktop product is developed in Cocoa, but I'd like to expand it onto the web and the iPhone. Cappuccino looks like it might handle the web side of that quite well.
I tried Sproutcore, and while I'm impressed with what's been done so far it takes me several days of working on it to shift into Javascript/HTML/CSS mode from Obj-C. Hopefully with Cappuccino it'll be more like porting the app than rewriting the app.
[Edit to clarify]
I've just spent some quality time with Cappuccino - and it's not hyperbole - it's that good. I'm much more enamored of the 100% javascript approach than Sproutcore's impedance mismatching between client, server and intermediate "compiler". And all this love despite the obj-c square brackets!
Congratulations, 280 North! What a contribution.
I have to say, it looks very impressive. I am sure that this will spur new development, and with Chrome having a very fast JS engine putting more JS on the client side is more feasible.
Prediction: With Chrome + tools like Cappuccino, web apps are going to look completely different within a year. They'll be at least indistinguishable from desktop apps, and probably better (since desktop apps haven't had a lot of evolutionary pressure lately).
It looks interesting, but it seems to have a while to go. I've been trying to make a presentation at 280slides now and it's hung several times, and messed up the slides too. Maybe not the API's fault, but not very comforting...
I've not used Cappuccino and have only tooled around with SproutCore, but I tend to agree with the SproutCore philosophy.
http://www.sproutcore.com/2008/05/01/another-reason-not-to-c...
http://www.sproutcore.com/2008/04/22/emulating-cocoa-in-java...
While Cappuccino gives me the ability to dip into JavaScript if needed, it means I have to be proficient in Obj-J, JS, CSS, HTML, DOM, ...
That said, it is very impressive and I think competition for the "cocoa of the web" will improve both projects.
It doesn't really mean that, no. You don't need to know any CSS, HTML or DOM to get started in Cappuccino. If we've done our jobs right, you'll never need those things unless you're doing seriously advanced hacking (and even then, only in rare circumstances).
Sproutcore, on the other hand, really does need you to be an expert in all of those technologies, plus its own, plus ruby helpers to actually put anything on the screen.
I guess I should be a little clearer. I am already an "expert" in CSS/JS/DOM/... (after spending years doing web stuff and then over a year as lead dev on Flock). I really like the languages.
I've not used Obj-J so I cannot say if I will like it as much as I like JS. The idea of cappuccino providing a cocoa for the web is great, I just wonder if it could have been done without requiring a "new" langauge
I look forward to experimenting with your framework though.
Kudos!
Objective-J is actually a fairly thin layer on top of JavaScript. It adds classical inheritance to JavaScript, not unlike what most JavaScript libraries try to do, except it cleans it up (IMO) with Objective-C style syntax.
Even SproutCore is resorts to preprocessing code to get syntax enhancements, like their sc_super(whatever) which is converted to arguments.callee.base(this, whatever).
Anyone know what a "from-scratch" learning path would look like, to build a simple web app in Cappuccino? (ie. what are the 'knowledge prerequisites'?)
I'm wondering whether only desktop developers will use this, or if it will be reasonable for web developers more familiar with PHP/Python/Ruby & HTML/CSS to pick it up and run as well.
This is a good place to start:
Thanks.. (the link was down earlier)
If you're more familiar with things like PHP/Python... etc, something like NOLOH (Not One Line of HTML) http://www.noloh.com might be better. Like Cappuccino, NOLOH allows you to write your application in a single language, instead of Objective-J, the language is PHP. Also, unlike Cappuccino, NOLOH is lightweight and on-demand, this means that it only loads the parts of your application that are currently in use, rather than compiling your entire application in the beginning. However, NOLOH is a server side platform, the opposite of Cappuccino, but this has the benefit of allowing your application to truly be written in a single language, rather than having to write parts of your application in Cappuccino, and other parts in your server language. I recommend watching the Hello World video in the features section of the NOLOH website to see what I mean.
"However, NOLOH is a server side platform, the opposite of Cappuccino, but this has the benefit of allowing your application to truly be written in a single language, rather than having to write parts of your application in Cappuccino, and other parts in your server language."
That argument doesn't really make sense, since you can run JavaScript / Objective-J on both the client and the server, but you can only run PHP on the server (though from what I understand you translate PHP to JavaScript?)
Objective-J runs on a number of JavaScript engines that can run on the server, including Rhino (check out the "objj" executable in the "Tools" package: http://cappuccino.org/download/). While we don't have a good web server solution yet, it's certainly a possibility.
But even once that is a reality, Cappuccino will be totally server agnostic, so it will work with whatever server side technology you are comfortable with (or stuck with)
NOLOH does not translate PHP to JavaScript, certain aspects of NOLOH use JavaScript, but no translation takes place. The 1.8 release of NOLOH will allow for your applications to run with or without JavaScript enabled.
The fundamental difference between Cappuccino and NOLOH is that unlike Cappuccino, GWT, Silverlight, Java, Flash, etc, a NOLOH application is not a compiled application living on your local machine, which means you don't download the entire application, rather it's lightweight and on-demand. Because of this you can write things such as Amazon.com in NOLOH, as well as things like 280Slides, all while having a smaller footprint, but maintaining a unified application lifecycle. This also has other benefits such as being able to modify your application while it's running, as seen in the Hello World video. See http://www.noloh.com/#/section=features for more information.
There will be Python and Ruby versions of NOLOH in the near future.
I recommend you play around with NOLOH a bit more before making these statements. Please note that I wasn't belittling Cappucinno in any way, I was suggesting that if he was more comfortable with things like PHP, Python, etc, that NOLOH might be a better fit for him, rather than having the equivalent of a thick client application.
An impressive piece of tech but I'm not really convinced this is a good approach, especially after comparing their photo demo with Sproutcore's (http://cappuccino.org/learn/demos/FlickrPhotoDemo/ vs. http://www.sproutcore.com/static/photos/) which suggests to me that Cappuccino has serious speed problems. The situation is likely even worse on old machines with older browsers as I'm on a relatively up-to-date machine using FireFox 3.
Incidentally, those are two of the Cappuccino developers in the first photo in the new slideshow on http://ycombinator.com (plus Patrick Collison of Auctomatic).
I don't really see how this is much different than the promise of ASP.Net (outside of the Mac vs PC argument) - Allowing programmers to create web pages the same way they create applications.
It's a tremendous pain in the ass and a failure for Microsoft as far as I see it.
Well, at the very least, ASP.NET is a server side solution, while Cappuccino is entirely client side -- it has no server side component.
How is being the #1 or #2 enterprise application framework a failure for Microsoft?
Because they're now starting to back the MVC framework more and more heavily, which is a return to developing web applications like web applications and not like client-server applications.
Just because they have a large amount of adoption doesn't mean they've done things the right way.
I'm not saying that ASP.Net doesn't have a huge level of adoption, because it does. I am saying that they are seeing the problems with the idea of web applications just like client-server apps.
To be 100% clear, I mean that the concept of developing a web application just like it's a client-server application is a failure. Not the Asp.Net stack which is very clearly not.
Very excited about this release!
Official Cappuccino site: http://www.cappuccino.org/
Download link: http://cappuccino.org/download/
Dude. Lets give them a little break already!
git clone git://github.com/280north/cappuccino.git
Congrats guys. Of all of the YC startups that I've seen come through you've been the ones that I felt had the most potential to be a truly disruptive technology.
Hm, yet more evidence that I should be working harder on learning Objective C.
I don't know much about their product, but if I were an investor I'd have a hard time not wanting to fund hackers like that.
If I'm ever an angel, I'll probably have a "write a framework? here's your check" policy.
Interesting, I like building tools, but when it comes to a startup, I would be more cautious if a team came to me with their own framework...
Was all the time spent building the framework worth it because they have new capabilities or was it NIH syndrome?
I've kept away from commenting on this one, because I can't tell. But let me let my thoughts out:
Frameworks are a tough thing to do as a business. People tend to flock to use mostly one. Learning a framework is a big decision, and a big time and money investment. A framework needs to be compelling to make anybody want to use it for serious stuff.
The key motivators are default, money and laziness. Let me give you an example:
- I know MFC because it's the default framework on Visual Studio - I use Django because it allows me to be lazier than if I use PHP. Also, I figure my python knowledge may make me money in the future - I use jquery because the availability of plugins means that I don't need to write those stuff myself - I plan to learn to use the iPhone SDK because there is money there
I don't want to use Lisp or Fortran or any of those smaller languages/frameworks because they offer me nothing.
I would only use your framework if it fulfilled on one of the criteria above. Right now, it's really not clear. Will it make my development work faster? Will the resulting applications be better? I can't tell, so instead of wasting 2 weeks finding out, I'd rather just close the page.
i remember hearing about cappuccino a couple years ago when i was at usc (arcaeum?). congrats guys.
Wow. I'm impressed someone could remember us for that long! Especially with such a terrible name!
i like to think that i have a good memory. :-) in all seriousness, it's nice to see other usc people making cool stuff up here. i think it's hilarious that my company is also named after a road. man, scary stuff.
What's the best practice for communicating back to the server?
Is it data = [CPURLConnection sendSynchronousRequest:"http://myUrl"] ?
Is my head in the cloud, or would this work great with Chrome's 'Create Application Shortcut', or Mozilla Prism? :)
I admit that's the first thing I tried when I got Chrome. 280slides.com works quite well in these types of things. "Plainview" on OS X is particularly good for presentation software and other apps that benefit from full screen viewing.
This is very impressive from a tech perspective, but what exactly does it have that native Cocoa apps don't?
A browser window.
This is a Javascript wrapper, which means that browsers can execute it. Browsers can't execute Objective C.
I'm not sure why these people felt they needed a wrapper around Javascript, which already has it's own fairly dynamic object model, but meh.
[edit: elaborate a bit]
Is 280 North a reference to Beverly Hills Cop II?
Or is it my lack of cultural awareness?
I thought so too, but the club in the movie is 385 North
You guys are awesome.