Una historia corta y opinada del desarrollo web

En el inicio, TBL inventó la Web, y era buena.

Me gusta considerar este tiempo como la “Edad de piedra” del desarrollo web, una era caracterizada por herramientas torpes y difíciles de usar. Escribiamos HTML, a mano, generalmente en un editor de texto. El concepto de páginas web dinámicas no existia: Si querias publicar mil historias online, escribias mil documentos .html.

Esto era desagradable. Obviamente.

Y llevo a una pregunta obvia: y qué si pudiéram os generar HTML programaticamente, como desde una base de datos o algo?

Y así nació CGI, y dió inicio a la edad de Bronce de la web. Teniamos herramientas, finalmente, para automatizar algunas de nuestras tareas repetitivas. Podiamos manejar entrada de datos por parte del usuario! Conectar páginas web con bases de datos! Generar contenido mediante plantillas!

Pero CGI apesta. Es horriblemente lento. Peor aún, incentiva un estilo de desarrollo increiblemente malo. O tenes docenas (cientos!) de programas .cgi, con toda clase de código repetitivo… o terminas con un único, gigantesco, monolítico go.cgi. CGI usualmente es escabrosamente difícil de mantener. El hecho de que la mayoria del CGI de esta era este escrito en Perl — o peor, C — no ayuda.

Entonces, nuevamente, la gente inteligente comenzó a hacer preguntas. Al principio, preguntamos, “como podemos hacer que CGI apeste menos?” Nótese que esta no es una pregunta muy complicada — no es replantearse como deberia funcionar el desarrollo web — pero aún así condujo a un gran salto hacia adelante: La primer generación de servidores de aplicaciones.

Estoy hablando aqui de cosas como mod_perl, mod_python, y especialmente PHP. PHP, que es esencialmente “CGI hecho bien”, ganó una predominancia abrumadora, y la edad de hierro de la web comenzó².

Ahora, mencioné que las preguntas que llevaron a PHP no eran muy buenas preguntas, y por eso el salto no fue tan dramático. La edad de hierro es muy similar a la edad de Bronce: las herramientas se ven iguales, solo que usan tecnologia un poco mejor. Eso es, PHP sufre de la mayoria de los problemas de CGI, pero en un grado menor.

El problema mas grande, al menos en mi cabeza, con las primeras etapas del desarrollo web es que la forma de pensar esta orientada a páginas. Todo lo que hicimos en esos años tempranos fue cambian pagina.html por pagina.cgi por pagina.php. Todavia representabamos a los sitios web como una coleccion de páginas, escritas en una seguidilla de lenguajes que iba mejorando.

Entonces la revolución verdadera vino cuando empezamos a cuestionarnos esta suposición. “Y que pasaria si,” nos preguntamos “pudieramos pensar acerca de esto como aplicaciones, no páginas?”

Esta pregunta llevó directamente a la creación de Django, y a la revolución industrial: Frameworks Web.

Ahora, las revoluciones técnicas suceden orgánicamente. Tomemos la Imprenta: Aunque Gutenberg es acreditado por su invención, en realidad también fue descubierta por otros 2 inventores³ en europa alrededor de esa fecha. De hecho, es inexacto dar crédito a cualquiera de estos hombres por la invención de la imprenta: Material impreso que data del siglo VII fue encontrado en China y Korea⁴.

Como la imprenta, entonces, los frameworks existieron mucho antes que la cosecha actual (WebObjects por ejemplo). Como la revolución industrial, la revolución de los frameworks sucedió en muchos lugares, y de muchas maneras diferentes. No quiero pretender que Django fue el primer framework — o uno de los primeros — ni que Django nació de la nada. Django es, como los otros frameworks de nuestra época, un producto de esta era, y de estas preguntas acerca del desarrollo web.

Nota del editor

Buscas hosting de calidad? asegura tu tranquilidad contratando tu plan de hospedaje con Okhosting.com , una empresa confiable y con experiencia en México, en todos nuestros servicios de alojamiento web ilimitado, gratis asesoría ayuda y orientación para principiantes y avanzados, compra tu dominio .MX y si aun no tienes sitio web utiliza nuestro programa para hacer paginas web en minutos,  te invitamos a conocer nuestros planes de alojamiento ahora con mas espacio y con mas funciones profesionales. OKhosting.com  todo lo necesario para estar en internet

La era industrial: Frameworks Web

Ahora nos encontramos a nosotros mismos en la era industrial, la era del Framework. Como estoy hablando mucho de frameworks, creo que vale la pena clarificar a lo que me refiero. Según lo veo, las caracteristicas principales de un framework web son las siguientes:

• Operan a un nivel conceptual alto. En vez de pensar acerca de HTTP, HTML y “páginas” web, los frameworks nos permiten pensar y operar al nivel de “aplicacion web”. Esto significa menos código, y tambien nos permite ser mucho mas ambiciosos acerca de lo que estamos construyendo.

• Los frameworks proveen bloques mucho mas grandes para construir aplicaciones.

  Me gusta utilizar la analogia de la construcción: tradicionalmente, la mayoria de las casas estan hechas de madera: Solo tenés que clavar un monton de maderas, una por vez, hasta que la casa finalmente aparece. Los materiales son simples: madera, clavos, pegamento, tejas, ladrillos. Tenes mucha flexibilidad, pero la construcción toma mucho tiempo.

  Hoy en dia hay otra opcion: casas prefabricadas. Aquí, la casa esta hecha de muchas secciones grandes en una fábrica, automaticamente en su mayor parte. Cada habitación, prefabricada, es cargada en un camión y la grua ensambla la casa en su sitio. La arquitectura esta mas restringida — tenes que armar la casa usando las opciones de habitaciones soportadas por la fábrica — pero podes estar mudandote a la casa nueva literalmente 30 dias despues de aceptar los planos finales.

• Los frameworks alientan el desarrollo veloz. No es coincidencia que la Edad del Framework es también la edad del desarrollo Ágil. Ágil, XP, Scrum, etc. — los frameworks se lucen mas cuando son utilizados en un estilo de iteraciones rápidas.

• Los buenos frameworks son software libre. I no creo que tenga que justificar este punto a esta audiencia en particular, así que es suficiente decir que no es accidental que no haya ningún framework privativo con muchos seguidores del que valga la pena hablar⁵.

• Finalmente, los buenos frameworks hacen que el desarrollo sea divertido. La gente de negocios suele pensar que este es un requerimiento tonto. No lo es. La mejor parte del mundo de los frameworks web es nuestro sentido de la diversión: la diversión motiva, lleva a la experimentacion, y así a la innovación.

Inter-operabilidad

Los frameworks web modernos apestan en la inter-operabilidad. Los frameworks son buenos. Pero inevitablemente nos encierran. El encierro es malo.

Es importante darse cuenta que la parte mas importante de inter-operabilidad es con el código del usuario, y francamente los frameworks web suelen ser malos en esto. Una verdad fundamental del software es que mientras crece y se vuelve mas maduro, también se vuelve mas específico de un dominio y menos genérico. Voy a hablar mas de esto en un momento; La parte importante por ahora es que los frameworks genericos deberian poder ceder el control a reemplazos mas específicos del dominio en la medida en que la pila de herramientas crece. La mayoria de los frameworks no hace esto.

Por supuesto, la mayoria de la gente piensa en la inter-operabilidad como inter-operabilidad entre múltiples frameworks. Nadie esta haciendolo muy bien aquí, pero desafortunadamente el mundo web de Python es peor que el promedio. Hay mucha fragmentación en la comunidad web, y francamente Django no esta ayudando. Eso es un bug en la comunidad de Django, y hay bugs similares en todo el mundo web Python. Necesitamos solucionarlos.

WSGI esta ayudando con esto; WSGI es lo mejor que le pudo pasar al desarrollo web en python. Pero no podemos dormirnos en los laureles: WSGI tiene problemas serios. Estan fuera de tema aquí, asi que simplemente voy a apuntarlos al Hablemos de WSGI de James Bennett y a decirles que estoy de acuerdo.

Tambien deberia mencionar Rack. Rack, en resumen, llegó cuando el mundo Ruby, enfrentando problemas similares a los que enfrentamos en pythonlandia, crearon un ‘web gateway’ inspirado en WSGI. Fue un exito rotundo: Rails 3 esta siendo reescrito en Rack. Rack es francamente un poco mejor que WSGI; Nosotros los pythonistas deberiamos estar avergonzados por eso.

El problema principal, sin embargo — el elefante en la habitación — es que los gateways apestan también. Los gateways no son APIs. Hay un limite — y es uno muy bajo — al nivel de inter-operabilidad que podes obtener si la unica interface de la que dispones es un gateway. Incluso si mejoraramos WSGI — y deberiamos — no nos va a llevar muy lejos.

Peor aún, herramientas como WSGI y Rack no sirver para ayudar la inter-operabilidad entre lenguajes. Realmente me gustaria escribir partes de mi aplicacion en Python, partes en Clojure, partes en Ruby, y hasta partes en Perl. Cosas como los proxies web, SOA, ROA, y las máquinas virtuales ayudan con esto, pero como los gateways no son APIs no podemos llegar muy lejos.

Esto va a ser un problema difícil de solucionar, aunque solo nos enfoquemos en Python. Tenemos un monton de comunidades separadas, todas formadas por voluntarios. Muy pocas personas tienen conocimiento superpuesto, pocos saben como navegar múltiples estandares de la comunidad, y todavia menos tienen el impetu para trabajar en inter-operabilidad. Casi nadie esta pensando en inter-operabilidad multi lenguaje.

Pero estas cosas son increiblemente importantes. Si django desaparece, estaré triste. Pero si python falla como un lenguaje web, voy a estar devastado.

Rich web applications

Estoy extremadamente excitado con HTML 5. De hecho, creo que podria ser lo mejor que le pasó a los frameworks web. Si las aplicaciones web realmente pueden reemplazar a las aplicaciones de escritorio, entonces los frameworks van a ser el lugar donde uno deberia estar, y python la rompe en este ámbito.

Ahora mismo, sin embargo, las herramientas que tenemos no son buenas para crear ‘rich internet applications’ La vanguardia actual es lamentable. Los dos enfoques que he visto parecen ser, o construir dos capas MVC en el cliente y en el servidor, y pegarlas de alguna manera, o inventar un framework muy rígido que corre en el backend con un front-end generado, como GWT o SproutCore. Ninguno de los dos enfoques me agrada mucho.

Por ejemplo, miren 280Slides. Es una pieza de tecnologia web asombrosa — el navegador realmente desaparece; es difícil decir que no estas en una aplicacion de escritorio nativa, es increible.

Sin embargo, los desarrolladores creyeron que 280Slides seria literalmente imposible de escribir usando cualquiera de las tecnologias web actuales. No solo construyeron su propio framework, Cappuccino; sino que inventaron un nuevo lenguaje Objective-J!. Si esto se hace moda, es preocupante.

Manejando complejidad (alias el problema del despliegue)

Es un hecho bien conocido que las aplicaciones web se estan volviendo mas complejas, y la lista de cosas que necesitas para desarrollar exitosamente, desplegar, y escalar una aplicacion web, se esta haciendo cada vez mas larga.

Resulta ser que escribir la aplicación es ahora la parte facil; manejar el resto de la pila de herramientas que necesitas para un despliegue exitoso puede ser realmente imposible. En otras palabras: ahora todos somos operadores

Hace un tiempo, Leonardo Lin recopiló esta lista de todas estas “otras cosas” de las que necesitas preocuparte luego de desarrollar tu aplicación:

• Mediciones del API
• Backups & Snapshots
• Contadores

• Herramientas de manejo de Cluster/Nubes

  • Instrumentación/Monitoreo(Ganglia, Nagios)
  • Contingencia.
  • Agregar/quitar nodos y hashing de nodos.
  • Auto-escalamiento para recursos en la nube.

• Protección a CSRF/XSS
• Retención/Archivado de datos

• Herramientas de despliegue

  • Multiples Devs, Staging, Producción
  • Actualizacionens al modelo de datos
  • Hacer despliegues
  • Multiples versiones (betas selectivas)
  • Bucket testing
  • Deshacer despliegues
  • Manejo de Redes de distribución de contenidos

• Almacenamiento distribuido
• Almacenamiento distribuido de Logs, analisis
• Graficado
• HTTP Caching
• Filtrado de entrada y salida
• Memory Caching
• Key Stores no relacionales
• Rate Limiting
• Almacenamiento relacional
• Colas
• Mensajeria en tiempo real (XMPP)

• Busqueda

  • Por rangos
  • Geografica

• Sharding

• Smart Caching

  • dirty-table management

Si, un desarrollador web moderno realmente necesita entender estas cosas. puaj.

Las buenas noticias son que hay software libre para satisfacer todas estas necesidades. Las malas noticias son que estan todos inmaduros, piezas separadas sin conexiones unas con otras. Levantar la mitad de estas cosas e integrarlas es una tarea monumental.

Hay una gran oportunidad para python aquí. Python ha sido utilizado historicamente como un lenguaje de “pegamento”, aunque recientemente hemos intentado des-enfatizar ese aspecto. No es nada para avergonzarse: Python es un muy buen lenguaje de pegamento.

Python podria facilmente ser el pegamento que evita que toda esta pila se caiga.

Escala

El uso de internet esta creciendo explosivamente. Mundialmente se ha duplicado 2 veces desde el 2000… y la penetración mundias es de solo un 25%⁶. Este número solo va a seguir subiendo.

Mientras tanto, los sitios web estan volviendose mucho mas complejos. Piensen en el 2000 — podrian haberse imaginado un sitio como 208Slides en ese entonces?

El trafico esta creciendo, el usuario promedio esta gastando mas y mas tiempo en la web, y piensen en lo que va a suceder cuando la internet móvil explote.

Vamos a tener que aprender a lidiar con mas y mas trafico. Y los frameworks son malos en escalar.

Los frameworks son muy buenos en tareas genericas. Se supone que lo sean: abstraen las dificultades comunes. Pero mientras las aplicaciones crecen en escala, necesitan volverse mas y mas especificas a su dominio para poder lidiar con la escalada. Hay una correlación directa entre el tamaño de un sitio y que tan específico es.

Esto usualmente se descompone de la siguiente manera:

• Desarrollas tu primer aplicación de juguete usando Framework X. (En el mundo Django esta parece ser un Blog — parece que al menos 75% de los desarrolladores de Django han construido su propio blog.) Esto usualmente sale muy bien.
• Feliz y exitoso, desarrollas un producto con el framework, y lo lanzas. Esto usualmente va bien también — los sitios al punto de lanzamiento inicial son todavia muy similares entre si, y los frameworks son excelentes hasta aquí.
• En la medida que tu sitio crece, comienza a hacerse un poco doloroso, y necesitas reemplazar algunas partes del framework con partes específicas del dominio. Esto usualmente no es muy malo: La mayoria de los frameworks, Django incluido, son suficientemente modulares que podes reemplazar las partes mas comunes, menos escalables.
• Un dia te convertis en Twitter, y se te descarrilan los patos. Escencialmente terminas teniendo que tirar todo el framework a la basura para reescribir todo, desde cero, en formas muy muy especificas, solo para lidiar con las cantidades exuberantes de tráfico que tenés.

Los frameworks funcionan increíblemente bien para hacerte empezar rápido… y después fallan miserablemente cuando se enfrentan a las necesidades específicas de los sitios grandes.

Esta es una situación imposible para los desarrolladores de frameworks: Al optimizar para un comienzo rápido, enfocandonos en las necesidades comunes, estamos esencialmente garantizando la futura derrota. Recuerdan la controversia de “Rails no escala” es año pasado? Puedo garantizarles que solo es cuestión de tiempo hasta que haya una situación de “Django falló!”.

Los frameworks deberian desvanecerse agraciadamente en la medida que los reemplazas, parte por parte, con código específico del dominio. (A esto me referia antes, con que inter-operabilidad es tambien un problema de escalado.) Ahora mismo, no lo hacen.