Apa yang sangat buruk tentang DOM?


42

Saya terus mendengar orang (khususnya Crockford) mengatakan DOM adalah API yang mengerikan, tetapi tidak benar-benar membenarkan pernyataan ini. Terlepas dari inkonsistensi lintas-browser, apa saja alasan mengapa DOM dianggap sangat buruk?


31
Apart from cross-browser inconsistenciesBukankah itu cukup?
yannis

3
pertanyaan yang sama (termasuk referensi ke Crockford) telah ditanyakan dan ditutup sebagai tidak konstruktif pada SO: Apa yang salah dengan DOM?
nyamuk

3
Sebagian besar orang yang mengatakan DOM mengerikan adalah bodoh atau mengatakan browser lawas itu buruk
Raynos

Model propagasi acara salah: itu tidak mengizinkan node induk untuk mengesampingkan pengendali acara anak untuk menambahkan perilaku kustom. Dalam OOP itu disebut fungsi virtual, polimorfisme, dan delegasi (pewarisan melalui komposisi). Acara ditangkap dari atas ke bawah terlebih dahulu, lalu digelembungkan ke atas. Di Elm mereka telah menerapkan model komposabel yang sangat memadai di mana peristiwa-peristiwa menggelembung terlebih dahulu kemudian "ditangkap" (berkembang dari orang tua ke anak-anak). Hal ini memungkinkan untuk membatalkan acara ("tutup jendela?"), Dan menimpa / menghias perilaku komponen anak-anak.
Brian Haak

Jawaban:


33

Crockford telah memberikan presentasi luas berjudul "An Inconvenient API: The Theory of the Dom" di mana ia menjelaskan pendapatnya tentang DOM. Ini gondrong (1jam 18m), tetapi karena kebanyakan presentasi Crockford itu cukup menyenangkan dan mendidik.

Inkonsistensi lintas browser tampaknya menjadi perhatian utamanya, dan saya setuju itu satu-satunya hal yang paling menyebalkan tentang DOM. Dia mengidentifikasi:

  • Perangkap kepemilikan (perangkap peramban dan server)
  • Melanggar aturan,
  • Peperangan perusahaan,
  • Tekanan waktu yang ekstrem

sebagai masalah utama di balik berbagai inkonsistensi, menambahkan bahwa presentasi, sesi, atau interaktivitas tidak pernah diantisipasi dalam visi asli web. Beberapa contoh ketidakkonsistenan meliputi:

  • document.all, satu-satunya fitur Microsoft,
  • fakta itu namedan iddulu bisa dipertukarkan.
  • fungsi yang berbeda pada pengambilan node:
    • document.getElementById(id),
    • document.getElementsByName(name),
    • *node*.getElementsByTagName(tagName))

dan berlanjut dengan beberapa contoh lagi, sebagian besar menargetkan penargetan DOM, kebocoran memori, dan acara mengalir dan menggelegak. Ada slide ringkasan, berjudul "The Cracks of DOM" yang merangkum:

  • Daftar bug DOM mencakup semua bug di browser.
  • Daftar bug DOM mencakup semua bug di semua browser yang didukung.
  • Tidak ada DOM yang sepenuhnya menerapkan standar.
  • Banyak DOM tidak dijelaskan dalam standar apa pun.

Singkatnya, ini adalah API yang berantakan dan berantakan. Ini mungkin tampak seperti nitpicking, tetapi Anda harus ingat bahwa ketika Anda mengembangkan untuk web, Anda jarang bisa memilih browser yang akan digunakan pelanggan Anda. Harus menguji semuanya dalam setidaknya dua versi dari masing-masing browser utama menjadi tua segera. API seharusnya konsisten dan DOM adalah korban dari perang browser , tetapi semakin baik. Platform ini masih tidak netral seperti W3C (dan saya pikir kita semua) akan menyukainya, tetapi vendor browser tampaknya lebih bersemangat untuk bekerja sama daripada mereka lima atau sepuluh tahun yang lalu.


18
inkonsistensi lintas-browser tidak ada hubungannya dengan DOM. Itulah yang kami sebut "browser lawas". Jangan salahkan DOM atas keberadaan browser lawas. Itu seperti mengatakan "linux menyebalkan karena saya tahu distro lama dan dan mereka payah".
Raynos

document.alldalam standar
Raynos

@ Raynos Ya dan tidak. Vendor peramban telah menjadi kekuatan utama di balik evolusi standar web terlalu lama, mengacaukan semuanya, analogi dengan linux tidak terlalu berpengaruh. Apa yang saya coba tekankan adalah bahwa DOM itu sendiri tidak salah, itu adalah implementasi yang salah dan cara yang tidak koheren standar berkembang. Ambil document.allcontoh, itu ada dalam standar tetapi sebagai pelanggaran yang disengaja .
yannis

1
Saya tidak dapat diganggu untuk berteriak-teriak tentang orang-orang yang membingungkan browser lawas dan DOM. Saya meninggalkan komentar. Sedangkan untuk browser lawas, menjatuhkan dukungan untuk mereka adalah sepele, lakukan saja. Miliki nyali untuk melakukannya. Entah Anda mengontrol kehidupan pengembangan Anda atau IE8 mengendalikannya. Saya mengendalikan milik saya.
Raynos

3
Jawaban bagus; gangguan lain yang belum Anda sebutkan adalah bahwa DOM API sangat verbose - hanya membandingkan kode jQuery khas untuk, katakanlah, memasukkan elemen dengan beberapa atribut pada node tertentu vs versi DOM polos yang melakukan hal yang sama.
Pelaku

15

Apa yang salah dengan DOM? Selain dari sintaks yang diilhami Java (yang disentuh Crockford), tidak ada.

Apa yang "salah" berlaku sebagian untuk vendor browser; apa yang "salah" berlaku untuk pengembang; apa yang "salah" berlaku untuk ketidaktahuan.

Jadi, dari mana harus memulai?

Masuk kedalam lubang kelinci…

Vendor Peramban

Pertama, vendor browser telah berjuang secara kompetitif selama beberapa dekade untuk menjadi yang "terbaik", "tercepat", "termudah", dll. Dalam dekade pertama (199x-2000), Microsoft memerintah. Internet Explorer memperkenalkan ide-ide inovatif seperti:

  • mengekspos mesin parsing HTML browser sebagai innerHTMLdan outerHTML;
  • manipulasi teks yang mudah dengan innerTextdan outerText;
  • model acara ( *tachEvent) yang merupakan cetak biru untuk Acara DOM Level 2 ( *EventListener).

Masing-masing telah berkontribusi (lebih baik dan lebih buruk) secara signifikan ke tumpukan pengembangan web saat ini. Opera bahkan melangkah lebih jauh dengan mengimplementasikan ketiganya dalam versi 7 (2003).

Namun, Netscape memiliki model acara DOM sendiri ( *EventListener). Pada tahun 2000, itu menjadi spesifikasi Acara DOM Level 2. Safari 1 (2003) mengimplementasikan model ini; Opera 7 (2003) juga menerapkan model ini. Ketika reruntuhan Netscape menjadi Mozilla, Firefox 1 (2004) mewarisi model tersebut.

Untuk bagian pertama dari dekade kedua (2000-2004), Microsoft berkuasa. Internet Explorer 6 (2001) adalah browser terbaik saat itu. Salah satu pesaingnya, Opera 6 (2001), belum mengimplementasikan DOM Level 1 Core ( createElementet al.) Microsoft menerapkannya di Internet Explorer 4 (1997) sebelum spesifikasi bahkan menjadi rekomendasi (1998).

Namun, bagian kedua dari dekade kedua (2004-2010) akan menjadi bencana bagi Microsoft. Pada tahun 2003, Apple merilis Safari 1.0; pada tahun 2004, Mozilla menyelesaikan Firefox 1.0. Microsoft tampaknya tertidur di atas takhta di atas gunung browser. Internet Explorer 7 tidak dirilis hingga 2006: kesenjangan lima tahun sejak tanggal rilis Internet Explorer 6. Tidak seperti Internet Explorer versi 4 hingga 6, versi 7 sedikit berinovasi; Perubahan DOM sangat kecil. Hampir dua setengah tahun kemudian, Internet Explorer 8 dirilis. Microsoft terbangun dari tidurnya dan memperhatikan perpaduan vendor browser lain yang telah terbentuk di sekitar berbagai standar web. Sayangnya, terlalu banyak waktu telah berlalu sejak inovasi nyata terakhir Microsoft. Sebuah gerakan telah dibuat di antara vendor browser. Fitur DOM baru harus ditambahkan dalam bentuk spesifikasi ke W3C; Gagasan Microsoft ditinggalkan di masa lalu. Model acara Microsoft (*tachEvent) diasingkan untuk model Acara DOM Level 2. Internet Explorer tidak menerapkan model sebelumnya hingga versi 9 (2011), yang menjadi model DOM Level 3 Events.

Kebodohan Microsoft (DOM) dapat disimpulkan sebagai berikut:

  • kehadiran sebagai fitur inti Windows, dan persyaratan keamanan tingkat OS yang dihasilkan;

  • mengandalkan ActiveX untuk kode sisi klien;

  • inovasi yang meruncing dengan penasaran setelah versi 6 (2001).


(Web) Pengembang

Kedua, pengembang menanggung sejumlah kesalahan. Ketika web terus berkembang, semakin banyak orang "berkecimpung" dalam pengembangan web. Ini telah menyebabkan dilusi dalam bakat dan etos kerja. Masalahnya, bagaimanapun, terutama terletak pada sikap. "Selesaikan dengan cepat" lebih diutamakan daripada "Selesaikan dengan benar." Akibatnya, halaman web yang tak terhitung banyaknya tidak kompatibel dengan berbagai browser. Salah satu penyebab utama ketidakcocokan ini adalah praktik yang disebut "agen pengguna mengendus". Meskipun praktiknya masih digunakan hingga saat ini, praktik ini terbukti salah dan berbahaya. Opera bahkan melangkah lebih jauh dengan "membekukan" versi agen pengguna di "9,80" di versi 10 (2009) dan seterusnya. Ini dimaksudkan agar skrip yang salah tidak rusak. Praktek yang jauh lebih baik disebut "


Ketidakpedulian

Ketiga, titik kesalahan pilihan saya adalah ketidaktahuan; ketidaktahuan pada kenyataan bahwa vendor browser tidak bekerja bersama hampir cukup untuk membuat spesifikasi yang disatukan; ketidaktahuan pada kenyataan bahwa Microsoft dijauhi pengguna browser lain; ketidaktahuan pada kenyataan bahwa pengembang terlalu malas atau terlalu rabun untuk repot meneliti peramban (terutama yang tidak populer ). Ada banyak perbedaan dalam API dan implementasi. Sebagian besar dapat dihindari dengan pendekatan yang disederhanakan-namun-defensif (mengandalkan DOM 0) bersama dengan sejumlah besar penelitian dan pengujian. Ketidaktahuan telah menyebabkan anggapan bahwa Internet Explorer 6 adalah bencana bagi Bumi (ingat tempatnya di tahta browser yang disebutkan sebelumnya.)


Refleksi

Sayangnya, DOM hanyalah API yang disalahpahami. Banyak keinginan untuk melempar batu (melalui FUD), tetapi sedikit keinginan untuk mempelajari seluk-beluknya. Salah satu hasil dari ketidaktahuan ini adalah pengenalan "penyeleksi" DOM. DOM at heart adalah API untuk memanipulasi pohon dokumen. Traversal pohon harus digunakan untuk masalah kompleks mengingat bentuk dokumen yang diuraikan. Dengan diperkenalkannya DOM Selectors API, pengembang sekarang dapat memanfaatkan mesin traversal CSS browser. Ini cukup nyaman, tetapi menyembunyikan bentuk sebenarnya dari pohon dokumen. Dengan "penyeleksi", pengambilan elemen node bersifat elementer. Namun, DOM memiliki sebelas jenis simpul lain yang ditentukan. Bagaimana dengan simpul teks? Node komentar? Node dokumen? Ini juga merupakan simpul yang sering diinginkan saat berinteraksi dengan DOM.


Kesimpulan

Singkatnya, luangkan waktu Anda dan baca berbagai spesifikasi DOM. Uji kode di sebanyak mungkin browser. Jika Internet Explorer dianggap berperilaku aneh, hubungi MSDN. Paling sering, perilaku tersebut didokumentasikan.

(Anekdot historis dapat dan mungkin tidak akurat; setiap ketidakakuratan boleh diajukan.)

—Matt


Opera bahkan melangkah lebih jauh dengan "membekukan" - Saya benci pendekatan semacam ini karena sangat picik (beberapa pengembang tidak dapat kode, jadi mari kita mengacaukan API untuk membantu mereka). Anda biasanya perlu mendapatkan jenis dan versi peramban ketika ada bug khusus di peramban itu yang pelanggan Anda perbaiki. Memperbaiki untuk browser tertentu jauh lebih mudah daripada menerapkan beberapa "deteksi bug" (yaitu kebalikan dari "deteksi fitur").
Pavel Horal

3

DOM adalah API yang mengerikan

Itu SALAH . DOM BUKAN API yang mengerikan.

  • Pertama, ingat bahwa DOM adalah agnostik bahasa. Semua bahasa utama telah menerapkan API. Ini karena Anda tidak menggunakannya di browser, tetapi di mana pun Anda perlu berurusan dengan XML.

  • Kedua, perhatikan bahwa DOM tidak mendefinisikan kelas tetapi antarmuka. Ini memiliki implikasi yang sangat penting: bahasa dapat mengimplementasikannya dengan cara yang sesuai dengan konstruksi dan filosofi mereka. Ini membebaskan semua bahasa dari harus konsisten dalam implementasi dengan yang lain.

  • Ketiga, DOM adalah salah satu dari dua cara utama untuk mem-parsing XML (selain SAX), dan tergantung pada konteks Anda, DOM bisa sangat efisien.

Yang Anda maksud adalah DOM peramban. Dan, saya setuju bahwa DOM "terasa" buruk di browser. Sebagian alasannya adalah ketidakcocokan browser. Tapi, saya tidak setuju bahwa mereka adalah satu-satunya alasan reputasi buruk DOM di browser.

  • Pertama, jika Anda memikirkannya, DOM adalah salah satu area di mana ketidakcocokan ini relatif lebih mudah diatasi. Sebagai perbandingan, acara, misalnya jauh lebih rumit dan menjengkelkan untuk dinormalisasi.

  • Kedua, deteksi fitur untuk fitur DOM lebih sederhana daripada untuk area lain.

  • Ketiga, DOM 3 jauh lebih baik - dan hari ini semua browser mendukung sebagian besar.

Tentu saja, ketidakcocokan itu menyebalkan, tetapi ketika Anda sampai pada mereka, DOM jauh lebih menjengkelkan.

Saya juga tidak setuju dengan alasan seperti perangkap Hak Milik, peperangan Korporat, dll. Menjadi alasannya.

  • Saya pikir itu adalah pemutusan antara filosofi JavaScript menjadi bahasa yang ringan, dan implementasi DOM yang terinspirasi dari Jawa - yang telah berkontribusi banyak frustrasi.

  • Kedua, DOM telah dirancang untuk XML, dan telah diadaptasi untuk HTML. Karenanya di browser, kami memiliki dua DOM - HTML DOM dan XML DOM - dan keduanya tidak kompatibel.

  • Ketiga, traversal DOM di browser tidak bagus. Kami tidak memiliki XPath untuk HTML DOM, jadi sebelum mesin pemilih CSS, sangat melelahkan untuk melakukan traversal.

Akhirnya, saya pikir hari ini , dengan browser modern, (dan dengan browser lama perlahan menghilang) tidak ada alasan DOM perlu disebut buruk. Ini pasti akan menjadi lebih baik di browser - baik API maupun implementasinya.


peristiwa-peristiwa sama sepele untuk dinormalisasi: \
Raynos

pikirkan - jika Anda harus mendukung currentTargetproperti untuk objek acara - apakah itu sepele?
treecoder

mengimplementasikan event bubbling seperti 100 baris kode: \
Raynos

currentTargetbukan hanya peristiwa yang menggelegak - dan apakah akan lebih bijak untuk menerapkan peristiwa yang Anda alami sendiri?
treecoder

1
Dan dengan dataManagerduduk di luar, Anda mengatakan bahwa kode itu Sepele? :)
treecoder
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.