En ce moment, j'explore les possibilités du #WebNatif pour faire des tout petits outils #offlinefirst (et peut-être ensuite #localfirst )

En gros il s'agit de faire des outils qui fonctionnent directement dans un navigateur sans nécessiter de connexion internet une fois l'outil chargé pour la première fois.

Voici un exemple d'un outil que j'ai développé récemment pour générer les bannières pour le meetup que j'organise.

https://banner.strasbourg-craft.fr

Bannières - Software Craft Strasbourg

Génération de bannières pour les meetups Software Craft Strasbourg

J'ai envie d'explorer les possibilités de cette approche.

Inspiration https://alethgueguen.com/how-to-build-a-pwa-in-pure-javascript-a-compilation-of-insights-and-pratices par @planeth

Quelques avantages que je perçois pour le moment :

- le code est portable : s'appuie sur des fonctionnalités natives du navigateur
- le code est lisible par des humains (on peut récupérer le code et l'étudier "à l'ancienne")

How to build a PWA in pure Javascript, a compilation of insights and pratices

Aleth Gueguen Conseil IT

Avantages (suite)

- #nobuild : pas de build requis (oubliez npm et autres package.json) : le code écrit est exactement celui qui est exécuté sur le navigateur sans transformation. Les libs sont inclues dans un dossier "vendor" et ne sont pas téléchargées via un gestionnaire de dépendances (évite les #supplychainattack)

Des inconvénients :

- le code utilisé tel quel n'est pas "minifié", et a un impact plus grand sur le réseau. MAIS ! Je n'importe que très peu de code tierce partie.

Les compromis que j'accepte de faire :

- je ne gère pas certains cas d'erreur ou fonctionnalités "de confort" (les outils sont tout petits et ne font qu'une seule chose (#unixphilosophy ), par exemple, je ne vérifie pas tous les cas de saisie incorrecte (ou par exemple le redimensionnement des images que j'envoie, je m'assure que les images que j'envoie ont la même largeur et hauteur)

Compromis (suite)

- j'ai choisi d'utiliser les scripts de type "module". Ca m'empêche d'utiliser les attributs écouteurs d'événements `onclick` et autres. Je dois récupérer les éléments Html avec des sélecteurs dans JavaScript et j'y déclare des event listeners (ne pas oublier de les nettoyer)

Explorations techniques:

- Persistance via localstrorage (j'ai envie d'essayer IndexedDB maintenant)
- Pwa (Progressive Web App) via manifeste Jason (pour "installer" l'application sur un ordinateur ou un smartphone)
- Service Worker pour servir de proxy et mettre en cache des ressources (html, scripts, images...) pour le fonctionnement hors ligne

Explorations techniques (suite)

- jusqu'à quel point je peux utiliser des fonctionnalités récentes du navigateur tout en maintenant une compatibilité avec des terminaux plus anciens (ex iphone 7+ ne supporte pas les styles Css imbriqués) #Rgaa #EcoConceptionNumérique
- Comment communiquer des données avec d'autres applications (#unixphilosophy ) peut-être via des postMessage entre des applis sur le même sous-domaine ?

Explorations techniques (suite)

#localfirst

- Comment synchroniser mes données locales entre plusieurs machines ? avec un serveur ?
- #eventsourcing et #CQRS ?
- #crdt (@inkandswitch.com ) pour la collaboration ? Est-ce qu'il faut de la collaboration ?

@marc_bouvier @inkandswitch.com commence par le plus simple/rustique et voit si ça colle à ton cas d'usage. Je sais que les CRDT c'est la hype, mais la lib qui l'implémente est très lourde, le code non trivial, et à part si tu veux faire du collaboratif en temps réel sur des documents, ça a pas trop d'intérêt

@planeth @inkandswitch.com

C'est un peu ce que je me disais. Tant que le besoin n'y est pas, pas trop d'intérêt de les mettre en place.

Je laisse l'usage me guider pour le moment.

@marc_bouvier si c'est pas pour un iphone, share_target c'est top !
@planeth merci beaucoup pour ces découvertes