C'est l'histoire de… des frameworks Javascript ! Ce cycle éternel…

[Sephi-Chan]

De mémoire, les dernières versions de IE Edge implémentent très bien ES6 et CSS:
https://developer.microsoft.com/en-us/mi...rsshaders/

Ce qui est en fait très dommageable, je trouve, c'est que jQuery amène une approche très obsolète face aux API actuelles du JS (à moins que jQuery n'ait monté de version entre temps?!). Javascript a fortement évolué (surement grâce aux serveurs JS, qui en ont bénéficié en retour!) et jQuery reste embourbé dans de vielles méthodes et structures...

(et pareil: je pense que jQuery va faire comme Flash: 2000: flash c'est génial, 2010: Flash c'est de la merde, faite du jQuery c'est génial, 2020: jQuery c'est de la merde, faite du React, 2030: React c'est de la merde, faites du ...)

[Je vire mon propre message, sinon, ça va diverger comme discussion ^^]

Entre React et jQuery il y a eu Backbone (et ses extensions, ses concurrents…).

Je ne vois pas le mal à avoir des outils nouveaux qui sortent (en dehors de l'effet Javascript fatigue) dans la mesure où chaque génération apporte quelque chose.

Avec la génération actuelle, React + Redux, on t'encourage à utiliser ES6 (parfois via Babel, pour cibler tous les navigateurs en compilant le Javascript 6 en Javascript 5), à créer des applications complexes qui fonctionnent comme des fonctions pures (un état + une action = un nouvel état), donc prédictibles, faciles à tester, etc.

A chaque fois on y a gagné : Flash était pourri parce que ça demandait un runtime tiers merdique et truffé de failles, soumis au bon vouloir d'un éditeur, jQuery a relancé le Javascript et a rendu accessible un tas d'opérations fastidieuses, de nos jours les API des différents navigateurs sont assez proches. Bref, on avance pour le mieux, et ceux qui ne veulent pas utiliser Javascript (ou par petite touche) peuvent ne pas le faire ou bien profiter de ces avancées.

[Ter Rowan]

je suis assez d'accord avec Sephi

Autant changer de framework à chaque projet est à mon sens complètement contre productif (contre sens même à la définition de framework)

autant considérer qu' un framework ne doit pas être obsolète au bout de dix ans me semble extrêmiste. 10 ans c'est long quand même, quelque part, dans une carrière ça voudrait dire utiliser 4 frameworks, si on pouvait en arriver là, ce serait plutôt industriel

[Xenos]

Ce que je trouve surtout dommageable (et peut-être mal exprimé), ce sont les deux lames de fonds qui se cachent derrière:

• Des codeurs qui ne savent finalement qu'appliquer des tutos dans un framework donné, sans tenter de comprendre le langage derrière

• Des langages qui sont pliés pour faire ce pour quoi ils n'ont pas été prévus. Quant on se sert d'un langage dans le cadre de ce qu'il sait faire, les FW deviennent vite inutiles. Le web est conçu pour s'affranchir du support, et les FW entrent en jeu quand on veut faire des choses spécifiques par support ou à la charge du support/navigateur. Le DOM est le Modèle de la page (du Document), et on le virtualise en variables JS ("keep state out of the DOM" est un total non-sens pour moi [au même titre que manipuler son modèle de données en PHP plutôt que MySQL]).
Ces FW sont donc souvent là parce que les devs veulent se charger de problématiques qui sont hors de leur contexte de travail.

Bref, finalement, tout cela a un côté "la techno-qui-brille-du-moment" pour moi. C'est certainement amusant pour passer du temps à loisir, mais je n'ai statistiquement pas vu beaucoup de projets sortir ici en React ou Angular (et bien plus en PHP basique). Je préfère attendre: peut-être que cette philosophie sera intégrée par la suite dans HTML6 ou dans les prochaines évolutions de ce langage.

PS: HTML et PHP, cela fait plus de 20 ans que cela existe. Les langages ont souvent tendance à évoluer, mais je trouve que les FW sont bien plus "rigides" de ce point de vue-là.

[niahoo]

Perso j'utilise React comme une librairie, pas comme un framework. Et Redux aussi d'ailleurs. C'est à toi aussi à ne pas considérer le FW comme la colonne vertébrale de ton application mais comme un coussin moelleux sur lequel s'appuyer.

Des codeurs qui ne savent finalement qu'appliquer des tutos dans un framework donné, sans tenter de comprendre le langage derrière.

Mais tu fais un procès d'intention. Suivre des tutos et utiliser un framework ne te prive pas soudainement de la moitié de tes neurones. Un bon codeur va utiliser le framework à bon escient. Un codeur médiocre sera content d'avoir le framework en soutien pour l'aider à réaliser ce qu'il souhaite.

[Xenos]

Un procès d'intention, possible, mais c'est ce que je constate dans les dev que je croise au taff ou en ligne. Je constate la même chose sur le fait de faire graviter son appli autour du FW: je ne connais pas de dev qui se soient ainsi servi de leur FW, en le rendant "amovible" de leur appli (souvent, le FW a plutôt tendance à la complexifier, souvent inutilement [le but de l'appli c'est quand même de rendre un service, pas d'empiler des FW ou du code]).

[Sephi-Chan]

Xenos, qu'est-ce que tu suggères comme "bon outil pour le job" pour ajouter de l'interactivité à une page Web ?

J'entrevois quelques réponses simples :

• Ne pas embarquer son jeu dans un navigateur mais dans une application native.
  
• Ne pas faire de single page app et rendre une nouvelle page à chaque interaction non-native (en dehors des formulaires, en somme).
  

Si on décide d'utiliser Javascript, on est obligé de toute faire avec sur le client, puisqu'il n'y a que ça.

On peut donc le faire de plusieurs manières : modifier son DOM à la main, faire une soupe de callbacks, etc. Si on veut pouvoir durer, mieux vaut créer des outils pour faciliter ça. React en est un de la génération actuelle (comme on l'a vu il y en a eu d'autres). Son approche permet de raisonner plus simplement — mais "simple" est déjà complexe pour une single page app — sur les changements d'état avec un flux descendant, une cascade (là où Backbone permet d'aller dans les deux sens) et optimise les opérations coûteuses pour une performance accrue : ce n'est qu'un détail d'implémentation, finalement.

[Xenos]

Pour moi, le problème est justement de vouloir implémenter un truc qui n'a rien à faire là (note qu'on a dérivé du problème initial du "je sais pas faire du javascript alors je fais du jQuery").

Je trouve particulièrement inutile de vouloir prendre un site classique (avec des pages, des liens entre ces pages, des formulaires etc) pour le mettre dans une appli: c'est inutile, cela rajoute des contraintes et cela ne sera probablement pas utilisé. De même, je trouve inefficace de vouloir prendre une appli native (qui permet de faire un gameplay spécifique à un support et un contexte donné) pour l'embarquer dans un site web qui n'apportera rien de plus (si ce n'est des emmerdes).

Les mecs d'oGame (point Godwin!) n'ont pas eu besoin de complexité d'implémentation pour faire un jeu à succès. Ceux qui gèrent Wikipedia n'ont pas fait une single page app. JeuWeb n'est pas une simple page app et s'en sort très bien (alors que les tentatives de reboot en single page app ont échoués).

Le gameplay (ou le service) derrière le site, c'est ce qui importe. Or, souvent, c'est "je veux faire tel jeu temps réel" (pas pour passer le temps à loisir comme on ferait des mots croisés, mais pour vraiment crée un jeu, joué et maintenu), "prends telle stack moderne temps réel", et 3 à 6 mois après, le jeu n'est toujours pas là. Ou, au mieux, c'est un pâle jeu à peine plus évolué qu'un Age of Empire 1. Pour moi, ce type de jeu (de gameplay) n'est juste pas adapté aux langages et à la structure du web (surtout sans une équipe de 20 personnes, un budget et une entreprise), alors que les SDK type NeoAxis ou Unity (ou autre pour mobile) le seront. [Edit] D'autant que si c'est "un détail d'implémentation", qu'est ce qui empêche de rapidement lancer le jeu avec des pages qui s'enchaînent, et ne mettre en place ce FW que plus tard, quand ce sera vraiment nécessaire?

Ce que j'en vois de ces framework, hors entreprise (et encore), c'est que leurs utilisateurs s'amusent à les installer, à les essayer, et au bout du compte, n'en font finalement rien. On peut faire pareil sur un SDK, mais cela se verra en moins d'une soirée: on installe le SDK, on essaye un peu les trucs, puis finalement on n'en fait rien. Si tel est le cas, on aime juste passer le temps en découvrant des nouveaux framework (y'a pas de mal à ça), mais on n'en fera jamais un jeu, et je trouve donc incohérent de pousser des créateurs de jeux à s'y essayer également (en fait, à y perdre également leur temps, à loisir).

[Sephi-Chan]

Je trouve particulièrement inutile de vouloir prendre un site classique (avec des pages, des liens entre ces pages, des formulaires etc) pour le mettre dans une appli: c'est inutile, cela rajoute des contraintes et cela ne sera probablement pas utilisé. De même, je trouve inefficace de vouloir prendre une appli native (qui permet de faire un gameplay spécifique à un support et un contexte donné) pour l'embarquer dans un site web qui n'apportera rien de plus (si ce n'est des emmerdes).

Les mecs d'oGame (point Godwin!) n'ont pas eu besoin de complexité d'implémentation pour faire un jeu à succès. Ceux qui gèrent Wikipedia n'ont pas fait une single page app. JeuWeb n'est pas une simple page app et s'en sort très bien (alors que les tentatives de reboot en single page app ont échoués).

Quand tu fais un jeu par navigateur, tu ne fais pas Wikipedia ou un forum, où la navigation page par page est tout à fait adaptée.

Dans un jeu, tu peux vouloir tendre vers l'immersion : une page intégrée qui donne toutes les informations nécessaires, avec laquelle tu peux avoir un œil sur tout et avec laquelle tu peux interagir sans forcément atterrir sur une autre page. Même Ogame et ses compteurs s'approchaient de ça.

Le gameplay (ou le service) derrière le site, c'est ce qui importe. Or, souvent, c'est "je veux faire tel jeu temps réel" (pas pour passer le temps à loisir comme on ferait des mots croisés, mais pour vraiment crée un jeu, joué et maintenu), "prends telle stack moderne temps réel", et 3 à 6 mois après, le jeu n'est toujours pas là. Ou, au mieux, c'est un pâle jeu à peine plus évolué qu'un Age of Empire 1. Pour moi, ce type de jeu (de gameplay) n'est juste pas adapté aux langages et à la structure du web (surtout sans une équipe de 20 personnes, un budget et une entreprise), alors que les SDK type NeoAxis ou Unity (ou autre pour mobile) le seront. [Edit] D'autant que si c'est "un détail d'implémentation", qu'est ce qui empêche de rapidement lancer le jeu avec des pages qui s'enchaînent, et ne mettre en place ce FW que plus tard, quand ce sera vraiment nécessaire?

La grande grande majorité des projets amateurs n'a pas besoin d'une grosse stack Javascript pour se casser la gueule.

[niahoo]

Pour digresser encore sur React, cette librairie se résume en un concept simple : state -> DOM.

C'est très simple, c'est facile à comprendre, facile à expliquer. Une fois que tu as pigé et que tu en as compris l'intérêt, la complexité du machin est tout à fait acceptable en échange de la simplicité d'architecture de l'appli. Pour moi, il n'y a pas photo, je suivais déjà ce principe avec d3js et quand React est sorti c'était une évidence de l'utiliser. J'utilise parfois des trucs équivalents (Ractive, snabbdom, Vue) mais c'est pour moi un paradigme totalement supérieur au reste (hormis éventuellement CycleJs).

[Xenos]

[Tout cela est dans le contexte de nos jeux web amateurs, pas dans celui d'un pro ni d'un site B2B: quand le pognon intervient, c'est différent car on fait ce qu'on nous demande point.]

Du dynamisme dans une page n'implique pas de flinguer la navigation naturelle sur le web, c'est tout. Peut-être qu'on peut ne pas la flinguer en usant proprement de tel ou tel framework, mais sans y recourir, on est certain de ne pas la flinguer (et même chez les pros, j'ai rarement vu des sites JS-mandatory qui ne flinguent pas la navigation).
Si on se lance dans "un jeu (vidéo) web", on restreint ce qu'on veut créer: un jeu (donc, bye bye la création de meubles) vidéo (donc, obligation d'utiliser l'outil informatique) web (donc, pour moi, obligation de respecter le fait qu'on est dans un navigateur, et que oui, un site web n'est pas nécessairement "immersif" parce qu'il n'a pas la moindre idée du contexte d'utilisation où il se situe [et c'est l'intérêt de la chose: ne pas avoir à se soucier du contexte dans lequel on s'exécutera]).


Mais perso, cet argument de l'immersion, je le trouve complètement bidon: quand tu navigues sur Wikipedia (ou autre), t'as constamment en tête "oh je suis dans mon navigateur, ce n'est pas immersif"? Perso, quand je navigue, tant mes habitudes ne sont pas explosées par un site, tout se passe impec', et le site devient immersif parce que "tout est comme d'habitude et je n'y fais donc même plus gaffe". Et si le gameplay que tu veux proposer ne rentre pas dans ces "habitudes", à mon avis, autant changer le contexte et passer du "jeu (vidéo) web" au "jeu vidéo". Tu ne seras plus emmerdé par ces notions "d'habitudes", et tu auras toutes les largesses pour faire le gameplay temps réel 3D qui envoie du pâté.

[J'ai peut-être un peu de mal à expliciter l'idée, donc je "verbose" un peu!].
En fait, je trouve que ce serait un peu comme vouloir supprimer les numéros de pages et de chapitre d'un livre, parce que "ça casse l'immersion" (c'est du texte qui ne fait pas partie de l'histoire). Ou idem pour les n° de vers d'une pièce de théâtre (ou les n° de scène et d'acte). Sauf que c'est d'une part usuel comme façon de faire (disons, "standard") et d'autre part, on n'y fait humainement plus gaffe. Donc s'embêter à vouloir les supprimer avec tous les effets colatéraux que cela amènera, je trouve cela improductif.
Du coup, oui, un bon jeu avec une histoire bien trouvée, un design bien pensé et une navigation bien standard, je trouverai cela immersif, car en moins de 10 secondes, j'aurai plongé dans l'histoire (qui doit évidemment être immersive, si elle est pourrie, c'est mort). L'espèce "d'habillage" qu'il y a autour (celui qui requiert de passer par ces FW) n'est, pour moi, qu'une façon de repousser le plus possible le moment où on tombera sur le coeur du jeu (voire parfois, fausser ce coeur de jeu en tentant de le sur-embellir). Finalement, c'est avoir pris le problème dans le mauvais sens que s'embringuer direct dans ces stack complexes avant même d'avoir pondu une version du jeu opérationnelle: on fait toute une décoration autour d'un coeur vide, au lieu de passer son temps à construire un coeur intéressant, même s'il sera "brut de décoffrage". Les entreprises peuvent faire du blé avec du vide bien décoré, mais pas un amateur (encore moins un codeur [t'auras toujours des exceptions, évidemment]).