Pourquoi un site statique n’aurait-il pas de javascript ? Par exemple ce cours sur les courbes de beziers est bourré de javascript, il reste néanmoins un site statique, dont les sources sont sur git.
Pas mal de monde a du mal à voir la réalité en niveau de gris, c'est du binaire tout ou rien. Il y a plein de choses possibles entre son 1 et son 2, incluant un serveur statique avec client dynamique (bref, HTML+JS), ou PHP+MySQL très léger.
Ça simplifie la vie, ça fait une vie de "combattant contre le mal", faut laisser faire (tant que ça ne nous impacte pas, et pour le moment cette idée de site tout statique est juste un petit délire dans un coin qui ressort à intervalle régulier dans un milieu assez restreint).
incluant un serveur statique avec client dynamique (bref, HTML+JS), ou PHP+MySQL très léger.
Ou utiliser un site ou service dynamique uniquement pour certaines parties ou faire un site publié statiquement mais qui est recalculé et republié suivant certains stimulus (réception d'un mail qui sert de commentaire par exemple) ou utiliser la persistance du navigateur pour créer une forme de dynamisme ou bien sûr utiliser quelques webservices (par exemple qui n'entravent pas l'utilisation du dit site s'ils ne fonctionnent pas ou ne sont jamais automatiquement appelés mais uniquement sur des boutons dédiés) ou avoir une extension de navigateur pour interagir avec le reste du système (il y avait un moteur de wiki personnel qui faisait ça),…
Ce n'est pas un niveau de gris, c'est un pantone de couleurs.
Je crois que pour certains, y compris moi, on limite le javascript car on a conscience de l'impact sur les performances. Après là-encore, niveaux de gris, on peut avoir du javascript sans aller jusqu'à l'excès et la lourdeur.
Faut quand même mettre beaucoup de jquery/underscore pour arriver à observer une différence de performance (ou faire des trucs très lourds ou s'être raté quelque part).
En fait la grande différence réside dans le fait de faire un site d'information plus ou moins dynamique (avec commentaires ou filtres de recherche par exemple), et une vraie application qui va devoir avoir beaucoup plus d’interactions utilisateurs.
Pour qu'un site d'information arrive à pousser le js à mort, c'est quand même étonnant, car c'est pas censé être le coeur de son activité, alors que pour l'application ça me parait plus plausible, car elle mettre des events un peu partout c'est un peu son fonctionnement normal.
Évidement là c'est la vision générale, on peux trouver des exemples de chaque côté qui vont l'exact opposé.
La question initiale c'est un site statique n'a pas de js. Il peut en avoir un peu ou être entièrement en js et tout un tas de niveaux entre.
Ce n'est pas le js qui est lent mais ce que l'on en fait. Si tu as un formulaire, valider les champs par chargement de la page complète peut être pénible pour l'utilisateur surtout quand il y a beaucoup de champs, valider chaque champ au fur et à mesure peut être plus confortable.
Il peut être mal utilisé bien sûr comme html (mais ça tout le monde s'en fout).
La question est pourquoi veut-on un site statique? Pour moi l'intérêt est côté serveur : baisser la charge serveur à trafic équivalent ou autrement dit augmenter le trafic à charge équivalent. C'est logique, un site statique ne demande aucun travail au serveur à part servir la page.
Évidemment, une fois ça fait, on peut alléger le poids des pages pour encore gagner mais côté serveur l'intérêt est relativement limité. Par contre côté client l'intérêt est bien de gagner encore en temps de chargement de la page (Pour le site, c'est une meilleure "expérience utilisateur")… et alors on a un intérêt à réduire le Javascript… mais le supprimer totalement c'est aussi réduire l'intérêt du site. On propose moins de chose avec du contenu purement statique.
Ce qui est plus intelligent que de supprimer le JavaScript, c'est de le limiter et surtout de limiter l'utilisation des librairies tierces qui ajoutent beaucoup de lourdeur pour de moins en moins d'intérêt.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Pour moi l'intérêt est « tu déploies et t'oublies ». Zéro maintenance ou presque. La montée en charge, c'est la problématique d'une infirme minorité de sites à fort trafic (et qui se résout, y compris avec des solutions dynamiques ou hybrides).
On propose moins de chose avec du contenu purement statique.
En dehors de celui qui ferait une oeuvre animée en javascript pas forcément. Ça c'est uniquement si tu fais le goret et que tu imposes une forme à ton contenu.
Et conditionner l'affichage du contenur par l'activation du javascript, c'est déjà faire un choix politique d'exclure des navigateurs, les personnes utilisant du matériel ancien, etc.
Et conditionner l'affichage du contenur par l'activation du javascript,
Je ne parle pas d'aller vers ça.
Mais si ton site est avec du Javascript, tu peux mettre de la cartographie, mettre un calcul ( site qui te calcul ton bidul en fonction du machin) tu peux même faire beaucoup plis comme mettre une base de données en local ou pas (bon c'est un peu plus complexe). Tu peux encore aller plus loin en Wasm: des jeux, des applications type suite Word…
La seul chose que tu ne peux pas faire c'est de l'enregistrement en ligne: poster un commentaire, formulaire, s'authentifier, shopping… mais même pour ça on pourrait se contenter de Web services léger.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Tu peux encore aller plus loin en Wasm: des jeux, des applications type suite Word…
C'est la que je fais la distinction, on n'est plus selon moi dans le site web, mais dans la webapp qui utilises https comme protocole de communication réseau.
Après libre à chacune de décider de faire ou non la distinction entre website et webapp mais pour moi elle est importante.
L'auteur oublie un critère qui est dans mon cas le plus important: la sécurité. Tant au niveau de la connaissance que de l'effort.
Au niveau de la connaissance: on sait tous les compromis que les entreprises pour lesquelles on travaille font régulièrement au niveau de la sécurité. On sait donc tous que n'importe quel hébergeur va être compromis un jour ou l'autre. Ce n'est pas une question de si mais plutôt de quand.
Quand on bosse dans l'informatique 8h par jours, parfois plus, on n'a pas envie de se trimballer des tâches de maintenance à répétition pour des trucs personnels. Du coup dès que c'est possible on limite la surface d'attaque et héberger un site statique ça la limite beaucoup.
Oui, un moment j'utilisais Wordpress pour faire la gestion du site, et le plugin Simply Static, qui exporte un rendu de toutes les pages du site dans un zip prêt à installer sur un serveur statique. Plutôt cool, car Wordpress, malgré sa lourdeur et ses nombreux trous de sécu, a un bon paquet de trucs pratiques intégrés, pléthore de thèmes et gadgets, et est connu des webmestres, qui par conséquent ne sont pas perdues devant un nouvel outil (Wordpress c'est quelque chose comme 40% des sites Internet).
J'ai cherché un tel greffon de rendu statique pour Spip, mais je n'ai pas trouvé.
L'auteur oublie un critère qui est dans mon cas le plus important: la sécurité. Tant au niveau de la connaissance que de l'effort.
Je ne bosse pas dans l'informatique et je ne suis tout sauf un geek, mais + 1.
À quoi j’ajouterai l'absence de prise de tête. Je veux dire, vraiment.
Du moins, passée la phase de prise en mains du site statique, qui dans mon cas fut une sacrée corvée (la doc n'est pas faite pour un cinquantenaire de mon genre, qui n'y connait rien ou presque), on découvre un truc réellement très simple… à deux niveaux :
Légèreté du site, ou pas selon les choix de chacun. Je voulais un site le moins taxant possible, qui marche partout.
Pas de contraintes d’outils, de mises à jour et d’interface utilisateur. Je ne veux plus m’emmerder à gérer la sécurité et les mises à jour d’un CMS et des modules dont il a besoin sur le serveur, et je veux avoir le choix des outils que j’utilise.
Ce qui m’a poussé à abandonner les CMS, c’est de ne plus comprendre les choix et les designs récent de WordPress.
Je n’ai aucun souci avec leurs changements, c’est leur outil ils en font ce qu’ils veulent, c’est dans l’ordre des choses. J’avais juste un souci avec le fait qu’ils ne me laissaient plus vraiment d’alternative et que je me retrouvais avec zero envie de me connecter à leur interface et d’écrire quoi que ce soit dedans. Dommage.
Ça, plus la course sans fin aux mises à jour et failles de sécurités… Découvrir les sites statiques m’a fait l’effet d’une libération.
J’écris où je veux, avec les outils qui me plaisent, je publie de temps en temps ™, quand l’envie m’en prends ou quand je me connecte. Et même la publication, passé le choc de changer de la GUI de WordPress à la ligne de commande, se révèle tellement plus simple et plus rapide ! Même un crét… pardon, je voulais dire un utilisateur technologiquement challengé de mon espèce est capable de l’utiliser (et de l’automatiser).
# Prémisse fausse
Posté par chimrod (site web personnel) . Évalué à 10 (+12/-2).
Pourquoi un site statique n’aurait-il pas de javascript ? Par exemple ce cours sur les courbes de beziers est bourré de javascript, il reste néanmoins un site statique, dont les sources sont sur git.
[^] # Re: Prémisse fausse
Posté par Zenitram (site web personnel) . Évalué à 2 (+3/-3).
Pas mal de monde a du mal à voir la réalité en niveau de gris, c'est du binaire tout ou rien. Il y a plein de choses possibles entre son 1 et son 2, incluant un serveur statique avec client dynamique (bref, HTML+JS), ou PHP+MySQL très léger.
Ça simplifie la vie, ça fait une vie de "combattant contre le mal", faut laisser faire (tant que ça ne nous impacte pas, et pour le moment cette idée de site tout statique est juste un petit délire dans un coin qui ressort à intervalle régulier dans un milieu assez restreint).
[^] # Re: Prémisse fausse
Posté par barmic 🦦 . Évalué à 5 (+3/-0).
Ou utiliser un site ou service dynamique uniquement pour certaines parties ou faire un site publié statiquement mais qui est recalculé et republié suivant certains stimulus (réception d'un mail qui sert de commentaire par exemple) ou utiliser la persistance du navigateur pour créer une forme de dynamisme ou bien sûr utiliser quelques webservices (par exemple qui n'entravent pas l'utilisation du dit site s'ils ne fonctionnent pas ou ne sont jamais automatiquement appelés mais uniquement sur des boutons dédiés) ou avoir une extension de navigateur pour interagir avec le reste du système (il y avait un moteur de wiki personnel qui faisait ça),…
Ce n'est pas un niveau de gris, c'est un pantone de couleurs.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Prémisse fausse
Posté par Psychofox (Mastodon) . Évalué à 5 (+2/-0).
Je crois que pour certains, y compris moi, on limite le javascript car on a conscience de l'impact sur les performances. Après là-encore, niveaux de gris, on peut avoir du javascript sans aller jusqu'à l'excès et la lourdeur.
[^] # Re: Prémisse fausse
Posté par barmic 🦦 . Évalué à 4 (+2/-0).
Faut quand même mettre beaucoup de jquery/underscore pour arriver à observer une différence de performance (ou faire des trucs très lourds ou s'être raté quelque part).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Prémisse fausse
Posté par Jean Gabes (site web personnel) . Évalué à 2 (+0/-0).
En fait la grande différence réside dans le fait de faire un site d'information plus ou moins dynamique (avec commentaires ou filtres de recherche par exemple), et une vraie application qui va devoir avoir beaucoup plus d’interactions utilisateurs.
Pour qu'un site d'information arrive à pousser le js à mort, c'est quand même étonnant, car c'est pas censé être le coeur de son activité, alors que pour l'application ça me parait plus plausible, car elle mettre des events un peu partout c'est un peu son fonctionnement normal.
Évidement là c'est la vision générale, on peux trouver des exemples de chaque côté qui vont l'exact opposé.
[^] # Re: Prémisse fausse
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
La question initiale c'est un site statique n'a pas de js. Il peut en avoir un peu ou être entièrement en js et tout un tas de niveaux entre.
Ce n'est pas le js qui est lent mais ce que l'on en fait. Si tu as un formulaire, valider les champs par chargement de la page complète peut être pénible pour l'utilisateur surtout quand il y a beaucoup de champs, valider chaque champ au fur et à mesure peut être plus confortable.
Il peut être mal utilisé bien sûr comme html (mais ça tout le monde s'en fout).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Prémisse fausse
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1 (+0/-0).
La question est pourquoi veut-on un site statique? Pour moi l'intérêt est côté serveur : baisser la charge serveur à trafic équivalent ou autrement dit augmenter le trafic à charge équivalent. C'est logique, un site statique ne demande aucun travail au serveur à part servir la page.
Évidemment, une fois ça fait, on peut alléger le poids des pages pour encore gagner mais côté serveur l'intérêt est relativement limité. Par contre côté client l'intérêt est bien de gagner encore en temps de chargement de la page (Pour le site, c'est une meilleure "expérience utilisateur")… et alors on a un intérêt à réduire le Javascript… mais le supprimer totalement c'est aussi réduire l'intérêt du site. On propose moins de chose avec du contenu purement statique.
Ce qui est plus intelligent que de supprimer le JavaScript, c'est de le limiter et surtout de limiter l'utilisation des librairies tierces qui ajoutent beaucoup de lourdeur pour de moins en moins d'intérêt.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Prémisse fausse
Posté par Pol' uX (site web personnel) . Évalué à 2 (+0/-0).
Pour moi l'intérêt est « tu déploies et t'oublies ». Zéro maintenance ou presque. La montée en charge, c'est la problématique d'une infirme minorité de sites à fort trafic (et qui se résout, y compris avec des solutions dynamiques ou hybrides).
Adhérer à l'April, ça vous tente ?
[^] # Re: Prémisse fausse
Posté par Psychofox (Mastodon) . Évalué à 3 (+0/-0).
En dehors de celui qui ferait une oeuvre animée en javascript pas forcément. Ça c'est uniquement si tu fais le goret et que tu imposes une forme à ton contenu.
Et conditionner l'affichage du contenur par l'activation du javascript, c'est déjà faire un choix politique d'exclure des navigateurs, les personnes utilisant du matériel ancien, etc.
[^] # Re: Prémisse fausse
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1 (+0/-0). Dernière modification le 12 octobre 2024 à 07:27.
Je ne parle pas d'aller vers ça.
Mais si ton site est avec du Javascript, tu peux mettre de la cartographie, mettre un calcul ( site qui te calcul ton bidul en fonction du machin) tu peux même faire beaucoup plis comme mettre une base de données en local ou pas (bon c'est un peu plus complexe). Tu peux encore aller plus loin en Wasm: des jeux, des applications type suite Word…
La seul chose que tu ne peux pas faire c'est de l'enregistrement en ligne: poster un commentaire, formulaire, s'authentifier, shopping… mais même pour ça on pourrait se contenter de Web services léger.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Prémisse fausse
Posté par Psychofox (Mastodon) . Évalué à 3 (+0/-0).
C'est la que je fais la distinction, on n'est plus selon moi dans le site web, mais dans la webapp qui utilises https comme protocole de communication réseau.
Après libre à chacune de décider de faire ou non la distinction entre website et webapp mais pour moi elle est importante.
# Critère oublié
Posté par Psychofox (Mastodon) . Évalué à 10 (+13/-0).
L'auteur oublie un critère qui est dans mon cas le plus important: la sécurité. Tant au niveau de la connaissance que de l'effort.
Au niveau de la connaissance: on sait tous les compromis que les entreprises pour lesquelles on travaille font régulièrement au niveau de la sécurité. On sait donc tous que n'importe quel hébergeur va être compromis un jour ou l'autre. Ce n'est pas une question de si mais plutôt de quand.
Quand on bosse dans l'informatique 8h par jours, parfois plus, on n'a pas envie de se trimballer des tâches de maintenance à répétition pour des trucs personnels. Du coup dès que c'est possible on limite la surface d'attaque et héberger un site statique ça la limite beaucoup.
[^] # Re: Critère oublié
Posté par cg . Évalué à 8 (+6/-0).
Oui, un moment j'utilisais Wordpress pour faire la gestion du site, et le plugin Simply Static, qui exporte un rendu de toutes les pages du site dans un zip prêt à installer sur un serveur statique. Plutôt cool, car Wordpress, malgré sa lourdeur et ses nombreux trous de sécu, a un bon paquet de trucs pratiques intégrés, pléthore de thèmes et gadgets, et est connu des webmestres, qui par conséquent ne sont pas perdues devant un nouvel outil (Wordpress c'est quelque chose comme 40% des sites Internet).
J'ai cherché un tel greffon de rendu statique pour Spip, mais je n'ai pas trouvé.
[^] # Re: Critère oublié
Posté par Xanatos . Évalué à 3 (+1/-0).
Oh merci pour la découverte !
[^] # Re: Critère oublié
Posté par Libb (site web personnel) . Évalué à 1 (+1/-0).
Je ne bosse pas dans l'informatique et je ne suis tout sauf un geek, mais + 1.
À quoi j’ajouterai l'absence de prise de tête. Je veux dire, vraiment.
Du moins, passée la phase de prise en mains du site statique, qui dans mon cas fut une sacrée corvée (la doc n'est pas faite pour un cinquantenaire de mon genre, qui n'y connait rien ou presque), on découvre un truc réellement très simple… à deux niveaux :
Ce qui m’a poussé à abandonner les CMS, c’est de ne plus comprendre les choix et les designs récent de WordPress.
Je n’ai aucun souci avec leurs changements, c’est leur outil ils en font ce qu’ils veulent, c’est dans l’ordre des choses. J’avais juste un souci avec le fait qu’ils ne me laissaient plus vraiment d’alternative et que je me retrouvais avec zero envie de me connecter à leur interface et d’écrire quoi que ce soit dedans. Dommage.
Ça, plus la course sans fin aux mises à jour et failles de sécurités… Découvrir les sites statiques m’a fait l’effet d’une libération.
J’écris où je veux, avec les outils qui me plaisent, je publie de temps en temps ™, quand l’envie m’en prends ou quand je me connecte. Et même la publication, passé le choc de changer de la GUI de WordPress à la ligne de commande, se révèle tellement plus simple et plus rapide ! Même un crét… pardon, je voulais dire un utilisateur technologiquement challengé de mon espèce est capable de l’utiliser (et de l’automatiser).
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.