No voy a profundizar en todo lo que al lenguaje de programación Javascript se refiere, pero sí voy a hablar acerca de su uso como lenguaje interpretado por diversos navegadores de red, que es la única aplicación que hasta ahora le he dado.

En el pasado Javascript apareció para darle dinamismo a las páginas de internet sin necesidad de redirigir a otros enlaces o de refrescar todo el contenido actual y, a día de hoy, ése es el uso que le doy. Sin embargo, existen testimonios de los dolores de cabeza que causaba emplear este lenguaje, tal vez porque aún no contaba con herramientas de más alto nivel o porque no había un estándar para organizar su codificación. Hace apenas poco más de un un año por fin comenzaba yo por abandonar la programación estructurada para trascender al paradigma de la programación orientada a objetos que, al querer trabajar con Java, me vi obligado a aprender. Fue confuso al principio, pero después pude ver las grandes ventajas de programar así, las más importantes de ellas para mí son: la tendencia a generar código limpio, la claridad que ofrece para reutilizar código y la facilidad para abstraer cualquier objeto del mundo real en uno virtual. Todo lo anteriormente dicho sin la necesidad de generar código espagueti. A pesar de ello, programar con estructuras de secuencia, condicionales y de iteración sigue siendo el pan de cada día, pero pueden colocarse dentro de métodos que dejan muy claro lo que tienen qué hacer y evitando cualquier cruce extraño con variables que no deberían modificarse ni por error, al menos no desde el alcance de ese método.

La primera vez que trabajé con Javascript lo hice pensando como programador de funciones, cuando el proyecto se volvía más complejo siempre me resultaba un código con un montón de funciones mal administradas y que podían llevar a sucesos extraños, como los que ocurren cuando algo que pudiera instanciarse se construye basado en el mismo objeto para cualquier lugar en donde aparezca, teniendo que cuidar que no se crucen ciertas características. Por ejemplo, para un mismo cuadro de diálogo que aparezca en dos páginas diferentes con aspectos inicialmente similares y con acciones muy diferentes, habría que validar en dónde está apareciendo para que no crucen las características que tendría que tener en uno u otro lugar. Esto podría quedar mejor administrado con una sola clase de un cuadro de diálogo con instancias diferentes para cada situación o lugar en el que se encuentre sin tener que estar cuidando que no se cometan ciertos errores.

Hubo un momento en el que pensé si podía emplear Javascript de manera similar a como lo hacía con Java, y cuando lo hice comencé a desarrollar mucho más rápido y de manera más ordenada. Cabe destacar que Javascript es orientado a prototipos, pero puede simular muy bien la POO. La velocidad a la que alguien puede desarrollar crece de manera exponencial cuando puede reutilizar recursos, y es muy importante que lo que se pueda reutilizar sea fácilmente identificable e independiente de muchas circunstancias.

Después de orientar Javascript a objetos, comencé a utilizar un framework que pone su propia pauta para desarrollar. No voy a negar que utilizar un framework para Javascript puede traer grandes ventajas, y lo más seguro es que no lo esté utilizando bien puesto que aún no me ha convencido de que sea la mejor manera de desarrollar algo, al final vuelvo a caer en la programación estructurada generando un montón de funciones que al momento de hacerlas me han traído muchos problemas, no me imagino cómo sería programar en Java con frameworks como Angular o React. Otro de los grandes problemas con Javascript es que sus frameworks no terminan de cuajar y duran muy poco tiempo hasta que aparece otro nuevo que se pone de moda y lo que se mantiene estable es el Javascript Vanilla y JQuery, aunque la tendencia es que éste último empieza a caer en desuso. Sin embargo, el principal problema de Vanilla es la falta de librerías a su manera, aunque sabemos que Javascript puede combinar diversos paradigmas de programación en un mismo proyecto.

Tal vez en un futuro empiecen a aparecer más librerías de Javascript POO puesto que está tomando mucha fuerza, ya no es lo mismo de lo que fue en 1995. Por lo pronto, yo me adapto a las necesidades de los proyectos conforme a lo que sus patrones de desarrollo lo requieran, pero el paradigma de la POO sigue siendo mi favorito.

Me despido y les comparto el siguiente artículo: Descubre por qué Javascript vanilla es el futuro.