RPW 16/07/10: poids des pages, moteur de jeux en JS, convention de codage JavaScript, intersection de tableau javascript

Revue de Presse Web de hier :

• Perfs : les pages web sont de plus en plus lourdes, c'est un constat que l'on se fait depuis l'avènement de l'ADSL pour tous en France mais à quel point cela est il grave ? Le markup d'un site populaire comme CDiscount fait 172Ko (normal, tout est à base de <table> ...), mais il ne fait plus que 31Ko une fois gzippé : il est généré et reçu en moins d'une demie seconde, ils ne voient sans doute pas l'intérêt de changer. Et pourtant si l'on ajoute les 15% d'utilisateur à qui l'on ne sert pas Gzip (voir ce PDF) aux utilisateurs sans ADSL (5%) ou sur réseau mobile, on peut se dire que le poids de la page est toujours important, même en France pays du haut débit.
• JavaScript : un code très optimisé pour obtenir l'intersection de 2 tableaux. Des solutions JS génériques comme Taffy DB ou JSLINQ permettent de manipuler sans difficulté des tableaux, mais lorsqu'arrivent des problèmes de performances, ces librairies ont rarement été optimisées. L'auteur présente donc ici un algorithme qui est beaucoup plus efficace sur les grands ensembles. Etant donné les licences et la vitesse à laquelle ces librairies évoluent, cela vaut peut être mieux d'utiliser un wrapper pour pouvoir changer facilement de code et avoir le mieux optimisé pour vos besoins.
• JavaScript : convention de codage en JavaScript, par Google. Sans le savoir et à force d'erreurs je respecte déjà les ³/₄ de ces conventions, qui deviennent logiques dès que ce que l'on code dépasse le stade du scripting ou que la taille de l'équipe dépasse 1. Les règles sont très diverses et vont de la documentation au format JavaDoc (la même que pour PHP, facile) à l'utilisation d'eval() en passant par les conventions de nommage (majuscules pour les constante, camelCase pour les fonctions ...). Et cela évite également les débats sans fin sur l'utilisation de ' ou " pour les chaînes de caractères ou la position des {} : il n'y a parfois pas de gagnant, il faut juste trancher. Même si certaines de ces règles sont orientées pour faire passer son JS au Google Closure Compiler, la formalisation de ces règles dans votre équipe vous assurera quoi qu'il en soit une maintenance plus aisée.
• JS : conférence sur un moteur de jeu en JS. Il s'agit du moteur Aves, dont voici une bonne démo. Ca prend 45mn en anglais, voici donc quelques notes :
  • Canvas n'est pas assez efficace => utilisation directe de .innerHTML
  • jquery est utilisable pour sa gestion de la souris et son modèle évènementiel
  • 2D et 3D isométrique seulement, WebGL est très loin
  • Flash éliminé pour manque d'interopérabilité
  • utilisation de la génération de classes plutôt que de générer des styles inlines sur chaque élément
  • l'industrie du jeux peut se permettre d'attendre HTML5, CSS3 et l'accélération matérielle, car ils savent qu'ils vont passer 1-2 ans sur un jeu
  • 3 listeners pour tout le document ! pour gérer les zones non carrées, ils voulaient gérer une carte de pixels en JS, et finalement ils ont utilisé Canvas pour analyser les images et savoir si la zone cliquée était transparente ou pas !
  • l'avantage de réutiliser JS au frontend comme au backend est que des portions de code sont réutilisables, pour calculer les positionnements par exemple
  • JS au backend est presque aussi rapide que C, utilisation de EcmaScript 5
  • mais Node est tout neuf
  • le code backend event-driven, jamais bloqué est idéal pour des MMO
  L'intérêt d'étudier cette utilisation extrême de JS est que c'est une vraie implémentation professionelle de toutes les techniques HTML5, CSS3 et Node.js. Même si leur vision se situe à 2 ans d'ici, cela préfigure ce qu'il sera possible d'ici là.

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious, Mail .