Pas d'app mobile ?
Non, trop couteux en temps de dev & de gestion des stores. Beaucoup trop couteux. Or, le Web est puissant.
Voir ce ticket dédié à la question de l'app mobile.
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.
MAJ : on est passés à Next-yak depuis longtemps et c'est génial. On écrit notre CSS qui marche en RSC comme en client, sans contrainte majeure.
Design
Sur cet ticket en réponse j'expose une partie de nos choix "radicaux" sur le design.
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, trop couteux en temps de dev & de gestion des stores. *Beaucoup* trop couteux. Or, le Web est puissant.
Voir [ce ticket dédié à la question de l'app mobile](https://github.com/laem/cartes/issues/606).
## 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.
MAJ : on est passés à Next-yak depuis longtemps et c'est génial. On écrit notre CSS qui marche en RSC comme en client, sans contrainte majeure.
## Design
Sur [cet ticket](https://codeberg.org/cartes/web/issues/2194) en réponse j'expose une partie de nos choix "radicaux" sur le design.
## 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 !