L'écosystème du Javascript

Je ne peux m'empêcher d'ajouter le site javascripting qui référence tous les framework/outils disponible en javascript (il y a moyen de voir par popularité) ce qui devrai faire grossir pas mal ta liste

Merci à tous pour vos retours. Je vais essayer de réagir de manière globale du coup.

A travers vos messages, on se rend bien compte que l'écosystème JS en tant que tel est vachement flexible. Il y'a des trucs qui sortent tous les jours et d'autres trucs qui meurent aussi rapidement. Le fait qu'il n'y a aucun organisme derrière pour formaliser un peu tout ça n'aide pas vraiment. Ceci dit, la raison de ce sujet est de dégager les outils/framework/doc de référence.

L'idée n'est pas tant de lister tout ce qui existe et qui peut être utilisé, mais plutôt des trucs qui sont incontournables de manière générale. Pour vous faire une idée, prenons le cas de video.js, qui est très populaire et très utilisé, mais comment dire, son cadre d'utilisation est très spécifique (si mon site veut utiliser de la vidéo). Du coup des trucs comme Snap.svg, spin.js, et cie ne m’intéressent pas vraiment. Ce qui m’intéresse ici, est d'avoir :

• une liste de choses qui font parti de la vie d'un projet JS quelque soit sont domaine fonctionnel
• des outils qui ont fait leur preuves (c'est à dire qui sont matures (production ready), utilisés et ont fait leur preuve)

L'idée derrière tout ceci est de pouvoir me dire que si je lance un projet en full stack JS je n'ai qu'a aller choisir dans chaque catégorie un outil. C'est aussi pour ça que je vous demande des liens vers des docs officielles (donc si possible des fondation éditrices de navigateurs webs) sur les normes actuelles et futures liées à Javascript.

Coté JS pour Desktop j'ai aussi du mal à trouver des bon candidats.

PS : Le premier topic est normalement à jour avec vos dernières informations.

Outil de templating

hogan.js

Es ce que le fait qu'il ai été développé par Twitter en fait une lib de référence ? À vous d'en juger … (Je veux dire par là qu'il est parfois difficile de savoir si une lib est une lib de référence ou non)

L'idée derrière tout ceci est de pouvoir me dire que si je lance un projet en full stack JS je n'ai qu'a aller choisir dans chaque catégorie un outil.

C'est loin d'être aussi simple que ça malheureusement. Et c'est bien ce que j'essaie de faire passer comme idée.

Il n'y a pas de stack de référence ou d'outil adapté à une tâche.

Si tu démarres un projet "fullstack" comme tu dis, tu vas devoir choisir entre React, Angular, Meteor, Angular2, etc. Et à partir de là tu pars sur des pistes totalement différentes.

Pour certains projets tu pourras te contenter d'un simple browserify et/ou gulp/grunt le cas échéant. Pour d'autres projets de plus grande ampleur tu auras besoin de webpack et son rechargement à chaud.

Malheureusement l'écosystème veut ça, y'a autant d'outils qu'il y a de projets en JS, et peu de références. Et c'est généralement très complexe de découper les responsabilités entre les différents éléments de la couche sans avoir galéré à les faire fonctionner un par un, ou sans avoir été confronté au soucis qu'il résout avant.

Hogan n'est surtout qu'une implémentation de Mustache, donc au final ce n'est qu'une lib parmi d'autres. Surtout que ses fonctionnalités sont plutôt limitées (j'aurais tendance à préférer Dot.js du coup).

A propos du full stack JS, il y a aussi Backbone.js qui est assez populaire.

Niveau doc, comme je pense que ça a été dit, ce que je préfère reste MDN : https://developer.mozilla.org/en/

Niveau développement d'applications desktop, ça reste effectivement très fouillis et balbutiant. Entre XUL, node-webkit, App.js et plein d'autres… J'ai testé plein de truc et au final, rien n'est vraiment bien, ou en tout cas pleinement opérationnel. XUL est le plus poussé, mais il y a des soucis de performance/réactivité si on commence à faire des interfaces réellement complexes. Les autres solutions nécessitent d'utiliser le HTML pour faire les interfaces, et là on se heurte aux limites du HTML que flexbox ne corrige pas encore tout à fait (la flexibilité "verticale"). Il faudrait aussi des frameworks CSS pour skinner des applications desktop, ce qui fait également défaut.

Sinon, pour des petites applis simplistes sous Windows, il reste la solution des scripts HTA combinés aux ACtiveX d'IE). Je m'en suis développé pour mon travail, car c'est exécutable sans rien nécessiter d'autres que Windows, ce qui est pratique pour les PC verrouillés de partout.

il y a des soucis de performance/réactivité si on commence à faire des interfaces réellement complexes

React est vraiment bien pour adresser ce genre de soucis. Mais la marche à franchir pour rentrer dedans est quand même assez violente :\

Juste pour revenir sur XUL : https://mail.mozilla.org/pipermail/firefox-dev/2015-July/003063.html

Pour tester la compatibilité de ES6 sur un Navigateur : http://ruanyf.github.io/es-checker/

Moi personnellement, j'ai du mal avec ce genre de truc. Je suis avant tout un dev web, séduit par le HTML. C'est pour ça que j'aime des truc comme XUL, ou bien même XAML (.NET), car ça permet de séparer totalement l'interface. Le tout stylable en CSS, donc c'est simple et puissant.

Ouais, j'avais déjà vu des infos en ce sens, mais je doute que cela se face d'ici peu. C'est tout l'écosystème de Mozilla qui est à repenser.

En éditeur de texte je te proposes de rajouter Brackets à ta liste, c'est un projet soutenu par Adobe et particulièrement puissant pour les dev front end et les intégrateurs.

Attention au plugin git de Brackets, parfois particulièrement récalcitrant. Et surtout qui empêche de lancer deux instances de Brackets en parallèle (assez chiant quand même pour un éditeur de texte…).

Atom fait très bien le taff' aussi.

Salut !

Je propose d'ajouter Meteor aux Frameworks > Server (il est déjà sous Frameworks > Client, mais comme il est autant serveur que client, …).

Et d'ajouter une section

Web Components

• http://x-tags.org/
• https://www.polymer-project.org/1.0/
• https://github.com/jayphelps/graffiti

[EDIT]

Sous "Linters / Analyseurs de code", j'ajouterais mon favoris : jscs qui est assez en vogue.

Sous Templating Engine, j'ajouterais htmlbars.

Je me rends compte qu'il y'a des bonnes propositions que je n'ai pas remonté.

Maintenant je passe "cette réponse m'a aidé" les posts que je remonte.

Sinon, je découvre Bracket qui a l'air sympa. Pour Atom, je n'en ai pas entendu que du bien, est-ce que c'est réellement une bonne référence ?

Pour Atom, il se bloque de temps en temps chez moi et je sais que je ne suis pas le seul à avoir ce genre de problèmes.

J'me permet de proposer Underscore.js à ajouter à la liste.

Alors faisons une catégorie "Bibliothèques fonctionnelles" et ajoutons-y Underscore et Lodash

Lodash et Underscore avaient pas fusionné récemment ?

Nope. C'est un projet en cours, mais si tu veux mon avis c'est pas pour tout de suite. Et même après la fusion, sauf erreur Lodash et Underscore resteront des bibliothèques distinctes en fonctionnalités mais partageant la même codebase.

J'ai entendu (au détour d'un café) "vaut mieux utiliser lodash" mais pas eu le temps de demander pourquoi, ni d'aller chercher le pourquoi du comment sur internet, j'ai l'impression que le deep-merge par exemple n'est pas présent dans underscore.

Si quelqu'un a un retour d'expérience (sur les deux libs) et objectif, c'est bon à prendre

D'accord, il me semblait que ça avait abouti ! Ca a l'air de prendre son temps du coup, c'est bien dommage…

@Javier : déjà lodash est réputé plus performant qu'underscore. Il permet aussi de faire des custom builds (qui embarquent juste les fonctions que tu comptes utiliser donc), contrairement à underscore. Enfin au niveau features, a priori lodash est un superset d'underscore : il offre les mêmes fonctions et features (arrêtez moi si je me trompe, peut-être qu'underscore a bien évolué depuis que je m'y suis intéressé) + d'autres qui ne sont pas dans underscore. Tu cites le deep merge, il me semble bien qu'il y a aussi le deep clone par exemple