Non. C'est très coûteux de maintenir 3 bases de code : impossible de présenter une app android sans app ios, donc 3 bases de code. Aux dernières nouvelles, React native oblige à maintenir deux bases, la mise en commun est faible.
Je ne vois pas comment se mettre à supporter ces plateformes correctement sans avoir au moins 2 dev à plein temps.
Le Web est puissant. C'est l'app store le plus universel, plutôt épargné par les politiques de requins d'Apple et Google.
Pour l'instant donc, Cartes fait le pari du Web, et il reste déjà tant de choses à développer, donc un meilleur support PWA et par exemple, une notification "voulez-vous installer cette application ?".
SPA vs MPA / RSC vs 'use client'
Le projet est codé en NextJs.
À la base, futur.eco était en React + webpack basique. Mon seul besoin était de générer des meta pour les partages de lien. J'ai donc commencé un serveur en expressjs pour pré-rendre des meta à envoyer dans la page HTML. C'était pas trivial mais pas trop compliqué non plus, mais je me suis rendu compte que j'étais en train de réimplémenter Next :D.
Aujourd'hui, après 12 ans de travail sur des applis Web diverses, je fait un constat simple : les promesses de gain de SEO et de performance vendues par les défenseurs des MPA par rapport aux SPA ne sont pas vérifiées dans les faits.
Sur futur.eco comme sur nosgestesclimat.fr, la migration vers Next depuis un React sans serveur + l'option de prerender.io de base de Netlify n'a pas donné d'augmentation de SEO à horizon que ce soit au bout d'une semaine, d'1 mois, de 6 mois, d'1 an ou d'un an. À l'inverse sur futur.eco, l'ajout d'un nouveau calculateur qui ciblait des mots clefs "coût d'un trajet en voiture" en plus de "calcul de CO2 ferry avion etc" a résulté en une explosion* de SEO. De même, le trafic n'a pas non plus explosé sur ces deux produits.
Certains développeurs ont donc tendance à surestimer énormément le gain produit d'une MPA, et à sous-estimer les complexités de la gestion du combo server client et toutes ses réhydratations finalement pas si magiques.
Et si ça peut vous rassurer, si je devais lancer un nouveau blog interaction utilisateur, évidemment que je ferais du prérendu côté serveur ;) À chaque besoin sa techno.
Cela dit, ça n'empêche pas de vouloir augmenter la part de RSC dans l'architecture de Cartes. Mais ce n'est pas la priorité, loin de là ! Pour le SEO, avant tout ça, il faut des liens entrants, des partenariats, des intégrations en iframe, des pages de contenu, une page à propos, un blog plus fourni, de meilleurs meta de partage, de la génération côté serveur des fiches lieux, des dizaines d'autres contenus à inventer, et tout ça ne nécessite aucunement du RSC plutôt qu'un simple rendu côté serveur.
Ajoutons que d'autres frameworks sont très intéressants en 2024 : Deno Fresh, Hono jsx, etc. Mais pour Cartes, à ce stade, Next fait le boulot sans problème et avec beaucoup d'avantages :)
CSS
La gestion du CSS par Next app router n'est pas super. Je suis très attaché à styled-components, car c'est un framework CSS très proche du standard CSS, qui permet à la fois d'extraire des composants réutilisables, et de balancer du CSS personnalisé pour des composants uniques (très fréquents) via la balise css. Mais styled-components oblige à créer des îlots de use client même dans le layout haut niveau des pages, car React RSC ne supporte pas le context... Notons alors la librairie next-yak qui semble super prometteuse pour ça ! https://github.com/jantimon/next-yak/issues/77#event-12982863836.
Typescript ou JS ?
Je suis largement favorable à Typescript, mais pas encore convaincu de l'intérêt de tout typer, notamment l'UI, en l'absence d'une équipe nombreuse de développeurs ni d'enjeux de prod graves. Surtout, dans la perspective actuelle d'expérimentations à tout va. Je suis plus un utilisateur opportuniste de typescript : mon usage principal aujourd'hui est d'améliorer les suggestions automatiques de l'environnement de dev. On est très très loin d'avoir une app qui compilerait avec l'option stricte typescript et ce n'est pas le but d'y arriver à moyen-terme. Mais plus de couverture des types, notamment au fur et à mesure de la convergence des fonctionnalités (par exemple, la gestion des images Wikimedia, Wikipedia, Wikidata, Panoramax dont certains bouts de codes sont actuellement séparés, bazar vs cathédrale), ça oui !
Pas d'app mobile ?
Non. C'est très coûteux de maintenir 3 bases de code : impossible de présenter une app android sans app ios, donc 3 bases de code. Aux dernières nouvelles, React native oblige à maintenir deux bases, la mise en commun est faible.
Je ne vois pas comment se mettre à supporter ces plateformes correctement sans avoir au moins 2 dev à plein temps.
Le Web est puissant. C'est l'app store le plus universel, plutôt épargné par les politiques de requins d'Apple et Google.
Pour l'instant donc, Cartes fait le pari du Web, et il reste déjà tant de choses à développer, donc un meilleur support PWA et par exemple, une notification "voulez-vous installer cette application ?".
SPA vs MPA / RSC vs 'use client'
Le projet est codé en NextJs.
À la base, futur.eco était en React + webpack basique. Mon seul besoin était de générer des meta pour les partages de lien. J'ai donc commencé un serveur en expressjs pour pré-rendre des meta à envoyer dans la page HTML. C'était pas trivial mais pas trop compliqué non plus, mais je me suis rendu compte que j'étais en train de réimplémenter Next :D.
Aujourd'hui, après 12 ans de travail sur des applis Web diverses, je fait un constat simple : les promesses de gain de SEO et de performance vendues par les défenseurs des MPA par rapport aux SPA ne sont pas vérifiées dans les faits.
Sur futur.eco comme sur nosgestesclimat.fr, la migration vers Next depuis un React sans serveur + l'option de prerender.io de base de Netlify n'a pas donné d'augmentation de SEO à horizon que ce soit au bout d'une semaine, d'1 mois, de 6 mois, d'1 an ou d'un an. À l'inverse sur futur.eco, l'ajout d'un nouveau calculateur qui ciblait des mots clefs "coût d'un trajet en voiture" en plus de "calcul de CO2 ferry avion etc" a résulté en une explosion* de SEO. De même, le trafic n'a pas non plus explosé sur ces deux produits.
Certains développeurs ont donc tendance à surestimer énormément le gain produit d'une MPA, et à sous-estimer les complexités de la gestion du combo server client et toutes ses réhydratations finalement pas si magiques.
Et si ça peut vous rassurer, si je devais lancer un nouveau blog interaction utilisateur, évidemment que je ferais du prérendu côté serveur ;) À chaque besoin sa techno.
Cela dit, ça n'empêche pas de vouloir augmenter la part de RSC dans l'architecture de Cartes. Mais ce n'est pas la priorité, loin de là ! Pour le SEO, avant tout ça, il faut des liens entrants, des partenariats, des intégrations en iframe, des pages de contenu, une page à propos, un blog plus fourni, de meilleurs meta de partage, de la génération côté serveur des fiches lieux, des dizaines d'autres contenus à inventer, et tout ça ne nécessite aucunement du RSC plutôt qu'un simple rendu côté serveur.
Ajoutons que d'autres frameworks sont très intéressants en 2024 : Deno Fresh, Hono jsx, etc. Mais pour Cartes, à ce stade, Next fait le boulot sans problème et avec beaucoup d'avantages :)
CSS
La gestion du CSS par Next app router n'est pas super. Je suis très attaché à styled-components, car c'est un framework CSS très proche du standard CSS, qui permet à la fois d'extraire des composants réutilisables, et de balancer du CSS personnalisé pour des composants uniques (très fréquents) via la balise
css. Mais styled-components oblige à créer des îlots de use client même dans le layout haut niveau des pages, car React RSC ne supporte pas le context... Notons alors la librairienext-yakqui semble super prometteuse pour ça ! https://github.com/jantimon/next-yak/issues/77#event-12982863836.Typescript ou JS ?
Je suis largement favorable à Typescript, mais pas encore convaincu de l'intérêt de tout typer, notamment l'UI, en l'absence d'une équipe nombreuse de développeurs ni d'enjeux de prod graves. Surtout, dans la perspective actuelle d'expérimentations à tout va. Je suis plus un utilisateur opportuniste de typescript : mon usage principal aujourd'hui est d'améliorer les suggestions automatiques de l'environnement de dev. On est très très loin d'avoir une app qui compilerait avec l'option stricte typescript et ce n'est pas le but d'y arriver à moyen-terme. Mais plus de couverture des types, notamment au fur et à mesure de la convergence des fonctionnalités (par exemple, la gestion des images Wikimedia, Wikipedia, Wikidata, Panoramax dont certains bouts de codes sont actuellement séparés, bazar vs cathédrale), ça oui !