¿Tienes teléfono móvil o celular?

Porque salvo que tu aplicación sea de intranet o esté tras un login, los spiders no ejecutan javascript.
Aparte, es pasarse por donde no ilumina el sol la accesibilidad, y no hablo solo de lectores de pantalla sino de poder funcionar bien con browsers viejos o de solo texto. Imagina que aún hay empresas que usan XP y sólo dejan usar IE8 porque por política tiene bloqueadas las aplicaciones externas.

Esa debería ser la razón de más peso, tal y como dice >>3-san. Lo mencionado en >>2 es menos importante: los tiempos de carga insoportables, sobre todo en teléfonos, que dejan la web inusable y hacen perder visitas, aun sabiendo que la mayoría de accesos a la web se hace desde estos dispositivos debería ser fundamental, pero destrozar el SEO es un suicidio a cambio de nada. Solo para que el programador esté "cómodo", cuando todo ese trabajo debería hacerse del lado del servidor. Es falaz decir que se sobrecargan los servidores, cuando las peticiones para obtener cientos y cientos de kb de JavaScript mantienen más tiempo abierta la conexión abierta y por tanto disparan el consumo de memoria.

Para eso está el server side rendering que soluciona la mayoría de los problemas que mencionan. A parte de eso alguna razón más para odiar las frameworks de js?
Respecto a la accesibilidad existen proyectos como este https://a11yproject.com/

Por lo general, las dependencias para funciones extremadamente simples en lugar de hacer una librería especializada que las recopile por categorías. Esto ralentiza enormemente los despliegues, complica la resolución de las mismas, requiriendo ingentes cantidades de RAM para ejecutar NPM (más de 1 GB para sí mismo), disparando los requerimientos mínimos del VPS o contenedor donde se ejecuta. Al incrementar muy notablemente la cantidad de pequeñas dependencias mantenidas por una mayor cantidad de usuarios, el riesgo de fallo de las dependencias en cuanto a seguridad, secuestro o corrupción de sus mantenedores se incrementa, además de que ya ha sucedido en varias ocasiones algún problema caótico al respecto.

Si vas a usar JS, usalo para mejorar la experiencia, priorizando solo donde haya características que solamente pueden ejecutarse con JS, y siempre permitiendo una alternativa que degrade el mínimo posible la experiencia. Usar Vanilla JS mejorará enormemente el rendimiento de la página, al no tener tantas llamadas anidadas innecesarias. Jquery es miles (sí, miles) de veces más lento para operaciones tan básicas como selectores. En páginas grandes se dispara la falta de rendimiento. En dispositivos móviles que venden hoy en día, salvo modelos caros de lujo, afecta muy notablemente no solo al rendimiento de carga de página (tarda más en cargar el JS que en descargar el sitio), sino que drena la batería de forma muy notable, lo que no agradará a los usuarios.

>(sí, miles)
oh no, la operación va a demorarse milisegundos en vez de microsegundos :-o

(y sí, estoy siendo sarcástico)

ah, y
>librería
biblioteca

Para completar la información:

Vanilla JS: document.getElementById('test-table');
Operaciones por segundo: 12.137.211

jQuery: $jq('#test-table');
Operaciones por segundo: 350.557


Vanilla JS: document.getElementsByTagName("span");
Operaciones por segundo: 8.280.893

jQuery: $jq('span');
Operaciones por segundo: 19.449


Y a eso, sumen la lentitud extra de React. Y sin contar el consumo de RAM (se me cierra el navegador a menudo en Android por OOM en las mismas páginas). Pueden sacar sus propias conclusiones.

concluyo que tu teléfono móvil es una patata

Nuevo, comprado en diciembre, Android Go 8.1

Cada vez se venden más teléfonos con Android Go por precio, suelen tener 1 GB de RAM, aunque sean quad core, algunos traen más almacenamiento interno por motivos obvios (16 GB o más).

gracias por apoyar mi conclusión

El cuico señores. Edición inmune a la economía del coronavirus.

Normalmente las web no se hacen para ti únicamente. Hay quien prefiere ahorrar en teléfonos y consumir otro tipo de productos. ¿De qué me sirve que la mayoría de gente malgaste dinero en un teléfono si no va a tener dinero para otros gastos? Deja de mirarte al ombligo, que las patatas son para comérselas. Gracias.

>Normalmente las web no se hacen para ti únicamente.
lo mismo te digo

Este weón también viene a dar la cacha a Tecnología? Debí haberme imaginado que era computín.

¿cuál es el problema? ¿acaso está prohibido?

>>12
Dile eso a los webdevs que desarrollan en sus Macbook Pros 16" del año con 16/32 GB de RAM, procesador i7/i9 y en móvil prueban en iPhones 11 Pro y en Galaxy S20s

Lo interesante de React es que en escencia mantiene un DOM virtual que evita que una actualización del DOM ("original") haga un recorrido completo de los nodos siendo realmente ineficientemente. En estricto rigor, esto puede no ser apreciado por desarrolladores que no se dedican al frontend con JS vanilla a gran escala, pero para muchos es algo verdaderamente significativo.

Ahora no importa nada de eso, GitHub adquirió NPM. AAAAAAAAAAAAAAAAAAAAAAAAAA

Es cierto lo del shadow DOM. De todos modos, algo falla cuando páginas tan sencillas como Twitter tiene una latencia de varios segundos en su navegabilidad. No quiero ni saber para qué agregan profilers a las herramientas del navegador si luego no hay interés en optimizar.

En la práctica todo suena muy bien, aparte de Shadow DOM, los web workers o webAssembly. Pero algo no está realmente bien en general cuando las web más emblemáticas están recomendando sus propias apps porque su versión web es imposible de usar en un teléfono.

Otro detallito que no se pensó, es la cantidad de reflow que sucede al cargar una página. Quieren mostrar contenido lo antes posible (tras desperdiciarlo con assets gigantescos), sin embargo eso hace que el navegador cargue contenidos múltiples veces, repinte y vuelva a repintar. Google demonizó lo de cargar JS en el <head> sin una buena justificación, pensando en HTTP/1.1 y no en preload o defer. Hay contradicciones en sus webmaster tools.

Es preocupante que haya cientos de kb en dar compatibilidad a navegadores que ya no existen. Hay quien piensa que su web todavía tiene que funcionar en IE7. Y eso tiene un costo enorme también. Herramientas como WebPack o incluso el monstruo de 7 cabezas Babel deberían desaparecer de la faz de la tierra.

Cabros ¿es buena idea usar frameworks de CSS y si es así cuáles recomiendan? (excluyo a bootstrap por requerir jquery y ser demasiado monótono)

vanilla css es todo lo que necesitas

>>24
Es buena idea si te da paja hacer algo o sientes que no sabes "diseñar" y quieres algo bonito de forma rápida.

>>25 +1
Y usar selectores adecuadamente. La especificidad también tiene un precio. Hay que informarse.
Muchos resets absurdos e innecesarios que usan casi todos los "frameworks" javascript se basan en el abuso del selector universal. Huye de ellos como de la peste.

>>25
Apoyo, entiendo por qué hay gente a la que le gustan frameworks de JS pero de CSS?? No gracias.

Los resets de CSS son necesarios porque entre WebKit, Blink, Gecko, Trident y EdgeHTML no se ponen de acuerdo con los estilos base.

No es necesario si defines explícitamente ciertos estilos. Si reseteas no puedes hacer compatible tus elementos con los de otros CSS existentes. Por ejemplo, intenta mezclar bootstrap con pdf.js: se romperá todo. Al principio salió una idea interesante de componentes CSS autónomos, hasta que inventaron esa mierda dependiente de JS que modifica el DOM sin necesidad.