Cuando escribí el libro Phoenix Framework: Red Social en 7 días me pregunté si valdría la pena incluir LiveView, en esos momentos se incluía por defecto con Phoenix Framework y me preguntaba si sería estable, no obstante, no consideré que fuera el momento, ¿lo es ahora?

El pasado 11 de abril tuve la fortuna de poder entrevistar a Louis Pilfold, creador del lenguaje Gleam. Hablamos durante una hora sobre el lenguaje, su futuro y sus orígenes, ¿damos una vuelta por Gleam?

Hasta Phoenix Framework 1.3 veníamos empleando Brunch como gestor de arranque, en la versión 1.4 cambió a Webpack y ahora en la versión 1.6 va a cambiar a Esbuild. ¿Por qué el ecosistema de JavaScript cambia tanto?

Después de hablar sobre protocolos como HTTP/2 creo que es momento de centrar el foco en WebAssembly. He estado jugando un poco con Rust y creo que es interesante lo que podemos conseguir, ¿quieres saber cómo funciona y qué es WebAssembly?

Hace prácticamente un año escribí un artículo denominado Spidermonkey: extendiendo PHP, donde comentaba como emplear Spidermonkey para poder emplearlo como lenguaje de extensión a un núcleo sencillo hecho en PHP.

El servidor Node.js vio la luz de manos de Ryan Dahl en 2009, la motivación, según la entrevista que BostInno le realizó en enero de 2011, es la arquitectura de E/S orientada a eventos.

Después de bastante tiempo de trabajo, al fin, conseguí liberar la primera versión estable de PHAS-JS, un servidor de aplicaciones JavaScript con base en PHP e interfaz de administración en Django.

Hace tiempo que vi este lenguaje de pasada y no le presté mucha atención, pero hoy, revisando algunas cosas, he vuelto a él y he visto algo que, antes quizás me habría parecido ridículo, pero ahora, después de ciertos acontecimientos, comienzo a verle mucho sentido.

Hace tiempo que tenía pendiente dar una vuelta a las base de datos NoSQL para mostrar un poco el cómo funcionan, qué se puede hacer con ellas y cómo se comportan en ciertas situaciones específicas.

Después de leer la liberación de Rails 3.1, me topé con que trae por defecto este sistema para facilitar la escritura de código JavaScript. Es curioso que lo traiga activo por defecto, ya que hay muchos a los que les gusta el lenguaje JavaScript y pueden haberse tomado mal esta decisión... no obstante yo lo veo bastante acertado, más que nada porque el código de CoffeeScript me resulta muy claro y limpio, en comparación con JavaScript y, lo mejor de todo, es que resulta incluso hasta más fácil de portar entre navegadores.

Hay muchas veces que nos encontramos con el problema de que queremos extender la funcionalidad de nuestro programa por extensiones, plugins, addons o como los queramos llamar. Estas extensiones tienen el problema de que pueden afectar al funcionamiento del resto del programa si lo ejecutamos directamente desde el core del programa que estemos haciendo, quedando el mismo en una situación inestable o nada funcional.

Cuando se pensaba en MVC, la capacidad para dividir las tareas obvias de tratamiento de datos, en lógica de negocio (el modelo), control de flujo de ejecución (el controlador) y la presentación de datos (la vista), aún quedaban en el aire muchos problemas en lo que respecta a las interaces, propiamente dichas, entre estas tres capas.

Centrándonos en la vista, existen miles de soluciones, para alejar al diseñador del código y al programador del diseño, pero aún así, cuando se habla de AJAX y desarrollos específicos... el programador tiene que tocar diseño y el diseñador preocuparse de lo que hará el código de servidor.