Discussion :

[Michael Guilloux]

NativePHP veut permettre aux développeurs de créer des applications desktop natives multiplateformes avec PHP et les techs du Web
une réincarnation du framework Electron pour les développeurs PHP ?

NativePHP est un nouveau framework, qui selon ses auteurs, permet de créer rapidement des applications de bureau natives riches en utilisant PHP. Il offre des classes faciles à utiliser pour interagir avec les fonctionnalités du système d'exploitation, des outils pour construire et empaqueter des applications natives, ainsi qu'un runtime PHP statique pour une exécution sans effort sur les systèmes des utilisateurs. Contrairement à d'autres frameworks, NativePHP n'impose pas de méthodes strictes pour la construction des applications et prend en charge différents outils d'interface utilisateur tels que React, Vue, Livewire, etc. Il comprend également des fonctionnalités de gestion de fenêtres, de menus, de fichiers, de base de données, et bien plus encore. Selon ses auteurs, les possibilités de développement avec NativePHP sont vastes et limitées uniquement par l'imagination des développeurs.

Actuellement en phase alpha, NativePHP est un nouveau framework qui fait étrangement penser à Electron, le framework de GitHub permettant de développer des applications de bureau multiplateformes (macOS, Windows, Linux) avec des technologies web (JavaScript, HTML et CSS). La différence majeure semble être l'utilisation de PHP.

NativePHP est un nouveau framework pour construire rapidement des applications de bureau riches et natives en utilisant PHP. Si vous êtes déjà développeur PHP, vous vous sentirez tout de suite chez vous. Si vous êtes nouveau dans le monde de PHP, nous pensons que vous trouverez NativePHP facile à apprendre et à utiliser. Quel que soit votre parcours, nous pensons que vous serez rapidement productif.

NativePHP connaît un succès fulgurant à travers le monde en permettant aux développeurs PHP de créer de véritables applications natives multiplateformes en utilisant les outils et les technologies qu'ils connaissent déjà : HTML, CSS, JavaScript et bien sûr, PHP.

Sur le site du projet, NativePHP est présenté comme une combinaison des éléments suivants :

• Une collection de classes faciles à utiliser - des abstractions - qui vous permettent d'interagir avec diverses fonctionnalités du système d'exploitation hôte.
• Un ensemble d'outils pour permettre la création et l'empaquetage de votre application native en utilisant l'environnement Web d'Electron ou Tauri.
• Un runtime PHP statique qui permet à votre application de s'exécuter sur n'importe quel système d'utilisateur sans aucun effort de leur part.

NativePHP vient également avec un ensemble de fonctionnalités utiles, notamment la gestion des fenêtres, la gestion des menus, la gestion des fichiers, une prise en charge de base de données (SQLite) et des notifications natives.

Pour les auteurs du projet, vous pouvez construire presque tout avec NativePHP dans les limites de votre imagination.

Que puis-je construire avec NativePHP ?

Honnêtement, tout ce que vous voulez. Nous pensons que NativePHP va permettre à des milliers de développeurs de construire toutes sortes d'applications. La seule limite est votre imagination.

Vous pourriez construire une application de barre de menus qui vous permet de gérer vos cron jobs, ou une nouvelle application de lancement, ou un enregistreur d'écran qui met des chapeaux de cowboy sur chaque emoji de smiley qu'il voit.

Pour l'instant, le projet ne prend en charge qu'un pilote Laravel, mais l'équipe dit déjà travailler sur sa compatibilité avec n'importe quel framework que vous utilisez. Et même si vous n'utilisez pas de framework du tout, NativePHP devrait prendre en charge vos cas d'utilisations.

Avant que vous ne vous posiez la question, les auteurs du projet précisent également que NativePHP n'est ni une nouvelle version personnalisée de PHP, ni un framework GUI.

NativePHP n'est pas un framework GUI. Nous ne voulons pas vous dire comment construire votre application. Vous pouvez choisir l'ensemble d'outils d'interface utilisateur qui vous rend le plus productif, ainsi que votre équipe.

Vous construisez une interface front-end React ? Pas de problème. Vue ? Bien sûr. Livewire ou Inertia ? Peu importe ! Du simple HTML et CSS ? C'est bon aussi. Tailwind ? Bootstrap ? Material UI ? Comme vous voulez.

NativePHP n'est pas une nouvelle version personnalisée de PHP. C'est le bon vieux PHP que vous connaissez et aimez.

PHP et les technologies Web sont-ils adaptés pour développer de bonnes applications de bureau ?

Comme avec Electron, NativePHP veut permettre aux développeurs de créer des applications desktop natives multiplateformes avec les technologies Web. Mais cette approche est-elle adaptée pour le développement d'applications de bureau performantes et vraiment natives ?

Rappelons ici les critiques relatives au développement d'applications de bureau avec Electron.

« Si vous ne connaissez pas Electron, il s'agit essentiellement d'un navigateur Web (Chromium) qui héberge seulement votre application Web... comme s'il s'agissait d'une application de bureau », disait Renato Athaydes, un développeur logiciel travaillant dans une entreprise technologique privée. « Si les gens préfèrent livrer un navigateur Web complet avec leurs applications afin qu'ils puissent utiliser d'excellents outils tels que JavaScript pour les développer, il y a vraiment quelque chose qui ne va pas. »

Ainsi, indépendamment de la question de savoir si la pile de technologies Web est bonne pour les applications de bureau, l'un des points qui dérangent le plus à propos d'Electron est qu'il va empaqueter un runtime Web complet dans chaque application, même si un runtime convenable existe déjà sur le système d'exploitation. Chromium comprend plus de 20 millions de lignes de code et il semble que chaque application Electron va empaqueter une copie de cette énorme base de code sous forme de binaire. Ce qui aura pour conséquence de grossir la taille de votre application et créer un gaspillage de mémoire.

Le framework NativePHP utilisant l'environnement Electron pour la création et l'empaquetage d'applications, il pourrait hériter aussi de ces inconvénients. Mais si cela n'a pas empêché Electron d'être populaire aujourd'hui, le framework NativePHP peut-il aussi avoir du succès avec les fonctionnalités annoncées ?

Source : NativePHP

Et vous ?

Avec les fonctionnalités annoncées, pensez-vous NativePHP est un framework prometteur ?
PHP et les technologies Web sont-ils adaptés pour développer de bonnes applications de bureau vraiment natives ?

Voir aussi

Un rapport révèle que la plupart des déploiements de PHP utilisent des versions qui ne sont plus prises en charge, 61,9 % des répondants utilisent encore des versions de PHP en fin de vie

PHP 8.2 est disponible et s'accompagne des propriétés "en lecture seule" aux classes ainsi que la possibilité de déprécier les propriétés dynamiques

Faut-il utiliser Electron pour le développement d'applications de bureau ? Quels sont ses avantages et inconvénients ?

[clavier12AZQSWX]

je me demande ce que cet outils aura de "mieux" qu'un basic xamp/wamp/lamp installé où l'on est pas limité à un framework...

[grunk]

je me demande ce que cet outils aura de "mieux" qu'un basic xamp/wamp/lamp installé où l'on est pas limité à un framework...

Une solution xamp ou wamp quand tu l'installe sur un poste d'utilisateur , tu as toujours la possibilité d'un service qui démarre pas, d'un petit rigolo qui te modifie un fichier, etc ...
Avec ce genre d'application tu n'as plus ces problématique et tu fais croire que c'est une vraie application puisque tu n'as pas de navigateur à lancer.
C'est limité à Laravel pour le moment mais clairement ils veulent s'ouvrir.

Il existe des tas de solution similaires (php gtk , php-qt, wxphp) et elles ont globalement toute en commun de n'intéresser pas grand monde car forcément à un moment on se heurte a des limitation techniques.

On va dire que c'est pratique quand tu as une appli web que tu veux transformer en desktop à moindre coût pour une raison X, mais la tendance est quand même plutôt à l'inverse.

Le seul vrai intérêt c'est la rapidité/facilité de création des UI en html/css qu'aucune solution native n'a jamais réussi à égaler à mon gout.

[Invité]

Maintenir le code PHP legacy/spaghetti d'une app web n'est-il pas suffisamment dissuasif? Non, il faut en rajouter une couche avec des applications desktop "natives"... quelle horreur. Sérieusement, j'espère que ce château de sable n'ira pas plus loin qu'une version alpha.

[grunk]

Maintenir le code PHP legacy/spaghetti d'une app web

Ca fait 15 ans que t'as pas fait de web non ?

[Eric30]

Ca fait 15 ans que t'as pas fait de web non ?

Non. Ça fait surtout 15 ans qu'il n'a pas du faire de PHP.
Ou alors il est resté sur la version PHP5 d'il y a 15 ans.
Ou encore il ne bosse qu'avec des applications développées en PHP il y a 15 ans.

Je trolle, mais c'est un classique quand on parle de PHP.
Tu as toujours quelqu'un qui parce qu'il en a fait un peu il y a 15 ans ou qui bosse sur un projet vieux de 15 ans ou fait par un ado de 15 ans (je trolle encore) qui a du coup une mauvaise expérience et considère ce langage comme pourri.
Débat sans fin.

[clavier12AZQSWX]

On va dire que c'est pratique quand tu as une appli web que tu veux transformer en desktop à moindre coût pour une raison X, mais la tendance est quand même plutôt à l'inverse.

le jour où j'ai voulu "founir" une appli lamp à un tiers, j'ai fait une VM minimaliste avec une gui qui lançait le browser au démarrage. ça restait "keep it simple" pour la maintenance (modification,deploiement,configuration, formation).

àprès 20ans de php, je me méfie bcp des "nouvelles " solutions de framework php : le framework n'a pas 15ans d'age, il ne vaut plus le coup de s'investir (je pense surtout au temps humain de formation et de passage-transisation de relai pour la re-formation par un collègue).

[Invité]

NativePHP connaît un succès fulgurant à travers le monde en permettant aux développeurs PHP de créer de véritables applications natives multiplateformes en utilisant les outils et les technologies qu'ils connaissent déjà : HTML, CSS, JavaScript et bien sûr, PHP.

Il est indiqué sur le site officiel que ce truc est en version alpha et ne doit pas être utilisé en production.

De là au "succès fulgurant à travers le monde permettant aux développeur PHP de créer de véritable applications natives multiplateformes", il n'y a qu'un pas ...

[Invité]

Ca fait 15 ans que t'as pas fait de web non ?

J'en ai surtout marre de devoir maintenir des "applications" PHP obsolètes de 5, 10 ou 15 ans parce que des pseudo-autodidactes et autre ingénieurs ratés ont écrit et entassé du code pourri pendant des années, en mélangeant des paradigmes, des conventions, des versions et extensions PHP qui ne sont plus maintenues, des extensions PEAR douteuses, des bibliothèques récupérées sur composer et maintenue par 1 seul gars qui voulait faire parler lui, bonjour la gestion des dépendances... sans oublier le "hacking" des frameworks et ORM parce qu'ils ne comprennent pas les design pattern ou guidelines élémentaires qui les régissent...ou sont juste trop paisseaux pour les mettre en oeuvre.

Sérieusement, pour implémenter un online shop qui se connecte à une base de données et consomme une API pour les paiements, PHP c'est très bien. Pour faire quelque chose d'un peu plus accueillant qu'un script bash en administration système, ça passe aussi. Mais pour tout le reste, c'est choisir d'investir à fonds perdus et l'assurance d'une dette technique dans les 18 mois suivant le passage en production...

[chrtophe]

Il est indiqué sur le site officiel que ce truc est en version alpha et ne doit pas être utilisé en production.

De là au "succès fulgurant à travers le monde permettant aux développeur PHP de créer de véritable applications natives multiplateformes", il n'y a qu'un pas

C'est sûr qu'en cassant du sucre sur le truc, il va prendre de l'ampleur.

PHP n'est pas forcément le langage le plus adapté pour faire des applis Desktop, il n'a pas été conçu pour ça à la base mais il peut le faire. Exemple php-gtk qui lui n'est pas en Alpha.

Après ça reste de l'interprété (sans tenir compte de la compilation à la volée en bytecode).

D'un autre coté, si un projet est codé avec les pieds, ce n'est pas le langage qui est en cause. Utiliser un langage inadapté ne va pas aider non plus. Pour moi php n'est pas forcément le langage le plus adapté pour faire une appli Desktop, mais ça ne veut pas dire que c'est inadapté.

[Invité]

Non. Ça fait surtout 15 ans qu'il n'a pas du faire de PHP.
Ou alors il est resté sur la version PHP5 d'il y a 15 ans.
Ou encore il ne bosse qu'avec des applications développées en PHP il y a 15 ans.

Je trolle, mais c'est un classique quand on parle de PHP.
Tu as toujours quelqu'un qui parce qu'il en a fait un peu il y a 15 ans ou qui bosse sur un projet vieux de 15 ans ou fait par un ado de 15 ans (je trolle encore) qui a du coup une mauvaise expérience et considère ce langage comme pourri.
Débat sans fin.

Je pense que tu devrais te confronter à la réalité du terrain, à des applications complexes, à la haute disponibilité, en tant que développeur et chef de projet... Coder des sites web et CMS en PHP dans son coin, même un gamin de 12 ans peut le faire.

Par ailleurs, je ne considère pas le langage comme étant pourri, c'est plutôt la manière dont il est utilisé et sa granularité qui posent problème.

Et plutôt que de faire des commentaires creux, tu devrais fournir quelques arguments en faveur de PHP puisque tu aimes ce langage. Je sens que ça va être très drôle...

C'est sûr qu'en cassant du sucre sur le truc, il va prendre de l'ampleur.

PHP n'est pas forcément le langage le plus adapté pour faire des applis Desktop, il n'a pas été conçu pour ça à la base mais il peut le faire. Exemple php-gtk qui lui n'est pas en Alpha.

Après ça reste de l'interprété (sans tenir compte de la compilation à la volée en bytecode).

D'un autre coté, si un projet est codé avec les pieds, ce n'est pas le langage qui est en cause. Utiliser un langage inadapté ne va pas aider non plus. Pour moi php n'est pas forcément le langage le plus adapté pour faire une appli Desktop, mais ça ne veut pas dire que c'est inadapté.

Je ne casse pas du sucre, j'ai simplement mis côte-à-côte les envolées lyriques et la réalité des faits. Il s'agit d'une produit en version alpha, il devrait être présenté comme tel. En plus, ils parlent d'un framework mais pour l'instant c'est surtout un wrapper dépendant de Lavarel... les grandes ambitions aiment l'humilité.

En outre, je serais curieux de connaître le nombre de projets ayant utilisé avec succès PHP-GTK au cours des 15 dernières années...

En conclusion, PHP n'a jamais été conçu pour faire du desktop. Ce n'était pas l'ambition de son créateur, et ce n'est pas l'ambition de ses mainteneurs. Il existes de nombreux autres langages éprouvés et adaptés au desktop. Pour moi, NativePHP est surtout l'initiative de 2 développeurs qui par ego démesuré ou non souhaitent enjoliver leur CV avec un projet "ambitieux". Ce projet n'a visiblement aucune chance d'aboutir, si ce n'est au-près d'une petite niche de développeurs.

[pokap]

Je n'ai pas trouvé l'information sur le site sur la machine virtuelle php. J'imagine qu'elle est embarqué avec l'app ? comme c'est le cas pour le navigateur web.
Mais du coup y a un serveur http interne ou il y a process CGI spécifique ?

En tout cas c'est un projet intéressant et assez dense aussi, il y avait déjà eu il y a très longtemps une tentative de php dekstop mais c'était pas foufou.

Vivement que ça supporte autre chose que Laravel parce que personnellement je n'aime pas ce framework.

[NukaCola]

Maintenir le code PHP legacy/spaghetti d'une app web n'est-il pas suffisamment dissuasif? Non, il faut en rajouter une couche avec des applications desktop "natives"... quelle horreur. Sérieusement, j'espère que ce château de sable n'ira pas plus loin qu'une version alpha.

J'en ai surtout marre de devoir maintenir des "applications" PHP obsolètes de 5, 10 ou 15 ans parce que des pseudo-autodidactes et autre ingénieurs ratés ont écrit et entassé du code pourri pendant des années, en mélangeant des paradigmes, des conventions, des versions et extensions PHP qui ne sont plus maintenues, des extensions PEAR douteuses, des bibliothèques récupérées sur composer et maintenue par 1 seul gars qui voulait faire parler lui.

Je pense que tu devrais te confronter à la réalité du terrain, à des applications complexes, à la haute disponibilité, en tant que développeur et chef de projet... Coder des sites web et CMS en PHP dans son coin, même un gamin de 12 ans peut le faire.

Pour moi, NativePHP est surtout l'initiative de 2 développeurs qui par ego démesuré ou non souhaitent enjoliver leur CV avec un projet "ambitieux". Ce projet n'a visiblement aucune chance d'aboutir, si ce n'est au-près d'une petite niche de développeurs.

Oui tu as raison, c'est bien mieux de ne jamais rien proposer, de ne jamais rien essayer, de ne jamais innover, et de venir chier sur le langage, les développeurs ratés qui l'utilisent, les gens qui te répondent, une alpha d'un projet, et les développeurs derrière à "l'égo démesuré".

[chrtophe]

Il s'agit d'une produit en version alpha, il devrait être présenté comme tel.

Lis au moins complètement l'actu : c'est le cas :

Actuellement en phase alpha, NativePHP est un nouveau framework...

et le site d'origine le précise avec un warning.

[Invité]

Oui tu as raison, c'est bien mieux de ne jamais rien proposer, de ne jamais rien essayer, de ne jamais innover, et de venir chier sur le langage, les développeurs ratés qui l'utilisent, les gens qui te répondent, une alpha d'un projet, et les développeurs derrière à "l'égo démesuré".

J'ai parlé d'égo demesuré en réponse à la citation suivante:

NativePHP connaît un succès fulgurant à travers le monde en permettant aux développeurs PHP de créer de véritables applications natives multiplateformes en utilisant les outils et les technologies qu'ils connaissent déjà : HTML, CSS, JavaScript et bien sûr, PHP.

Je ne m'en prends pas gratuitement à ce projet ni à ses développeurs. C'est eux qui sèment le vent avec ce genre de déclarations arrogantes et dénuées de sense.

Quant aux développeurs "ratés", c'est le même principe. En Suisse, les développeurs Web (PHP) sont payés en moyenne entre 5000 et 6000 euros par mois. Désolé mais avec un tel salaire, je n'ai pas vraiment de pitié pour les génies incompris, les one-liners et ceux qui produisent du code qui trois mois ou trois ans plus tard coûtera un rein et quelques burnout à déboguer.

Enfin, il ne s'agit pas de ne "rien proposer" ou de ne rien "essayer". Et encore moins de ne pas innover. Seulement la vie est courte et au lieu de faire des châteaux de sable dans son coin en attendant la pluie, il est préférable de mettre à profit ses compétences dans des projets open source existants, dont l'utilité et la viabilité sont démontrées.

[NukaCola]

J'ai parlé d'égo demesuré en réponse à la citation suivante:



Je ne m'en prends pas gratuitement à ce projet ni à ses développeurs. C'est eux qui sèment le vent avec ce genre de déclarations arrogantes et dénuées de sense.

D'accord donc quand tu vas sur cette page https://nativephp.com/docs/1/getting...d/introduction, ta première réaction à sa lecture est "Ils sont arrogants et sèment le vent" ? J'ai envie de dire pourquoi pas, je respecte l'opinion de chacun, à titre personnel j'ai vu bien pire dans le monde de l'informatique, à la télé, ou juste dans la vie de tous les jours mais très bien.

Quant aux développeurs "ratés", c'est le même principe. En Suisse, les développeurs Web (PHP) sont payés en moyenne entre 5000 et 6000 euros par mois. Désolé mais avec un tel salaire, je n'ai pas vraiment de pitié pour les génies incompris, les one-liners et ceux qui produisent du code qui trois mois ou trois ans plus tard coûtera un rein et quelques burnout à déboguer.

Quel rapport avec le sujet ? Et je ne savais pas que les autres langages avaient une option qui empêchaient de faire du code sale, sans design pattern, sans architecture, sans doc, et non maintenable avec de la dette technique.

Enfin, il ne s'agit pas de ne "rien proposer" ou de ne rien "essayer". Et encore moins de ne pas innover. Seulement la vie est courte et au lieu de faire des châteaux de sable dans son coin en attendant la pluie, il est préférable de mettre à profit ses compétences dans des projets open source existants, dont l'utilité et la viabilité sont démontrées.

D'accord donc si le modèle de gouvernance du langage/framework/projet open source utile et viable rejette tes idées, ça sert à rien d'en faire un fork ?
Ou encore un projet comme Laravel, "fork" de Symfony (open source), c'est un château de sable qui attend la pluie ?
Car vu que dans l'informatique y'a pas mal de fork qui ont dépassé le maître, ou des projets qui se basent très largement sur d'autres, c'est pour savoir à quel moment ça devient un château de sable ?


Et même si ça en été un, comme tu le dis si bien, la vie est courte. Si on pouvait encore faire ce qu'on veut dans notre coin sans qu'un quidam vienne pour dire qu'idéalement il faudrait faire autre chose de mieux ça serait top. Et n'oublie pas qu'en répondant à ce message, tu aurais pu mettre ce temps là pour mettre à profit tes compétences dans des projets open source existants à la place.

[Madmac]

je me demande ce que cet outils aura de "mieux" qu'un basic xamp/wamp/lamp installé où l'on est pas limité à un framework...

Ruby avec Sinatra. Ruby vient avec un serveur intégré. Ce qui fait que l'on n'a pas à installer un serveur. Vous lancer l'appli en Sinatra. Et le serveur se lancera automatiquement.

Et J'oubliais OpenSuse a un GUI utilisant Ruby pour des applications de ce genre.


Sauter directement à 2 minutes

Et pour ceux qui ne sont pas au courant. Il est possible de produire de véritable exécutable avec mRuby. https://mruby.org/docs/articles/exec...ith-mruby.html

ou fait des applis en webassembly: https://semaphoreci.com/blog/ruby-webassembly

[Eric30]

J'en ai surtout marre de devoir maintenir des "applications" PHP obsolètes de 5, 10 ou 15 ans parce que des pseudo-autodidactes et autre ingénieurs ratés ont écrit et entassé du code pourri pendant des années, en mélangeant des paradigmes, des conventions, des versions et extensions PHP qui ne sont plus maintenues, des extensions PEAR douteuses, des bibliothèques récupérées sur composer et maintenue par 1 seul gars qui voulait faire parler lui, bonjour la gestion des dépendances... sans oublier le "hacking" des frameworks et ORM parce qu'ils ne comprennent pas les design pattern ou guidelines élémentaires qui les régissent...ou sont juste trop paisseaux pour les mettre en oeuvre.

Sérieusement, pour implémenter un online shop qui se connecte à une base de données et consomme une API pour les paiements, PHP c'est très bien. Pour faire quelque chose d'un peu plus accueillant qu'un script bash en administration système, ça passe aussi. Mais pour tout le reste, c'est choisir d'investir à fonds perdus et l'assurance d'une dette technique dans les 18 mois suivant le passage en production...

Merci. Ta réponse est exactement du même acabit que celles que l'on lit d'habitude : tout ce que tu évoques n'est pas lié à PHP mais aux personnes et aux projets. Étonnant que tu ne sois pas capable de t'en rendre compte.

Pareil. La dette technique et les mauvais choix, ce n'est pas PHP.

Les projets mal gérés, la dette technique, les "autodidactes", les paresseux, le turnover... tu trouves ça en Python, en Java, en ce que tu veux...

Je connais des sites et apps écrits en PHP qui tournent sur des versions régulièrement mises à jour et bien suivies depuis 10 ans.
À l'inverse, lors d'une de mes expériences en ESN, j'ai eu à intervenir des projets écrits en Java dont je savais qu'ils étaient déjà pourris avant même leur MEP car les compétences n'étaient pas là.
Autre exemple : en ce moment je bosse parfois avec une équipe qui bosse sur un projet écrit en C++.
Le projet a 4 ans : code spaghetti et dette technique sont déjà bien présents.

[Invité]

D'accord donc quand tu vas sur cette page https://nativephp.com/docs/1/getting...d/introduction, ta première réaction à sa lecture est "Ils sont arrogants et sèment le vent" ? J'ai envie de dire pourquoi pas, je respecte l'opinion de chacun, à titre personnel j'ai vu bien pire dans le monde de l'informatique, à la télé, ou juste dans la vie de tous les jours mais très bien.

Dans cet article il est dit:

NativePHP connaît un succès fulgurant à travers le monde en permettant aux développeurs PHP de créer de véritables applications natives multiplateformes en utilisant les outils et les technologies qu'ils connaissent déjà : HTML, CSS, JavaScript et bien sûr, PHP.

Sur le site officiel il est dit:

NativePHP is currently an alpha release and is not ready for production applications yet.

Autrement dit, le projet est en version alpha et n'est visiblement pas recommandé pour un usage en production, en plus il est dépendant de Lavarel. Parler d'un succès mondial fulgurant est arrogant.

Quel rapport avec le sujet ? Et je ne savais pas que les autres langages avaient une option qui empêchaient de faire du code sale, sans design pattern, sans architecture, sans doc, et non maintenable avec de la dette technique.

Le rapport, c'est PHP. La manière dont il est utilisé et implémenté par des développeurs (parfois grassement payés) et ses débouchées à moyen et long terme dans un projet d'envergure.

Car vu que dans l'informatique y'a pas mal de fork qui ont dépassé le maître, ou des projets qui se basent très largement sur d'autres, c'est pour savoir à quel moment ça devient un château de sable ?

Tu peux me citer 3 exemples s'il te plait ?

même si ça en été un, comme tu le dis si bien, la vie est courte. Si on pouvait encore faire ce qu'on veut dans notre coin sans qu'un quidam vienne pour dire qu'idéalement il faudrait faire autre chose de mieux ça serait top.

Tu fais ce que tu veux de tes journées et de ta vie, mais à partir du moment où tu les exposes dans un espace public, la liberté d'expression est garantie.

Et n'oublie pas qu'en répondant à ce message, tu aurais pu mettre ce temps là pour mettre à profit tes compétences dans des projets open source existants à la place.

Je n'oublie pas. J'ai même le privilège d'être payé pour ça. Par contre bosser, même gratuitement, sur un projet qui n'est pas viable et qui va être utilisé par une niche de développeurs têtus, j'ai passé l'âge...

[NukaCola]

• La citation que tu rasasses en boucle est tirée de la page que j'ai mis plus haut, en dessous du gros encart disant que c'est en Alpha.
• Encore une fois, PHP ne produit pas magiquement du code spaghetti, et à l'inverse, les autres langages ne l'évitent pas magiquement.
• Laravel, Nodejs, PyTorch pour citer des frameworks/bibliothèque, Nextcloud, caddy, nginx, mariadb, php fpm/pm pour citer autres choses.

Et sur ce je vais te laisser exercer ton droit à la liberté d'expression seul, atteindre le fond du caniveau ne m'intéressant pas, j'ai bien compris ton point de vue/état d'esprit.