CloudKit JS : Apple ouvre CloudKit sur le web
Qu’elle semble loin, l’époque où les développeurs se plaignaient d’iCloud à longueur de journée ! CloudKit ne fête pourtant que son premier anniversaire. Mais en renversant la logique des services dans le nuage d’Apple, il a résolu de très nombreux problèmes. Ne restait qu’une critique : CloudKit est réservé aux apps iOS et OS X, alors que la tendance est aux services web. Une critique qui n’a plus lieu d’être grâce à CloudKit JS.
CloudKit JS est une bibliothèque JavaScript permettant de concevoir une interface web accédant aux mêmes données qu’une application iOS ou OS X utilisant CloudKit. Elle se charge de l’authentification de l’utilisateur, du stockage des métadonnées, et du transfert des ressources. Un développeur indépendant devrait rapidement trouver ses marques, Apple ayant fait en sorte de décalquer l’API originale en JavaScript/JSON.
De la même manière qu’Apple a éprouvé CloudKit avec iCloud Drive et la Photothèque iCloud, la firme de Cupertino a construit la version web de Notes avec CloudKit JS. On y retrouve les mêmes données que dans l’application native sur iOS 9 et OS X El Capitan, qui stocke désormais ses données dans iCloud Drive.
CloudKit JS devrait faciliter le développement de services web associés à une application iOS ou OS X, mais il faut noter qu’il ne permettra pas de développer de nouveaux services indépendants. Le point de départ est toujours une application, seules les applications étant autorisées à créer une structure de données CloudKit. Apple ne connecte donc pas les sites web à iCloud, mais ouvre les apps sur le web.
Je ne suis pas sûr d'avoir compris. Concrètement, si on a une app avec une base CloudKit, et qu'on veut développer une interface web qui accède aux mêmes données, voire une application Android, c'est possible ?
@pirmezur oui
C'est moi ou Apple tend à s'ouvrir de plus en plus ? :)
@iSc0tty :
J'ai aussi ce sentiment
non.
Apple ajoute simplement, TRES LENTEMENT, des services et fonctionnalités pour développeur, sur sa plateforme.
avant c'était le Mac puis iOS, et maintenant qu'Apple acquière (trèèèèès lentement) une plateforme "en ligne" assez solide, elle fait comme le mac et iOS: elle ouvre de nouveaux services pour les développeurs.
Notez comme le fait MacG que c'est centré et pensé autour d'une APPLICATION.
Perso, je ne comprends pas pourquoi les GAFAM ne font pas un peu de lobbying pour forcer la norme ECMA à évoluer vers d'autres langages de script en plus du JS.
parce qu'elle le fait. Par exemple Google a tenté (oublié le nom du énième projet google sans avenir)
et bien sur l'inénarrable Microsoft avec Oasis
mais la réponse du marché (les ingénieurs et développeurs) est : "parle à ma main".
Fondamentalement : Javascript est _BIEN_
il est redoutablement _BIEN_
il est objet, dynamique, moderne, extensible, syntaxe claire et classique, il est connu, normalisé, stable, intégré dans quantité de produits avec plusieurs implémentations de références, quasi tout libres ou au moins opensource
il est _BIEN_
Les runtimes se sont améliorés comme JAMAIS ON AURAIT CRU. ils sont _BIEN_
On peut travailler maintenant à ajouter plus de fonctionnalités à sa bibliothèques standards. Par exemple normaliser et intégrer un équivalent de jQuery.
Mais pourquoi diantre voulez vous remplacer Javascript par autre chose ? parce que vous voulez du Jouet à Noel ? de l'excitation ? du fun ? de "nouvo calgon" ?
Pensons plutôt à unifier le stack client et serveur. Foutre en l'air PHP pour rebâtir sur javascrip un stack serveur léger, avant de sauter à JAVA.
merci, bonsoir et au revoir.
@oomu :
Marrant tes variations sur les mots en majuscules (tu devrais arrêter d'en abuser) ^^
Javascript est née en 1995, ce n'est pas un langage "pur objet", il faut se faire beaucoup de noeuds dans la tête pour pallier à certains de ses défauts (erreurs d'implémentation, problèmes de scalabilité,...).
Je ne suis pas un grand fan de Javascript (ni de PHP) même si je reconnais qu'il(s) ont bien évolué avec le temps et j'aurais aimé utiliser LUA ou Python pour faire du scripting côté client dans le navigateur.
Je ne veux pas remplacer Javascript, j'aimerais qu'on puisse ouvrir le champ des possibles au niveau du navigateur et pour moi ça ne peut passer que par une standardisation et une adoption un peu plus rapide de concepts "modernes" au niveau de l'ECMA (faire coexister les deux modèles "pur objet" et objet orienté prototype).
Si Google a poussé Dart (peut-être en vain), c'est qu'il y a bien des arguments techniques solides en leur faveur.
Java n'est pas l'alpha et l'omega des langages par contre la JVM (ou LLVM) est son côté multi langages et un des concepts qu'il faudrait plus mettre en avant.
Le projet de Google s'appelle Dart.
De fait, tu peux utiliser d'autres langages. Tout d'abord, il y a des convertisseurs de JavaScript ES6 en JavaScript ES5 (comme Traceur et Babel). Il y a aussi des langages qui sont des versions légèrement modifiés du JS (comme Coffee Script). Il y a aussi des projets pour convertir des langages pas fait pour le Web en JS, par exemple C/C++ avec emscripten (basé sur LLVM).
Mais du coup Mac OS X Server permet de monter une passerelle LOCALE d'iCloud Drive … possiblement déconnecté au cazou coupure ou indisponibilité du service ???
"Ne restait qu’une critique : CloudKit est réservé aux apps iOS et OS X"
J'en ai au moins une de plus, CloudKit n'est pas libre (au sens de la FSF et Debian).