Discussion :

[Olivier Famien]

Ilias estime que le développement front-end est plus complexe qu’il ne parait
les bons développeurs front-end sont-ils rares et difficile à trouver ?

Pour développer les applications web, plusieurs aspects doivent être pris en compte. Nous avons dans un premier temps la partie visible permettant d’interagir avec l’utilisateur et dans un second temps la partie immergée qui traitent les éléments en arrière-plan tels que les bases de données, les paramètres de configuration de l’application web, des serveurs, etc.

La partie visible est réalisée par les développeurs front-end et la partie immergée de l’application web est gérée par les développeurs back-end.

Pour accomplir leurs missions, les développeurs front-end utilisent certaines technologies comme les langages de développement web à savoir HTML, CSS ou encore JavaScript. Les développeurs back-end, par contre, se réfèrent aux outils de gestion de bases de données, aux frameworks client-serveur, etc.

De manière générale, il est reconnu que les aptitudes réclamées aux développeurs back-end sont assez complexes. Mais qu’en est-il des développeurs front-end ?

Ilias Ismanalijev, qui est également développeur frontal et designer, après avoir jaugé la perception que le public a des développeurs front-end a voulu corriger certaines idées reçues qui tendent à montrer cette profession comme un métier assez facile et donc accessible à tout le monde.

Pour lui, même si l’on ne rejette pas les difficultés liées au développement côté serveur, il est toutefois bon de reconnaître que le côté client en dénombre beaucoup et donc s’avère plus complexe qu’on pourrait le penser.

Pour commencer, Ilias souligne que lorsque les développeurs front-end conçoivent leurs applications web, l’usage des CSS commence déjà à poser problème une fois que le site devient assez large ou profond. En effet, il va falloir garder en mémoire tous les petits détails de présentation des documents HTML.

Aussi, dès que l’on touche à JavaScript, d’autres problèmes pointent également le nez. Nous avons entre autres des problèmes de performances dus à l’utilisation de ce langage et des bibliothèques dérivées. Et ces problèmes s’accroissent à mesure que vous vous retrouvez en face d’un grand nombre de lignes de code.

Une autre difficulté également relevée est le changement constant observé dans l’environnement de développement des applications ou sites web. Ces changements imposent de mettre à jour les connaissances acquises à un rythme insoutenable. Et pour le nouveau développeur, cela est encore plus difficile, car dès qu'il met les pieds dans l’environnement il est déjà dépassé. Il doit ainsi chercher sans fin à rattraper son retard avec des outils en constante évolution.

En outre, au-delà de ces fonctions de base, plusieurs autres compétences sont demandées aux développeurs front-end. Ces derniers doivent par exemple être capables de maîtriser les aspects de cache HTTP, l’optimisation du temps de recherche DNS, la sélection du meilleur moteur de présentation CSS pour le projet, etc.

De même, vu que le travail du développeur frontal est directement lié au client, il lui est recommandé d'avoir des notions en design ainsi qu’une bonne compréhension du marketing. Cela sous-entend également, connaitre la psychologie du consommateur, rendre accessible à tout moment le service fourni et maintenir un bon positionnement sur les moteurs de recherche.

À ces éléments, il faut ajouter le volet sécurité qui nécessite de mettre en œuvre des mécanismes de protection contre les attaques de types XSS, CSRF, l’usurpation de DNS, le détournement de clic, etc.

Enfin, cette présentation resterait incomplète si l'on ne parlait pas de la compatibilité avec les différentes plateformes qu'il faut entretenir. En effet, en jetant un coup d’œil uniquement du côté des navigateurs, la tâche non plus n'est pas aisée. Le développeur front-end doit s’assurer que son implémentation est fonctionnelle aussi bien sur plusieurs versions d’un même navigateur que sur différents types de navigateurs. À côté de cela, il faut également tenir compte des différents types d’appareils (mobile, tablette…) et les différents systèmes pour lesquels son code doit être fonctionnel.

Aussi, en considérant le fait que les fonctionnalités des applications front-end sont en interaction permanente avec le volet back-end, Ilias continue pour dire qu’un bon développeur front-end sera forcément amené à mettre la main dans le côté back-end. Et d'ajouter, « un bon développeur front-end doit être également un bon développeur back-end ».

Tous ces éléments poussent Ilias à conclure que le métier de développeur front-end est beaucoup plus difficile que l’on pourrait croire. Et trouver un bon développeur front-end pourrait s'avérer plus ardu que ce que des « non-initiés » pourraient penser. Ces propos viennent rappeler ceux de Bulat Bochkariov, également développeur front-end, lorsqu'il affirmait que « nous travaillons avec des outils de merde sur les plateformes incompatibles gérées par chaque type d’appareil que vous pouvez imaginer... en faisant en sorte que le produit fonctionne pour tout le monde ».

Source : Medium

Et vous ?

Que pensez-vous du point de vue d'Ilias sur le métier de développeur front-end ? A-t-il raison ?

Ou plutôt pensez-vous que cette présentation du métier de développeur front-end est surfaite ?

Voir aussi

Forum développement web

[MikeRowSoft]

Oui, cela demande quelques notions d'arts et d'avoir suivi des études ou des formations dans le domaine.
Le film "le rois lion" par exemple est vraiment un mauvais présage philosophique, mais pourtant presque tous le monde à aimé, et cela sans y voir ou comprendre un mot de la chanson principale, de l'histoire et du scénario.

[psykokarl]

Ilias comme beaucoup confond, ou a confondu, ce qui relève de la complexité et ce qui relève de la criticité.
Dans le Web, ce qui est Front peut être autant, voir d'avantage, compliqué que ce qui est Back. Le truc est que très souvent un problème Front se traduit par des problèmes d'affichage ou d'interactivité. C'est toujours moins grave que des problèmes au niveau de la gestion du système ou la sécurisation des données. Il est techniquement possible de gérer l'aspect critique coté Front, mais cela ne se fait pas pour des raisons évidentes de sécurité.
Indépendamment des questions stratégiques de mise en oeuvre, la complexité du Front peut varier de la simple page HTML à la papy à un enchevêtrement complexe de XHTML et de canvas interactif animé à coup de webgl avec prise en compte de pas mal d'aspect sécurité.

[captainKirk]

Nous ça fait longtemps que nous ne faisons plus de distinction entre développeurs front-end et développeurs back-end. Nous avons des développeurs, point. Chacun d'eux travaille de manière verticale, c'est à dire qu'il est capable d'intervenir sur n'importe quel aspect du projet. Franchement ça fonctionne bien mieux comme ça.

[SylvainPV]

Selon moi , le développement (front ou back) doit être complètement déconnecté du design et de l'ergonomie. Ce n'est pas le même métier ! Ce ne sont pas les mêmes thématiques, contraintes, outils... pour m'être égaré un moment, je peux aussi affirmer que les conférences UI/UX n'ont rien à voir avec les conférences de développement.

Certes en tant que dev front, j'ai appris quelques trucs en travaillant aux côtés de designers et d'ergonomes. Mais c'est loin d'être suffisant pour m'affirmer professionnel dans le domaine. J'ai un peu honte du design de mes sites persos Nos designers et ergonomes sont aussi amenés parfois à faire de l'intégration et un peu de code JavaScript. Eh bien ils ont appris quelques trucs aussi, mais c'est loin d'être acceptable. Généralement ça va à la poubelle dès qu'on reçoit les livrables

Ça ne veut pas dire qu'on peut pas faire les deux, peut-être que Ilias est un touche-à-tout. Mais d'après moi c'est préférable de chercher deux profils différents, chacun sa spécialité.

[NSKis]

Il y en a marre de ces éternels discours "il manque des spécialistes", "il manque des milliers d'informaticiens, blabla..."

Si il y avait pénurie, les acteurs de l'informatique seraient les premiers à s'en rendre compte parce que, vu leur rareté, on leur proposerait des salaires de ministres!!!!

Est-ce que quelqu'un sur ce forum, a vu son salaire doublé, triplé, ces derniers temps?

[psykokarl]

Non. Ils refoulent du monde à l'entrée mais un dev suffisamment bon peut encore se tirer d'une boite qui ne lui plait pas. Je suppose que ce dernier point doit changer...

[dfiad77pro]

Il y en a marre de ces éternels discours "il manque des spécialistes", "il manque des milliers d'informaticiens, blabla..."

Si il y avait pénurie, les acteurs de l'informatique seraient les premiers à s'en rendre compte parce que, vu leur rareté, on leur proposerait des salaires de ministres!!!!

Est-ce que quelqu'un sur ce forum, a vu son salaire doublé, triplé, ces derniers temps?

Faire croire à une pénurie sert à multiplier le nombre d'étudiant en informatique, pour ensuite pouvoir tirer les salaires vers le bas.
C'est une technique que la Syntec affectionne particulièrement et qu'elle utilise depuis quelques années déjà.

D'autre part, on embauche des bac+5 pour faire du pissage de code, et après on se plain que ça coute trop cher ...
Pour moi un ingénieur et quelqu’un qui conçoit, pas quelqu’un qui se fait tout dicter dans un dossier de spec techniques déjà établi.

[Invité]

De toutes manières, dire qu'il manque des informaticiens c'est comme dire qu'il manque des gens dans le btp : ça n'a aucun sens. L'informatique est un domaine très très large qui compte de nombreux métiers, il suffit qu'il y ai pénurie dans un métier de l'informatique pour que nos chers médias nous pondent une jolie généralité...

Pour rester dans le sujet sur le front end, c'est comme tout. Savoir faire du HTML/CSS/JS et connaitre les subtilités les plus connues sans chercher plus loin suffira à intégrer une créa artistique et sera suffisant pour un bon paquet de sites, et ce n'est vraiment pas très compliqué. Et puis il y a ceux qui s'intéressent un minimum au coté serveur qui leur fourni les données à afficher, à ce que recherchent les internautes en termes d'ergonomie, se tiennent informés des dernières technos, etc. Et là c'est une autre paire de manches : c'est un véritable écosystème à comprendre et des compétences variées à posséder.

[air-dex]

Je reprends plus ou moins ce que je dis ici, dans un autre fil de discussion.

Si le développement front-end Web est plus complexe qu'il n'y parait, c'est aussi parce qu'au fond les technologies de développement front-end Web n'évoluent pas ou peu. Il y a une manière de concevoir des UI Webs qui est celle du trio HTML-CSS-JavaScript et si tu veux faire des UIs Web, c'est ça ou rien. Pire, le HTML 5 accentue ce problème. Tout ce qui n'appartient pas au trio HTML 5 - CSS 3 - JS est tabou, comme par exemple Flash quelles que soient ses qualités. HTML 5 donne également beaucoup trop de place au CSS. HTML devient un vulgaire sac à composants de page Web et tout est agencé par CSS, un langage fourre-tout où se mêlent architecture d'une page et look and feel de celle-ci. Il faudrait coder ses pages Web avec seulement des <div> et autres <span> et faire tout le reste avec du CSS. Le JS, quant à lui, ne doit être là que pour manipuler le sacro-saint DOM, modifier les propriétés CSS et communiquer avec le backend. Si t'es pas capable de raisonner comme ça alors tu peux faire une croix sur le développement front-end. C'est beaucoup trop bas niveau pour du développement Web moderne.

Alors oui il y a des nouvelles technologies, mais cela reste trop souvent de la poudre aux yeux. Ce ne sont que des surcouches qui au final font perdre des performances car il faut les transpiler au moment où on les utilise. Par exemple, LESS et SASS ont beau amener des améliorations à CSS, cela ne sert pas à grand chose puisqu'au final on ne manipulera toujours que du CSS dans le JS de nos pages Web. Idem avec l'HTML. On bâtit des technologies au dessus, mais on ne s'en éloigne surtout pas philosophiquement. Il y a des langages au dessus de JavaScript comme CoffeeScript ou TypeScript, mais il faut les traduire en JS si on les utilise côté client sur les pages Web, ce qui fait fatalement chuter les performances. Pour moi il n'y a qu'une poignée de technologies qui valent le coup côté front-end, notamment parce qu'elles amènent du haut niveau dans ce monde où on en manque cruellement : Bootstrap, jQuery et React.

Pour devenir moins complexe, les technologies Web doivent s'ouvrir. Elles doivent s'ouvrir à des technologies qui ne soient pas dans les moteurs des navigateurs. Elles doivent s'ouvrir à des philosophies de conception d'interface qui ne soient pas celle d'HTML et CSS. Elles doivent s'ouvrir à des pages Web conçues de manière plus haut-niveau que ce que HTML, CSS et JS proposent. Il faut que ces technologies dissocient l'architecture d'une page (layouts) et son thème / look and feel. Sans ça le développement front-end restera complexe. Bootstrap, jQuery et React sont un bon début et il faut continuer le combat.

L'article parle aussi de fragmentation. Il est vrai que c'est un problème, mais je pense qu'il est amener à disparaître à l'avenir. Qu'on le veuille ou non, le tandem Webkit/V8 (ou Blink/V8) devient chaque jour un peu plus un standard. Opera a jeté l'éponge pour Presto/Carakan. Firefox est en train de faire sombrer Gecko/SpiderMonkey. Microsoft défend son Trident/Chakra avec Edge mais comme pour Gecko/SpiderMonkey combien de temps tiendront-ils encore ? Je pense aussi au JavaScript hors navigateur sur lequel Node.js, basé sur Webkit/V8, est en train de faire main basse.

[MikeRowSoft]

Si le développement front-end Web est plus complexe qu'il n'y parait, c'est aussi parce qu'au fond les technologies de développement front-end Web n'évoluent pas ou peu.

Pour moi un front-end Web est comme l'ensemble des pages d'administrations ou gestions d'un modem-routeur. Donc somme toute très différent des pages web standard ayant pour objectif de captivé l'intérêt, commercial ou promotionnel ou fonctionnel, des internautes.

Bootstrap, jQuery et React sont un bon début et il faut continuer le combat.

J'espère qu'ils font mieux que les systèmes d'exploitation livré par défaut avec un extracteur de CD Audio, car la cours de justice Européenne l'a fait payé à Microsoft, c'est retrouvé satisfaite mais n'a jamais su comment cette outil c'est retrouvé implanté par défaut dans Windows Media Player et par la suite iTunes (qui ont réussi là où Microsoft à échouer), ainsi que presque toutes les distributions Linux. Et cela depuis Windows XP.
Probablement un problème de modération.

[Invité]

Pour devenir moins complexe, les technologies Web doivent s'ouvrir. Elles doivent s'ouvrir à des technologies qui ne soient pas dans les moteurs des navigateurs. Elles doivent s'ouvrir à des philosophies de conception d'interface qui ne soient pas celle d'HTML et CSS. Elles doivent s'ouvrir à des pages Web conçues de manière plus haut-niveau que ce que HTML, CSS et JS proposent. Il faut que ces technologies dissocient l'architecture d'une page (layouts) et son thème / look and feel. Sans ça le développement front-end restera complexe. Bootstrap, jQuery et React sont un bon début et il faut continuer le combat.

Je ne comprend pas bien ce que tu reproches au trio html/css/js pour le développement front end. Tu souhaiterais avoir un autre moyen de gérer le layout de ta page que le css tout en utilisant le css pour le style (ou inversement) ? Je trouve que le layout est une partie intégrante du look de la page et ca ne me semble pas particulièrement pertinent de le gérer d'une autre manière.

De plus bootstrap et jquery ca reste de la manipulation de css et de dom (jamais utilisé react donc je ne me prononce pas pour celui là), du coup je suis vraiment perplexe face à ce que tu dis.

[Sodium]

D'expérience, voir du code HTML et CSS clair, simple et maintenable est extrêmement rare. La majorité des "développeurs front-end" ont appris en dilettante et comblent leurs lacunes en multipliant l'usage de plugins javascript et frameworks CSS inutiles. Cela donne des pages extrêmement lourdes qui chargent des dizaines de fichiers, des feuilles de style qui font des milliers et des milliers de lignes impossibles à optimiser tant la tâche est énorme. Bootstrap est l'un des problèmes majeurs actuels avec des milliers de lignes de CSS chargées pour un résultat qui n'en prendrait qu'une centaine en se limitant aux besoins réels du projet.

Le soucis est que peu de "developpeurs front end" (souvent des webdesigners ou des développeurs back-end qui s'y sont mis par besoin) font la démarche de se documenter sur les subtilités des différents langages utilisés, les bonnes méthodes de travail et les conventions.

[mothsART]

Le dev frontend : plus difficile qu'il n'y parait ?
Comme toujours : ça dépend du contexte...

Est-ce que l'appli est du one-shot avec un cahier des charges restreint ou nécessite de la maintenance corrective/évolutive?
Quel est le cadre de fonctionnement et exigences :
* version de navigateurs supportés, utilisation via mobiles/tablettes ou uniquement desktop traditionnel ?
* Quel est l'environnement pro : est-ce qu'il y a un graphiste et/ou un ergonome par exemple ou le dev front joue ce(s) rôle(s) également (toute les boites ne peuvent pas se permettre d'avoir une personne pour chaque tâche) ?
* Appli publique ou privé ?
* quel est la cible ?
* etc.

Mon constat sur le dev frontend c'est qu'il est passé d'un format proche de l'artisanat à de l'industriel depuis quelques années (c'est plus du tout le même job) :
Il y a peu, créer l'ensemble de son css/html/js à la mano était plutôt la norme avec des tests en réel.
Le dev back à déjà franchi ce cap depuis longtemps d'ou la disparité sur le marché des devs front.

La multiplication des devices et les projets de + en + complexe avec des délais de + en + serré a fait basculé le dev front dans des perspectives plus industriel :
* utilisation de framework
* automatisation des dépendances, des tests etc.
* création de composants réutilisables

Constat et revers de la médail: le front, en l'état n'est pas vraiment prévu pour ce genre d'exigence :

* Utiliser des frameworks demande des investissements en formation non négligeable et un investissement sur 1 framework par rapport à un autre est fortement spéculatif. (react, angular, angular2 ou riot? CofeeScript, Dart ou TypeScript ? Less, Sass, Stylus ou PostCss ? Gult, grunt ou )
* Automatiser le front nécessite de bien comprendre ce qui est en dessous le plus souvent et avoir de bonnes connaissances en back (ou de bonnes interactions avec les devs backend) est presque toujours bénéfique.
* utiliser trop de lib Js tue les performances souvent pour pas grand chose alors que certaines initialement idenspensables (jquery) deviennent peu à peu anecdotique => cf vanillaJS.
* le js est un langage dynamique idéal pour faire du prototypage (ça plait aux commerciaux d'avoir un truc "proof of concept" rapidement) mais une horreur incroyable en maintenance => typage innexistant, architecture merdique (vrai POO)
Ecmascript 6 améliore beaucoup de choses à ce niveau mais qu'il soit supporté par 90 % des utilisateurs finaux : va y'avoir des octets qui vont couler dans les tuyaux.

Qui dit industrialisation dit pour moi R&D et ça c'est vraiment pas ancré dans les esprits.
Consacrer des équipes ou des heures de travail sur de la recherche pure donc sans résultat immédiat.
La plupart des devs frontend passionnés et sortant du lot font en réalité ce taf en dehors de leurs heures de travail...

[SylvainPV]

Si le développement front-end Web est plus complexe qu'il n'y parait, c'est aussi parce qu'au fond les technologies de développement front-end Web n'évoluent pas ou peu. Il y a une manière de concevoir des UI Webs qui est celle du trio HTML-CSS-JavaScript et si tu veux faire des UIs Web, c'est ça ou rien. Pire, le HTML 5 accentue ce problème. Tout ce qui n'appartient pas au trio HTML 5 - CSS 3 - JS est tabou, comme par exemple Flash quelles que soient ses qualités. HTML 5 donne également beaucoup trop de place au CSS. HTML devient un vulgaire sac à composants de page Web et tout est agencé par CSS, un langage fourre-tout où se mêlent architecture d'une page et look and feel de celle-ci. Il faudrait coder ses pages Web avec seulement des <div> et autres <span> et faire tout le reste avec du CSS. Le JS, quant à lui, ne doit être là que pour manipuler le sacro-saint DOM, modifier les propriétés CSS et communiquer avec le backend. Si t'es pas capable de raisonner comme ça alors tu peux faire une croix sur le développement front-end. C'est beaucoup trop bas niveau pour du développement Web moderne.

Au contraire, le web front-end évolue énormément ces dernières années, bien plus que les technos back. C'est d'ailleurs une source de complaintes régulières, car personne n'arrive à suivre toutes les nouveautés.

En responsive web design, domaine que je connais bien puisque c'est mon domaine de spécialisation, le look and feel et le layout sont intimement liés. Si on prend l'exemple d'un menu de navigation par exemple, le positionnement, la taille et le style varient de manière homogène entre différentes media queries. De ce point de vue, CSS est plutôt bien conçu (même si je suis d'accord que le layout en CSS est assez mal foutu). Après, si tu souhaites quand même séparer les deux, tu en as tout à fait la possibilité ; c'est d'ailleurs la démarche choisie par plusieurs frameworks UI qui proposent des composants et des thèmes.

Flash oblige les utilisateurs à installer un plug-in, n'est pas compatible avec de nombreuses plates-formes et présente de grosses failles de sécurité régulièrement. Le web se doit d'être sécurisé et universellement accessible, c'est pour ça que ce sont les éditeurs de navigateurs eux-même qui font le choix de retirer le support de Flash et de tout autre plugin. Et franchement, quand je retombe sur un site full Flash, je ne suis pas mécontent qu'on soit derrière tout ça. C'était une catastrophe, pas accessible, impossible à crawler/inspecter, code fermé, plantages et j'en passe.

Enfin, si tu codes ton HTML qu'avec des <div> et des <span>, je doute que quelqu'un veuille t'embaucher

Pour moi un front-end Web est comme l'ensemble des pages d'administrations ou gestions d'un modem-routeur. Donc somme toute très différent des pages web standard ayant pour objectif de captivé l'intérêt, commercial ou promotionnel ou fonctionnel, des internautes.

Non, web front-end signifie simplement toute la partie côté client d'un site web, côté navigateur si tu préfères. Certains englobent aussi dans le terme les langages de vues côté serveur comme PHP ou JSP, mais tout ça tend à disparaître.

[mothsART]

Enfin, si tu codes ton HTML qu'avec des <div> et des <span>, je doute que quelqu'un veuille t'embaucher

Tout dépend : si c'est dans un contexte fermé (pas de référencement) full appli : la sémantique ne peut avoir que peu d'intérêt.
Attention à toute forme d’extrémisme : certaines règles n'ont de raisons que dans un contexte donné.

[SylvainPV]

Ce n'est pas qu'une question de SEO. Une bonne sémantique est essentielle pour l'accessibilité, l'adaptation aux différents terminaux, la communication entre machines... Il n'y a pas de bonne raison de ne pas faire de HTML sémantique.

[mothsART]

Ce n'est pas qu'une question de SEO. Une bonne sémantique est essentielle pour l'accessibilité, l'adaptation aux différents terminaux, la communication entre machines... Il n'y a pas de bonne raison de ne pas faire de HTML sémantique.

Oui, enfin, ça c'est la théorie... dans la pratique c'est loin d'être aussi évident.

La sémantique ça demande des connaissances (et uniformisation des connaissances : dans des grosses équipe, c'est fragile), de la réflexion, de la veille et par conséquent du temps qui n'a pas forcément de retour sur investissement. (ou reste difficilement palpable)
Cet investissement doit être justifié et j'estime qu'il y a plein de cas ou il n'y est tout simplement pas.

Y'a l'idéologie et les habitudes d'un côté et la réalité/le bon sens de l'autre.


Par analogie, optimiser du code avant même d'avoir fait le tour des contraintes techniques est un non sens => donner du sens à des données avant même d'en avoir établi les intérêts est une perte de temps.

[mothsART]

L'article parle aussi de fragmentation. Il est vrai que c'est un problème, mais je pense qu'il est amener à disparaître à l'avenir. Qu'on le veuille ou non, le tandem Webkit/V8 (ou Blink/V8) devient chaque jour un peu plus un standard. Opera a jeté l'éponge pour Presto/Carakan. Firefox est en train de faire sombrer Gecko/SpiderMonkey. Microsoft défend son Trident/Chakra avec Edge mais comme pour Gecko/SpiderMonkey combien de temps tiendront-ils encore ? Je pense aussi au JavaScript hors navigateur sur lequel Node.js, basé sur Webkit/V8, est en train de faire main basse.

Le monopole d'un moteur de rendu me semble forcément une mauvaise idée : l'époque "only IE" a suffisament marqué les esprits.

Quand je vois ce graphique : https://upload.wikimedia.org/wikiped...b_browsers.svg, je me dis qu'il reste encore de la marge.
D'ailleurs, Microsoft a assez d'argument pour ne pas mourir de si tôt... en douter c'est mettre la tête dans le sable. (et pourtant, je suis loin d'être partisant)

De plus, chaque techno va, à mon sens, mourrir un jour ou l'autre et plus son monopole peut être imposant plus sa chute peut être prompt :
* car le moteur sera trop gros et inmaintenable : plein de dead-code à refactoriser, taille de l'exe excessif, consommation de mémoire difficilement prédictible et améliorable etc.
* changement d'usage
* certains pilier du projets abandonne le navire (imaginez par ex Linus torvald abandonner Linux : ça aurait forcément des incidences économiques)
* etc

Mozilla a pris la décision de repenser leur moteur de zéro (Servo) avec un nouveau langage (Rust).
Ça va les mettre dans une situation périeuse pendant une paire d'année mais derrière, si ça abouti (je dis bien si car les facteurs sont multiples), ils auront un avantage technologique incroyable!

[SylvainPV]

Le HTML n'est pas vraiment le langage le plus compliqué à apprendre... J'ai imprimé une cheat sheet, ça tient sur 2 pages et dit tout ce qu'il y a à savoir sur les balises sémantiques HTML5. Une norme qui rappelons-le a succédé à HTML 4.01, sorti quinze ans plus tôt ! Pas trop dur la veille technique...

Et puis, ce n'est pas noir ou blanc. Pas besoin d'être un pro de la sémantique pour vouloir faire un effort et essayer de choisir les bonnes balises dans la bonne situation. En connaissant une vingtaine de balises, les nouveaux types de champs de formulaire et les relations de liens, on couvre déjà 90% de ce qu'il y a à savoir en sémantique HTML.