Le mythe de la productivité d'un seul langage
C'est génial, car vous pouvez utiliser le même langage en frontend et en backend !
Je ne pense pas que ce soit génial, en fait.
C'est une hypothèse assez courante dans le monde javascript.
Vous gagnez en productivité, car vous utilisez le même langage sur le frontend et le backend.
Mais pourquoi exactement ? Comment gagner en productivité ? Et combien?
Certains arguments courants et hypothèses intégrées sont
Vous n'avez qu'à apprendre une seule langue
Vous pouvez partager du code entre le frontend et le backend
Vous bénéficiez de la sécurité des types entre le backend et le frontend
Déploiement plus facile
Il est difficile d’être en désaccord avec l’un ou l’autre de ces éléments en théorie.
Toutes choses étant égales par ailleurs, tout le monde devrait choisir d’écrire le frontend et le backend dans le même langage.
Mais tout le reste n’est pas égal…
Les arguments
Vous n'avez qu'à apprendre un seul langage
Dans tout projet réel, vous utilisez déjà de nombreux langages et outils.
HTML
CSS
Javascript
Manuscrit
Vent arrière
SQL
prisme
Vite
Yaml
Docker
Vercel
Sans serveur vs serveur
8 fichiers .config.js
Vous basculez constamment entre de nombreux langages, outils et systèmes. Un de plus ne tuera pas votre productivité.
Connaître le javascript "frontend" ne vous donne presque aucun avantage une fois que vous souhaitez créer un serveur qui prend en charge les requêtes et répond avec json.
Si tu veux apprendre, tu dois apprendre
SQL
Comment modéliser vos tables/entités
Prisme (ORM)
Comment s'authentifier sur le serveur
Comment exécuter des tâches coûteuses et de longue durée en arrière-plan
Comment acheminez-vous les demandes entrantes ?
Comment répondez-vous avec json ?
Comment répondre avec un 404 ? Quand répondez-vous avec un 404 ?
Comment faire du middleware ?
Comment accepter un téléchargement de fichier et le stocker quelque part ?
Comment générer une définition openAPI ? Qu’est-ce que c’est ?
C'est quoi ce truc de cors ?
Où l'hébergez-vous ?
Comment configurer vos pipelines pour qu'ils se déploient automatiquement ?
Imaginez devoir comprendre tout cela pour la première fois dans une application NodeJS par rapport à une application c#.
Quelle que soit votre expérience en Javascript frontend, vous ne gagnez pratiquement rien en choisissant NodeJS plutôt que c# plutôt que Django.
Savoir réagir n'améliore pas significativement votre vitesse d'apprentissage ou de mise en œuvre de l'un de ces éléments.
Vous pouvez partager du code entre le frontend et le backend
Ouais et tu ne devrais probablement pas. J'ai vu cela du côté javascript et .net.
C'est incroyable en théorie, mais cela ne fonctionne pas vraiment dans la réalité. Ce qui arrive la plupart du temps, c’est qu’une classe essaie d’en faire trop.
Ceci est particulièrement visible dans le cas de classes d'entités qui décrivent également la forme des tables de la base de données.
Nous avons la classe Post qui a créé la table Posts via notre ORM.
Ensuite, nous avons le endpoint get/posts/1 qui renvoie naturellement Post.
Bien sûr, nous affichons également les messages dans le frontend et vérifions que nous avons une classe Post parfaite pour cela.
Attendez maintenant, cette propriété Slug sur la publication ne peut jamais être vide au niveau de la base de données. Ajoutons un attribut.
Et lorsque vous créez une publication via le endpoint post/Post, nous voulons nous assurer qu'Author est toujours remplie, nous ajoutons donc une validation avec un attribut.
Oh, nous devons également le dire à l'utilisateur, alors ajoutons également un attribut côté client d'une manière ou d'une autre, avec l'internationalisation, bien sûr.
Cela devient incontrôlable à chaque fois.
La plupart des gens ont déjà adopté différentes classes dto ou model.
La validation fait trébucher les gens, car ils pensent à « la » validation.
Mais il existe en fait 3 types de validation différents ici. Côté client, niveau API, niveau base de données.
Ces 3 niveaux du système ne correspondent tout simplement pas à 1:1 et si vous essayez de le faire fonctionner (ce qui est malheureusement possible), vous vous retrouverez noyé dans la complexité.
Vous bénéficiez de la sécurité des types entre le backend et le frontend
Ce n'est tout simplement pas vraiment un gros problème avec des outils modernes comme openAPI/swagger.
J'ai également une sécurité de type entre mon backend AspNetCore et mon frontend NextJs.
Il me suffit de générer un client à partir de mon contrat openAPI généré automatiquement avec une seule commande.
npx swagger-typescript-api -p ./../backend/Schema.yaml -o ./src/api -n api.ts --axioset maintenant j'appelle mes typesafe endpoints comme ceci
let launches = await api.getTodaysLaunchesEndpoint();Le déploiement est plus facile
Honnêtement, oui.
Il est définitivement plus facile de déployer une application nextjs seule qu'une application nextjs + un serveur backend en c# ou go.
Cependant, le savoir ne devrait pas vous coûter plus d’une journée si vous ne l'avez jamais fait auparavant.
Comment choisir alors ?
Alors, si aucun de ces arguments n’est valable, comment choisissez-vous votre backend ?
Regardez le langage de programmation actuel.
Regardez l'écosystème.
Découvrez ce que cela fait d'écrire en c#, javascript et python.
C'est ainsi que vous écrivez une requête qui récupère les publications les plus récentes des flux RSS auxquels un utilisateur est abonné.
Prisma / Javascript
EF Core/C#
SQL pur
Comment savoir comment créer un contexte React pour partager des données entre plusieurs composants vous aide-t-il ici ?
Ce n’était pas un exemple choisi avec soin. C'était la première requête que j'ai sélectionnée dans mon exemple d’agrégateur Rss.
Plus tôt, lorsque je copiais le code pour créer ces blogs dans des fichiers mdx à partir du repository shadcn/taxonomy , j'ai vu ce code et je n'arrivais pas à y croire.
Cela semble probablement normal pour javascript.
Dans aucun univers, le tri d'un tableau pour 1 champ sur un objet ne devrait être une opération à 3 lignes et 2 paramètres.
Cela nécessite également une bibliothèque supplémentaire pour travailler avec les dates.
Je sais que vous pouvez l'écrire en une seule ligne. Mais un de vos autres petits outils, appelé Prettier ne vous le permettra pas.
C'est ainsi que vous commencez à accepter les requêtes http et à répondre avec json dans js, go et c#.
Les langages et frameworks se consolident tous sur ce type de syntaxe.
Go et C# peuvent proposer du sucre syntaxique, là où javascript ne le peut tout simplement pas.
Les autres langages ne sont pas aussi effrayants qu’on le pense.
Leurs langages de programmation sont supérieurs.
Leurs bibliothèques standard sont supérieures.
Leurs écosystèmes sont supérieurs pour effectuer le travail back-end.
La productivité que vous pensez perdre en écrivant du c# au lieu de javascript est largement compensée par l'écosystème, les outils et le langage.
Vous serez également simplement un meilleur programmeur avec une compréhension plus claire de la différence entre client et serveur.
Cela peut paraître évident pour les personnes plus expérimentées, mais je me souviens avoir commencé mon premier travail en créant des formulaires Web dans Asp.net.
Les premiers mois, je n'avais tout simplement pas la notion de client et de serveur, car tout est juste... là.
J'ai juste changé ce peu de logique et ensuite il a fait ce dont j'avais besoin.
Où va-t-il ? Je n'ai même pas encore la compréhension nécessaire pour réfléchir à la question.
Les débutants utilisant NextJS ou les composants du serveur React rencontreront à 100 % le même problème.
Dernières choses
L'écosystème javascript est incroyable pour créer des interfaces.
JSX est génial. Tailwind est génial. Le retour visuel instantané lorsque vous enregistrez est génial.
Tous les méta-frameworks comme NextJS et Svelte avec leur réactivité magique, le rendu côté serveur, la mise en cache statique et le routage vous offrent une puissance insensée pour très peu d'investissement.
Les bibliothèques comme TanStack Query ou shadcn ou next-auth fonctionnent très bien.
Les landing pages que je peux simplement voler sur Github, qui offrent une réactivité parfaite et de petites animations, sont géniales.
Des développeurs incroyables ont rendu javascript supportable sur le serveur.
Mais c'est tout. C'est tout ce que c'est et tout ce que cela sera toujours.
Javascript sur le serveur ne se compare à aucun des langages spécialement conçus à cet effet.
Je suis vraiment désolé pour les personnes qui ont été amenées à écrire du javascript sur le serveur. J'ai vu ce que ça fait aux gens.
Essayez-le. Choisissez un langage backend et voyez ce que cela donne.
Vous serez plus productif, pas moins.
Merci de m’avoir lu!