| french | english |
 |
|
| Sign in | |
| 30-06-08 / 23:57 : ArsTechnica : about Cappuccino (cjed) |
| ArsTechnica provides an article about Cappuccino. We find here an Objective-J code sample compared with its Objective-C counterpart... syntax is identical (except the * for pointers isn't required anymore and CP classes name prefix replaces NS prefix). We learn that the Objective-J interpreter that generates javascript is abstract in a such a way that it can ensure independance from the underlying implementation technology : AppKit does generate DOM elements, but, in many ways, the DOM is just an implementation detail for us. If tomorrow every browser implemented SVG, and we thought Cappuccino should really run on SVG, we could rip out the guts and replace some of the code in AppKit and suddenly every app on top of Cappuccino would be running on top of SVG. As there isn't any server-side compilation step required (contrary to GWT) it can not only provide a faster development cycle (They make a change, hit refresh, and see it on the screen), but it will also allow in the future accessibility (that is access to system features, when browsers will have evolved - that is for sure if we look backward and consider the many new extensions and plugins), what is impossible from bytecode generated on the server side (GWT case). The preprocessor performances doesn't seem to be a problem if we dig in the article and in the even more useful comments : the company [280 North] has a tool "to preprocess Objective-J code ahead of time, so you save client side execution and load time. like WebKit's use of the SquirrelFish interpreter, the extra time required to preprocess before the app starts running becomes less and less of an issue. Preloading images is a good idea, and something we've discussed. We want to come up with a generic solution for it, though, and we simply haven't had the time to do that yet. We will definitely tackle that problem at some point. Sending bytecode to the client won't gain you that much if you're using gzip compression. Besides, with offline support like what google gears allows, you're downloading the app once, and then running it from local storage (unless updates are made). This makes rich web apps feasible even on dial-up, because you have to incur the download cost just once. Throughout the course of building Cappuccino and 280 Slides we've frequently come up with ways that give us anywhere from 2x to 10x performance gains. We released 280 Slides because we felt the performance was adequate (in fact, it loads faster than both PowerPoint and Keynote on my mac), but we're always looking into ways to make it faster. All that has been made by 3 guys only (engineers working at Apple) ! The framework is being polished before the public release (open source) : we reimplemented AppKit, Foundation, CoreGraphics, and parts of CoreAnimation. |
| Comments |
| Write a comment |