The small changes made the function body of add() growing over 600 character. v8 optimizer (crankshaft) inlines the functions whose body length, including the comments, is less than 600 characters.
Je ne peux m’empêcher de trouver étrange d’inclure les commentaires. Ça ressemble à une façon d’épargner un micro-cycle de CPU assez peu pertinente. Il reste que c’est à savoir, et que mettre le commentaire hors de la fonction résout tout. Autant le savoir.
Les informaticiens se battent depuis longtemps contre ces intersticiels qui incitent à télécharger l’app native quand ils se connectent sur le site web avec un smartphone. C’est pénible, et ça ne répond pas à l’intention. C’est même horrible quand on suit un lien direct vers un contenu.
Les popins ne sont guère mieux (voire pire quand elles sont complexes à fermer). Le comble c’est quand la popin ou l’intersticiel ne sont pas adaptés à la lecture sur un écran de smartphone, et empêchent toute suite positive.
La pratique reste, parce que le marketing rêve de fidéliser avec une application dédiée, considérée comme plus qualitative mais surtout qui reste sur le téléphone.
69% of the visits abandoned our page. These users neither went to the app store nor continued to our mobile website.
On manque de chiffres, ou de gens qui veulent bien publier leurs chiffres. Celui là est juste énorme. 69%… C’est énorme. Pour juste 9% de gens qui vont cliquer sur « je veux l’app », dont certains l’ont déjà, d’autres ne l’installeront pas, la désinstalleront dans la foulée ou ne l’utiliseront pas.
À l’inverse, en remplaçant l’intersticiel par une bannière bien faite (non, pas une popin, pitié) :
1-day active users on our mobile website increased by 17%.
G+ iOS native app installs were mostly unaffected (-2%). (We’re not reporting install numbers from Android devices since most come with Google+ installed.)
Ne nous emballons pas, Google continue de mettre un intersticiel sur Gmail quand il est accédé par un smartphone Android.
Les bonnes ressources expliquant comment faire du web mobile sont rares. La plupart se limitent à parler de media query ou d’adaptation du rendu, ce qui est loin d’être finalement le plus complexe ou le plus important.
Ici Google nous parle performance, avec plusieurs étapes très concrètes, du code exemple, et un aperçu d’utilisation des magiques service workers, en tout juste une dizaine de minutes. Si vous voulez parier sur une techno qui va révolutionner le web mobile dans les 12 mois, misez là dessus.
Unicode intègre maintenant des pictogrammes depuis des années, et ça se renforce chaque version. Aujourd’hui on doit dépasser les 1000 emoji, dont certains sont en réalité des modificateurs. Avec la composition ce sont des dizaines de milliers qui sont possibles. À cela il faut ajouter des milliers de symboles, de la flèche jusqu’à l’enveloppe.
Tout ça se retrouve ou se retrouvera dans nos polices de caractères. C’est fait pour, à dessein.
Dans Unicode, et donc dans nos polices de caractères se trouve aussi une plage de symboles dite « privée ». Elle est faite pour que vous y mettiez vos propres symboles, à vous, pour vos besoins. Tant qu’on reste là dedans, je ne vois pas trop pourquoi y ajouter un pictogramme représentant un panier d’achat serait plus ou moins un hack, une bidouille, que les emojis ou les symboles déjà présents.
La seule différence est que vous êtes dans un espace privé donc que le sens de vos pictogramme est inconnu des programmes qui les utiliseront. Bon, c’est prévu comme ça au départ aussi, à dessein, et c’est aussi vrai de n’importe quelle image sur une page web.
Bref, les polices de caractères personnalisées avec des pictogrammes, un hack ? ça se discute. Uniquement si vous considérez que les plages Unicode de symboles et autres emoji le sont aussi. Ça se discute…
To get websites to load in an acceptable time using HTTP1 we have developed a series of techniques; hacks really; to eke performance out of this old protocol. They are:
- Spriting: taking multiple images, combining them into one image, and using CSS to only show part of that image in a particular place.
- Concatenating: Taking multiple CSS or JS files and sticking them into one large file.
- Serving assets from a cookie-less domain.
- Sharding: creating different domains or sub-domains to host assets like images.
Avec l’arrivée de HTTP 2, ces quatre optimisations tendent à devenir inutiles, voire contre productives.
Pour les deux premières, le pipelining devient plus intelligent (donc réellement utilisable) et au besoin le serveur peut pousser les contenus sans même attendre qu’ils soient demandés par le client.
Pour les deux suivantes, le système de compression des entêtes et de multiplexage rend le retour sur investissement d’une nouvelle connexion TCP à un domaine tiers franchement contestable. Vous risquez de perdre de la performance au lieu d’en gagner.
La leçon est intéressante. Pendant quelques années les développeurs ont cherché à contourner les navigateurs, croyant pouvoir être plus smart. Le problème c’est que les navigateurs et les protocoles ont évolué entre temps pour résoudre les mêmes problèmes. Les bouts de scotch des développeurs peuvent désormais faire plus de mal que de bien. C’est toute une littérature qu’il va falloir mettre à jour.
J’aimerai tant un site e-commerce qui ne me demanderait pas de créer un compte pour faire un achat. Qu’il me soit obligatoire de décliner nom et adresse pour par exemple acheter un livre en ligne… est plus que gênant
Je regarde la super lampe déco, je clique sur « acheter », je saisis une éventuellement adresse de livraison, puis mon numéro de carte bancaire, je valide, et voilà !
Je n’ai pas besoin de plus pour acheter mon pain à la boulangerie, un lit ou une armoire dans mon magasin de meuble, ou un livre à ma librairie. Tout ce qui vient en plus avant la finalisation de la commande me fera fuir.
Parce qu’il y a parfois un besoin d’une relation après vente, je peux comprendre qu’on me demande aussi un numéro de téléphone ou un email, même si ce n’est pas strictement nécessaire. On pourra m’y envoyer un jeton d’accès pour me relier à mes commandes ou m’authentifier si besoin.
Je ne vois aucune raison incontournable d’imposer la saisie de plus d’informations [en fait si, voir commentaires]. Je n’ai ni besoin d’un compte ou d’un mot de passe, ni besoin de décliner mon identité.
Rien n’empêche de proposer la saisie de bien plus d’informations, mais après la commande, et de façon totalement optionnelle.
Celle ci je ne peux me retenir de la copier car elle est magnifique :
$override = null;
if ($notify_admin and $conf['browser_language'])
{
if (!get_browser_language($override['language']))
{
$override=null;
}
}
À première vue, le code ne fait rien. À la seconde lecture non plus, je vous rassure.
Après explication, la méthode get_browser_language utilise un passage par référence (oui, avec ce nom là…), c’est à dire que la variable qui est passée en argument pourra voir sa valeur modifiée.
Eureka! En sortie de code on pourrait bien avoir une variable $override qui contient quelque chose. On a au passage fait une création de tableau implicite en utilisant la syntaxe avec crochets sur une valeur nulle (conseil : ne jamais faire ça si vous souhaitez rester lisible).
La seconde affectation $override=null sert si jamais get_browser_language a bien modifié $override['language'] mais a renvoyé une valeur évaluée à false.
Mais pourquoi cette seconde affectation à null ? Et bien il se trouve que la fonction get_browser_language renvoie false si elle ne modifie pas la variable passée par référence. Dans ce cas le code d’appel aurait quand même créé un tableau dans $override à cause de override['language'], il faut donc revenir en arrière et écraser ce tableau créé implicitement.
À retenir :
null.Ici en plus vu qu’on utilise déjà l’évaluation à true ou false du retour de get_browser_language, autant lui faire retourner directement la langue, ou null si aucune n’est trouvée.
Je note ici autant pour ceux qui ne connaissent pas que pour mon moi de plus tard : Autoprefixer, qui prend une CSS classique et qui ajoute les versions préfixées utiles pour les différents navigateurs.
Ça ne le fait pas bêtement, genre pour flexbox ça sait gérer les différences de syntaxes. Bref : utile.
Attention ça va réagir :)
I want to address one-by-one all of the strange and misguided arguments for Node.js in one place.
C’est chez Eric Jiang, et si c’est plein d’opinion, d’ironie et de caricature, c’est quand même vrai sur le fond.
J’avais regardé CoffeeScript il y a longtemps, mais sans être convaincu. Si j’ai besoin de faire du Javascript, je fais du Javascript. Coffee apporte bien des améliorations 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éellement percer pourquoi, j’ai l’impression qu’ils ont réussi à mieux se détacher de Javascript, et donc avoir un vrai langage distinct qui « compile » du Javascript (c’est bien l’esprit de Coffee aussi, mais je n’ai pas eu ce ressenti).
Je suis probablement plus ouvert à TypeScript ou Traceur, qui sont plus proches du langage d’origine et dont les objectifs et syntaxes sont presque « le prochain Javascript ». On a plutôt une couche de compatibilité arrière, et c’est un bon système.
L’impression que ça donne est tout de même qu’ils ont fait leurs propres extensions qui n’appartiennent qu’à eux.
Est-ce qu’on a quelque part un projet similaire, qui implémente un maximum de nouveautés des futurs EcmaScript mais qui évite d’ajouter trop de syntaxes divergentes au cœur du langage ?
Quelles sont vos expériences avec l’un ou l’autre de ces systèmes ?