React ha revolucionado el desarrollo web, ofreciendo a los desarrolladores una poderosa herramienta para crear interfaces de usuario dinámicas e interactivas. Gracias a Honeypot, una plataforma tecnológica reconocida, recientemente lanzó un excelente documental de React.js que profundiza cómo fue el nacimiento de esta tecnología
¿De qué se trata?
Puedo decir que me encantó este documental de React.js debido a que la historia es narrada por los participantes de la creación del proyecto. El documental abarca desde que fue una idea, el inicio de su desarrollo, las motivaciones tecnológicas para hacer React, qué cosas pasaron dentro de Facebook y como el proyecto fue adoptado por la compañía hasta ir poco a poco avanzando sobre la evolución de la librería a lo largo del tiempo, hasta llegar al futuro del mismo.
Las entrevistas son interesantes, variadas y con el contenido fácil de entender. No posee mucho contenido de alto grado tecnológico por lo que puede verlo todo tipo de público interesado en React.
Para quienes llevamos rato en el mundo del desarrollo web. Este documental de React.js nos traerá nostalgia de como funcionaban las cosas en el 2010-2012, a pesar que allí lo muestran como algo viejo y lejano, para uno es como si fuese ayer (creo que me estoy volviendo viejo al escribir estas cosas).
¿Cómo ver el documental de React.js?
El documental de React.js está disponible de forma gratuita en Youtube. Te recomiendo verlo con calma y tiempo porque es bueno, muy interesante y podría ser motivador, sobre todo si quieres llevar adelante tu proyecto de código abierto.
Así que mira el documental a continuación:
How A Small Team of Developers Created React at Facebook | React.js: The Documentary
Espero que te guste este grandioso documental de React.js y compártelo con tus amigos en las distintas redes sociales. Si deseas ver otro documental similar, te recomiendo ver el documental de la creación de Vue. Es igual de bueno y te encantará.
Finalmente, te invito a dejar tu comentario sobre el vídeo, si has trabajado con React.js o tu opinión de este framework que es mas actualizado actualmente para el desarrollo web.
Luego de 7 años tuve la oportunidad de dedicarle tiempo a mi plugin JS Categories List y poder actualizarlo para que esté al día respecto a los estándares de WordPress y de la web en general.
El plugin muestra un listado de categorías expandibles
Durante este tiempo WordPress añadió Gutenberg, un editor visual que ahora se incorpora en cada instalación y poco a poco va tomando el liderazgo de como crear el contenido. Por este motivo los widget/bloques han migrado a ser hechos con una aplicación en React y que llame a entradas del API del sitio.
Eliminación de jQuery de JS Categories List
En estos 7 años el principal cambio fue lo innecesario de depender de jQuery. Su popularidad se debía porque está incluida en cada instalación y anteriormente ayudaba a manipular el DOM fácilmente debido a las limitaciones de los navegadores.
Pero actualmente no es necesario usarla: los navegadores ya permiten hacer nativamente mucha de sus funcionalidad, la librería requiere cargar contenido JS innecesario y los bloques de Gutenberg se realizan con React quien ofrece mucho mas.
Creación del bloque de Gutenberg
Primero fue mejorar el código fuente, cuya tarea mas que todo fue aplicar estandarización de código PHP, organizar mejor el código, rescribir partes mal hechas
Luego fue la creación del bloque de Gutenberg, tomé como base el código fuente de mi otro plugin recientemente actualizado y lo modifiqué para funcionar con categorías en vez de archivos.
Los bloques de Gutenberg usan React, así que me tocó rescribir el plugin desde el PHP que genera HTML a componentes JSX. La lógica es similar pero en esta migración pude hacer mejoras que luego apliqué a la versión de PHP.
Para facilitar futuras mejoras y ver que el código funciona, agregué pruebas jest a los componentes y así asegurarme que todo funciona bien. En futuros cambios, ahora tendré como probar los cambios y garantizar el correcto funcionamiento,
Animaciones en JavaScript
Una de las principales funcionalidades que ofrecía jQuery es de animaciones sencillas con simplemente llamar una función. Esta funcionalidad no está disponible en el JavaScript puro porque esas características se fueron agregando a CSS.
En mi plugin de JS Archive List, logré implementar las animaciones usando clases CSS pero no funcionan bien en algunos casos reportados por usuarios, sobre todo, cuando hay altura dinámica.
Por ello, para este JS Categories List decidí crearlas desde 0 en vanilla JS para que funcionen bien en cualquier escenario. Descarté el uso de clases CSS por el problema mencionado, ademas que es mas fácil de probar de forma automatizada.
Experiencia al actualizar JS Categories List
Aprendí mucho al rescribir mi código antiguo. Noté como ha evolucionado mi forma de programar a lo largo de estos años, cómo la tecnología cambia pero las bases de WordPress se mantienen y la retrocompatibilidad se respeta. Con razón este CMS es el mas usado en el mundo.
Pude pulir mis conocimientos de React, de pruebas automatizadas con Jest y aplicar mejores patrones en el código de PHP. También el resultado me permitirá actualizar con mayor frecuencia este plugin y ofrecer mejoras.
Desde hace un par de años, se libera una versión de PHP cada año y por lo tengo para estar al día, es recomendable estar actualizando el código para que sea compatible con futuras versiones. Si utilizas alguna herramienta de contenedores como Docker y tienes tu stack armado allí tarde o temprano tienes que cambiar de versión. Pero si usas PHP en laradock, el proceso es muy fácil como puedes ver.
Cambio de versión de PHP en laradock
El primer paso es ir a la carpeta raíz de Laradock y buscar el archivo de variables de entorno llamado .env. Ábrelo con tu editor de textos favorito y buscar la variable de entorno denominada PHP_VERSION y escribir la versión deseada, por ejemplo:
PHP_VERSION=8.2
Reconstruir imágenes
Luego debes volver a construir los contenedores de php-fpm que es el que procesa el código PHP en laradock y el de workspace para poder ejecutar scripts de PHP como composer, phpcs, entre otros.
Luego para que los cambios tomen efecto, debes reiniciar los contenedores. En mi caso como uso un stack LAMP sería:
docker-compose down
docker-compose up -d nginx mariadb phpmyadmin workspace
Comprobar que la versión de PHP en laradock es correcta
Y finalmente ya todo debería estar en la versión definida. Para comprobar, puedes crear un archivo .php con la funciónphp_info() por dentro para imprimir todos los datos de la versión. Para el caso del workspace puedes ejecutar: php –version y ver la versión instalada.
Finalmente, espero que te sirva y puedas usar PHP en laradock con la versión que desees. Si necesitas volver a la versión anterior, simplemente edita de nuevo el archivo .env y comienza de nuevo.
Hace unas semanas Brent Roose publicó un vídeo de por qué considera mejor un tema claro en los editores de código. Me llamó la atención su opinión y los artículos que compartió que decidí intentarlo. Ya al segundo día, había notado los cambios y no volví a usar el tema oscuro exceptuando en la terminal (empecé a usar computadoras en los tiempos de MS-DOS y para mí la terminal siempre será con fondo oscuro).
El reconocido meme entre los programadores sobre el miedo a usar un editor claro. Fuente: @programming_tips
¿Usar un tema claro es mejor para mis ojos?
Hace tiempo leí que los temas oscuros eran mejores porque las pantallas no iluminaban tanto ni cegaban la vista, ocasionando cansancio con el tiempo. Pero al parecer sólo es válido para monitores viejos de tipo CRT. Pero viendo la entrada de Brent Roose, en él comparte enlaces a varios artículos y estudios donde muestran que el ojo humano está acostumbrado a reconocer patrones oscuros sobre fondo claro. Por ejemplo, el ojo al ver algo oscuro va a tardar mas en procesarlo que en fondo blanco, pero en cambio, cuando hay colores fuertes sobre fondo oscuro, la información queda mejor grabada en el cerebro. Pero en el caso de programar, nos interesa es tener menor cansancio y ser productivos durante el día.
Si aún no te convences, fíjate en la siguiente imagen extraída del artículo anterior. Cómo es mas fácil de reconocer el rostro de la derecha porque la información que necesita nuestro está en color oscuro y con fondo claro. Si aplicas esta lógica para el código, veras como nuestro cerebro necesita menos tiempo para reconocer texto oscuro en fondo claro. Suma ese tiempo a lo largo del día, cada vez que haces desplazamiento del texto o cambias de ventana, al regresar al editor y leer el código, estarías ahorrando un tiempo.
El rostro de la derecha es mas fácil y rápido de reconocer que de la izquierda. Fuente: Tidibits
Al ver este ejemplo, me convencí de que es mejor tener la tipografía oscura sobre el fondo blanco. Inicialmente era probarlo por una semana pero ya al segundo día vi mejoras y me quedé usándolo.
Mi experiencia usando el tema claro luego de una semana
El cambio mas inmediato que noté fue que al cambiar entre el editor y el navegador. Como la mayoría de las páginas suelen ser fondo claro con letras oscuras. No hay cambio brusco de colores al cambiar de aplicaciones. Imagino que si usas todo en modo oscuro pasa lo mismo, pero la web es clara por defecto y no todas las aplicaciones tienen un modo oscuro.
Durante la semana, si noté menos cansancio lugar de mirar la pantalla luego de varias horas usando el tema claro. El hecho de bajarle el brillo al monitor al principio porque me encandilaba el fondo blanco, posiblemente ayudó a reducir el agotamiento visual. Porque ahora la pantalla no necesitaba tanto brillo para mostrar el contenido a diferencia de cuando el modo oscuro es usado. También indirectamente esto debería disminuir el consumo eléctrico del monitor al requerir menos brillo.
Respecto a los colores del código, no vi ningún cambio porque a pesar de ser diferentes, resaltan la misma información. Durante las primeras horas me costó el cambio pero luego de me adapté.
En mi opinión, si vale la pena cambiar a un tema claro y si siento que me descansa mas la vista al durar varias horas en él. La adaptación me llevó dos días y luego me pareció normal el nuevo esquema de colores.
¿Cuando no recomiendo usarlo?
En monitores antiguos de CRT siento que se cansa mas la vista usando un tema claro, porque hay mas brillo en la pantalla. Pero si tienes un monitor moderno no ocurre lo mismo.
Sin embargo, si tienes una pantalla OLED y necesitas ahorrar batería, usar el modo oscuro puede darte de 3% a 9% mas tiempo de energía. Podría no parecer una cifra significante, pero si estas en una emergencia laboral y no tienes suministro eléctrico. Ese tiempo adicional es valioso.
Otro punto donde no recomiendo, es al momento de explicar o hacer presentaciones. El hecho de usar un fondo oscuro con letras de colores, facilita que se guarde la información del contenido de las palabras. Ahí no importa la velocidad de procesamiento de la información sino que resalte y se almacene en las personas que ven el código.
Recomendaciones finales
Te recomiendo probar durante una semana usar un tema claro. Recuerda que si sientes que te estas cegando de tanta luz, entonces significa que debes bajar el brillo de la pantalla y mejorar la iluminación de la habitación/oficina. Luego en un par de horas es probable que te acostumbres y sientas la diferencia.
