C’est aussi une bonne nouvelle pour Firefox.
Sans les financements de Google, versés pour donner au moins l’apparence que ce n’est pas exclusif, Mozilla s’effondrerait immédiatement.
S’ils perdent Chrome, il n’y aura plus de raison de les verser.
Il ne s’agit pas d’avoir piraté les communications, mais d’avoir piraté la passerelle.
Comme les serveurs du jeu augmentent ou diminuent selon la charge,
c’est la passerelle qui indique à la connexion à quel serveur se connecter.
De nos jours, on peut obtenir gratuitement des certificats TLS, donc on peut aussi mettre en place HTTPS de manière sûre, non ?
L’idée est sans doute que la passerelle compromise pointe vers un mauvais serveur, et que ce serveur intercepte toutes les données pour mener une attaque MITM.
Ce qui est dit dans les avis Hacker News ci-dessous est tout à fait juste.
« Next.js comporte une énorme couche d’abstraction dont 99,9999 % des projets n’ont pas besoin ; et dans les rares cas où quelque chose comme ça est réellement nécessaire, je pense qu’il vaut mieux construire une solution sur mesure à partir de composants de plus bas niveau »
Une API inutilement et excessivement complexe, un produit instable et incomplet qu’on continue pourtant à promouvoir obstinément comme production ready, et une dépendance énorme à Vercel qui rend l’exploitation sérieuse difficile ailleurs que sur Vercel.
C’est peut-être parce que j’ai commencé ma carrière dans le web, mais le web — surtout le front — se développe à l’origine avec ce petit goût-là (rires)
Ce goût du changement permanent...
Le côté JS donne un peu cette impression. Il y a tout un tas de choses censées être bien, mais chacune a un peu ses problèmes, et ça change très vite au gré des modes...
C’est peut-être aussi parce que j’ai surtout travaillé avec Java, EJB et Struts, donc c’est comme ça que je le ressens.
En surface, le nombre de lignes de code (LOC) compte aussi. Du point de vue de la productivité, lire et comprendre une page entière n’est pas la même chose que lire et comprendre 3 lignes.
Bien sûr, moi aussi j’utilise .asyncio jusqu’à saturation en production, mais je ne suis pas assez satisfait de l’expérience actuelle pour dire que « je l’utilise bien ».
L’asyncio actuel est conçu en partant du principe du GIL et constitue, d’une certaine manière, une stratégie pour le contourner, donc le GIL n’interagit pas directement avec asyncio.
Mais si l’on considère l’ensemble de la programmation concurrente fondée sur asyncio, je pense qu’affirmer que le GIL n’a aucun rapport revient à dire quelque chose comme : « C’est Python, donc c’est normal que ça ne marche pas. »
Je suis d’accord sur le fait qu’on ne peut pas s’attendre à ce que l’orientation actuelle autour du GIL soit à la hauteur des « autres alternatives ».
Mais dire qu’il faut adopter d’autres alternatives que Python ne devrait-il pas conduire non pas à soutenir qu’il n’y a pas de problème, mais au contraire à reconnaître qu’il y a bien un problème ?
Cette fois, j’ai essayé le développement web par simple intérêt personnel, un domaine qui n’a absolument rien à voir avec celui dans lequel je développais à l’origine. J’ai créé un forum avec le app router de next.js v15… mais à chaque fois que je vois ce genre de post, j’ai l’impression que ça me coupe toute envie de tenter quelque chose de nouveau côté web. Pourquoi l’écosystème est-il si instable ? Et puis quoi, si un nouveau truc sort, tout le monde va encore se ruer dessus, l’utiliser un peu, le critiquer, puis repartir chercher autre chose ? Le développement web a vraiment l’air difficile.
Le pouvoir et l’argent sont certes les moteurs qui font avancer un projet.
Mais il est difficile de ne pas pousser un soupir à chaque fois qu’on voit une page web qui ne fonctionne pas correctement sans Chromium.
Honnêtement... Il n’y a probablement que Google qui soit capable de maintenir Chrome à ce niveau. En plus, même si ce n’est pas au niveau des semi-conducteurs, la domination du marché des navigateurs web est aussi un domaine que les États-Unis ne veulent pas lâcher.... J’ai l’impression qu’un certain degré de monopole continuera d’être toléré à l’avenir.
Ce n’est pas clairement indiqué dans le texte, mais cela pourrait-il vouloir dire que, lorsqu’on écrit du code avec l’IA, il devient une dette parce qu’il est moins familier pour les humains que du code écrit directement par eux-mêmes ?
Tiens, moi aussi j’étais un utilisateur payant haha
En regardant l’historique de l’App Store, je vois que c’est devenu gratuit à partir de la version 1.51.
Pour moi, c’est un outil indispensable, car les réglages d’écran de mon MacBook changent selon l’endroit où je l’utilise.
C’est aussi une bonne nouvelle pour Firefox.
Sans les financements de Google, versés pour donner au moins l’apparence que ce n’est pas exclusif, Mozilla s’effondrerait immédiatement.
S’ils perdent Chrome, il n’y aura plus de raison de les verser.
On dirait qu’ils n’ont toujours pas réalisé que React nuit à la productivité.
Même si le code est très long, ce n’est pas une dette si l’on peut facilement expliquer « ce qu’il fait ».
On dit que l’usage indiscriminé de l’IA crée de la dette, parce qu’il rend cela difficile.
Il ne s’agit pas d’avoir piraté les communications, mais d’avoir piraté la passerelle.
Comme les serveurs du jeu augmentent ou diminuent selon la charge,
c’est la passerelle qui indique à la connexion à quel serveur se connecter.
De nos jours, on peut obtenir gratuitement des certificats TLS, donc on peut aussi mettre en place HTTPS de manière sûre, non ?
L’idée est sans doute que la passerelle compromise pointe vers un mauvais serveur, et que ce serveur intercepte toutes les données pour mener une attaque MITM.
Ce qui est dit dans les avis Hacker News ci-dessous est tout à fait juste.
« Next.js comporte une énorme couche d’abstraction dont 99,9999 % des projets n’ont pas besoin ; et dans les rares cas où quelque chose comme ça est réellement nécessaire, je pense qu’il vaut mieux construire une solution sur mesure à partir de composants de plus bas niveau »
Une API inutilement et excessivement complexe, un produit instable et incomplet qu’on continue pourtant à promouvoir obstinément comme production ready, et une dépendance énorme à Vercel qui rend l’exploitation sérieuse difficile ailleurs que sur Vercel.
C’est peut-être parce que j’ai commencé ma carrière dans le web, mais le web — surtout le front — se développe à l’origine avec ce petit goût-là (rires)
Ce goût du changement permanent...
Le côté JS donne un peu cette impression. Il y a tout un tas de choses censées être bien, mais chacune a un peu ses problèmes, et ça change très vite au gré des modes...
C’est peut-être aussi parce que j’ai surtout travaillé avec Java, EJB et Struts, donc c’est comme ça que je le ressens.
Merci.
https://github.com/kelseyhightower/nocode
En surface, le nombre de lignes de code (LOC) compte aussi. Du point de vue de la productivité, lire et comprendre une page entière n’est pas la même chose que lire et comprendre 3 lignes.
Bien sûr, moi aussi j’utilise
.asynciojusqu’à saturation en production, mais je ne suis pas assez satisfait de l’expérience actuelle pour dire que « je l’utilise bien ».L’
asyncioactuel est conçu en partant du principe du GIL et constitue, d’une certaine manière, une stratégie pour le contourner, donc le GIL n’interagit pas directement avecasyncio.Mais si l’on considère l’ensemble de la programmation concurrente fondée sur
asyncio, je pense qu’affirmer que le GIL n’a aucun rapport revient à dire quelque chose comme : « C’est Python, donc c’est normal que ça ne marche pas. »Je suis d’accord sur le fait qu’on ne peut pas s’attendre à ce que l’orientation actuelle autour du GIL soit à la hauteur des « autres alternatives ».
Mais dire qu’il faut adopter d’autres alternatives que Python ne devrait-il pas conduire non pas à soutenir qu’il n’y a pas de problème, mais au contraire à reconnaître qu’il y a bien un problème ?
Cette fois, j’ai essayé le développement web par simple intérêt personnel, un domaine qui n’a absolument rien à voir avec celui dans lequel je développais à l’origine. J’ai créé un forum avec le
app routerde next.js v15… mais à chaque fois que je vois ce genre de post, j’ai l’impression que ça me coupe toute envie de tenter quelque chose de nouveau côté web. Pourquoi l’écosystème est-il si instable ? Et puis quoi, si un nouveau truc sort, tout le monde va encore se ruer dessus, l’utiliser un peu, le critiquer, puis repartir chercher autre chose ? Le développement web a vraiment l’air difficile.Le pouvoir et l’argent sont certes les moteurs qui font avancer un projet.
Mais il est difficile de ne pas pousser un soupir à chaque fois qu’on voit une page web qui ne fonctionne pas correctement sans Chromium.
Honnêtement... Il n’y a probablement que Google qui soit capable de maintenir Chrome à ce niveau. En plus, même si ce n’est pas au niveau des semi-conducteurs, la domination du marché des navigateurs web est aussi un domaine que les États-Unis ne veulent pas lâcher.... J’ai l’impression qu’un certain degré de monopole continuera d’être toléré à l’avenir.
Je confirme tardivement.
Merci pour votre réponse si attentionnée !
Même si l’on ressent de l’inconfort, on s’y habitue vite à force de l’utiliser, non ?
L’être humain est un animal d’adaptation.
Ce n’est pas clairement indiqué dans le texte, mais cela pourrait-il vouloir dire que, lorsqu’on écrit du code avec l’IA, il devient une dette parce qu’il est moins familier pour les humains que du code écrit directement par eux-mêmes ?
Tiens, moi aussi j’étais un utilisateur payant haha
En regardant l’historique de l’App Store, je vois que c’est devenu gratuit à partir de la version 1.51.
Pour moi, c’est un outil indispensable, car les réglages d’écran de mon MacBook changent selon l’endroit où je l’utilise.