en fait, objective-J n'est vraiment pas l'aspect important de Cappuccino. Il est là principalement pour rajouter à javascript ce qui permet de créer l'important : le "cadre" (framework) Cocoa pour le web : cappuccino. et c'est là que cela devient génial. Plus encore que sproutcore, on est face à une série de classe prête à l'emploi empruntant à un modèle très éprouvé (cocoa, feu openstep, feu nextstep, bientôt 20 ans de maturation) Il est du coup rapide d'imaginer qu'à terme, une fois cappuccino bien développé, qu'on pourra utiliser interface builder pour prototyper l'interface. Le passage de cocoa à cappuccino, est assez naturel, un peu comme passer de cocoa à sa version touch pour iphone. On est en terrain connu, à quelques détails d'implémentation prêts (et le fait que javascript est toujours disponible, en permanence) Bien évidemment, cappuccino ne couvre pas encore tous les "framework" d'apple, pas encore de Coredata, Coreanimation en chantier, etc. Comme dit il y a 2 mois, je suis très impressionné par l'environnement applicatif que deviennent les navigateurs web. et ce n'est que le début. Toutes les versions majeures en chantier (firefox, safari, opera, etc) vont amener de grosses améliorations et fonctionnalités pour développer.

N'était-ce la lenteur de ce genre d'application web (on édite tout de même plus rapidement sur une application locale), on se croirait vraiment sur Keynote. Ça donne une idée de ce que pourrait devenir notre environnement informatique d'ici quelques années - par contre j'ose à peine imaginer ce que ça impliquera au niveau de la bande passante de nos réseaux...

Ca marche comment ? Le langage objective-J est interprété par le Javascript ? Même si 280slides est impressionnant, n'est-il pas plus optimisé de faire directement du javascript ?

lukum : la plupart des fonctionnalités de 280 Slides fonctionnent en local. Le Java Script est interprété par le navigateur. Donc une fois que les programmes sont chargés sur ton Mac, ils tournent sur ta machine. C'est un langage interprété, ce qui occasionne une perte de performance par rapport aux langages compilés, mais ça devient de plus en plus négligeable grâce aux améliorations matérielles et logicielles de ces dernières années. Dans tous les cas, un Framework de haut niveau d'abstraction pour faire des applications web de qualité c'est toujours appréciable (ça fait gagner beaucoup de temps).

@lukum : une fois l'application téléchargée, il n'y a plus besoin de bandes passantes, sauf bien sur si l'application traite des données sur le net Il faut réaliser que cela n'a rien à voir avec Flickr, ce n'est PAS un site web auquel on recharge une "page" chaque fois que l'on clique. Toute l'application est téléchargée (en une fois) et exécutée localement par votre navigateur. C'est ainsi que procède Mobile me par exemple (écrite avec sproutcore, elle). Bien sur MobileMe, au cours de son exécution va récupérer des données sur les serveurs (courriers, calendriers, etc) mais le logiciel proprement dit est entièrement en local. Il est facile pour un navigateur, et c'est ce qui est en cours de normalisation pour html5 d'ailleurs, de stocker une bonne fois pour toute l'application et ne la réactualiser que si le navigateur remarque une nouvelle version. Vous revenez sur "280 slides" ? très bien, firefox la prend depuis son cache local, et envoie un petit message pour voir si y a pas une nouvelle version à ramener au cas où. C'est aussi cela qui a motivé Google de faire son propre navigateur. Microsoft évoluant avec la vitesse d'un escargot englué...

@biniou : Y a effectivement une transformation de Objective-J en javascript, mais il faut bien réaliser que Javascript a déjà beaucoup de choses proches de Objective C, il ne s'agit donc pas d'imaginer une complète transformation. il est toujours "+" optimisé de faire autrement. Ainsi, il est NETTEMENT + optimisé de cabler une bonne fois pour toute le logiciel dans la matière même du processeur (un cpu MS Word ! ) , mais y a d'un coté optimisation et de l'autre le coté pratique. (un peu comme quand je dis que consommation mémoire vitesse d'exécution, ca se pèse ) Ainsi, pensons à Os X. Cocoa fait des choses délirantes que mon oric atmos ne faisait pas. Il y a des couches d'abstraction dans Cocoa/Objective C que du temps de mon oric atmos on aurait jugé criminel mais je ne reviendrai PAS pour tout l'or du monde en arrière. Bien sur que Cocoa au final est "moins rapide" qu'un code C/assembleur sans facilités. (virons coredata, virons les polices dynamiques, virons le runtime objective, virons le collecteur de variables, virons tout ) Mais on perd en souplesse, en facilité de créations de logiciels. Des logiciels comme Coda ou Omnigraffle sont possibles et si rapidement mis en oeuvre grâce à Cocoa, grâce à toutes les fonctionnalités couteuses de cocoa. faire Coda en assembleur sur mon oric atmos auraient demandé des années voir 10 ans à tout réinventer, haa mais le code aurait été "optimisé", houlala, sur un pentioum, il aurait tourné à la vitesse de la lumière ouais mais bon, si on passe 20 ans pour créer un logiciel.. on a pas fini. Bref, bien sur qu'il y a un coût dans "cappuccino" (si on va par là, y a un coût dans html, css, jscript et le fait de faire du multitache) mais le gain au final le vaut largement : plus de logiciels de qualités, fait par plus de gens, en moins de temps avec moins de sources de bugs. Et les processeurs évoluent en puissance justement pour cela : pour amener plus d'outils, pas pour se gargariser.

@biniou : je complète : sproutcore est , comme vous dites, "directement en javascript" j'ai comparé les 2 et écrit du code , mon jugement (qui changera dans 6 mois, 1 an, et 2 ans) Sproutcore : - sproutcore tape directement du javascript, c'est plus "optimisé", - par contre on se mange css, Rhtml (ruby templating) , javascript et des tonnes de classes aliens inventées de toute pièces - la documentation est désastreuse (mais le projet est jeune, c'est normal, et elle évolue) - sproutcore est à peu près complet pour ses fonctionnalités importantes : on a les classes pour l'interface graphique, on a un système de "stockage" moderne pour gérer données locales ou provenant du net et les synchroniser avec l'interface graphique, etc. les briques sont là. - le projet n'est pas mure. - Apple leur a joué un vilain tour quelque part en annonçant ouvertement que mobile me était sproutcore et en faisant des présentations sur ça. Parce qu'en réalité Sproutcore n'est pas fini. Il est encore en mutation, et les travaux d'apple n'ont pas été donné à la communauté sproutcore. Du coup, des gens comme moi sont venus et sont tombés face à un projet opensource en pleine panique face à l'afflue (massif) de gens intéressés pour écrire du vrai code. --- Cappuccino : - objective-J , personnellement j'adore cette syntaxe et les conventions reprises de Cocoa : c'est littéral, structuré, cela pousse à écrire du code lisible. Objective-J rajoute les quelques manques de javascript. (un véritable système de classes, @implementation, etc) (et oui , je sais, les brouillons de futur javascript rattrape quelques manques justement) - on ne se mange PAS html, css ou je ne sais quel truc de templating : un seul langage, une véritable expérience de création d'applications sérieuses - la documentation est désastreuse (mais le projet est jeune, c'est normal, et elle évolue) - MAIS c'est TRES proche de cocoa. Du coup la doc de cocoa sert.

- cappuccino n'est pas encore complet. Il manque par exemple l'équivalent de Coredata. On peut créer une vraie application oui, mais avoir comme dans sproutcore la gestion de REST (api web pour récupérer et stocker des données via un serveur web) , un "storage", serait un grand plus. Cela est évidemment une priorité pour cappuccino. - le projet est mure. C'est à dire que les classes actuellement disponible ne varieront quasi plus. Elles suivent les conventions de Cocoa, Cocoa a pratiquement 20 ans, Certaines classes, genre NSString (CPString donc) ne bougeront pas avant 107 ans. On sait à quoi s'attendre. Peu de mutations à prévoir du jour au lendemain. - Personne a joué de vilain tour aux gens de 280 North. Ils ont sorti "cappuccino" quand ils ont estimé qu"il était mure pour faire quelque chose d'utile, ils ont mis D'ABORD en avant un exemple concret d'applications et ils ont dans le marbre la base de cappuccino. Personne ne leur a subitement braqué un projecteur en pleine gueule. ---- (bien évidemment , dans 6 mois, tout ce que j'ai dit sera faux)

je préfère carrément la vision de Cappuccino.

@Oomu : merci pour ces éclaircissements, je préfère aussi la vision de Capuccino parce que je pense que cela pourra rapprocher pas mal de développeurs des applications Web et à terme en facilitera le développement. Mon bagage est plus C, C++, Java, Javascript, PHP, ... Objective-C j'ai un peu du mal mais c'est surtout par manque de temps. Je pense qu'il faut surtout se réjouir de la venue de tel framework qui marque un réel tournant dans le domaine du web et de son expérience utilisateur.

Objective-C est proche de smalltalk, difficile donc de vous dire que c'est entre C et JAVA , mais bon en gros. Etudier le runtime de objective-C c'est réaliser la puissance du langage. Avant tout, c'est un greffon au C. Contrairement à C++, objective-C ne définit pas un nouveau langage, mais juste une extension de C. C'est 100% compatible C, c'est C qui est là. Mais la syntaxe elle même est secondaire, ce qu'il faut réaliser c'est que l'important est Cocoa. On ne vit pas en "objective C", on vit grâce à cocoa. Cocoa c'est ce qui fait que vos logiciels sont plus rapides à être écrits. Bien sûr le "runtime" objective C permet de mettre en oeuvre des concepts de Cocoa , mais vraiment, dans le cadre de Xcode et Interface Builder, l'ami que vous recherchez, c'est Cocoa. C'est pour cela, que indépendamment de vos goûts en syntaxe, avant tout, vous devriez vous sentir concerné par Cocoa. Les Frameworks sont plus importants que le langage Java Enterprise est plus important que la grammaire java (et personnellement J2EE me parait abominablement mal pensé et lourdingue à un niveau galactique, mais c'est du complet ha oui) .NET est plus important que C# Sproutcore est plus important que javascript etc.

"Je pense qu'il faut surtout se réjouir de la venue de tel framework qui marque un réel tournant dans le domaine du web et de son expérience utilisateur. " clairement oui.

@ lukum Teste le avec Chrome, il est ultra rapide.

En tout cas 280 slides est vraiment impressionant, ça promet. Là on peut vraiment parler d'application.

@Nicky: bonne idée, je vais essayer. Merci @oomu pour ses explications. Si je comprends bien, la lenteur que j'observe peut être imputée à mes ressources logicielles et matérielles (Firefox 3 sous Mac OSX 10.5 pour PPC, G5 faiblement cadencé à 1,6 Ghz, monoproc.). Je vais voir ce que ça donne sur mon MacBook du printemps 2008, avec Google Chrome sous VMWare fusion et Windows XP (comme voyage dans le passé on ne peut pas faire mieux!). Il reste que c'est assez étonnant, cette évolution d'applicatifs pour navigateur: l'OS de base de notre machine sert de plus en plus à faire tourner une sorte d'OS du navigateur. En arriverons-nous à un OS ultra simplifié pour la machine, alors que l'essentiel de l'OS se trouvera dans le navigateur? Je vois mal Final Cut ou Photoshop dans Firefox...

[quote]En arriverons-nous à un OS ultra simplifié pour la machine, alors que l'essentiel de l'OS se trouvera dans le navigateur[/quote] On en est encore loin. Les applis web ne gère pas la 3D et c'est pas encore prévu. Par contre, dans le monde de l'entreprise, ça va sûrement pousser un maximum. Serveur web ultra puissant avec des postes clients ultra optimisés pour le web.

Et comment fait-on du multi threading dans une application web ? On est pas prêt de se séparer des applications desktop.

Du coup, je me demande de plus en plus quel sera l'intérêt de développer une application web en Flash quand on pourra le faire avec un framework tel que Capuccino, et tout cela sans plugin !?

alors la "lenteur", c'est effectivement parce que les navigateurs actuels ont été conçu pour le temps rigolo où javascript servait à afficher des popups et bouger des petits bonhommes amusants sur la page.. bref des fadaises rapides. Maintenant, on est en passe de normaliser beaucoup de choses UTILES, et là , il faut que javascript devienne robuste, puissant, rapide, efficace donc c'est pour cela que tout le monde parle de squirrelfish, de v8, de firefox 3.1 etc. subitement javascript devient central, ses performances vont êtres décuplés, on abandonne les vieux "interpréteurs" pour passer à de véritable machines virtuelles. - non l'os ne disparaîtra pas non l'os ne "simplifiera" pas . De fait, l'os n'a fait qu'englober toujours plus de services et utilitaires depuis les années 70. fut un temps où "unix" était vécu comme un Monstrosaure qui débordait de "l' os" , si je vous mettais un vénérable "unix" sur votre ordi, vous crierez à la famine. Le navigateur web est un composant parmi tant d'autre. Il sera le composant permettant d'exécuter des applications et documents en provenance du réseau. Mais en aucun cas il remplacera votre Spore, votre logiciel de création graphique pro, etc. La distribution de logiciel peut passer par le web, l'exécution de logiciel peut provenir du web, mais ce n'est qu'un outil de plus, qu'un paradigme supplémentaire. Tout comme l'émergence de l'ordinateur personnel n'a pas détruit le serveur central (quoiqu'on en dise) - et le moulti-fred ? (exécution en même temps de plusieurs tâche d'un même logiciel) et bien c'est facile, il suffit que le navigateur propose cette possibilité au moteur javascript du logiciel. c'est d'ailleurs une des nouvelles avancées de javascript, (Web Worker, un pool de process)) http://developer.mozilla.org/web-tech/2008/09/04/web-workers-part-1/ comme quoi c'est pensé derrière. ha mais justement, c'est l'une des avancées majeures de Google Chrome : séparation et éxecution en parallèlle

il existe déjà des "mini os", par exemple les "thin client" sous un linux simplifié juste pour afficher un client Windows Terminal Server ou effectivement , un navigateur web.

@Zenx "Du coup, je me demande de plus en plus quel sera l'intérêt de développer une application web en Flash quand on pourra le faire avec un framework tel que Capuccino, et tout cela sans plugin !? " à mon avis : zéro. c'est justement ZE troll du moment dans les forums de développeurs, les chopes de bières volent bas. Les tenants de flex ou silverlight hurlant à l'infamie

@oomu merci pour ta remarque sur Flash/Flex et autres ... Il y a toujours Java pour faire du multithread pour les applications (quoi qu'on en dise ou on en pense c'est loin d'être une technologie dépassée)...