SoJavaScript

aux sources des approches responsive et adaptative, de Sylvain Pollet-Villard

À propos de l’auteur

Sylvain Pollet-Villard est ingénieur (ISEN de Lille) d’études et développement expert en web front-end. Il est auteur de nombreux jeux ou expérimentations aussi funs que loufoques. Il est également bénévole pour répondre aux questions des développeurs débutants sur les forums de developpez.net, en particulier sur le forum JavaScript. Il se peut que vous le croisiez aux détours d’une ChtiJS (meetups sur JavaScript) ou d’un apéro WelshDesign (meetups sur les métiers du front, orientés UI/UX).

Critique du livre

Pourquoi développer plusieurs versions d’un site web […] ? Il est possible de concilier les usages autour d’un seul site et d’une seule URL : c’est ce que propose l’approche One Web

Sylvain Pollet-Villard

Couverture du livre
Créer un seul site pour toutes les plates-formes

Ce livre est destiné aux webdesigners, intégrateurs, développeurs web, chargés de marketing et responsables de communication. Il faut avoir au moins participé à l’élaboration d’un site afin de bien comprendre le livre. Il n’est donc pas adressé à un public débutant.

Il tente de répondre à une problématique : face à la recrudescence des objets connectés, comment faire en sorte que son site soit compatible avec tous les appareils sans avoir besoin de maintenir plusieurs versions ? (Il ne traite néanmoins pas des objets connectés, tels les montres, lunettes ou smart TV, jugés trop instables pour le moment). La réponse à cette problématique est accompagnée d’un site compagnon qui permet de mettre en pratique la théorie parfaitement maîtrisée par l’auteur.

Il y a quatre grosses parties dans ce livre :

  • Normalisation / Contextualisation : pour poser les bases et comprendre le reste du livre, uniformisation des styles, les préfixes vendeurs, événements souris/tactiles, les polyfills/shims/fallbacks, le contexte dans lequel le site est lancé (récupération des éléments essentiels tels que la hauteur de la fenêtre, l’orientation, la connexion, etc)
  • Approche Responsive : pourquoi on en a eu besoin, les unités CSS à utiliser, le viewport, les media queries
  • Approche Adaptive : histoire et différences avec le responsive, la relation avec les URL/REST/HTTP, AJAX à la rescousse pour servir des ressources adaptées
  • Outils du dév front d’aujourd’hui : préprocesseurs CSS, outils de build Grunt/Gulp, debugging (console), tests, etc

Chacune des ces parties est très complète, la précédente amène toujours la suivante et c’est donc très fluide à lire. Il y a même une partie qui explique comment concilier l’approche responsive avec l’approche adaptive afin d’offrir une expérience optimale à l’utilisateur.

Ce que j’ai aimé dans ce livre :

  • Chaque partie commence par une phrase d’introduction décrivant parfaitement ce que l’on va lire
  • Les encarts “Pour aller plus loin”, “Remarques” qui proposent au lecteur d’approfondir le sujet
  • Le site web compagnon
  • Le côté technique omniprésent mais accompagné d’exemples concrets
  • Le dernier chapitre qui liste les outils d’aujourd’hui qui nous permettent de gagner du temps (préprocesseurs CSS, outils de build Grunt/Gulp, debugging, tests, etc)
  • … et plus particulièrement la partie sur les tests

Sylvain nous offre là un livre très clair et concis (120 pages) dans l’air du temps, bourré de bonnes pratiques pour réaliser un site adapté à plusieurs appareils et donc plusieurs écrans. A la fin de ce livre, vous serez en mesure d’avoir les meilleures bases pour créer un site “responsive/adaptive”.

ISBN-10: 2212139861 / ISBN-13: 978-2212139860

JavaScript, ECMAScript, ES6/2015, W3C, V8, DOM, Node.js / io.js : qui fait quoi ?

Quand j’ai débarqué dans le monde du JavaScript, j’étais assez confus par tous ces termes qui gravitent autour. Si vous pensez que l’ECMAScript c’est une maladie juvénile liée à l’acnée et que JavaScript est un plugin de Java, cet article est fait pour vous.

tl;dr, JR ! Ce billet en bref

  • JavaScript n’a rien à voir avec Java. C’est qu’un choix de nommage “commercial/marketing”. N’oubliez pas le “S” majuscule, s’il vous plait.
  • ECMAScript, c’est une norme, une spécification, un standard. JavaScript est une implémentation de cette norme.
  • ES6, ou ES2015, c’est la prochaine (la 6ème) version majeure (qui devrait sortir courant 2015) de ECMAScript.
  • JavaScript 1.x est la terminologie utilisée historiquement par Netscape (puis Mozilla) pour nommer ses versions de JavaScript.
  • JScript était le “JavaScript” de Microsoft pour concurrencer celui de Netscape.
  • Mocha/LiveScript étaient les noms de code de JavaScript avant qu’il ne s’appelle JavaScript.
  • W3C, WHATWG : on parle de “consortium”. C’est une association de plusieurs membres influents d’entreprises, elles-mêmes influentes, qui s’unissent pour faire avancer le web.
  • V8 : C’est le moteur JavaScript de Google (les navigateurs Chrome et Opera l’utilisent). C’est ce qui sert à lire et exécuter le JavaScript. D’autres moteurs : Spider Monkey / Rhino (Netscape/Mozilla), Chakra (Microsoft)
  • DOM : c’est un standard (maintenu par le W3C) qui décrit comment représenter/modifier le code source d’une page web (le contenu, la structure et les styles). Il est attaché à JavaScript dans un navigateur (window.document). Le DOM n’est pas spécifié dans ECMAScript. C’est le WHATWG/W3C qui en a la charge.
  • Node.js ça sert à exécuter JavaScript sur un serveur à l’aide du moteur JavaScript V8. C’est une marque déposée qui appartient à une entreprise qui s’appelle Joyent.
  • io.js c’est un fork de Node.js. Ce sont les ptits gars qui font Node qui ont décidé de se défaire de l’emprise de Joyent.

J’ai cherché à en savoir plus sur chacun de ces termes. Voici mes trouvailles, n’hésitez pas à ajouter/corriger ces propos dans les commentaires.

JavaScript n’est pas Java !

JavaScript et Java n’ont de commun que le préfixe “Java”. C’est comme dans Cartoon et Carnaval. Ils n’ont de commun que le “Car”. Et bien là c’est pareil. (bon ok, y’a des trucs salaces que JavaScript a repris à Java, comme Date et Math par exemple, mais là n’est pas la question)

Ce choix de nommage est, à la base, purement commercial, marketing et historique.

Il faut remonter en 1995, alors que Sun sort le premier JDK Java. Ils veulent intégrer leur JVM dans Netscape Navigator 2.0 afin d’ouvrir leur technologie au web. Netscape, souhaitant donner une grosse plus-value afin d’enterrer totalement la rockstar des navigateurs de l’époque (Mosaic) flaire donc les avantages d’un tel partenariat.

Sun et Netscape sont alors en pleines discussions commerciale et marketing. Durant cette même année 1995, en avril, Brendan Eich (le papa de JavaScript) se fait embaucher pour créer un langage pour le navigateur. Mais attention, un langage qui ne doit pas marcher sur les plates bandes de Java.

L’enjeu de Brendan Eich est donc double. Il doit sortir de son chapeau, en très peu de temps, un tout nouveau langage et, surtout, convaincre Sun que ce nouveau langage ne fera pas de l’ombre à leur Java bien aimé.

En décembre 1995 sort le le Netscape Navigator 2.0. Dedans, le tout nouveau JavaScript (développé par Brendan Eich entre mai et novembre 1995 si on en croit la légende) ainsi qu’une machine virtuelle Java.

Mais alors, comment papa Eich a réussi à convaincre les gars de Sun que son langage n’avait rien à voir avec Java ?

Java était destiné aux développeurs expérimentés. Il imposait d’être intransigeant avec son typage, ses classes et ses méthodes static/main et il fallait compiler le code sous forme d’applet afin de l’embarquer dans une page web. Dès lors, le navigateur devait avoir la machine virtuelle pour l’exécuter.

Beaucoup trop d’étape. Beaucoup trop lourd. Beaucoup trop difficile à apprendre pour des débutants en programmation : voici comment les gars de Netscape voyaient Java.

Ils voulaient un langage plus simple. Un langage comme “Scheme” mais dans le navigateur. Un langage de script qui ne nécessite pas de compilation. Un langage qui ne génère pas d’erreur. Un langage permissif où il n’y a pas de notions de typage à la Java. Un langage qui s’exécute directement dans le HTML. Un langage facilement compréhensible par des débutants en programmation.

JavaScript se voulait donc tout le contraire de Java. Tout le complémentaire de Java, en fait.

Il a été pensé pour être facilement programmable par les débutants, il suit le concept du “vas-y que je te copie/colle ton snippet pour que ça marche”.

Les deux langages se voulaient donc complémentaires :

  • Java : permet de contrôler les éléments (hardware) de la machine. Le code est embarqué/compilé dans une applet. Destiné à un public de développeur expérimenté.
  • JavaScript : permet de contrôler les éléments de la page web afin de la rendre dynamique facilement. Le code se fait directement dans le HTML. Destiné à un public de développeur débutant/amateur.

Sun s’est vite rendu compte que son langage n’était pas destiné aux novices en programmation, c’est pourquoi ils ont laissé les gars de Netscape développer JavaScript en parralèle afin d’avoir un langage pour le web plus simple d’utisation. “Mocha” était déjà une marque déposée. “LiveScript” n’était pas très aimé car d’autres projets au sein de Netscape avait déjà des technologies “Live-quelque-chose”. Ils ne voulaient pas de “Live-ci”, “Live-ça”.

C’est ainsi que JavaScript est né, et avec lui la confusion.

Petit note marrante, Java a failli s’appeler Oak. Mais finalement, pour des raisons de trademarks (encore elles), ce fut Java. OakScript, c’est pas mal non plus, non ?

Sources : 1)

ECMAScript, ou ES de son petit nom

Non, AcnéeScript, pardon, ECMAScript, n’est pas une maladie.

ECMAScript, c’est un standard, une norme, une spécification.

JavaScript est une implémentation de cette norme. Au même titre qu’ActionScript 3 l’est, par exemple.

Un commité technique (TC39) a été mis en place au sein d’Ecma (association de membres influents de l’industrie informatique) pour définir des spécifications au langage afin d’éviter les divergences constatées à l’époque entre JavaScript (le langage de script de Netscape) et JScript (celui de Microsoft). Ces spécifications se nomment donc ECMAScript (nom de code de la norme : ECMA-262 pour être précis). 2)

Pourquoi la standardisation a t elle était confiée à Ecma et non au W3C ?

Certains disent que c’est parce que le W3C ne standardise pas de langage de programmation 3), d’autres disent que c’est Microsoft qui a forcé Netscape à choisir ce protagoniste 4). Je n’ai pas vraiment réussi à trouver la véritable raison. Mais il y a fort à parier que c’est un peu ces deux affirmations qui ont poussé Netscape à confier le bébé à Ecma.

Pourquoi ECMAScript ne s’appelle pas JavaScript ?

Qui veut JavaScript ?

Uniquement pour des raisons de “trademarks”, de marques, de gros sous (voir l’histoire ci-après). Le nom “JavaScript” appartenait à Sun, maintenant Oracle 5). Ils n’ont pas trouvé de terrain d’entente pour leur céder les droits. D’où le nom ECMAScript. Microsoft n’a pas pu utiliser non plus le nom JavaScript à l’époque, pour les mêmes raisons. C’est pourquoi ils avaient opté pour “JScript”.

Fait marrant, prouvant la détermination de Sun à ne pas laisser les autres se faire du pognon sur leur marque si eux ne peuvent pas en faire eux mêmes (alors que le nom est bien ancré dans la tête des gens). Il existait ce site, Javanko.com, qui appartenait à un homme s’appelant “Javanko” de père en fils depuis de nombreuses générations. Les avocats de Sun l’ont poursuivi afin qu’ils ferment son site car il utilisait un nom commençant par JAVA 1). Alors imaginons un organisme voulant standardiser le JavaScript … avoir les droits d’utiliser ce nom était donc perdu d’avance.

Remercions Sun pour la confusion.

Et d’ailleurs, heureusement que Sun n’a jamais attaqué Gainsbourg pour sa “JAVAnaise”. Nav’allavez pavas lave davirave avà avOravaclave.

Les versions d’ECMAScript

Il y a eu, pour le moment en janvier 2015, 4 versions majeures d’ES depuis la toute première de juin 1997.

  • ES1 / ES2 : c’est en fait un portage du JavaScript de Netscape vers ECMAScript.
  • ES3 : c’est la version majeure qui a régné entre 1999 et 2009 de laquelle on commence à se défaire.
  • ES4 : ce fut un fiasco total. Cette version n’est jamais sortie à cause des discordances entre les principaux acteurs du TC39 d’Ecma.
  • ES5 / ES5.1 : sortie fin 2009, puis révisé en 2011. Il s’agit de la 5ème édition de la norme ECMAScript, faisant suite à ES3.
  • ES6 : a été fraichement renommée ES2015. C’est la prochaine version majeure de la norme. Les moteurs JavaScript sont en pleines courses, à celui qui réussira le premier à couvrir l’ensemble des fonctionnalités
  • ES XXXX : Les prochaines versions porteront l’année de leur publication à la suite de leur nom. A noter que le numéro de version restera ancré dans la tête des gens.

Une autre version d’ECMAScript (norme ECMA-357), indépendante de celle que l’on connait, a tenté de percer : E4X. Il faut lire “ECMASCript for XML”. Rien à voir avec ES4 donc qui fait partie de la norme ECMA-262 (le ECMAScript que l’on connait tous).

Cette spécification désuète ajoutait le support natif d’XML dans ECMAScript. Le but était de se passer du DOM pour lire les informations d’un document XML. Cela a été implémenté à partir de Firefox 1.5 et vite retiré. Désactivée dès Firefox 17, retirée définitivement depuis Firefox 21.

Son échec est dû essentiellement à l’essor du JSON (qui a eu lieu en même temps vers 2004/2005 grâce à Douglas Crockford, fervent défenseur de ce format) et sa simplicité par rapport au XML.

ES6 vs ES.next vs ES Harmony

ES Harmony est l’ensemble des versions d’ECMAScript à partir d’ES5. En effet, suite à la discordance du commité (TC39) autour d’ES4, ils ont donné un nom de code à toutes les nouvelles fonctionnalités faisant suite au fiasco ES4 : ES Harmony 6). ES Harmony est donc l’ensemble des fonctionnalités suivants cette mésentente ES4 6).

ES.next est le nom de code pour la prochaine version d’ECMAScript. A l’heure actuelle, ES.next est donc la version qui suivra ES5.1, soit ES2015/ES6. Quand ES2015/ES6 sera la dernière version publiée, ES.next sera ES2016/ES7 (si une version 7 est publiée en 2016) et ainsi de suite.

ES6 a été pendant longtemps le nom de la version majeure suivant ES5.1. L’année de publication viendra compléter ce nom, comme on peut le voir sur cette couverture du brouillon en cours. En effet, “6th edition” est toujours présent sur la couverture. Cela laisse sous-entendre que les deux noms cohabiteront.

JavaScript 1.x, JScript, Mocha/LiveScript

Mocha/LiveScript étaient les premiers noms de code de JavaScript (voir le point “JavaScript n’est pas Java !” ci-dessus pour savoir pourquoi ils n’ont pas été sélectionnés).

JavaScript 1.x, c’est la règle de nommage spécifique à Mozilla. Historiquement, un nouveau navigateur venait avec son lot de nouveautés JavaScript qui voyait alors son numéro de version s’incrémenter. Chaque version ayant un équivalent ECMAScript 7) (ou presque).

  • JavaScript 1.0 : Netscape Navigator 2.0, tout premier navigateur ayant JavaScript
  • JavaScript 1.1 : Netscape Navigator 3.0 / ECMAScript 1
  • JavaScript 1.2 : Netscape Navigator 4.0 à 4.05 / ECMAScript 1 + des nouveautés non standardisées encore
  • JavaScript 1.3 : Netscape Navigator 4.06 à 4.5 / ECMAScript 1 remis à niveau pour être consistent avec la spéc.
  • JavaScript 1.4 : seulement utilisé en interne chez Netscape, sur de la techno côté serveur.
  • JavaScript 1.5 : Netscape Navigator 6+ / Firefox 1 / ECMAScript 3 édition 1999
  • JavaScript 1.6 : Firefox 1.5 / ECMAScript 3 + des fonctionnalités du mort-né E4X
  • JavaScript 1.7 : Firefox 2 / ECMAScript 3 + des fonctionnalités des futures normes
  • JavaScript 1.8 : Firefox 3 / ECMAScript 3 + des fonctionnalités des futures normes
  • JavaScript 1.8.1 : Firefox 3.5 / Idem que JavaScript 1.8 + le nouveau compilateur JIT : Tracemonkey
  • JavaScript 1.8.5 : Firefox 4 / ECMAScript 5

Le processus de livraison de Firefox s’étant calqué sur celui de Chrome (1 version par mois), il n’y a plus eu d’évolution du numéro de version de JavaScript. Chaque nouvelle version du navigateur Firefox embarque de plus en plus de nouvelles fonctionnalités du prochain ECMAScript.

Quant à Internet Explorer, flairant le succès de ce langage de script, décide de sortir sa version de JavaScript (appelée JScript) 8).

  • Internet Explorer 1 : Basé sur le code source Spyglass Mosaic. Un fork du tout premier navigateur : NCSA Mosaic.
  • Internet Explorer 2 : Il est inclut dans Windows 95. JScript n’est pas encore présent dans ces deux premiers navigateurs.
  • Internet Explorer 3 : Première apparition de JScript sous l’appellation JScript 1.0, plus ou moins JavaScript 1 de Netscape
  • Internet Explorer 4 : JScript 3.0, plus ou moins JavaScript 1.1 de Netscape
  • Internet Explorer 5.5 : JScript 5.5 / ECMAScript 3 plus ou moins
  • Internet Explorer 6 : JScript 5.6 / ECMAScript 3 plus ou moins
  • Internet Explorer 7 : JScript 5.7 / ECMAScript 3 plus ou moins
  • Internet Explorer 8 : JScript 5.8 / ECMAScript 3 plus ou moins. Cette version est la dernière sous le nom JScript.
  • Internet Explorer 9 : ECMAScript 5 plus ou moins. A partir de IE 9, l’appelation JScript disparait au profit de “JavaScript”, correspondant à la version 5 d’ECMAScript
  • Internet Explorer 10 : ECMAScript 5.1 + des nouveautés du prochain ECMAScript
  • Internet Explorer 11 : ECMAScript 5.1 + des nouveautés du prochain ECMAScript

W3C, WHATWG

Le W3C et le WHATWG, en gros, c’est un peu comme le groupe Ecma. Ce sont des hommes/femmes vachement calés dans les technologies du web et qui font avancer les standards. Ils viennent de tout horizon mais bien plus souvent des grosses entreprises liées au web telles Google, Apple, et consors. Les standards ont pour vocation à être implémentés dans les navigateurs, utilisés par les développeurs, et évoluent en fonction de feedbacks, de critiques, etc.

On parle de “consortium”. C’est une association de plusieurs membres influents d’entreprises, elles-mêmes influentes, qui s’unissent pour faire avancer les standards du web.

Mes définitions grossière (elles sont réductrices de tout le travail fournit pas ces organisations) :

  • Le W3C 9) : ils “figent” et publient diverses spécifications de standard liés au web et lui attribuent un petit nom. DOM level XXX, xHTML, HTML5, etc…
  • Le WHATWG 10) : c’est un groupe du W3C créé par une entente Apple/Mozilla/Opera. Ils font dans le “live”. Comprendre qu’ils font évoluer sans cesse la spécification. Une fois suffisament évoluée, ils décident de la figer et un autre groupe du W3C reprend le bébé pour le figer/publier.

Les moteurs JavaScript

Ils permettent de lire et d’exécuter du code JavaScript. Il y en a énormément 11). Certains vivent dans un navigateur, d’autres non.

  • V8 est le moteur JavaScript de Google (les navigateurs Chrome et Opera l’utilisent).
  • Spider Monkey fut le premier moteur JavaScript de Netscape Navigator, puis ensuite de Firefox
  • Chakra est celui de Microsoft

Le DOM, Document Object Model

Le DOM est un standard 12) (maintenu par le WHATWG/W3C) qui décrit comment représenter/modifier le code source d’une page web (le contenu, la structure et les styles).

Voyez-le comme une sorte de modèle (imaginez ça comme un “plugin”) attaché à l’objet racine de JavaScript (window) quand il s’exécute dans un navigateur (accessible via window.document). Mais il peut très bien être présent dans d’autres langages. Il est “neutre”. C’est le WHATWG/W3C qui a la charge de le faire évoluer. En ce moment (janvier 2015), c’est le WHATWG qui le fait évoluer quasi quotidiennement. On parle alors de “Living Standard”.

DOM veut dire Document Object Model, c’est tout simplement le code HTML qui est transformé en arbre afin d’être manipulé, transformé.

Le DOM est né assez simplement. Brendan Eich s’est vite rendu compte que pour écrire du code dans le HTML (principe de base de JavaScript), il fallait que ce code puisse manipuler le code source HTML 1). Il a alors pensé à un système qui permet :

  • de faire appel à tous les liens : document.links
  • d’appeler le 2ème formulaire : document.forms[1]
  • carrément d’appeler le formulaire s’appelant toto : document.forms.toto

Ainsi naquit le DOM primitif qui devint plus tard le fameux DOM level 0 13), une fois standardisé.

Node.js

Node est né en 2009 des mains de Ryan Dahl. Il est basé sur le moteur JavaScript V8 et permet donc d’exécuter du JavaScript sur un serveur.

C’est une marque déposée 14) qui appartient à une entreprise qui s’appelle Joyent.

io.js

C’est un fork de Node.js. Ce sont les ptits gars 15) qui faisaient Node qui ont décidé de se défaire de l’emprise de Joyent en faisant évoluer io.js plutôt que Node.js directement. Ils ont un modèle de gouvernance 16) très souple où tout le monde peut s’exprimer. Ils opèrent de la même façon que le W3C ou qu’Ecma (comprendre il y a un Comité Technique). Ces membres sont les contributeurs principaux du projet (comprendre les serials commiters) mais d’autres personnes externes, comme Domenic Denicola membre du TC39 d’Ecma / Google Chrome Team, sont entrées au sein de ce comité. Cela ne peut apporter que du bon à io.js. En l’occurrence des ententes entre ECMAScript et le moteur V8.

Et après ?

La guerre des navigateurs, ça a du bon.

C’est ainsi qu’est standardisée une technologie.

C’est ainsi que les fonctionnalités nous arrivent à nous, développeurs.

C’est ainsi les rythmes de release sont de plus en plus rapide.

C’est ainsi que nous pouvons nous exprimer afin d’arriver à un consensus final.

La diversité fait du bien, grâce à cette guerre, je dirais plutôt paix mouvementée, la norme tout juste sortie est déjà presque totalement implémentée dans nos navigateurs préférés.

Pour notre plus grand plaisir et le plus grand plaisir de nos clients. C’est-à-dire nous, en fait, consommateurs de l’Internet !

Sources

le Guide Complet, de Nicolas Froidure

Il existe deux versions du livre. Une version dite “de poche” et une autre plus complète. Cette dernière a des chapitres en plus comparée à la première, pour aller plus loin : les performances, les design patterns, les frameworks et la boite à outils du développeur JavaScript. Si vous hésitez, prenez cette version “longue” qui vous servira pour une deuxième lecture, plus technique.

À propos de l’auteur

Nicolas Froidure est un développeur JavaScript full-stack, un fervent défenseur des streams et un utilisateur du premier jour de Node.js. Il écrit de nombreux plugins, outils et programmes Open Source. De plus, il est un des piliers de FranceJS, regroupant les communautés francophones autour de JavaScript, ainsi que de ChtiJS, communauté JavaScript de Lille. N’hésitez pas à y aller si vous êtes dans le coin, Nicolas est quelqu’un aussi accessible que sympa avec qui il est très enrichissant de discuter de JavaScript (entre autre !).

Critique du livre

L’idéal […] est de permettre à monsieur tout-le-monde de devenir un développeur JavaScript

Nicolas Froidure JavaScript™

Couverture du livre JavaScript™
JavaScript™, Le Guide Complet

Ce livre est parfait pour les débutants, voire intermédiaires, en JavaScript. Il s’adresse à toute personne désireuse de devenir développeur(euse) JavaScript. Le livre s’adresse aussi aux personnes n’ayant pas, ou peu, de bagages en programmation. Le style d’écriture clair et précis de l’auteur vous permettra d’être assidu aux 400 pages de la lecture. (359 pour la version de poche)

Selon moi, c’est le livre à lire aujourd’hui, en 2014, si on souhaite apprendre, ou ré-apprendre JavaScript avec les outils et méthodes modernes. L’auteur, en plus de nous apprendre le JavaScript, nous distillera tout au long de la lecture les bonnes pratiques du quotidien (participer sur Github/MDN, l’Open Source, réunion de développeurs, comment faire sa veille technologique) en plus de son expérience personnelle.

Vous apprendrez, tout au long des 12 chapitres, à maîtriser JavaScript de A à Z, de son exécution dans la page web au serveur (Node.js). Toutes les fonctionnalités de JavaScript y sont expliquées très précisément et se veulent, en plus, accompagnées d’un exemple concret. En effet, chaque exemple sert à la création d’un jeu de Memory (cartes retournées, retrouver les paires), véritable fil rouge de la lecture. Le code est disponible sur le compte Github de l’auteur. C’est une des choses que j’ai aimées dans ce livre. L’explication théorique d’une fonctionnalité est directement mise en relation avec un cas concret.

Les grandes parties du livre sont :

  • L’histoire de JavaScript
  • Structure d’un fichier JavaScript
  • Utilisation des objets/fonctions natifs
  • Gestion des erreurs
  • Sensibilisation à l’héritage, prototype, etc
  • Comprendre ce qu’est le DOM
  • AJAX et le JSON
  • HTML5 (ApplicationCache, localStorage, TouchEvents, etc)
  • Les outils de débogage dans le navigateur Chrome
  • Node.js (introduction)

… entre autres. Je pense aux annexes “pour aller plus loin”. Nicolas parle également de la prochaine norme de JavaScript (ES6) dont certaines fonctionnalités sont déjà disponibles dans certains navigateurs (les tableaux typés par exemple). Un autre point fort du livre est la “check-list” de ce qu’il y a à retenir d’important à la fin de chaque partie.

Enfin, le gros plus de ce livre est qu’il n’utilise que le “Vanilla JS” (comprendre du pur JavaScript, sans framework). Cela laissera donc au lecteur toute objectivité s’il souhaite en utiliser un plus tard.

Le JavaScript est un langage en plein essor. On n’apprend pas le JavaScript en 2014 comme on pouvait l’apprendre en 2003, 2007 ou encore en 2010. Ce livre est donc, aujourd’hui, un des meilleurs (en français!) pour apprendre JavaScript avec les outils et méthodes de 2014 et le sera encore pour quelques années je pense.

ISBN-10: 2822408653 / ISBN-13: 978-2822408653

de Cody Lindley

TL;DR Ce livre est réservé, selon l’auteur, à des débutants ayant déjà manipulé JavaScript ou une librairie JavaScript (jQuery par exemple). Il enseigne en profondeur le fonctionnement des objets JavaScript : les objets natifs (Object, Array, String, etc), les primitives ("string", 12, false, undefined, null) et les objets définis par le développeur. Comme tout est objet, ou peut être utilisé comme tel en JavaScript, l’auteur part du principe que si ce point est compris, alors le lecteur aura toutes les bases pour comprendre le langage et ainsi passer d’un développeur utilisant une librairie à un développeur JavaScript

A book to turn a JavaScript library user into a JavaScript developer

Cody Lindley JavaScript Enlightenment

Couverture du livre JavaScript Enlightenment
JavaScript Enlightenment

Ce livre, écrit par Cody Lindley, transformera, selon lui, les développeurs utilisant des librairies (par exemple, jQuery) en développeur JavaScript. Je n’ai pas compris pourquoi. Selon moi, ce livre aurait dû s’appeler “JavaScript : Object Enlightenment”.

Contexte :

Ce livre est sorti en 2011 et se base sur la spécification ECMA-262, Edition 3 (JavaScript 1.5), de son petit nom ES3. Depuis, ES5, qui a enrichi énormément JavaScript, est sorti en juin 2011 et nous sommes à l’aube de la sortie d’ES6. De fait, ses explications sont, au jour d’aujourd’hui, incomplètes et pourraient donner au lecteur une vision de JavaScript ne reflétant pas la réalité. Il aborde, très rapidement, la librairie underscore qui permet d’apporter à JavaScript (ES3) des fonctions avancées pas encore disponible dans les navigateurs implémentant la norme ES3 (IE8-). De fait, lu avant 2011, ce livre est parfait pour comprendre la vraie nature de JavaScript et des fonctionnalités qu’il offre. Lu aujourd’hui, fin 2013, bien qu’il soit efficace pour assimiler le fonctionnement des objets en JavaScript, il m’a semblé être insuffisant pour apprécier le périmètre complet de JavaScript.

Les plus :

  • “JavaScript Object Enlightenment” : les objets n’ont plus de secret pour moi
  • Function, Function.prototype, le scope et this très bien expliqués
  • Bonnes distinctions entre les primitives et objets complexes
  • Le résumé à la fin du livre de ce qu’on doit avoir retenu
  • Ecriture concise, claire bien qu’un peu trop d’expressions familières
  • Des liens vers des jsFiddle pour pouvoir tester les bouts de code

Les moins :

  • Trois objets natifs manquants : Date, Error et RegEx. Car, selon l’auteur, son livre n’est pas un guide exhaustif et ces objets n’apporteraient rien de plus à la compréhension du fonctionnement objet de JavaScript. Alors pourquoi liste - t - il des propriétés de Number, Array, etc ?
  • Beaucoup de répétitions ennuyeuses de l’auteur (leverage, the take away, grok, etc) qui rendent la lecture parfois chronophage
  • Les exemples de code manquent de vie : que du foo et du bar. J’aurais aimé plus de cas concrets

Conclusion

JavaScript Enlightenment aurait pu être une référence intemporelle sans ses listes de propriétés d’objets ES3 et l’exemple sur underscore. Outre ce point négatif et une fois habitué au style littéraire de l’auteur, ce livre conviendra parfaitement aux débutants expérimentés qui comprendront parfaitement la logique objet de JavaScript

ISBN-10: 1449342884 / ISBN-13: 978-1449342883

sur Ubuntu et hébergement alwaysdata

Comme je l’ai dit dans le premier post Pourquoi créer son blog (de geek) avec Octopress ?, il ne faut pas avoir peur de taper quelques lignes de commande pour gérer le blog. Aucune interface graphique n’est à disposition. Octopress a besoin de quelques prérequis pour fonctionner :

  • git pour récupérer Octopress, le mettre à jour et versionner ses fichiers
  • Ruby 1.9.3 utilisant une machine virtuelle (par exemple RVM)

Pour le reste, comme chaque environnement est spécifique, le mieux est de lire la documentation très rapide et claire. Cependant, si vous êtes, comme moi, sous Ubuntu (12.04), voici comment j’ai procédé (fin août 2013) :

Installation des dépendances (Git, RVM, Ruby)

# Installation de git
sudo apt-get install git-core

# Installation de RVM (bien suivre les étapes)
curl -L https://get.rvm.io | bash -s stable --ruby

# Installation de Ruby 1.9.3
rvm install 1.9.3

# Indiquer à rvm d'utiliser Ruby 1.9.3
[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm"
rvm use 1.9.3

# Récupérer le gestionnaire de paquets Ruby (équivalent de npm pour Node par exemple)
rvm rubygems latest

# Vérifier que la version de Ruby est bien la 1.9.3
ruby --version

Installation d’Octopress

# Nommer le répertoire cible par le nom du blog (dans mon cas : sojavascript)
git clone git://github.com/imathis/octopress.git sojavascript

# On se met dans le répertoire fraîchement créé qui est d'ailleurs versionné avec git
cd sojavascript
# Un message demandera si vous voulez faire confiance au fichier .rvmrc (il indique quelle version de Ruby utiliser. En l'occurrence, la version 1.9.3)
yes

# Octopress dépend de packages (gem) tiers. Il faut installer la gem "bundler" (équivalent de Bower pour Node) qui va inclure ces dépendances au projet (listées dans le fichier Gemfile)
gem install bundler

# Installation des dépendances
bundle install

Pour le moment, je n’ai rien fait de plus (si ce n’est expliquer en français) que ce qui est indiqué sur la page d’installation d’Octopress.

Configuration du blog et de l’hébergement

Personnalisation du blog

A ce stade, Octopress est installé mais le blog n’est pas encore généré. En effet, il va falloir paramétrer les variables “d’environnement” afin qu’il soit à notre image ! Examinons les dossiers et les deux fichiers de configuration importants :

|_ .themes
|_ plugins
__ _config.yml
__ Rakefile

# Des tas d'autres fichiers de configuration (git, gem, config ruby, etc) non nécessaires pour une personnalisation basique
  • .themes : Par défaut, il n’y a que le thème “classic” mais d’autres peuvent être installés.
  • plugins : Par défaut, les utilitaires de base inclus dans Octopress qui apportent des fonctionnalités intéressantes telles que générer les catégories du blog, intégrer des fiddle / gist / codeblock dans les articles, embarquer des vidéos, etc
  • _config.yml : ce fichier recense les variables d’environnement nécessaires à la personnalisation du blog
  • Rakefile : ce fichier définit toutes les tâches de gestion du blog (pour installer un thème, pour générer le blog, le déployer, etc) et les informations de l’hébergement

Ouvrir le fichier _config.yml. Il est très compréhensible et les variables parlent d’elles-mêmes. On y configure, entre autres, le format de date, nos identifiants de réseaux sociaux, le système de commentaires des posts.

Configuration de l’hébergement

Encore une fois, si vous n’avez pas choisi la même solution que moi, la documentation Octopress est très complète. J’ai choisi alwaysdata car c’est gratuit pour stocker ce type de blog, on peut se connecter via ssh (très important pour Octopress) et il propose moults technologies intéressantes (Mongo, Couch, Rails, Django par exemple).

Une fois inscrit, dans le panneau d’administration SSH, il faut cocher la case pour activer SSH.

# Ensuite, se connecter via ssh :
ssh user@ssh.alwaysdata.com

# Créer le répertoire qui contiendra le blog. Dans mon cas :
cd ~/www/
mkdir sojavascript

Revenir dans le panneau d’administration SSH afin de définir le répertoire home. Ainsi, à chaque connexion, on démarrera directement de ce dossier. (Dans mon cas : /www/sojavascript)

Dans le panneau d’administration des sites, il faut paramétrer le blog :

  • le répertoire qui contiendra le code du blog. Dans mon cas : /www/sojavascript/
  • les DNS attachés à l’hébergement (peu importe d’où ils viennent, je les ai pris chez OVH). Dans mon cas : sojavascript.com, sojavascript.fr

Ouvrir le fichier Rakefile afin de configurer l’hébergement et renseigner les informations. Dans mon cas :

ssh_user       = "cmoreau@ssh.alwaysdata.com"
ssh_port       = "22"
document_root  = "~" # Car j'ai paramétré par défaut le répertoire HOME lors de la connexion SSH
rsync_delete   = true
rsync_args     = ""  # Any extra arguments to pass to rsync
deploy_default = "rsync"

Génération et déploiement du blog

Avant de générer le blog, il faut lui choisir un thème. Par défaut, Octopress inclut un thème classique mais d’autres peuvent être utilisés selon les goûts et les couleurs de chacun.

rake install # équivaut à rake install['classic']. Remplacer classic par le nom d'un autre thème le cas échéant

Cela va tout simplement créer deux nouveaux dossiers qui vont être copiés à partir de .themes/classic

  • sass : contient toutes les feuilles de style
  • source : contient les fichiers de templates du blog

A ce stade, le blog a un squelette, on peut donc le générer (css à partir de sass, html et JavaScript à partir des templates).

# Génération du blog
rake generate

Un nouveau dossier est créé : public. Il contient donc le blog statique qui sera déployé sur le serveur d’hébergement.

# Déploiement du blog
rake deploy

A noter que rake gen_deploy est un alias pour réaliser les deux opérations ci-dessus.

Conclusion

Si tout s’est bien passé, votre blog statique propulsé par Octopress est disponible sur le net !

D’autres articles sur Octopress suivront, notamment :

  • profiter de la puissance de Git
  • poster un article, modifier les méta données, ajouter une nouvelle page
  • franciser tous les termes, malheureusement, “en dur” dans le code
  • corriger les bizarreries qui ne sont pas encore corrigées dans la branche principale (meta description et keywords)

et laisser tomber le gros Wordpress

Soyons clairs, je ne connais pas Wordpress intimement. Ce sous-titre a simplement une vocation trollesque :) Je n’ai jamais travaillé avec, si ce n’est l’avoir installé “pour tester”. Cet article ne sera donc ni une comparaison Octopress/Wordpress ni une critique de Wordpress qui n’a d’ailleurs rien à prouver. A l’heure où j’écris ces lignes, environ 70 millions de personnes pourront vous dire que Wordpress, c’est le pied. Par contre, un nombre plus limité vous parlera d’Octopress.

Pourquoi j’ai choisi Octopress ?

Parce que c’est cool et comme ça, je passe pour un bon geek crédible ! Non ? Tant pis j’aurais essayé :)

Avant de me lancer dans un blog, j’avais quelques besoins et contraintes :

  • ne pas payer un hébergement supplémentaire pour me lancer dans le blogging. Après tout, ce n’est peut-être qu’une lubie qui s’estompera dans quelques temps ! dixit le type qui a quand même acheté un nom de domaine
  • mettre à jour et déployer le blog le plus simplement possible (comprendre un clic ou une ligne de commande)
  • pas d’interface admin lourde avec gestion de droits / utilisateurs / plugins etc
  • pourvoir installer / supprimer un thème facilement
  • être responsive et s’adapter à tous les écrans
  • configurer simplement l’aspect social

Après avoir écumé les forums, les benchmarks, les différences entre plusieurs plateformes de blog et CMS, mon choix s’est donc arrêté sur Octopress qui répondait, et répond toujours, à mes besoins et contraintes.

Un blog fait par des geeks, pour les geeks

Octopress en a fait sa devise : A blogging framework for hackers.

A blogging framework for hackers

Il ne faut pas avoir peur de :

  • git,
  • oublier ftp pour deployer son blog (c’est possible avec ftp, mais plus contraignant),
  • s’y connaitre un peu dans l’univers Ruby (Gems, Rake),
  • Jekyll qui permet de générer les pages statiques à partir de templates,
  • taper des lignes de commande

Vous êtes encore là ? Ne partez pas ! Il y a tellement d’avantages.

Les avantages

Le principal avantage c’est la création et la mise en ligne du blog qui tient en une ligne : rake gen_deploy

Votre blog est à jour et disponible sur le net. Bien sûr, cela demande un peu de configuration de fichiers avant, mais rien d’insurmontable ! Surtout que la documentation est excellente.

Performances & Scalabilité

La commande ci-dessus, rake gen_deploy, va générer du html, du javascript, du css et déployer le blog sur le serveur. C’est tout. Ce qui est un point fort indéniable : un hébergement gratuit est suffisant au départ pour tester la bête qui ne demandera pas, ou très peu, de ressources. Délivrer une page statique ou une page dynamique ? Niveau performance et scalabilité, je crois que le test et vite fait.

Sécurité

Il n’y a donc pas de langage serveur, pas de base de données, donc pas de risque de se faire attaquer de ce coté. Il faut néanmoins faire attention à la conf’ serveur qui est le seul vecteur potentiel d’attaque.

Maintenance

Oubliez donc les mises à jours PHP, MySQL, etc … quelques simples lignes de commande permettront à la rigueur de mettre à jour Octopress si vous le souhaitez

Gestion des commentaires & réseaux sociaux

Octopress peut-être lié à un système de gestion des commentaires (j’ai choisi Disqus). Mais il est possible d’en utiliser un autre, il suffit de l’indiquer dans le fichier de configuration. De la même façon, on gère tous les réseaux sociaux dans ce fichier (_config.yml).

Les inconvénients

Voici des choses qui pourraient vous manquer si vous venez de Wordpress, par exemple :

Adieu interface admin

Aucune interface administrateur avec Octopress. Pour poster, il faudra donc être sur votre poste ayant ruby installé pour pouvoir générer/déployer le blog. Ce qui est l’inconvénient majeur, j’en conviens.

Gestion des images

Tout se fait à la main sous Octopress. De la découpe, au redimensionnement, à l’upload, au code dans votre article pour insérer l’image.

Internationalisation

Ce qui est dommage, c’est qu’il faille toucher à certains fichiers du coeur pour modifier l’anglais. On aurait apprécié une apporche plus simple pour “franciser” tous les termes plutôt que de devoir plonger dans les fichiers sources.

Tout régénérer à chaque changement

Que vous changiez une lettre dans un fichier ou ajoutez un nouvel article, il faudra régénérer tout le blog. Du coup, un blog avec un nombre conséquent d’articles peut engendrer une attente non négligeable. (j’ai vu quelque part 1min10 environ pour 1’000 articles).

Conclusion

J’ai donc créé mon blog avec Octopress pour la simplicité, la solution robuste de blogging et les performances qu’il offre tout en nécessitant de faible coût (voire nul) de fonctionnement. A titre d’exemple, voici comment je publie un article :

  • ouvrir un gist au format markdown (.md) pour pouvoir travailler dessus de n’importe où, le faire corriger, etc.
  • Une fois corrigé et révisé je me connecte sur ma machine, me place dans le répertoire où tout le code du blog est versionné (git) et lance rake new_post["Mon titre d'article"]
  • J’ouvre le fichier fraîchement généré, je change les quelques options de configuration (tags, commentaires actifs ou non ?, description, etc.) et copie/colle l’article
  • rake gen_deploy

Pour aller plus loin

D’autres articles sur Octopress suivront, notamment :

de Douglas Crockford

Ce livre, écrit par Douglas Crockford, est destiné à un public intermédiaire en JavaScript, ayant déjà connaissance des bases du langage. Il est court, une centaine de pages sans les annexes. Les “bonnes pratiques”, selon l’auteur, sont décrites de façons claires, concises et facilement compréhensibles pour peu que vous ayez déjà des notions en JavaScript.

Couverture du livre JavaScript: The Good Parts
JavaScript: The Good Parts

Afin de bien comprendre le but du livre, il est nécessaire de savoir qui est ce Douglas “Papa” Crockford et pourquoi JavaScript a des mauvais côtés. Sir D. Crockford est considéré comme l’un des pères de JavaScript par la communauté éponyme. Il est le créateur du fameux format JSON et de l’outil JSLint. Le premier est un format d’échange de données facile pour nous, développeurs, à lire et à écrire et, indépendant de tout langage. Il est très utile pour la communication entre un client et un serveur de par sa légèreté et ses outils (parse <> stringify). Par exemple, ceci est un JSON :

{
  "message": "Compréhension OK !", 
  "erreur":  false, 
  params:    ["n'importe", "quoi", 1] 
}

Le deuxième est un outil qui juge la qualité d’un code JavaScript. Il remonte toutes les “mauvaises pratiques” qu’il faut éviter en JavaScript. Par exemple, pour une comparaison il faut privilégier l’opérateur === plutôt que ==. Si vous utilisez ==, l’outil remontra une erreur.

JavaScript, quant à lui, a connu un passé tumultueux. En résumé, il est sorti des laboratoires de Netscape (anciennement Mozilla) dans le but de réaliser des interactions simples avec le document web. En pleine guerre contre Internet Explorer, c’était à celui qui sortirait la meilleure fonctionnalité avant l’autre. Heureusement, une norme a vu le jour, ECMAScript, ce qui a permis de standardiser le langage. Mais le mal était fait ! De cet affront ont résulté des fonctionnalités bénéfiques pour le langage, mais aussi des maléfiques. Pour ne pas casser les pages web réalisées avec le JavaScript d’Internet Explorer, et celles construites avec celui de Netscape, une nouvelle version de JavaScript ne doit pas tuer la précédente sous peine de tuer de nombreux sites ! C’est pourquoi les mauvaises conceptions cohabitent tranquillement avec les bonnes.

Douglas Crockford est donc un homme qui aime la rigueur, la qualité du code et qui le veut simple de lecture aussi bien par l’homme que par la machine. Il nous apprend donc dans ce livre à apprécier les bonnes fonctionnalités et à oublier les maléfiques ! Il le fait par des exemples concrets et explique clairement sa démarche par l’apprentissage. Bien sûr, certains points sont à la bonne appréciation du lecteur, mais l’auteur nous explique pourquoi telle ou telle fonctionnalité est à écarter. Libre à nous, ensuite, de la garder ou non.

Ce livre m’a donc littéralement ouvert les yeux sur certaines pratiques que je pensais bonnes, mais qui sont, quand on creuse, mauvaises ou susceptibles de faire tomber notre code à la moindre secousse.

A la fin de ce livre, vous serez donc avertis de ce qu’il faut faire en JavaScript pour éviter les pièges classiques qui font malheureusement partie du langage de par son historique. Si vous avez l’ambition de parfaire vos connaissances en JavaScript, vous devez lire ce livre !

Il existe une version Version Française, JavaScript : Gardez le meilleur, traduit par Patrick Fabre. Cependant, je pense qu’il est préférable de le lire en Version Originale si vous êtes à l’aise avec l’anglais. Car dans la traduction, ce qui ne devrait pas être traduit, selon moi, l’est. Par exemple, la closure devient la fermeture. Pourquoi apprendre de nouveaux termes techniques que nous ne reverrons nulle part ailleurs ?

ISBN-10: 0596517742 / ISBN-13: 978-0596517748