URI.js es una librería de JavaScript que permite trabajar fácilmente con las URIs (o URLs).
En el apartado de documentación podemos encontrar una explicación de los componentes de una URL:
URI.js es una librería de JavaScript que permite trabajar fácilmente con las URIs (o URLs).
En el apartado de documentación podemos encontrar una explicación de los componentes de una URL:
La nueva etiqueta canvas de HTML5 ofrece la posibilidad de trabajar a nivel de pixel en una página web, lo que permite crear animaciones y, por supuesto, videojuegos.
Desgraciadamente, por ahora el soporte de canvas no es completo, así que su uso conlleva los problemas de costumbre cuando aparece una tecnología nueva.
A alguien, a Christer Kaitila, se le ha ocurrido algo: DOM Sprites: A Viable Alternative to Canvas. La verdad es que la demo es impresionante (cientos de sprites moviéndose de forma fluida al mismo tiempo), y lo mejor, es que parece que funciona en casi todo.
¿El problema? Se sigue sin poder trabajar a nivel de pixel, y ciertas operaciones que son necesarias cuando se trabaja con videojuegos no están disponibles de forma nativa con esta solución.
¡Y no te atrevías a preguntar!
Te recomiendo la lectura de los artículos Arrays in JavaScript y What They Didn’t Tell You About ES5’s Array Extras. Te aseguró que te sorprenderás o incluso pensarás que no sabes nada sobre los arrays en JavaScript.
Y para terminar, el vídeo JavaScript: objeto Array del curso iDESWEB, en el que te cuento lo básico sobre los arrays en JavaScript:
[kml_flashembed movie=”http://www.youtube.com/v/DLX2ON9Q7Ao” width=”560″ height=”315″ wmode=”transparent” /]
La programación en el lado del cliente de las aplicaciones web, es decir, la programación con JavaScript en el navegador siempre ha sido poco estructurada, con poca organización. Hasta hace poco eso no era un problema, ya que se programaba poco en el lado del cliente. Si no te preocupabas por escribir “bien”, no era un problema importante.
Sin embargo, desde hace unos cinco años, debido a las “aplicaciones ricas de Internet” (Rich Internet Applications), la programación del lado del cliente ha sufrido un aumento impresionante y organizar bien el código se ha convertido en una prioridad.
En el artículo Client-Side Templating nos presentan una forma de crear plantillas en el lado del cliente y aplicar el patrón modelo, vista, controlador (model, view, controller, MVC). Sin duda alguna, una gran idea.
No te lo recomiendo, con la cantidad de frameworks que ya existen, lanzarse a hacer uno propio es un poco pérdida de tiempo. Recuerda, no reinventes la rueda. Pero quizás tengas entre manos un proyecto especial en el que sea necesario trabajar con un framework propio.
En el sitio web Let’s Make a Framework te explican paso a paso cómo crear tu propio framework de JavaScript. Aunque no lo vayas a hacer, es un recurso muy interesante, ya que te ayuda a comprender cómo están hechos los frameworks que seguramente ya usas.
Más o menos, la mayoría de los desarrolladores web tienen claro la relación que debe existir entre HTML y CSS: se tienen que separar al máximo para intentar reducir el acoplamiento al máximo.
Sin embargo, cuando se plantea la relación entre CSS y JavaScript, muchas veces se olvida lo anterior y se escribe CSS en el código JavaScript.
En el artículo Building A Relationship Between CSS and JavaScript de Smashing Magazine nos explican algunas formas de lograrlo y la importancia de ello.
Impresionante y aterrador todo lo que trae la próxima versión de EcmaScript, el lenguaje de script en el que se basa JavaScript. Se puede decir que es un lenguaje totalmente nuevo. Así que, ya se sabe, habrá que volver al colegio para aprenderlo.
ECMAScript 6 is la próxima versión de este lenguaje de script que es considerado el estándar. A la nueva versión también se la conoce como “Harmony” o “ES.next”.
En la wiki oficial se puede encontrar información sobre la nueva especificación. Pero yo te recomiendo la lectura de algún artículo que te puede ayudar a digerir los cambios, como por ejemplo:
Los errores son algo que me fascinan, por el poder que tienen (las consecuencias de un único error en un programa pueden ser desastrosas) y por lo mucho que se puede aprender de ellos.
En este blog tengo una colección de entradas dedicadas a los errores.
El artículo My Favorite Programming Mistakes es una interesante recopilación de los errores más interesantes que un programador (el que escribe el artículo) ha cometido en JavaScript y PHP. Vale la pena leerlo, seguro que muchos habremos cometido errores parecidos más de una vez.
Hace unos días, el 5 de septiembre de 2012, Twitter actualizó su API a la versión 1.1: Version 1.1 of the Twitter API.
Sin duda alguna, lo que más me sorprendió fue este párrafo:
JSON support only
API v1.1 will support JSON only. We’ve been hinting at this for some time now, first dropping XML support on the Streaming API and more recently on the trends API. We’ve chosen to throw our support behind the JSON format shared across the platform. Consequently, we’ve decided to discontinue support for XML, Atom, and RSS, which are infrequently used today. For historical context, when we originally built the API all major languages did not have performant, well vetted libraries supporting JSON — today they do.
“XML, Atom, and RSS, which are infrequently used today”, ¿en serio?
Un artículo muy interesante y práctico que nos explica cómo manejar la consola de Firebug para ayudarnos a depurar el código JavaScript: Consola de Firebug al detalle.