Todo está bien con JavaScript
- Artículo extraído desde:
- Traducción por Hugo Ruscitti
Este es el único diario dispuesto a decir la verdad: todo está bien.
Hay una serie de blog posts que seguramente has leído - una puñalada sarcástica
sobre JavaScript, npm y frameworks. Estos artículos mencionan que hay demasiadas
opciones, que es confuso, y sobre lo complicadas que parecen las cosas. También
toman montones de nombres del ecosistema y los presentan como opciones equivalentes
en un intento cómico por construir un escenario de parálisis de decisión. Todo se
mueve muy rápido y hay demasiado de todo.
Pienso que es tiempo de revisar algunos principios.
La obsesión con las cosas nuevas es un problema personal y no tecnológico
Ocasionalmente paso el rato en foros sobre guitarras. Ahí, tienen nombre para esto: Síndrome de la adquisición de pedal, o simplemente GAS. Y es como suena, es cuando estás más preocupado por conseguir ese pedal Fuzz OCD para manipular tus sonidos en lugar de aprender a tocar el instrumento.
Esto que sucede con las guitarras funciona de la misma manera con la programación: comienzas preguntándote si estás usando el mejor pedal de distorsión, comienzas a investigar, y unas semanas después tienes un gasto de $2.000 en pedales de distorsión.
Programar es un oficio, para los cuales necesitas herramientas. Algunas de esas herramientas son relucientes, otras nuevas y algunas viejas. Todas básicamente funcionan. Solo cambia tus herramientas cuando dejan de funcionarte, si no no las cambies. Demonios, para muchas startups y casi todas las empresas que recién comienzan la decisión del stack de tecnología ni siquiera importa
Tienes que usar diferentes herramientas para diferentes problemas
¿Estás creando una visualización de datos?, probablemente puedas usar d3. ¿Haces una aplicación?, react y redux. ¿Haces una biblioteca?, tal vez no necesites ningún framework.
De alguna forma, esto está anclado al ecosistema de JavaScript. Si miras a través del contexto, esto es algo que tienes que afrontar para crear casi cualquier cosa. Si eres un desarrollador Python, ¿vas a usar Twisted o asyncio?. Si eres un arquitecto, ¿usarás madera o ladrillo?, ¿vas a elegir una lapicera o un lápiz?.
Algunos materiales son mejores que otros en ciertas áreas: ahora que existe lodash hay muy pocas razones para usar underscore. Otras veces hay que sumergirse para ver cuál es la mejor. Webpack o browserify es un ejemplo de dos herramientas que intentan solucionar el mismo problema. Pero muchas veces las herramientas están claramente resolviendo diferentes propósitos: Yo, por ejemplo, uso React cuando escribo una aplicación grande como Mapbox Studio, sin embargo no uso ningún framework cuando escribo bibliotecas que necesito que sean pequeñas.
A medida que aprendes, vas adquiriendo una lista de tecnologías para resolver cada tarea. Esta no es una lista exhaustiva de herramientas, como mucho puede que conozcas 5 sistemas por completo. Posiblemente te vuelvas productivo conociendo estos sistemas, no por juguetear con cada alternativa.
Si alguien es más apasionado que vos sobre decisiones tecnológicas, está equivocado y deberías ignorarlo
Si lees entre líneas, suena como si tuvieras que cambiar de framework cada vez que surge una nueva herramienta que consigue más estrellas en GitHub. O cambiar porque ahora muchos dicen que tienes que usar programación funcional. Tal vez ese sea el caso en San Francisco, pero yo no vivo ahí, y sé que en el resto del mundo es un sin-sentido cambiar de herramientas así. Además, hay modelos de empresas exitosas en cada stack, desde PHP hasta Haskell.
Así que disfruta leyendo cómo las personas despotrican contra todas las opciones que existen, pero cuando leas Cómo se siente aprender JavaScript en 2016 pregúntate a vos mismo: ¿este es un problema de la tecnología?, ¿es acaso el hecho de que existen tantas opciones? ¿o en realidad el problema es que este tipo de miradas nunca está dirigida por un problema concreto a resolver?