Café de la semana

Nueva Funcionalidad Añadida a los Sets de JavaScript

Recientemente, JavaScript ha introducido nuevos métodos para los objetos Set. Estos nuevos métodos podrían reemplazar algunas bibliotecas que anteriormente se usaban para el mismo propósito. Esta evolución es ventajosa porque, además de reducir la dependencia de bibliotecas de terceros, estas nuevas funcionalidades ahora son compatibles con los intérpretes de JavaScript en los principales navegadores. Estos métodos también pueden proporcionar ganancias significativas en el rendimiento en comparación con el uso de bibliotecas externas para el mismo efecto, ya que los usuarios no necesitarán descargar código adicional para realizar estas operaciones, ya que ahora están presentes de manera nativa en su navegador. Los dos métodos más relevantes introducidos son intersection y union.

El intersection retorna los elementos comuns de ambos los sets:

const setA = new Set([1, 2, 3, 4, 5, 6]);
const setB = new Set([2, 4, 6, 8, 10]);

const intersectionSet = setA.intersection(setB);
// Set {2, 4, 6}
console.log(intersectionSet);

El union retorna todos los elementos de ambos los sets, sin duplicacíon:

const setA = new Set([1, 2, 3, 4, 5, 6]);
const setB = new Set([2, 4, 6, 8, 10]);

const unionSet = setA.union(setB);
// Set {1, 2, 3, 4, 5, 6, 8, 10}
console.log(unionSet);

Nikita Prokopov's en Bloat de Javascript

La publicación del blog de Nikita Prokopov destaca los tamaños de JavaScript en varios sitios web y aplicaciones en 2024. Por ejemplo, páginas simples como Wikipedia usan 0.2 MB de código JavaScript, mientras que páginas más complejas como Slack pueden llegar a 55 MB. En comparación, la versión original de Doom tenía solo 2.32 MB, y actualmente, según el autor, una página web tiene en promedio 3 MB de JavaScript. En mi opinión, esto se debe a un paradigma de desarrollo común hoy en día, que asume que las computadoras modernas tienen mucho rendimiento y, por lo tanto, podemos escribir código menos eficiente sin que el usuario final note la diferencia. Estoy de acuerdo con esta premisa cuando necesitamos lanzar un producto rápidamente para probar en el mercado, pero a partir del momento en que el mercado valida el producto y señala a través de su compra que quiere que sigamos desarrollándolo, necesitamos adoptar una programación más consciente de las consecuencias en el rendimiento. Es muy común al desarrollar en JavaScript utilizar métodos como forEach y for...of para iterar colecciones, pero estos métodos pueden aumentar significativamente el tiempo de iteración de estos datos en comparación con un bucle for tradicional si iteramos grandes cantidades de datos. En casos específicos, debemos analizar si la elegibilidad del código es realmente tan difícil en comparación con estos métodos y si la ganancia en rendimiento compensa este cambio. Otra práctica común es usar bibliotecas cuando solo necesitamos una función específica. Esto puede ser aceptable si la biblioteca implementa un mecanismo de tree-shake, pero si solo queremos usar una funcionalidad simple, ¿no podríamos desarrollarla nosotros mismos? A menudo, al usar bibliotecas, necesitamos aprender a trabajar con la abstracción que imponen, y a veces podemos pasar más tiempo aprendiendo a trabajar con la abstracción de la biblioteca que implementando la funcionalidad que queremos. Creo que todo esto contribuye a que un paquete de JavaScript tenga mucho más código del estrictamente necesario para la aplicación, lo que resulta en que el usuario final tenga que descargar un paquete de JavaScript más grande, aumentando la latencia de un sitio web al cargar y proporcionando, en consecuencia, una peor experiencia de usuario. Adoptar prácticas de desarrollo más conscientes del rendimiento es esencial para mitigar los tamaños excesivos de los paquetes y mejorar la experiencia de nuestros usuarios.

Desarrollando Nuevos Productos con un Enfoque "Radicalmente Simple"

El enfoque de "Simplicidad Radical en Tecnología", propuesto por Schmidt (2024), aboga por minimizar los componentes y reutilizar tecnologías para agilizar el desarrollo de productos. Esta metodología tiene como objetivo mejorar la incorporación y productividad de los desarrolladores al centrarse en resolver problemas clave en lugar de adoptar nuevas tecnologías por sí mismas. Si bien es beneficioso para las startups que buscan una rápida validación en el mercado, el enfoque puede ser menos adecuado para empresas establecidas que enfrentan desafíos de escalabilidad. La estrategia enfatiza la entrega rápida de funciones y la mejora de la experiencia del usuario, pero su implementación debe considerarse cuidadosamente en función de las necesidades específicas de una empresa y su posición en el mercado.

Clave de Administrador del Repositorio Oficial de Python en un Binario

Esta semana, la empresa JFrog, mientras analizaba el código binario de Python, descubrió una clave de autorización de administrador para el repositorio oficial de Python en GitHub. Aunque esta clave no estaba directamente presente en el código fuente, se encontró en el código compilado. Este descubrimiento destaca cómo un simple error humano puede llevar a fallas de seguridad graves. Actualmente, gran parte del software mundial se ejecuta en Python, y si un agente malintencionado hubiera descubierto esta clave, las consecuencias podrían haber sido catastróficas. Con esta clave, un intruso podría inyectar código malicioso en el repositorio oficial de Python, que luego se incluiría en nuevas versiones de Python descargadas por usuarios de todo el mundo. Este incidente debería alertarnos sobre la importancia de detectar claves de autorización no solo en el código fuente, sino también en los binarios. El error humano es común y puede tener consecuencias desastrosas si es explotado por agentes malintencionados. Por lo tanto, es crucial adoptar medidas de seguridad sólidas que incluyan la revisión tanto del código fuente como de los binarios que se distribuirán a nuestros usuarios.

La Relación de Amor/Odio con CSS

CSS a menudo provoca opiniones diversas entre los desarrolladores. Algunos consideran que escribir CSS es tedioso, otros lo usan solo por necesidad para renderizar algo visualmente atractivo, y pocos lo aman de verdad. Recientemente discutimos internamente un artículo de Li (2024) que destaca las ventajas de CSS. Una de las principales ventajas presentadas es la capacidad de ver los cambios realizados renderizados en segundos. Esto permite un desarrollo incremental rápido de la aplicación. Este ciclo de retroalimentación continua es una de las mayores ventajas de CSS, facilitando ajustes e iteraciones inmediatas. A pesar de esto, CSS es un lenguaje vasto y complejo, con una amplia gama de palabras clave, propiedades y valores. Cuando trabajamos en aplicaciones a gran escala, esta complejidad puede exacerbarse. Gestionar esta complejidad para garantizar la consistencia del diseño y evitar conflictos puede convertirse en una tarea ardua. Sin embargo, considero que CSS es un lenguaje generalmente subestimado por los desarrolladores. En consecuencia, muchos no dedican el tiempo necesario para aprenderlo correctamente. Esto resulta en frustraciones, ya que los desarrolladores no logran obtener los resultados deseados tan rápido como esperaban. Sin embargo, como cualquier lenguaje, cuanto más tiempo dedicamos a aprender CSS, más sentido tiene. Con el tiempo, comenzamos a iterar rápidamente en interfaces en CSS que no serían posibles sin este lenguaje de estilo universal para la Web. La dedicación al estudio de CSS revela su verdadero potencial, transformando la frustración inicial en una herramienta poderosa para crear experiencias visuales ricas y consistentes en la web.

Referências:

1. JFrog. (2024, July 17). Leaked PyPI Secret Token Revealed in Binary Preventing Supply Chain Attack. JFrog. https://jfrog.com/blog/leaked-pypi-secret-token-revealed-in-binary-preventing-suppy-chain-attack/
2. Mursal. (2024, July 20). What's new in web dev this month. DEV Community. https://dev.to/mursalfk/whats-new-in-web-dev-this-month-1al8
3. Li, M. (2024, July 19). 3 Reasons I Love CSS. Atomic Object. https://spin.atomicobject.com/3-reasons-i-love-css/?ref=dailydev
4. Prokopov, N. (2024, July 18). JavaScript Bloat. https://tonsky.me/blog/js-bloat/
5. Schmidt, S. (2024). Radical Simplicity. https://www.radicalsimpli.city/
6. Siddiqui, S. (2022, July 21). Which for-loop is the fastest in JavaScript? DEV Community. https://dev.to/siddiqus/which-for-loop-is-the-fastest-in-javascript-4hdf
7. Faishal, M. (2023, July 22). Benchmarking for, while, for...of, and array.forEach using performance.now. DEV Community. https://dev.to/maafaishal/benchmarking-for-while-forof-and-arrayforeach-using-performancenow-1jjg