El desarrollador de javascript promedio no sabe manipular HTML de forma eficiente

es lo mismo que con php hace 10 años y la explicación sigue siendo la misma.

>Si es ahorrarse tiempo
ahorran mucho tiempo. con un framework podes hacer en 8 horas lo que en javascript puro tardarías 2 semanas (sin contar el tiempo perdido cayendo en pitfalls)

>quizás era así cuando sólo había un framework, pero hoy en día salen nuevos frameworks a cada rato
irrelevante, sobretodo cuando la mayoría de los proyectos que usan estos framework son de usar y tirar. nadie espera que reciban mantenimiento de acá a 3 años. es más barato esperar que se rompa y armar algo nuevo.

>la industria por un afán de parecer actualizado se mueve a lo que salió recién obligando a los asalariados a aprender todo desde cero.
la mayoría usan patrones y modelos ya conocidos (mvp y el otro basado en eventos). si tardas más de un par de días en aprenderlos, es porque no recibiste una formación adecuada desde el principio.

es malo desde el punto de vista del programador porque reduce la cantidad de programadores necesarios; ademas de transformar un proceso previamente artesanal a uno más sistemático, "choiceless", y repetitivo. que a su vez requiere menos formación, lo que aumenta la "reserva industrial" para cada puesto.
por los mismos motivos es malo para el hobbyista e incluso para el estudiante. aunque yo no le recomendaría javascript o php a ninguno de los dos.
en realidad solo es bueno para el capital. si eso te enoja la próxima elegí no ser pobre ;)

Pensandolo a la ligera, se podría considerar que la idea del framework es proporcionar una capa de abstracción a las cosas que siempre tienden a hacerse de una misma manera, así el hecho de que salgan tantos frameworks distintos se podría argumentar que cada framework hace las cosas distintas porque en realidad no exista una única forma de hacer una cosa, al final.

Creo que el problema es que generalizar ese tipo de cosas conduce eventualmente al bloat en dependencias (generando problemas de rendimiento, poca flexibilidad y dolores de cabeza constantes con la API del framework que con el problema que intentas solucionar), pero al final ganas en que el tiempo para tener X carácteristica lista para un proyecto es mucho menor si tienes experiencia al trabajar con bibliotecas o el codigo que quieres reutilizar tiene buena documentación.

En mi caso, tengo suerte de poder darme el lujo de escribir codigo vanilla en JS o usar bibliotecas especificas para tareas bien definidas en caso de que las recomienden o sea estrictamente necesario su uso.

Usa vainilla o te arrepentirás a medio plazo cuando la dependencia te OBLIGUE cada pocos meses a migrar por cambios innecesarios en el diseño de la API y cubrir vulnerabilidades solo en versiones nuevas.

O mejor aún: usa JS solamente cuando sea necesario para mejorar la usabilidad pero NUNCA impidas la navegación sin JS.

Buena suerte consiguiendo un trabajo hoy en día que no requiera dominio de ES6, React y proyectos de Node.

¿En serio consideras ES6 y Node como frameworks? ES6 como un nuevo estandar de JS y Node es JS del lado del servidor.

Mi problema con React es que en ciertos países de latam están muy infravalorados los profesionales que lo manejan, por lo que puedes terminar en trabajos de mierda por sueldos de mierda. No vale la pena a menos que tengas contactos buenos o en tu trabajo actual te lo pidan (la peor a mi parecer, peor valorarán tus conocimientos).

Lo gracioso con los programadores de node.js es que incluso para hacer un sitio web personal, o vamos, incluso una página de texto plano con fondo blanco y texto usan frameworks de 4MB y 20 CDNs de terceros para maximizar el rastreo. Tremendo asco el javascript, pero como mencionan arriba, paga. Evito usarlo a toda costa, a menos que me paguen por usarlo.

¿Como se llamaría el framework que desarrollaría BAI?

NEETjs

>>10 React, ya lo han ocupado :)

Creo que se refería a BaI como un todo, no un dev individual con ideas de otros sitios.

no entendiste

Menos mal.

>>12
Pero la aplicación minificada y optimizada sólo pesa menos de un MB (dejando los sonidos aparte)

>menos de un MB
sigue siendo caleta men

Más de 100KB = BLOAT
Y estoy siendo amable.

Entiendo por qué se usa react en proyectos corporativos porque el jefe quiere ahorrar tiempo y dinero pero usarlo para proyectos chicos y personales es una tontera.

Nadie en el tercermundo (al menos que yo conozca) hace proyectos de programación por hobby, casi todos aprenden tecnologías malas pero que están de moda en empresitas como Gugul o Maicrosoft porque quieren salir de la pobreza programando, lo cual aclaro, no tiene nada de malo, pero es una explicación más de por qué esas tecnologías son tan usadas y por qué si las insultas mucha gente lo siente como ataques personales.

>>12
¿No fue una contribución de un usuario? Aparte todos usan el bai radio que parece winamp y ese es puro javascript.

igual hay una app en react

>>20 poca latinoamérica conoces. Viaja, hermano.

>>22
Esa también es una contribución de un usuario.

>>20 ¿por qué van a sentir como ataque personal algo que hacen solo por interés económico? es al revés, son los hobbistas los que se sobre-identifican con la herramienta porque tienen un interés emocional más que económico

el hacer algo por interés económico no impide que también lo hagas por interés intelectual