Crímenes contra GitHub y el software

 (eblog.fly.dev)
1 puntos por GN⁺ 22 시간 전 | 1 comentarios | Compartir por WhatsApp
  • GitHub se usa como una pieza central de la infraestructura de desarrollo, pero se considera que su confiabilidad básica está en entredicho por incidentes frecuentes, páginas lentas y fallas en el navegador
  • Microsoft dijo que la carga aumentó bruscamente por los agentic workflows, pero también crecen las críticas de que GitHub empujó directamente las funciones de Copilot y de agentes para inducir su uso
  • En un experimento con un repositorio mínimo, GitHub descargó 291 solicitudes, una respuesta reducida de 15 MiB y 544,564 líneas expandidas, en fuerte contraste con las 11 solicitudes de Codeberg
  • En mediciones del frontend, GitHub usó un heap estable de aproximadamente 69 MiB, y la página de pull request de rust-lang usó 148 MiB, lo que se considera excesivamente derrochador para una página centrada en texto
  • La conclusión es que el despilfarro de GitHub no es simplemente un deterioro del producto, sino un fracaso de software que prioriza las funciones de IA y las prioridades centradas en inversionistas por encima de resolver los problemas de los usuarios

Confiabilidad y prioridades de GitHub

  • GitHub se usa como una pieza central de la infraestructura de desarrollo de software, pero su confiabilidad básica es cuestionada por caídas, degradación de rendimiento y problemas de compatibilidad con navegadores
  • El historial de GitHub Status muestra decenas de incidentes cada mes, y tanto la página oficial de estado como los criterios del SLA reflejan situaciones que podrían considerarse incumplimientos
  • Se le critica por romperse con frecuencia en Firefox y Safari, por la lentitud de las páginas de comentarios y revisiones de pull requests, y por mostrar un uso excesivo de RAM y picos de heap
  • Se presenta a GitHub Actions como lento y con documentación insuficiente, y la pantalla de logs como causante de fugas de memoria y cierres del navegador durante varios años
  • También se considera que el comportamiento de caché de acciones básicas como setup-go carece de invalidación o es demasiado simplista
  • Existen sitios como githubstars.com que publicitan abiertamente la compra de estrellas, y también se cita la frase “fake stars are highly related to malicious activities” del artículo de Carnegie Mellon
  • Se considera que GitHub debería apuntar a un sistema distribuido de alto rendimiento, alta disponibilidad y gran escala, pero que en la práctica el producto prioriza las funciones de IA y los flujos con agentes por encima de la confiabilidad básica

La carga “agentic” y la responsabilidad de Microsoft

  • En ‘an update on github availability’, GitHub afirmó que desde la segunda mitad de diciembre de 2025 los agentic development workflows se aceleraron bruscamente, y que crecieron rápido la creación de repositorios, la actividad de pull requests, el uso de APIs, la automatización y las cargas de trabajo de repositorios grandes
  • Esta explicación trata el aumento de carga como si fuera un fenómeno externo, pero da pie a críticas de que GitHub y su empresa matriz Microsoft empujaron directamente la IA y los “agents” en varios productos para inducir su uso
    • En la barra superior de casi todas las páginas de GitHub hay 3 botones de IA, y 2 de ellos son exclusivamente para iniciar agents; en muchas páginas hay 4
    • En el área superior derecha de la página de inicio de un repositorio común hay 4 formas de ejecutar Copilot
    • Se presenta un enlace crítico que sostiene que GitHub subsidió durante años el costo de usar estas herramientas para impulsar su adopción, lo que equivale a subvencionarse a sí mismo una denegación de servicio distribuida
  • Microsoft explica que un solo pull request puede tocar el repositorio Git, la verificación de mergeabilidad, branch protection, GitHub Actions, búsqueda, notificaciones, permisos, webhooks, APIs, trabajos en segundo plano, cachés y bases de datos
  • A gran escala, incluso pequeñas ineficiencias pueden provocar profundización de colas, fallos de caché, carga en la base de datos, retrasos de indexación y amplificación del tráfico por reintentos, pero aquí se considera que las ineficiencias de GitHub no son “pequeñas”, sino gigantescas y abrumadoras
  • Microsoft dijo “availability first, then capacity, then new features”, pero en el changelog público de GitHub, durante los 30 días posteriores a esa actualización, “copilot” aparece 59 veces en las notas de parche, “agent” 8 veces, y “performance” y “reliability” 0 veces
    • En los filtros del changelog existe una categoría copilot, pero no hay categorías performance ni reliability
    • También se critica que Visual Studio Code esté integrado directamente con funciones de GitHub y “agentic”, y que se sigan agregando funciones de agentes mientras se deterioran funciones básicas como la terminal integrada
  • La parte donde Microsoft dice que está reduciendo el trabajo innecesario, mejorando el caché, aislando servicios críticos, eliminando puntos únicos de falla, moviendo rutas sensibles al rendimiento, reduciendo acoplamientos ocultos, limitando el radio de explosión y aplicando graceful degradation se interpreta como una admisión de que el diseño del sistema está mal

Por qué el frontend sugiere problemas en el backend

  • La raíz de los problemas de confiabilidad de GitHub está en el backend y la base de datos, pero eso no puede verse desde afuera; en cambio, sí se puede observar el código frontend que se descarga cada vez, como HTML, JavaScript y CSS
  • Así como si se ve una rata en el comedor de una pizzería cuesta creer que la cocina esté limpia, se plantea que la corrupción visible del frontend de GitHub sugiere problemas en el backend, aunque no los demuestra
  • Las páginas de inicio de repositorio de GitHub, GitLab y Codeberg están compuestas por listas de enlaces, pequeños elementos de UX, botones, pestañas y cuadros de búsqueda, con casi ningún elemento costoso como medios interactivos o imágenes
  • Se argumenta que este tipo de páginas debería funcionar a bajo costo en casi cualquier computadora o teléfono, incluso sin una buena conexión a internet, y se menciona que GitHub realmente funcionaba así en el pasado incluso en un iPhone 4 y con conexión 3G
  • Si la funcionalidad es la misma, se define como mejor código aquel que usa menos ancho de banda de red, menos tiempo de CPU, menos RAM y tiene menos errores
  • No es posible conocer directamente el número de bugs del frontend, pero estudios históricos sostienen que la cantidad de bugs suele ser proporcional al número de líneas de código
    • Steve McConnel, Code Complete, 2nd Ed (2004) es citado indicando que el promedio de la industria para errores en software entregado es de 1 a 25 por cada 1000 líneas de código
    • También se cita que la Microsoft Applications Division experimentó de 10 a 20 defectos por cada 1000 líneas durante las pruebas internas, y 0.5 defectos por cada 1000 líneas en productos lanzados

Diseño del experimento y método de recolección

  • Para reducir variables de confusión, la velocidad de internet se limitó a una conexión fast 3G
    • Esta configuración busca reducir el efecto de las variaciones de red y simular la experiencia de clientes de GitHub en condiciones menos ideales, como zonas rurales
  • En los tres servicios se usó el mismo repositorio mínimo, ghsucks
    • Una sola rama master
    • Un solo archivo README.md
    • 0 elementos adicionales como issues o tags
  • Se usaron el mismo navegador y la misma computadora
    • Firefox
    • Apple Macbook Pro M5 Max
    • 48 GiB de RAM
  • En cada servicio se examinaron cuatro páginas
    • Página “landing”: diseño del código
    • Página de “pull requests” o “merge requests”
    • Página de “issues”
    • Página de “settings”
  • Con la caché limpia, se recopiló un HTTP Archive (HAR) para analizar las solicitudes de red, y después de completar la carga se recolectó un heap snapshot para obtener una estimación del uso estable de RAM
  • Para el análisis de HAR se usó anhar, escrito por el autor; para el análisis con soporte de compresión, testcompress; y para verificación cruzada, pagespeed.web.dev

Uso del heap y desperdicio de memoria

  • El uso de heap medido en la página principal de repositorios fue de 69 MiB para GitHub, 68 MiB para GitLab, 14 MiB para Codeberg y 1.3 MiB para eblog.fly.dev
  • Renderizar la primera página de issues de https://github.com/rust-lang/rust/pulls usa 148 MiB de RAM
  • 148 MiB es más memoria que la del iPhone original, y se considera un desperdicio extremo para una página centrada en texto con unos cuantos enlaces
  • Como referencia, se mencionan memorias de dispositivos como Apple iphone 1 con 128 MiB, iphone 4 con 512 MiB, Sony playstation 2 con 32 MiB y Nintendo wii con 88 MiB

Comparación de cantidad de solicitudes y tamaño de respuestas

  • anhar es un programa en Go que parsea HAR JSON, autoformatea el HTML, CSS y JavaScript de las respuestas con deno fmt, y luego calcula el tamaño de solicitudes y respuestas, los totales por MIME, el tiempo de carga y la cantidad de líneas de respuesta
  • Las métricas principales son el tamaño de la solicitud, el tamaño real de la respuesta minificada recibida, el tamaño y número de líneas de la respuesta expandida tras aplicar deno fmt, el Content-Load como tiempo de carga del HTML base y el Load como tiempo de carga de todo el contenido
  • La página de repositorio en Codeberg registró en total 11 solicitudes, 9 KiB de solicitudes, 1 MiB de respuesta, 1 MiB de respuesta expandida, 3,480 líneas expandidas, Content-Load de 2.934 s y Load de 3.172 s
  • La página de repositorio en GitHub registró 291 solicitudes, 178 KiB de solicitudes, 15 MiB de respuesta minificada, 22 MiB de respuesta expandida, 544,564 líneas expandidas, Content-Load de 843 ms y Load de 21.330 s
    • application/javascript: 214 solicitudes, 12 MiB de respuesta, 19 MiB de respuesta expandida, 481,849 líneas expandidas
    • text/css: 42 solicitudes, 2 MiB de respuesta, 60,016 líneas expandidas
    • GitHub pulls: 266 solicitudes, 14 MiB minificados, 20 MiB expandidos, 487,922 líneas expandidas, Content-Load de 592 ms y Load de 6.754 s
    • GitHub settings: 255 solicitudes, 14 MiB minificados, 20 MiB expandidos, 486,067 líneas expandidas, Content-Load de 778 ms y Load de 6.963 s
  • GitLab es más pequeño que GitHub, pero sigue siendo pesado
    • Repositorio en GitLab: 78 solicitudes, 8 MiB de respuesta, 101,682 líneas expandidas, Content-Load de 6.880 s y Load de 12.941 s
    • GitLab merge_requests: 65 solicitudes, 7 MiB de respuesta, 90,567 líneas expandidas, Content-Load de 6.947 s y Load de 12.096 s
    • GitLab edit: 117 solicitudes, 7 MiB de respuesta, 71,916 líneas expandidas, Content-Load de 6.964 s y Load de 13.302 s
  • Se señala que GitHub trae unas 540 mil líneas de código y datos incluso para mostrar un repositorio vacío, más que DOOM con 35 mil líneas, Windows Quake con 120 mil líneas, MS-DOS 4.0 con 332 mil líneas y el toolchain de Zig con 460 mil líneas
  • Se considera problemático que cada página individual cargue 40 archivos CSS y cientos de archivos JavaScript
  • En teoría, la división de chunks de Webpack puede separar funciones centrales y opcionales y favorecer el caché y los CDN, pero aquí se interpreta que termina ralentizando la carga porque cada archivo requiere una solicitud HTTP independiente
  • Esperar 22 segundos para ver una página vacía se considera inaceptable, y se afirma que incluso con fibra de más de 1 GiB/s y un procesador de consumo de alto rendimiento, pasan más de 1 segundo antes de que el repositorio resulte algo utilizable

Comparación de soporte de compresión

  • La compresión se presenta como una forma útil de reducir la carga en clientes, servidores y rutas intermedias
  • gzip es un estándar de compresión probado que todos los sitios web deberían soportar, mientras que zstd tiene buenas características de rendimiento pero es un método más moderno, por lo que su soporte se considera simplemente “deseable”
  • testcompress es un programa en Go que prueba si una URL soporta compresión gzip y zstd, y si no la soporta, comprime directamente el cuerpo de la respuesta para mostrar el ahorro potencial
  • eblog.fly.dev/startingsystems3.html: codificaciones soportadas zstd gzip, original 575.77 KiB, gzip 67.64 KiB, zstd 60.17 KiB
  • github.com/ef0xa/ghsucks: codificaciones soportadas gzip, original 224.70 KiB, gzip 43.27 KiB, zstd 37.96 KiB
  • gitlab.com/efronlicht/ghsucks: codificaciones soportadas gzip, original 43.08 KiB, gzip 11.48 KiB, zstd 11.34 KiB
  • codeberg.org/efronlicht/ghsucks: codificaciones soportadas n/a, original 43.88 KiB, gzip 13.00 KiB, zstd 12.79 KiB

Resultados móviles de PageSpeed

  • En la medición móvil de pagespeed.web.dev, Codeberg obtuvo PASS con First Contentful Paint de 1.2 s, Largest Contentful Paint de 1.3 s e Interaction to Next Paint de 86 ms
  • eblog.fly.dev obtuvo PASS con First Contentful Paint de 1.1 s, Largest Contentful Paint de 1 s e Interaction to Next Paint N/A
  • GitHub obtuvo FAIL con First Contentful Paint de 1.8 s, Largest Contentful Paint de 2.1 s e Interaction to Next Paint de 242 ms
  • GitLab obtuvo FAIL con First Contentful Paint de 2.1 s, Largest Contentful Paint de 2.4 s e Interaction to Next Paint de 243 ms

Evaluación por servicio

  • GitHub

    • Trae unos 300 archivos, alrededor de 550,000 líneas de código y datos, y se estima que introduce unos 550 bugs
    • Se resume con un Content-Load de unos 800 ms, un Load total de unos 7 s y un heap en estado estable de unos 69 MiB
    • Soporta gzip, pero no zstd
    • Recibe una calificación de F, por considerarse que el peso del código es extremadamente grande
    • Se señala que GitHub carga todos los temas en todas las páginas, se usen o no
    • Como pagespeed.web.dev indica que 528 KiB de JavaScript y CSS no se usan en absoluto, se considera que se puede empezar por reducir esa parte
    • Si alguien tiene que quedarse en GitHub, se plantea que estaría incumpliendo el propio SLA de GitHub, y se sugiere enviar un ticket de soporte para pedir un reembolso

  • GitLab

    • El Content-Load es de unos 7 s, el Load de unos 13 s, y descarga más de 70 archivos para un total de 7 MiB y unas 10,000 líneas
    • El heap en estado estable es de unos 68 MiB, y soporta gzip, pero no zstd
    • Recibe una calificación de D+: no es tan derrochador como GitHub, pero descarga demasiados recursos y no logra aprovecharlos bien
    • Descarga más de 1 MiB de JavaScript y CSS del que en la práctica no se usa nada, y aun dentro del código que sí se usa hay chunks de 3 MiB cuyo parseo por sí solo tarda 255 ms
    • Se considera que una landing page no necesita 55,000 líneas de CSS, y que tanto el CSS como el JavaScript podrían reducirse a una décima parte del nivel actual

  • Codeberg/Forgejo

    • El Content-Load es de 2.9 s, el Load de 3.1 s, y descarga 11 archivos por 1 MiB y unas 1,100 líneas
    • El heap en estado estable es de unos 14 MiB, y no soporta ni gzip ni zstd
    • Recibe una calificación de C+: tiene buenas bases, pero le falta atención al detalle y experiencia
    • No minificar el HTML se considera un problema menor, pero no soportar compresión se evalúa como una omisión grave
    • La mayor parte del JavaScript y CSS no es necesaria para renderizar la página, pero el problema es que se cargan de una forma que bloquea el renderizado
    • Se propone combinar los payloads de JavaScript y CSS para reducir la cantidad de solicitudes, y soportar compresión gzip y zstd para los payloads HTTP, incluido el HTML
    • Como es software libre, se destaca como ventaja que se puede migrar a otra instancia o hacer self-hosting

  • eblog.fly.dev

    • eblog.fly.dev/startingsystems3.html registra un Content-Load de 76 ms, un Load de 1.1 s, 5 archivos, 766 KiB y unas 3,800 líneas
    • El único archivo HTML pesa 576 KiB y puede comprimirse hasta unos 70 KiB con zstd
    • El heap en estado estable es de unos 11 MiB, y soporta tanto zstd como gzip
    • Recibe una calificación de A-: en general está bien, pero el HTML sigue siendo voluminoso y repetitivo incluso considerando la compresión, y una página que podría resolverse con una sola solicitud requiere 5

No es solo degradación del producto, sino un problema de costos

  • “enshittification” se resume como el proceso por el cual un buen producto empieza beneficiando a usuarios y clientes empresariales, luego pasa a perjudicar a los usuarios, después también a los clientes empresariales, y termina favoreciendo al operador
  • Se considera que Microsoft y GitHub tampoco están desligados de Embrace, Extend, Extinguish, pero que el problema aquí es distinto porque genera costos no solo para usuarios y clientes empresariales, sino también para Microsoft
  • Un codebase inflado aumenta directamente los costos de servidores y ancho de banda, y además consume indirectamente tiempo de ingeniería para mantener una base de código inestable y sobredimensionada
  • Si se asume que GitHub tiene unos 800 ingenieros, y que cada uno trabaja 40 horas semanales durante 48 semanas al año, eso equivale a 1,536,000 horas-ingeniero al año
  • Se plantea que la mayoría de los problemas de frontend podrían corregirse o mitigarse en una semana por ingenieros competentes con solo seguir las recomendaciones de pagespeed
  • Se interpreta que la razón por la que se dejan de lado mejoras de bajo nivel que podrían reducir costos es una de tres: desinterés, incompetencia extrema, o una organización bloqueada por un liderazgo centrado en la IA y los inversionistas
  • El software se describe como una herramienta poderosa y hermosa porque, una vez escrito correctamente, puede copiarse de forma perfecta, para siempre y gratis, para que todos lo usen
  • La conclusión es que el despilfarro y la incompetencia de GitHub y servicios similares no son solo un mal producto, sino un crimen contra el software

Lecturas relacionadas

1 comentarios

 
GN⁺ 22 시간 전
Comentarios en Lobste.rs

  • Estaría bien que Trac y Sourcehut también se incluyeran en esta comparación.

  • Los 4 botones de agentes de IA dan risa, y las cifras relativas del artículo también son interesantes, pero aunque no estoy tratando en absoluto de defender a GitHub, algunos detalles del texto carecen de contexto y no parecen suficientes para respaldar la tesis del autor.
    El uso de memoria en reposo podría ser una señal de que GitHub hace más cosas que Codeberg, pero es difícil sacar una conclusión significativa comparando el uso absoluto de RAM en una computadora con 48 GB de RAM con la computadora de guiado del Apollo.
    Formatear un bundle de JavaScript minimizado para estimar líneas de código y compararlo con las líneas de un proyecto en Zig excluyendo dependencias también es comparar peras con manzanas. Habría que descompilar el ejecutable de Zig y ver cuántas líneas salen.
    Tampoco entiendo la recomendación de que Codeberg “debería combinar las cargas de JavaScript y CSS para reducir la cantidad de solicitudes”. Por cómo habla del “overhead adicional” de las solicitudes HTTP, hasta me hace dudar de si el autor conoce HTTP/2.
    Tengo mucho más que decir sobre el rendimiento de páginas web, pero lo dejaré para otro texto; para una mejor perspectiva sobre un tema parecido, recomiendo releer el artículo de Danluu de 2017 sobre el exceso de peso en la web: https://danluu.com/web-bloat

  • Si el autor está leyendo esto, le vendría bien revisar la discusión entre Casey Muratori y Uncle Bob. El primero encontró una degradación de rendimiento muy interesante.
    “No pude resistirme, así que miré una captura de rendimiento de Chrome y descubrí al culpable :) ¡era el ‘emoji picker’!”
    “Solo revisé el código por encima, pero parece que el problema es que cada vez que escribes un carácter, el ‘emoji picker’ retrocede para comprobar si lo que acabas de escribir es un emoji”.
    Uf. Aunque en este caso el culpable podría no ser el código frontend de GitHub, sino un navegador basado en Chromium.

  • La frase “Codeberg es un producto ofrecido por voluntarios libres que depende de donaciones independientes” no es precisa.
    Codeberg depende de sus miembros. No solo en términos de cuotas, sino también de política; y aunque actualmente las cuotas no alcanzan para contratar personal de tiempo completo, así que depende mucho del voluntariado, según entiendo también tienen contratistas.
    No sigo a Codeberg muy de cerca (prefiero sourcehut), pero el hecho de que sea una cooperativa es una parte central de su propuesta de valor. También intentan publicar sus gastos con transparencia. Por ejemplo: https://blog.codeberg.org/codebergs-budget-of-2026.html
    Si usas Codeberg, valdría la pena considerar hacerte miembro ahora mismo: https://join.codeberg.org/

  • De verdad odio GitHub. Mi problema no es la disponibilidad, sino que es ridículamente lento y consume demasiada memoria. ¿“No mostramos este diff por defecto para un cambio de este tamaño”? ¿En serio?
    También está roto para un flujo de desarrollo razonable. Si haces rebase a un PR, desaparecen el feedback y los comentarios de revisión; si haces squash de commits, también desaparecen el feedback y los comentarios.
    Aunque tengas un enlace a un comentario específico, si ese commit desaparece, el comentario también desaparece \o/
    Si hay una corrección de bug, te dicen que abras un PR, y aunque ese bug se haya corregido con otro cambio, como el PR y el bug existen al mismo nivel, el PR muerto se queda para siempre en la cola de revisión.
    Si quieres saber qué bug corrigió este commit, solo te muestra el historial del PR. Es como si te dijera que no mires el bug sino el PR, y si quieres saber del bug tienes que ir a buscarlo tú mismo.

    • El concepto de “pull request”, al igual que git, viene del desarrollo del kernel de Linux. Es un flujo en el que se le pide al mantenedor del kernel que “jale” el parche hacia la rama principal.
      GitHub hizo ese flujo más cómodo con el botón de “fork”, lo volvió más “social” al introducir nombres de usuario centralizados, y luego conquistó el mundo añadiendo un rastreador de issues y una wiki. En términos de negocio, sí fue una genialidad.
      Pero todo el flujo sigue estando orientado al desarrollo open source, donde personas separadas le piden a otras que “jalen” sus parches.
      No entiendo por qué un equipo de desarrollo estrechamente integrado, cuyo mecanismo real es “discutir una rama y aprobar un merge”, tendría que usar “pull request”. ¿Jalar desde dónde? Está en el mismo repositorio y el cambio ya fue push.
      Incluso dejando de lado el problema de la terminología, que falten cambios acumulados, comentarios estables y diffs por conjunto de cambios no tiene sentido.
      Perdón por soltar otra queja aburrida sobre GitHub. ¿Hay alguna alternativa mejor? Claro, aunque no puedas obligar a nadie a usarla…

  • He visto varias veces la reacción de que “los gráficos sin etiquetas en los ejes ni puntos de datos individuales siempre son sospechosos” respecto a gráficos publicados por GitHub.
    Como el gráfico sí muestra los valores máximos, se puede estimar visualmente que los valores medios del eje y son algo así como 45M, 0.7B y 10M, a menos que en secreto use escala logarítmica y la carga no haya aumentado 100000 veces.
    Yo no llamaría “sospechoso” a un mal gráfico aquí; diría simplemente que comunica mal. Personalmente, siempre prefiero la salida cruda de ggplot.
    Estoy de acuerdo con el sentimiento general, pero en la parte de los caballos gordos y muchas tablas me costó un poco seguirlo. Aun así, si estuviera enumerando todos los defectos de GitHub, yo también habría terminado soñando que me volvía loco y cabalgaba un caballo gordo hacia el atardecer.
    Yo también empecé a hacer una lista parecida y me rendí cuando llegué como a 12 problemas de UX/rendimiento. Me gusta lo minucioso de este análisis y ojalá el equipo de GitHub lo revise de verdad.
    Como ya dije antes, Microsoft debería asignar algunos ingenieros de rendimiento a GitHub. Hasta que las métricas de rendimiento entren de verdad en los indicadores clave, este exceso de peso seguirá y otras plataformas se verán más atractivas. Si alguna vez hay un próximo CEO de GitHub, espero que lo priorice.

    • Estás asumiendo que el eje y del gráfico empieza en 0. En este tipo de gráficos corporativos muchas veces no es así.
      Es muy común que afirmen un “crecimiento enorme” mientras la línea cruza el área del gráfico en diagonal, pero el eje y en realidad solo va de 100 a 101.

  • Estoy de acuerdo con lo de que “los logs de GitHub Actions filtraron memoria y mataron mi navegador durante años, y todavía no hay una forma de simplemente hacer pipe de stdout a otra parte”.
    Por desgracia, Forgejo también heredó eso. A veces recibo una notificación de una compilación fallida y quiero revisarla rápido desde el teléfono, pero en bastantes casos el navegador móvil ni siquiera logra cargar la salida.

  • Cuando hice clic en este artículo, esperaba totalmente otra queja sobre la disponibilidad de GitHub, pero me sorprendió gratamente que al final fuera una evaluación tranquila y razonable de los problemas actuales de GitHub, GitLab y Codeberg, con propuestas de solución incluidas.
    Estaría bien que Tangled también se incluyera en la comparación.
    El autor debería escribir algo de CSS para que el sitio se pueda leer también en móvil. Tuve que usar el modo lectura del navegador.
    Lo único con lo que no estoy de acuerdo es con la afirmación de que ningún sitio debería cargar más de un archivo JavaScript/CSS.
    Si esas 550 mil líneas de JavaScript estuvieran todas en un solo archivo, tardaría mucho más en parsearse y ejecutarse. El CSS sí podría empaquetarse, pero por ejemplo puede ser útil tener un chunk común y otro específico por ruta. Un enfoque así o algo similar probablemente seguirá siendo muy usado.

  • Esta página no se puede leer.
    Y si no te gusta GitHub, entonces no lo uses. Me sorprende que la gente tenga tiempo de juntar listas de quejas así de largas. O lo usan porque les pagan, o simplemente deberían usar otra cosa.