Safari va finalement adopter les Service Workers
Les développeurs web du monde entier sont en liesse depuis hier. Apple a officiellement commencé le travail pour prendre en charge les Service Workers dans Webkit, et donc dans Safari.
Les Service Workers permettent aux sites web d’exécuter du code en JavaScript même s’ils ne sont pas au premier plan, voire si aucune page n’est actuellement ouverte dans le navigateur. Cette fonction est l’équivalent des mises à jour à l’arrière-plan des apps natives, mais appliqué au web. L’exécution est interrompue quand une tâche est terminée, mais elle peut ensuite se relancer si c’est nécessaire.
Cette fonction peut servir à mettre à jour régulièrement les données d’un site et ainsi afficher directement les données à jour quand l’utilisateur l’affiche. Les Service Workers peuvent aussi servir pendant le développement, par exemple pour compiler des ressources et convertir des fichiers. Ou bien aussi améliorer les performances en chargeant à l’avance non seulement des ressources statiques, mais aussi des pages complètes.
En bref, les Service Workers rapprochent le web des apps natives. Jusque-là, Apple ne semblait pas intéressée par cette fonction, ce qui lui a valu bien des critiques ces dernières années de la part de la communauté des développeurs web (lire : Safari est-il le nouvel Internet Explorer ?). Son arrivée est une bonne nouvelle pour les webapps les plus complexes, même si le navigateur de macOS et iOS reste toujours à la traîne dans le domaine.
Dernier exemple en date, les Progressive Web Apps poussées par Google ne sont pas encore prises en charge. Par rapport aux webapps traditionnelles, elles permettent notamment de stocker l’interface d’un site et des données en local. Les PWA peuvent ainsi fonctionner même sans connexion à internet, comme une vraie app native… en tout cas sur Android, plate-forme logiquement la plus avancée sur ce point.
Apple privilégie comme toujours l’App Store, mais cela ne veut pas dire que Safari est à l’abandon. Bien au contraire, son navigateur évolue régulièrement et encore cette année, mais le constructeur privilégie souvent les fonctions dédiées aux utilisateurs, plutôt que celles qui arrangent les développeurs.
Permettre d'exécuter du code Javascript en arrière plan voire même sans qu'aucune page ne soit affichée, c'est potentiellement un risque de voir s'exécuter du code malveillant, non?
@r e m y
Pas plus ni moins qu’en premier plan.
Ca permet surtout *enfin* de faire du multithreading client et d’exploiter tous ces petits cores que même le plus médiocre téléphone propose en quantité.
Ce sont les web workers ça, déjà supportés dans Safari.
@byte_order
Aie oui c’est juste. Confondu. Oops. Trop chaud.
@byte_order
+1
Moais, ça n'a pas grand chose a voir meme si le terme est proche, faut effectivement connaître le sujet pour ne pas raconter n'importe quoi basé sur la proximité lexicale...
Pour la question de @remy: oui il y a un risque plus important, l'utilisateur ne pouvant pas savoir qu'un script tourne malgré qu'il n'y ait pas de page chargée... Mais on est pas dans un risque viral non plus, le protocole est tres encadré. En fait cette API permet d'utiliser le cache comme ressource, donc une fois que les ressources sont en cache, il n'y a pas besoin d'acces reseaux, pas d'utilisation de l'interface du navigateur.
La ou c'est plus embettant et on comprend l'attentisme d'Apple sur le sujet, c'est sur la consommation électrique supplémentaire.
La philosophie d'iOS a toujours ete de n'avoir qu'une application active, celle du premier plan, avec des services qui pouvaient etre activés au besoin, et bien évidemment cette restriction ne touchant que les app pas l'OS.
Ici, la question se pose de savoir si Apple va autoriser le navigateur a executer des taches de fonds consommatrice (sans accces WEB) alors que le navigateur n'est pas au premier plan. De plus il y a la question de la taiile du cache et de sa persistance...
Pour les dev, il va falloir etre tres prudent avec l'utilisation de cette fonction histoire de ne pas se voir reprocher de vider la batterie a grande vitesse ou de lourdeur (et quand on voit les critiques contre Chrome en terme d'efficacité energetique....)
Question de novice en la matière : est-ce que cela signifie que la dernière version de Google Earth (g.co/earth) sera finalement compatible avec Safari ?
Cela n'a à priori rien à voir du tout.
> mais le constructeur privilégie souvent les fonctions dédiées aux utilisateurs,
> plutôt que celles qui arrangent les développeurs.
Il privilégie souvent les solutions qui arrangent d'abord ses affaires.
Permettre à des webapps de fonctionner de plus en plus comme des apps natives, cela ne fait pas ses affaires car cela signifie moins d'apps natives dans son store, et moins d'utilisateurs captifs de sa plateforme.
@byte_order
"Il privilégie souvent les solutions qui arrangent d'abord ses affaires."
Ça arrange les miennes aussi. Quand on voit que SimpleNote est passé de 3Mo à plus de 100 juste parce que les développeurs ont adopté une solution web pour faciliter le développement de l'app...
Désolé de préférer une application native bien codée. Le multiplateforme c'est le cadet de mes soucis en tant qu'utilisateur, en particulier si c'est au détriment des performances et donc de mon expérience et de l'autonomie de ma machine.
@LeGrosJeanLou
Le multiplateforme est l'ennemis de la qualité.
Y a qu'à voir depuis l'émergence d'android comment les apps iPhone et iPad ont régressé par rapport à ce que c'était au début... On a le droit à la même interface quelque soit la taille de l'écran, les graphismes ont régressé et la consommation est montée en flèche!
@fousfous
Je n'utilise pratiquement que des apps exclusives iOS/macOS pour cette raison ^_^
@fousfous
Voir une corrélation avec l'emergence d'Android est, comment dire,... temeraire?
Il y a plusieurs phenomenes qui ont conduit a cette degradation:
- augmentation du nombre de "codeurs" qui ne sont pas correctement formés au developpement
- augmentation de la vitesse de production des applications avec un tarif tres bas
- apparitions de generateurs d'applications (pas forcement multiplateformes)
- arrivée d'iOS 7 (moins de coherence dans l'interface)
- arrivée de Swift ( plus abordable qu'Objective-C, donc plus de bricoleurs amateurs qui produisent des calculatrice, horloges et coussin-peteurs)
Apres, il y a aussi un indeniable impact, assez recent, avec Android, meme si en general il semble que l'application soit developpée d'abord sur iOS (rentabilité, fragmentation, coherence) puis soit portée sur Android.
@ byte_order : « Il privilégie souvent les solutions qui arrangent d'abord ses affaires.
Permettre à des webapps de fonctionner de plus en plus comme des apps natives, cela ne fait pas ses affaires »
Certes.
Mais les deux ne sont pas exclusifs : les webapps qui remplacent les applications natives, ça ne fait pas non plus l'affaire des utilisateurs la plupart du temps, puisqu'on y perd la possibilité d'avoir des applications vraiment adaptées à la plateforme qu'on utilise.
La réalité, c'est que devoir faire une version native pour iOS, une version native pour Android, et évidement une version Web pour tout le reste, le tout pour bien souvent des fonctionnalités qui reposent en pratique sur des services web, cela représente un surcoût.
Surcout que les utilisateurs sont de moins en moins enclins à payé.
Surcout qui pour beaucoup d'apps ne se justifient pas forcément, beaucoup des apps qui reposent principalement sur des services web où la plus value est installée, n'ayant pas vraiment besoin d'accéder à des fonctionnalités natives spécifiques.
L'utilisateur y perd peut-être des applications "vraiment adaptées à la plateforme", mais il gagne la disponibilité du service, même s'il est moins bien adaptée.
Quand le coût du développement natif n'est pas rentable, c'est ça ou pas d'application du tout disponible.
Par ailleurs, tout le temps que vous passez à surfer via Safari, c'est typiquement ça : les pages web par définition ne sont pas adaptées et ne profitent pas spécifiquement aux capacités de la plateforme.
Cela n'empêche visiblement pas grand monde de passer beaucoup de temps à surfer sur des pages web, ou à faire du Facebook, autre application très loin d'être "native" mais pourtant dont beaucoup ne pourrait pas se passer.
La forme l'emporte rarement sur le fond en matière de fonctionnalité.
Libre à vous de snober, mais l'offre et la demande en matière d'application native est régulée par l'argent, pas l'exigence de l'utilisateur.
Ca coute cher le développement natif. Les revenus des apps natives sont en chute libre pour les développeurs.
Cela a des conséquences.
@byte_order
Moais, je suis pas si certain du surcout.
Tout va dependre en fait du service et des fonctions.
deux cas se posent:
- on a coté client une interface de consultation
- on a coté client un traitement massif avec un service WEB type cloud
Dans le premier cas, l'application native c'est majoritairement du design d'interface, avec tres peu de traitement specifiques, et parfois le cout de développement de la meme interface en JS peut coûter un peu plus. Ce qui coute le plus c'est le développement du coté serveur.
Dans le second cas, on est face a une application complete qui va utiliser le serveur pour du backup, de la synchro, de l'echange, voire dans les cas les plus avancés du calcul deporté.
Dans ce cas, le développement JS est enorme et tres cher, puisque il faut employer le WEB pour ce qu'il n'est pas fait.
L'application native demande aussi pas mal de boulot, mais moins et c'est plus efficace et coherent (et esthetique).
Dans ce cas on va avoir un cout important pour les 5 plateformes: WEB, iOS, Android, MacOS, Windows. Soit l'editeur a les finances pour assurer le developpement et le suivi sur chaque plateformes, soit il doit se concentrer sur certaines, soit n'a que l'argent pour l'une et la c'est le WEB qui va souvent etre choisi.
On comprend que pour des raisons de couts, l'editeur va alors focaliser ses ressources sur la production d'une version WEB, qui fonctionnera, approbativement, sur toutes les plateforme, et lorsque l'utilisateur gueulera contre la consommation, les bug, les performances,... l'editeur dira que c'est la faute a Chrome qui consomme trop, a Safari qui prend pas en compte la fonction JS idoine, a Firefox qui...
Apres se pose la question du modèle économique.
Faire une application native, c'est facile a faire payer. C'est moins facile a faire avaler par abonnement
Faire une web app, c'est quasi impossible a faire payer. Donc on fait payer le service WEB et logiquement on le fait pas abonnement (ou achat a l'utilisation...). Et l'abonnement contenant deja la principe de captivité et d'obsolescence programmée, l'editeur a tout interet a aller sur la WEB app.
@ byte_order : « Surcout qui pour beaucoup d'apps ne se justifient pas forcément, beaucoup des apps qui reposent principalement sur des services web où la plus value est installée, n'ayant pas vraiment besoin d'accéder à des fonctionnalités natives spécifiques. »
Pour ma part, je parlais bien de ces webapps qui tentent de remplacer les applications natives pour les tâches qui leur sont normalement dévolues. Ce sont celles-là (celles qui, justement, auront besoin de trucs tels que les service workers) qui sont nuisibles.
Dans de nombreux autres cas, en effet, ce qu'on nomme « webapp » est juste une page web au contenu plus ou moins dynamique, et là il y a un net intérêt à ce que ce soit accessible par le web plutôt que par une application native dédiée qui n'apportera pas grand chose. On est bien d'accord sur ce point.
Mais quand on voit, par exemple, la vaste blague que sont les logiciels de bureautique version web, je suis désolé mais je leur préfère nettement des logiciels pour Mac.
« L'utilisateur y perd peut-être des applications "vraiment adaptées à la plateforme", mais il gagne la disponibilité du service, même s'il est moins bien adaptée.
Quand le coût du développement natif n'est pas rentable, c'est ça ou pas d'application du tout disponible. »
Quand il n'est pas rentable, c'est bien le mot important. Le danger de trop faciliter la création de webapps, c'est de pousser certains développeurs à ne même pas s'interroger sérieusement sur cette rentabilité.
« Par ailleurs, tout le temps que vous passez à surfer via Safari, c'est typiquement ça : les pages web par définition ne sont pas adaptées et ne profitent pas spécifiquement aux capacités de la plateforme. »
Ça n'a strictement rien à voir : on parlait jusque là de webapps, c'est-à-dire des pages web au contenu très dynamique et interactif, qui tentent d'imiter le fonctionnement d'applications. On ne parlait pas de la masse énorme des pages web au contenu statique (ou quasi-statique) qui ne sont que des documents à consulter et ne tentent pas de se présenter comme des applications servant à créer quoi que ce soit.
« La forme l'emporte rarement sur le fond en matière de fonctionnalité. »
Il ne s'agit pas ici de forme. L'adaptation à la plateforme permet aussi de profiter de fonctionnalités de fond qu'on ne retrouvera pas dans une webapp.
« Libre à vous de snober, mais l'offre et la demande en matière d'application native est régulée par l'argent, pas l'exigence de l'utilisateur. »
Argent qui sert parfois à exprimer l'exigence de l'utilisateur. On le sait bien sur notre plateforme (le Mac — je le précise parce qu'il semble parfois que ce n'est pas clair, tellement on voit dans ce fil de commentaires parler de plateformes mobiles ou autres encore).
« Ca coute cher le développement natif. Les revenus des apps natives sont en chute libre pour les développeurs. Cela a des conséquences. »
En effet. Ce qui n'interdit pas de déplorer ces conséquences et de faire remarquer que tout ça ne va pas forcément dans le sens d'un bénéfice pour l'utilisateur.
@BeePotato :
« Mais quand on voit, par exemple, la vaste blague que sont les logiciels de bureautique version web, je suis désolé mais je leur préfère nettement des logiciels pour Mac. »
Vous n'avez probablement jamais utilisé les Google Apps, qui permettent de travailler à plusieurs en même temps sur un document, pour dire ça.
C'est tout sauf une "vaste blague".
Cordialement,
HAL1
@ webHAL1 : « Vous n'avez probablement jamais utilisé les Google Apps, qui permettent de travailler à plusieurs en même temps sur un document, pour dire ça.
C'est tout sauf une "vaste blague". »
Si, si, je les ai testées. Et je les inclus bien dans la vaste blague.
Leur seul intérêt est cette fonction d'édition à plusieurs. Quand on en a besoin, elle peut effectivement justifier de passer outre les défauts de ces webapps.
Mais on n'en a pas toujours besoin, loin de là.
@BeePotato
Ah. Je vois. J'imagine que pour vous, Safari est, par exemple, une "vaste blague", mis à part quand il s'agit de naviguer sur le Web. ^_^
@ webHAL1 : « Ah. Je vois. »
Je n'en ai pourtant pas l'impression.
« J'imagine que pour vous, Safari est, par exemple, une "vaste blague", mis à part quand il s'agit de naviguer sur le Web. »
?!?
Ben non. C'est un navigateur qui, de mon point de vue, fait très correctement son boulot.
Et, étant une vraie application pour Mac, il exploite autant que possible les fonctionnalités de cet OS.
Mais le cas de Safari n'a strictement aucun rapport avec ce dont on parlait jusque là.
La distinction faite entre Service Workers et Progressive Web Apps dans ce billet n'est pas bonne.
Les Progressive Web Apps sont une appellation marketing d'un ensemble de technologies arrivées sur le Web ces dernières années, et encore en cours d'élaboration et d'implémentation dans les différents navigateurs.
Les Service Workers sont une de ces technologies, indispensable pour gérer plusieurs fonctionnalités jusqu'à présent réservées aux applications natives : gestion de l'offline, mise à jour en arrière plan, notifications.
Donc on ne peut pas se réjouir du développement des Services Workers dans webkit/Safari, et dire que les Progressive Web Apps ne « seront probablement pas [supportées] de sitôt »… ;-)
J'ai justement écrit un billet sur le sujet il y a deux jours : Introduction aux Progressive Web Apps
@fte non, il ne faut pas confondre les Service Workers et les Web Workers.
Les premiers sont une sorte de proxy qui permet d'intercepter toutes les requêtes en JavaScript et en faire ce que l'on veut, dont les stocker ou lire dans un cache particulier du navigateur.
Les seconds, plus anciens, permettent par contre effectivement de gérer plusieurs threads en arrière plan. Voir la doc de MDN.
« le constructeur privilégie souvent les fonctions dédiées aux utilisateurs, plutôt que celles qui arrangent les développeurs »
Je ne comprends pas très bien cette phrase. Les fonctions d’un moteur de rendu Web ne sont-elles pas systématiquement au service du développeur, pour à terme faciliter la vie de l’utilisateur ? Le développeur et l’utilisateur n’ont-ils pas un intérêt convergent ? (À part les EME j’entends, mais ça c’est autre chose…)
@SimR69
" Le développeur et l’utilisateur n’ont-ils pas un intérêt convergent ? "
Non.
Le développeur veut diminuer les coûts de développement de ses logiciels. Une manière de faire c'est d'utiliser des solutions multiplateformes (comme les webapps) qui s'exécuteront aussi bien sur n'importe quel OS. La conséquence c'est un code beaucoup moins optimisé et beaucoup plus lourd.
Et dans ce cas c'est l'utilisateur qui paye les économies du développeur.
Ouais mais pour un truc qui avantage l’utilisateur à coût constant, on peut dire qu’il avantage aussi le développeur.
Pages