Es el navegador que a todo el mundo le encanta odiar, a veces justificadamente. Lo que alguna vez fue el navegador más innovador se convirtió en la espina de todos los desarrolladores de aplicaciones para usuario. En medio de la confusión y las quejas de los desarrolladores de hoy en Internet Explorer, lo que a menudo no se oye es cómo Microsoft cambió la cara no solo del desarrollo de aplicaciones para usuario, sino del desarrollo web en general..
La caída de IE no es una historia poco común; de hecho, es algo así como Netscape. La compañía detrás del navegador líder se vuelve complaciente, el navegador se estanca y surge un nuevo campeón. Es un ciclo repetitivo, uno al que Mozilla se enfrenta de nuevo hasta cierto punto (pero esa es otra historia para otro momento).
Antes de los navegadores de la versión 4, JavaScript se utilizaba principalmente para el procesamiento simple de datos (validación de formularios). Como tal, las páginas web eran principalmente estáticas. Mientras que una página podría ser generada dinámicamente por las aplicaciones del lado del servidor, la página no podría interactuar con el usuario. Esta limitación existió debido a que el modelo de objetos de documento (DOM) inadecuado del navegador, que es la interfaz de programación de aplicaciones (API) que los desarrolladores de JavaScript utilizan para acceder y manipular elementos individuales en la página. El DOM que existía antes de los navegadores de la versión 4 se conoce con frecuencia como DOM Level 0. Las implementaciones del DOM Level 0 permiten a los desarrolladores acceder a ,
, y
elementos, pero eso es todo.
"Microsoft está poniendo a Internet Explorer de nuevo en la pista".
No fue hasta que Netscape lanzó Navigator 4 (NS4) a mediados de 1997 que el DOM de un navegador permitió a los desarrolladores web modificar una página con JavaScript. La técnica de manipulación de elementos con JavaScript y el DOM se denominó HTML dinámico (DHTML). El DHTML de NS4 fue sin duda un paso adelante, pero su DOM propietario y mal diseñado basado en capas y su limitada hoja de estilo en cascada (CSS) admiten desarrolladores restringidos en lo que realmente podrían lograr.
Netscape no implementó un modelo de objeto completo. Aparte de la funcionalidad DOM Nivel 0, los únicos elementos a los que un desarrollador pudo acceder fueron los elementos posicionados de forma absoluta,
elementos, y
Elementos (los dos últimos elementos fueron posicionados de facto). Cada uno de estos tipos de elementos fue representado por una Capa
objeto en el DOM de NS4. Netscape diseñado Capa
Los objetos deben ser muy similares a los objetos de marco (y, por tanto, de la ventana). Cada Capa
objeto tenía un documento
propiedad, que básicamente era otro documento HTML. Como marcos, un Capa
objeto podría estar anidado en otro Capa
objeto, haciendo que el código para acceder a esas capas sea extremadamente detallado como el siguiente:
var myLayer1 = document.layers ["myLayerId"]. document.layers ["mySecondLayerId"]; // o var myLayer2 = document.myLayerId.document.mySecondLayerId;
Estas dos líneas de código hacen lo mismo: acceden al Capa
objeto con un carné de identidad
de mySecondLayerId
que está anidado dentro de una capa con una carné de identidad
de myLayerId
. Sí, los desarrolladores tuvieron que caminar por el "árbol" de capas para acceder a las capas anidadas.
El DOM de NS4 no permitió la creación, inserción, reubicación y eliminación de objetos del DOM, sino porque cada capa expuso un documento
objeto, un desarrollador podría cambiar dinámicamente el contenido de una capa usando el escribir()
, carga()
, y cerrar()
metodos Si bien esto le da algo de poder adicional al modelo de capa, restringió a los desarrolladores en la forma en que podrían actualizar dinámicamente una página. El contenido nuevo debería escribirse o cargarse en una capa, eliminando efectivamente el contenido existente de la capa. No hace falta decir que la mayoría de los desarrolladores evitaron la manipulación del contenido y se centraron en cambiar el estilo de una capa.
El desarrollo web utilizando el DOM de NS4 fue doloroso y frustrante.
Pero el estilo en el DOM de NS4 era algo gracioso. Mientras que el navegador soporta CSS hasta cierto punto, Capa
Los objetos no proporcionan una API para que los desarrolladores accedan directamente a una capa. estilo
atributo como el de hoy estilo
objeto. En lugar, Capa
los objetos expusieron un conjunto muy limitado de propiedades que alteraron la posición de una capa, la visibilidad, el recorte y el color / imagen de fondo, nada más, y el valor que estas propiedades aceptaron también fue bastante limitado. Por ejemplo, las propiedades de posicionamiento y recorte solo aceptaban valores numéricos; un desarrollador no pudo especificar una unidad (como px, em, pt, etc.). Un ejemplo de tal código sigue:
var myLayer = document.myLayerId.document.mySubLayerId; myLayer.top = 10;
No hace falta decir que el desarrollo web utilizando DOM de NS4 fue doloroso y frustrante. Las capacidades DHTML extremadamente limitadas de NS4 se derivan de las limitaciones del motor de representación de NS4 (no pudo hacer que la página vuelva a fluir). Pero, ¿por qué dedicar tanto tiempo al DOM de Netscape, especialmente en un artículo que se supone que trata de IE? Si Netscape hubiera ganado la guerra de los navegadores, el DOM de hoy sería un paso evolutivo del DOM presentado por Netscape en NS4. Si bien el DOM de hoy es un estándar establecido por el W3C (y algunas ideas de Netscape están implementadas en el estándar de hoy), el DOM de hoy está fuertemente influenciado por el DOM de IE4..
Apenas unos meses después de que Netscape lanzara Navigator 4, Microsoft lanzó la cuarta versión de IE. También incluía soporte para DHTML, pero La implementación de Microsoft fue muy diferente y superior a NS4. IE4 contaba con un soporte CSS mucho mejor y un modelo de objeto más completo para acceder y manipular elementos y contenido en la página. El efecto del DOM de IE4 fue de gran alcance; De hecho, un desarrollador puede encontrar muchas similitudes entre el DOM de IE4 y el DOM estándar..
"Microsoft cambió la cara no solo del desarrollo de front-end, sino del desarrollo web en general".
Los diseñadores de IE4 querían convertir el navegador en una plataforma para aplicaciones web. Así que se acercaron a la API de IE4 como un sistema operativo, proporcionando un modelo de objeto casi completo que representaba cada elemento (y los atributos de un elemento) como un objeto al que se podía acceder con un lenguaje de secuencias de comandos (IE4 admitía JavaScript y VBScript).
En el DOM de IE4, el medio principal para acceder a un elemento particular en la página era el propietario todos[]
colección, que contenía todos los elementos del documento. Los desarrolladores pueden acceder a los elementos con un índice numérico o especificando un elemento carné de identidad
o nombre
, Me gusta esto:
var myElement1 = document.all ["myElementId"]; // o var myElement2 = document.all.myElementId;
Usando este código, los desarrolladores podrían acceder al objeto elemento con un ID de myElementId
independientemente de donde existía dentro de la página. Esto está en marcado contraste con el modelo de capa de Netscape en el que los desarrolladores solo podían acceder a las capas a través de la jerarquía de la capa. La funcionalidad de document.all ["elementId"]
evolucionado hacia el estándar document.getElementById ()
método. Pero esta no era la única forma en que un desarrollador podía acceder a los elementos; uno podría caminar el árbol DOM y tocar cada elemento con el niños[]
colección y padre elemento
precursores de la propiedad a la norma childNodes []
y parentNode
propiedades.
Además de cargar elementos como objetos, el DOM de IE4 representaba los atributos de un elemento como propiedades del objeto de elemento. Por ejemplo, el carné de identidad
, nombre
, y estilo
propiedades mapeadas directamente a un elemento carné de identidad
, nombre
, y estilo
atributos, respectivamente. Este diseño se convirtió en estándar..
Microsoft inventó el
internalHTML
propiedad.
Al igual que Netscape, Microsoft no proporcionó una API completa para agregar, mover y eliminar dinámicamente nodos con JavaScript. Ellos, sin embargo, inventaron el internalHTML
Propiedad para obtener o establecer el contenido de un elemento. A diferencia de Netscape Capa
objetos escribir()
y carga()
métodos, los internalHTML
la propiedad no era una solución de todo o nada para modificar el contenido de un elemento; un desarrollador podría usar internalHTML
para eliminar completamente, reemplazar o agregar al contenido de un elemento. Por ejemplo, el siguiente código obtiene el contenido de un elemento y lo modifica:
var el = document.all.myElementId, html = el.innerHTML; el.innerHTML = html + "Hello, innerHTML";
A día de hoy, el internalHTML
La propiedad es una piedra angular de DHTML. Es un medio eficaz para agregar grandes cantidades de contenido a un elemento. Aunque nunca se ha incluido formalmente en ningún estándar DOM, cada navegador principal implementa un internalHTML
propiedad.
Microsoft inventó varias herramientas y diseños que evolucionaron en piezas del DOM estándar, pero el trabajo que hicieron con el API de estilo de IE4 se convirtió en estándar con muy poca modificación. La clave para cambiar el estilo de un elemento en IE4 fue la
estilo
propiedad, la misma propiedad (y sintaxis) utilizada por los desarrolladores hoy.
DHTML cambió el desarrollo web para siempre. Sin embargo, fue el DOM de IE4 el que impulsó la tecnología (y el desarrollo web) al ser la principal influencia en las especificaciones de nivel 1 y 2 del DOM del W3C. IE4 revolucionó el desarrollo web en 1997, e IE lo haría de nuevo unos años más tarde.
Ajax abrió las puertas para el desarrollo web.
Antes de que Ajax fuera Ajax, se denominaba secuencias de comandos remotas, y los desarrolladores que aprovechaban el poder de las secuencias de comandos remotas utilizaban marcos ocultos e iframes para la comunicación cliente-servidor. Un marco oculto (i) generalmente contenía un formulario que se completó dinámicamente y se envió a través de JavaScript. La respuesta del servidor sería otro documento HTML que contiene JavaScript que notificó a la página principal que los datos se recibieron y están listos para usar. Era crudo, pero funcionaba..
Sin embargo, había una alternativa: una gema poco conocida y oculta en la biblioteca MSXML 2.0 de Microsoft. IE5, lanzado en marzo de 1999, incluía MSXML 2.0, y los desarrolladores encontraron un componente llamado XMLHttp
(el nombre real de la interfaz era IXMLHTTPRequest
). Su nombre es engañoso, como el XMLHttp
El objeto funciona más como un simple cliente HTTP que cualquier otra cosa. Los desarrolladores no solo podían enviar solicitudes con el objeto, sino que también podían monitorear el estado de las solicitudes y recuperar la respuesta del servidor..
Naturalmente, XMLHttp
comenzó a reemplazar la técnica de trama oculta (i) para la comunicación cliente-servidor. Un par de años más tarde, Mozilla creó su propio objeto, siguiendo el modelo de Microsoft. XMLHttp
, y lo llamo XMLHttpRequest
. Apple siguió su ejemplo con su XMLHttpRequest
Objeto en 2004, y Opera implementó el objeto en 2005..
A pesar de su creciente interés, la popularidad de
XMLHttp
/XMLHttpRequest
(colectivamente conocido como XHR aquí en adelante) no explotó hasta 2005 cuando Jesse James Garrett publicó su artículo, "Ajax: un nuevo enfoque para aplicaciones web".?
Ajax abrió las puertas para el desarrollo web, y en la vanguardia estaba JavaScript, XHR y DHTML, dos de los cuales fueron inventos de Microsoft. ¿Entonces qué pasó? ¿Qué causó un navegador que cambió literalmente la forma en que los desarrolladores web escriben aplicaciones web para convertirse en la perdición de la Web moderna??
Para 2003, la participación de mercado total de Internet Explorer era de alrededor del 95%; Microsoft ganó oficialmente la guerra de los navegadores. Sin competencia real en el espacio web, Microsoft cambió su enfoque del navegador a .NET. Esto se confirma con citas de muchos empleados de Microsoft, pero lo más revelador es el de un artículo de CNET titulado "¿Ayudará el Ajax a Google a limpiar?" En él, se citó a Charles Fitzgerald, gerente general de tecnologías de plataforma de Microsoft, diciendo:
?Es un poco deprimente que los desarrolladores acaban de concentrarse en estas cosas que enviamos a finales del siglo XX. [ed: DHTML y Ajax], pero XAML está en una clase completamente diferente. Esta otra cosa es muy torpe, muy difícil de depurar. Hemos visto algunos hacks bastante impresionantes, pero si miras lo que XAML comienza a resolver, es un gran paso adelante..?
Entonces, en mayo de 2003, Microsoft anunció que IE ya no se lanzaría por separado de Windows (también se conservó el excelente IE5 para Mac). El navegador aún se desarrollaría como parte del sistema operativo Windows en evolución, pero Microsoft no lanzará ninguna versión independiente de IE. Apostaban principalmente por ClickOnce, una tecnología que permite a los desarrolladores escribir aplicaciones convencionales (por supuesto, mediante .NET) y distribuirlas a través de la Web..
Pero la Web continuó evolucionando en el camino que Microsoft estableció originalmente con IE4 e IE5, y Microsoft comenzó a perder cuota de mercado debido al heredero de Netscape: Firefox. Los desarrolladores escribían aplicaciones web que vivían en el navegador, no en aplicaciones convencionales a través de ClickOnce. Eso obligó a Microsoft a recoger IE, desempolvarlo y comenzar a lanzar versiones independientes de nuevo.
IE9, incluye mucho mejor soporte de estándares en todos los ámbitos.
Las siguientes dos versiones, 7 y 8, fueron en gran parte evolutivas. IE7 contenía una variedad de correcciones de errores, XMLHttpRequest
identificador (aunque todavía creó una XMLHttp
objeto de la biblioteca MSXML) y mejoras en la interfaz de usuario y la seguridad.
IE8 fue en gran medida más de lo mismo, excepto que incluyó en cada recuadro, una característica que Google también implementó en Chrome (Microsoft lo anunció primero). Aísla cada pestaña en su propio proceso, aumentando la seguridad y la estabilidad. El sandboxing se está convirtiendo en un estándar en los navegadores de hoy (Firefox aún carece de capacidad), y también se está moviendo en el ámbito de los complementos y complementos..
Microsoft está poniendo a Internet Explorer de nuevo en la pista.
La última versión, IE9, incluye un soporte de estándares mucho mejor en todos los ámbitos, pero también innova con su nuevo motor de JavaScript de compilación JIT (que utiliza un núcleo de CPU separado si está disponible y puede acceder a la GPU) y su motor de procesamiento acelerado por hardware. Si bien los motores de JavaScript de compilación JIT no son nuevos, la capacidad de IE9 para descargar la compilación en un núcleo separado en paralelo a la representación de la página es un logro que estimulará el rendimiento muy necesario para las aplicaciones web. Sus capacidades de aceleración de hardware demostraron ser útiles cuando debutaron, y ahora Firefox y Chrome ofrecen hasta cierto punto aceleración de hardware.
No se puede negar que Internet Explorer ha causado dolores de cabeza a los desarrolladores web. La pausa de cinco años entre IE6 e IE7 hizo que Microsoft quedara muy por detrás de la competencia, lo que hacía que el desarrollo de front-end fuera menos que ideal. Pero Microsoft está poniendo a Internet Explorer de nuevo en la pista. Dieron forma al desarrollo web de lo que es hoy; Esperamos que vuelvan a hacerlo..
La próxima versión de Internet Explorer, versión 9, se lanzará oficialmente el 14 de marzo de 2011.