Kevin Kofler (./42) :
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.

Mais c'est moche et limité

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.

Lesquels ?

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.

Mais c'est moche et limité

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.

Il y a plein de cas où le fait d'avoir une appli web apporte plein d'avantages (tellement évident qu'il serait inutile de les énumérer).

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

Oui, les choses sont compliquées pour le développeur de moteur HTML/JS. Bon, on s'en fout, c'est leur boulot. Pour le dév web qui veut faire du un site simple, c'est toujours possible (et bien plus facilement qu'avant avec Bootstrap).