• [^] # Re: C'était mieux avant

    Posté par . En réponse au journal Installer un serveur Firefox Accounts et Firefox Sync. Évalué à 4.

    Tu te rends compte que pour exposer ce service REST, je dois me manger git/node/bower et pour chacun d'eux peut-être des dépendances supplémentaires qu'il va falloir que je gère sur le long terme

    Tout ça n’a rien à voir avec PHP vs node. Tu peux très bien faire un .tar d’une appli node, tout comme tu peux déployer une appli PHP avec git+composer (et pour info, bower a encore moins à voir avec la choucroute, c’est pour le frontend, et c’est aussi utilisé dans des projets faits en PHP). Faudra m’expliquer la différence fondamentale entre https://github.com/symfony/symfony/blob/master/composer.json et https://github.com/expressjs/express/blob/master/package.json pour appeler l’un usine à gaz et pas l’autre.

    Ce dont tu te plains c’est jusque que les devs d’applications node s’embêtent plus rarement que les devs d’application PHP à fournir une archive prépackagée. Alors je peux comprendre que ce soit légèrement irritant pour certains (perso j’ai du mal à voir en quoi git clone && npm install est tellement plus pénible que tar xzf, mais admettons...), mais de là à en faire un point bloquant, ça me dépasse...

    Au passage, je ne vois pas le rapport entre réinventer la roue et les trous de sécurité.

    Tu vois sincèrement pas en quoi un projet qui utilise un ORM connu et largement testé comme Doctrine aura beaucoup moins de chances d’avoir des SQL injections qu’un projet qui décide de faire toutes ses requêtes SQL à la main parce que « je veux pas embarquer 150.000 dépendances » ?

    De trous de sécurité, il y en a partout même sur une bibliothèque un peu utilisée.

    Je n’ai jamais prétendu que l’utilisation de librairie externes garantissait l’absence de failles.