Capítulo 4. Los lenguajes

Jon Postel 9,57 era uno de los ingenieros que trabajaban en ARPANET 8,58, la precursora de internet. Quería asegurar que los paquetes – o “datagramas”-que se enviaban alrededor de la red llegaran a su destino de la forma más eficiente. Se dio cuenta que un enfoque laxista de los errores (como la interpretación de HTML en los navegadores) era crucial para un intercambio de paquetes eficaz.

Los lenguajes

Si un nodo de la red recibe un “datagrama” 59 con errores, pero aún así es comprensible, entonces el paquete puede ser procesado. A la inversa, cada nodo de la red debe intentar enviar paquetes correctos. Esta línea de pensamiento se consagró en el Principio de Robustez, también conocido como Ley de Postel 60:

Sé conservador en lo que envías; sé liberal en lo que aceptas.

Si te suena familiar es porque es la misma manera en que los navegadores web actúan con HTML y CSS. Si hay errores en el código HTML o CSS, el navegador intenta procesar la información, saltando los fragmentos que no pueda procesar.

 

Declaración

HTML y CSS son dos ejemplos de lenguajes declarativos 61. Un autor escribiendo en un lenguaje declarativo describe una salida deseada sin indicar las instrucciones paso a paso que el ordenador debe procesar. Con HTML, puedes describir la naturaleza del contenido – párrafos, cabeceras, campos de formulario, etc – sin tener que indicar exactamente qué tiene que hacer el navegador con esta información. Con CSS, puedes describir la apariencia deseada del contenido – colores, bordes, etc – sin tener que escribir un programa para aplicar estos estilos.

La mayoría de lenguajes de programación no son declarativos, sino imperativos. Perl, Java, C++… son ejemplos de lenguajes imperativos. Si programas en uno de estos lenguajes, debes indicar las instrucciones precisas para que el ordenador interprete tu código.

Los lenguajes imperativos te confieren más poder y precisión que los lenguajes declarativos. Esto tiene un precio. Los lenguajes imperativos tienden a ser más difíciles de aprender que los lenguajes declarativos. Es también más difícil aplicar la Ley de Postel a los lenguajes imperativos. Si cometes un único error – simplemente, olvidar una coma o un punto y coma – fallará el programa entero. Una etiqueta mal escrita en HTML o una llave ( { ) olvidada en CSS también pueden causar dolores de cabeza, pero los programas imperativos deben estar correctamente escritos o no se ejecutarán por completo.

Los lenguajes imperativos como PHP, Ruby y Python se pueden encontrar en los servidores 62 de la World Wide Web, leyendo y escribiendo registros en bases de datos, procesando entradas, y ejecutando complejos algoritmos. Puedes elegir qué lenguaje de programación quieres cuando escribas código del lado servidor. De diferente manera que pasa con el navegador web del usuario, tú tienes el control sobre las capacidades del servidor.

Si quieres escribir código imperativo que corra en un navegador web, sólo tienes una elección: JavaScript 63.

 

Scripting

La idea de ejecutar un programa desde una página web es tan vieja como la misma web. A continuación, podemos leer esto en un mail antiguo:

Me gustaría saber, si alguien ha extendido WWW tal, que es posible iniciar programas arbitrarios pulsando un botón en un navegador WWW.

Tim Berners-Lee respondió:

Muy buena pregunta. El problema es el del lenguaje de programación. Necesitas algo realmente poderoso, pero al mismo tiempo omnipresente. Recuerda que una faceta de la web es la de lector universal. No existe un lenguaje de programación universal interpretado.

Esta conversación ocurrió en 1992. El lenguaje de programación interpretado finalmente llegó en 1996. Fue escrito en 10 días por un programador de Netscape llamado Brendan Eich 64.

El lenguaje pasó por algunos cambios de nombre. Primero se llamó Mocha. Entonces se lanzó oficialmente como LiveScript. Luego el departamento de marketing decidió renombrarlo JavaScript, con la esperanza de que aprovechara el impulso del nuevo lenguaje Java 65. En realidad, ambos lenguajes tienen poco en común.

 

Patrones de progreso

JavaScript le dió a los diseñadores el poder de actualizar las páginas web después de que estas se cargaran. Dos usos comunes surgieron de seguida: rollovers 66 y validaciones de formularios.

Intercambiar imágenes cuando alguien pasa el cursor encima de un enlace, puede no parecer un uso sensible de un nuevo lenguaje de programación, pero en los 90 no había otra forma de crear efectos hover 67.

Antes de que apareciera JavaScript, un formulario tenía que ser enviado a un servidor web el cual verificaba que se hubieran rellenado todos los campos requeridos o que la información se había introducido en el formato correcto.

Ambos usos todavía existen, pero actualmente no se precisa JavaScript para ello. Puedes crear efectos rollover mediante CSS. También puedes validar campos de formularios mediante los atributos REQUIRED 68 y TYPE 69 de HTML.

Este es un patrón que se repite una y otra vez: se crea una solución en un lenguaje imperativo y si es suficientemente popular, migra a un lenguaje declarativo al cabo de un tiempo. Cuando una característica está disponible en un lenguaje declarativo, no sólo es más fácil de utilizar, sino que además es más robusta.

El manejo de errores sueltos de HTML y CSS significa que muchos errores de creación, o problemas de soporte del navegador, se manejan con gracia; el navegador simplemente ignora que no lo puede interpretar y sigue. Generalmente esto es bueno. Por contra, si le introduces código JavaScript erróneo o intentas emplear alguna característica no soportada por JavaScript, no sólo te mostrará un error, sino que parará su ejecución en ese punto.

 

Responsabilidad

JavaScript le da a los diseñadores el poder de crear sitios web más llanos, más suaves y más reactivos. La misma tecnología también les proporcionó a los diseñadores web la capacidad de crear sitios web que eran más lentos y de peor manejo.

Uno de los primeros abusos de JavaScript vino (¿sorpresa?) de la industria publicitaria, un negocio cuya razón de ser está a menudo en desacuerdo que los objetivos de aquellas personas que tratan de lograr una tarea lo más rápidamente posible. JavaScript te permite crear nuevas ventanas 70 de navegador, algo que anteriormente sólo podía hacer el usuario. Un joven desarrollador llamado Ethan Zuckerman 71 descubrió que podía generar una nueva ventana con un anuncio. Esto permitía a los anunciantes colocar su mensaje enfrente de los visitantes de una web. No sólo eso, JavaScript se podía utilizar para generar múltiples ventanas, algunas visibles, algunas ocultas bajo la ventana actual. Fue una solución diabólica.

Veinte años después, Zuckerman escribió:

Yo escribí el código para generar la ventana y ejecutar un anuncio en ella. Lo siento.

Las ventanas emergentes ( y las ocultas ) se volvieron tan intolerables que los navegadores tuvieron que proporcionar medios a los usuarios para bloquearlas.

La industria de la publicidad encontró después otros medios para abusar de JavaScript. Los editores en línea soportados por anuncios inyectaron JavaScript hinchado e ineficiente en sus páginas, haciéndolas lentas de carga. También se utilizó JavaScript para realizar un seguimiento a la gente de sitio a sitio. Los usuarios echaron mano de software de bloqueo de publicidad para combatir este abuso. Eventualmente el bloqueo publicitario se integró en los navegadores y sistemas operativos para evitar el excesivo JavaScript.

Los diseñadores web harían bien de recordar lo que la industria de la publicidad intenta ignorar: en la web, el usuario tiene la última palabra.

 

2.0

El auge de JavaScript fue impulsado en 2005 con la publicación de un artículo titulado Ajax 72: A New Approach to Web Applications (AJAX: Un nuevo enfoque a las aplicacioness web) por Jesse James Garrett 73. El artículo puso un nombre a una técnica que estaba ganando popularidad. Utilizando un subconjunto de funciones de JavaScript era posible que un navegador web enviara y recibiera datos de un servidor web sin tener que actualizar la página completa. El resultado era una experiencia de usuario más fluida.

El término AJAX fue acuñado a la vez que otro neologismo ascendía. Tim O’Reilly 74 utilizó la frase Web 2.0 75 para describir una nueva ola de productos y servicios web. A diferencia de Ajax, era difícil precisar una definición de Web 2.0. Para la gente de negocios, significaba nuevos modelos de negocio. Sin embargo, para los diseñadores gráficos, significaba esquinas redondeadas y gradientes. Finalmente, para los desarrolladores, significaba JavaScript y AJAX.

Cualquiera que fuera su significado exacto, el término Web 2.0 capturó un estado de ánimo y un sentimiento. Cualquier cosa iba a ser diferente ahora. Las formas antiguas de pensar acerca de crear para la web podían ser descartadas. Tratar la web como una colección ilimitada de documentos con hiperenlaces pasó de moda. La era de las aplicaciones web estaba en la mano.

 

Apego

En 1964 en el caso de la Corte Suprema Jacobellis contra Ohio, el juez Potter Stewart ofreció esta definición de obscenidad:

Lo sé cuando lo veo

Lo mismo se podría decir acerca de la Web 2.0 o el término “aplicación web” 76. Podemos apuntar a ejemplos de aplicaciones web, pero es más complicado proveer una definición para el término. Las web apps permiten a la gente crear, editar y borrar contenido. Pero esas tareas ya existían antes de que llegaran las web apps. La gente podía rellenar formularios y enviarlos a servidores web para que éstos los procesaran. Ajax eliminó la necesidad de ese viaje de ida y vuelta al servidor.

Quizá la definición de aplicación web requiere algunos razonamientos redundantes:

  • JavaScript es un requisito para una web app, y
  • Una web app es un sitio web que requiere JavaScript para funcionar.

En tal caso, la creación de web apps depende de una asunción fundamental: JavaScript debe estar disponible y confiable. Pero quizá por su naturaleza imperativa, JavaScript tiende a ser más frágil que un lenguaje declarativo como HTML. Confiar en JavaScript podría no ser una suposición segura después de todo.

 

Imperdonable

El tratamiento de errores de HTML le permitió crecer en el tiempo. También aseguró que el lenguaje era fácil de aprender. Si cometías un error, la implementación del navegador de la Ley de Postel aseguraba que aún así obtendrías un resultado. Sorprendentemente, existía un intento de eliminar este superpoder de HTML.

Después de la estandarización de la versión 4 de HTML en 1999, el Consorcio World Wide Web publicó XHTML 1.0 77. Este HTML se reformuló de acorde a las reglas del formato de datos XML 78. Así como HTML puede tener nombres y atributos de etiquetas en mayúsculas y minúsculas, XML requiere que todas sean minúsculas. Existían algunas otras diferencias: todos los atributos tenían que estar entrecomillados, y los elementos aislados como IMG o BR requerían un signo de cierre.

XHTML 1.0 no añadió nuevas características al lenguaje. Simplemente era una manera estricta de escribir código marcador. XHTML 2.0 fue una propuesta diferente. No sólo eliminaría elementos establecidos, como IMG, sino que también implementaría el draconiano modelo de manejo de errores de XML. Si hay un simple error en un documento XML, el intérprete para inmediatamente y rehúsa interpretar nada.

XHTML 2.0 murió ‘en la vid’. Su pureza teórica fue despreciada por la gente que en ese momento creaba sitios web. Los diseñadores rechazaron publicar en un formato que fallaba completamente, en lugar de intentar recuperarse de un error.

Extraño entonces, que años más tarde, los diseñadores web crearan felizmente sitios web enteros utilizando JavaScript, un lenguaje que comparte el modelo de gestión de errores implacable de XML. No los llamaban sitios web. Los llamaban web apps. Esa distinción era una fría comodidad para alguien que no pudiese completar su tarea porque un servicio dependía de JavaScript para una funcionalidad crucial.

A pesar del modelo de gestión de errores frágil de JavaScript, los diseñadores web se volvieron más flexibles con JavaScript con el tiempo. En 2015, la NASA 79 relanzó su sitio web como una web app. Si quieres leer las últimas noticas de los esfuerzos de exploración espacial de la agencia, primero tienes que descargar y ejecutar tres megabytes de JavaScript. Este contenido – texto e imágenes – podría haber sido entregado en HTML, pero los desarrolladores, en su lugar, decidieron utilizar AJAX para recuperar estos datos. Hasta que no se carga todo JavaScript, interpretado y ejecutado, los visitantes del sitio se encontrarán con un fondo negro. Tal vez esto se pretende como una demostración de la vasta y solitaria vacuidad del espacio.

Esto destaca otra diferencia entre HTML y JavaScript. Mientras HTML se puede mostrar pieza a pieza tal como se va cargando, un fichero JavaScript se debe descargar entero antes de que su contenido se interprete. Mientras es tentador pensar que sólo una pequeña minoría de visitantes se perderá en un sitio de JavaScript, la verdad es que todo el mundo es un no usuario de JavaScript hasta que JavaScript se ha terminado de cargar… si se termina de cargar JavaScript. Conexiones débiles, interferencias de operadores de red, e impredecibles softwares de bloqueo de publicidad pueden torpedear la suposición de que JavaScript está siempre accesible.

El problema no es que la gente deshabilite deliberadamente JavaScript en sus navegadores. Aunque sea un caso de uso que vale la pena considerar, no es la causa más común de errores de JavaScript. Stuart Langridge 80 puso juntos en una lista todos los puntos posibles de fallo bajo el título Everyone has JavaScript, right? (“Todo el mundo tiene JavaScript, ¿correcto?”).

El usuario solicita tu aplicación web. ¿Ya ha cargado la página? ¿Ha tenido éxito la solicitud HTTP para el JavaScript? ¿Se completó la solicitud HTTP para el JavaScript? ¿El firewall corporativo bloquea JavaScript? ¿Su operador de ISP o móvil interfiere con el Javascript descargado? ¿Han desactivado JavaScript? ¿Tienen add-ons o plug-ins instalados que inyectan script o alteran el DOM de maneras que no se preveen? ¿Está la Red de Entrega de Contenidos? ¿Su navegador soporta el JavaScript que has escrito?

Algunos de esos problemas también pueden afectar a los ficheros HTML y CSS, pero gracias a la Ley de Postel, afortunadamente se pueden recuperar.

Esto no significa que los diseñadores web no deban utilizar JavaScript. Pero significa que los diseñadores web no deben confiar en JavaScript cuando existe una solución más simple.

 

Plataforma

Los diseñadores web que ignoraron el mensaje de A Dao of Web Design de John Allsopp, cometieron el error de tratar la web como la impresión. La historia de la impresión tiene mucho que ofrecer – jerarquía, tipografía, teoría del color – pero la web es, fundamentalmente, un medio diferente. La historia del desarrollo del software también tiene mucho que ofrecer – arquitectura, testeo, proceso – pero otra vez la web mantiene su propio medio.

Es tentador aplicar el conocimiento y los aprendizajes de otros medios a la web. Pero es más honesto estructuralmente descubrir los propios puntos fuertes y débiles de la web.

El lenguaje que utilizamos puede influenciar nuestro pensamiento sutilmente. En su libro Metaphors We Live By (“Metáforas que vivimos”), George Lakoff 81 destaca los peligros del lenguaje político.  Ejemplos obvios son “fuego amigo” o “daño colateral”, pero un ejemplo más maquiavélico es “exención fiscal” – antes que empiece un debate, la fiscalidad ha sido enmarcada como algo que requiere alivio.

En la cara de la moneda, el término “plataforma web” parece inofensivo. Describir la web como una plataforma la pone a la par con otros entornos de software. Flash era una plataforma. Android es una plataforma. iOS es una plataforma. Pero la web no es una plataforma. El punto principal de la web es que es multiplataforma.

Una plataforma provee un entorno de ejecución controlado para el software. Así como el usuario tiene ese entorno de ejecución, puedes estar seguro que él obtendrá exactamente lo que tú has diseñado. Si tu creas una aplicación iOS y alguien tiene un dispositivo iOS, tu sabes que él puede tener el 100% de tu software. Pero si tu creas una aplicación iOS y alguien tiene un dispositivo Android, él obtendrá el 0% de tu software. No puedes instalar una app iOS en un dispositivo Android. Es todo o nada.

La web no es tan binaria como eso. Si tú creas algo utilizando tecnologías web, y alguien visita con un navegador web, tú no puedes estar seguro de cuántas tecnologías web soportará. Probablemente no sea el 100%. Pero también es improbable que sea el 0%. Algunas personas visitarán con dispositivos iOS. Otras con dispositivos Android. Algunas personas tendrán el 80 o 90% de lo que tú has diseñado. Otras justo el 20, 30 o 50%. La web no es una plataforma. Es un continuo.

Pensar en la web como una plataforma es un error de categoría. Una plataforma como Flash, iOS, o Android provee estabilidad y certeza, pero sólo bajo un conjunto de circunstancias muy específico – a tu software se debe acceder con el entorno de ejecución correcto, específico de la plataforma. La web no provee dicha certeza, pero tampoco restringe los entornos de ejecución posibles.

Las plataformas son controladas y predecibles. La World Wide Web es caótica e impredecible.

 

Referencias


Notas de traducción

(57) Jon Postel, responsable de los protocolos TCP/IP: IP, ICMP, TCP, SMTP y DNS.

(58) ARPANET. Red creada por el Departamento de Defensa de los Estados Unidos. Nacida el 29 de octubre de 1969, duró hasta 1990, cuando se finalizó la transición al protocolo TCP/IP, lo que supuso el nacimiento de internet.

(59) Datagrama. Paquete mínimo de datos utilizado para el intercambio de información.

(60) Principio de Robustez o Ley de Postel“Ser conservador en lo que haces, ser liberal en lo que aceptas de otros”.

(61) Lenguaje declarativo vs. lenguaje imperativo. En el lenguaje declarativo se indica cuál es el problema; en el lenguaje imperativo se indica cómo resolver el problema.

(62) Lenguajes de lado servidor. Lenguaje que se interpreta en el servidor de un sitio web y cuyo resultado se envía al navegador. ASP, PHP, Ruby o Python son lenguajes de lado servidor que envían al navegador instrucciones en lenguaje de lado cliente (HTML, CSS, Java o JavaScript), los cuales se interpretan en el navegador del usuario.

(63) JavaScript. Lenguaje de programación interpretado.

(64) Brendan Eich. Programador conocido por inventar el lenguaje JavaScript.

(65) Java. Lenguaje de programación de propósito general. Su virtud es que cualquier programa Java se puede ejecutar en cualquier dispositivo, gracias a las máquinas virtuales Java (Java Virtual Machine – JVM).

(66) Rollover. Efecto simple que consiste en cambiar de forma dinámica una propiedad de un elemento HTML.

(67) Hover. Selector CSS utilizado para modificar una propiedad de un elemento HTML al pasar el puntero encima de él.

(68) Required. Atributo de un campo de un formulario HTML, que indica que dicho campo debe ser rellenado por el usuario.

(69) Type. Atributo de un campo de un formulario HTML, que indica qué tipo es; por defecto es text.

(70) Ventana popup, emergente, modal. Ventana o cuadro de diálogo que se abre en un momento dado, para que el usuario ejecute una acción.

(71) Ethan Zuckerman. Considerado el inventor de los anuncios pop-up (emergentes).

(72) AJAX: Asynchronous JavaScript And XML ( JavaScript asíncrono y XML ), técnica de desarrollo web que permite establecer una comunicación asíncrona entre el cliente y el servidor, la cual se ejecuta al recibir la respuesta y mientras tanto sigue la ejecución de la página, sin tener que recargarla completamente. Es la técnica base de la Web 2.0 y de la actual AMP (Accelerated Mobile Pages).

(73) Jesse James Garrett. Programador web que acuñó el término AJAX en 2005.

(74) Tim O’Reilly. Creador del concepto Web 2.0. Fundador de la editorial O’Reilly, especializada en libros de programación.

(75) Web 2.0. El término Web 2.0 o Web Social comprende aquellos sitios web que facilitan el compartir información, la interoperabilidad, el diseño centrado en el usuario y la colaboración en la World Wide Web.

(76) Aplicación web (“web app”).

(77) XHTML (eXtensible HyperText Markup Language), es HTML expresado como XML válido.

(78) XML (eXtensible Markup Language) es un subconjunto de SGML, simplificado y adaptado a Internet. Es un meta-lenguaje que nos permite definir lenguajes de marcado adecuados a usos determinados.

(79) NASA. National Aeronautics and Space Administration.

(80) Stuart Langridge.

(81) George Lakoff.

Derechos

Este libro ( Resilient Web Design ) ha sido escrito y producido por Jeremy Keith. Bajo licencia Creative Commons Attribution-ShareAlike 4.0 International License. Yo me he limitado a traducirlo, y, en todo caso, añadirle unas notas de traducción para enriquecerlo ( aunque no fuera necesario enriquecerlo ). Esta traducción, a su vez, también está bajo la licencia Creative Commons Attribution-ShareAlike 4.0 International License.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *