C'est incroyable le temps qu'on perd à dégrader notre code pour le faire fonctionner sous IE6, encore utilisé par 15 à 25% d'internautes dont l'immobilisme va totalement à l'encontre des technologies qu'ils essaient d'utiliser.

Microsoft n'est fautif que d'avoir réussi à réunir autant d'incompatibilités et d'échecs dans un seul explorateur et de n'avoir jamais su corriger le tir. On parle ici du pauvre support des CSS avancés, des divers bugs et problèmes de sécurités, de l'impossibilité d'exécuter correctement un simple javascript ou encore d'avoir voulu réinventer les standards.

Le détenteur du dit browser, lui, est fautif de se contenter du pire et par la même occasion, de ralentir le progrès. Mais on constate rapidement que la plupart des machines qui supportent encore IE6 dans leur mémoire font parties de parcs informatiques professionnels (90%), bien souvent ceux de multinationales ou autres grandes entreprises.

Evidemment, les entreprises ne trouvent aucun intérêt à mettre à jour leur parc informatique pour un outils qui finalement, ne rapporte pas grand chose. Et surtout, ils n'en tireront aucun bénéfice. Les employés, eux, n'osent pas mettre à jour ou n'en ont simplement pas les droits.

Comme le dit si bien Mark Trammell: "demander aux utilisateurs de mettre à jour leur explorateur est non seulement inutile mais surtout sadique".

Pour les développeurs web, bien entendu, c'est l'enfer du devoir. Il est hors de question de refuser le portage sur IE6 sur des sites marchands, car on perdrait un quart de clientèle. Comment ainsi dire qu'on se soucie d'augmenter l'impact du site réalisé ?

En fait, la question n'est pas vraiment de ne plus supporter IE6, ce n'est pas possible. Mais la vraie question est de savoir quand est-ce que IE6 va disparaître suffisamment pour qu'une agence web puisse justifier le fait d'arrêter de s'en soucier ?

Car mine de rien, si les entreprises qui persistent à obliger l'utilisation de cet explorateur faisait un rapide calcul du temps perdu (80% du temps passé sur le développement du CSS et Javascript est investi dans les soucis de compatibilité avec IE6) auprès de leur agence web, ça fait bien longtemps que le pas aurait été franchis.

Et d'ici là, nous continuerons à perdre notre temps et à doubler nos factures pour supporter les technologies dépassées.

Zend Framework propose des fonctionnalités et une puissance certaine en plus d'être modulaire et de disposer de la pérennité de sa société créatrice. Malheureusement, le framework a quelques soucis de performance qui apparaissent rapidement à l'oeil du développeur averti.

En affichant simplement la mémoire consommée sur une page générée à l'aide du ZF, nous constatons rapidement que cette consommation est assez exagérée. Les scores nous amènent rapidement aux alentours des 10 ou 15M. On peut alors imaginer ce qui se passerait si nous montions en charge.

Dans le cadre d'un projet nécessitant, justement, de supporter une haute charge, j'ai été amené à participer à l'évaluation des performances de Zend Framework.

Le but de cette évaluation n'était pas de déterminer si le framework était plus ou moins performant qu'un code PHP pur ou qu'un autre framework, comme CodeIgniter ou Kohana, car nous connaissons déjà la réponse à cette question.

Non, le but était de déterminer, premièrement, si l'infrastructure prévue était suffisante. Dans le cas contraire quelle infrastructure devait être mise en place pour supporter un nombre déterminé de connexions concurrentes. Et finalement, déterminer si ces acquisitions étaient une solution viable et moins onéreuse que l'optimisation ou la formation de développeurs sur un framework différent.

Malgré les piètres performances de Zend Framework en terme de consommation mémoire, nous avons vite réalisé que ce n'était pas son plus gros point faible.