È il browser che tutti amano odiare, a volte in modo giustificato. Quello che una volta era il browser più innovativo divenne la spina in ogni lato dello sviluppatore front-end. Tra le turbolenze e le lamentele che gli sviluppatori di oggi lanciano su Internet Explorer, ciò che spesso non viene ascoltato è come Microsoft abbia cambiato il volto non solo dello sviluppo front-end, ma dello sviluppo web nel suo complesso.
La caduta di IE non è una storia insolita; in effetti, è in qualche modo la stessa storia di Netscape. La società dietro il browser principale cresce compiacente, il browser ristagna e sorge un nuovo campione. È un ciclo ripetitivo, quello che Mozilla affronta di nuovo in una certa misura (ma questa è un'altra storia per un'altra volta).
Prima dei browser della versione 4, JavaScript veniva utilizzato principalmente per l'elaborazione semplice dei dati (convalida dei moduli). Pertanto, le pagine Web erano principalmente statiche. Mentre una pagina può essere generata dinamicamente da applicazioni lato server, la pagina non può interagire con l'utente. Questa limitazione esisteva a causa dell'AD inadeguato del Document Object Model (DOM) del browser, che è l'API (application programming interface) che gli sviluppatori JavaScript utilizzano per accedere e manipolare i singoli elementi nella pagina. Il DOM esistente prima dei browser versione 4 viene spesso definito DOM Level 0. Le implementazioni di DOM Level 0 consentono agli sviluppatori di accedere ,
, e
elementi, ma questo è tutto.
"Microsoft sta riportando Internet Explorer in pista."
Non è stato fino a quando Netscape ha rilasciato Navigator 4 (NS4) a metà del 1997 che il DOM di un browser consentiva agli sviluppatori web di modificare una pagina con JavaScript. La tecnica di manipolare elementi con JavaScript e il DOM è stata soprannominata Dynamic HTML (DHTML). Il DHTML di NS4 è stato sicuramente un passo avanti, ma il DOM proprietario e mal progettato e basato su layer e il CSS (Cascading Style Sheet) limitato supportano gli sviluppatori limitati in ciò che potevano effettivamente realizzare.
Netscape non ha implementato un modello a oggetti completo. A parte la funzionalità DOM Level 0, gli unici elementi a cui uno sviluppatore poteva accedere erano elementi posizionati in modo assoluto,
elementi, e
elementi (gli ultimi due elementi erano di fatto posizionati). Ciascuno di questi tipi di elementi era rappresentato da a Strato
oggetto nel DOM di NS4. Netscape progettato Strato
gli oggetti sono molto simili agli oggetti frame (e quindi finestra). Ogni Strato
oggetto aveva un documento
proprietà, che fondamentalmente era un altro documento HTML. Come i fotogrammi, a Strato
l'oggetto potrebbe essere annidato in un altro Strato
oggetto, rendendo il codice per accedere a quei livelli estremamente prolissi come il seguente:
var myLayer1 = document.layers ["myLayerId"]. document.layers ["mySecondLayerId"]; // o var myLayer2 = document.myLayerId.document.mySecondLayerId;
Queste due righe di codice fanno la stessa cosa: accedono a Strato
oggetto con un id
di mySecondLayerId
che è annidato all'interno di un livello con un id
di myLayerId
. Sì, gli sviluppatori hanno dovuto scendere dal livello "albero" per accedere ai livelli annidati.
Il DOM di NS4 non consentiva la creazione, l'inserimento, il riposizionamento e la rimozione di oggetti DOM, ma poiché ogni livello esposto a documento
oggetto, uno sviluppatore potrebbe modificare dinamicamente il contenuto di un livello usando il Scrivi()
, caricare()
, e vicino()
metodi. Mentre questo dà un po 'di energia extra al modello di livello, ha limitato gli sviluppatori nel modo in cui potevano aggiornare dinamicamente una pagina. Nuovi contenuti dovrebbero essere scritti o caricati in un livello, rimuovendo efficacemente il contenuto esistente del livello. Inutile dire che la maggior parte degli sviluppatori ha evitato la manipolazione del contenuto e si è invece concentrata sulla modifica dello stile di un livello.
Lo sviluppo Web utilizzando il DOM di NS4 è stato doloroso e frustrante.
Ma lo stile nel DOM di NS4 era una cosa divertente. Mentre il browser supportava i CSS in una certa misura, Strato
oggetti non fornivano un'API per gli sviluppatori per accedere direttamente a un livello stile
attributo come quello di oggi stile
oggetto. Anziché, Strato
gli oggetti mostravano un insieme molto limitato di proprietà che alteravano la posizione di un livello, la visibilità, il ritaglio e il colore / l'immagine di sfondo, nient'altro e anche il valore accettato da queste proprietà era piuttosto limitato. Ad esempio, le proprietà di posizionamento e di ritaglio accettano solo valori numerici; uno sviluppatore non ha potuto specificare un'unità (come px, em, pt, ecc.). Segue un esempio di tale codice:
var myLayer = document.myLayerId.document.mySubLayerId; myLayer.top = 10;
Inutile dire che lo sviluppo web utilizzando il DOM di NS4 era doloroso e frustrante. Le funzionalità DHTML estremamente limitate di NS4 derivano dalle limitazioni del motore di rendering di NS4 (non è in grado di ridisporre la pagina). Ma perché spendere così tanto tempo sul DOM di Netscape, specialmente in un articolo che dovrebbe riguardare IE? Se Netscape avesse vinto la guerra dei browser, il DOM di oggi sarebbe stato un passo evolutivo dal DOM presentato da Netscape in NS4. Mentre il DOM di oggi è uno standard proposto dal W3C (e alcune idee di Netscape sono implementate nello standard di oggi), il DOM di oggi è fortemente influenzato dal DOM di IE4.
Solo pochi mesi dopo che Netscape ha rilasciato Navigator 4, Microsoft ha rilasciato la quarta versione di IE. Anch'esso includeva il supporto per DHTML, ma L'implementazione di Microsoft era molto diversa e superiore a NS4. IE4 vantava un supporto CSS molto migliore e un modello di oggetti più completo per accedere e manipolare elementi e contenuti nella pagina. L'effetto del DOM di IE4 era di vasta portata; infatti, uno sviluppatore può trovare molte somiglianze tra il DOM di IE4 e il DOM standard.
"Microsoft ha cambiato il volto non solo dello sviluppo front-end, ma dello sviluppo web nel suo complesso?"
I progettisti di IE4 volevano trasformare il browser in una piattaforma per le applicazioni Web. Quindi si avvicinarono all'API di IE4 come un sistema operativo - fornendo un modello di oggetto quasi completo che rappresentava ogni elemento (e gli attributi di un elemento) come un oggetto a cui si poteva accedere con un linguaggio di scripting (IE4 supportava sia JavaScript che VBScript).
Nel DOM di IE4, il mezzo principale per accedere a un particolare elemento nella pagina era il proprietario tutti[]
collezione, che conteneva ogni elemento nel documento. Gli sviluppatori potevano accedere a elementi con un indice numerico o specificando un elemento id
o nome
, come questo:
var myElement1 = document.all ["myElementId"]; // o var myElement2 = document.all.myElementId;
Usando questo codice, gli sviluppatori potevano accedere all'oggetto elemento con un id di myElementId
indipendentemente da dove esisteva all'interno della pagina. Questo è in netto contrasto con il modello di livello di Netscape in cui gli sviluppatori potevano accedere ai livelli solo attraverso la gerarchia del livello. La funzionalità di document.all [ "elementId"]
evoluto nello standard document.getElementById ()
metodo. Ma questo non era l'unico modo in cui uno sviluppatore poteva accedere agli elementi; si può camminare sull'albero DOM e toccare ogni elemento con il bambini[]
collezione e parentElement
precursore della proprietà allo standard childNodes []
e parentNode
proprietà.
Oltre al caricamento di elementi come oggetti, il DOM di IE4 rappresentava gli attributi di un elemento come proprietà dell'oggetto elemento. Ad esempio, il id
, nome
, e stile
proprietà mappate direttamente su un elemento id
, nome
, e stile
attributi, rispettivamente. Questo design è diventato standard.
Microsoft ha inventato il
innerHTML
proprietà.
Come Netscape, Microsoft non ha fornito un'API completa per aggiungere, spostare e rimuovere dinamicamente nodi con JavaScript. Hanno, tuttavia, inventato il innerHTML
proprietà per ottenere o impostare il contenuto di un elemento. A differenza di Netscape Strato
oggetto di Scrivi()
e caricare()
metodi, il innerHTML
la proprietà non era una soluzione "tutto o niente" per modificare il contenuto di un elemento; uno sviluppatore potrebbe usare innerHTML
per cancellare, sostituire o aggiungere completamente al contenuto di un elemento. Ad esempio, il codice seguente ottiene il contenuto di un elemento e lo modifica:
var el = document.all.myElementId, html = el.innerHTML; el.innerHTML = html + "Ciao, innerHTML";
Ad oggi, il innerHTML
la proprietà è una pietra miliare del DHTML. È un mezzo efficace per aggiungere grandi quantità di contenuti a un elemento. Anche se non è mai stato formalmente incluso in nessuno standard DOM, tutti i principali browser implementano un innerHTML
proprietà.
Microsoft ha inventato diversi strumenti e progetti che si sono evoluti in componenti del DOM standard, ma il lavoro svolto con l'API di stile di IE4 è diventato standard con poche modifiche. La chiave per cambiare lo stile di un elemento in IE4 è stata la
stile
proprietà, la stessa proprietà (e sintassi) utilizzata dagli sviluppatori oggi.
DHTML ha cambiato lo sviluppo del web per sempre. È stato, tuttavia, il DOM di IE4 che ha spinto la tecnologia (e lo sviluppo web) in avanti ad essere l'influenza principale sulle specifiche del DOM 1 e 2 del W3C. IE4 ha rivoluzionato lo sviluppo del web nel 1997, e IE lo avrebbe fatto di nuovo alcuni anni dopo.
Ajax ha aperto le porte per lo sviluppo del web.
Prima che Ajax fosse Ajax, veniva chiamato script remoto e gli sviluppatori sfruttando la potenza dello scripting remoto utilizzavano frame nascosti e iframe per la comunicazione client-server. Un frame (i) nascosto di solito conteneva un modulo che veniva compilato e inoltrato dinamicamente tramite JavaScript. La risposta del server sarebbe un altro documento HTML contenente JavaScript che ha notificato alla pagina principale che i dati sono stati ricevuti e pronti per l'uso. Era rozzo, ma ha funzionato.
Tuttavia, c'era un'alternativa: una gemma poco conosciuta sepolta nella libreria MSXML 2.0 di Microsoft. IE5, pubblicato nel marzo 1999, comprendeva MSXML 2.0 e gli sviluppatori hanno trovato un componente chiamato XMLHttp
(il vero nome dell'interfaccia era IXMLHTTPRequest
). Il suo nome è fuorviante, come il XMLHttp
l'oggetto funziona più come un semplice client HTTP di qualsiasi altra cosa. Gli sviluppatori non solo potevano inviare richieste con l'oggetto, ma potevano monitorare lo stato delle richieste e recuperare la risposta del server.
Naturalmente, XMLHttp
ha iniziato a sostituire la tecnica dei frame nascosti (i) per la comunicazione client-server. Un paio di anni dopo, Mozilla ha creato il proprio oggetto, modellato su quello di Microsoft XMLHttp
, e lo chiamò XMLHttpRequest
. Apple ha seguito l'esempio con i loro XMLHttpRequest
oggetto nel 2004, e Opera ha implementato l'oggetto nel 2005.
Nonostante il suo crescente interesse, la popolarità di
XMLHttp
/XMLHttpRequest
(collettivamente noto come XHR qui fuori) non esplose fino al 2005 quando Jesse James Garrett pubblicò il suo articolo, "Ajax: un nuovo approccio alle applicazioni Web.?
Ajax aprì le porte allo sviluppo del web, e in prima linea JavaScript, XHR e DHTML - due dei quali erano invenzioni di Microsoft. Allora, cos'è successo? Cosa ha causato un browser che ha letteralmente cambiato il modo in cui gli sviluppatori web scrivono le applicazioni web per diventare la rovina del Web moderno?
Nel 2003, la quota di mercato totale di Internet Explorer era del 95% circa; Microsoft ha ufficialmente vinto la guerra dei browser. Senza concorrenza reale nello spazio Web, Microsoft ha spostato l'attenzione dal browser a .NET. Ciò è confermato dalle citazioni di molti dipendenti Microsoft, ma il più significativo è da un articolo di CNET intitolato? Ajax aiuterà Google a pulire? In esso, Charles Fitzgerald, General Manager di Microsoft per le tecnologie di piattaforma, ha dichiarato:
?E 'un po' deprimente che gli sviluppatori stiano appena girando attorno a queste cose che abbiamo spedito nel tardo 20 ° secolo [ed: DHTML e Ajax], ma XAML è in un'altra classe. Questa altra roba è molto sfacciata, molto difficile da eseguire il debug. Abbiamo visto alcuni hack piuttosto impressionanti, ma se si guarda a ciò che XAML inizia a risolvere, è un importante, importante passo avanti.?
Così, nel maggio 2003, Microsoft annunciò che IE non sarebbe più stato rilasciato separatamente da Windows (anche l'eccellente IE5 per Mac era in scatola). Il browser sarebbe comunque sviluppato come parte del sistema operativo Windows in evoluzione, ma Microsoft non rilascia alcuna versione standalone di IE. Scommettevano principalmente su ClickOnce, una tecnologia che consente agli sviluppatori di scrivere applicazioni convenzionali (utilizzando .NET ovviamente) e distribuirle tramite il Web.
Ma il Web ha continuato ad evolversi nel percorso originariamente impostato da Microsoft con IE4 e IE5, e Microsoft ha iniziato a perdere quote di mercato per l'erede di Netscape: Firefox. Gli sviluppatori stavano scrivendo applicazioni web che vivevano nel browser, non in applicazioni convenzionali tramite ClickOnce. Ciò ha costretto Microsoft a prendere IE, rispolverare e iniziare a rilasciare di nuovo versioni autonome.
IE9, include un supporto agli standard molto migliore su tutta la linea.
Le prossime due versioni, 7 e 8, erano in gran parte evolutive. IE7 conteneva una serie di correzioni di bug, il XMLHttpRequest
identificatore (sebbene abbia ancora creato un XMLHttp
oggetto dalla libreria MSXML) e miglioramenti all'interfaccia utente e alla sicurezza.
IE8 era in gran parte più o meno lo stesso, tranne che sandboxing ogni scheda, una funzionalità che Google ha implementato anche in Chrome (Microsoft l'ha annunciato prima). Isola ogni scheda nel proprio processo, aumentando la sicurezza e la stabilità. Il sandboxing sta diventando standard nei browser di oggi (Firefox non ha ancora la capacità) e si sta inoltre spostando nel regno dei componenti aggiuntivi e dei plug-in.
Microsoft sta riportando Internet Explorer in pista.
L'ultima versione, IE9, include molto meglio il supporto degli standard su tutta la linea, ma innova anche con il suo nuovo motore JavaScript JIT-compilazione (che utilizza un core CPU separato se disponibile e può accedere alla GPU) e il suo motore di rendering con accelerazione hardware. Mentre i motori JavaScript di compilazione JIT non sono nuovi, la capacità di IE9 di scaricare la compilazione su un core separato in parallelo al rendering della pagina è un risultato che stimolerà le prestazioni necessarie per le applicazioni web. Le sue capacità di accelerazione hardware si sono rivelate utili al momento del debutto e ora Firefox e Chrome offrono in certa misura l'accelerazione hardware.
Non si può negare che Internet Explorer abbia causato mal di testa per gli sviluppatori web. La pausa di cinque anni tra IE6 e IE7 ha fatto sì che Microsoft si trovasse molto indietro rispetto alla concorrenza, rendendo lo sviluppo del front-end meno che ideale. Ma Microsoft sta riportando Internet Explorer sulla giusta strada. Hanno modellato lo sviluppo del web per quello che è oggi; spero che lo facciano di nuovo.
La prossima versione di Internet Explorer, versione 9, è prevista per essere rilasciata ufficialmente il 14 marzo 2011.