ZaRQuN – Diseño Gráfico, Web y Programación Blog sobre diseño grafico en general y curiosidades

Si trabajas con JavaScript o TypeScript y necesitas meter gráficos en una aplicación, seguramente ya te hayas encontrado con un montón de librerías que hacen prácticamente lo mismo. TanStack Charts intenta darle otra vuelta al asunto.

El proyecto forma parte del ecosistema TanStack y propone una forma bastante flexible de construir visualizaciones a partir de una especie de “gramática” de gráficos. En lugar de limitarte a configurar un tipo de gráfico concreto, puedes combinar diferentes elementos, escalas e interacciones para crear visualizaciones más personalizadas.

La idea está basada en TypeScript y utiliza primitivas de D3 cuando necesitas funcionalidades más avanzadas. Puedes empezar con gráficos habituales como barras o líneas y, si el proyecto se complica, añadir escalas o algoritmos específicos de D3 sin tener que cambiar completamente de sistema.

Otro punto interesante es que la definición del gráfico es independiente del framework. El mismo gráfico puede utilizarse con React, Vue, Angular, Svelte, Solid, Preact, Lit, Alpine e incluso con JavaScript sin framework. También contempla renderizado mediante SVG y, de forma opcional, Canvas.

Además, no se queda únicamente en pintar barras y líneas. TanStack Charts incorpora responsive design, márgenes automáticos, temas, tooltips, animaciones, interacción, accesibilidad, renderizado en servidor (SSR) y exportación. Es decir, intenta cubrir buena parte de lo que necesitas cuando un gráfico pasa de ser una simple demo a formar parte de una aplicación real.

Eso sí, hay una advertencia importante: TanStack Charts 0.6.5 está actualmente en fase pre-alpha y su API puede cambiar, por lo que sus propios responsables indican que todavía no está preparado para producción.

Aun así, es un proyecto muy interesante para seguir de cerca, especialmente si trabajas con TypeScript y necesitas visualizaciones que vayan más allá del típico gráfico de barras. Y si ya conoces el ecosistema TanStack, merece la pena echarle un vistazo.

Puedes consultar el código en GitHub de TanStack Charts y la documentación oficial en TanStack Charts.

#TanStack #TanStackCharts #TypeScript #JavaScript #D3js #DataVisualization #DataViz #WebDevelopment #Frontend #React #Angular #Vue #Svelte #WebDesign #Programming

Si trabajas con bases de datos y alguna vez has pensado «solo quiero probar esta consulta SQL rápidamente», RunSQL puede ser una herramienta bastante interesante. La idea es sencilla: llevar el trabajo con SQL directamente al navegador para que puedas ejecutar consultas y experimentar sin tener que preparar todo un entorno de desarrollo desde cero.

Este tipo de herramientas resultan especialmente prácticas cuando estás aprendiendo SQL, quieres comprobar rápidamente cómo funciona una consulta o necesitas hacer pequeñas pruebas antes de llevar el código a tu proyecto. En lugar de abrir tu IDE, conectarte a una base de datos y preparar todo el entorno, tienes una alternativa más rápida para experimentar.

Para quienes programan habitualmente, RunSQL también puede servir como un recurso de apoyo para probar ideas y trabajar con consultas de una forma más directa. Y si estás empezando con SQL, es una manera interesante de familiarizarte con el lenguaje y entender mejor cómo funcionan las consultas sobre datos.

Al final, RunSQL apuesta por algo que cada vez vemos más en el mundo del desarrollo: herramientas que eliminan pasos innecesarios y permiten centrarse directamente en lo que quieres hacer. Si trabajas con SQL o estás aprendiendo a manejar bases de datos, merece la pena echarle un vistazo y comprobar qué posibilidades ofrece.

#RunSQL #SQL #BasesDeDatos #Programación #DesarrolloWeb #DesarrolloSoftware #WebDevelopment #Coding #Programadores #Tecnología #Desarrollo #ProgramaciónWeb

¿Y si el futuro de la inteligencia artificial no está en tener una única empresa controlando los modelos más potentes?

Eso es, precisamente, lo que están defendiendo NVIDIA, Microsoft, Mozilla, Linux Foundation y otras grandes compañías y organizaciones tecnológicas en una carta conjunta sobre los llamados modelos de pesos abiertos (open-weight).

La idea es bastante sencilla: si unas pocas empresas controlan los modelos de IA más avanzados, el resto del mundo acaba dependiendo de ellas. Y eso significa pagar por cada uso, aceptar sus condiciones, confiar en que mantendrán sus servicios y asumir que, si cambian sus precios o políticas, poco puedes hacer.

Los modelos con pesos abiertos plantean otra alternativa. Permiten descargar los pesos del modelo y ejecutarlo, adaptarlo o integrarlo en diferentes infraestructuras. Esto puede facilitar que startups, universidades y empresas desarrollen soluciones de IA sin tener que depender siempre de los grandes proveedores de modelos cerrados.

Y aquí aparece uno de los argumentos más interesantes de la carta: la apertura también puede favorecer la seguridad. La lógica es que cuantos más investigadores y desarrolladores puedan analizar, probar y auditar una tecnología, más posibilidades existen de encontrar problemas y mejorarla. La Linux Foundation defiende precisamente que los modelos abiertos y los pesos abiertos son una pieza importante para construir una IA más segura y con mayor capacidad de supervisión.

Pero hay otro punto que está levantando bastante debate: la destilación de modelos.

En términos sencillos, consiste en utilizar las respuestas generadas por un modelo para ayudar a entrenar o mejorar otro. Es una técnica habitual en el desarrollo de sistemas de IA y puede servir para crear modelos más pequeños y eficientes. La carta defiende que esta práctica puede ser legítima y que no debería considerarse automáticamente un robo o una infracción. Eso sí, hay una diferencia importante entre utilizar técnicas de destilación y apropiarse de propiedad intelectual protegida: una cosa no implica necesariamente la otra.

La frase que más llama la atención es probablemente la que plantea que depender únicamente de modelos cerrados no es intrínsecamente más seguro. Y aquí está el verdadero debate.

Los modelos cerrados tienen ventajas evidentes: sus propietarios pueden controlar mejor el acceso, aplicar filtros y gestionar determinadas medidas de seguridad. Pero los modelos abiertos permiten una mayor capacidad de análisis externo, personalización y control sobre dónde y cómo se ejecuta la IA.

Eso sí, tampoco hay que confundir open-weight con open source. Un modelo puede ofrecer sus pesos para que otros lo descarguen y ejecuten, pero no publicar todo su código de entrenamiento, los datos utilizados o el proceso completo de desarrollo. Por eso, hablar de «IA abierta» puede ser bastante más complejo de lo que parece.

Lo interesante de todo esto es quién está firmando la carta. NVIDIA, Microsoft, Meta, IBM, Mozilla, Linux Foundation y otras organizaciones están defendiendo que la competición en IA no debería depender únicamente de quién tiene el modelo más potente, sino también de quién consigue crear un ecosistema donde más empresas y desarrolladores puedan construir sobre esa tecnología.

Y hay una lectura económica bastante clara: más modelos abiertos significa más competencia, más alternativas y potencialmente menos dependencia de unos pocos gigantes tecnológicos. También puede reducir costes y permitir que una empresa elija qué modelo utilizar según sus necesidades, en lugar de estar atada a un único proveedor.

La batalla por el futuro de la IA, por tanto, no se está librando solo entre modelos. También se está librando entre dos formas de entender cómo debería distribuirse esta tecnología: una IA controlada por unos pocos proveedores o un ecosistema donde cualquiera pueda descargar modelos, experimentar con ellos y construir nuevas herramientas.

Y viendo quién se ha sentado ahora en el lado de los pesos abiertos, parece que esta discusión acaba de ponerse bastante más interesante.

#InteligenciaArtificial #IA #OpenAI #OpenSource #OpenWeights #ModelosAbiertos #NVIDIA #Microsoft #Mozilla #LinuxFoundation #Tecnología #Programación #Desarrollo #MachineLearning #DeepLearning #IAGenerativa #Software

Si trabajas programando con IA y estás cansado de configurar cada herramienta con un proveedor diferente, OmniRoute puede ser una opción bastante interesante. La idea es sencilla: en lugar de conectar tu IDE o agente de código con cada API por separado, OmniRoute actúa como una capa intermedia que centraliza el acceso a cientos de proveedores de modelos de IA desde un único endpoint.

Una de sus funciones más interesantes es el auto-fallback. Si un proveedor alcanza su límite o deja de estar disponible, OmniRoute puede cambiar automáticamente a otro proveedor para que el trabajo continúe. También permite utilizar estrategias de routing para priorizar proveedores gratuitos, reducir costes o elegir automáticamente la opción más adecuada para cada petición.

Además, es compatible con herramientas habituales del desarrollo asistido por IA como Claude Code, Codex, Cursor, Cline o GitHub Copilot, entre otras. También incorpora funciones como compresión de tokens, memoria, MCP y soporte para protocolos de agentes, por lo que va bastante más allá de ser un simple proxy de APIs.

La instalación también busca ser sencilla: puedes ejecutarlo mediante npm, Docker, como aplicación de escritorio o incluso en dispositivos ARM. Una vez funcionando, tus herramientas pueden apuntar a un único endpoint local y dejar que OmniRoute se encargue del routing entre los distintos proveedores.

Para quienes están metidos de lleno en el desarrollo con IA, es una herramienta que merece la pena echar un vistazo. Especialmente si utilizas varios modelos, quieres aprovechar diferentes planes gratuitos o simplemente buscas tener una configuración más centralizada y flexible.

#OmniRoute #AI #ArtificialIntelligence #IA #AIGateway #OpenSource #Programacion #Desarrollo #Coding #DevTools #ClaudeCode #Codex #Cursor #MCP #LL

Si llevas poco tiempo programando en JavaScript, probablemente todavía no hayas tenido que pelearte con el objeto Date. Si es así, enhorabuena: estás llegando justo cuando las cosas empiezan a cambiar para mejor.

Date existe desde 1995 y arrastra decisiones que hoy parecen difíciles de justificar. Los meses empiezan en cero, las zonas horarias pueden jugarte malas pasadas y una fecha puede modificarse desde cualquier parte del código sin que te des cuenta. No es casualidad que durante años hayan aparecido librerías como Moment.js, Luxon o date-fns para intentar hacer más llevadero el trabajo con fechas.

La buena noticia es que Node.js 26 activa por defecto Temporal, la API moderna que sustituye a Date. Su objetivo es muy claro: trabajar con fechas y horas sin sorpresas. Las fechas son inmutables, existen tipos específicos para fechas, horas y zonas horarias, y los cálculos de calendario son mucho más fiables.

En otras palabras, uno de los mayores quebraderos de cabeza de JavaScript por fin tiene una solución oficial.

Y aquí hay una lección interesante para quien está aprendiendo. La primera es práctica: si empiezas ahora con JavaScript, merece la pena aprender Temporal desde el principio y evitar muchos de los problemas que generaciones de desarrolladores tuvieron que soportar.

La segunda es casi una filosofía de aprendizaje. Muchas veces pensamos que llegamos tarde a una tecnología, pero los lenguajes evolucionan constantemente. Los que empiezan hoy no solo aprenden más rápido, sino que en ocasiones aprenden directamente la versión buena, sin cargar con años de trucos, parches y malas costumbres.

Temporal en JavaScript: guía rápida y ejemplos

Temporal ofrece una forma fiable y predecible de trabajar con fechas y horas. A continuación se presentan ejemplos prácticos para empezar a usarlo hoy mismo.

Crear y formatear fechas

// Asumiendo que Temporal está disponible (Node.js 26+ o polyfill si corresponde)
const todayISO = Temporal.Now.plainDateISO(); // PlainDate
console.log(todayISO.toString()); // e.g., 2026-07-09

const specificDate = Temporal.PlainDate.from('2024-12-25');
console.log(specificDate.toString()); // 2024-12-25

Sumar y restar tiempo

const date = Temporal.PlainDate.from('2024-03-15');

// Sumar 2 meses
const plusTwoMonths = date.add({ months: 2 });
console.log(plusTwoMonths.toString()); // 2024-05-15

// Restar 10 días
const minusTenDays = date.subtract({ days: 10 });
console.log(minusTenDays.toString()); // 2024-03-05

Trabajar con horas y zonas horarias

// Instant en UTC y conversión con zona específica
const instant = Temporal.Now.instant();
const zoned = instant.toZonedDateTimeISO('Europe/Madrid');
console.log(zoned.toString()); // 2024-...T...
console.log(zoned.hour);        // hora en la zona indicada

// Creación de un PlainDateTime y su conversión a ZonedDateTime
const dt = Temporal.PlainDateTime.from('2024-07-09T12:00');
const madrid = dt.toZonedDateTime( Temporal.TimeZone.from('Europe/Madrid') );
console.log(madrid.toString());

Diferencias clave frente a Date

// Date tiene meses basados en  y mutabilidad implícita
const d = new Date(2024, , 31); // 31 de enero de 2024 (confusión frecuente)
d.setMonth(d.getMonth() + 1);
console.log(d.toISOString()); // 2024-03-02T...


// Temporal evita sorpresas: objetos inmutables y tipos explícitos
const t = Temporal.PlainDate.from('2024-01-31');
const nextMonth = t.add({ months: 1 });
console.log(nextMonth.toString()); // 2024-02-29 (manejo claro de meses)

Consejos de migración

• Preferir PlainDate, PlainTime y PlainDateTime para valores sin zona horaria variable.
• Usar ZonedDateTime cuando se trabajen fechas y horas con zonas horarias específicas.
• Mantener inmutabilidad para evitar efectos secundarios inesperados durante cálculos.

Enlaces y conceptos clave

• Temporal.PlainDate, Temporal.PlainTime, Temporal.PlainDateTime
• Temporal.ZonedDateTime para zonas horarias
• Temporal.Now y Temporal.Instant para instantes precisos
• Conversión entre instantes y zonas horarias con toZonedDateTimeISO o toZonedDateTime

Si se desea, puedo adaptar este contenido para un formato específico (guía paso a paso, fragmentos reutilizables en snippets, o una versión enfocada a migración desde Date).

#JavaScript #NodeJS #NodeJS26 #Temporal #WebDevelopment #Programacion #DesarrolloWeb #Frontend #Backend #ECMAScript #Codigo #Developer #DevLife #SoftwareEngineerin

Si trabajas con React, Vue, Angular, Svelte o cualquier otro framework moderno, es muy probable que hayas oído hablar de Storybook. Y si todavía no lo utilizas, puede que estés perdiendo una de las herramientas que más tiempo ahorra en el desarrollo de interfaces.

La idea es muy simple: en lugar de arrancar toda la aplicación cada vez que quieres modificar un botón, un formulario o una tarjeta, Storybook te permite desarrollar cada componente por separado. Es como tener un laboratorio donde probar todos los estados posibles de una interfaz sin depender de APIs, bases de datos o lógica de negocio.

Cada variante de un componente se guarda como una «story». Gracias a eso puedes comprobar rápidamente cómo se comporta un botón deshabilitado, una alerta de error o un formulario con datos reales sin tener que navegar por toda la aplicación para llegar a ese punto.

Pero Storybook ya no sirve únicamente para desarrollar componentes. También genera documentación automática, facilita la creación de Design Systems, permite realizar pruebas visuales, test de interacción y comprobaciones de accesibilidad desde un único lugar. Todo ello convierte la biblioteca de componentes en una fuente de verdad para diseñadores y desarrolladores.

Otra de sus grandes ventajas es que se integra con la mayoría de herramientas habituales del ecosistema frontend, desde React y Next.js hasta Vue, Angular o Web Components. Además, admite cientos de integraciones que amplían todavía más sus posibilidades sin obligarte a cambiar tu flujo de trabajo.

No es casualidad que miles de empresas lo utilicen para mantener sus sistemas de diseño organizados y que millones de desarrolladores lo tengan instalado en sus proyectos. Si alguna vez has perdido tiempo buscando dónde se usa un componente o intentando reproducir un estado concreto de la interfaz, Storybook probablemente sea la solución que estabas buscando.

En un momento donde los proyectos frontend son cada vez más complejos y la reutilización de componentes es la norma, Storybook se ha convertido en una herramienta casi imprescindible para desarrollar interfaces más rápidas, consistentes y fáciles de mantener.

#Storybook #Frontend #JavaScript #React #Vue #Angular #UI #DesignSystem #WebDevelopment #Programación #DesarrolloWeb #OpenSource #FrontendDeveloper #CSS #DeveloperTools

Si estás desarrollando una aplicación con IA, haciendo pruebas o simplemente experimentando con modelos de lenguaje, seguramente te has encontrado con el mismo problema: casi todas las APIs interesantes terminan pasando por caja. Ahí es donde entra en juego Free LLM API Resources, un repositorio que se ha convertido en uno de los recursos más útiles para cualquier desarrollador que trabaje con inteligencia artificial.

La idea es sencilla pero tremendamente práctica: reunir en un único lugar todos los proveedores que ofrecen acceso gratuito o créditos iniciales para utilizar modelos de lenguaje mediante API. En la lista aparecen plataformas conocidas como OpenRouter, Google AI Studio, Groq, Cohere, GitHub Models, Cloudflare Workers AI o NVIDIA NIM, junto a sus límites de uso, cuotas disponibles y modelos compatibles.

Lo interesante no es solo la cantidad de servicios recopilados, sino el tiempo que ahorra. En lugar de investigar proveedor por proveedor para descubrir si tienen plan gratuito, límites diarios o créditos promocionales, aquí tienes una comparativa actualizada que te permite elegir rápidamente la mejor opción para tu proyecto.

Para quienes crean prototipos, herramientas internas, bots, extensiones o proyectos personales, este repositorio puede significar la diferencia entre empezar hoy mismo o perder horas buscando alternativas. Además, incluye tanto proveedores con planes gratuitos permanentes como servicios que ofrecen créditos de prueba para lanzar proyectos más ambiciosos sin inversión inicial.

No es casualidad que haya acumulado decenas de miles de estrellas en GitHub. Se ha convertido en una referencia habitual entre desarrolladores que buscan experimentar con modelos de IA sin disparar costes desde el primer día. Si trabajas con inteligencia artificial, merece un lugar fijo en tus marcadores.

#IA #InteligenciaArtificial #LLM #API #DesarrolloWeb #Programacion #OpenSource #GitHub #MachineLearning #Desarrolladores #AITools #Tech

La inteligencia artificial es muy buena escribiendo código, pero también tiene una peligrosa afición por complicar tareas sencillas. Ahí es donde entra Ponytail, un proyecto open source creado por Dietrich Gebert que intenta enseñar a los agentes de programación una habilidad que muchos desarrolladores veteranos dominan desde hace años: no escribir código cuando no hace falta.

La idea detrás de Ponytail es sorprendentemente simple. Antes de generar una solución, obliga a la IA a hacerse varias preguntas: ¿realmente hay que crear esto?, ¿ya existe en la librería estándar?, ¿el navegador o el sistema operativo ya lo resuelven?, ¿alguna dependencia instalada lo hace? Solo cuando todas las respuestas son negativas permite escribir código nuevo.

El resultado, según los benchmarks publicados por el proyecto, es una reducción drástica del volumen de código generado, menores costes de uso de modelos de IA y tiempos de respuesta mucho más rápidos. Todo gracias a una filosofía basada en YAGNI («You Aren’t Gonna Need It»), un principio clásico que combate la sobreingeniería.

Uno de los ejemplos más divertidos es el de un selector de fechas. Mientras un agente convencional podría instalar una librería completa, crear componentes personalizados y añadir estilos, Ponytail simplemente recuerda que HTML ya incluye <input type="date"> y que probablemente no necesitas nada más.

Lo interesante es que Ponytail no es un modelo de IA ni un asistente independiente. Funciona como una capa de comportamiento compatible con herramientas como Codex, Claude Code, Cursor, OpenCode y otros entornos de desarrollo asistidos por IA. Su objetivo no es hacer que la IA programe más, sino que programe mejor.

En una época donde muchos proyectos terminan con cientos de líneas de código innecesarias, Ponytail apuesta por algo mucho más revolucionario: la simplicidad.

Repositorio oficial: Ponytail en GitHub

#Ponytail #GitHub #OpenSource #Programacion #DesarrolloWeb #Codex #ClaudeCode #IA #DeveloperTools #SoftwareDevelopment #Coding #Tech #Productividad #DevLife #AIProgramming

Aquí hay que ser claros: no es que “Fable 5” sea una herramienta mágica nueva, sino más bien una forma de nombrar la evolución que está empujando Anthropic con Claude en el terreno creativo y generativo. Y lo interesante no es el nombre, es lo que cambia para diseñadores y devs.

Para diseño, la novedad más bestia es que dejamos de trabajar solo con pantallas estáticas. Ahora el contenido puede generarse en tiempo real según contexto, usuario o intención. Eso significa que el diseñador ya no está solo pensando en UI, sino en sistemas de comportamiento. Interfaces que no son fijas, sino que “responden”. UX más viva, más variable, menos predecible… y eso obliga a diseñar con reglas, no solo con layouts.

Otra cosa importante: el contenido deja de ser un “asset” cerrado. Antes diseñabas textos, estados, variantes… ahora diseñas estructuras que generan esos elementos. Es como pasar de dibujar cada frame a diseñar el motor que los crea.

En desarrollo, el cambio es igual o más profundo. Las APIs de IA no son solo una feature más, se convierten en parte del core lógico del producto. Empiezas a trabajar con prompts como configuración, estados conversacionales como máquinas de estado, y flujos que no están 100% definidos en el código clásico.

Esto tiene una parte brutal: velocidad. Puedes prototipar ideas complejas muchísimo más rápido. Interfaces, juegos narrativos, asistentes, SaaS dinámicos… cosas que antes requerían semanas de iteración ahora se testean en horas.

Pero también hay una parte menos sexy: control y consistencia. Si el sistema genera contenido, tú tienes que diseñar los límites. Qué puede hacer, qué no, cómo se comporta en edge cases, cómo mantienes coherencia. Eso es nuevo terreno para muchos devs: mezclar ingeniería con diseño de comportamiento.

Y lo más interesante de todo esto es el cambio mental: ya no diseñas pantallas o funciones aisladas. Diseñas sistemas vivos que producen experiencia.

#Claude #Anthropic #IA #DiseñoUX #UI #Programación #CreativeCoding #DesignSystems #UXDesign #AIProducts #Desarrollo

Si utilizas GitHub Copilot a diario, hay un cambio importante que no deberías pasar por alto. Desde el pasado 1 de junio, GitHub ha comenzado a aplicar un modelo de facturación basado en el consumo real de tokens para determinadas funciones de Copilot. En otras palabras, ya no basta con tener una suscripción: ahora conviene vigilar cómo y cuánto utilizas la herramienta.

Lo primero que recomendamos es establecer un límite de gasto de 0 dólares. Puede parecer exagerado, pero es la forma más sencilla de evitar sorpresas mientras entiendes cómo funciona el nuevo sistema. Siempre habrá tiempo para aumentar ese límite cuando tengas claro cuál es tu consumo habitual.

También merece la pena identificar qué tareas son las que más créditos consumen. Un autocompletado rápido apenas tiene impacto, pero las sesiones agénticas largas, los análisis complejos o los flujos que utilizan varias herramientas pueden disparar el consumo mucho más de lo que imaginas.

Otro aspecto clave es elegir el modelo adecuado para cada trabajo. Los modelos más avanzados suelen ofrecer mejores resultados, pero también consumen más créditos. Para tareas rutinarias, generación de código sencilla o consultas rápidas, los modelos ligeros suelen ser más que suficientes.

Ojo también con las revisiones de código automáticas. El nuevo sistema no solo puede consumir créditos de Copilot, sino también recursos de GitHub Actions. Si trabajas en equipo, configurar correctamente los runners a nivel de organización puede ayudarte a mantener los costes bajo control.

La buena noticia es que GitHub ha habilitado un periodo de transición entre junio y septiembre con créditos adicionales para facilitar la adaptación. Es el momento perfecto para medir, probar y entender cómo afecta este cambio a tu flujo de trabajo. No te confíes demasiado, porque cuando llegue octubre las condiciones serán diferentes y conviene llegar preparado.

Y precisamente ahí está la clave de todo: medir. La única forma real de saber si GitHub Copilot sigue siendo rentable para tu equipo o proyecto es comparar productividad y costes con datos reales. Si algo ha quedado claro con este cambio es que la inteligencia artificial ya no solo se evalúa por lo que hace, sino también por lo que cuesta hacerla funcionar.

#GitHub #GitHubCopilot #Programacion #DesarrolloWeb #Developer #Coding #IA #InteligenciaArtificial #OpenAI #SoftwareDevelopment #DevTools #GitHubActions #Productividad #Tecnologia #CodeReview