| french | english |
 |
|
| Créer un compte | |
| 30-06-08 / 23:57 : ArsTechnica : article sur Cappuccino (cjed) |
| ArsTechnica propose à son tour un article sur Cappuccino. On y trouve un exemple de code Objective-J comparé au code correspondant d'origine (Objective-C)... la syntaxe est identique (les seules différences sont la disparition du * pour les pointeurs et le suffixe des classes, CP au lieu de NS). On y apprend notamment que l'interpréteur Objective-J qui génère le javascript est suffisamment abstrait pour offrir l'indépendance vis à vis de la technologie d'implémentation : 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. L'absence de phase de compilation côté serveur (contrairement à GWT) assure non seulement un cycle de développement plus rapide (They make a change, hit refresh, and see it on the screen), mais permettra également à terme l'accessibility (accès à des fonctions système, lorsque les navigateurs auront évolué - ce qui est certain si on regarde le chemin parcouru depuis les débuts et le nombre d'extensions et plugins), chose impossible à partir de bytecode compilé côté serveur (cas de GWT). Les performances du preprocesseur ne semblent pas un souci d'après l'article et les commentaires comme toujours encore plus intéressants : 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. Et tout cela a été réalisé par 3 personnes (ingénieurs travaillant à Apple) seulement ! Le framework est en cours de peaufinage avant la release publique (open source) : we reimplemented AppKit, Foundation, CoreGraphics, and parts of CoreAnimation. |
| Commentaires |
| Poster un commentaire |