Meowcate (./40) :
Penser à l'accessibilité et à l'ergonomie

Concepts qui ne sont devenus nécessaires qu'avec les sites qui se concentrent sur la forme plutôt que le contenu. Une page HTML simple (avec du texte et du formatage de base comme les listes) est automatiquement accessible.

tout en sachant privilégier la construction visuel et la bonne répartition des éléments constituants la page,

Ce n'est pas mon problème où exactement s'affichent les éléments. Les tailles d'écran et les préférences de taille des polices des utilisateurs sont très différentes. Coder en dur des tailles et coordonnées en pixels dans des CSS ne fait que créer des problèmes.

aujourd'hui d'ajouter à savoir maîtriser le responsive design pour être indépendant du matériel du navigateur pour être consulté dans de bonnes conditions

Un site Web 1.0 à l'ancienne était automatiquement indépendant du matériel du navigateur, parce qu'il n'y avait pas de tailles absolues ni de coordonnées codées en dur! Tout était spécifié de manière relative ou laissé carrément au libre choix du navigateur. Du coup, ces sites s'adaptaient parfaitement à n'importe quelle taille d'écran sans que le webmaster n'eût à faire quoi que ce soit.

et d'avoir des technologies Javascript poussées (Angular, NodeJS, etc) si on veut concevoir une "application web", non pas un simple affichage de contenu mais un site qui accomplit une tâche particulière.

Si tu veux coder une application, le web n'est pas la bonne plateforme, il n'a pas du tout été prévu pour, et tous les frameworks qui font du web une plateforme d'applications sont des hacks énormes. (Il y en a même qui émulent une machine virtuelle en JavaScript!) Si je veux une application, je veux un logiciel libre que je peux télécharger comme paquetage pour ma distribution GNU/Linux, pas une application web qui cache du code propriétaire dans mon navigateur libre ou du côté serveur. S'il y a un service côté serveur, il devrait utiliser un protocole ouvert (jusqu'au niveau application tout en haut, c'est-à-dire qu'une surcouche propriétaire qui utilise le HTTP comme simple transport ne compte pas!) à travers lequel un client libre peut communiquer. Et préférablement, le serveur devrait être libre lui-même.

Quand on a conçu des sites il y a des années et qu'on ne les remet pas au goût du jour par flemme ou par désintérêt, je comprends qu'on puisse prétendre cracher sur le web 2.0.

Je ne m'en plains pas seulement du point de vue webmaster, mais aussi du point de vue utilisateur, et aussi du point de vue du développeur de navigateurs qui ne m'échappe pas entièrement en tant que packageur pour une distribution GNU/Linux. (Les moteurs HTML deviennent de plus en plus des usines à gaz énormes et difficilement packagables, tous les moteurs HTML simples marchent sur de moins en moins de sites, même KHTML est devenu limite inutilisable, et même son successeur QtWebKit est en train d'être remplacé par une usine à gaz encore plus grosse: QtWebEngine, qui embarque une copie de Chromium! QtWebKit a toujours été à la pointe, et il n'y a pas trop longtemps, KHTML aussi, il avait passé le test ACID2 avant Firefox! Mais la complexité du web ne cesse d'augmenter. Les sites modernes s'attendent aussi à un niveau de performance du JavaScript qui n'est possible qu'avec un compilateur JIT, et exécuter du code natif compilé à partir d'une source issue de n'importe quel site web est un énorme risque de sécurité: la moindre faille dans le générateur de code et voilà l'exécution de code arbitraire!)

Un peu comme un spécialiste C avec 20 ans d'expérience dans les pattes qui va s'accrocher à tout et n'importe quel argument pour justifier qu'il vaut mieux qu'il profite encore de C plutôt que passer à cette évolution inutile qu'est le C++.

Il y a toujours des cas où le C suffit largement. Personnellement, j'utilise le C++ pour utiliser Qt; entre du C++/STL et du C, je choisis le C.