• [^] # Re: La présentation oublie des infos essentielles

    Posté par . En réponse à la dépêche « Fourmilieres », un générateur de formulaires qui permet de reprendre la main sur vos données. Évalué à 3.

    Javascript est devenu un prérequis en 2016 (un peu avant ça, mais bon). Un navigateur n’est pas un bête moteur de rendu html, mais plutôt une machine virtuelle pour applications js.

    C'est toi qui le dit. Parce que ça arrange ceux qui veulent contrôler l'interface utilisateur plutôt que ça soit l'utilisateur qui puisse dicter ses besoins. Ça colle bien au fait que ça rende les choses moins accessibles : c'est l'idéologie même de ce mouvement de casser le pouvoir de l'utilisateur.

    Si ça ne te plaît pas, soit, mais dans ce cas, tu te coupes de beaucoup de sites.

    Et, qu'en conclues-tu ? Ne trouves-tu pas ça dommage que des gens se coupent de sites à cause de leur conception qui va à l'encontre des principes de base du Web, comme bien dégrader ? Je suis sûr que même Berners-Lee n'accroche pas vraiment à cette tendance.

    Sachant que l’argument de la sécurité n’en est plus vraiment un : les navigateurs ont énormément progressé de ce point de vue. Je regrette cela dit qu’il n’y ait toujours pas de norme pour la signature de code.

    J'avoue que je ne comprends pas trop les arguments de sécurité, mais bon.

    • le dev coûte moins cher (joue un peu avec un framework comme angularjs, c’est impressionnant ce qu’on arrive à faire rapidement)

    Moins cher que quoi ? Que bien faire les choses ? Ah oui, ça, forcément, c'est comme ça partout, bâcler le travail et faire de la merde et s'en foutant des conséquences que ça a pour les autres, ça a toujours été (et ça l'est toujours) une technique en vogue et qui ne coûte pas cher. C'est censé être un argument pour toi ?

    • la charge serveur / la bp est réduite (oui, recharger une page html et faire tous les calculs – je ne parle pas de la validation de données, qui est indispensable, mais de calculs liés à la présentation – côté serveur, ça coûte, alors qu’on peut en faire plein côté client). C’est particulièrement critique quand tu embraques un serveur http dans un périphérique embarqué disposant d’une petite cpu.

    Ça, d'accord. Mais on a déjà essayé de normaliser des solutions pour le templating côté client : c'est XSLT. Mais tout le monde l'a oublié. Pour le reste, très bien, ne fait pas de mise en forme côté serveur, ça me va très bien : je m'en fous que ça soit moche, bien sûr que je fais des compromis quand je n'ai pas de JS.

    • la séparation métier / présentation est généralement de fait améliorée (car usage de technos différentes pour les deux, moins de risques de mélanger les choses)

    Houa, alors ça pas du tout par contre : aujourd'hui, côté client, on mélange aussi les choses comme on le faisait avant côté serveur. Les applications bien délimitée, ça n'est pas juste en disant que « je fais du JS » que ça va arriver magiquement. C'est comme tout, ça demandera un bon dev.

    Mais ça c’est un problème de dev qui n’a pas fait son boulot correctement, pas un problème de techno (sachant que les framework js apportent des solutions simples à mettre en œuvre).

    On est donc d'accord : ça n'est pas parce que c'est du JS que c'est magiquement « mieux ». Alors pourquoi, si on ne fait pas mieux, casser tout l'existant, l'accessibilité, voire les fonctions de base ?! Une des raisons pour lesquelles l'HTML est « rigide » niveau interaction (et la raison pour laquelle tant de gens sont tentés de mettre plein de JS), c'est aussi parce que ça évite de faire n'importe quoi à ceux qui n'y connaissent rien et font du dev à deux francs.