Cosa c'è di così brutto nel DOM?

Continuo a sentire la gente (Crockford in particolare) che dice che il DOM è un'API terribile, ma non giustifica davvero questa affermazione. A parte le incongruenze tra browser, quali sono alcuni dei motivi per cui il DOM è considerato così male?

Crockford ha tenuto un'ampia presentazione dal titolo "An Inconvenient API: The Theory of the Dom", dove spiega più o meno le sue opinioni sul DOM. È lungo (1h 18m), ma come la maggior parte delle presentazioni di Crockford è abbastanza divertente ed educativo.

Le incoerenze tra browser sembrano essere la sua principale preoccupazione, e sono d'accordo che sia la cosa più fastidiosa sul DOM. Identifica:

• Trap proprietari (trap browser e server),
• Infrazione alle regole,
• Guerra corporativa,
• Estrema pressione temporale

come le questioni chiave alla base delle varie incongruenze, l'aggiunta di quella presentazione, sessione o interattività non è mai stata anticipata nella visione originale del web. Alcuni esempi di incoerenze includono:

• document.all, una funzionalità unica di Microsoft,
• il fatto che nameed idera intercambiabile.
• le diverse funzioni sul recupero dei nodi:
  
  • document.getElementById(id),
  • document.getElementsByName(name),
  • *node*.getElementsByTagName(tagName))

e continua con alcuni altri esempi, principalmente mirati a attraversare il DOM, perdite di memoria e gocciolamenti e bolle di eventi. C'è una diapositiva di riepilogo, intitolata "The Cracks of DOM" che riassume:

• L'elenco di bug DOM include tutti i bug nel browser.
• L'elenco di bug DOM include tutti i bug in tutti i browser supportati.
• Nessun DOM implementa completamente gli standard.
• Gran parte del DOM non è descritto in nessuno standard.

In breve, è un'API disordinata e disordinata. Potrebbe sembrare nitpicking, ma devi tenere a mente che quando stai sviluppando per il web, raramente puoi scegliere il browser che i tuoi clienti useranno. Dover testare tutto in almeno due versioni di ciascuno dei principali browser invecchia molto presto. Un'API dovrebbe essere coerente e il DOM è stato vittima delle guerre del browser , ma sta migliorando. Non è ancora così neutrale rispetto alla piattaforma come vorrebbe il W3C (e penso che tutti noi), ma i venditori di browser sembrano molto più desiderosi di collaborare di quanto non fossero cinque o dieci anni fa.

Cosa c'è che non va nel DOM? A parte la sintassi ispirata a Java (che Crockford ha toccato), niente.

Ciò che è "sbagliato" si applica in parte ai fornitori di browser; ciò che è "sbagliato" si applica agli sviluppatori; ciò che è "sbagliato" si applica all'ignoranza.

Quindi, da dove cominciare?

Giù nella tana del coniglio…

Fornitori di browser

Prima di tutto, i produttori di browser hanno combattuto in maniera competitiva per decenni per essere il "migliore", il "più veloce", il "più semplice", ecc. Nel primo decennio (199x - 2000), Microsoft ha dominato il posatoio. Internet Explorer ha introdotto idee innovative come:

• esponendo il motore di analisi HTML del browser come innerHTMLe outerHTML;
• facile manipolazione testuale con innerTexte outerText;
• un modello di evento ( *tachEvent) che era il progetto per gli eventi di livello DOM 2 ( *EventListener).

Ognuno ha contribuito (nel bene e nel male) in modo significativo allo stack di sviluppo web di oggi. Opera arrivò addirittura a implementare tutti e tre nella versione 7 (2003).

Tuttavia, Netscape aveva il suo modello di eventi DOM ( *EventListener). Nel 2000, è diventata la specifica DOM Level 2 Events. Safari 1 (2003) ha implementato questo modello; Anche Opera 7 (2003) ha implementato questo modello. Quando le rovine di Netscape sono diventate Mozilla, Firefox 1 (2004) ha ereditato il modello.

Per la prima sezione del secondo decennio (2000-2004), Microsoft regnò sovrana. Internet Explorer 6 (2001) era di gran lunga il miglior browser in quel momento. Uno dei suoi concorrenti, Opera 6 (2001), non aveva ancora implementato il DOM Level 1 Core ( createElementet al.) Microsoft lo aveva implementato in Internet Explorer 4 (1997) prima ancora che la specifica diventasse una raccomandazione (1998).

Tuttavia, la seconda sezione del secondo decennio (2004-2010) si rivelerebbe disastrosa per Microsoft. Nel 2003, Apple ha rilasciato Safari 1.0; nel 2004, Mozilla ha completato Firefox 1.0. Microsoft sembrava addormentato sul suo trono in cima alla montagna dei browser. Internet Explorer 7 non è stato rilasciato fino al 2006: un intervallo di cinque anni che risale alla data di rilascio di Internet Explorer 6. A differenza di Internet Explorer versioni da 4 a 6, la versione 7 ha innovato poco; Le modifiche al DOM sono state minime. Quasi due anni e mezzo dopo, Internet Explorer 8 è stato rilasciato. Microsoft si era svegliata dal sonno e notò la coalescenza che altri fornitori di browser avevano formato attorno a numerosi standard web. Sfortunatamente, era trascorso troppo tempo dall'ultima vera innovazione di Microsoft. È stato creato un movimento tra i fornitori di browser. Le nuove funzionalità DOM dovevano essere aggiunte nel modulo delle specifiche al W3C; Le idee di Microsoft sono state lasciate in passato. Modello di eventi di Microsoft (*tachEvent) è stato evitato per il modello di eventi DOM livello 2. Internet Explorer non ha implementato il modello precedente fino alla versione 9 (2011), che è diventata il modello di eventi di livello 3 DOM.

Le follie di Microsoft (DOM) possono essere riassunte dai seguenti punti:

• presenza come funzionalità principale di Windows e conseguenti requisiti di sicurezza a livello di sistema operativo;

• affidamento su ActiveX per il codice lato client;

• innovazione che si è assottigliata in modo curioso dopo la versione 6 (2001).

(Web) Sviluppatori

In secondo luogo, gli sviluppatori hanno una certa colpa. Mentre il web ha continuato a decollare, sempre più persone si "dilettano" nello sviluppo web. Ciò ha portato a una diluizione del talento e dell'etica del lavoro. Il problema, tuttavia, sta principalmente nell'atteggiamento. "Fallo rapidamente" ha la precedenza su "Fallo bene". Di conseguenza, innumerevoli pagine Web sono incompatibili con vari browser. Una delle principali cause di questa incompatibilità è una pratica chiamata "sniffing dell'agente utente". Sebbene la pratica sia ancora in uso oggi, è stata dimostrata sia errata che dannosa. Opera è persino arrivata al punto di "congelare" la versione dell'agente utente a "9.80" nella versione 10 (2009) e oltre. Questo aveva lo scopo di impedire la rottura di script errati. Una pratica molto migliore chiamata "

Ignoranza

In terzo luogo, il mio punto di colpa preferito è l'ignoranza; ignoranza nel fatto che i fornitori di browser non hanno lavorato insieme abbastanza da creare specifiche unificate; ignoranza nel fatto che Microsoft ha evitato gli utenti di altri browser; ignoranza nel fatto che gli sviluppatori sono o troppo pigri o troppo miopi per disturbare la ricerca dei browser (specialmente quelli che non sono in voga ). Vi sono molte differenze nelle API e nelle implementazioni. La maggior parte può essere evitata con un approccio semplificato ma difensivo (affidamento su DOM 0) insieme a quantità abbondanti di ricerca e test. L'ignoranza ha portato all'idea che Internet Explorer 6 è una rovina sulla Terra (ricorda il suo posto sul trono del browser menzionato in precedenza).

Riflessione

Purtroppo, il DOM è solo un'API fraintesa. Molti desiderano lanciare pietre (via FUD), ma pochi desiderano apprenderne le complessità. Un risultato di questa ignoranza è l'introduzione dei "selettori" DOM. Il DOM in fondo è un'API per manipolare gli alberi dei documenti. Traversal tree dovrebbe essere usato per problemi complessi data la forma di un documento analizzato. Con l'introduzione dell'API selettori DOM, uno sviluppatore può ora sfruttare il motore di attraversamento CSS del browser. Questo è abbastanza conveniente, ma nasconde la vera forma di un albero di documenti. Con "selettori", il recupero del nodo elemento è elementare. Tuttavia, il DOM ha undici altri tipi di nodo specificati. Che dire dei nodi di testo? Nodi di commento? Nodi documento? Questi sono anche nodi che sono spesso desiderati durante l'interazione con il DOM.

Conclusione

In breve, prenditi il ​​tuo tempo e leggi le varie specifiche DOM. Prova il codice nel maggior numero di browser possibile. Se si ritiene che Internet Explorer si stia comportando in modo strano, consultare MSDN. Molto spesso, il comportamento è documentato.

(Gli aneddoti storici possono e possono essere imprecisi; eventuali inesattezze sono benvenute.)

-Opaco

DOM è un'API terribile

Questo è SBAGLIATO . DOM NON è un'API terribile.

• Innanzitutto, ricorda che DOM è indipendente dalla lingua. Tutte le principali lingue hanno implementato l'API. Questo perché non lo usi nel browser, ma ovunque devi occuparti di XML.

• In secondo luogo, notare che DOM non definisce classi ma interfacce. Ciò ha un'implicazione molto importante: i linguaggi possono implementarlo nel modo in cui si adatta ai loro costrutti e alla filosofia. Ciò libera tutte le lingue dal dover essere coerenti nell'attuazione con gli altri.

• In terzo luogo, DOM è uno dei due modi principali per analizzare XML (altro che è SAX) e, a seconda del contesto, DOM può essere molto efficiente.

Quello a cui ti riferisci è il DOM del browser. E, sono d'accordo che DOM "si sente" male nel browser. Parte del motivo è l'incompatibilità del browser. Ma non sono d'accordo sul fatto che siano l'unica ragione della cattiva reputazione di DOM nel browser.

• In primo luogo, se ci pensate, DOM è una di quelle aree in cui queste incompatibilità sono relativamente più facili da superare. In confronto, gli eventi, ad esempio, sono molto più complicati e fastidiosi da normalizzare.

• In secondo luogo, il rilevamento delle funzionalità per le funzionalità DOM è più semplice rispetto ad altre aree.

• Terzo, DOM 3 è decisamente migliore e oggi tutti i browser lo supportano.

Certamente, le incompatibilità sono fastidiose, ma quando si arriva a loro, DOM è molto meno irritante.

Sono anche in disaccordo con ragioni come trappole proprietarie, guerre corporative, ecc. Che ne sono la ragione.

• Penso che sia la disconnessione tra la filosofia di JavaScript come linguaggio leggero e l'implementazione di DOM ispirata a Java - che ha contribuito a gran parte della frustrazione.

• In secondo luogo, DOM è stato progettato per XML ed è stato adattato per HTML. Quindi nel browser, abbiamo esattamente due DOM - HTML DOM e XML DOM - e sono incompatibili.

• In terzo luogo, l'attraversamento del DOM nel browser non è buono. Non abbiamo XPath per HTML DOM, quindi prima dei motori di selezione CSS, era davvero noioso fare traversals.

Infine, penso oggi , con i browser moderni, (e con i browser più vecchi che stanno lentamente svanendo) non c'è motivo per cui DOM debba essere chiamato male. Certamente migliorerà nel browser, sia l'API che l'implementazione.