D'un point de vue client, le chargement est bien plus rapide. Du static répondra toujours plus rapidement qu'un traitement côté serveur. Donc évidemment qu'en latence tu y gagne.
Je te défie de le prouver.
Car sur de la théorie c'est très loin d'être évident :
- gain temps de traitement distant, OK
- perte temps de transmission (plus de données)
- perte de temps de traitement local (plus petite machine client que serveur donc temps plus long, sans parler de faire tourner en JS plutôt que compilé natif)
- gain potentiel (aléatoire) sur 2ème requête si requête sur même bloc, certes, car plus de temps de transmission, mais même ça faut voir par rapport au temps JS
ne coute rien à héberger contrairement à un site PHP/MySQL [...] Mais du SQLLite, ça ne va pas chercher bien loin
Tiens, les technos changent... tu peux avoir du SQLLite sur le serveur aussi.
D'un point de vue coût, c'est génial.
Pareil, faut démontrer le gain par rapport au développement, un serveur ça coûte rien par rapport à du développement.
D'un point de vue écologique c'est mieux car le surplus de CPU consommé par le client est négligeable compte tenu que de toutes manière son CPU tourne et consomme.
Sérieux, la faut arrêter l'écologie d'affichage, si négligeable en local JS c'est tout autant négligeable voir encore plus en centralisé optimisé. 1000x négligeable peut être supérieur à 1000x sur le même serveur donc optimisé pour coûter peu. Démontre que faire tourner 1000x sur JS avec les octets en plus transmis serait plus écolo que centralisé, la comme ça en première vue théorique c'est le contraire.
Avant de sortir des "idées super économiques et écologiques" contre-intuitives, faudrait avoir plus de concret.
En attendant c'est juste un jeu, au mieux squatter sur le dos de l’hébergeur statique gratos, de la bande passante gratos, et du CPU utilisateur gratos, et du développeur gratos aussi sans doute pour que ce soit rentable.
[^] # Re: Quelle bonne idée
Posté par Zenitram (site web personnel) . En réponse au lien Héberger une base de données SQLite sur Github Pages (ou un autre hébergement statique). Évalué à 1.
Je te défie de le prouver.
Car sur de la théorie c'est très loin d'être évident :
- gain temps de traitement distant, OK
- perte temps de transmission (plus de données)
- perte de temps de traitement local (plus petite machine client que serveur donc temps plus long, sans parler de faire tourner en JS plutôt que compilé natif)
- gain potentiel (aléatoire) sur 2ème requête si requête sur même bloc, certes, car plus de temps de transmission, mais même ça faut voir par rapport au temps JS
Tiens, les technos changent... tu peux avoir du SQLLite sur le serveur aussi.
Pareil, faut démontrer le gain par rapport au développement, un serveur ça coûte rien par rapport à du développement.
Sérieux, la faut arrêter l'écologie d'affichage, si négligeable en local JS c'est tout autant négligeable voir encore plus en centralisé optimisé. 1000x négligeable peut être supérieur à 1000x sur le même serveur donc optimisé pour coûter peu. Démontre que faire tourner 1000x sur JS avec les octets en plus transmis serait plus écolo que centralisé, la comme ça en première vue théorique c'est le contraire.
Avant de sortir des "idées super économiques et écologiques" contre-intuitives, faudrait avoir plus de concret.
En attendant c'est juste un jeu, au mieux squatter sur le dos de l’hébergeur statique gratos, de la bande passante gratos, et du CPU utilisateur gratos, et du développeur gratos aussi sans doute pour que ce soit rentable.