Service Workers replacing AppCache: a sledgehammer to crack a nut
▻https://medium.com/@firt/service-workers-replacing-appcache-a-sledgehammer-to-crack-a-nut-5db6f473cc9
“Can we replace Application Cache with Service Workers? Yes we can. In the same way we can replace your old CRT TV with a Microsoft Hololens.”
@robin je ne trouve pas du tout, non…
Ben outre quelques erreurs factuelles, je ne comprends pas très bien quel est son problème avec les librairies. C’est le principe même d’une plateforme puissante que de permettre le développement de librairies pratiques et puissantes. Si au bout d’un moment une d’elle est utilisée partout, elle peut devenir partie intégrante de la plateforme. C’est l’idée depuis le début, comme le montre ►https://gist.github.com/darobin/4739167 qui date du deuxième meeting Service Workers (l’API a changé depuis, mais les idées de base sont là).
@robin AppCache avait des problèmes pénibles, mais pas insurmontables, et était ultra simple à mettre en œuvre, sans code. Devoir utiliser des libs et builders et autres pour se « simplifier » la vie avec les SW, c’est quand même dommage. C’est un gros frein à l’adoption, tout comme HTTPS, même si ce dernier est plus justifié.
@fil on peut difficilement tout mettre en cache, là, effectivement. Il faut utiliser le cache pour la perf gagnée lors des visites suivantes, donc sur les premiers éléments affichés.
@robin très concrètement, pour mon cas perso, c’est la goutte qui fait déborder le vase.
Je suis convaincu que AppCache n’est pas une solution d’avenir, mais imposer la migration vers les SW en le supprimant purement et simplement n’est pas un bon signal dans l’histoire plutôt forward compatible du Web.
Entre la complexité de HTTPS, la complexité des SW, la disparition annoncée de AppCache, et la disparition annoncée de SMIL, je commence à envisager d’abandonner mon projet esviji, tout simplement.
@nhoizey Je comprends bien que c’est frustrant, mais j’éviterais de mélanger le changement pour AppCache et celui pour SMIL.
Si AppCache devait subsister, il faudrait que ce soit uniquement en HTTPS aussi — les attaques MITM sont trop dangereuses de toute façon. HTTPS a longtemps été horrible à utiliser, mais avec letsencrypt c’est en train de devenir facile (progressivement). Je pense que bientôt on n’y pensera plus.
Pour ce qui est des builders, avec AppCache il fallait de toute façon un build step pour modifier au minimum un commentaire dedans lors d’une mise à jour. Et franchement quand je l’enseignais je crois qu’aucun élève ne l’a pas trouvé problématique d’une façon ou d’une autre (bon après je suis peut-être mauvais prof :).
Je sais bien que changer c’est du boulot pour les gens qui l’utilisent déjà, mais justement AppCache est très peu utilisé (notamment parce que ça pose trop de problèmes). Il y a un point philosophico-pragmatique qui est très important pour ce qui concerne le coté forward compatible du Web : pour que la plateforme reste viable au long terme il est important d’élaguer quand c’est possible. Si on n’a affaire uniquement à de l’accumulation, sur suffisamment de temps ça devient vraiment le bordel. Par exemple l’élimination des applets est clairement une bonne chose.
Pour ce qui est de SMIL la question est peut-être plus épineuse. Personnellement je trouve que c’est une technologie un peu ratée (et mal implémentée en plus), notamment parce qu’elle marche de façon mal définie avec le DOM (en insertion principalement, mais aussi les anim/baseVal), et après en avoir essuyé les plâtres pour faire des UIs animées en SVG ça fait 10-15 ans que je conseille généralement de ne pas l’utiliser. Mais je sais que tu n’es pas d’accord, ainsi que d’autres, et qu’il n’y a pas de solution de substitution déclarative proposée, ce qui est gênant. Je pense qu’il est trop tôt pour s’en débarrasser.
De mon coté j’ai le même type de problème avec MathML. C’est une techno relativement mal conçue et très mal supportée, mais pour le moment c’est tout ce qu’on a. On parle de l’éliminer mais pour le moment sans remplacement viable. Je ne vois pas très bien comment publier de la science accessible sans ça…
Bref, je ne dis pas que c’est un monde parfait, loin s’en faut, mais je pense que la décision sur AppCache est in fine la bonne.
@fil Si tu as besoin de tout mettre en cache ce n’est pas forcément possible quelle que soit la techno, ceci dit avec SW tu peux au moins contrôler ce qui est en cache et ce qui ne l’est pas (et réagir en conséquent) et l’interaction (à venir) avec un système de quota permettant à un site de stocker plus avec l’accord de l’utilisateur est plus simple à mettre en place.
@robin ne t’inquiète pas, je ne mélange pas les cas AppCache et SMIL, je sais que les deux logiques sont différentes. J’ai juste la malchance d’être au mauvais moment au mauvais endroit. Passer des nuits à développer un jeu en SMIL, qui fonctionne en offline (demandé notamment par 50% de mes joueurs, qui sont aux Philippines), et voir tout ça disparaître, ça fait mal.
Et bien sûr, j’ai oublié de dire que Mozilla vire petit à petit sa Marketplace, qui représente 95% de mes joueurs… mais ce n’est plus une question de standard.
Pour répondre plus précisément à tes explications :
Je suis d’accord que HTTPS est mieux que HTTP, et que ce serait plus pertinent pour AppCache. Soit. Je n’aurais peut-être pas encore touché à AppCache si ça avait toujours été le cas.
Je suis d’accord aussi que la mise en œuvre de HTTPS va s’améliorer grâce à Let’s Encrypt, mais j’attends encore que mon hébergeur s’y mette. Je me suis mis à CloudFlare pour avoir le HTTPS, mais ça me pose des problèmes sur le cache, un impact de perf global bien pénible.
Sinon, tu dis toi-même que tes étudiants n’étaient pas gênés par AppCache, je ne sais pas du coup si tu argumentes pour ou contre… ;-)
Quoi qu’il en soit, pour revenir au sujet initial de ce seen, le fossé entre AppCache et les Service Workers est AMHA bien trop grand pour la plupart des développeurs, ça va nécessairement ralentir l’adoption, et ce n’est pas en menaçant de virer AppCache complètement qu’on va faire des heureux, quelles que soient les qualités intrinsèques des SW.
Pour SMIL, je veux bien comprendre que ce n’est pas parfait, notamment au niveau des implémentations (j’ai ouvert des bugs dans Firefox, Safari, Opera et Chrome avant Blink, il a fallu écrire un polyfill, oublier le support dans IE, etc.), mais mon jeu est la preuve qu’on peut en faire quelque chose de plutôt complet assez simplement, je n’avais pas franchement d’autres solutions à ce niveau quand j’ai commencé le dev il y a 5 ans, pour faire une interface fluide adaptée à tous les navigateurs (ou presque), et sur toutes les tailles d’écrans.
Tout le monde se met aujourd’hui à GSAP pour faire ce genre de chose, et ça me fait rager, c’est une solution propriétaire.
@nhoizey Bon, les doubles négations ne sont pas ce qu’il y a de plus lisible, mais j’ai bien écrit « aucun élève ne l’a pas trouvé problématique » :) Ou plus clairement : « tous les élèves l’ont trouvé problématique ».
La Marketplace n’est pas un problème de standard mais c’est un réel problème d’écosystème. Il n’y a pas de façon simple de trouver des applis Web. Quelques startups s’y sont collées, mais pour l’instant rien ne semble prendre de l’ampleur. Peut-être CozyCloud ? Avec SW, manifest, etc. il commence à y avoir une vraie plateforme mais la découverte est encore le parent pauvre de l’affaire.
Pour ce qui est de l’adoption de SW je pense qu’à ce stade les signes sont prometteurs — mais évidemment il n’y a pas de preuve, l’histoire nous le dira ! Ce qui m’inquiète sur le offline-first ce n’est pas SW mais tout ce qui va avec, qui a l’air simple au premier abord et qui se révèle complexe à la pratique : je vois venir des déconvenues. Certains systèmes simples au niveau de l’offline (lecture seule, ou écriture additive) vont rester simple, mais dans une appli avec des données partagées (qui impactent d’autres utilisateurs) on arrive vite à avoir besoin d’une cohérence de données et donc à la possibilité de conflits. Ici on utilise PouchDB (et c’est génial pour beaucoup de raisons) mais on se retrouve à devoir faire des pirouettes très spécifiques à notre modèle pour pouvoir gérer la cohérence des données sans que l’impact de performance ne rende le système inutilisable.
Si on se pose deux minutes pour y songer, on voit qu’avec l’offline on arrive vite à un système qui est effectivement équivalent à une DB distribuée. Et donc : le CAP theorem s’applique. Et ça, si tout le monde commence à devoir s’y coller ça va être une autre paire de manches.
Quand je regarde React Motion, je me demande à quel point il serait difficile de créer un nouveau shim pour SMIL (ou SMIL-like) aujourd’hui ?
Ok pour tes élèves… ;-)
Pour la marketplace, ou plus largement la découverte, nous sommes complètement en phase. Ce problème de découverte dans un écosystème ouvert et distribué n’est clairement pas nouveau.
Pour les problématiques de données à synchroniser dans les deux sens (et plus) dès qu’on fait de l’offline un peu poussé, rien de nouveau non plus, on gérait des troupes de VRP avec ordis ou PDA non connectés il y a déjà pas mal d’années… ;-)
Enfin, côté SMIL, un shim ne m’intéresse pas. Si la techno va disparaître, autant se tourner vers le futur. Les shims de futures technos, oui, mais pas d’acharnement thérapeutique…