La supercherie de lâuniversalitĂ© du web
đ«đ· â Mercredi 30 octobre 2024
Mots clés: #web, #internet, #navigateur, #ViePrivée, #merdification
Le web a Ă©tĂ© totalement travesti ces derniĂšres annĂ©es, voire dĂ©cennies. De plus en plus de merdification, de monopoles, de silotages et de nivellement par le bas. Quand j'Ă©tais gamin, je voyais le web â au sens large â comme quelque chose d'universel. J'ai Ă©crit mes premiĂšres lignes de code pour des pages web via le Site du ZĂ©ro. Je me rends compte qu'en l'Ă©tat actuel des choses, cette universalitĂ© est une supercherie, une fumisterie grotesque. Ce billet de blog a un gros cĂŽtĂ© âTeam Vieux Consâ, je prĂ©viens.
Comment c'Ă©tait "avant" ?
Apparemment il y a des gens qui aiment en mettre d'autres dans des cases, et je serais alors un millennial, un digital native ou un spĂ©cimen de la gĂ©nĂ©ration Y, en gros je suis nĂ© au dĂ©but des annĂ©es 1990. De fait, on ne parlait pas encore de âfracture numĂ©riqueâ, l'informatique domestique n'Ă©tait pas encore dĂ©mocratisĂ©e (pas autant qu'aujourd'hui), et quand on habitait en zone rurale l'ADSL n'Ă©tait pas encore mis en place, on avait droit Ă des dĂ©bits de 56kb/s au mieux avant qu'il n'arrive avec sa vingtaine de Mb/s. Bref, je n'ai pas connu la naissance de l'informatique, ni celle du web, je ne prĂ©tends pas la connaĂźtre non plus, mais j'ai vu les choses s'installer tranquillement.
Avant, du cÎté des navigateurs web, il y avait Netscape, Internet Explorer, et d'autres trucs aussi que je n'ai pas connus. Puis Opera, Firefox et Safari. Chrome ne sera arrivé que bien plus tard vers 2008. Edge n'existait pas, ni Brave, et on ne parlait pas de Chromium.
Les pages HTML Ă©taient simples. Moches selon les critĂšres de nos jours, mais se composaient de XHTML et de CSS ; le HTML 5 et le CSS 3 de mĂ©moire Ă©taient arrivĂ©s dans les annĂ©es 2010. Par contre, effectivement, pour certaines choses comme l'audio et la vidĂ©o, on avait du Silverlight et du Flash. En dehors de ça, on savait faire simple. On Ă©tait obligĂ©s de faire simple. Les dĂ©bits, toujours selon les critĂšres de nos jours, Ă©taient mĂ©diocres. Les ordinateurs parfois n'avaient pas plus de 2 ou 3 Go de RAM (et bien moins avant). Les pages HTML devaient ĂȘtre lĂ©gĂšres car sinon mettaient trop de temps Ă ĂȘtre chargĂ©es, et les dĂ©passements de forfaits Ă©taient trĂšs vite lourdement facturĂ©s. Pas de DRM, pas ou trĂšs peu de JavaScript (qu'on dĂ©sactivait Ă l'Ă©poque pour gagner du temps tout comme l'affichage des images), pas ou peu de publicitĂ© (mais vite arrivĂ©e en force ensuite), pas de tracking. Bref, du web documentaire que l'on pouvait considĂ©rer d'une certaine façon comme Ă©purĂ©, voire pur. Et plus tard, quand on voulait commencer Ă faire des pages ârĂ©activesâ, avec quelques requĂȘtes, on faisait du AJAX. Du JavaScript asynchrone, qui consommait du XML ou plus tard du JSON, et ce, au travers de XMLHttpRequest. On se contentait aussi des faire des requĂȘtes de formulaires simples, allant taper directement le serveur qui nous renvoyait ensuite tout ou partie de la page visitĂ©.
Les premiÚres bibliothÚques comme MooTools ou jQuery ont commencé à venir, et le merdier aussi.
Les technologies de développement
On a oubliĂ© de faire simple. Et on a cherchĂ© Ă tordre le HTML et le CSS dans tous les sens, Ă totalement travestir le truc. On est limitĂ©, cloitrĂ© au navigateur web, mais on va chercher Ă faire des sites web de plus en plus complexes, et mĂȘme des Progressive Web Apps.
Le JavaScript est devenu incontournable et indispensable, quand bien mĂȘme ce langage de programmation est exĂ©crable et trop permissif. Alors certains diront que l'on a TypeScript aussi, mais ça reste finalement la mĂȘme merde qui sera gĂ©nĂ©rĂ©e / transpilĂ©e et exploitĂ©e par la suite. On a juste changĂ© l'emballage.
On avait MooTools. Puis jQuery. On avait mĂȘme des applets Java. Et ensuite AngularJS. Puis Angular. Polymer aussi, qui aussi a rejoint AngularJS dans le Google graveyard, et Bootstrap. Et enfin ReactJS qui n'est plus maintenu au profit de React. Et on a mĂȘme Flutter qui s'y met. Certes, je mĂ©lange les torchons sales et les serviettes trouĂ©es, mais quand mĂȘme. Le but est le mĂȘme : faire des pages web affichĂ©es par son navigateur web. Mais on a voulu faire des ensembles de pages, qu'on appelle âsitesâ. Et on a voulu ajouter d'autres logiques dedans et parodier ou plagier gauchement les applications mobiles, en appelant ça âapplis webâ. Les pages sont de plus en plus complexes. Le DOM, que l'on pouvait facilement fouiller avant, finalement est remplacĂ© par le shadow DOM de plus en plus pĂ©nible Ă investiguer. On va avoir des Ă©vĂšnements JavaScript en pagaille, avec des chargements de pages ici ou lĂ , partiels ou non, et une tonne de fichiers JS que l'on va tirer depuis les pages via des CDN, sans mĂȘme forcĂ©ment s'assurer qu'ils n'aient pas Ă©tĂ© compromis. Des requĂȘtes rĂ©seaux en pagaille pour aller chercher des ressources devenues indispensables pour faire fonctionner des foutues pages web totalement travesties.
Avant, si on voulait travailler sur un projet web, ou a minima bricoler un truc, on s'en sortait trĂšs bien avec les bases du HTML et du CSS, voire du JavaScript. Maintenant, si on ne connait pas la derniĂšre stack Ă la mode, qui en plus va utiliser des prĂ©processeurs ou extensions CSS comme Sass ou Less, et le dernier framework du moment comme Vue.js ou Svelte ou un langage de programmation tout nouveau portĂ©e par la hype comme Elm, on ne s'en sort plus. Les technologies web dâaujourdâhui sont dĂ©jĂ du code legacy, pas besoin d'attendre demain pour les voir dĂ©prĂ©ciĂ©es et vite remplacĂ©es. Tout le monde lave plus blanc que blanc, mais au fond ça reste le trio HTML + CSS + JS. Ăa reste de la merde, seule la couleur change, pas l'odeur.
Pire encore, on augmente les surfaces d'attaque et les probabilitĂ©s d'avoir des problĂšmes en dĂ©pendant d'outils desquels on est devenu trop dĂ©pendant. Il a fallu un bad buzz pour que Facebook remplace la licence BSD+Patent de React pour passer Ă MIT. Avec Web Assembly on va injecter du code binaire dans les projets web, faisant que l'on pourra encore plus difficilement savoir ce qu'il s'y passe. Si on prend des outils clĂ©s en main comme WordPress, on se prend souvent des alertes Ă cause de plugins ayant des failles de sĂ©curitĂ©, sans parler du psychodrame actuel entre le fondateur de WordPress et WP Engine. Idem pour les usines Ă gaz que sont les CMS comme Drupal et PrestaShop avec de temps en temps des alertes critiques. On avait mĂȘme polyfill.js qui avait Ă©tĂ© compromis.
Et cĂŽtĂ© backend et au delĂ c'est pas glorieux. Node.js avec son API standard incapable nĂ©cessitant plĂ©thore de dĂ©pendances tierces plus Ă jour, sabotĂ©es ou sujettes Ă des failles de sĂ©curitĂ©, J2EE, Ruby on Rails, PHP et son PreHistoric Programming, Symfony, Laravel, Django, ASP.net, ... On a une tĂ©trachiĂ©e d'outils pour faire du backend et plus encore, et qui font plus ou moins la mĂȘme chose. Et certains organismes de formation sans scrupules iront former des jeunes ou des personnes en reconversion Ă l'arrache, vider leurs porte-monnaies, les formant sans sĂ©rieux, et les balancer sur le marchĂ© du travail dans des marchĂ©s saturĂ©s.
Certains ont tentĂ© de faire des applications mobiles web avec un OS dĂ©diĂ©, comme Firefox OS, mais le projet a capotĂ©. Peut-ĂȘtre pas pour un mal.
Si je prends une Ă©chelle de temps relative, forcĂ©ment plus courte mais tout de mĂȘme, du cĂŽtĂ© du dĂ©veloppement d'applications mobiles (natives j'entends, les seules qui vaillent Ă©videment), on a eu moins de changements et de risques de se crĂ©er de la dette technique. Du cĂŽtĂ© du dĂ©veloppement d'apps Android, on est juste passĂ© de Java Ă Kotlin, progressivement. Et Java a Ă©tĂ© officiellement destituĂ© que tout rĂ©cemment. MĂȘme chose pour iOS, on est passĂ© de Objective-C Ă Swift, mais en soit, l'ancien langage de programmation n'est pas dĂ©prĂ©ciĂ© pour autant. On garde UIKit et SwiftUI pour la dĂ©finition des interfaces graphiques, rien de dĂ©prĂ©ciĂ© lĂ aussi. Un peu moins vrai pour Android avec Jetpack Compose qui remplace les layouts XML. Bref, bien moins de changements structurants, de dettes techniques et d'outils dĂ©prĂ©ciĂ©s, car les choses sont davantage normalisĂ©es et lisibles. On n'a pas plusieurs crĂ©meries qui vont tenter de vendre leur beurre en tentant de planter les autres. Pour l'embarquĂ©, ça bouge encore moins. On a Qt, et c'est assez. Finalement personne n'a besoin d'un Ă©niĂšme framework qui refasse ce que les autres font, mais diffĂ©remment. Les tendances finiront par arriver, mais tranquillement et proprement. Bref, c'est moins le foutoir.
La merdification systématique
Je n'ai pas l'impression que le web ait beaucoup d'innovations qui vont dans le bon sens, Ă savoir celui du progrĂšs plutĂŽt que celui des intĂ©rĂȘts privĂ©s et capitalistes. Si on regarde Web Assembly, il y a de l'idĂ©e. Avoir un code source quelconque, en tirer un binaire, et balancer ça sur les navigateurs, ok. Toutefois, comment contrĂŽler ce qu'il s'y passe ? Comment s'assurer de la loyautĂ© de ce binaire ? On apporte de l'opacitĂ© Ă un environnement qui, avant, laissait l'utilisateur le bidouiller, fouiner dedans, et voir comment les choses Ă©taient foutues. MĂȘme chose pour le JavaScript, on en vient Ă intĂ©grer sur les pages web du code propriĂ©taire, opaque, privateur, qui est lĂ pour surveiller, pister ou forger des empreintes numĂ©riques permettant de traquer l'utilisateur peu importe oĂč il va. Quand on parle de logiciels, on arrive vite Ă la dichotomie entre les logiciels libres (au sens donnĂ© par la Free Software Foundation, le seul qui vaille) et les logiciels propriĂ©taires. Or, on oublie vite que c'est le mĂȘme problĂšme pour le code JavaScript qu'on subit lorsque l'on surfe sur le web. Le code JavaScript est un piĂšge, vite dĂ©loyal, vite dangereux.
Avant, modulo des animations clignotantes et des GIF horribles, les pages Ă©taient simples. Le contenu Ă©tait rapidement accessible. Maintenant, c'est une purge. On se prend dĂ©jĂ un bandeau pour accepter les cookies, contraignant Ă tous les accepter ou passer par un parcours insupportable pour choisir ceux que l'on ne veut pas, en supposant que ces choix soient respectĂ©s. Ă cela s'ajoutent les panneaux publicitaires, proposant tout et n'importe quoi. Et ensuite un paywall, soit en cours de lecture pour appĂąter lâutilisateur, soit dĂšs l'affichage de la page pour forcer lâutilisateur Ă accepter tous les cookies (donc le pistage) ou Ă prendre un abonnement. Les champions sont les sites de presse en ligne que l'on doit plaindre si on les Ă©coutait ; ils ont choisi dĂ©libĂ©rĂ©ment de se lier pieds et poings chez Google ou Facebook, mais dĂšs que certains comme Apple et la âgomme magiqueâ de Safari arrivent pour dĂ©gager leurs merdes, ils se plaignent. Ils sont nĂ©s avant la honte.
Des justifications merdeuses
En discutant avec les gens au sujet du web et des technologies de dĂ©veloppement âwebâ, j'entends toujours les mĂȘmes arguments Ă©culĂ©s.
Les DRM permettent de fournir une meilleure expĂ©rience Ă l'utilisateur. Non. DĂ©jĂ car ici on pense surtout Ă des consommateurs. Et ensuite parce que ces Digital Rights Management sont des cancers pour le web libre. Zoner gĂ©ographiquement, empĂȘcher l'accĂšs, la copie, la diffusion, c'est purement de la censure Ă des fins mercantiles. Ă quel moment on a cru bon d'accepter ces verrous numĂ©riques pour le web ?
Les technos web rĂ©duisent les coĂ»ts de dĂ©veloppement. Si un choix technique ou technologique est justifiĂ© par un argument financier, ce choix est par dĂ©finition mauvais. Les logiciels faits grĂące Ă (ou Ă cause de) Electron sont les pires que je n'ai jamais pu utiliser, en terme de performances ou d'efficacitĂ©. Idem pour les machins Ă base de PhoneGap, Ionic ou Cordova. MĂȘme la suite Teams de Microsoft passant de Electron Ă WebView2 est une purge Ă utiliser. Ăa bouffe de la RAM, ça glitch, ça refresh mal, l'accessibilitĂ© est dĂ©gueulasse, ça ne reprend pas les codes plus sains des logiciels natifs.
Ăa donne une expĂ©rience unifiĂ©e pour l'utilisateur. Non. Embarquer des web views dans des applications mobiles est une connerie. On augmente la surface d'attaque, on consomme davantage de bande passante, on se retrouve avec des failles de sĂ©curitĂ© en plus tant dans le code web qu'Ă cause du navigateur faisant le rendu, lâaccessibilitĂ© est souvent foirĂ©e, et on se retrouve parfois avec des rĂ©gressions identifiĂ©es tardivement Ă cause d'effets de bords indĂ©sirĂ©s. On modifie la page web pour changer une fonctionnalitĂ©, sauf que c'est tracĂ© nulle part cĂŽtĂ© application et lâutilisateur ne se rend compte de rien. Sans oublier qu'on zappe parfois la mise en cache des donnĂ©es et le mode hors-ligne. Les web views sont un excellent moyen de dĂ©possĂ©der l'utilisateur ; suffit de ne pas faire de cache et de changer la page ou la rediriger, et c'est terminĂ©.
Le HTTPS permet d'ĂȘtre sĂ©curisĂ©. Oui, c'est vrai. Mais pour du contenu statique on n'en a pas besoin du tout. Ă cause du tout HTTPS, on se retrouve avec par exemple des ordinateurs âvieuxâ, avec des âvieuxâ navigateurs web, qui n'ont plus leurs certificats Ă jour. Donc un âvieuxâ iMac, qui fonctionne bien mais plus mis Ă jour depuis quelques annĂ©es toutefois, ne pourra plus permettre Ă l'utilisateur de naviguer sur les internets car on aura du HTTPS partout et le navigateur web ne pourra afficher le contenu Ă cause de certificats rĂ©voquĂ©s ou obsolĂštes. TLS 1.0 et 1.1 sont obsolĂštes depuis 2018, donc des certificats racines ne sont plus mis Ă jour, donc des sites web inaccessibles. Bingo.
C'est nouveau, c'est génial. J'ai entendu ça sur le server-side rendering (SSR), un cran plus loin dans la merdification. On a des gens qui sont satisfaits d'avoir réinventé la roue : le serveur web qui va construire la vue HTML. Retour aux débuts du web. On avait le serveur qui renvoyait la page à afficher, puis on a fait des API SOAP, puis on a fait des API REST, puis des API GraphQL, et là on fait ce SSR. Et des pignoufs vendent ça comme de l'innovation, quels escrocs. Faire du développement web c'est faire de la hype driven development.
Des pétards mouillés aussi
Qui a encore entendu parler du physical web ? Ces pages et sites web qui arrivent sur nos appareils grĂące Ă des beacons qui diffusent des signaux, notamment prĂšs des bornes publicitaires ? Un gag.
Et les progressive web apps (PWA) alors ? Un plagiat ridicule des applications mobiles. Les utilisateurs ne comprennent pas comment les installer, ce n'est pas naturel. On est toujours limitĂ© de prĂšs ou de loin par le navigateur. Ăa impose d'avoir du JavaScript pour gĂ©rer la mise en cache avec le service worker. Qui, lui, impose d'ĂȘtre en HTTPS pour fonctionner. On pourrait s'attendre Ă avoir des vraies Ă©volutions, comme des threads ? Les web workers n'y arrivent pas sĂ©rieusement. Sans compter qu'encore aujourdâhui des API accessibles par les apps mobiles ne le sont pas par les PWA, et que par essence et par dĂ©finition les apps mobiles natives seront toujours en avance sur l'usage des terminaux contrairement aux PWA qui n'innoveront jamais et persisteront Ă corriger le retard.
Et les neutralités du net et du web ?
Un lointain souvenir. Les adresses IP des VPN sont de plus en plus sur listes noires. Si on utilise des bloqueurs de pubs les sites sont inutilisables, soit dĂ©libĂ©rĂ©ment, soit par conception maladroite. Il y a de plus en plus de discrimination envers les usagers, sans parler des problĂ©matiques rĂ©seaux. Le simple fait de vouloir utiliser TOR nous prive d'une bonne part du web. Sans parler du fait que de plus en plus de sites web ne fonctionnent pas bien voire refusent de fonctionner selon les navigateurs. Ou alors vous imposeront des contrĂŽles âanti robotsâ et des captchas, notamment si le site est gĂ©rĂ© par au hasard Cloudfare. Franchement, j'en ai marre de rĂ©soudre des puzzles et d'attendre qu'un systĂšme obscur me donnent l'accĂšs Ă un site web. Parfois mĂȘme les sessions sont suspendues car on est considĂ©rĂ© comme autre chose qu'un humain lĂ©gitime. DĂ©solĂ© bande de clowns, j'ai un logiciel qui bloque la publicitĂ©, le code JavaScript dĂ©loyal et qui me fait sortir ailleurs qu'en France, juste pour protĂ©ger ma vie privĂ©e. Et c'est justement Ă cause de vous si j'en suis lĂ . Escrocs.
Un noyautage public
Et pendant ce temps, on remarque que Google et consorts continuent leur noyautage du web et de ces instances, ainsi que le silotage de tout ça. Les DRM sont validés par le W3C, Chromium prend presque toutes les parts de marché et applique la stratégie 3E : maintenant que la place est prise, on se débarrasse de ce qui est nuisible, comme par exemple uBlock Origin. De plus en plus de sites web se plient au rÚgles de Google en terme de SEO. Google est en train de foutre en l'air le web ouvert et libre, et ce, délibérément avec son projet de web environement integrity. On peut aussi parler du Manifest v3 de Google encadrant les extensions des navigateurs, toujours pour favoriser les pisteurs et privilégier ce qui intéresse les géants du numérique en torpillant les projets qui préfÚrent protéger les utilisateurs. Ou encore des tentatives pour dégager des formats ouverts, notamment de la part de Google avec JPEG-XL.
Le web social, boulimique, grotesque et Ă©gocentrique
Le web 2.0, le web social, a amené les gens à s'exprimer plus facilement, à créer du contenu, à en partager. Forcément les gros datavores comme Facebook maintenant Meta mais aussi X anciennement Twitter, ou encore Reddit et j'en passe, se sont rués dessus. On incite les gens à créer, commenter, liker, partager. On engloutit autant de données personnelles que l'on peut, soit en exploitant les contenus, soit leurs métadonnées. Et ensuite on se gave encore sur ça en créant de gros corpora de données pour entrainer des modÚles d'intelligence artificielle. Et on verrouille aussi les API, faisant qu'un paquet d'applications qui pouvaient interagir avec Twitter ou Reddit ont plié boutique.
L'effet pervers de ce web social est qu'il a fait naĂźtre les influvoleurs et instabouffons, dit autrement les influenceurs et dindons de tous poils qui commentent, donnent leurs avis, lustrent leurs communautĂ©s de blaireaux avec des hot takes claquĂ©es au sol ou en vendant des produits bidons. MĂȘme dans les milieux de la tech on en a, surtout dans le monde du dĂ©veloppement web. Des paons et des dindons, formant des communautĂ©s de pigeons, gavĂ©s d'articles LinkedIn mauvais, de vidĂ©os YouTube mĂ©diocres, enfonçant des portes ouvertes et rendant le banal et classique tout simplement incroyable. Et quand on les met en face de leurs impostures, ils lĂąchent leurs chiens sans sommation pour protĂ©ger leur crĂ©dibilitĂ© fantoche. Ces gens lĂ sont responsables de rendre les autres plus cons qu'avant, et de leur faire croire Ă des rĂȘves idiots. Regardez, c'est facile de coder, waouh je fais des choses trop bien, vous allez ĂȘtre dĂ©veloppeurs grĂące Ă ma formation. RĂ©sultat ? Trop de personnes s'Ă©tant reconverties avec des formations minables, sans culture, sans bagage sĂ©rieux, saturant les marchĂ©s.
Je pensais que la communautĂ© Debian Ă©tait une des pires, avec sa mentalitĂ© RTFM. Mais une communautĂ© web la surclasse, celle qui adore le JavaScript et le web front ; constamment soumise Ă la hype, Ă rĂ©inventer la roue, Ă s'extasier devant des choses basiques ou peu originales, et Ă avoir l'arrogance de croire que le web va tout surclasser. Pire encore, une partie des membres de cette communautĂ© va se former Ă l'arrache, et se croire meilleure. Heureusement, comme partout, il y a les bons et les mauvais artisans du logiciel, et j'ai de chouettes collĂšgues qui font du dĂ©veloppement web, mais bon sang, je n'ai jamais vu autant de kikoos et de crĂ©tins dans le dĂ©veloppement web front end. On peut trop rapidement et trop facilement faire des choses, et surtout n'importe quoi et n'importe comment. Les mĂȘmes nous font croire qu'il n'y a pas de problĂšme Ă parler de front end quand on parle d'apps Android et iOS ; ils n'ont jamais touchĂ© Ă cet art pour comprendre Ă quel point ce propos est rĂ©ducteur. Et de temps en temps, les mĂȘmes, toujours, tentent de se tailler la part du lion en poussant leurs technologies Ă eux. PhoneGap, Cordova, Ionic, maintenant React. Autant de dette technique en puissance, voire en acte, et de dĂ©pendance Ă des outils que l'on ne maĂźtrise pas, sans parler du fait que ni Google d'un cĂŽtĂ© pour Android, ni Apple pour iOS, ni mĂȘmes d'autres acteurs comme /e/ ne recommendent, Ă l'heure oĂč j'Ă©cris ce lignes, de passer par ces outils tiers. Bref, que les clowns du dĂ©veloppement web front end s'occupent dĂ©jĂ de faire des pages HTML propres et arrĂȘtent d'entretenir les porcs comme Google et tous ceux qui ont travesti le web et se gavent dessus. Ils pourront donner des leçons et polluer le dĂ©veloppement d'apps mobiles une fois que leur maison aura cessĂ© de brĂ»ler. On n'a pas besoin qu'ils fassent les pompiers, juste que les flammes ne se propagent pas de chez eux Ă chez nous. Est-ce du gatekeeping ? Probablement, mais on en arrive lĂ pour Ă©viter le nivellement par le bas et lâuniformisation ridicules des environnements.
Le web social a permis le partage de la connaissance, il a aussi aidé à la fabrique du mensonge. On partageait aux autres avant, on s'étale aux yeux du monde maintenant.
On pensait mĂȘme ĂȘtre tranquille avec le fediverse comme dans les Ă©cosystĂšmes Mastodon ou Pixelfed, mais on trouve encore des gĂ©ants du numĂ©rique comme Meta qui tentent de mettre un pied dans la porte afin de rĂ©cupĂ©rer toujours plus de donnĂ©es avec Threads par exemple. Ces prĂ©dations capitalistes ne sont pas nouvelles ; Google avait rĂ©ussi Ă torpiller XMPP il y a un moment, et impose ses rĂšgles concernant les courriers Ă©lectroniques avec Gmail.
Et forcément, la pub, la pub, les pisteurs, la pub, la pub... qui explosent la taille des pages web et consomment davantage de bande passante.
Bref
Le web est devenu trop compliqué. Nous avons oublié comme faire simple. On créé tous les jours du code legacy. On est devenu dépendant d'un navigateur. On est face aux géants du numérique qui cloisonnent tout. Le développement web est un développement au rabais. Le web 2.0 a créé des dindons arrogants entretenant la fabrique du mensonge et la superficialité. Le web est trop ravagé par les capitalismes de la donnée, de l'attention et de la surveillance. On a oublié toutes les valeurs initiales du web, et la merdification continue.
J'espĂšre qu'on aura de belles histoires avec Gemini par exemple. Ou Kittens et le small web, ou le slow web.
Le web pue la merde, je ne l'ai jamais autant détesté qu'aujourd'hui. Il était émancipateur. Il est devenu privateur.
Quelques ressources en vrac pour aller plus loin et réfléchir un peu
1 â Sur le web environment integrity 2 â Firefox meurt 3 â Ă propos du small web 4 â Meta et le fediverse 5 â On peut avoir un autre web 6 â A brief history of web development. And why your framework doesn't matter. 7 â Lâapocalypse Google avec le web synthĂ©tique 8 â Tracking Protection in Firefox For Privacy and Performance 9 â Et si on faisait du web comme en 1999, ou presque ? 10 â Spritely and Veilid: Exciting Projects Building the Peer-to-Peer Web 11 â Tariq Krim : le slow Web Ă la française 12 â The SOLID project 13 â Retour d'expĂ©rience concernant le navigateur web Brave 14 â Privacy or sensitive data⊠a list of tools to protect your ĐŽŃŃ 15 â Le jour oĂč le Web sâenfonça un peu plus dans la tombe
Wall of shame
â DerniĂšre mise Ă jour : lundi 23 dĂ©cembre 2024 đ â
Did you enjoy reading this blog? Give me a beer đș or use something else â€ïžâđ„ Licensed under CC-BY-SA 4.0. Opinions are my own. To contact me, feel free to choose the most suitable medium for you, or for example Mastodon.