| french | english |
 |
|
| Créer un compte | |
| 09-12-08 / 00:42 : Javascript & ActionScript : retour en arrière (cjed) |
| Dans les commentaires sur l'article d'ArsTechnica de septembre au sujet de Cappuccino, on pouvait lire : Technologically, JavaScript apps running in a browser is like apps running under MultiFinder back in the Mac OS 6 days: no memory protection, cooperative multi-tasking, etc. One badly programmed web app and it takes down your entire browsers and all the other web apps and open web pages along with it. Worse, however, there are just about half a dozen software abstraction layers added, and thus, what used to work on a 68k CPU back then now requires a dual or quad-core CPU with GHz clock frequencies and Gigabytes of RAM just to get adequate performance. Can you say "back to the future"? JavaScript, Java, Flash, Cookies, etc. should be filtered out by the firewall. The web is a publishing platform, if you want to go back to mainframes and terminal based remote processing, then come up with a secure protocol that's designed for remote GUIs over low-bandwidth channels. The web isn't it. Il est vrai que l'absence de procédé de synchronisation (mutex) en Javascript rend les applications peu robustes. Et que dire des performances des applications Flash (donc Flex), basées sur l'ActionScript (dérivé de l'ECMAScript, ancêtre également du Javscript), qui font se déclencher les ventilateurs de portables double core. Pire, sur un simple G4, alors qu'une nouvelle publicité est apparue récemment sur le site (pour la page de saisie de news notamment), la saisie de texte est impossible tant l'animation ralentit la machine (heureusement elle ne se déclenche pas systématiquement) ! On peut lire un article présentant des astuces pour gérer les problèmes de synchronisation en Javascript. Je n'ai pas trouvé de classe CPLock dans Cappuccino, mais le code de classe evaluate.js (et également CPTimer - présence de timeouts) laisse penser qu'un minimum de synchronisation est gérée, sans doute par des procédés (hacks) similaires. La compétition ne se jouera donc pas seulement au niveau du moteur Javascript (SquirrelFish Extreme, Chrome, etc.), mais globalement au niveau du container, car comme je le disais il y a quelques mois tout est container : moteur d'exécution javascript (typiquement script dans un modèle html DOM, donc dans un navigateur), plugin Flash (si dans navigateur) ou container AIR (si hors du navigateur), container Quicktime (QuickTimeX pourrait utiliser les sockets de HTML 5, et iTunes est déjà une applicaion hybride, basée sur WebKit). Puisque les dérivés de l'ECMAScript ne sont pas satisfaisants, on pourrait s'attendre à leur évolution, ou bien à l'arrivée de langages plus puissants, mais alors on bascule très vite vers les langages déjà connus... On ne peut donc pas obtenir d'interface réactive et robuste et en même temps réduire les compétences des développeurs à un langage de script. L'informatique est complexe, les threads et la synchronisation une réalité, il faudra un jour l'admettre. Google travaille sur le parallélisme et la protection d'espaces d'exécution Javascript, mais tout cela représente beaucoup de travail pour un résultat qui ne sera pas complètement satisfaisant (à la manière des astuces sous Système 7 au niveau de la gestion de la mémoire - réserve de sécurité et allocation depuis le haut de la pile d'adresses, à l'opposé - pour limiter le risque d'écrasement, qui ne faisaient que retarder l'apparition de ces problèmes en cas de manque de mémoire). Les problèmes de lenteur ne touchent cependant pas que les langages interprétés. Par exemple le récent OpenOffice.org 3, pourtant présenté comme utilisant des APIs natives, est anormalement lent pour le défilement, comparé à NeoOffice qui passe pourtant par le bridge Java pour l'interface. Un LC475 avec 4 Mo de ram et Word 5.1 est bien plus rapide. MacOSX aussi utilise un empilement de couches : une task Mach est wrappée par une task BSD, puis enfin par une task Carbon. On peut espérer la suppression de cette dernière couche dès que la migration des applications vers Cocoa aura abouti (en cours pour les logiciels Adobe, mais pas encore pour Office de Microsoft). Les points d'optimisation sont pourtant très nombreux en Cocoa comme on le découvre dans le livre Cocoa Programming de 2002 (930 pages lues déjà). Heureusement le succès de l'AppStore et les ressources limitées de l'iPhone obligent les développeurs à s'intéresser à l'optimisation (d'ailleurs le garbage collector d'Objective-C 2 n'est pour cette raison pas disponible sur l'iPhone SDK). Apple également a énormément progressé sur ce point pour la version mobile d'OSX, ce qui sera bénéfique à la version desktop (sans parler de Grand Central, OpenCL, l'optimisation 64 bits, le nettoyage et l'optimisation du code pour Intel, le SSE4). |
| Commentaires |
| Poster un commentaire |