Alpha's Manifesto

A black and white figure's thought-hive

Comentarios sobre The State of Responsive Web Design

Opiniones propias sobre muchos problemas mencionados

Acabo de terminar de leer un artículo largo y genial de Smashing Magazine, llamado The State of Responsive Web Design. Como el título lo indica, habla sobre el estado actual del diseño de webs responsive y sus pros y contras. Mucho mejor aún, habla de los distintos problemas a superar y la forma en la que la tecnología de hoy nos permite hacerlo. Pero no es una introducción al tema, sino que abarca todos esos problemas que aún no tienen soluciones definitivas. Totalmente novedoso.

Sin embargo, como bien dicen al final, esto no es ni el comienzo, y sobre las cosas mencionadas tengo mucho que mencionar. Quería dejar mis comentarios por aquí.

(Read more →)

Programando Arkanoid – Parte 1

Cómo hacer un pequeño juego en JavaScript y HTML5 canvas

Haciendo ya mucho tiempo que no trabajaba en JavaScript sin la utilización de ningún framework, me propuse crear algo simple que a la vez fuera divertido. Pensé en algunas opciones y la ganadora fue un juego de Arkanoid (que, ahora me entero, es una de las tantas copias del Breakout, y para mi el nombre original siempre fue Arkanoid, en fin).

El resultado final lo pueden ver aquí y el código fuente está en mi repositorio de GitHub, pero no es tanto el resultado sino el viaje lo que fue interesante, y quiero describir las cosas que aprendí en ese camino.

Vengan y acompáñenme en mi viaje.

(Read more →)

Responsive Web vs. Mobile Web

¿Qué son y cuándo usar cada uno?

Pantallas y tamaños

Ahora que el mundo web se ha acelerado de forma increíble, CSS3 y HTML5 son más y más poderosos cada día. Una de las características que trajo CSS3 son media queries, que habilitan un nuevo tipo de sitio llamado responsive web. ¿Qué es esto y cómo nos afecta?

(Read more →)

VS2012, día cuatro

Videos resumidos luego del release oficial

Introducción

Ya casi llegando al final de esta investigación sobre qué tiene Vs2012 para ofrecernos, estoy ya probando la versión oficial, ya lista para trabajo en producción. Mucho de lo que encontré en ella no es una sorpresa para mí, y mis entregas anteriores se hicieron desde el Release Candidate. Hay muchos más cambios que ocurrieron entre ese RC y la versión final, algunas superficiales (como la pantalla de Start Page), otras debo descubrirlas aún.

Hay muchos más videos al respecto que dejaré a disposición de ustedes, pero esta vez, en lugar de agrupar el contenido por video, lo haré por funcionalidad y dejaré las referencias al final. Sin embargo, voy adelantando que muchos de ellos vienen directamente de Visual Studio 2012 Premium and Ultimate Overview de Channel 9, y del blog de Scott Hanselman.

(Read more →)

Mobile: ¿Web o lenguajes nativos?

Sobre cómo elegir la tecnología correcta

Cuando una organización, por grande o pequeña que sea, quiere comenzar su presencia en el mercado mobile, hay una pregumta que siempre surge y que muchas veces no les resulta fácil resolver. ¿Qué es más conveniente: utilizar tecnologías web y sus capabilidades para llegar a todos los dispositivos, o utilizar el framework propio de los dispositivos para utilizar todo el potencial que ellos ofrecen?

Está claro que una solución web puede hacer uso de todas las nuevas tecnologías, incluyendo HTML5, CSS3, las nuevas versiones de JavaScript y una variedad de trucos que muchos programadores conocen, pero utilizar el lenguaje nativo de los dispositivos hace que nada sea imposible. Entonces, ¿cuál es la más apropiada?

Como siempre, la respuesta correcta no es absoluta, sino que varios factores juegan al momento de una desición estratégica. Primero, consideremos los beneficios y problemas de cada elección, lado a lado.

 Web (HTML, JS, CSS) Lenguaje nativo
A favor
  • Cross-browser
  • Curva de aprendizaje suave
  • Estándares definidos
  • Alto nivel
  • Acceso a cualquier funcionalidad del dispositivo
  • Mejor performance
  • Look and feel consistente con otras apps
  • Capacidad de reinventar el UI completamente
En contra
  • No toda funcionalidad de dispositivo móvil está disponible
  • Distintos niveles de implementación según el navegador
  • Estándares todavía en desarrollo
  • Requiere conectividad, al menos en algún punto
  • Requiere instalación de una aplicación
  • Diferentes según dispositivos, modelos y versiones
  • Diferentes políticas de market
  • Requiere de uso de licencias para algunos markets
  • Requiere aprendizaje y especialización
  • Los ciclos de vida los determina el market

Existe una tercera opción que he elegido no listar: los híbridos. Son compañías o frameworks que aseguran la llegada a una mayoría de dispositivos, solucionando la necesidad de aprender distintos lenguajes. Sin embargo, estas soluciones por lo general son tercerizadas (es decir, corren la aplicación por su cuenta), o son wrappers (es decir, toda nuestra aplicación corre dentro de otra aplicación que ellos proveen) o simplemente revierten a aplicaciones HTML sin demasiado poder. El mercado todavía está surgiendo para estos frameworks y hay resultados muy variados con ellos aún, razón por la cual he elegido dejarlos fuera de la consideración de hoy.

Tomar una decisión según cuál opción tenga más ítems de su lado puede parecer una solución fácil, pero realmente no es la más sabia. La decisión debe alinearse con los objetivos estratégicos de la organización, incluyendo el mercado destino, el tipo de usuario que se espera tener, los recursos disponibles para afrontar el desarrollo, y el tipo de llegada que la aplicación desea tener.

Como un buen ejemplo, muchas empresas grandes quieren entrar al mercado mobile, y deben hacer algo digno de su nombre, pero quieren tener presencia en todos los dispositivos. Al mismo tiempo, startups pequeñas quieren hacer una inversión pequeña para aproximarse al mercado. En estos casos la mejor opción será web, excepto que requieran capacidades especiales (como acceso a la red celular, o acceso USB, etcétera).

En los otros casos, o cuando el público destino es un conjunto de usuarios muy particular, las soluciones nativas pueden ser las más apropiadas. Por ejemplo, cuando el usuario serán oficiales de seguridad de una empresa, haciendo uso de la cámara o acelerómetro del teléfono, las organizaciones pueden decidir que tal o cuál marca de dispositivo con tal o cuál versión será la apropiada y reducir el desarrollo a un sólo lenguaje.

Front-end code standards

Una aproximación de best practices

Acabo de leer el artículo de IsoBar Front-end Code Standards & Best Practices. El artículo cubre de forma extensiva varias de las tecnologías utilizadas, con las sugerencias que esta empresa utiliza interamente. Cubre varios aspectos del uso de HTML (y algunas nuevas características de HTML5), CSS (y algunas nuevas características de CSS3), JavaScript, Performance, e integración cross-browser.

Personalmente no me siento de acuerdo con la totalidad de los items mencionados, pero creo que como punto de partida es muy bueno. Tienen una buena cantidad de referencias al por qué conviene hacer las cosas de la forma que ahí están explicadas, y muchas veces las razones son totalmente válidas. Muchas veces también se pesan pros y contras de cada aproximación, lo cual ayuda a tomar una decisión educada del proceso que elijamos seguir.

Soy un zorrinito front-end.

CSS Dinámico

Post procesamiento vs. preprocesamiento

Para los que conocemos y usamos Less o sus variantes, nos alegraríamos mucho de saber que CSS pueda agregar capacidades similares. A pesar de que gran parte de la comunidad esté en desacuerdo (¡Gracias, AM!), yo creo que serían útiles, por varias razones. (Invito a discutir a quién piense distinto.)

  • Por un lado, permitirán la inserción fácil de quienes no dominen CSS completamente. Está claro que significa que se pueden resolver cosas de una forma no tan prolija, pero los lenguajes tratan de facilitarnos las tareas a nosotros, no imponernos reglas que debemos seguir. Cuando existe esa diferenciación es cuando comienzan a surgir buenas prácticas.
  • Por otro lado, permitirá la creación de frameworks más dinámicos, sin uso de JavaScript. Frameworks CSS que sean adaptables al uso de los usuarios, multi-navegador y apropiadamente utilizables. De la misma forma que Bootstrap tiene variables globales que se pueden cambiar para ajustar su comportamiento, así serían más dinámicos y reutilizables.
  • Por otro lado más: reutilización. Muchas veces los esquemas de colores se basan en un conjunto limitado de los mismos. Si los tamaños de fuentes ya admiten relaciones entre ellos, ¿por qué no los colores, por qué no condicionales que devuelvan un valor según el valor padre? (Nuevamente, en favor de los CSSs consistentes cross-browsers.)
  • Minimización de hacks. Por partida doble. En el primer aspecto, por todo lo que nombré. En el segundo aspecto, por la posibilidad de limitarlos a lo necesario y sólo reutilizarlos como referencia (lo que Less denomina mixins).

Todo esto venía a los links que me encontré, relativamente novedosos: Calc() para CSS, un operador que calcula valores en base a los argumentos que se le pasen. Creo que este pedacito de código lo paga todo:

[sourcecode language=”css”]
#foo {
width: calc(50% – 100px);
}
<div id=”foo”>Always 100 pixels less than half the available area</div>
[/sourcecode]

Por otro lado, Scoped Styles, algo que sólo veo como utilidad al momento de permitir usuarios escribir su propio CSS (apropiado para SaaS en donde los usuarios tengan su propio espacio). No soy muy fanático de esta funcionalidad, pero reconozco que resuelve un problema existente.

Soy un zorrinito dinámico.

Estilos en IE8-

Y mi sobrada misericordia

Me acabo de dar cuenta, de casualidad, que los estilos del blog no estaban funcionando en IE8-, debido a la presencia de elementos de HTML5, que, para ser breve, rompían todo. Tengo sentimientos encontrados y noticias acordes.

Por un lado, si es que estabas usando IE8- y visitando mi blog, asumo que debés de estar de pasada, no creo que seas el tipo de audiencia que lee este blog. Por lo general la gente acá utiliza Chrome o Firefox, y siempre en las versiones más actuales. Lamento decirlo, pero surfers de IE, son una minoría.

Por otro lado, les perdono que no hayan actualizado y ya solucioné el problema. Disfruten de dos colores más.

PS: Ahora tenemos búsqueda. ¡Wheeee!

Soy un zorrinito misericordioso.

Limpiando el CSS

De forma casi automatizada

Como siempre, yo sacando cosas de los foros de StackExchange, en este caso de ProWebmasters. La pregunta fue: Cómo trabajar con archivos CSS viejos? Específicamente, cuando estos archivos se vuelven enormes, y cuando ya no estamos seguros de qué está en uso, qué quedó en desuso, qué está repetido, qué se puede resumir, etc. Cuando tenemos un proyecto de ya un par de años, esto se hace muy difícil de medir.

La respuesta provee una buena cantidad de herramientas para probar que nos permite facilitar este trabajo, algunos de los cuales trabajan sólo en la página actual mientras que otros pueden realmente recorrer el sitio o usar un listado de URLs que les proveemos.

Soy un zorrinito limpio.

DotLess

Precompilación de CSS para .NET

Sé que esto no es ninguna novedad, pero lo explico para el que no lo conozca: less es un componente JavaScript que nos permite tener más flexibilidad en el tipo de cosas que podemos escribir en nuestros archivos CSS. Estos archivos pasan luego a llamarse archivos less, con una sintaxis muy parecida a CSS, pero con algunas mejoras, como la definición de variables, mixins (“funciones”) y anidamiento (namespacing?) de declaraciones. Como bien dicen entonces, less is more.

Ahora, uno de los grandes problemas con esto es que less es JavaScript, y por tanto, no está bueno que cada navegador tenga el trabajo de pre-compilar el CSS y aplicarlo a cada página. Es un poco trabajoso (dependiendo de la complejidad de nuestros estilos y nuestras páginas), pero está claro que es demasiado trabajo. Alguien preguntó si había una forma de compilar los archivos less a CSS para que cada navegador no tenga que hacerlo, y obtuvo una buena cantidad de alternativas.

Yo encontré una no mencionada, y sacada directamente de NuGet, dotless es la portación de esto mismo a .NET, con la diferencia de que está implementado en forma de HTTP Handler, lo que significa que el browser se encarga de resolver los pedidos de archivos .less y devolverlos como CSS. Mejor aún, ya puede devolverlos minimizados y cachearlos. Dije que es un paquete Nuget? La instalación en sí son 4 clicks. Muy adecuado.

Soy un zorrinito cómodo.