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.
@SimR69
L'utilisateur et le développeur ont évidemment des intérêts communs. En tant qu'utilisateur tu payes le développeur pour qu'il te fournisse un logiciel/service. Donc chacun y gagne (heureusement d'ailleurs sinon pourquoi payer ?)
Mais il y a aussi des intérêts divergents. Les économies réalisées sur le développement n'est pas dans l'intérêt de l'utilisateur comme j'ai pu l'expliquer.
Et c'est pas forcément facile de trouver un équilibre entre coûts, pérennité et performances.
Les performances des plateformes mobiles ne cessant de croitre, contrairement aux recettes des ventes d'applications natives, c'est tout trouvé je le crains.
@byte_order
Il faut aussi savoir donner le bon prix et le justifier avec des performances et services irréprochables. J'utilise OmniFocus et Ulysses par exemple, sur iOS comme sur Mac et bien que relativement simples ces apps coûtent assez cher. Et ça me va très bien parce que je sais que j'y trouve mon compte. J'utilise aussi Affinity Photos et Affinity Designer qui sont presque données pour leur qualité. Ensuite j'utilise les apps stock d'Apple parce que là encore je suis certain d'avoir du logiciel hyper optimisé (n'utilisant pas les services Google je n'ai jamais rencontré de difficultés avec leurs apps)
Je pense que ce qui est compliqué pour un développeur aujourd'hui c'est de justifier un prix. Quand on est habitué à payer 1€ voire 0€ en supportant des publicités ça parait difficile de mettre 5€ pour avoir le même service. Mais j'ai choisi d'encourager ces développeurs parce qu'ils m'offrent une vraie plus-value. C'est une question de culture et de prise de risque. Et je ne suis pas certain que chercher à occuper tous les terrains soit une bonne manière d'aborder le problème de la rentabilité d'une app. Android est un assez bon exemple de la difficulté à rentabiliser un développement avec un taux de rémunération par utilisateur très faible par rapport à iOS. Mais ça dépend évidemment du produit qu'on cherche à vendre. Si on regarde le cas de Day One il est parfaitement représentatif d'une conversion multiplateforme ratée (en tout cas du point de vue de l'utilisateur).
En tout cas s'il y a des gens trop radins qui vont privilégier les apps gratuites multiplateformes et mal codées il y en a aussi comme moi pour privilégier les apps plus chères et monoplateformes.
> En tout cas s'il y a des gens trop radins qui vont privilégier les apps gratuites
> multiplateformes et mal codées
La qualité du codage n'est pas lié au fait qu'il soit portable ou pas.
Une application payante, monoplateforme peut parfaitement être mal codée tout autant (et les exemples sont légions d'ailleurs).
> il y en a aussi comme moi pour privilégier les apps plus chères et monoplateformes.
Pareil, vous associé payant, natif à qualité. Là encore, les contre-exemple sont nombreux.
Ce qui compte c'est la qualité du service rendu / son prix. Une application chère rendant nativement un service moyen vaudra vite moins aux yeux d'un utilisateur qu'une application multiplateforme mais gratuite et rendant un service équivalent, voir meilleur.
Et ce ratio n'a rien de linéaire.
@byte_order
"La qualité du codage n'est pas lié au fait qu'il soit portable ou pas.
Une application payante, monoplateforme peut parfaitement être mal codée tout autant (et les exemples sont légions d'ailleurs)."
Certes. Mais j'ai plus de chances de tomber sur du bon code quand c'est une petite boite qui ne travaille que sur une seule plateforme et qui a fidélisé sa clientèle avec un développement de qualité (et pas sur la base d'un monopole)
"Pareil, vous associé payant, natif à qualité. Là encore, les contre-exemple sont nombreux."
Sur le MAS/AppStore je me fais rembourser jusqu'à 14 jours après l'achat. Ça me laisse très largement le temps de constater si le boulot a été bien fait. C'est déjà plus difficile de se faire rembourser un abonnement quand on est pas satisfait...
"Ce qui compte c'est la qualité du service rendu / son prix."
Évidemment. Et la pérennité de l'investissement aussi. Une question qu'on ne se posait pas quand on achetait du logiciel en boîte. Je refuse la formule à abonnement, en tout cas pour certaines applications. Le SAAS c'est bien pour l'entreprise, pas pour le particulier.
M’enfin je suis bien d’accord, mais re-situons le contexte. On parle d’API proposées par Apple.
Dans tous les cas, ces API vont servir l’intérêt à la fois du développeur et de l’utilisateur. Du moins, à coût égal.
@SimR69
C'est pas tellement que ce soit Apple ou pas qui propose les API qui pose problème. C'est le fait qu'une webapp ne sera jamais aussi performante qu'une app native. Il suffit de comparer iWork ou MS Office dans le navigateur avec sa version desktop pour s'en convaincre.
Même avec tous les efforts du monde tu ne pourras jamais faire une webapp aussi performante que du code natif. C'est mécanique.
Disons que c'est certainement mieux, mais ce n'est pas idéal.
@LeGrosJeanLou
Je ne comprends pas du tout le rapport avec ce que j’ai dit en fait. À mon avis on ne se comprend pas du tout, on n’est absolument pas sur le même sujet.
Je ne suis pas du tout en train de comparer avec les apps natives, où ai-je parlé de ça ? Je n’ai pas parlé de performances non plus. Je sais très bien que les performances Web sont moins bonnes, puisque c’est de l’interprété.
Je parle simplement de l’ajout d’API pour les développeurs. Je ne vois pas comment on peut dire qu’une API rend service aux utilisateurs sans rendre service aux développeurs.
@SimR69
À quoi sert l'API en question ? À faire en sorte qu'une webapp se comporte plus comme une app native, c'est à dire avec plus de droits.
Privilégier les webapps en développant des API facilitant leur développement c'est évidemment aider les développeurs mais au détriment des apps natives et donc indirectement de l'utilisateur (pour les cas que j'ai cité).
Mais dans l'absolu une API est toujours une aide aux développeurs (en admettant qu'elle soit facile à utiliser). Il n'y a pas de question à se poser de ce point de vue. Il faut regarder à quoi elle sert pour savoir à qui elle sera bénéfique.
Oui mais je parle des API en général.
Et dans l’autre sens en fait : une API qui soit bénéfique pour l’utilisateur mais pas pour le développeur. Je n’en vois pas.
@SimR69
"Oui mais je parle des API en général."
Moi aussi :
"Mais dans l'absolu une API est toujours une aide aux développeurs (en admettant qu'elle soit facile à utiliser). Il n'y a pas de question à se poser de ce point de vue."
"Et dans l’autre sens en fait : une API qui soit bénéfique pour l’utilisateur mais pas pour le développeur. Je n’en vois pas."
Une API super chiante à utiliser car trop complexe, même si elle apporte des améliorations démentielles du côté de l'utilisateur peut être une vraie plaie à utiliser pour le développeur. Mais normalement c'est son travail.
Une API imposée aussi peut être pénible pour le développeur. À une époque Steve Jobs a voulu interdire toute app qui n'avait pas été produite avec Xcode. Il a fallu que Unreal sorte Epic Citadel pour le faire changer d'avis.
Bref, il y a plein de cas où les développeurs pourraient se trouver emmerder d'utiliser une API même si c'est pour le "bien" de l'utilisateur.
Bah ils sont pas obligés de l’utiliser. Ça ne peut pas être plus compliqué pour le développeur que lorsque cette API n’existait pas encore. Vu qu’il peut toujours faire comme si elle n’existait pas.
@SimR69
Tu parles d'une API bénéfique pour l'utilisateur mais pas pour le développeur.
Et dans l’autre sens en fait : une API qui soit bénéfique pour l’utilisateur mais pas pour le développeur. Je n’en vois pas.
Si elle est bénéfique pour quelqu'un c'est qu'elle est utilisée. Une API qui reste au fond du tiroir n'est bénéfique pour personne, par définition.
Donc si tu cherches une API bénéfique pour l'utilisateur mais pas pour le développeur qui l'utilise je te confirme qu'il y en a plein.
> Je ne vois pas comment on peut dire qu’une API rend service aux utilisateurs
> sans rendre service aux développeurs.
ben il suffit que les développeurs ne voient pas l'intérêt d'utiliser cette API dans leur application. Ou qu'ils s'y cassent trop les dents dessus à tenter de l'utiliser.
Des API qui on disparu faute d'audience, y'en a plein.
Tout comme pour les applications, une API native n'est pas automatiquement de bonne qualité forcément.
Jusqu'à preuve du contraire.
"Dernier exemple en date, les Progressive Web Apps poussées par Google ne sont pas encore prises en charge."
Un truc que je ne comprends pas.
Google utilise bien un fork de WebKit pour Chrome.
Est-ce que c'est le fait que ce soit un fork, que Google ne soit pas obligé de sousmettre leurs travaux à l'équipe de WebKit ?
Non, il n'y a aucune obligation de reverser dans webkit les développements faits pour Blink.
@Nicolas Hoizey
Merci pour la confirmation...
Je trouve que c'est un peu limite quand même, car tu peux bénéficier des avancements dans WebKit sans le retour...
Je me suis posé cette question déjà à l'époque de l'implémentation de VP8 dans blink, mais pas dans WebKit...
Si je ne m'abuse, Blink a maintenant trop divergé de webkit pour qu'ils puissent continuer à récupérer (tous) les développements qui y sont faits.
Blink est un fork de WebKit c'est donc devenu un projet indépendant.
les équipes de WebKit peuvent bénéficier des avancements dans Blink, les deux projets étant open source. Mais l'équipe de Blink ne va pas le faire à leur place, tout comme l'équipe de WebKit ne va pas faire de même à la place de celle de Blink.
Moi ça m'inquiète l'exécution du code même si la page est fermée, ça va être une catastrophe en terme de ressources demandé vu le nombre de sites qu'on peut visiter, et les publicitaire vont être ravis de pouvoir nous traquer même lorsque Safari est fermé.
Les services workers sont encore plus sandboxés que les web workers. et ils ne tournent pas quand le navigateur est fermé. Ils tournent dès que et tant que le navigateur tourne, nuance.
Par contre, en terme d'impact en ressources, oui, cela peut se sentir. Ou pas. C'est comme pour tout site, il peut être lourd ou pas, tout dépend de la qualité du code qui produit le contenu, code client compris.
@byte_order
Je te rappelle que sur Mac des qu'un programme est lancé il ne se coupe qu'à l'extinction ou si tu fais un cmd+Q, donc safari a une tendance à tourner en permanence en arrière plan.
J'adore le "sur mac".
Comme si sous Windows ou Linux ou BSD ou tout autres OS multitâches préemtif les applications ne continuaient pas de s'exécuter tant que :
1) l'utilisateur ne les arrête explicitement
2) l'utilisateur arrête l'ordinateur.
Si vous laissez en permanence Edge/IE/Firefox/Chrome/Safari tourné, c'est votre choix.
@byte_order
Le sur Mac ça vient du fait que quand tu appuis sur La Croix rouge l'application n'est pas fermée...
Pages