« Pourquoi on est repassé de Go à PHP ? », Danny van Kooten, l'éditeur de MailChimp nous livre les raisonsde ce rebasculement
En avril 2017, Danny van Kooten, un développeur indépendant, prenait la décision de réécrire en Go l'application Laravel qui alimente Boxzilla, un plugin pour WordPress qui permet de créer des formulaires MailChimp ayant plus d'un million d'utilisateurs. Le développeur précisait qu'il avait pris du plaisir à coder son application en Go. Rappelons au passage que Go est un langage de programmation compilé et concurrent inspiré de C et Pascal. Ce langage a été développé par Google et veut faciliter et accélérer la programmation à grande échelle. C'est un langage qui vise aussi la rapidité d'exécution, indispensable à la programmation système. Il considère le multithreading comme le moyen le plus robuste d'assurer sur les processeurs actuels cette rapidité tout en rendant la maintenance facile par séparation de tâches simples exécutées indépendamment.
Pourquoi avoir laissé PHP pour Go ?
Après avoir développé son application en Go, Kooten trouvait que le résultat final était une énorme amélioration par rapport à l'ancienne application (développé en PHP) avec une meilleure performance, un déploiement plus facile et une couverture de test plus étendue. Le développeur explique que son application était relativement simple. C'était une API et un gestionnaire de compte relativement simple, pilotée par une base de données, où les utilisateurs peuvent se connecter pour télécharger le produit, consulter leurs factures ou mettre à jour leur méthode de paiement, dit-il. Laravel l'avait bien aidé à développer, mais Kooten trouvait que certaines choses « ont toujours semblé trop compliquées » à faire.
« C'est un plaisir d'écrire du code Go, l'outillage est incroyable et il n'est pas seulement rapide à développer, le résultat final est généralement très rapide aussi. Le simple fait de lire le but du projet Go m'a convaincu sur le langage. Je pense que nous verrons un bon nombre de personnes passer des langages de typage dynamique comme PHP, Python et JavaScript à Go dans les prochaines années. Migrer le code vers Go consistait principalement à obtenir l'interaction de la base de données et à porter les modèles Blade vers quelque chose que nous pourrions utiliser dans Go », écrivait-il.
Pourquoi avoir renoncé à Go pour revenir à PHP ?
Contre toute attente, Danny van Kooten annonce dans un billet de blog le lundi dernier que ses applications de boutique sont de nouveau alimentées par PHP. Pourquoi ce revirement soudain pourrait-on se demander ? Eh bien, la raison est simple. Le développeur trouve que PHP s'est beaucoup amélioré au cours des trois dernières années. « Le langage a ajouté des déclarations de type argument scalaire, des déclarations de type retour, des exceptions multi-catch, des améliorations de performances impressionnantes et bien d'autres améliorations plus générales », dit-il. Kooten a été principalement séduit par Symfony 4.
Envoyé par Danny van Kooten
J'ai toujours été un grand fan de la promesse de compatibilité de Symfony et leur impressionnante expérience de 13 ans prouve qu'ils le pensent vraiment. Alors quand Symfony 4 est sorti et que j'ai entendu de bonnes choses à son sujet, je l'ai pris pour un essai en y implémentant une toute petite partie de notre application. Comme conclusion, j'ai remarqué que beaucoup d'efforts ont été consacrés à la simplification de l'installation, ce qui a accéléré le démarrage d'une application Symfony avec beaucoup moins de travail pour configurer les bundles. Il rivalise maintenant avec le développement rapide de Laravel tout en encourageant des pratiques de développement décentes. Et il est très performant.
Il a été relativement facile de porter notre ancienne application Laravel sur Symfony, d'implémenter de nouvelles fonctionnalités de la version Go de notre application et d'annuler certains des raccourcis que j'avais pris auparavant (la plupart grâce aux aides globales de Laravel). Un bel effet secondaire est que j'ai réussi à augmenter substantiellement notre couverture de test dans le processus. Écrire la même application en termes de fonctionnalités pour la deuxième fois une troisième fois est vraiment utile à cet égard.
La barre de débogage de Symfony est un outil incroyable. Il vous montre ce qui s'est passé pendant le trajet de la demande à la réponse, vous informe des avertissements et des déprédations et est livré avec un profileur intégré que vous pouvez facilement connecter à des parties de benchmark de votre propre code. Après avoir appris le composant Form de Symfony, je préfère ne plus m'en passer. Il est donc trivial de rendre un formulaire accessible qui peut être réutilisé à plusieurs endroits, de valider le formulaire lors de sa soumission, puis de remplir un objet PHP à partir des données du formulaire en toute sécurité.
Il a été relativement facile de porter notre ancienne application Laravel sur Symfony, d'implémenter de nouvelles fonctionnalités de la version Go de notre application et d'annuler certains des raccourcis que j'avais pris auparavant (la plupart grâce aux aides globales de Laravel). Un bel effet secondaire est que j'ai réussi à augmenter substantiellement notre couverture de test dans le processus. Écrire la même application en termes de fonctionnalités pour la deuxième fois une troisième fois est vraiment utile à cet égard.
La barre de débogage de Symfony est un outil incroyable. Il vous montre ce qui s'est passé pendant le trajet de la demande à la réponse, vous informe des avertissements et des déprédations et est livré avec un profileur intégré que vous pouvez facilement connecter à des parties de benchmark de votre propre code. Après avoir appris le composant Form de Symfony, je préfère ne plus m'en passer. Il est donc trivial de rendre un formulaire accessible qui peut être réutilisé à plusieurs endroits, de valider le formulaire lors de sa soumission, puis de remplir un objet PHP à partir des données du formulaire en toute sécurité.
Pour certains internautes, passer de PHP à Go ne semble pas être une bonne idée à leur avis. Pour cause, disent-ils, les fichiers PHP peuvent être déployés indépendamment, échangés ou mis à jour en direct, aucune compilation des fichiers PHP n'est nécessaire. Pour eux, si ce n'est que pour compiler et déployer un système entier pour changer un seul point d'extrémité d'une application est comme revenir en arrière après avoir utilisé PHP.
Source : Billet de blog
Et vous ?
Qu'en pensez-vous ? Quel langage de programmation Web côté serveur préférez-vous ? Pourquoi ? Vous est-il déjà arrivé de quitter PHP pour y revenir après ? Pour quelles raisons ?Voir aussi
Quels sont les langages de programmation les plus utilisés par les développeurs ? Une analyse des évènements publics sur GitHub PHP est utilisé par plus de 80 % des sites, toutefois 96 % de ces sites utilisent encore la version 5 du langage, selon un rapport de la W3Techs PHP 7.4 devrait être rendu disponible vers la fin de cette année voici un aperçu des nouveautés qui pourraient y figurer W3Tech : plus de 60 % des sites Web tournent sur PHP 5.x une version qui ne sera plus supportée après le 31 décembre 2018
Vous avez lu gratuitement 4 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
