Bonjour à tous, bienvenue sur ce nouvel épisode de Double Slash, comme d'habitude nous
sommes avec Alex, salut Alex ! Salut Patrick, salut tout le monde ! Et donc moi je suis
Patrick comme d'habitude, j'ai pas changé. Donc petit épisode improvisé, je vais le
faire comme ça. On n'avait pas forcément prévu de parler de ce sujet mais en fait hier le
state of front end est tombé. En fait c'est une petite survie qui a été réalisée par, je crois
c'est une agence en fait, je sais ce que je regardais juste avant. En fait c'est une agence qui est en
Pologne et au pays bas je crois, qui a fait un sondage par rapport au développeur front end
tout ça, sur tout ce qu'ils utilisent, leur façon de coder, tout ça. Et c'est tombé hier et en
fait j'ai vu un tweet de Sébastien Chopard qui parlait de ça puisque justement il donne un petit
intro sur le state of front end et donc voilà. Et je trouve ça super intéressant parce que ça
permet de voir un petit peu où on en est au niveau des outils, tout ça, des frameworks librairies.
Après c'est vachement inspiré de state of js qui pour le coup est poussé par stack overflow,
il me semble ou je sais plus qui est derrière, peut-être que je dis une connerie. Mais state of
js qui est hyper hyper connu, du coup là ils ont repris un peu le même concept pour faire une
version un petit peu plus front end, pas uniquement limité au js. Donc intéressant,
intéressant, on va pouvoir regarder, on découvre le truc en même temps quoi.
Ouais, j'ai rapidement lu hier, j'ai vu un bâchin,
mais j'ai préféré découvrir en même temps que les auditeurs comme ça.
Du coup c'est basé sur 3703 réponses et issue 225 pays, du coup ça donne déjà un
retour, on va dire sur la vision. On voit quand même c'est quand même quasiment 2000
personnes qui viennent de l'Europe, 800 des États-Unis, 200 Amérique du Sud, une centaine
d'Africains, 500 de l'Asie et 80 de l'Australie. Du coup il y a quand même une grosse partie qui
vient de l'Europe quoi. Donc après c'est pas un gros panel 3 700 parce qu'on est quand même
des millions à développer, mais ça donne un échantillon quand même. Ce qui est intéressant aussi
c'est qu'il avait été fait en 2020 et que tu peux comparer en fait avec les résultats de 2020.
Ça c'est pas mal quand même. Ouais, carrément, ce qui fait un avant après.
Ce qu'on voit par contre, tu vois au niveau des... Vas-y on les commence comme ça direct.
Donc les gens qui ont répondu en fait, ils sont majoritairement en remote, en travail remote,
et en hybrid, ce qu'on dit hybrid c'était une partie de travail, une partie bureau. On le voit bien
là dans ce que tu es en train de montrer là. Alors ceux qui nous écoutent, on a aussi la
vidéo sur YouTube qui sera disponible en même temps que l'épisode sur Apple Podcast.
Du coup vous pouvez aussi nous suivre et nous liker sur YouTube et en fait on vient
commenter et vous avez directement les slides qui sont directement sur la vidéo.
Excellent. Après en fait, est-ce que vu que c'est basé sur 2021 et donc est-ce qu'il y a pas aussi
un effet Covid où il y avait plus de monde qui était en remote, est-ce que c'est une tendance ?
Tu vois ? Est-ce qu'il y a un extrapollation à faire là-dessus aussi ? Garder en tête qu'on sort
du Covid avec toutes les restrictions qu'il y a eu dans les entreprises ou clairement les devs
on s'en doute étaient les premiers à être mis dehors parce que techniquement c'est plus facile
de bosser à distance et il y a plus une culture remote chez les devs. Après est-ce qu'elle a été
accentuée par le Covid ? Ah bah clairement ça c'est un sujet, tu vois, ça c'est le premier sujet.
Non clairement il y a eu du changement, enfin je ne sais pas si tu l'as vu avec des clients et
moi je l'ai vu avec mes clients en fait dont certains qui n'étaient pas du tout télétravail
comme ce soit et qui sont complètement pivotés et qui aujourd'hui sont moitié télétroits,
moitié bureau et on avait vu, enfin moi j'ai vu vraiment du changement à ce niveau-là et c'est
après il y a beaucoup, les devs ne sont pas tous fans d'être en télétravail, tu vois,
c'est pas tout le monde qui a l'air de ça et il y a beaucoup de gens qui préfèrent aussi,
enfin qui aiment ce contact au bureau, jouent au bapifoot et tout ça donc puis voilà le contact.
Après voir aussi un contact, un rapport humain et tout, après c'est évident, après moi j'ai pas trop
vu la différence à titre perso parce que ça fait déjà longtemps que je suis en remote et c'est
un critère de travail dans mes choix de mes clients et ça fait partie du contrat et donc en
fait il n'y a même pas discussion à avoir, on est en remote mais en plus en même temps parfois
les clients sont soit très très loin de chez moi soit carrément à l'étranger donc en fait
il y a même la question de se poser même pas parce que c'est assez facile et assez clair.
En tout cas avant la crise de la Covid, j'avais dans un temps un client qui me disait
qu'il vient au bureau, là c'est fini quoi. Après néanmoins je reste intime qu'on a
vu quand même que sur un lancement de projet ou pour mettre vraiment les fondements et les
bases de la relation avec le client pour bien comprendre le projet souvent c'est quand même
pas mal de faire des réunions, des vraies réunions en physique pour justement aborder
tout le concept global du projet et je trouve ça amène quand même une bonne valeur et après
quand on doit coder on code et clairement après c'est à chacun de préférer.
Ce qui est bien c'est un mix tu vois. Après c'est bien fait ce qu'il veut mais c'est bien de se
rencontrer des réunions importantes. La dernière fois que j'étais dans une entreprise c'était
pas longtemps c'était pour une grosse mise en prod, là c'est utile parce qu'on parle en live il
faut être actif si jamais il y a un bug ou quoi. Il y a des moments où vraiment c'est bien d'être
ensemble. Bon clairement. Qui a répondu est ce que c'est des juniors des seniors depuis combien de
temps ils sont dans dans l'activité et on se rend compte qu'il y a plus de 5 ans. Plus de 5 ans
et après plus de 10 ans et après 3 ans. Est ce qu'il y a une différence avec 2020 ? En fait ils ont vieilli.
C'est normal. C'est les mêmes en fait. Mais après de toute façon je pense que les personnes qui
répondent à ce type de vote ou de questionnaires je pense c'est plutôt on va le découvrir. Est ce
que c'est plutôt des gens qui sont en agence ou des salariés ou je sais pas des frilances. Je
sais pas du tout. On va peut-être découvrir ça plus tard. Ah oui il y a des emplois.
Ça c'est intéressant de voir comment il se calige. C'est ce que j'allais dire.
J'allais dire ok ça fait 3 ans que tu es deaf mais à quel à coup de combien de temps on peut dire
que tu es un deaf senior ou que tu es plus junior. La question est compliquée parce que ça fait 5
ans que tu fais la même chose. Bon t'as pas vraiment évolué tu vois. Ouais après c'est super
difficile et de toute façon c'est toujours une question. Après parce que moi je pense que c'est
intimement lié à la personne et à son investissement ou à comment il bosse parce qu'il y a
des gens au bout de 5 ans peut-être qui seront qui vont qui vont pas beaucoup évoluer et d'autres
peut-être au bout de 3 ans ils ont un niveau de compréhension et ils peuvent être déclarés
comme senior même si je reste intimement convaincu qu'il faut quand même passer du temps sur un
frémoire ou sur une technologie avant de comprendre toutes les subtilités qu'il y a derrière ça
prend du temps. Après il y a des gens qui ont des capacités d'apprentissage qui sont on n'est pas
tous égaux là dessus et donc il y a des gens qui vont passer senior ou là pour le terme qui
utilise ses mid-levels intermédiaires on va dire. Bon il y a des gens qui vont passer intermédiaires
ou senior beaucoup plus vite que d'autres parce qu'ils ont des facultés d'apprentissage ou peut-être
qui passent plus de temps à coder à côté ou voilà un ensemble de choses qui vont faire que mais c'est
dur de décrire vraiment des règles en disant quand tu passes tel niveau ça veut dire que tu es senior
ou à tel niveau je pense c'est vraiment propre à la personne et à la maturité sur la technologie
qui l'utilise. Après il y a le côté techno il y a aussi le côté mentalité aussi comment tu
réagis comment tu solves les problèmes en fait comment tu trouves des idées machin mais c'est
pas que le code non plus tu vois quand tu fasses un problème et puis il y a aussi souvent et on a le
syndrome de la posteur aussi tu vois il y a des gens qui non mais je suis pas senior même si les
mecs sont super bons des mecs ils diront jamais qu'ils sont seniors tu vois il y a aussi ça le
syndrome. Et à l'inverse il y en a aussi qui vont se déclarer comme senior parce que ça fait trois
ans qu'ils sont sur une techno et ils ont fait trois projets et ils disent c'est bon je suis senior
et en fait c'est hyper difficile mais c'est de la raison. En fait il y a le syndrome de la posteur
et il y a aussi l'inverse des gens qui n'ont pas beaucoup beaucoup de vécu et qui vont se déclarer
comme syndrome de la posture. On va dire ça. Du coup ils bossent à bah parfait.
Ils bossent chez qui les personnes qui ont des grosses boîtes apparemment. Et clairement là
c'est vraiment des grosses boîtes quoi. Il y a plus d'un tiers enfin quasiment un tiers c'est que des
grosses boîtes plus de 500 en plus. Oui c'est juste énorme. Plus de 500 c'est vraiment beaucoup
beaucoup quoi. Il y a très très peu de friands quoi. Les friands ça a 10%. Après 2 à 10 qui est
le on va dire l'équipe tech. Après en fait attention parce que là en fait quand on dit 500 ça
se trouve c'est des boîtes de 500 personnes mais le département dev ils sont plus petits en fait.
En fait ils bossent ils bossent pour une boîte je sais pas qui fait.
Ils bossent chez Total mais. Ouais voilà ils bossent chez Total dans la partie IT mais leurs boîtes
elles correspondent à 500 donc il faudrait voir à bah voilà combien il y a de dev dans la boîte.
Ça c'est intéressant. Et donc là en fait on arrive à des résultats plus mitigés.
En même temps il y a moins de 5 donc voilà c'est des équipes de 5 par contre c'est des
frontaines des dev frontaine quoi. Ouais il parle de frontaine développeur. Exactement et donc du
coup j'ai perdu le fil. De frontaine donc 5 après 10 plus de 100 plus de 100 frontaine là c'est
pour une ssd ou des choses comme ça. C'est en Inde ou un truc comme ça non. Non c'est en Europe.
On a vu que c'était en Europe. Comme non mais j'ai vu mal à imaginer une boîte qui a 100
développeurs frontaine. Et du coup en fait comment ils décrivent leur compagnie enfin leur boîte
dans la Calibos et bah ouais. Agence et Tech First, Digital First compagnie. Ouais c'est des
grosses agences quoi. Des boîtes de développement donc je pense que ça peut être des ssd z quoi.
On parle de framework. Passant la techno c'est bon. Voilà on va éviter toutes les gégères de
clochette. Non justement c'est ce qui m'intéressait. Bon ça est sans surprise. React reste toujours hyper
hyper hyper liké quoi. Utilisé et aimé même s'il y a une différence peut-être entre utiliser
aimé mais bon n'importe. Premier React, deuxième Next, troisième vu et Angular. Par contre ce
qu'on voit c'est une nette différence entre il y a une grosse baisse entre Angular entre 2020 et 2021.
Ouais 2021 et 2020. Ce qui fait qu'il y a une grosse régression de Angular. Ça fait un moment
Angular est en baisse d'année en année et on voit que ça continue donc pourquoi je ne sais pas.
Après vu reste à peu près pareil mais bon il y a une nette domination de React et de Next.
D'autant. Après c'est pas pourquoi ils ont séparé Next et React. Ils ont séparé vu et
nukes. Alors comment c'est pour moi c'est la même chose quoi. Tu fais du vu, tu fais du nukes.
Oui après j'ai toujours du mal à comprendre des personnes qui sur des projets un peu ambitieux
qui vont faire une appli React ou une appli vu avec la Ciel Eye classique. Et derrière ils vont être
obligés de faire plein de choses à la mano alors que Next ou nukes te fait ça très très bien et
va vous amener, va faire plein de choses pour nous sous le capot automatique et va optimiser
plein de choses. Enfin en termes d'expérience de développement sur des applications d'envergure.
Il n'y a quand même pas photo quoi. Même si moi je suis d'avis de même sur des petites apps
c'est tellement plus facile. Pourquoi se prendre la tête ? Il y a tellement de choses qui sont fait
automatiquement quoi. Et bien tu as la même chose entre Next et React. Aujourd'hui c'est pareil.
Tu ne vas pas faire un sucre React à la mano, tu vas tout taper. Même si Next et Next c'est
complètement différent. Next fait beaucoup plus de choses, va beaucoup plus loin pour t'aider à
développer que Next. Next il y a beaucoup de moins de choses qui sont intégrées. Je peux faire plus de
choses là. Il n'y a pas de plus de choses sur Next. Bien sûr, depuis combien de temps vous le dis
que Next ? Et du coup sans surprise en fait les techno qui sont le moins likés, la première c'est
Angular. Et donc on explique le recul. En fait la question c'est celui que vous avez utilisé et que
vous avez détesté en fait. Le plus détesté. Et le premier c'est Angular quoi. C'est réglé.
Et le deuxième c'est React. Alors bon. Tu veux une guégaire ? Les gens ils répondent.
C'est normal. C'est le plus utilisé. Donc forcément il y a plus de gens qui détestent.
Tu vois c'est logique. Mais par contre Angular il est moins utilisé et il y a beaucoup de gens
qui détestent. Donc c'est... Donc c'est... C'est vraiment significatif. C'est quand même...
Ouais il y a une grosse... Gatsby. Gatsby, forcément Gatsby il a beaucoup évolué.
Depuis la version 2, 3, 4 ça évolue très vite. Ils sont partis sur un mode d'évolution.
À l'Angular ça va très vite. Les migrations sont de plus en plus rapides.
C'est des petites évolutions de... Ça va vite. Ça va vite. Ils implémentent beaucoup de choses.
Ils sont de plus en plus couplés avec leur Gatsby Cloud, leur système d'hébergement.
Et ça devient dur à suivre en fait. Donc je pense que de plus en plus ça
se complique. Et Gatsby en fait, il se complique des choses.
Enfin, Next c'est beaucoup plus facile et je vois beaucoup de gens qui migrent en fait de Gatsby
à Next en fait. Parce que ça devient un Gatsby il va trop vite en fait je pense.
Donc ouais. Pas forcément là. On le voit à très soon.
Vu par contre je comprends pas pourquoi les gens ils aiment pas.
C'est bizarre. Mais non mais après il y a... Je pense qu'il y a des gens...
Après en fait quand t'es familiarisé avec un frémoire qu'en fait le fait de changer
t'as une période d'adaptation qui va se passer plus ou moins bien.
Il y a des gens juste ils n'aiment pas. Et après sans rentrer dans la guerre de
clocher. Mais après il y a des gens qui vont choisir leur camp. Et l'autre camp c'est l'edmé.
C'est le mal. Ça c'est pour tout ça. Mais voilà.
C'est donc... C'est ça. Exactement. Du coup je pense qu'on va retrouver les mêmes.
Et ceux qui ont choisi leur camp sur React ou même Svelte qui est une grosse communauté aussi
qui est très active. Mais qui pour l'instant c'est sûr et bien en dessous d'être un
concurrent à React sur le nombre d'utilisateurs. Après sur la philosophie, sur l'approche.
Il faut le surveiller parce que c'est un système qui est de plus en plus apprécié.
Il y a le Svelte kit qui permet de faire du SSR. Après Svelte c'est pas vraiment une librairie.
Parce que c'est plutôt un compilateur. En fait il t'écrit ton truc. Il te compile tout le système.
C'est un peu différent des autres systèmes. Mais je vois qu'il est de plus en plus apprécié.
Versel a investi sur Svelte. Je crois qu'ils ont embauché le développeur de Svelte, le créateur,
pour continuer à ce qui développe Svelte. C'est vraiment la techno à surveiller là
prochainement. Parce que on voit que les gens qui l'utilisent l'apprécient. Et d'ailleurs ça se
voit dans le graphique. Et c'est dans les derniers de ceux qui sont moins appréciés.
Et là Svelte, il est juste derrière vue. Et donc il y a une grosse progression sur Svelte.
Attention, c'est vraiment la techno. Et je suis hyper râtonné de voir qu'il y a des gens
qui gasient. Ils ont pas le choix. C'est qu'ils sont sur des techno où ils utilisent backbone.
Ils sont peut-être en train de faire la migration. Je ne suis même pas sûr que c'est encore
maintenu. Il y a très longtemps. Et on revient sur la même chose. Quels frameworks on a envie
d'apprendre dans le futur ? Et on retrouve en premier Svelte. Et ça pousse derrière Remix,
puis Next, puis Vue, puis React et Nux. Donc React était en grand. C'était le truc que tout le monde
prend en 2020. Et en 2021, il est beaucoup, beaucoup, beaucoup moins. Et la progression
en fait bascule sur clairement Svelte et Remix. Après Remix et Next, ça reste sur React.
On va dire que les mecs ont appris React. Maintenant, ils passent sur Remix et Next.
Et puis ça passe. Mais en même temps, c'est peut-être une suite logique aussi.
C'est des outils. Pour ceux qui ne connaissent pas Remix, c'est un framework qui est sorti en
V1, peut-être en octobre, novembre dernier. C'est les gars de React Router qui ont créé ce
framework. À la base, ils étaient payants, puis ils ont eu un investissement. Et donc, ça leur a
permis de le mettre en open source. Et c'est un système hyper novateur. Ils ont vraiment
tous les fondamentaux de HTML, HTTP, etc. Et le truc est vraiment bien. Et en plus, ils ont annoncé
qu'à terme, il ne sera plus du tout lié à React. On pourra faire un framework agnostic.
Remix, c'est vraiment un super, super système. Mais qui est encore assez jeune,
mais qui est stable. Bon projet. On déroule sur les petites libérées.
Enfin, les petites, non, ce n'est pas des petites, mais sur les libérées qu'on utilise le plus.
Axios, Laudach, Redux, Dat, FNS, Moment. Et donc, on voit dans les cinq premières,
il y a déjà deux qui ne gèrent que la gestion des dates. Parce que les dates,
c'est compliqué à gérer. Et donc, c'est des librairies qu'on utilise tout le temps.
Ça nous facilite la vie quand même pas mal. T'es pas trop fan de librairies de dates ?
Je trouve que les dates avec JS, c'est plus facile. Je n'ai pas utilisé dernièrement un
système de dates. Enfin, tu n'as pas fait des trucs hyper complexes en dates.
Mais après, quand tu vois ma…
Le moment de JS, il est hyper lourd.
Oui, oui. Mais justement, là, on parle de dates FNS. Moi, j'utilise une autre qui s'appelle
Djs et qui, pour le coup, utilise les mêmes APIs, mais qui sont beaucoup, beaucoup, beaucoup
plus légères. Et par contre, quand tu dois faire des manipulations, des calculs de dates,
avec… oui, faire… ajoutent trois jours, ajoutent quatre jours. Ok, ça, ça se débloque
dans sept jours, l'autre dans 14. Voilà, toutes ces opérations-là, c'est vachement plus
facile de le faire avec des librairies. Après, Axios, tu le matchs, quoi. À-dessus…
Axios, ouais.
Axios est beaucoup en tournage.
Et beaucoup en tournage.
Et puis, l'Odache, mine de rien, il y a quand même pas mal de petites fonctions,
même s'il y en a de moins en moins qui sont utiles, parce qu'avec la dernière version
de Djs, on a de plus en plus des possibilités de faire ça en natif. Par contre, il y a des
méthodes un petit peu plus complexes qui restent quand même hyper pratiques, quoi.
Donc…
Ouais, mais l'Odache, c'est un peu… Ouais, comme tu dis, il y a de moins en moins de trucs qui
sont… Enfin, tu peux faire en natif.

Il y a plein de choses que tu peux faire en natif. Et petit à petit, son utilité va être de moins
en moins présente, parce qu'en fait, c'est un peu à la jQuery, quoi. En fait, avec l'évolution
de JavaScript, on aura de moins en moins besoin de l'Odache et puis va disparaître petit à petit.
Ouais. Même s'il y a quand même des fonctions. Ouais, carrément. Et derrière, il y a Apollo,
donc qui est un client graffQL qui, à mon avis, est le plus gros client graffQL.
Le premier.
Ouais, ouais, ouais.
Et le meilleur peut-être, non ? Je sais pas, ce qu'est-ce qu'on pense ?
Je… C'est lourd. Après, en fait, ils ont plein de systèmes de cache, enfin, ils ont plein de
plugins, plein de possibilités. C'est un niveau de granularité qui est assez, assez élevé.
Après, il y a plein de clients qui se sont développés beaucoup plus léger, hyper light.
Et enfin, straight forward, quoi. C'est vraiment hyper simple. Et donc beaucoup, beaucoup plus
léger. Moi, je me rappelle, alors, ça date un peu, mais sur les derniers projets, j'ai des clients
plus léger. Par contre, quand j'avais installé Apollo, ouais, fait la config de Apollo,
wouah, tu transpirais un peu, quoi. Ok, en fait, je veux injecter mon token ou des choses comme ça.
C'était… t'avais vachement, vachement des tapes et c'était assez complexe. Peut-être que
maintenant, sur les dernières versions, ça s'est vachement amélioré. Ça s'est un peu simplifié.
Par contre, il y a un niveau de granularité, un niveau de précision qui est hyper, hyper poussé.
Du coup, c'est super, super intéressant avec leur optimistique UI et tout ça, avec l'optimisation
du cache et… intéressant, quoi. Et faut pas oublier, et je le fais la plupart du temps, tu peux faire
du GraphQL avec Axios, puisque le requin de GraphQL, c'est du texte, en fait.
Mais même avec Fetch, quoi, un truc. Tout ça avec Fetch aussi. Donc, des fois,
il n'y a pas besoin de mettre une librairie GraphQL pour faire du GraphQL. Axios ou Fetch,
suffit, quoi. Si vous avez des petits projets, il n'y a pas besoin de se prendre en tête.
Ouais. Après, aujourd'hui, il y a des petits clients qui vont nous faciliter la vie et que ça
va être plus facile à utiliser, mais une simple Axios ou Fetch marche.
Il y en a un qui a pas mal celui comme il se l'appelle, c'est RQL ou un truc comme ça, je ne sais plus.
Ouais. J'ai pas encore testé celui-là. Et celui qu'on déteste, que les gens détestent le plus,
mais qui les ont utilisés et qui le détestent le plus, le problème.
Ah oui, bah ouais.
Redux.
Il était déjà troisième dans l'utilisation juste avant, et là, il est le plus détesté et je
confirme. Pour quoi on déteste Redux ? C'est pas qu'on déteste, en fait.
C'est juste qu'il est hyper verbeux. C'est vrai que c'est un peu l'apollo,
quoi. Quand tu veux le mettre en place, c'est chiant, en fait. C'est beaucoup d'écriture de
code, tout ça. Des fois, c'est un peu dur à maintenir. C'est un peu illisible,
des fois aussi, si tu as mal démerdé. Ouais. Je valide.
Et en deuxième, c'est Moment. Et à mon avis, ça doit être à cause de la lourdeur ou des
choses comme ça. Ça, c'est clair. Ça te plombe tes stats. Mais en même temps, il y a d'autres solutions.
On parle de DatFNS ou DGS, qui sont des équivalents qui utilisent les mêmes API,
donc le transfert se fait assez facilement. Et en termes d'optimisation, c'est vachement plus
l'ight. Je ne sais pas ce que c'est, Ramda. Je ne connais pas. Je ne connais pas.
Et qu'est-ce que les gens ont envie d'apprendre dans le futur ? En premier, c'est Apollo,
Erics, Js, Relais, Redux, Ramda, Dat. Après, je pense que je ne pense pas qu'il y avait une,
en fait, le choix était imposé, je pense, sur les librairies parce que c'est curieux,
en fait, qu'on retrouve exactement les mêmes. Donc je suppose qu'il y avait des librairies imposées.
Oui, apprendre à utiliser Apollo, ça veut dire qu'il y a une tendance qui va sur le
GraphQL. Oui, parce que c'était un relais juste après. Et sinon, Erics, Js, c'est un système
qui est utilisé en interne sur Angular, système d'événement de pipe et tout ça. Très intéressant,
par contre, c'est complexe. Je ne sais jamais réussir à m'y faire. Je ne sais pas si tu as mis
les mains dedans. C'est assez spécial. En fait, tu fais les pipes, il y a des événements qui vont
faire des trucs. C'est les tuyaux. Tu branches les tuyaux. C'est totalement intégré à Angular,
donc ça marche très bien. C'est hyper populaire comme librairie, mais je vois quand même des
gens qui veulent l'apprendre encore. On parle un peu de design maintenant. Qu'est-ce qu'ils
utilisent comme design ? Est-ce qu'ils utilisent des librairies toutes prêtes, type Angular ?
Non, pas n'importe quoi. Excuse-moi. type Bootstrap, Tywin, Material UI, où ils apportent leur propre
solution. La sans surprise, on arrive à 30% sur des solutions custom, mais en même temps, il faut
aussi mettre en parallèle le fait que c'était des boîtes. C'est plutôt des grosses boîtes. Ils
ne vont pas implanter leur propre solution parce qu'il faut tout brander. Ils sont déjà en place.
Sans surprise, ils vont tout faire à la main. Par contre, sur des plus petites agences,
ils vont peut-être plus vite utiliser des designs systèmes qui sont déjà…
Ouais, c'est dépend des projets. Dès déjà en place. Après, est-ce que si tu utilises Tywin,
CSS, mais tu fais toi-même tes composants et tu designes tes composants, est-ce que c'est une
custom solution ? Bah ouais. En fait, on a pas mal de boîtes qui commencent à construire leurs
designs systèmes, sérieusement avec du storybook ou d'autres systèmes, avec vraiment leurs
componentes et compagnie. Dans ce cas-là, c'est du custom solution. Après, tout ce qui est
matériel UI, c'est le choix de la facilité. Je déteste ces trucs-là. C'est le choix de la
facilité. Souvent, c'est difficile à maintenir. C'est lourd. C'est comme bootstrap. Après,
matériel UI est super utilisé. Ça, c'est clair. Surtout avec React. Mais ça va bien pour une admine.
Tu fais une admine, tu ne veux pas t'emmerder à faire les composants. Mais après, sur du front,
vraiment, je n'ai pas du mal à comprendre qu'on puisse utiliser matériel UI.
T'es dur. Non, mais je déteste ces trucs-là. À la base, je déteste bootstrap,
tous ces trucs-là. Et là, matériel UI, je vois tout le temps des gens qui l'utilisent. Je
déteste ça. Ça te fait tellement de dépendance difficile à maintenir dans ton projet. Allez,
sans surprise, c'est le SCSS qui arrive devant et talonné derrière par Tywin.
Tywin a grave prix. On l'avait dit. On était tous comme ça.
Moi, le premier, j'étais là. Quand j'ai vu la version 0, je me suis dit, c'est quoi ce truc ?
Et puis aujourd'hui, je fais que ça. Et je trouve ça trop bien. Et ça, dans mes composants,
c'est vachement plus facile. C'est trop bien. Après, je pense qu'une migration sur un nouveau
projet, ça se fait. Par contre, une migration sur un projet qui est déjà en place avec tout un
design system où tu as tout fait en sas, machin. Faire une migration, ça sert à rien. Tu ne vas
pas refaire un truc. Surtout quand tu commences à faire un design system, tu ne le fais pas pour
deux ans. Tywin, je connais personne qui s'y est mis et qui te dit, je déteste. La plupart des
gens disent, moi, je n'aime pas. Et tu l'as utilisé. Non. Ah bon, d'accord. Ils n'ont pas mis
post-CSS, c'est quand même vachement bien. D'ailleurs, perso, je ne fais plus trop de ça.
C'est plutôt sur du post-CSS. Alors, je ne sais pas toi. Il y a un truc que j'ai complètement banni
mon code CSS. Tu sais, quand tu imbriques les trucs, les nestages. C'est complètement banni. En fait,
je me suis rendu compte qu'à terme, c'était illisible. En fait, ton projet, c'est horrible.
En fait, moi, je ne vais pas l'utiliser tellement parce que, en fait, je vais avoir beaucoup de
composants. Et donc, clairement, tout va être dans des composants. Moi, chez la plupart du temps,
je fais du vues. Du coup, ça va tout être dans des composants vues. Donc, par définition, je vais
avoir très peu d'imbriquations. Je ne vais pas avoir des feuilles de CSS à rallonge. Donc,
c'est assez vite lisible parce que j'essaie de faire des composants pas trop petits non plus,
mais pas des trucs trop gros. Trouver le bon juste milieu. Et donc, en fait, toutes les
figures de, enfin, toutes les feuilles de style soient vont être directement dans le HTML parce
que je fais du thaiouine. Et donc, ça va être des classes. Et quand la classe commence à être trop,
trop longue, en fait, je la déporte dans un truc style pour justement, pour gagner en lecture sur
Montain Plate, pour éviter d'avoir des classes. Quand je conserve 10, 12 classes, ça commence
à être un peu un peu un peu lourd et compliqué à lire. Du coup, je la déporte dans le style,
ce qui me donne plus de l'asibilité. Avec un apply. Exactement, avec un apply. Et c'est là
où en fait, on arrive directement sur justement les outils de développement où on va utiliser
ESLint, Prétyer pour justement formater et faciliter la lecture de notre code. Donc, clairement,
je ne suis pas surpris que c'est des outils que quasiment tout le monde utilise parce qu'il y a
d'autant plus quand on est sur des projets où il y a plusieurs personnes qui ont leur,
enfin où il y a plusieurs personnes qui interviennent sur le projet, chacun va avoir ces
manières de l'initier dans son éditeur. Et donc, le fait de mettre ça, on vient normaliser sur
ce projet, on utilise cette règle-là et tout le monde utilise la même, sinon en fait, c'est le
chantier. Et en fait, tu crées des comites juste parce que le formatage est différent. Et donc,
ça, ce n'est pas bien du tout. Non, tout projet, c'est ESLint avec les règles écrites sur un
fichier Prétyer avec les règles. J'ai même d'autres trucs qui s'appellent ESKi qui vont jouer
les tests et tout, ESLint tout ça avant de comiter. Enfin, il y a plein d'outils comme ça, mais ESLint
des Prétyer, c'est obligatoire. Il fait ça possible. Ça serait pas mal de faire justement
un épisode vraiment sur les lintards et sur les tools qu'il y a tout autour pour nous aider.
Je pense que ça pourrait être vraiment intéressant. On voit que Webpack est encore très présent,
76% et Vite 25%. Mais Vite, il n'a qu'un nom. Voilà. Mais déjà, 25%. Et ESbuild qui est aussi
dans la même partie. Après, Parcell qui, on n'a pas trop l'historique. On ne sait pas si c'est
la V1 ou la V2, mais après, on en a déjà parlé dans l'épisode précédent. Cette migration V1,
V2 qui a été longue, tout ça, ça n'a pas aidé. Allez, on parle de TypeScript.
Spoiler alert. Du coup, est-ce que les utilisateurs ont utilisé TypeScript ?
Attends, je vais faire une annonce. Spoiler alert. Episodes TypeScript prochainement.
Alors, on va juste faire un limit. On ne va pas trop débattre de TypeScript là. On va juste regarder
les usages et on va vraiment commenter que le questionnaire et on développera
vraiment TypeScript dans le prochain épisode. On fait ça ?
Ouais, on peut quand même dire qu'il y a 84% des gens qui ont répondu qui utilisent TypeScript.
Déjà. Donc, ça veut dire qu'il y a une grosse adoption. Il y a une grosse adoption. Et en
contre, les gouvernements, les non-tech firsts, on panie tout ça. On voit que, de toute façon,
ça a 80%. Bon, mais en fait, ils vivissent tous.
Ça use de manière vraiment significative. Et il y a une grosse progression sur TypeScript.
Et TypeScript va remplacer Javascript en termes de nouveaux standards sur le front.
En fait, c'est leur opinion. Est-ce que TypeScript va remplacer le Javascript ?
Oui et non, mais enfin, remplacer non parce que c'est juste pour développer. Après,
Javascript, ça reste le langage du navigateur. A part pour Deno, pour le côté serveur.
Oui, c'est un type de script. D'ailleurs, je ne me sens pas si compilé,
Deno, je ne suis pas sûr. J'ai pas de souviens. Je te rappelle qu'on a un épisode là-dessus.
Oui, pardon. J'ai aucune souviensse, mais mettez-vous au TypeScript rapidement.
Par contre, il va falloir que nous fassons un épisode sur TypeScript pour nous convaincre
avec tous tes arguments. On n'en parle dans le prochain épisode.
Ça marche. SSG, donc la génération de sites statiques, hashtag jamstack, hashtag
statique is the new dynamic. Ça marche. Du coup, grosse, grosse régression dans l'ensemble
sur tous les générateurs. Next, Moins, Gatsby, beaucoup, beaucoup moins. Comment tu expliques ça ?
En fait, parce que ça a évolué et qu'on se rend compte qu'il y a une limite.
Gatsby, comme je l'ai dit déjà tout à l'heure, le truc est devenu trop complexe et trop difficile
à suivre. Il y a eu un effet de mode aussi dans lequel j'étais aussi dedans. J'aime bien Gatsby,
mais je n'en fais plus aujourd'hui, quasiment plus. On voit quand même qu'il y a entre 35 et 40%
de gens qui n'ont pas utilisé de SSG sur le sondage. Next, sa force, c'est qu'il est capable de faire
du statique, du dynamique, un peu de tout sur le même projet. On se rend compte que le
statique est quand même limité quand tu arrives sur des gros sites avec beaucoup de pages,
on arrive à des problématiques qu'on n'a pas forcément sur du rendu serveur. C'est ce qui fait
qu'avec le recul au bout de 2-3 ans d'utilisation de ce générateur de sites statiques, on se rend compte
des limites. Les outils évoluent parce que Gatsby a aussi introduit des systèmes de pages générés
à la demande. Les outils évoluent, après les mentalités évoluent. On a testé, ça ne marche pas.
Enfin, ça ne s'adapte pas à tous les projets. Oui, ce n'est pas adapté à tous les projets.
Et clairement, c'est un peu la tendance, tu vois, et lequel générateur de sites statiques
que vous utilisez le plus ? Quel est votre favori ? En première position, ce n'est non aucun.
Donc, ce qui veut bien dire qu'il y a eu une appétence, après on a peut-être touché du doigt les limites,
et c'est ce que Next, NUXT, sont en train de faire. C'est une solution un peu hybride,
c'est-à-dire, ok, il y a des pages statiques, mais il y a aussi des pages qui sont générées à la volée.
Et donc, il faut trouver un juste milieu entre les deux, et on voit bien l'évolution de ces deux
frémoires qui tentent vers ça, sur une sorte de réhydratation au fur et à mesure,
un mix entre du statique et du SSR. Il faut un mix, il faut un système comme Next,
ou comme Next, le prochain de la version 3, qui fait du statique, qui fait du rendu serveur,
qui est capable de faire en fonction des pages du rendu différent, et ils tentent tous là-dessus.
Ce qui prend tous les générateurs de ces statiques, aujourd'hui, ils proposent leur
système de SSR, même Eleventy, aujourd'hui, il tend un petit peu sur une partie SSR aussi,
parce qu'à un moment donné, il était limité.
Ouais, bien sûr. Ok, on passe sur l'hébergement. En première position,
sans surprise, Amazon Web Service. Merci Jeff. Il fait tout quoi. Il est trop fort, Jeff.
En deuxième position, c'est des propres solutions qui gèrent à eux-mêmes leurs serveurs,
qui sont peut-être hébergés chez Amazon. Oui, c'est possible aussi.
Mais en même temps, avoir leurs propres serveurs, ça veut dire qu'il faut les gérer et tout.
Donc là, je pense qu'on est vraiment face à des boîtes qui ont une grosse grosse
infrastructure. Et derrière, Versel et Netlify, qui sont en grosse, grosse progression,
qui sont en grosse progression, parce que c'est facilitant pour les devs, surtout sur du front,
où ça va bilder automatiquement et ça va déployer automatiquement. Tu vas pouvoir
faire ce qu'ils appellent les Atomic Diploi, où tu peux revenir sur un comite précédent.
Enfin, c'est hyper, hyper, hyper facile et facilitant. Ça va automatiquement monter les PR,
tout. Alors, je ne connais pas Amazon, mais on peut sans doute le faire sur Amazon Web Service.
Par contre, la config est beaucoup plus compliquée. Et là, sur Versel, c'est en trois clics, c'est fait.
Et donc, on n'a pas besoin d'être DevOps pour pouvoir mettre ça en place et faire une
poulre request, demander l'approbation soit du chef de projet, soit du client sur la PR qui est
automatiquement montée. Et derrière, c'est validé, où on fait des décorrectifs. Une fois que c'est
validé, ça passe en prod. C'est un outil, c'est des outils monstrueux. Donc, je ne suis pas surpris
qu'il y ait une grosse progression là-dessus. Enfin, moi, je parle de Versel, parce que c'est
plus adapté à Next. Dernièrement, c'est hyper. Quand tu mets un Dev qui ne connaît pas
Versel, tu ne mets sur Versel, mais qui ne veut plus en sortir. Mais c'est pareil sur Netlify.
Oui, c'est pareil. Je suis beaucoup plus sur Netlify. Quelqu'un qui ne connaît pas, tu lui montres ça,
il hallucine. C'est trop bien. Mais en fait, ce qui est triste, c'est que maintenant,
je montre ça aux étudiants. Ils font leur site, ils débloient. Ils sont là, c'est cool,
en mode normal. Mais mec, tu ne sais pas tout ce que tu devais faire. Et là, le pain que ça
surtout pour les Dev-Counts, vachement plus facile. Je suis étonné qu'il n'y ait pas,
comment s'appelle, le passe, là. Merde, j'oublie le nom, là. Il y a un violet logo.
Héros coups. Héros coups, je suis étonné qu'il n'y ait pas héros coups dans la viste.
Après, peut-être qu'il n'y avait pas la suggestion.
Mais c'est sûr que tous ces passes, les plateformes à des services,
ça a vachement explosé et c'est vachement plus facile. Je pense que ça serait intéressant de
faire un épisode dessus aussi. On peut faire un épisode. Moi, il n'est pas aussi.
Squalling Go passe français qui est plutôt pas mal. On en parle dans l'épisode.
Je suis pas sponsorisé. Sur les passes. Mais clairement, c'est vraiment...
Je pense qu'il y a une grosse pression là-dessus. Est-ce qu'ils utilisent du
déploiement, d'une intégration continue, grande sans surprise, 80% oui, évidemment.
Et quel est l'outil le plus utilisé pour faire cette intégration continue ?
GitHub Action. Mais en même temps, c'est super récent.
Exactement. C'est super récent. On voit l'énorme progression.
Jenkins a perdu un tout petit peu. GitLab, si il y a perdu un petit peu.
Mais la grosse progression, c'est GitHub Action. Mais en même temps, GitHub Action a
vraiment investi... Enfin, GitHub a vachement investi là-dessus. Ils ont des plateformes
de Marketplace avec toutes les actions. Et c'est pas surprenant qui truste en fait ça.
Parce que si on va voir ça sur Losting, je suppose que derrière, beaucoup de gens sont chez GitHub.
Et donc, le fait d'avoir les GitHub Action directement intégrés dans le même repo,
on rajoute un fichier. Il y a une Marketplace de ouf avec plein de fichiers qu'on peut intégrer
directement. Le Gamble, ce n'est pas si compliqué que ça. Mais surtout, toutes les actions génériques,
en fait, standards, elles sont déjà codées. Donc, on n'a plus qu'à faire un install,
bim, bim, click, click et c'est fait. Donc, ça nous facilite la vie énormément. Et je crois qu'il y a
1000... Je ne sais plus combien de minutes gratuites, des minutes de build par mois pour les free
users et pour les users pro, les users payants chez GitHub, ils ont un petit peu plus. Et
on peut faire plein de choses. C'est marqué que c'est passé de 35% en 2020 à 56% en 2022
en GitHub Action. Donc, ça a vraiment une grosse progression. Et bien oui. Bon, voilà, cool.
Ensuite, micro front end. Alors, celle-là, je n'ai pas compris la question en fait.
C'est surtout la suite à ce qu'on comprend encore moins en fait.
C'est là que je ne comprends pas du tout cette question et encore moins les réponses où
ils mélangent bit avec module federation et web components. Alors, est-ce que tu utilises des
micro front end ? La réponse est à 75%. Elle est non. Mais en même temps, qu'est-ce que tu mets
dans... Qu'est-ce qu'un micro front end ? Je ne sais pas. Alors, pour le coup, s'il y a des
mecs qui connaissent, éclairer nous. Balancez-nous un lien sous la vidéo ou quelque part. Mais là,
on est un peu single aspera. Oui, d'un pile. On n'arrive pas. On skipe, please help.
Browser technologie. La technologie la plus utilisée dans notre navigateur. Les websockets.
La clipboard à API et géoloc API. Et ouais, clairement logique. Logique. Après, quand tu
commences à jouer avec du websocket, ça change un peu la manière de faire. Mais en fait,
c'est vraiment trop cool. C'est vraiment trop cool. Parce que, ouais, c'est côté instantané.
Quand tu es greffé à du GraphQL ou sur Routes, comme ça, forcément, ça m'appelait.
Je me rappelle, pour un client, j'avais codé le système de présence. Si l'utilisateur est
connecté depuis moins de 4 minutes, en fait, si la dernière fois qu'il a été vu,
c'était moins de 4 minutes, alors tu affiches comme quoi il est connecté. Et du coup, c'est
comme les trucs de forum à l'époque. Exactement.
T'es connecté ou pas, ça change tout. Franchement, c'est assez cool. Du coup,
pas surprenant. Après, le clipboard API, c'est vrai qu'il y a de plus en plus sur les devs.
On copie tout le temps des infos. Du coup, c'est des petits tools qui sont plutôt rapides et
qui marchent. Et je l'ai aux questions pour tout ce qui est web app sur mobile.
Exactement. Exactement. Sur mobile, ça passe très bien. Allez, le code éditeur. Alors là,
c'est pas la gégare. Là, c'est avec la gégare sur les éditeurs de code et sans surprise,
le trust total de chez Microsoft avec son Visual Studio Code. Ouais, alors ça,
75%. D'un côté, c'est normal puisqu'il est gratuit alors que GeneBrain,
le WebStorm ou le PHPStorm, il est payant. Ouais. C'est ça calme.
Ouais. Après, il y a 20% des gens qui sont prêts à payer pour avoir une idée de quel
genre de code. Après, je pense que c'est comme tout. Du temps passé, une fois qu'on a configuré
son outil, ça va plutôt bien marcher. Visual Studio Code marche vraiment bien. Il y a plein
de plugins, j'ai un tout plein d'intégrés. Là, je vais m'en faire qui commence à se former sur
le dev. Je lui ai dit install Visual Studio Code direct. Il avait installé Sublime, mais bon,
Sublime marche bien d'ailleurs. Une dernière version qui est sortie il n'y avait pas longtemps.
Très, très rapide. Moi, ce qui me fait halluciner, c'est vraiment bien. Et à
quand je veux lire un fichier, il s'ouvre avec Sublime. Si j'ouvre le projet, je vais l'ouvrir
avec Visual Studio Code pour gérer le projet. Par contre, si je veux ouvrir que un fichier,
je n'ai pas à mettre les règles pour qu'il s'ouvre directement avec Sublime parce que ça
va tellement, tellement rapide. C'est l'inatif Mac, direct. Visual Studio, c'est du nôtre.
C'est pas électron. Est-ce que vous utilisez des éditeurs de code en ligne à 41% ? Non.
Ça marche bien franchement. Oui, ça marche super bien. Le deuxième, c'est Code Sandbox
qui est plutôt bien. Par contre, moi, j'ai découvert StackBit justement pour, j'ai découvert avec
VIT pour implémenter sur VIT, VIT et NUXT3 pour faire des tests en fait, pour jouer avec
des lib, c'est hyper rapide, c'est super efficace et franchement, c'est impressionnant. Et ça marche
plutôt bien pour tester des lib pour faire des... Ouais, ça marche super bien. En tout cas, moi,
c'est vraiment mon utilisation en ligne, c'est pour tester des lib, tester une manière de faire
un truc hyper rapide. Ça m'évite de faire un projet Playground où je viens tester Crash,
Crash tester en local. Là, c'est directement dans le navigateur. C'est vraiment super rapide.
Non, ça marche super bien. Ça est vraiment pratique pour faire des projets, pour tester des trucs,
d'installer des paquets, genre deux secondes, machin, code sandbox, ils en avaient rajouté un
système qui était en Rust, je crois, qui compilait dans le navigateur. Ils s'améliorent tous au
fur et à mesure, ça marche vraiment du tonnerre, en fait, tu peux vraiment coder avec... Et pareil,
CodePen ou CodeSendbox, pareil, si on veut regarder des exemples d'implémentation de
librairie, on va chercher là-dedans, entre GitHub ou aller chercher dans CodePen ou dans CodeSendbox,
dans StackBlix aussi. Il y a des collections de gens qui ont sauvegardé leurs projets. Et en fait,
on va voir qu'il y a plein d'exemples d'implémentation et en fait, c'est vachement utile. C'est vachement
utile parce qu'on voit comment ils ont fait. Après, parfois, il faut pas tout prendre, il faut pas
faire du copier-coller. Mais en fait, on peut voir leur implementation et ça, c'est vraiment super
pratique. Et je trouve que c'est des outils qui sont vachement pratiques pour...
Tu vois le truc, tu forques, tu fais ton truc, tu modifies. Par contre, je suis surpris. Alors,
c'est pas... C'est un code editor, mais il n'y a pas le système de privé-visualisation comme les
autres, mais juste l'éditeur VS Code qui est dans GitHub, en fait, quand tu appuies sur le point et
que tu... Le GitHub, pourquoi ? Et oui, tu vas sur NINB. Mais après peut-être qu'il est... C'est hyper
récent, qui... Oui, c'est vrai que c'est récent. Ils ont implémenté ça assez rapidement. Mais oui,
sur n'importe quel ripot, vous allez... Vous tapez point et bim. Ça s'ouvre dans VS Code online et
vous pouvez utiliser... Ouais, puis tu peux synchroniser avec ton compte et tout. Ça te met toutes tes
plugins et tout. Enfin, c'est vraiment de la balle, quoi. Ton setup, ouais, clairement. Version,
version, contrôle. Voilà, c'est agréable. Bon, c'est GitHub qui truste tout à 75%. Le deuxième,
c'est GitHub, Bitbucket et les autres nonnes. C'est-à-dire, ça veut dire qu'il y a 2%
des gens qui ne versionnent pas leur code ? Non, tout en respecté. Version 1, version 2. Ça,
c'est les designers. Ça t'a... Ça t'a... Allez, on passe au test. Testing. Faut faire des tests,
attention. C'est important. Ouais, alors qui est en charge de mettre en place les tests ? Donc,
c'est les développeurs et l'équipe de recétage, comme on dit en français. De recétage. Ouais, QNA,
ouais. Quo-A c'est... Quo-A c'est... Quality insurance. Et c'est quand même les développeurs.
Mais bon, dans ensemble, c'est plutôt les développeurs qui vont quand même faire leur code.
Est-ce que tu as fait tes codes toi-même, ben 80% ? Oui. Et là, le plus gros des tests,
c'est les tests unitaires. Ouais, c'est le minimum, franchement. Enfin, franchement,
faut se forcer à faire des tests. Ceux qui écoutent, forcez-vous à faire des tests. Le minimum,
c'est des tests unitaires. Et après, des tests d'intégration, c'est sans doute plus long à mettre
en place. Mais enfin, excuse-moi, là où je veux venir, c'était sur des tests end-to-end. C'est
vraiment plus long à mettre en place, peut-être. Il y a des outils maintenant. Par contre, ouais,
ouais. Et je pense qu'on devra parler un jour de Cypress ou de Playwright de chez Microsoft.
Mais clairement, aujourd'hui, on peut tester vraiment end-to-end, tester des features,
tout ça marche quand même plutôt pas mal. Donc, il faut tester. Et les librairies de tests,
on y arrive. Il n'y a pas de tests parce que c'est trop récent. Ouais, je pense que
ça serait intéressant de regarder l'année prochaine, de regarder entre gestes et vitestes pour voir
s'il y a une grosse percée de vitest, même si tout l'écosystème vit et tout ce qui
gravite autour est en train de troster beaucoup de choses, enfin, troster. Une grosse, grosse progression.
Et donc, on retrouve Cypress, Cypress qui est une grosse librairie de end-to-end qui nous
permet de faire des choses. Et ce qui est super intéressant, c'est que dans la dernière version,
avec le studio, ou peut-être pas dans la dernière version, mais depuis qu'ils ont
sorti la fonctionnalité studio, ils peuvent, on peut enregistrer les clics. Et donc,
ça vient nous écrire les recettes au fur et à mesure. Alors, il y a toujours des
ajustements à faire, mais c'est quand même plutôt très bien fait. Il y a un 80% du boulot
qui est fait, ce qui fait qu'après, il nous suffit de réajuster sur la précision des éléments
ou des choses comme ça. C'est assez pas mal. Donc, c'est tester avec des gros outils qu'on
connaît déjà. Tester à fond. Je serai tranquille. Quand tu déploies, tu sais que ça marche.
Vous dormez à être tranquille. Les best-practice.
Voilà, c'est un petit peu plus... Tu vois, on peut passer vite fait,
les derniers trucs. C'est un petit peu, qu'est-ce qu'ils font en best-practice ?
Moi, ce qui me surprend quand même, c'est Search Optimization, le SEO. Ils disent,
ouais, on s'en fout en fait. Après, ça va vraiment dépendre du projet.
C'est pas notre lamin. Mais en même temps, on l'avait déjà dit quand on avait reçu Nicolas sur
l'épisode SEO. Si c'est implémenté dès le départ, c'est vachement plus facile. Il faut.
Donc, sur l'arborécence, sur la structuration des pages et sur tous les éléments in-page,
c'est hyper... Un truc qui est cool, c'est qu'ils font plus d'accessibilité que de SEO.
Donc, ça, c'est bien. Les deux sont bien aussi. Après, on est quand même rentré à plus de 50%
sur du responsive. Ça ressemble à... Que 50%. Non, mais Always et Often.
Ça veut dire que tu as quand même des gars qui font des sites non responsibles.
Après, en fait, il faut comprendre l'usage. Si par exemple, tu fais un logiciel interne pour une boîte
qui va être utilisé sur les ordi, tu sais très bien que ça sert à rien de te prendre la tête.
C'est hyper spécifique. Voilà. Donc, sur la spécificité, tout. Par contre, moi, ce qui m'intéresse,
c'est quand même la performance. On voit que c'est quand même important. Il faut faire quand même
des sites assez performants. C'est rentré à tête des gens, c'est sûr.
C'est rentré dans les merces. Et la user experience, est-ce que l'expérience utilisateur est importante ?
Oui, toujours à 55%. Et la développeur expérience ? C'est important aussi.
Mais bon, il ne faut pas que la développeur expérience prime sur la user expérience.
C'est quand même l'utilisateur final qui a le plus de pouvoir que le développeur.
Yes, on déroule. Le dernier.
Ah, les best practices que vous voulez mettre en place. Du coup, du code review,
de l'intégration continue avec du déploiement continue, du versioning, du scrum.
En premier, c'est la code review. Et je pense que c'est quand même pas mal.
Ça, c'est top, le code review. Après, il faut quand même déjà avoir du monde pour faire du review.
Il faut déjà avoir plusieurs développeurs. Mais si vous êtes dans une équipe de plusieurs développeurs,
faites de code review. C'est hyper important. Même si on est bon, on peut envoyer des trucs,
une erreur, un importe, ou un truc qui est mal fait, qui pourrait être un peu mieux fait.
C'est vraiment important. Ça fait progresser celui qui lit et celui qui élu.
C'est vraiment une très bonne pratique dans une équipe de dev.
Et pour revenir sur les best practices et sur le futur, on voit qu'il y a des grosses tendances
sur l'accessibilité, sur les applications cross-platformes.
Et sur du service side rendering. Le SSR est de retour.
Mais peut-être d'une autre manière qu'on a pu le connaître avec des applications monolithiques.
Totalement différent. C'est un peu changé. Ça reste du service side rendering, mais fait
différemment. Quand c'est nécessaire.
Et je pense que toutes les solutions, type Netlify, Edge,
vont vachement aider.
Et il y a une baisse de popularité sur la Jamstack, sur le terme Jamstack,
où j'inscrit un pays, markup, langage. On vient toucher la limite d'un système.
Moi, je pense que la Jamstack, elle va évoluer justement.
Avec le SSR. On est déjà dedans.
Il y a une grosse évolution. La fin de l'année dernière et puis la cette année, ça continue.
Les outils évoluent et les pratiques aussi.
Yes !
Écoute, pas mal ce petit state of…
Bon, qu'est-ce qu'on peut en dire ?
Il n'y a pas de surprise.
Il n'y a pas de surprise.
C'est une tendance un peu globale.
Il y a une grosse amélioration. Les gens vont vers du type script.
Ça, c'est vrai.
Hashtag, future épisode bientôt.
Grosse évolution aussi sur la régression des sites statiques purs type Jamstack
dévoqué, qui va de même avec l'évolution du SSR, qui prend une autre dimension.
React est toujours dominant.
Il y a toujours autant de monde sur React.
Faites du vu, c'est cool.
Oui, vu, c'est cool. Après, ce n'est pas moi qui vais dire le contraire.
Je suis fan.
Faites des tests.
Faites des tests importants.
Testez.
Yes.
C'est cool.
Très bien.
Un grand merci à tout le monde d'être resté jusqu'au bout.
Pensez à partager, liker l'épisode.
Ça nous fait toujours plaisir.
Mettez des pouces.
Des pouces.
Pardon, tu m'étends de pouces.
Et des commentaires aussi, parce qu'on n'a pas beaucoup sur Apple Podcast.
Exactement.
Soit sur podcast, soit sur Youtube, mais ça fait toujours plaisir.
Et on vous dit à bientôt.
Ciao ciao.
A plus.