Carnet de notes

Catégorie : javascript

  • [Lecture] On a testé fonc­tion­nel­le­ment notre app JS

    Lu sur le web :

    L’uti­lité des tests fonc­tion­nels pour les appli­ca­tions web n’est plus à démon­trer (comment ça, vous ne testez pas encore vos apps ?). Malheu­reu­se­ment, tout ne peut pas être tota­le­ment testé fonc­tion­nel­le­ment, ou de façon aisée : je pense par exemple au player chez nous, un compo­sant stra­té­gique mais pauvre­ment testé fonc­tion­nel­le­ment de par sa nature un peu hybride (mélange de flash et de JS). Dans tous les cas, pour ce qui peut l’être, nous sommes parti­sans dans l’équipe Cytron d’user sans mesure (ou presque !) de cet outil de manière à être le plus zen possible au moment d’ap­puyer sur le bouton “deploy”.

    — chez M6 Web

    Inté­res­sant, mais à deux moments j’ai l’im­pres­sion de tâton­ne­ments, de tests qui peuvent échouer sans raisons et qu’on relance pour s’as­su­rer que ça passe. Je trouve ça assez risqué comme approche. Ai-je mal compris ?

    il nous arri­vait que le compor­te­ment “hover” ne soit pas déclen­ché, mettant en échec la suite du test. Nous avons donc changé notre manière d’ef­fec­tuer le rollo­ver : on répète l’ac­tion grâce au waitUntil tant que l’éle­ment devant appa­raître au hover n’est pas visible

    Pourquoi l’évé­ne­ment n’est-il pas déclen­ché ? Et l’uti­li­sa­teur risque-t-il d’avoir le même bug ?

    Elle permet de stocker dans un fichier texte la liste des scéna­rios en échec pour les relan­cer ensuite afin de véri­fier qu’ils le sont réel­le­ment.

    Des faux posi­tifs ? Et si parfois le test échoue alors qu’il ne devrait pas, il y a-t-il un risque qu’il réus­sisse alors qu’il ne devrait pas ? Combien de fois le relan­cer pour être certain du résul­tat ?

    Le retour d’ex­pé­rience est extrê­me­ment inté­res­sant, mais ça laisse un goût de bidouille qu’il serait préfé­rable de corri­ger avant de consi­dé­rer la solu­tion comme stable.

  • La commu­nauté JS est actuel­le­ment une machine à créer de la dette tech­nique

    on est dans la phase de l’ado­les­cence. Ça cri, ça bouge, ça a plein d’éner­gie, et ça mérite des baffes.

    — par Sam & Max

    L’ins­tal­la­tion est deve­nue un enfer. Entre les dépen­dances dépré­ciées, les libs incom­pa­tibles, les diffé­rents outils de build, et les options de config et les plugins, c’est une merde incom­men­su­rable. Plusieurs stan­dards d’ins­tal­leurs (et outils joints) se tirent la bourre : AMD, CommonJS et Harmony. Vous vous souve­nez du temps ou on copiait juste jQuery dans le réper­toire static ?

    […] On peut faire plus de choses qu’a­vant. De manière plus propre […] Mais l’éco­sys­tème, c’est le bordel géné­ral, l’anar­chie totale, et ça conti­nue d’avan­cer, en lais­sant tout le reste derrière.

    Les projets JS s’ac­cu­mulent, de free­lances en SS2I qui se pointent, codent ou (surtout) recodent, et repartent en lais­sant un projet qu’il sera imbu­vable à reprendre, dépré­cié avant même d’être terminé, non docu­menté, non testé.

    Livré sans commen­taire, mais j’ai­me­rais bien les vôtres.

  • Cere­bral (React)

    Je manque d’ex­pé­rience en React / Flux, mais je partage quelque chose qui m’a eu l’air d’avoir du sens à partir de la vidéo (je partage un lien et pas direc­te­ment la vidéo parce que ça commence à 5h44m30s, ils ont visi­ble­ment filmé tout en une passe) : Cere­bral

    Le passage qui montre le scéna­rio de l’ap­pli­ca­tion et permet de comprendre tout le fonc­tion­nel et l’en­chaî­ne­ment sans aucun code est tout de même assez sympa (même si l’im­bri­ca­tion fait peur).

  • #NodeJS : A quick opti­mi­za­tion advice

    The small changes made the func­tion body of add() growing over 600 charac­ter. v8 opti­mi­zer (crank­shaft) inlines the func­tions whose body length, inclu­ding the comments, is less than 600 charac­ters.

    — chez Julien Crou­zet

    Je ne peux m’em­pê­cher de trou­ver étrange d’in­clure les commen­taires. Ça ressemble à une façon d’épar­gner un micro-cycle de CPU assez peu perti­nente. Il reste que c’est à savoir, et que mettre le commen­taire hors de la fonc­tion résout tout. Autant le savoir.

  • The empe­ror’s new clothes were built with Node.js

    Atten­tion ça va réagir :)

    I want to address one-by-one all of the strange and misgui­ded argu­ments for Node.js in one place.

    C’est chez Eric Jiang, et si c’est plein d’opi­nion, d’iro­nie et de cari­ca­ture, c’est quand même vrai sur le fond.

  • Sur-Javas­cript

    J’avais regardé CoffeeS­cript il y a long­temps, mais sans être convaincu. Si j’ai besoin de faire du Javas­cript, je fais du Javas­cript. Coffee apporte bien des amélio­ra­tions sur la syntaxe, mais le langage n’est lui-même pas parfait et je doute que le rapport béné­fice/coût soit très élevé.

    J’en ai à peu près autant au service de Dart même si, sans réel­le­ment percer pourquoi, j’ai l’im­pres­sion qu’ils ont réussi à mieux se déta­cher de Javas­cript, et donc avoir un vrai langage distinct qui « compile » du Javas­cript (c’est bien l’es­prit de Coffee aussi, mais je n’ai pas eu ce ressenti).

    Je suis proba­ble­ment plus ouvert à TypeS­cript ou Traceur, qui sont plus proches du langage d’ori­gine et dont les objec­tifs et syntaxes sont presque « le prochain Javas­cript ». On a plutôt une couche de compa­ti­bi­lité arrière, et c’est un bon système.

    L’im­pres­sion que ça donne est tout de même qu’ils ont fait leurs propres exten­sions qui n’ap­par­tiennent qu’à eux.

    Est-ce qu’on a quelque part un projet simi­laire, qui implé­mente un maxi­mum de nouveau­tés des futurs EcmaS­cript mais qui évite d’ajou­ter trop de syntaxes diver­gentes au cœur du langage ?

    Quelles sont vos expé­riences avec l’un ou l’autre de ces systèmes ?

  • Lien vers du Javas­cript

    Problé­ma­tique du jour : Inter­cep­ter l’ap­pel à des liens via Javas­cript.

    Mon cas d’usage : J’ai des conte­nus (images, vidéos, audio, polices de carac­tères) stockés côté client (indexedDB, webSQL ou DOMS­to­rage) que je souhaite insé­rer dans mes pages.

    (billet mis à jour au fur et à mesure des réponses)

    Quelques solu­tions :

    Data:URI

    Je récu­père ma donnée, je la trans­forme en base64, et je remplace le lien stan­dard par un lien en data:uri.

    Deux défauts : Je stocke N fois la donnée dans le DOM où N est le nombre d’ap­pa­ri­tion de l’image ou de la ressource dans mes pages HTML/CSS. Pour ne rien gâcher, on stocke en base64 donc avec 30% de poids en plus. De plus, même si je n’ai pas de test à montrer, on s’est déjà pris les pieds dans le tapis à cause de très mauvaises perfor­mances de pages avec beau­coup de data:uri, spécia­le­ment sur Fire­fox (proba­ble­ment sur les polices de carac­tères)

    Blob + crea­teObjectURL

    Je récu­père ma donnée, je créé un Blob à partir de cette donnée, je passe par URL.crea­teObjectURL pour créer une URL dédiée et j’uti­lise cette dernière quand je réfé­rence ma ressource.

    On résout les problèmes du data:uri mais on se coupe de IE 9, IE mobile et iOS 5. Pas gravis­sime mais j’au­rai préféré éviter.

    Par contre la solu­tion ne fonc­tion­nera de toutes façons pas pour les images ou polices de carac­tères réfé­ren­cées depuis les CSS (sauf à construire les CSS via Javas­cript mais là on entre dans des usines à gaz).

    Cas spéci­fique des vidéo et audio

    Les deux solu­tions me posent de toutes façons un sérieux problème pour les vidéo et les audio, qui peuvent être de gros volume. Je me vois mal sortir d’in­dexedDB des dizaines de méga­oc­tets (au mieux) pour construire un blob juste et avoir une URL dans ma balise HTML sans même savoir si l’uti­li­sa­teur tentera effec­ti­ve­ment de lire la vidéo ou le fichier audio.

    Pour les vidéos et les audio (mais unique­ment ces deux types de contenu) je peux réflé­chir à mettre un lien vers une vidéo de taille quasi nulle et le chan­ger dès que la vidéo est acti­vée. J’ai toute­fois un peu peur des effets de bords. Il va falloir aussi bosser en amont pour que la première image s’af­fiche bien dans le lecteur vidéo malgré l’ab­sence de la vidéo complète.

    Bidouille

    Pour l’ins­tant ma solu­tion serait :

    • Pour les images et polices de carac­tères dans les CSS : data:uri. En espé­rant que la CSS ne contient pas trop de ressources inutiles ou trop de liens vers la même ressource.
      • Au pire : Géné­rer la CSS en Javas­cript avec des liens obte­nus par crea­teObjectUrl, l’in­sé­rer dans le DOM manuel­le­ment
    • Pour les images dans le code HTML : crea­teObjectURL si possible.
      • Véri­fier tout de même si le data:uri n’est pas plus simple. La diffé­rence entre les deux sera assez faible si les images ne sont pas répé­tées plusieurs fois.
    • Pour les audio et vidéo : Désac­ti­ver le preload, rensei­gner le lien via crea­teObjectURL qu’au lance­ment de la vidéo. Pour les vidéo, penser à créer une image d’at­tente avec l’at­tri­but poster.

    Ça reste fran­che­ment du brico­lage je trouve, et ça va néces­si­ter plein de javas­cript pour géné­rer tout ça.

    Dans mon monde idéal

    Dans l’idéal j’au­rai bien aimé avoir une sorte de faux serveur web en javas­cript depuis le navi­ga­teur. Genre toute url en « local-js://xxxxx » fait appel à un objet Javas­cript qui répond ensuite ce qu’il veut.

    À défaut, un URL.createObjectURL( 'text/html', function() { return bindata; } ) serait bien pratique : Le navi­ga­teur n’ap­pe­lant la fonc­tion pour récu­pé­rer le contenu que quand il cherche à accé­der au dit contenu, au lieu de lui donner tout le contenu par avance au cas où il en aurait besoin.

    Quelqu’un a des pistes pour moi ?

  • Je veux chan­ger ça, et ça, et ça

    Je pense que je ne suis pas le seul à imagi­ner régu­liè­re­ment comment créer un nouveau langage ou modi­fier les exis­tants à ma conve­nance. Sans aller jusque là, en croi­sant ce qui se fait dans les diffé­rents langages, on trouve toujours des point inté­res­sants qu’on aime­rait voir copiés.

    Voilà donc quelques unes de mes frus­tra­tions, parce que les expri­mer permet de s’en débar­ras­ser un peu et de se concen­trer sur l’im­por­tant : ce qu’on fait avec le langage.

    Persis­tance du code en PHP

    Chaque requête web recharge entiè­re­ment l’ap­pli­ca­tif PHP. APC apporte une béquille indis­pen­sable mais ça reste au niveau de la béquille. Toute l’ini­tia­li­sa­tion est à refaire à chaque fois. Ça fonc­tionne, mais j’ai­me­rai vrai­ment un mode de PHP ou un frame­work web PHP qui permette de commen­cer direc­te­ment au trai­te­ment des requêtes sans avoir à tout refaire de zéro.

    Acces­seurs en PHP

    Toujours côté PHP j’at­tends depuis bien long­temps l’ap­pa­ri­tion d’ac­ces­seurs trans­pa­rents pour les attri­buts des objets. Ruby, Python et Javas­cript ont chacun leur façon de faire. Là il ne s’agit pas de repiquer une syntaxe au langage voisin mais bien de combler un manque.
    Sérieu­se­ment, je n’en peux plus de ces getX() et setX(). C’est encore plus pénible à l’uti­li­sa­tion qu’à la créa­tion.

    Espaces de noms

    Fut un temps je râlais beau­coup contre PHP mais ce dernier une bonne partie du retard qu’il avait. Mieux : Arrivé en dernier il s’est permis de parfois faire les choses plus intel­li­gem­ment.

    Dites, pourquoi n’ai-je pas d’es­paces de nom en Javas­cript ?

    Les « use » de PHP me manquent aussi en Ruby. Ils présentent une solu­tion élégante et pour donner des noms courts en local à des classes qui viennent d’autres espaces de noms, mais ils permettent aussi les alias pour chan­ger faci­le­ment une implé­men­ta­tion par une autre sans impac­ter le code.

    Pendant qu’on y est, pourquoi pas d’auto-char­ge­ment en Ruby ? Si je charge X::Y::Z, j’ai­me­rai bien que le langage se charge tout seul d’al­ler cher­cher le fichier X/Y/Z.rb. Ça fonc­tionne dans quasi­ment tous les autres langages mais Ruby conti­nue de faire du spaghetti d’in­clu­sion manuelle de fichiers.

    Blocs et ferme­tures lexi­cales

    Les blocs sont *la* fonc­tion­na­lité qui me fait utili­ser Ruby. On peut certes faire beau­coup de choses simi­laires avec des fonc­tions anonymes en Javas­cript ou en PHP mais c’est juste moins élégant (et ça compte beau­coup pour se sentir à l’aise).

    Par contre, sérieu­se­ment, la récep­tion des para­mètres dans les blocs est vrai­ment peu lisible. Le choix de la barre verti­cale comme déli­mi­teur est juste illi­sible.

    Le pire arrive avec les ferme­tures lexi­cales. Ruby laisse bien trop faci­le­ment utili­ser par erreur une variable venant de la portée parente. La syntaxe pour forcer une variable comme locale ajoute encore plus au côté non lisible. |x, y=3; z| ? sérieu­se­ment ?

    À côté de ça PHP et Python proposent des variables en lecture seule, ce qui limite la casse. PHP impose même de décla­rer expli­ci­te­ment les variables à impor­ter de la portée parente au lieu de décla­rer les variables locales. Diffi­cile à imagi­ner en monde Ruby mais assez confor­table au final.

    Et vous ? qu’est-ce que vous chan­ge­riez en premier ?

  • La lame de fond nodejs

    En ce moment côté star­tup et inno­va­teurs, les déve­lop­peurs javas­cript ont le vent en poupe. Pour autant, je ne crois pas que Javas­cript côté serveur soit le rouleau compres­seur qu’on veut nous faire croire.

    La syntaxe du langage est honnête, mais a large­ment autant de points néga­tifs que de points posi­tifs par rapport à l’exis­tant ailleurs.

    Si je résume, on me dit que Javas­cript a

    • Une grosse base de déve­lop­peurs à cause de son utili­sa­tion dans les pages web
    • Un runtime exis­tant sur quasi­ment toutes les machines
    • La possi­bi­lité d’avoir un seul langage côté client et côté serveur
    • Un système de proto­type
    • Un système d’event loop, api asyn­chrones et call­backs sur nodejs

    La base d’uti­li­sa­teur est un facteur très impor­tant, mais sur ceux ci une frange très mineure peut se récla­mer d’avoir une bonne connais­sance de Javas­cript. Le niveau moyen est même presque pire que sur PHP. Si on se contente de ceux qui font plus de quelques lignes et qui pour­raient passer côté serveur, la base utili­sa­teur n’est plus si fantas­tique que cela. PHP ou Java en ont proba­ble­ment autant si ce n’est plus.

    On trouve de quoi exécu­ter Javas­cript même sous Windows, mais au final on va instal­ler une machine virtuelle dédiée. Encore une fois, si on parle de côté serveur, Linux et autres BSD sont une bien meilleure cible et là Python ou Ruby sont par défaut, PHP est déployable faci­le­ment, Java est presque partout. Je n’ai jamais entendu dire que l’un des trois premiers souf­frait d’un frein à cause de la néces­sité d’ins­tal­la­tion sur telle ou telle machine.

    La possi­bi­lité d’avoir un seul langage n’est pas à négli­ger, mais au final coder du Javas­cript pour une page web dans le navi­ga­teur n’est pas comme coder du Javas­cript pour nodejs : Les API, les perfor­mances, les besoins, tout ça est diffé­rent. Même sans ça, les partages de code entre client et serveurs reste­ront anec­do­tique, Java en a fait l’ex­pé­rience il y a long­temps. Reste la syntaxe qui est la même, et évite un nouvel appren­tis­sage, mais c’est assez faible. L’ex­per­tise dans un langage est prin­ci­pa­le­ment liée à l’API et à ses impli­ca­tions, la syntaxe de base s’ap­prend rapi­de­ment.

    Le système de proto­type est effec­ti­ve­ment une des spéci­fi­ci­tés de Javas­cript par rapport aux langages courants. Ceci dit c’est un point incom­pris par quasi­ment tous les déve­lop­peurs au point que tous essayent de recréer arti­fi­ciel­le­ment un système de classe au dessus du système de proto­type. Le résul­tat est d’ailleurs un peu bancal. En théo­rie le système de proto­type ça peut être génial. Dans la réalité, sauf pour une petite mino­rité, c’est un gros point noir. Diffi­cile de consi­dé­rer ça comme un avan­tage.

    Il reste un point, parti­cu­lier : Tout l’en­vi­ron­ne­ment Javas­cript côté serveur s’est construit autour d’un système asyn­chrone bourré de call­back. S’il est facile d’y faire de la program­ma­tion spaghetti, c’est aussi une grande force et la plus grande spéci­fi­cité du langage.

    Avoir un système d’évent loop avec des accès asyn­chrones c’est réali­sable sur les autres langages, mais ça prend du temps. Il faut refaire tout un jeu de biblio­thèques. Les quelques essais actuels sont limi­tés, complexes à mettre en oeuvre, et surtout n’ont pas eu le coup de projec­teur qui a lancé nodejs.

    Et c’est un peu ça l’idée : Rien n’em­pêche Ruby, Python ou Java de créer une biblio­thèque équi­va­lente à nodejs. S’il y a une vraie valeur ajou­tée, alors ça se fera. À ce moment là, à part le coup de projec­teur, Javas­cript n’aura plus de quoi prétendre être en avance. Ça restera un bon langage, avec une excel­lente machine virtuelle, qui méri­tera proba­ble­ment d’être côté serveur, mais pas plus que les autres. Je ne vois pas ce qui justi­fiera la lame de fond que certains imaginent.

  • Joyeux effets javas­cript – file upload et Twit­ter boots­trap

    Les gens compé­tents se déchaînent et on voit main­te­nant appa­raitre des choses que nous aurions à peine imaginé du temps où j’étais inté­gra­teur web. Nous étions capable de créer tel ou tel compo­sant, mais en créant tout de zéro ou presque. Désor­mais des biblio­thèques pré-exis­tantes donnent un coup d’ac­cé­lé­ra­teur gigan­tesque.

    Aujourd’­hui je suis retombé sur le télé­char­ge­ment de fichiers, et les exemples du boots­trap proposé sont plus que convain­cants. Le menu à gauche pour gérer le posi­tion­ne­ment dans la page est lui aussi une très bonne idée bien implé­men­tée.

    Je ne peux cepen­dant pas m’em­pê­cher de me poser la ques­tion de la charge en terme de perfor­mance quand on utilise plusieurs compo­sants. Rien que baser tout ça sur jquery risque de faire mal côté mobile.