Discussion :

[mothsART]

Je comprend pas ta logique.

Si sur un projet, la sémantique n'apporte aucune plus-value, je préfère embaucher un gars qui me pond que des <div> sans se poser de questions qu'un mec qui va perdre du temps à écrire la bonne balise ou le bon attribut... et ça, peu importe la difficulté de la norme.

Ça ne veut pas dire que dans d'autres contextes, la sémantique n'a pas une importance capitale.

[SylvainPV]

Je voudrais bien savoir dans quel projet la sémantique n'a pas de plus-value. Admettons que tu te fiches de l'indexation. Admettons que tu sais tes pages ne seront utilisées que par un humain, sans aucune déficience, sans userstyle, sans extensions navigateurs et toujours sur le même appareil, desktop de préférence. Même en admettant tout ça, ce qui est déjà assez curieux quand on parle d'un projet web, il y aura quand même toujours un intérêt à utiliser les balises sémantiques. On peut profiter des styles prédéfinis, des noms de balise explicites dans les sélecteurs CSS ou la manip du DOM en JS, ou encore des éléments interactifs tels que la validation des champs de formulaire etc...

Et je ne sais pas d'où vient cette légende selon laquelle le HTML sémantique serait compliqué et ferait perdre du temps. On parle de HTML là, il ne faut pas un doctorat ! Retenir les règles CSS pour tenter d'imiter le comportement de ces éléments est bien plus compliqué que de retenir les noms des balises elles-même.

[air-dex]

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) ?

J'aimerais avoir d'autres manières de programmer, comme cela peut être le cas dans du développement d'applications non Web. Je pense bien sûr à des manières où il ne faut pas sacrifier de performances et où un plugin Web n'est pas requis (comme Flash).

Après les détails sont les détails. Les langages de style actuel seraient très bons pour du style. Mais que pour du style, pas pour d'autres choses où l'on essaye actuellement de les rendre incontournables.

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.

Est-ce tu demandes à un architecte d'inclure la décoration de ta future maison dans les plans qu'il te fournira afin de la construire ? Non ? Pourquoi cherches-tu à le faire avec le CSS dans tes pages Web ?

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.

Je dis que ce n'est un début, qu'il faut aller vers plus de haut-niveau.

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.

Source : Le Grand Livre de Mozilla.

Je sais bien que Flash n'est pas un sain en matière de sécurité, de performances et de consommation de ressources. Je n'ai jamais dit qu'il ne fallait pas le remplacer et je suis pour son remplacement. Là où j'ai le plus râlé était sur le fait que certains semblaient vouloir aller plus vite que la musique dans la transition vers un Web sans Flash. Mais ce n'est pas le débat ici. Hormis d'être l'unique possibilité de mettre certains contenus sur les sites Web avant l'HTML 5 (comme les vidéos), la programmation Flash devait bien avoir certains avantages sur la programmation JS, non ? En voulant remplacer Flash par HTML5, on méprise et perd ces avantages là et donc de la diversité de programmation.

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

Mes <div> et autres <span> sont avant tout là pour souligner qu'il n'est pas sain de tout mettre dans le CSS, les balises HTML dans le <body> pouvant très souvent être reproduites à l'aide de ces deux là. Mais je suppose que tu l'avais compris.

Dans les docs je vois d'ailleurs souvent des "il n'est pas conseillé d'utiliser cette balise HTML, faites du CSS à la place". Je te laisse deviner ce que j'en pense.

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.

Je n'ai jamais dit que HTML était compliqué à apprendre. Perso je n'ai pas eu de difficultés à l'apprendre à l'époque où je l'ai appris et je sais coder une page HTML.

Je dis que la conception d'interfaces via HTML, CSS et JS correspond à une philosophie de conception d'interface que l'on tend hélas à imposer, surtout avec HTML 5. Imagine un monde où il faudrait coder tous ses programmes avec de la programmation fonctionnelle (LISP, Scheme, Haskell, F#...). Un monde où la POO (C++, Java, C#...), la programmation impérative (C), la programmation logique (Prolog)... seraient bannis et considérés comme des parias. Tu n'arrives pas à penser fonctionnel ? Va faire autre chose que de la programmation !

C'est comme ça que je ressens l'évolution de la création d'UI Webs avec HTML, CSS et JS. J'aime bien coder des UI d'une manière générale, mais j'ai du mal avec la manière qu'imposent HTML et CSS pour le faire (indépendamment de mon mauvais niveau en CSS où je n'arrive jamais à retenir les propriétés). Exit donc les UI Webs pour moi à cause de ça. Du coup je rage que le Web ne soit pas comme le desktop où on a plein de manières d'en faire.

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)

Déjà merci de différencier Microsoft et le duo Trident/Chakra. Quand je dis ce que je dis je pense aussi à des comportements à la Opera, où l'on abandonne son moteur maison pour embrasser le leader. Les PDMs des navigateurs avec Trident et Chakra s'érodent, ce n'est pas nouveau. Si Edge n'arrive pas à redresser la barre, il arrivera un jour où MS ne lui fera pas de cadeau et passera Edge sous Webkit (s'il ne le supprime pas). Idem avec Firefox et Gecko puis Servo (même si Mozilla sera du genre à mourir avec leurs idées ). Bien sûr cela n'arrivera pas pour Windows 10.2 ou Windows 11. Les navigateurs actuels ont encore quelques bonnes années devant eux. Mais sur le (très) long terme on va vers ce que je dis.

On a aussi en ce moment Blink qui se développe. Mais Blink étant issu de Webkit, cela va rester très proche.

[bouye]

Donc en gros si j'en crois l'article, les webmaster / développeurs de pages webs viennent de découvrir les difficultés que les développeurs de clients lourds connaissent depuis des lustres ? Chuis pas vraiment impressionné...

[grunk]

C'est beaucoup trop bas niveau pour du développement Web moderne.

On à pas tout à fait la même notion de bas niveau je crois ...

Essai de faire une custom view sur un canvas (sans librairie) avec gestion des événements et tout le basard , tu vas voir que les balises html et le css c'est quand même plutôt haut niveau.
C'est tellement pas mal que toutes les UI récente se base sur le même principe (Android , JavaFX, WPF ...).

Pour revenir au sujet , il y'a 10 ou 15 ans le front end c'était compliqué. Il fallait gérer l'absence d'outils de débogage, les navigateurs , les versions d'IE qui n'évoluait pas , le js désactivé , ou mal interprété, les version de CSS disparates, bref c'était la merde. Actuellement on est simplement confronté à des problématiques d’ingénierie logiciel communes, on à des framework qui commencent à être assez aboutis , c'est devenu moins complexe qu'avant (à mon humble avis).

[youtpout978]

Justement je suis sur un projet full front actuellement (je suis dev c# Web/desktop/mobile à l'origine), et c'est toujours assez la merde le côté front, ceux qui n'en font pas donne des délais court pensant que la mise en page d'un élément peut prendre 2h alors qu'il met des fois la journée, on nous en demande toujours plus, je boss sur un site qui doit être responsive/multi navigateur multi lingue avec comme framework JS Angular, avec des temps de dev extrêmement cours, comme seul spec des maquettes et des fichiers PSD dont je dois extraire les éléments.

Le travail d'un dev front est souvent sous-estimé surtout que beaucoup de dev web préfère se décharger de cette tâche sur un collègue sachant très bien dans quel pétrin ils peuvent se mettre.

[ddoumeche]

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.

Les SSII sauraient-elles ce quelles veulent ? cela se saurait

[ddoumeche]

Justement je suis sur un projet full front actuellement (je suis dev c# Web/desktop/mobile à l'origine), et c'est toujours assez la merde le côté front, ceux qui n'en font pas donne des délais court pensant que la mise en page d'un élément peut prendre 2h alors qu'il met des fois la journée, on nous en demande toujours plus, je boss sur un site qui doit être responsive/multi navigateur multi lingue avec comme framework JS Angular, avec des temps de dev extrêmement cours, comme seul spec des maquettes et des fichiers PSD dont je dois extraire les éléments.

Le travail d'un dev front est souvent sous-estimé surtout que beaucoup de dev web préfère se décharger de cette tâche sur un collègue sachant très bien dans quel pétrin ils peuvent se mettre.

Comment un développeur C# peut-il faire du Angular JS ? tu as eu une formation ?

[SylvainPV]

@air-dex: énormément de langages compilent en JS. Si tu ne peux pas supporter le trio HTML/JS/CSS, choisis un autre langage qui propose cette possibilité. Même si derrière ce sera toujours la même stack de technos, et que personnellement je préfère travailler au plus près des standards. Voir https://github.com/kripken/emscripte...ming-languages

@youtpout978: c'est vrai, mais grunk a aussi raison. Tout ça se simplifie peu à peu. Imagine devoir faire la même chose il y a dix ans, en devant gérer du IE7

[rattlehead]

Comment un développeur C# peut-il faire du Angular JS ? tu as eu une formation ?

en se formant. ca fait parti du metier de développeur. mais comme disait quelqu'un au dessus ca n'est pas pour ca que tu seras payé plus.

[Sodium]

Je comprend pas ta logique.
Si sur un projet, la sémantique n'apporte aucune plus-value, je préfère embaucher un gars qui me pond que des <div> sans se poser de questions qu'un mec qui va perdre du temps à écrire la bonne balise ou le bon attribut... et ça, peu importe la difficulté de la norme.
Ça ne veut pas dire que dans d'autres contextes, la sémantique n'a pas une importance capitale.

Et la lecture du code alors, que ça soit par un collègue qui travaille également sur le projet ou par soi-même dans le futur, ça n'est pas important ?
C'est d'ailleurs le problème majeur de bootstrap : des dizaines de balises purement utilitaires peu claires sémantiquement qui donnent au final un code lourd et illisible.

[rattlehead]

POur répondre à la question on peut tous être dev front to back. dans le temps on l'etait tous. mais aujourd'hui vu c'est plus compliqué. là où moi je mettrais 2 jours à faire une interface un peu sympa, un dev front va le faire en moitié moins de temps. et puis connaitre tous les hacks les petites trucs de css d'optimisation de JS et autres un dev front qui fait ca toute la journée sera franchement meilleur qu'un dev back.
Après perso j'utilise pas mal les frameworks genre bootstrap. Sinon je ferais des beaux tableaux à l'ancienne :-)

[Traroth2]

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.

D'accord avec la première partie. Mais pour la seconde, quand on attaque de véritables applications web, ça peut se corser. Ça devient du développement comme n'importe quel développement.

[Traroth2]

On à pas tout à fait la même notion de bas niveau je crois ...

Essai de faire une custom view sur un canvas (sans librairie) avec gestion des événements et tout le basard , tu vas voir que les balises html et le css c'est quand même plutôt haut niveau.
C'est tellement pas mal que toutes les UI récente se base sur le même principe (Android , JavaFX, WPF ...).

Pour revenir au sujet , il y'a 10 ou 15 ans le front end c'était compliqué. Il fallait gérer l'absence d'outils de débogage, les navigateurs , les versions d'IE qui n'évoluait pas , le js désactivé , ou mal interprété, les version de CSS disparates, bref c'était la merde. Actuellement on est simplement confronté à des problématiques d’ingénierie logiciel communes, on à des framework qui commencent à être assez aboutis , c'est devenu moins complexe qu'avant (à mon humble avis).

Oui, mais ce qu'on cherche à obtenir est bien plus complexe.

[mothsART]

Et la lecture du code alors, que ça soit par un collègue qui travaille également sur le projet ou par soi-même dans le futur, ça n'est pas important ?
C'est d'ailleurs le problème majeur de bootstrap : des dizaines de balises purement utilitaires peu claires sémantiquement qui donnent au final un code lourd et illisible.

Pour la lecture du code, un id ou une classe bien nommé est tout aussi voir plus important.
Si vraiment, c'est pas suffisant, il reste les commentaires, les logs git etc.
Et puis, franchement, j'ai pas souvenir d'avoir galéré un jour à relire du HTML.

Pour bootstrap, je suppose que t'as pas trop approfondit : leur tutos sont certes bourrés de <div> car justement ça se veut générique (ils vont pas imposer la sémantique)
Tu peux très bien choisir d'utiliser un de leur composant et remplacer un <div> par un <article> et tu constateras que le comportement sera stricto-sensu identique.

SylvainPV

On tombera sans doute pas d'accord mais il me semble que chacun des points cités sont parfaitement réfutables :
L'indexation, le crawling n'ont pas besoin de sémantique pour fonctionner parfaitement.
Si un cahier des charges n'inclus pas de déficience, de userstyle, de compatibilité avec des extensions de navigateurs, pourquoi s'en soucier ?
En quoi occulter la sémantique aurait-il un impact sur d'autres cibles que le desktop ?
Utiliser des nom de balises explicites dans les sélecteurs à la place d'ids ou de classes : quelle différence ?

Sur les "éléments interactifs tels que la validation des champs de formulaire", l'affichage des erreurs sont spécifiques à chaque navigateur : pas vraiment les attente d'uniformité attendu communément.

L'utilisation des technos web pour énormément de projets sont une hérésie d'un point de vue purement technique.
Mais rien que pour le fait qu'il y ai énormément de monde sur le marché du travail qui connaisse les rudiments de http/html/css/etc, qu'il y ait de la doc à profusion sur le net suffisent à le rendre incontournable.


La sémantique en soit n'est ni simple ni compliqué : elle inclus des tâches non automatisables... donc nécessite d'être une tâche formalisé issu d'un "besoin". (cf: définir l'expression du besoin => la base d'un cahier des charges)
Tout projet "sain" inclus également des phases de tests avant livraison.
Si tu prévois par exemple une prise en charge de déficiences, il faut prévoir les tests correspondants sinon c'est juste du flan.

[SylvainPV]

L'indexation, le crawling n'ont pas besoin de sémantique pour fonctionner parfaitement.

Qu'est-ce que tu appelles fonctionner ? Bien sûr que ton site sera indexé dans tous les cas, mais de la manière la plus pauvre qu'il soit s'il n'y a aucune sémantique. Google donne un meilleur pagerank aux pages favorisant l'accessibilité, ce qui implique une meilleure sémantique. Il valorise les keywords dans les headers <h1> à <h6>, ainsi que les liens dans <nav role="navigation">. Et il extrait des tas d'informations à partir du markup pour valoriser le résultat de la recherche. Voilà un article avec des exemples concrets: http://searchengineland.com/2014-seo...-markup-177798

Si un cahier des charges n'inclus pas de déficience, de userstyle, de compatibilité avec des extensions de navigateurs, pourquoi s'en soucier ?

Tu en as beaucoup des projets où le client pense à préciser tout ça dans le cahier des charges ? Pour moi c'est une évidence, par respect de l'utilisateur, par conscience professionnelle et surtout par bon sens.

En quoi occulter la sémantique aurait-il un impact sur d'autres cibles que le desktop ?

Elle est d'autant plus importante sur mobile où les moyens d'interaction sont différents et où les widgets UI vieillissants à base de CSS/JS n'ont pas du tout été pensés pour l'utilisation mobile. Sortir le bon layout de clavier virtuel par rapport au type de champ à saisir, fournir des aides à la saisie, favoriser l'autocomplétion, profiter des styles prédéfinis des éléments pour favoriser la lecture, proposer des options contextuelles adaptées au type d'élément... Faut-il encore plus d'exemples ?
https://msdn.microsoft.com/en-us/lib...or=-2147217396
http://mobilewebbestpractices.com/de...semantic-code/

Utiliser des nom de balises explicites dans les sélecteurs à la place d'ids ou de classes : quelle différence ?

la standardisation et la spécificité minimale, ce qui n'empêche pas d'utiliser des classes et des ids lorsqu'ils s'avèrent utiles.

Sur les "éléments interactifs tels que la validation des champs de formulaire", l'affichage des erreurs sont spécifiques à chaque navigateur : pas vraiment les attente d'uniformité attendu communément.

Uniformité, c'est un mot qui doit disparaître en web. On doit éduquer les clients par rapport à ça. Le web n'a absolument rien d'uniforme, les spécificités et les variations sont essentielles pour une bonne expérience utilisateur. Des validations de formulaire en JS qui donnent un résultat dégueulasse sur mobile, j'en vois des tonnes et c'est insupportable. Alors que HTML5 permet d'autofocus et de zoom sur les champs invalides à la soumission, avec un beau message clair, lisible et localisé qui n'attend pas qu'on appuie dessus pour disparaître.

Si tu prévois par exemple une prise en charge de déficiences, il faut prévoir les tests correspondants sinon c'est juste du flan.

Effectivement, ce n'est pas la sémantique qui va couvrir 100% des besoins en accessibilité. C'est seulement une condition sine qua non. Ça ne peut qu'être bénéfique. Et pour avoir bossé sur des projets grand public avec des contraintes d'accessibilité fortes, j'ai pu vérifier par moi-même l'intérêt de la sémantique pour les screens readers, les commandes vocales et la navigation à la trackball.

Je trouve ça quand même assez fou d'avoir encore ce débat en 2015, alors que HTML5 est omniprésent et que la norme est précisément centrée autour des nouveaux éléments sémantiques. Ça paraît tellement évident aujourd'hui que voir une soupe de <div> serait comme voir un layout à base de tableaux, ou un site bloqué à 960px de largeur tous supports confondus. Au final, on a passé 3 fois plus de temps sur cette discussion qu'il n'en faut pour apprendre la sémantique HTML5.

[mothsART]

indexation

Quand je parlais d'indexation et de crawling, je pensais pas forcément au moteur de recherche et bot correspondant
car bcp de projets se fiche du référencement ou même pire souhaite être présent sur la toile sans être référencé.

Après, je doute un peu de l'altruisme de Google sur le parsing et l'attribution du pagerank avec pour seul critère la sémantique.
Difficile de savoir comment fonctionne une boite noire.

Enfin, suis-je le seul à m'interroger sur la pertinence des données retournés par un moteur de recherche si il se base principalement sur la sémantique ?
Si on déduis que la sémantique est le fruit d'un dev et que le contenu d'une autre personne... on a potentiellement un soucis :
En temps qu'utilisateur : si le contenu que je recherche est noyé (tout simplement parce que le site est vieux) par d'autres inintéressants mais sémantiquement irréprochable...

Bon, là, il ne faut rien voir de sérieux : juste des pistes de réflexions pour éviter la pensée unique.

Tu en as beaucoup des projets où le client pense à préciser tout ça dans le cahier des charges ?
Pour moi c'est une évidence, par respect de l'utilisateur, par conscience professionnelle et surtout par bon sens.

Quand j'étais effectivement à mon compte, je le mentionnais, oui.
Et je pense avoir fait énormément de choses par soit-disant "conscience pro" sans bon sens justement.
J'aurais sans doute, avec recul, passé moins de temps (donc plus de bénéfice) pour la même satisfaction client voir d'avantage car les délais ont été raccourcis.
Un cahier des charges n'est que rarement rédigé exclusivement par le client donc si le projet sous entend de la sémantique, je vais le mentionner/l'expliquer/le chiffrer.

Uniformité, c'est un mot qui doit disparaître en web.

Ben va expliquer ça à un client... que si il passe d'un navigateur (c'est quoi un navigateur?) à l'autre le comportement et l'affichage sont pas les même. Pour lui c'est égal à "bug" et je ne lui donnerais pas tord.

Qu'une app s'adapte en fonction de la taille du périphérique ou que des interactions IHM diffère (tactile, clavier etc.) est parfaitement compréhensible si elles sont prévus et cadrés.

Et si tu fais des tests d'intégrité (avec des outils comme CasperJS), t'es obligé de créer des scénarios par navigateur... c'est juste ingérable!

Une norme sert justement à mettre tout le monde d'accord : uniformiser, en somme.

Ça ne peut qu'être bénéfique...

C'est typique de la spéculation et des croyances : tu n'en sais rien... si tu n'as pas de moyen de le quantifier.
Si j'extrapole ton principe, je suis électricien, le cahier des charges dit de poser 10 prises, j'en pose 12... ça ne peut que être bénéfique.

Et pour avoir bossé sur des projets grand public...

Je ne doute pas de tes capacités techniques à gérer des projets complexes.
Néanmoins, dans ton exemple, ça faisait parti des contraintes donc HS.

la norme est précisément centrée autour des nouveaux éléments sémantiques.

Tiens, c'est marrant, moi j'aurais dit spontannément les API ... mais t'as probablement raison.

un layout à base de tableaux

Tu crois pas si bien dire :
http://blog.goetter.fr/2015/11/08/ce...-tableau-html/

Bcp de devs se perdent dans des lobbies : il n'y a pas de bonnes ou mauvaises manières de faire les choses (surtout reproductible partout).
Il y a que des problématiques avec des solutions sous couvert de contraintes (temps, argent etc.) et ... des résultats imparfaits.

3 fois plus de temps sur cette discussion qu'il n'en faut pour apprendre la sémantique HTML5.

C'est pas parce qu'après avoir appris la mécanique, que subitement je peux réparer des voitures instantannément.

Site bloqué à 960pixels...

Toujours en tant qu'utilisateur, y'a une paire de sites (pourtant à gros budget, j'imagine pas le petit site vitrine) qui ont l'effet pervert d'être très, très mal pensé en version mobile (et là, je parle que niveau ergonomie) : obligé de le passer en mode "desktop"... donc oui, le site bloqué reste d'actualité.
Ca veut pas dire que je suis contre le responsive mais si c'est pas réfléchi/testé, faut pas faire pour faire.

PS: C'est là mon dernier message sur le sujet. Je pense avoir fait le tour de la question.

[youtpout978]

@youtpout978: c'est vrai, mais grunk a aussi raison. Tout ça se simplifie peu à peu. Imagine devoir faire la même chose il y a dix ans, en devant gérer du IE7

J'ai fait du web il y a 5ans sous IE6, pour résumer très peu de JS (du Vanilla JS) et des scriplets asp pour les ID pour le reste tout se passe côté serveur, à cette époque on avait pas la même intolérance avec les rafraichissements de page qu'aujourd'hui, sinon il existait déjà le magnifique UpdatePanel (sous Asp.net) pour que tout passe par de l'AJAX

Comment un développeur C# peut-il faire du Angular JS ? tu as eu une formation ?

Dans l'entreprise où j'étais avant ,un gars qui est arrivé peu de temps après moi à mis en place une architecture autour d'Angular JS sur le site de l'entreprise, dès que je les ai rejoints sur le projet je m'y suis mis (mais je suis pas encore un expert j'en apprend encore aujourd'hui et Angular v2 n'a plus rien à voire avec la v1), et dans l'entreprise juste avant j'ai appris à utiliser JQuery (je faisais du JS pur avant, mais très peu), en connaissant ces 2 Frameworks + Html/CSS tu peux développer des Single Page Application assez simplement sans avoir 20 000 lignes de code.

[flipp]

Encore un qui nous sert que HTML et CSS sont des langages…

[fodger]

Surtout ceux qui savent écrire sans faire de faute .