Grand utilisateur de jQuery, formateur Angular et maintenant adorateur de VueJS, vous vous demandez sûrement ce que je pense de React. Si, je le sais, mon avis est pour vous comme un phare dans la nuit sombre du frontend engluée dans le brouillard de JavaScript.
Après tout, Facebook est codé avec cette techno pixel par pixel, et ils servent des milliards de pages chaque jour. Ça ne peut pas être mauvais. Ce ne sont pas de cons quand même.
Et puis tout le monde en parle, les asticots gigotent autour des restes du gigot d’ordre que les devs des GAFAS tentent de mettre au menu dans leur régime sans sel et sans typage.
Alors merde, quoi, react, keskeçavo ?
Je vais passer peut être pour un réact (hashtag lol), mais franchement le gigot au brouillard, c’est pas mon plat préféré.
Taillons un peu JS, ça m’avait manqué.
Mon royaume pour un hello world
React est tellement chiant à setuper que la doc officielle vous propose le hello world dans un code pen histoire de pas vous faire fuir tout de suite.
En fait, si pour vous installer un module avec npm/yarn/bower (plutôt que de copier le truc directement ou d’utiliser un CDN) est déjà un truc qui vous fait grogner, vous êtes loin derrière.
Il va vous falloir un outil de build (gulp, grunt ou l’usine à Vespene Webpack) et la série de recettes obsolètes customisées trouvées sur un coin de github pour connecter tous les bouts de votre pipeline. React bien sûr, mais aussi Babel pour transformer le JSX en JS.
Babel suit la left-pad philosophie, à savoir que tout est configurable et éclaté en centaines de petites dépendances et settings. C’est tellement chiant que des packages existent, appelés “presets”, dont l’unique but est de configurer Babel pour une tâche particulière.
Une fois que vous avez tout ça up, vous vous allez à la pêche au tuto, seulement pour remarquer que tout le monde code en ES6, voir ES7, et vous rajoutez donc un peu plus de plugins à tout ce bordel. Allah vous garde si vous tentez d’utiliser TypeScript.
Et vient alors le moment tant attendu pour faire coucou de la main programmatiquement. Ça foire, bien entendu. Le debugger vous pointe sur un bundle.js de plusieurs Mo, et vous apprenez que le support des sources maps est inégal d’un navigateur à l’autre.
Bienvenue.
Le X c’est pas toujours excitant
Une fois passée la douloureuse expérience de mettre en place votre environnement de travail, vous trouvez un certains confort. L’autoreload de la page est franchement pratique, et pouvoir utiliser l’unpacking (pardon le spread), les valeurs de paramètres par défaut et les arrow functions sans vous soucier de la compat du navigateur c’est quand même cool. Avec un webpack tout bien huilé avec amour (et douleur), vous pouvez faire des imports en JS et on a presque l’impression d’utiliser un langage de programmation.
Et puis le JSX, de loin ça à l’air pas mal ! Du HTML directement dans le JS ça parait un peu bizarre mais on vous le vend comme un avantage : finis les langages de templates limités, vous pouvez utiliser la pleine puissance (hum…) du langage JavaScript pour créer vos balises.
Sauf que non, le JSX, ça pue du cul.
D’abord, il y a le fait que toutes les structures sont à faire en JS. Les conditions, les concaténations et bien entendu, les boucles. Donc vous avez une liste de noms et numéros de téléphone, en VueJS, vous faites:
<ul>
<li v-for="pers in persons" v-if="pers">
<strong>{{ pers.nom }} </strong>: {{ pers.tel }}
</li>
<li v-else>
<em>Nobody's here!</em>
</li>
</ul> |
Mais en React, vous allez faire péter une expression ternaire et une fonction anonyme en plein milieu rien que pour l’occasion:
<ul>
{
(this.state.persons)
? this.state.persons.map((pers) => (
<li><strong>{ pers.nom } </strong>: { pers.tel } </li>
))
: (
<li>
<em>Nobody's here!</em>
</li>
)
}
</ul> |
Vous la sentez bien la puissance de JavaScript là ?
Et attention à ces boucles, car dedans vous guette cette erreur qui va vous poursuivre jusque dans vos cauchemars:
SyntaxError: Adjacent JSX elements must be wrapped in an enclosing tag
Babel vous signale gentiment que ne pouvez pas produire un snippet de JSX qui contienne plus d’un élément à la racine. Donc il faut TOUT wrapper dans un container. TOUT. Vous allez avoir vite des DIVs et des SPANs inutiles partout, juste pour faire plaisir à React. C’est absurde. C’est à vomir. Ca nique votre CSS et remplit vos sessions “examinez un élément” de tendinites dues aux clics pour déplier tout l’arbre des emballages cadeaux de vos balises. Et aussi, nique la sémantique.
Pour éviter ça vous allez tenter d’inliner un maximum de trucs dans une seule expression JSX ou tout foutre dans des arrays. Car je ne l’ai pas précisé ? Les arrays de JSX sont automatiquement et magiquement convertis en sous-éléments. Et du coup vous pourrez profiter au maximum des qualités de lisibilité de JS.
JSX est bourré de petits trucs comme ça, pour faire plaisir. Par exemple, j’ai un bouton, quand je le clique il delete la personne de la ligne de mon agenda. Je mets aussi une classe pour tous et une selon que la personne est importante ou non. Un prevent default pour éviter que le browser recharge la page si je suis dans un form.
En Vue, je passe un objet qui dit quelle classe afficher ou non. Le click handler contient une instruction prevent qui me permet d’appeler preventDefault automatiquement. Et j’appelle deletePerson tout naturellement :
<button class="{'delete-person': true, 'important-person': pers.isImportant}"
v-on:click.prevent="deletePerson(pers)">
Delete
</button> |
En react, on ne peut pas passer de paramètre à son handler. Il faut le passer dans une closure. Mais alors la closure va recevoir l’objet event, qu’on doit donc faire suivre à notre handler, afin qu’il puisse appeler preventDefault à la main. A noter aussi que class s’appelle className. Et n’accepte que des strings donc la concaténation se fait à la mano.
// plus haut on appelle preventDefault dans handleDelete
<button className={'delete-person ' + (pers.isImportant ? 'important-person': '')}
onClick={(e) => this.deletePerson(pers, e)}>
Delete
</button> |
Ce n’est pas juste chiant à lire, c’est surtout hyper chiant à trouver, à taper et à debugger.
Un peu de nutella sur votre confiture ?
React, c’est verbeux, il va falloir vous y faire. Il suffit de comparer le code nécessaire pour faire une TODO en react avec les autres frameworks.
Mais ce n’est pas juste ça qui est lourd.
Non, le vrai truc qui est super pesant, c’est que react est un cancer. Quand il est utilisé, il contamine tout.
Par principe, une fois que vous utilisez react, il faut mettre TOUTE VOTRE PAGE en react. Pas juste un petit bout. Par là j’entends que 90% de votre HTML va devoir migrer dans le code JSX. Votre beau code HTML bien propre, converti en cette monstruosité de mélange entre le langage le plus dégueulasse du monde et un monstre mimic qui essaye de se faire passer pour du HTML pour vous bouffer.
Or, toute l’idée c’est de faire des composants, de diviser votre pages en plus petits bouts. Mais voilà, React n’a rien prévu de simple pour la communication. Pour passer des données des composants enfants, il faut les passer via les attributs de balise HTML (appelés les props, pour faciliter la rechercher Google). Si vous avez 5 niveaux d’imbrications, vous vous tapez ça 5 fois.
Plus amusant, il n’y a aucun mécanisme pour passer des infos de l’enfant aux parents. La méthode standard est d’écrire puis passer manuellement un callback du parent à l’enfant, via props, et appeler ce callback dans l’enfant avec la valeur que le parent utilise ensuite. POUR. CHAQUE. PUTAIN. DE. VALEUR.
Passer des callbacks, ça va 5 minutes. Et ça ne résout pas un problème de communication entre composants parallèles, c’est à dire ni parent, ni enfant. Du coup tout le monde finit par utiliser une lib supplémentaire type EventEmitter pour servir de bus de communication.
Quand vous entendez les gens se plaindre de la difficulté d’utiliser l’écosystème de react, les fans répondent souvent que l’écosystème n’est pas obligatoire. On peut très bien s’en passer sur un petit projet.
Sauf que react est absolument inutilisable sans. Sans un bus d’event, un transpiler ES6 + JSX, un builder et un hot reloader au mininum, le projet ne dépasse jamais le stade du prototype.
Mais bon soyons franc, beaucoup de projets react tout court ne dépassent jamais le stade du prototype. On parle de codeurs JS là.
Etat
Les props ne doivent jamais changer. Seul l’état d’un composant react peut changer, ce qui trigger un nouveau rendu du composant.
Mais l’état lui-même est en read-only. On est supposé uniquement créer un nouvel état à chaque fois et remplacer l’ancien.
Au début on le fait à la main, mais JS n’est pas vraiment fait pour faire de l’immutabilité, et ça devient uber chiant très vite. Changer la propriété d’un objet qui est lui même dans un array demande de recréer tout l’array et l’objet. A chaque fois.
On se tourne alors vers des libs (encore une) type immutable.js qui fournit des listes et maps qui sont immutables et permettent de faire ces opérations sans y laisser ses jours de congé.
Une fois de plus, les connards qui vous disent qu’on peut faire du react sans la tonne de boiler plate qu’on voit dans les tutos ne le font jamais eux-mêmes. Parce que oui, on peut faire Paris-Amiens à pied en théorie, mais bon…
Des décisions à la con
Clairement, react a été fait pour créer des UI. Mais au bout d’un moment, les utilisateurs se sont réveillés et ont voulu une encapsulation pour des composants non UI. Mais react ne sait pas faire. Quand vous avez donc un composant non UI, par exemple la déclaration de votre routing, vous le déclarez… en JSX:
render((
<Router history={browserHistory}>
<Route path="/foo" component={FooView}/>
<Route path="/bar" component={BarViw}/>
</Router>
), document.getElementById('app')) |
Votre app va devenir très vite une pyramide de composants, certains qui s’affichent, d’autres non, tous se passant en cascade des données les uns aux autres.
Et au passage, quel est l’abruti qui a décidé des noms des méthodes des cycles de vie comme getInitialState, componentWillMount et componentDidMount ?
Surtout que vos méthodes et les méthodes héritées de la classe du component sont dans le même espace de nom.
Le bonheur des stores
Un truc dont on peut vraiment se passer par contre, ce sont les stores. Flux, redux, vuex, etc. On peut utiliser n’importe quelle solution pour stocker l’état de son projet côté client.
Mais si vous voulez profiter des promesses de react, comme le time travel et la concurrence parfaite, il vous faudra un store.
“store” c’est le nom huppé que react donne à ses modèles. Je ne vais pas rentrer dans les détails, et vous laissez décider par vous même du truc. Voici, comment la doc vous recommande d’ajouter une personne dans une liste d’un agenda avec redux, la store la plus populaire:
// Les imports
import React from 'react';
import { render } from 'react-dom';
import { createStore } from 'redux';
import { Provider } from 'react-redux';
// creation du store
const initialState = {'agenda': []};
function reducer(state=initialState, action){
switch (action.type) {
case 'ADD_PERSON':
return {
'agenda': [..., action.object]
}
default:
return state
}
}
const store = createStore(reducer);
// creation de l'action d'ajouter un objet dans le store
function addPersonAction(obj){
return {
'type': 'ADD_Person',
'object': obj
};
}
export function addPerson(Person){
store.dispatch(addPersonAction(Person));
}
// composant qui affiche le form de l'agenda et la liste des personnes
var Agenda = React.createClass({
handleAdd: function(){
addPerson({
"name": this.refs.name.value,
"tel": this.refs.tel.value
})
},
render: function(){
return <form onClick={this.handleAdd}>
<p><input ref="name" /><input ref="tel" /><button>Add</button></p>
</form>
<ul>
{
this.store.agenda.map((pers) => (
<li><strong>{ pers.nom } </strong>: { pers.tel } </li>
))
}
</ul>
}
});
// adapter qui permet de passer le store à l'agenda
const AgendaContainer = connect(function(state){
return {'agenda': state.get("agenda")};
})(Agenda);
// affichage du bouzin
render((
<Provider store={store}>
<AgendaContainer>
</Provider>
), document.getElementById('app')) |
Vous imaginez bien que trouver ça tout seul a été un bonheur. Parce que oui, la doc est absolument à chier, dans la longue tradition des stacks JS modernes.
Alors je vais répondre à ce post en tant que dev principalement frontend dont le framework principal est React, mais ayant touché Angular et VueJS aussi.
Il est clair que la barrière à l’adoption est élevée, mais ce sera pareil partout. Aujourd’hui qui veut coder en ES5 ? Bien sur c’est possible, ou on peut aussi se dire qu’on va coder en ES2015 et s’en foutre des navigateurs, mais en vrai dans tous les projets en ce moment il y a de l’ES2015/2016/2017 et il faut un process de build. J’ai vu des apps Angular avec un DOSSIER entier de fichiers de build webpack qui faisait plus de 1000 lignes. Pour indication le projet principal sur lequel je travaille fait plus de 15 000 lignes. Le fichier de build fait 100 lignes, ca va je n’en suis pas mort, même si je m’en passerais bien. Certes React oblige à y passer mais mëme avec un autre framework il y a une grande chance de devoir s’y faire aussi.
Concernant JSX, je trouve la critique un peu dur et l’exemple très mauvais. Plutot que ce spaghetti, je préfère largement
Certaines personnes préfèrent avoir tout au même endroit dans un code géant, je préfère largement la modularité. par exemple la fonction qui retourne la liste peut très bien être séparée sans soucis. Le bénéfice est aussi qu’on peut faire bien plus d’opérations complexes, genre itérer sur plusieurs variables, zipper des listes etc. plutôt que d’être contraints par un langage statique construits pour certains usages spécifiques. De plus, j’ai horreur de tout ce qui vient rajouter de la syntaxe par dessus, donc les n-for et autres non merci pour moi.
Il n’y a absoluement pas besoin de tout wrapper dans des div ou span, il suffit de retourner la fonction et non de crée un élément, par exemple:
Mais je concois bien que la limitation d’un seul élément à retourner par composant est en effet ennuyante. Le bon point c’est que la limitation va sauter lors de la prochaine version de React qui sortira dans pas trop trop longtemps, ce qui est toujours ca de pris, parce que c’est vrai que c’est chiant malgré tout.
Pour les remarques sur class je suis d’accord je crois d’ailleurs qu’il y a des plans sur le sujet mais rien de bien précis pour le moment. Jespère que ca viendra. En ce qui concerne les event handler, je partage à moitié, je comprends l’intérêt mais l’addition syntaxique ne me plait pas et j’ai du mal à voir une solution propre à ce soucis, d’autant que dans beaucoup de cas j’ai de toutes facons besoin de e au final donc pas vraiment un gros gain.
React est pensé selon moi avant tout pour un gros bloc cohérent, pas pour faire un slider à gauche, un autre à droite et communiquer à la jQuery au milieu. Le gros point négatif comme souligné ici c’est que du coup pour ce genre d’usage qui étaient ceux de jQuery ce n’est pas la joie du tout, et je recommanderais autre chose. Mais quand on a un gros bloc complexe, tout devient tellement plus clair à gérer. Tout va dans une seule direction donc on peut isoler les bouts, avoir un seul gros bloc de données et hop c’est l’application. C’est un bonheur pour tester et pour les transition, gérer les flux de données qui arrivent en parallèle et vont dans tous les sens.
Il n’y a pas de framework parfait. J’ai détesté VueJS pour sa syntaxe et pour son bordel quand on arrive à une taille un minimum conséquente. React est lourd et peu pratique pour un usage isolé (en même temps qui va se taper 200kB de JS pour un todo list sur le côté franchement ?).
Et si React a bien eu un autre mérite c’est de faire que les devs JS se sont repris à faire faire du JS, à maitriser les array, les objets, la mutabilité et pas juste à se reposer sur des facilités vaudous cachées dans des syntaxes additionnelles à la Vue/Angular.
C est sympas ce mélange HTML/JS ça rappelle de bon souvenirs. Ces joyeux mix de PHP/JS des années 90.
Super article, très intéressant !
J’ai fait beaucoup d’angular1, un peu de 2, du riotjs (mon préféré) .. et depuis peu du vuejs ;-)
Je voulais donne une chance à réact, mais tu m’as convaincu que non ;-)
J’AI adore, et découvre encore, vuejs : j’aime beaucoup le cadre qu’apporte vjs pour faire ses composants … C’est clairement ce qu’aurait du être angular2 … C’est un framework très mature, et très agréable à debuguer.
Je vais progressivement abandonné ang1, au profit de vjs, car il profite également de beaucoup de libs sympa (ui) … Pour éviter de réinventer la roue … Comme c’est le cas avec riot, un de ses seuls défaut, … Mais j’aime beaucoup riot, et je continuerai avec pour des trucs techniques …
Quelques typos:
“la peche au tuto” -> “la pêche au tuto”
“faire pêter expression” -> “faire péter expression”
“la concatenation” -> “la concaténation”
“Et ca ne résout” -> “Et ça ne résout”
“soyant franc” -> “soyons franc”
“le font jamais eux-même” -> “le font jamais eux-mêmes”
“en théory” -> “en théorie”
“par example” -> “par exemple”
“le nom hupé” -> “le nom huppé”
@dineptus :
la plupart des devs PHP, Ruby et Python. En fait la majorité des gens qui codent des sites Web ne savent même pas utiliser npm. Il faut bien se rendre compte que les devs qui ne savent faire plus que de l’Ajax sont en majorité.
Et oui, quand on a fait du ES6 ça fait mal de retourner à l’age de pierre, mais c’est le cout d’utilisation de ES6 qui est prohibitif.
Angular 2 non ? Car angular 1 ça marche out of the box.
Oui mais alors tu as un autre problème : un template non linéaire. Pour comprendre ce que ça fait, tu va scroller partout dedans et reconstituer la page dans ta tête. Horrible.
Là tu retournes un array, et c’est encore autre chose. Une autre magie que fait angular: si tu retourne un array, il l’insère automatiquement comme du JSX automatiquement. Ce qui permet d’éviter des wrappers, mais alors fait que tu as des arrays un peu partout dans ton template.
Ben pour une taille conséquente, tu peux utiliser Vue exactement comme React. Mieux même en fait car le css peut être inclu dans ton component isolé. Donc je vois pas le souci.
Perso je n’ai quasiment jamais rien cherché bien longtemps pour trouver comment faire un truc avec Vue. Alors qu’avec React je cherche (et recherche) systématiquement comment faire les trucs les plus simples. C’est juste pas naturel, et tout est éparpillés. Et au final le template qui ne doit pas être un truc magique mais seulement du vrai HTML et du JS n’est pas du vrai HTML, et donc on y gagne pas grand chose.
Je pense vraiment qu’il serait facile de donner un contre exemple sur chacun des points que tu as cité. Comme tu l’a si bien souligné il ne s’agit ici que de ton simple avis sur le très vaste sujet qu’est React et tout ce qui va avec ; c’est donc totalement subjectif et je comprends parfaitement :-).
Je me permettrai juste d’ajouter humblement ma pierre à ton royaume du hello world en discutant du package npm create-react-app qui permet de créer simplement une application react (et tout l’écosystème qui va avec) en 2min. Vraiment. Tout est déjà pré-configuré. Et puis le jour ou tu n’est plus satisfait des choix de build et config fait par défauts, un coup d’eject et tu prends la main sur le tout comme un grand.
Testé et approuvé.
create-react-app est un patch sur une jambe de bois. Tu vas l’utiliser 2 minutes pour voir le hello world tourner sans comprendre pourquoi il marche. Ensuite tu vas essayer de le faire marcher avec Django ou Rails, et ça va foirer, et tu vas retourner à la case départ.
En fait il est surtout utile une fois que tu sais te servir de react pour pas te faire chier à refaire tout le setup.
Hello :)
Pour le JSX, une autre façon de faire, un peu plus verbeuse… https://codesandbox.io/s/6B5nAkQz
C’est vrai que React chamboule pas mal des habitudes qu’on peut avoir pour faire des webs apps et impose un tooling assez lourd (webpack + babel)… mais tout ça c’est dans un but précis : faire de la single-page-app à base de components réutilisables, ce qui n’est pas forcement adapté à tous les projets (quoique si, qui veut ne pas pouvoir réutiliser ses composants??)… et au final de créer une bibliothèque de composants UI “unitaires” et isolés, réutilisables dans tes divers projets…(priceless). et React est connu pour la stabilité de son API donc c’est un bon investissement de ce point de vue à mon goût.
Coté tooling après quelques semaines de galère pour bien se mettre à jour sur ES6 et le tooling, on y arrive… surtout qu’on a maintenant https://github.com/facebookincubator/create-react-app et https://github.com/insin/nwb qui conviennent à la plupart des apps. Et franchement, venant du Python, et ayant bouffé masse d’ES5, c’est un vrai bonheur de travailler avec ES6/ES2015/etc malgré les contraintes (build, publication…) qui sont je le répète gommées avec ces outils. Et je ne parle même pas de npm qui est une mine d’or qui, une fois maitrisé, ouvre les portes de la plus grande bibliothèque de composants du Monde.
Pour l’intégration dans des frameworks backend tiers, pour l’avoir fait avec Django, node, etc, je trouve qu’il est préférable de veiller à bien séparer le front du back (API)…. et coté client, React peut très bien intégrer des composants tiers s’ils ont une API propre et sont “wrappés” : https://npms.io/search?q=react%20jquery – et des composants React peuvent utilisés dans des apps tierces (old: http://blog.revolunet.com/angular-react-meetup/slides/#1). Mais bon, franchement, qui a envie de maintenir une app frankenstein.js ?
Le side-effect sympa c’est qu’une fois que tu maitrises tout cela, tu as accès à un écosystème super riche; Et avec la connaissance du “paradigme” react (composants + lifecycle) tu vas pouvoir accéder à react-native, reactVR, react-gl, react-hardware, react-blessed, etc… pour le même prix… encore une fois un très bon investissement…. et toujours avec les mêmes outils, et la même façon de coder.
Vue offre tout ça sans la lourdeur.
Comme d’habitude super article.
Je fais depuis 6 ans du django et je me suis lancer dans l’aventure angularjs + django-rest il y a deux ans : une horreur. Mais j’avais fait des trucs sympa.
Puis je me suis mis à @angular + @angular/cli couplé à django-rest et là que du bonheur. J’ai voulu tester vue.js, mais rien qu’à l’idée de quitter typescript ça me hérisse. Par contre, la vrai raison qui a fait adopter angular à toute l’équipe c’est @angular/cli. Clairement, pour la grande majorité des frameworks js, la partie build est un vrai cauchemar. Faire des configurations webpack qui tiennent la route est en l’état presque de la magie (ou bien un spécialiste, mais c’est quand même triste de demander ce genre de compétence comme pilier de ton équipe).
En tout cas merci pour ton retour, rien que les deux exemples m’ont convaincu de ne pas perdre mon temps.
@Sam:
Je pense qu’il est vraiment temps que tu fasses un complément à ce post autour de Vue.js, montrer ce que tu n’apprécie pas dans React c’est bien mais au vu des commentaires je ne pense pas être le seul à me dire “Ok, mais si Vue ‘offre tout ça sans la lourdeur’ comment est-ce que tu applique Vue appliqué à un vrai projet ?”.
Globalement assez d’accord avec toi. React n’a pas été pensé pour ce qu’il est devenu. Cette espèce de couteau suisse à tout faire. J’ai l’impression de retourner à mes débuts sous PHP avec cette merde de JSX où toutes les excuses et quenelles sont bonnes pour nous faire croire que ce n’est pas gênant de mélanger des langages…
Ceci dit concernant npm et la taille du bundle, je ne peux que confirmer certains commentaires. Rares sont les frameworks désormais qui sont désormais simples et légers.
Ensuite, pour le commentaire de dineptus sur es2015, bah beaucoup de gens en fait. Si tu n’as pas de problématique SEO ou de question de performances pures, tant mieux. Perso, j’ai une pile de compatibilité plus large que le dernier babel ne peut couvrir (merci certains clients de payer mieux pour rester sous IE8). Là, que ce soit React, Angular ou Vue, t’es mort.
Avis d’un gros fan de AngularJS (premier du nom donc)
“More you fit the DOM, more you fuse the DOM.”
@cym13 je pense qu’il faut essayer. ya quelques projets qui pourraient illustrer
Les mecs de chez Twitter, Airbnb, Netflix, Uber, Khan academy, Facebook, Microsoft, Dailymotion, Atlassian, Disqus, etc… doivent bien se marrer en lisant ton article ;)
Tu critiques JSX, tu dis “bref HTML dans JS” mais c’est quoi ce snipper VueJS ? ni du HTML, ni du JavaScript. un nouveau language.
Mais du coup VueJS c’est plutôt magique non? il faut apprendre un nouveau lang de template et les directives etc… au moins JSX a la même API que le DOM et il suffit d’apprendre… JavaScript
franchement quand je vois
je me demande si c’est pas un troll cet article. Du JS dans un “string” , sérieux? ça fait un eval() à la fin? Pourquoi pas juste faire onclick=”” comme avant?
J’utilise React depuis 2011 et c’est un vrai bonheur. désolé.
“Et du coup vous pourrez profitez” -> “Et du coup vous pourrez profiter”
Merci de mettre des mots sur une douleur dont les hipsters JS ne parlent pas (“React c’est trop hype”).
Bon après pour nuancer, il y a des idées intéressantes quand même, comme par exemple avoir des composants unitaires réutilisables et testables unitairement, ça peut paraître séduisant.
Enfin bon je confirme pour l’apprentissage pour un nouveau, j’ai appris le JS et React en même temps ça a été assez douloureux =/
oops je voulais dire depuis 2014* pas 2011 :D
Les codeurs JS me font penser aux anciens Flasheurs, ils sont montés très haut, très vite puis ils sont retombés comme des merdes puis ils sont morts ;)
@greweb : ya encore plus dure à lire avec VueJS
Le fait que Facebook, Instagram, Twitter, Yahoo, Tesla, Airbnb, Dropbox, WordPress, et j’en passe l’utilisent, contribuent… Que c’est utilisé par des millions de gens sur des apps web et native, dans de la VR et 3D… CA PARLE A PERSONNE NON?
D’ailleurs il y a quasiment 90% de chance que vous ayez tous une app fait avec react sur votre smartphone iOS ou Android.
Mais oui, ça ne veut pas dire que c’est bien et que react résout des problèmes.
PS: le premier exemple de code ne fait pas ce qu’on pourrait croire (pour que ca marche il faudrait .map() en place de .forEach()). Ca montre que vous avez même pas tester en fait. JSX n’est PAS un langage de template. On est pas dans du PHP. Stop la mauvaise fois en papier mâché.
@MoOx :
Ils utilisent BEAUCOUP d’autres technos aussi. Et comme disait un commentaire precedent, ca ressemble a la fievre autour de Flash : beaucoup de trucs faits, partout, mais mort a cause des memes problemes du tout debut…
Et le fait que tout le monde soit-disant utilise ca ne veut dire qu’une chose en fait : ON A PAS MIEUX. Point. Et la communaute est a vomir donc comment vouloir en tirer quelque chose de mieux, sachant qu’un langage et sa communaute sont interdependants ?
En VR et en 3D (ce dans quoi j’ai eu l’occasion de pas mal travailler), non, on veut du C++, du Python, a la rigueur du HTML5, mais le JS on s’en debarrasse (un exemple random : Icy qui permet d’embarquer du code JS, les users n’aiment pas…).
La mauvaise foi en papier mache en ne s’en debarrasse avec une bonne dose de vomi de mauvaise foi. En bon entendeur MoOx.
Quand on a un marteau on voit plus les problèmes comme des clous, surtout pour la VR, quel enfer ça doit être…
Pour les sites c’est pas mieux, ils prennent des tonnes de requêtes réseau, de RAM, des millions de ligne de code pour afficher quelques lignes de textes dans des boites avec deux images…
Je pose ça là du coup https://twitter.com/id_aa_carmack/status/844902854171262977
Du coup, je cite “UI dev is several x faster than Unity”.
1) On parle de GUI pas d’autre chose. Laissons le backend aux vrais langages pour la VR en elle-meme
2) Unity = C#. J’ai vu tellement d’interface pour le C# et le C++ pour des applications lourdes que je me dis que la plupart des devs doit etre desesperee de trouver quelque chose pour faire des GUIs facilement pour passer aux choses serieuses avec un autre langage (OpenGL + shaders languages, C/C++, etc)
Et vu le boulot abattu et le temperamemt de carmack, effectivement, il prefere travailler sur une bonne facon d’integrer Vulkan sur le backend que de s’avoir avec quoi l’UI tourne tant que ca tourne.
Ma préférence va aussi à VueJS, par contre on peut quand même simplifier quelques exemples (même si on sera d’accord que Vue fait mieux :))
Pour la liste (considérant que
personest toujours unarray) :{ this.state.persons.length === 0 ? ( Nobody's here! ) } { this.state.persons.map((pers) => ( { pers.nom } : { pers.tel } )) }Pour le preventDefault, une petite fonction utilitaire peut toujours aider :
function preventDefault(callback) { return (event) => { event.preventDefault(); callback(); }; } deletePerson(pers)) }>Delete // ou si pas d'argument à passer au callback DeletePour les class, il y a une petite lib qui peut dépanner (oui, encore une lib à ajouter au setup de base :)) : https://www.npmjs.com/package/classnames
Allez, c’est pas si pire, si ?
Quant à la doc… j’y ai toujours trouvé ce que je cherchais et rapidement, comme dans celle de Redux. Je n’irai pas dire qu’elles sont parfaites, mais je nuancerais grandement le “absolument à chier” ;)
Arf désolé, mes bouts de code sont tout pourri :/
Bon article (troll) sur React je trouve.
A chaque fois que j’essai React (parce que c’est Hype et que ça déchire tout), j’arrêtre au bout de 30 min.
Et je me dit c’est quoi ce bordel, j’y comprend rien et ça pique les yeux (c’est pour rien que les anciens avait séparé html et code …)
il suffit de voir le nombre de framework dans le style de React qui sortent pour voir que c’est pas ça !!!
Perso, depuis que j’ai pris mes marques avec Angular (v4) + Typescript … c’est que du bonheur … ultra simple et pas verbeux (et encore moins avec le paradigme RXJS) … alors que j’avais eu du mal avec les scopes de AngularJS !!!
Pour moi les mecs de chez google connaissent bien leur sujet … ça se ressent !
(VueJS ne sera qu’une mode …)
Merci Sam, franchement merci. J’hésitais à me plonger dans cette techno dont tout le monde me vante la magie à coup “react native” par ci par là. Mais je déteste me prendre la tête. J’aime les choses simples. Voire simplissimes. Je considère qu’on peut faire des choses complexes en accumulant des myriades fonctionnalités simples, légères, bien documentées et qui respectent la philosophie du dev web. Du coup exit React, je vais jeter un coup d’oeil à Vue.js :)
@polo : vuejs gere typescript https://vuejs.org/v2/guide/typescript.html
Juste un petit détail, AngularJS est plus simple mais si beaucoup de gens l’on quitté c’est pour ses performances désastreuses et ses imports de taille monstrueuse.
Sinon moi quand j’ai appris React justement j’aimais bien, car je pouvais faire du vrai JavaScript sans Babel ni JSX et mon apprentissage a été progressif.
Oui j’ai pas sorti le truc immédiatement, mais j’ai bien compris ce qui se passait derrière.
Exemple de div en pur JS:
React.createElement(
"div",
null,
"Hello ",
this.props.name
);
On ressent le salty du gars envers JS lol… Et son incompétence aussi par la même occasion..
Hello,
Merci beaucoup pour l’article, j’ai un pote qui a écrit un article sur l’utilisation de Reduc avec React. C’est pas mal aussi :)
voici le lien :
[NOPE]
C’est bien beau de critiquer React en ne pensant qu’a son petit confort de développeur. Vous nous vous êtes pas poser la question de savoir pourquoi Facebook à développer son propre “Framework” ? Les performances désastreuse de AngularJS on en parle ?
La mauvaise foi dans cet article est monstrueuse. Tes bouts de code on en parle ? On t’as déjà parlé d’un terme qui s’appelle “performance” ?
Je n’ai rien à dire que de demander à tout le monde de comparer des applis mobile en React Native vs Ionic (du Angular quoi…) et vous verrez bien le décalage !
Ah voilà, c’est donc ça les dizaines de div au nom du style “ga8kq-n9z4de” que je déroule quand je cherche l’URL d’une vidéo ou d’une image sur Facebook…
Je suis loin de faire des sites ou des applis comme Twitter ou Discord, mais j’ai un peu du mal à comprendre pourquoi les projets web d’aujourd’hui sont des énormes usines à gaz qui multiplient les frameworks et les librairies, tout ça juste pour afficher des trucs. À moins de vouloir faire un truc VRAIMENT hors-catégorie (du genre une carte avec leaflet ou de la voix comme Discord), je ne vois pas pourquoi quel est l’avantage d’avoir une stack de ce genre, si ce n’est le gain de temps (pour ne pas dire paresse). HTML5, CSS3, JQuery (et encore, je ne m’en sers jamais perso), et à la rigueur une lib pour gérer la communication ajax ne sont pas suffisants ?
C’est bien beau d’avoir des navigateurs et des CPU de plus en plus puissants, mais ce qui est dommage, c’est que la réaction n’est jamais “ah cool, maintenant nos technos actuelles vont marcher super vite”, mais “ah cool, maintenant pour améliorer notre productivité on peut utiliser des trucs plus lourds et moins optimiser notre stack/code” (et ne me dites pas “ouais mais il y a 20 ans on avait des besoins plus légers” : on parle de sites web là, pas de jeu vidéo ou de calcul parallèle).
N’empêche qu’on est (presque) tous d’accord sur un point : le JS, c’est de la merde (cet article me rappelle d’ailleurs l’article “La communauté JS est actuellement une machine à créer de la dette technique”), et c’est vraiment tragique que personne ne peut/veut vraiment proposer une alternative à ça qui serait un minimum propre. À la base, Dart (créé par Google) était censé être un langage totalement indépendant de JS, mais même eux ont jeté l’éponge… “pour l’instant”.