Carnet de notes

Catégorie : Développement web

  • Déclen­cher le cache appli­ca­tif HTML 5 par javas­cript

    Parfois je me pose des ques­tions exis­ten­tielles. Hier c’était de savoir si le cache appli­ca­tif de HTML 5 pouvait être activé dyna­mique­ment par javas­cript lors de l’exé­cu­tion de la page, au lieu d’être déclaré de façon statique dans le code HTML.

    L’idée derrière cette inter­ro­ga­tion est que le cache appli­ca­tif ne soit activé que sur certains critères (compa­ti­bi­lité du navi­ga­teur avec le code javas­cript utilisé, requête spéci­fique de l’uti­li­sa­teur, etc.).

    Petit test :

    <!DOCTYPE html><html>
<head><meta charset=utf8><title>TEST offline</title></head>
<body><script>
document.documentElement.setAttribute("manifest", "cache.manifest") ;
window.applicationCache.update() ;
</script><body>
</html>

    J’ai été agréa­ble­ment surpris par Mozilla Fire­fox, qui accepte le tout sans bron­cher. La décon­nexion permet de véri­fier que le cache appli­ca­tif fonc­tionne sans heurs.

    Mes espoirs se sont arrê­tés là, Chrome déclenche une excep­tion sur la mise à jour à seconde ligne de script. Il faut décla­rer le cache de façon statique dans le HTML. Pas le choix, dommage.

  • Réso­lu­tions d’écran – mai 2011

    Petite statis­tiques abso­lu­ment pas repré­sen­ta­tive mais inté­res­sante quand même : les réso­lu­tions d’écran des gens qui sont passés sur ce site du 1 au 12 mai 2011.

    Petite inter­pré­ta­tion perso :

    • J’ai moins de 10% de visites de mobile (réso­lu­tion infé­rieure à 1024px)
    • Je dois avoir envi­ron 3% de netbook et tablettes (réso­lu­tion de 1024px mais pas plus)
    • Les desk­top supportent tous ou presque au moins 1280px (87% de support, mobiles inclus)
    • Les mobiles sont tous diffé­rents et il est diffi­cile d’ac­ter d’une réso­lu­tion mini­male stan­dard sauf à la prendre vrai­ment très petite
    Avec comme consé­quence sur le design, si on doit faire plusieurs versions:
    • Une version mini­male à 240 ou 280px, quitte à ce qu’elle soit très dégra­dée
    • Une version à 800 (android récent en paysage), qui servira aussi pour les iphone avec une meilleure réso­lu­tion, les tablettes et les netbooks
    • Une version desk­top à 1280, qui sera la version « stan­dard »
    • Une à 1400 ou 1600 pour récu­pé­rer les écrans larges
    • Et si je suis bien luné une version à 1900 parce que ça concerne quand même encore un quart des visites
    Atten­tion, ces chiffres ne prétendent pas être repré­sen­ta­tifs de quoi que ce soit, et ne repré­sentent que des réso­lu­tions d’écran, pas des tailles de fenêtre, ce qui est nette­ment diffé­rent.

  • JSON c’est hype

    J’en ai marre de voir du JSON partout. J’ai même vu des gens propo­ser de rempla­cer du XML par du JSON juste parce que c’est plus moderne, plus léger et plus compa­tible. « JSON is the new XML » est un effet de mode, un mauvais effet de mode. On va se retrou­ver comme avant avec des gens qui vont se réveiller dans quelques mois/années avec des formats de données pas du tout adap­tés à leur usage.

    Coupons un peu dans le tas :

    JSON n’est pas vrai­ment plus simple à lire par un humain

    Pour un petit fichier en volume comme en hiérar­chie, le JSON a un léger avan­tage sur le XML mais ce n’est pas fran­che­ment signi­fi­ca­tif.

    Pour un gros fichier ou avec beau­coup de hiérar­chie, le JSON devient complè­te­ment illi­sible à suivre au niveau des imbri­ca­tions.

    JSON n’est pas plus simple à écrire par un humain

    JSON est un peu moins verbeux mais plus propice aux erreurs : facile d’ou­blier une virgule en fin de ligne, ou d’en mettre une par erreur à la dernière ligne. Sur les gros fichiers les niveaux d’im­bri­ca­tion seront eux aussi un écueil à l’écri­ture.

    En compa­rai­son la verbo­sité d’XML rend diffi­cile les erreurs et le dispo­ni­bi­lité de fichiers gram­maire permettent de faire de l’aide à la saisie voire de vali­der en tems réel le contenu.

    La diffé­rence de poids n’est pas signi­fi­ca­tive

    JSON est plus léger que le XML d’en­vi­ron un tiers (pour des fichiers forte­ment struc­tu­rés, beau­coup moins pour les autres). À moins de 1,5 Ko une fois compressé en gzip (donc 6 Ko non compressé) ça tient dans un paquet TCP/IP et 500 octets de moins ne changent stric­te­ment rien. Sur disque on compte de toutes façons au moins par paquets de 4K.

    Pour faire une diffé­rence signi­fi­ca­tive de 10 Ko sur le réseau il faut une donnée de 160 Ko avant compres­sion. Ça concerne d’au­tant moins de monde qu’à ce volume le JSON n’est plus du tout lisible.

    JSON n’est pas plus natif que XML

    XML est natif sur tous les outils, langages et navi­ga­teurs depuis des années là où JSON n’a d’API native que sur les navi­ga­teurs récents, certains langages et quelques outils.

    JSON est en fait natif en javas­cript via eval(), mais ça n’est pas plus perfor­mant. Pour une même donnée, lire du XML via DOM est 30% plus rapide que lire du JSON avec eval(). Pour avoir sécu­rité et fiabi­lité en lecture, ou pour faire de l’écri­ture JSON, il faudra une biblo­thèque pas native du tout sur IE7 ou Safari pour iPhone 3.2. Elle fera au moins 5 Ko et ne sera donc renta­bi­li­sée par rapport au XML natif que si on trans­fert au moins 15 Ko de JSON.

    JSON n’est pas vrai­ment exten­sible ou évolu­tif

    JSON permet souvent d’ajou­ter de nouvelles clefs sans modi­fier casser la compa­ti­bi­lité. Si on souhaite ajou­ter une date de mise à jour à une liste de chaînes de carac­tères, il faudra toute­fois modi­fier le format, mettre à jour tous les outils concer­nés. Si on souhaite mixer des formats diffé­rents là ça devient vite un casse-tête et des solu­tions bidouille.

    En XML on a la possi­bi­lité d’in­sé­rer des méta-données dans des attri­buts, ainsi que de mixer diffé­rents concepts ou formats à l’aide d’es­paces de noms. Ce sont des fonc­tion­na­li­tés qui ont leurs limites, mais qui ont prouvé appor­ter un peu de souplesse et d’évo­lu­ti­vité aux formats créés.

    Compa­tible avec l’exis­tant

    Outre le concept de « natif », beau­coup d’ou­tils, d’ap­pli­ca­tions, de progi­ciels ou de chaînes de trai­te­ment sont adap­tés à l’ex­ploi­ta­tion ou à l’ex­por­ta­tion de données XML. Côté JSON les plus récents savent faire de l’ex­port, tout le reste est à trai­ter en spéci­fique.

    Sur l’exis­tant XML j’ai des concepts de signa­ture, des mapping XML-Objet en Java, des outils qui font du filtre ou du routage, de la vali­da­tion, des compo­si­tions entre données XML.. tout ça n’existe simple­ment pas en JSON. Quand (si) j’en aurai besoin, il faudra réin­ven­ter la roue.

    Hype, mode et trucs de jeunes déve­lop­peurs inno­vants

    JSON était simple au départ parce qu’on utili­sait eval(), que ça renvoyait immé­dia­te­ment sur un objet javas­cript sans deman­der au déve­lop­peur client de faire des mani­pu­la­tions complexes ou de char­ger une biblio­thèque de plus. Ça a permis d’ou­vrir quelques API à des gens qui auraient eu du mal autre­ment. C’est indé­nia­ble­ment posi­tif sur ce point là.

    Ensuite s’est rendu compte que pour la fiabi­lité et la sécu­rité il fallait du code en plus. Faire des petites fonc­tions qui lisent du XML simple pour créer des objets javas­cript natifs aurait été plus simple, plus perfor­mant et moins lourd mais c’était trop tard : c’était « hype ». Du coup on a utilisé des biblio­thèques d’ana­lyse de 10 Ko de pur javas­cript pour lire des JSON de moins de 1 Ko et annon­cer que ces derniers étaient moins lourds que le XML corres­pon­dant. Allez comprendre.

    Depuis on a des fonc­tions natives dans les navi­ga­teurs récents et un peu plus de support dans les outils récents (c’est la mode, il a bien fallu faire avec et suppor­ter le nouvel usage) donc ça a du sens pour quelques usages (échange de petites données struc­tu­rées avec un navi­ga­teur récent) mais la mode prend encore trop le pas sur des grilles de compa­rai­son argu­men­tées et factuelles et même dans les usages les plus adap­tés, le béné­fice sur le XML est rare­ment très signi­fi­ca­tif.

  • Sud Web : La confé­rence des métiers du web dans le sud

    Nous avons monté Paris Web il y a main­te­nant quelques années pour parler du web, de ses métiers, de retours d’ex­pé­riences de profes­sion­nels sur la qualité, l’ac­ces­si­bi­lité et la publi­ca­tion sur le réseau. Depuis lors on nous a demandé « et pour les gens du sud alors ? ».

    Cette année quelques uns ont pris leur courage à deux mains pour créer Sud Web, un événe­ment avec une des meilleurs tagline qu’on puisse imagi­ner : savoir-faire et faire-savoir. Avec le soutien de parte­naires locaux comme la recom­man­da­tion de noms pres­ti­gieux comme le W3C, le programme qui s’an­nonce peut mettre au défi une grande majo­rité des événe­ments web français du domaine.

    Si c’est incon­tour­nable pour les passion­nés et les amou­reux du web, c’est aussi une étape de forma­tion conti­nue et d’ex­plo­ra­tion de l’état de l’art avec un recul que vous ne pour­rez pas compen­ser par quelques lectures en ligne ou par une session de forma­tion entre quatre murs.

    Tout ça c’est à Nîmes, fin mai, le 27 exac­te­ment. Pour ceux qui veulent renta­bi­li­ser leur dépla­ce­ment c’est précédé le 26 par une jour­née centrée autour de l’ex­pé­rience utili­sa­teur : Web UX. Alors ce n’est pas à Paris, mais entre le soleil et l’hé­ber­ge­ment moins coûteux qu’à la capi­tale, on s’y retrouve rapi­de­ment ; et puis ça vaut large­ment le billet de train, tout simple­ment.

    Il reste des places, prenez votre courage à deux mains et jouez des pieds pour bouger votre employeur afin de vous inscrire.