Cocoa and Objective-C: Up and Running (by me) is now available from O'Reilly.

First Look at Cappuccino and Objective-J

You've probably heard of 280 Slides, which is an exceptionally polished Keynote-like presentation app for the web. The creators, 280 North, today published the framework and language used to create it, called Cappuccino and Objective-J, respectively. I only had a few hours to play with both, so keep in mind this is a very early review.

The executive summary is that Cappuccino is re-implementation of many of the basic parts of Cocoa, and Objective-J is a language which looks nearly identical to Objective-C and "compiles down" into JavaScript. You can also use JavaScript right inline with Objective-J, similar to how you can use C in Objective-C.

Mac OS X Leopard has 82 built-in frameworks, and Cappuccino implements portions of only two of them: Foundation and AppKit. There is an implementation of certain data structures of Core Animation as well, but I think it's misleading to call it a port because there's no OpenGL underlying it so none of the fancy 3D effects are available.

There is a lot of one-to-one mapping of common classes, such as CPString being equivalent to NSString, CPTextField being equivalent to NSTextField, and so on. Some of the CoreGraphics/Quartz API is implemented as well. Browsing the Cappuccino class documentation gives you a pretty good idea of what's going on. 280 North has done an incredible amount of work here.

That said, you generally won't be able to take a modern, multi-framework Mac app and "recompile" it for Cappuccino. Some small apps might be able to pull it off with a bit of renaming and reshuffling, but any moderately complex app would be stranded. As a simple example, there isn't a CPTableView, but there is a CPCollectionView, which I assume is close to NSCollectionView.

This isn't a knock against 280 North — all of this is really, really difficult to do. It's just important to understand that this doesn't mean all Mac apps can suddenly run on the web.

What it does mean is that Xcode and Interface Builder are now reasonable prototyping tools for web apps based on Cappuccino, and Mac programmers can now quickly become very effective client-side web developers. The transition is somewhat similar to developing for iPhone — fundamentally similar concepts, but a slightly different inventory in the utility belt.

What's most shocking initially is how practically anyone could mistake Objective-J for Objective-C:

@implementation AppController : CPObject { }

- (void)applicationDidFinishLaunching:(CPNotification)note
{
    theWindow = [[CPWindow alloc] initWithContentRect:CGRectMakeZero()
                styleMask:CPBorderlessBridgeWindowMask
]
;
                                            
    contentView = [theWindow contentView];    
    var label = [[CPTextField alloc] initWithFrame:CGRectMakeZero()];    
    [label setStringValue:@"Hello World!"];
    [label setFont:[CPFont boldSystemFontOfSize:24.0]];    
    [label sizeToFit];    
    [label setAutoresizingMask:CPViewMinXMargin | CPViewMaxXMargin];
    [label setFrameOrigin:CGRectMake(100,100)];
    
    [contentView addSubview:label];
    
    [theWindow orderFront:self];
}


@end


If you change the @implementation line and rename everything from CP to NS, this would probably compile as Objective-C. In my experiments, I did run into some obvious missing methods, such as +stringWithFormat:, but a ton of it is already here in the first release.

As a Cocoa/Objective-C programmer, it's easily to forget that you're writing a web app. For example, here's some code I wrote today to make a draggable box (a subclass of CPView):

- (void)mouseDown:(CPEvent)event
{
   mouseDownPoint = [self convertPoint:[event locationInWindow]
                              fromView:nil
]
;
}


- (void)mouseDragged:(CPEvent)event
{
    var newPoint = [event locationInWindow];
    newPoint.x -= mouseDownPoint.x;
    newPoint.y -= mouseDownPoint.y;
    [self setFrameOrigin:newPoint];
}


Other than replacing CPEvent with NSEvent* and var with NSPoint, this is, verbatim, how you'd do it in Cocoa. You don't have to think about any sort of DOM queries or JavaScript of any sort. For Mac and iPhone developers, this is beginning of something very big.

One question that occurred to me immediately is how to incorporate server-side frameworks into the stack. Cappuccino is, after all, a client-side framework, so you'll need need a separate server-side piece (more on that here) in most cases. I haven't had much time to look at this, but the Cappuccino Flickr demo seems to use an asynchronous JSON request to fetch data and display it as it arrives. I'll need to spend more time with it to figure out the details.

One side note here: Cappuccino seems to like to take over the whole browser window. I experimented with adding my own bare CSS-styled DIVs at arbitrary locations in the canvas and I didn't have a lot of success. Not sure if this is by design I was doing something wrong. The documentation does make it clear that Cappuccino is intended to create web-based applications, though, not web pages.

The biggest technical hurdle right now is the size of the framework. The AppKit implementation is 18k lines long, and Foundation is about 5k. When I asked the 280 North guys about this earlier in the year, they seemed to think server-side compression was a reasonable solution. This isn't my area of speciality, though, so I can't really comment on it.

A few quick things I figured out today:

  1. The coordinate system appears to be "flipped" by AppKit standards, so the origin is in the upper-left.

  2. Even though the APIs may have the same names, they may not behave the same. For example, [view setWantsLayer:YES] isn't enough in Cappuccino. You need to actually instantiate a CALayer yourself and add it to the view.

  3. Cappuccino seems to intercept all key events by default, so I found ⌘-N wouldn't open new windows in Safari with a Cappuccino app running in the window

  4. The syntax is currently Objective-C 1.x, so none of the new 2.x syntax is available


One last note: there are a set of tools provided to improve the development process, including a pre-interpreter (basically a compile-to-JavaScript tool) and plug-ins for TextMate and SubEthaEdit.

Overall, a very big day for Cocoa and iPhone developers looking to deploy web apps. Major kudos to 280 North.
Design Element
First Look at Cappuccino and Objective-J
Posted Sep 04, 2008 — 46 comments below




 

Keith Lang — Sep 05, 08 6332

Thanks Scott for the useful overview.

Na´ve question from someone who doesn't code; how does this compare to Sproutcore in general?

And would it be possible to write something in Cappuccino and later 'port' it with reasonable ease to Mac OS X?

Keith

David — Sep 05, 08 6333

how does this compare to Sproutcore in general?

As I understand it, SproutCore is simply a Model-View-Controller framework for pure javascript, whereas the intention of Objective-J and Cappuccino is to mimic the syntax and drawing layer of Objective-C and Cocoa, while also being a MVC framework.

I think that Obj-j/Cappuccino apps will tend to have a consistent (beautiful) look-and-feel (like 280slides), where SproutCore apps will likely implement their own custom interface style (like MobileMe). I don't think many developers will release their production app with the default purple SproutCore interface style.

-d

Qwerty Denzel — Sep 05, 08 6334

Looks amazing.

As you say, the frameworks don't directly translate to Cocoa methods. So why bother keeping the C-style functions like the CG... set (CGMakeRect, etc)? People have complained about having to use Carbon and similar frameworks on the Mac, so why not use Objective-J for everything given the chance?

It'll be interesting to see if the language and frameworks evolve, or keep along the same lines as Cocoa.

Scott Stevenson — Sep 05, 08 6335 Scotty the Leopard

@Keith Lang: how does this compare to Sproutcore in general?

I haven't spent a significant amount of time with either, so I'm probably not the best person to answer that. From what I've seen, though, SproutCore is a true JavaScript-based framework using standard JavaScript syntax. SproutCore could potentially be useful to those who already know how to write client-side web apps, whereas Cappuccino and Objective-J would require some knowledge of Cocoa. This is pretty close to what David said above, with the additional note that at least some of SproutCore's API terminology (methods names and such) is taken directly from Cocoa.

Paradoxically, all of this actually gives Cappuccino a bit of leg up in the area of documentation, since a good portion of existing Cocoa and Objective-C tutorials apply here as well.

One other very nerdy point: so far, I haven't seen support for Cocoa Bindings in Cappuccino, but SproutCore features them prominently. It makes a big difference when writing desktop Mac apps, but I'm not sure yet how big of a factor it is here.

would it be possible to write something in Cappuccino and later 'port' it with reasonable ease to Mac OS X?

Sure. Just keep in mind that when moving the code to Mac OS X, you'd want to step back and reevaluate the application design since you have much more available to you in that context.

@Qwerty Denzel: As you say, the frameworks don't directly translate to Cocoa methods. So why bother keeping the C-style functions like the CG... set (CGMakeRect, etc)?

The CG geometry functions are basically identical to the NS geometry functions. So if you're not using CGRectMake(), you're using NSMakeRect() and ending up with effectively the same result. There are some regular C functions even in Cocoa.

But, in general, I do see your point. AppKit provides higher-level drawing abstractions using classes like NSBezierPath. I'm actually not clear yet on how paths work in Cappuccino. There's no mention of classes called anything like CGPath or CPBezierPath, so maybe the details of that are still being worked out.

Steven Degutis — Sep 05, 08 6336

@Scott Stevenson But, in general, I do see your point. AppKit provides higher-level drawing abstractions using classes like NSBezierPath. I'm actually not clear yet on how paths work in Cappuccino. There's no mention of classes called anything like CGPath or CPBezierPath, so maybe the details of that are still being worked out.

I talked to the developers on IRC last night as soon as the framework was made public, and apparently many of these classes are there (and with nearly full implementation), just not documented. They say the documentation tool is missing several files, which is understandable. I've looked into the source and CGPath and CGContext are very full-featured right now. I've been experimenting with the little time I have to try and get many of the CoreGraphics routines I normally use in Cocoa to work, but I had to stop early in order to prepare for C4[2] tonight. I hope this helps.

Also, I think it might be beneficial for many Cocoa programmers to use this framework in an entirely different way than shown off in 280 Slides. For example, my website http://www.giantrobotsoftware.com/ could benefit with some simple Core Animation to "expand" categories on the side and display the screenshot thumbnails in a Collection View, while looking pretty much the same as it is already. The regular user would notice no difference, except they might think "hey, this looks like one of those fancy Flash websites" due to how interactive it could be with CP behind the scenes. This is my plan, and I recommend it to any Cocoa programmers who don't have the time to learn JS or Flash to write a fancy site's client end.

Mason — Sep 05, 08 6337

Also, I think it might be beneficial for many Cocoa programmers to use this framework in an entirely different way than shown off in 280 Slides. For example, my website http://www.giantrobotsoftware.com/ could benefit with some simple Core Animation to "expand" categories on the side and display the screenshot thumbnails in a Collection View, while looking pretty much the same as it is already.

I think this is exactly what Cappuccino is not for. From the website:

Designed for Applications

Nobody will deny that there is a distinct difference between a web site and a desktop application. Similarly, we believe there is a big difference between a static web page and a full fledged web application. Cappuccino is designed for applications, not web pages.
...
Cappuccino is not designed for building web sites, or making existing sites more "dynamic". We think these goals are too far removed from those of application development to be served well by a single framework. Projects like Prototype and jQuery are excellent at those tasks, but they are forced by their nature to make compromises which render them ineffective at application development.

I think there's some general confusion about what exactly Cappuccino is. As Scott said, you won't be able to take your Mac application and have it magically run on the web. A lot of desktop developers (in particular) seem to be coming to Cappuccino with this expectation, and finding themselves disappointed that certain things are missing. It's already been asked on the mailing list if there is (or will be) something akin to Interface Builder and .nib files. While there's certain bits of code in the framework hinting that such a thing may exist (nib2cib or some such), I don't think that's the appropriate mindset to approach this framework.

I don't know of this makes any sense, but here's how I think of it: Objective-J and Cappuccino bring the niceties of Obj-C/Cocoa to web development more than it brings to desktop development the niceties of having your desktop app run on the web. As someone approaching this from the standpoint of a web app developer, I see Obj-J/Cappuccino as a tool to help me remove HTML/JS/CSS/Cross-browser compatibility from the equation, and help me focus on the app itself. I do not see it as an easy/simple way to bring my Cocoa applications to the 'nets.

Or, perhaps put more simply, Cappuccino is Cocoa in spirit, and not necessarily a web-clone of Cocoa.

Mason — Sep 05, 08 6338

I haven't seen support for Cocoa Bindings in Cappuccino, but SproutCore features them prominently.

I'm 99% sure Objective-J supports KVC/KVO. One of their crew left a comment on Ajaxian mentioning it, and I'm pretty sure he mentioned it in the podcast as well. They completely override JS's default observers, partially (I'm guessing) for this reason.

Leif Singer — Sep 05, 08 6341

I browsed the Cappuccino Git repository a bit and found several indicators for Nib support, e.g.:
var nib = [[CPNib alloc] initWithContentsOfURL:@"MainMenu.cib"];
Also, a folder called "NibApp", a folder called "HelloWorld.nib", and a script called "nib2cib.j" which seems to convert Nibs to Cibs.

It all still looks somewhat experimental, so all of this seems to say "Nib support will come" -- which leaves me in awe. If they can convert Nibs to Cibs, developers could seemingly use Apple's own InterfaceBuilder to layout their web applications.

Scott Stevenson — Sep 05, 08 6342 Scotty the Leopard

@Steven Degutis: I've looked into the source and CGPath and CGContext are very full-featured right now

Yeah, you're right. There's a wide range of CGPath functions in there.

For example, my website http://www.giantrobotsoftware.com/ could benefit with some simple Core Animation to "expand" categories on the side and display the screenshot thumbnails in a Collection View

As Mason suggests above, I think one of the existing JavaScript libraries like dojo or something would probably work better for that. Cappuccino might be overkill.

@Mason: but here's how I think of it: Objective-J and Cappuccino bring the niceties of Obj-C/Cocoa to web development

Well said.

I'm 99% sure Objective-J supports KVC/KVO

I see that comment as well, but I can't find the key KVO method names in the source, such as -observeValueForKeyPath:. Also, we'd still need the actual KVB implementation to make bindings work, but it does look like they're planning to do something here.

Joe — Sep 06, 08 6345

Hey Scott,

I remember a while back when you asked about generating colored code for web page examples and there were several responses. What did you end up doing in the end, if you don't mind me asking.

Scott Stevenson — Sep 07, 08 6346 Scotty the Leopard

@Joe: I remember a while back when you asked about generating colored code for web page examples and there were several responses. What did you end up doing

I generate it in TextMate, as described here. There are probably better options available now.

MySchizoBuddy — Sep 07, 08 6347

call me crazy but 280 North like a good acquisition target for Apple.

Zach Thomas — Sep 07, 08 6348

The biggest technical hurdle right now is the size of the framework. The AppKit implementation is 18k lines long, and Foundation is about 5k. When I asked the 280 North guys about this earlier in the year, they seemed to think server-side compression was a reasonable solution.

At the Cappuccino talk here at C4[2], Ross said that currently the frameworks will be ~100k compressed.

Joe — Sep 07, 08 6349

Thanks Scott,

I had missed that one. The code coloring came out looking really good, better than anything else I've seen on the web.

Nick Caldwell — Sep 07, 08 6352

(this is me, beating a dead horse again) I'm terrible at browsing API documentation but I can't see anything that indicates the framework hooks into an OS's accessibility system. If the Cappuccino application is entirely generated in the browser through complex javascript, I'd assume the result will simply be a blank page for a typical screen reader app. Not good.

Accessibility needs to be baked in from inception, not added as an afterthought. I thought that was generally understood by now, but instead it looks like we've got a whole new generation of rocket surgeons to educate.

The home page hype would certainly suggest that these guys want to become the kings of browser-based application development. They're not going to get far without support for legally mandated (in Australia, at least) accessibility support.

Scott Stevenson — Sep 07, 08 6354 Scotty the Leopard

@Nick Caldwell: I'm terrible at browsing API documentation but I can't see anything that indicates the framework hooks into an OS's accessibility system

I agree with you it's an important point, but I'm not convinced it's something that's really in the hands of Cappuccino itself. Mac apps are much more tightly couple to the physical computer and have specific Accessibilities APIs to work with, provided by Apple. A web app, on the other hand, is just providing content to the browser to interpret as it will. The browser is ultimately responsible for handing off the data to the screen reader software.

I'm not sure how browsers like Safari and Firefox go about being the bridge between page content and the OS-specific Accessibility API, but I'm certain it's something they have to facilitate. Cappuccino isn't in a position to talk to directly the Accessibility frameworks on Mac OS X.

Asynchronous page updates are a reality of modern web apps. It's how Gmail, Google Maps, MobileMe, and countless other online services work. It's not at all specific to a single JavaScript framework.

If the Cappuccino application is entirely generated in the browser through complex javascript, I'd assume the result will simply be a blank page for a typical screen reader app

This part puzzles me. Why does the complexity of the JavaScript matter at all to the screen reader. It's not actually running the JavaScript, is it? Is the issue in determining visibility? This is a completely open-ended question -- I'm truly curious about the answer.

Russell — Sep 07, 08 6357

It seems nice, but not as complete or robust as Google's implementation:
http://code.google.com/webtoolkit/

Nick Caldwell — Sep 07, 08 6358

Asynchronous page updates are a reality of modern web apps. It's how Gmail, Google Maps, MobileMe, and countless other online services work. It's not at all specific to a single JavaScript framework.

Yeah, my concern is that one of these frameworks becomes sexy enough that everyone starts using them, thereby sending the web back into the accessibility dark ages!

Asynchronous apps can be made to work in the context of an application designed with accessibility in mind -- but you have to work out ways of notifying the screen reader that things are happening after the page has finished loading. Part of that work may well involve lobbying the screen reader makers to pay attention to the fact that the web has evolved just a tad.

This part puzzles me. Why does the complexity of the JavaScript matter at all to the screen reader. It's not actually running the JavaScript, is it? Is the issue in determining visibility? This is a completely open-ended question -- I'm truly curious about the answer.

Well, it actually does depend on the screen reader, but my rule of thumb has been the screen reader reads what you see if you view the HTML source code -- anything generated at runtime after the page loads is beyond its scope. That's why the accessibility best practice is to develop the fully working app as pure HTML with form submits, etc., and then overlay the javascript to animate and asynchronise everything. Then a user with visual disabilities can simply turn off the javascript and work normally with the application.

The thing is, even Flash these days can be made to be accessible - the API has hooks available to the OS for screen readers, but you have to turn them on and work with them proactively. Pure javascript apps don't allow that right now.

Scott Stevenson — Sep 07, 08 6359 Scotty the Leopard

@Russell: It seems nice, but not as complete or robust as Google's implementation

I admit I haven't looked closely at Google's toolkit, but the obvious difference is that it's based on Java. The overall net effect is probably similar, but Cappuccino is based on the Cocoa design patterns and Objective-C language features.

Google's toolkit is probably a lot easier to integrate into existing web apps (or web pages?), and has a lower learning curve for those who already know how to write client-side web apps. Even if they know JavaScript, though, I think many existing Mac programmers would probably prefer the Cocoa-based solution. I do, at least.

Russell — Sep 07, 08 6360

@Scott: I think many existing Mac programmers would probably prefer the Cocoa-based solution. I do, at least.
I think you're right, mac programmers would definately prefer a framework based on their language of choice, Objective-C. I guess I was speaking as someone who develops both Java and Objective-C apps, and who has looked at both frameworks. The Google one I use day to do, and yes it integrates very well with existing pages, as I often use it to write small 'widgety' type components that sit somewhere on an existing page.

I guess having looked at both, my personal choice is GWT, for performance, size of deployed code, and robustness. It's nice to have a choice though. I'll leave it at that, otherwise I'm starting to sound like some kind of fanboy...

Scott Stevenson — Sep 07, 08 6361 Scotty the Leopard

@Nick Caldwell: you have to work out ways of notifying the screen reader that things are happening after the page has finished loading

I agree in theory, but I think you need to take your case to the makers of the screen reader apps and/or the browsers. The authors of JavaScript libraries really aren't in a position in enforce any sort of policy. They can feed metadata to the browser, but the browser has to be listening for it.

Based on my limited knowledge of plug-ins, it seems to me Flash is in a somewhat different situation since it's like a little app (a native plug-in) running on the computer itself. The plug-in already makes direct API calls on the client side. Adobe also defines both the format and the reader implementation. I haven't written a browser plug-in, though, so don't take this at face value.

That's why the accessibility best practice is to develop the fully working app as pure HTML with form submits, etc., and then overlay the javascript to animate and asynchronise everything.

Certainly that works when the app is form-centric, but there are many kinds of applications that don't involve the user inputing structured data in pre-determined set of text boxes. In those cases, I don't know if it's clear what to do.

rd — Sep 07, 08 6362

It is deja vu all over again.
Apple converted WebObjects from Objective-C to Java.
It could create Java Applications, Applets.
It had rule based editor. It had EOF and all key-value coding.

Few years later, we are doing the same bloody thing
just now with JavaScript. and this considered
progress and innovation.

NOT.

If you really going to do this what you really
need is a Webkit based custom client that acts like iTunes Store
because there is no way people will use this when normal browser
functions are disabled. That is not going to fly

Andr Pang — Sep 07, 08 6363

Scott, your comment about OpenGL made me wonder the possibilities if OpenGL were a standardised JavaScript extension. World of Warcraft in your browser? There'd be some pretty rich possibilities...

Scott Stevenson — Sep 07, 08 6364 Scotty the Leopard

@rd: Few years later, we are doing the same bloody thing
just now with JavaScript


I do see what you're getting at, but the Cocoa-Java client approach was a far more complex, heavyweight solution. For that reason, I'm not sure it was really ever intended to be deployed in the context of actual public web sites as much as internal admin/enterprise apps (though I could be wrong about this). From my memory, the suggestion was to use HTML-based interfaces for public sites.

I also think the Cocoa API greatly benefits from being hosted by a dynamic language, and the fact that Cappuccino is backed by JavaScript is essentially an implementation detail anyway. You're effectively programming in Objective-C.

because there is no way people will use this when normal browser
functions are disabled


Not sure what you mean. Could you elaborate? If you're referring to capturing key events, I just found out that's easy to disable.

@Andr Pang: if OpenGL were a standardised JavaScript extension. World of Warcraft in your browser

Don't see why not offhand, though OpenGL is just one part of the equation. I think you'd need access to a bunch of native stuff to get solid performance. Another option is to pre-render on the server side.

aaron — Sep 08, 08 6365

I was experimenting with cappuccino this weekend, I've been trying to develop an application to sit inside of a web based ECM environment. I also noticed that cappuccino seems to take over the whole window, which made me wonder if i could use it. (This is an enterprise application, I can't use cappuccino if I can't embed my application into a webpage). Turns out that this is relatively simple to do if you use an iframe. Kind of annoying that you have to do it that way -- but the framework seems to have the functionality that I'm looking for to build my application, so I'll grin and bear it.

Ross Boucher — Sep 08, 08 6366

Great post Scott.

@Nick

I think Scott makes the right point here; screen reader vendors bear the responsibility for reflecting the current state of the DOM, not just the static HTML. While I'd love to make Cappuccino as accessible as possible, only part of the equation can ever lie with the framework. And I don't think its in anyone's best interest to halt progress on pushing the boundaries of the web while we wait for everyone to catch up. I'm confident that all these things will come together over time. After all, Cappuccino is only a few days old.

Michael Stroeck — Sep 09, 08 6367

Regarding screen-readers I have to agree with Ross. The number of people using them is so vanishingly small that nobody can expect developers of completely new technologies to spend a lot of time on their issues, especially when venturing into territory where there are no hard rules yet. Unfortunately, it's up to the makers of screen-readers and their users to keep adjusting to the state of the art.

britt — Sep 09, 08 6370

Heh... I find it kind of ironic that the environment that hosted the first web browser is now being implemented inside the web browser...

It occurs to me that something that ought to be done is compiled code caching at the browser level; as the size of applications grow, I can see having to do a build of the app locally for every invocation of it starting to get annoying...

And, of course, somebody needs to whip up something IB-like.

About screen readers -- I just switched on Voice Over, and it doesn't read any HTML in FireFox 3 (no matter the site), but it mostly works in Safari, and I did try it on 280 Slides. The major issue that I found was that the large text boxes seem to be broken up by character (perhaps as an artifact of the glyph layout that Cappuccino is doing). The other smaller text in 280 Slides was read fine.

Michael Ellis — Sep 10, 08 6375

I've been an Objective-C developer on and off for about fifteen years, and still I have to say that Objective-J is a completely nutty idea. Objective-C is a great language, but it's not the language that's supported in web browsers, JavaScript is. JavaScript isn't perfect, but it's very dynamic and open to whatever extensions people want to write for it. Requiring people to write their applications in Objective-J instead of JavaScript means that Cappuccino will be ignored large numbers of web developers who might otherwise have considered it. As I said, I've been using Objective-C for fifteen years, and I know it much better than I know JavaScript, and even I don't think this is a smart idea.

Scott Stevenson — Sep 10, 08 6376 Scotty the Leopard

@Michael Ellis: Objective-C is a great language, but it's not the language that's supported in web browsers, JavaScript is

Objective-J translates the code into JavaScript, so the browser doesn't need to support it at all. There's also tool for pre-interpretting the Objective-J code (essentially, "compiling") ahead of time.

Requiring people to write their applications in Objective-J instead of JavaScript means that Cappuccino will be ignored large numbers of web developers who might otherwise have considered it

I'm sure the developers know that. Their main goal may not be to sway existing JavaScript developers, but rather to enable Mac and iPhone developers to take their expertise and write web apps.

britt — Sep 10, 08 6377

Actually, I suspect that their main goal is to build 280 Slides...

:-)

The thing that I don't like about just about any C based language is that it's function centric: foo(x,y,z); or myObj.foo(x,y,z); there's no context for what the arguments are. I much prefer the Obj-C way; and I might even extend it to function calls also: [fooWithWidth:x height:y depth:z]; (although having it as a class method does help reduce namespace issues).

'Course, if JavaScript is your thing, there's always SproutCore...

Scott Stevenson — Sep 11, 08 6379 Scotty the Leopard

@britt: The thing that I don't like about just about any C based language is [...] there's no context for what the arguments are. I much prefer the Obj-C way

I completely agree. Rails obviously does the same sort of thing using named hashes.

Tom Robinson — Sep 13, 08 6382

@brit: Heh... I find it kind of ironic that the environment that hosted the first web browser is now being implemented inside the web browser...

It occurs to me that something that ought to be done is compiled code caching at the browser level; as the size of applications grow, I can see having to do a build of the app locally for every invocation of it starting to get annoying...


(I'm one of the Cappuccino devs)

There are a couple things that address those issues. First of all, we can do the preprocessing once ahead of time right before you deploy. The in-browser preprocessing is mostly a convenience for developers.

Second, we're working on a way to share the frameworks across all Cappuccino applications, so you load it the firs time, and it's cached from then on (like how Google hosts Prototype, Dojo, etc)

britt — Sep 14, 08 6383

@Tom Robinson:

Second, we're working on a way to share the frameworks across all Cappuccino applications, so you load it the firs time, and it's cached from then on (like how Google hosts Prototype, Dojo, etc)

That's great, but I was thinking of actual compiled code, i.e., the x86 machine code that V8 generates. Keeping that around would also mean that the JavaScript compiler could run an optimizing pass over it in a background thread; and once optimized, the entire framework would stay that way and be optimized when the app is first launched.


In any case, this is an incredibly cool project, and I am most impressed by your mad skillz. :-)

andy — Sep 15, 08 6384

You comment: "Xcode and Interface Builder are now reasonable prototyping tools for web apps based on Cappuccino". Could you provide any guide / instructions on how to install Cappuccino IN the XCode folder scheme on a Mac - and get the XCode editor and Interface Builder to recognize the installed framework? I cannot find any reference to that here or anywhere else. Thanks. Andy

Scott Stevenson — Sep 15, 08 6386 Scotty the Leopard

@andy: Could you provide any guide / instructions on how to install Cappuccino IN the XCode folder scheme on a Mac - and get the XCode editor and Interface Builder to recognize the installed framework?

Hi Andy, I don't think this will work quite the way you're expecting. You could certainly make a blank project by going to Xcode > New Project and choosing Other > Empty Project, then just add the files manually. All Xcode will really do in this case, though, is hold the files for you. Another approach is to use Xcode's Organizer with Window > Organizer.

I'm also not sure what sort of value Xcode could add to Cappuccino development right now beyond basic editing, since a lot of Xcode's features revolve around gcc (or llvm) and gdb. In other words, what are you hoping Xcode would do for you? I don't think there's any way to use Interface Builder with Cappuccino right now, though I'm sure the 280 North guys would like to improve that at some point.

When I said "prototyping tools for web apps based on Cappuccino," I meant prototyping in the literal sense, not development. In other words, you can could create test apps in normal desktop Cocoa, then "port" them to Cappuccino.

Tom Robinson — Sep 16, 08 6387

@Scott Stevenson: "I don't think there's any way to use Interface Builder with Cappuccino right now, though I'm sure the 280 North guys would like to improve that at some point."

http://github.com/280north/cappuccino/tree/master/Tools/nib2cib

It's very incomplete / proof of concept at this point, but we are working on it...

Roger Purves — Sep 18, 08 6388

to Scott:

I tried the puzzle on my six-month old MacBook, and found the drag (of a piece into the empty square) very sluggish. I realize dragging is not required to play the game, but I wonder if dragging will work smoothly in the Cappuccino, Objective-J framework.

(I tested the puzzle offline. The processor is a 2.4 GHz Intel Core 2 Duo, with 2 GB of SDRAM)

Any comments appreciated.

Roger Purves

Scott Stevenson — Sep 18, 08 6389 Scotty the Leopard

@Roger Purves: I tried the puzzle on my six-month old MacBook, and found the drag (of a piece into the empty square) very sluggish

Hi, Roger. I don't think dragging is actually implemented in the puzzle app. The individual puzzle pieces just send a click action to the controller after a single click is completed. If there was dragging, you'd see references in the source to "mouseDown" or something like that.

Roger Purves — Sep 18, 08 6390

to Scott:

You really made me laugh at my own foolishness. As you gently point out, I was deluding myself.

I think it happened as follows. In general, I enjoy dragging more than clicking, and I think I dragged in earlier versions of the puzzle. So when I first tried this one, I dragged--or thought I did. The movement of the mouse pointer and the slightly later movement of the piece gave me the illusion of dragging. But, as you say, it was simply the release of the mouse button that caused the piece to move into position.

(Actually, the delusion went further. I discovered the single click on my own, and concluded the programmers had thoughtfully provided two ways to move pieces--the click or the drag. I was grateful for the latter option, because it better mimics the old plastic puzzles.)

Still, I would like to try an application (in the framework) which allowed a user to drag things. Then I could compare the quality of the drag (in the framework) with the quality of the drag on the OS X desktop.

Thank you for your quick (and tactful) reply.

Roger Purves

Scott Stevenson — Sep 19, 08 6392 Scotty the Leopard

@Roger Purves: Still, I would like to try an application (in the framework) which allowed a user to drag things. Then I could compare the quality of the drag (in the framework) with the quality of the drag on the OS X desktop.

Anecdotally, I can say that I've tried it and it works very well.

britt — Sep 20, 08 6393

@Roger ---
Go play with 280 Slides, the inspector "windows" can be dragged around. I just tried it in FireFox 3 and both the standard Safari and the nightly WebKit build, and it works fine in all three, but the smoothest is the nightly WebKit, with Safari a close second. This is on a 24" 2.0Ghz Core 2 iMac.

Chris Peters — Sep 27, 08 6409

Scott,

Do you know what kind of database support is available in Cappuccino. Since it is APPLICATION centric and not WEB centric per say, any good application needs a good database support, specially commercial one.

Today, we have lots of clients available on Leopard. Does Objective-J/Cappuccino has anything for database?

Thank you for exploring Cappuccino. Its very informational, as usual from you.

Chris

Tom Robinson — Sep 28, 08 6410

@Chris:

You have to remember that while Cappuccino is meant for creating applications, you are still developing for the web, not the desktop, so the requirements for database support, etc is different from desktop applications. All communication with the backend must occur over HTTP, and the server needs to handle authentication and authorization, etc.

Typically you'll have a backend written in your server-side technology of choice (Rails, PHP, Django, WebObjects, ASP.NET, etc) which manages auth, etc, and sends the appropriate data encoded in JSON or XML to the Cappuccino-based frontend.

Cappuccino itself will likely always be predominately server agnostic, meaning you can use whatever server-side technology you like, as long as it speaks HTTP (that's a limitation of the browser, not Cappuccino)

That said, it would be great if there was something that made writing Cappuccino applications with x, y, and z server technologies even easier, preferably in a generic way.

We've also been talking about bringing some sort of CoreData-like technology to Cappuccino, which would be cool.

If anyone has ideas regarding these things, or you want to help out in implementing them, we'd love to talk (join us on IRC or the mailing list)

Cjed — Oct 01, 08 6419

Hi to all, I managed to make a synthesis of available informations about how to call JSON or JSONP web services from Cappuccino applications : here

Finley Still — Feb 10, 10 7397

Have you heard of Bombax for server side? It's all in objective-c Cocoa.

http://www.bombaxtic.com/




 

Comments Temporarily Disabled

I had to temporarily disable comments due to spam. I'll re-enable them soon.




Technorati Profile
Copyright © Scott Stevenson 2004-2008