Tout dépend de ce qu'on appelle un framework ?
Je constate plutôt l'inverse de ce que tu décrits, un gros framework (genre RoR ou Django) rend de plus en plus difficile toute évolution car il y a trop d'effet de bords et de surcouches à maintenir. En revanche un framework minimaliste comme Pyramid permet de faire évoluer un code dans n'importe quelle direction beaucoup plus facilement et surtout sans avoir à tout réécrire. Combien de projets on voit partis de RoR ou Django être réécrits entièrement car arrivés à une impasse ? On accuse bien trop souvent le langage alors que le problème vient du framework à mon avis.
Un critère que je trouve pertinent est de pouvoir conserver un même code d'un framework à l'autre. C'est ce que j'ai pu faire sur des applis qui datent de plus de dix ans et que je fais évoluer au fil de l'eau justement par ce que je n'ai jamais utilisé de gros framework. C'est aussi ce qui me permet de réécrire une partie en Go sans avoir à toucher à l'architecture ni à abandonner et réécrire ce qui peut très bien rester en Python.
J'aime bien Go pour ce même aspect minimaliste qu'on retrouvait au début en Python et qui a hélas été un peu perdu. Cet aspect me semble justement primordial pour la maintenance sur le long terme.
[^] # Re: Go
Posté par wilk (site web personnel, Mastodon) . En réponse au journal Et si JavaScript allait droit dans le mur ?. Évalué à 9.
Tout dépend de ce qu'on appelle un framework ?
Je constate plutôt l'inverse de ce que tu décrits, un gros framework (genre RoR ou Django) rend de plus en plus difficile toute évolution car il y a trop d'effet de bords et de surcouches à maintenir. En revanche un framework minimaliste comme Pyramid permet de faire évoluer un code dans n'importe quelle direction beaucoup plus facilement et surtout sans avoir à tout réécrire. Combien de projets on voit partis de RoR ou Django être réécrits entièrement car arrivés à une impasse ? On accuse bien trop souvent le langage alors que le problème vient du framework à mon avis.
Un critère que je trouve pertinent est de pouvoir conserver un même code d'un framework à l'autre. C'est ce que j'ai pu faire sur des applis qui datent de plus de dix ans et que je fais évoluer au fil de l'eau justement par ce que je n'ai jamais utilisé de gros framework. C'est aussi ce qui me permet de réécrire une partie en Go sans avoir à toucher à l'architecture ni à abandonner et réécrire ce qui peut très bien rester en Python.
J'aime bien Go pour ce même aspect minimaliste qu'on retrouvait au début en Python et qui a hélas été un peu perdu. Cet aspect me semble justement primordial pour la maintenance sur le long terme.