Quelle pile technique pour quel projet

Les clients demandent quelle technologie nous allons employer étonnamment tôt, souvent dès le premier échange. La question est légitime et c'est presque toujours la mauvaise par laquelle commencer, car pour la plupart des projets plusieurs réponses sont correctes et le choix se tranche sur des critères qui n'ont rien de technique.

Voici ce qui le tranche réellement.

Où cela doit tourner

C'est la contrainte que personne ne voit venir, et celle qui élimine des options le plus vite.

Une application PHP tourne sur de l'hébergement mutualisé ordinaire. Tous les hébergeurs économiques de la planète le prennent en charge, cela coûte très peu, et aucune configuration particulière n'est requise. Une application JavaScript moderne a besoin d'un processus Node qui tourne en continu, un type d'hébergement différent et moins universellement disponible. Beaucoup d'offres bon marché ne le proposent pas du tout, et celles qui le proposent le placent derrière davantage de configuration.

Si l'hébergement est imposé, ou si le budget d'hébergement est petit et permanent, cela tranche donc énormément avant que quiconque parle de frameworks. Ce n'est pas une inquiétude théorique. C'est la raison la plus fréquente pour laquelle un choix techniquement sain se révèle être le mauvais.

Qui l'entretiendra après notre départ

Deuxième question, et elle compte plus que n'importe quel comparatif de performance.

Si vos propres équipes reprennent le projet, construisez-le dans ce qu'elles connaissent déjà. Un framework marginalement meilleur que personne dans vos murs ne sait lire vaut moins qu'un framework ordinaire qu'elles savent lire. Si personne ne le reprend, la question devient de savoir avec quelle facilité vous pourriez nous remplacer, ce qui plaide pour une technologie ennuyeuse et répandue plutôt que pour quoi que ce soit d'astucieux.

Dans les deux cas, la réponse porte sur les personnes, pas sur les performances.

Ce que cela doit réellement faire

Ce n'est qu'en troisième position que le travail lui-même commence à restreindre les options, et moins qu'on ne le croit. La plupart des logiciels de gestion sont des formulaires, des enregistrements, des droits et des rapports. À peu près tout sait faire cela correctement. La technologie ne devient déterminante qu'aux extrêmes : temps réel intensif, exigences de performance inhabituelles, accès au matériel, très gros volumes de données.

Si votre projet n'est pas à l'un de ces extrêmes, et la plupart n'y sont pas, alors débattre du framework le plus rapide revient à débattre d'une différence que vos utilisateurs ne percevront jamais.

Ce que nous employons, et quand

Notre travail web suit deux voies, et la séparation découle de la question de l'hébergement ci-dessus.

Laravel et PHP prennent tout ce qui doit vivre sur un hébergement standard, tout ce qui comporte une partie administration substantielle, et tout ce pour quoi le client veut un point de chute bon marché, ennuyeux et durable. PHP traîne une mauvaise réputation acquise il y a vingt ans et largement imméritée aujourd'hui. Laravel en particulier vous donne l'authentification, les droits, une couche d'administration et les migrations de base de données sans les assembler vous-même, ce qui est exactement là où une application de gestion dépense l'essentiel de son budget.

Next.js avec React intervient là où l'interface est le produit. Tout ce qui est très interactif, tout ce qui a un véritable état à gérer dans le navigateur, tout ce pour quoi la vitesse d'affichage et la visibilité dans les moteurs comptent à la fois. Ce site tourne dessus, tout comme notre démonstration de tableau de bord, parce qu'un graphique avec réticule et navigation au clavier est précisément ce pour quoi cette pile existe et précisément ce qui devient pénible sans elle.

Nous écrivons en TypeScript plutôt qu'en JavaScript pour tout ce que nous pensons encore modifier l'an prochain. L'intérêt n'est pas moins de bugs le premier jour. C'est qu'une modification six mois plus tard vous dit immédiatement ce qu'elle vient de casser.

La mise en forme passe par Tailwind pour une raison peu glorieuse : cela garde les décisions de design dans le balisage, là où vous les voyez, plutôt que dans une feuille de style qui gagne une couche de surcharges chaque fois que quelqu'un est pressé.

Le mobile va vers Flutter quand une application est réellement justifiée. Une seule base de code produit iOS et Android, ce qui divise le développement par deux environ et, plus important, divise par deux chaque modification pendant toute la vie de l'application. Le natif justifie son coût quand il faut une intégration profonde à la plateforme ou le dernier degré de finition. Pour la plupart des applications de gestion, c'est une façon de payer deux fois.

Pour les données, PostgreSQL ou MySQL, et à l'échelle où fonctionnent la plupart des projets cela n'a réellement pas d'importance. Prenez ce que votre hébergement fournit. PostgreSQL est la meilleure base quand le choix est ouvert et que les données ont une structure réelle.

C++ apparaît là où le travail est du logiciel de bureau ou porte des exigences de performance qu'une pile web ne peut pas satisfaire. C'est une réponse spécialisée à une question spécialisée et cela ne devrait jamais être la réponse à une question ordinaire.

Docker apparaît quand un projet a plus d'une pièce mobile, ou quand l'écart entre nos machines et le serveur commence à coûter du temps réel.

La question qui vaut la peine d'être posée

Plutôt que quelle technologie, demandez ce qui se passe dans trois ans.

Pourrez-vous encore recruter quelqu'un qui connaît cela. Le framework est-il toujours maintenu. Si vous voulez changer d'hébergeur, le pouvez-vous. Si vous voulez changer de prestataire, quelle part de ce que nous avons construit est standard et quelle part nous est propre. Ces réponses vous en disent bien plus sur ce que vous achetez que le nom d'un framework.

Tout studio qui répond à « quelle pile » par le même mot à chaque fois, quoi que vous ayez décrit, vous parle de ses effectifs et non de votre projet.