Keuntungan menggunakan JavaScript murni dibanding JQuery


86

Apa keuntungan menggunakan Javascript-only dibandingkan menggunakan JQuery-only?

Saya memiliki pengalaman terbatas dengan pengodean JavaScript dan JQuery. Saya telah menambahkan bit dan snippet dari masing-masing ke halaman HTML tapi saya sebagian besar kode hal sisi server dalam bahasa lain. Saya telah memperhatikan bahwa walaupun Anda secara teoritis dapat melakukan hal yang sama menggunakan salah satu dari dua pendekatan (dan tentu saja Anda bahkan dapat mencampurnya dalam proyek yang sama) tampaknya ada kecenderungan untuk selalu mulai menggunakan JQuery dari awal. tidak peduli apa tuntutan proyek itu.

Jadi saya hanya ingin tahu, apakah ada manfaat tepat waktu untuk tidak menggunakan JQuery saja tetapi alih-alih hanya menggunakan JavaScript biasa?

Saya tahu ini sepertinya bukan pertanyaan karena dapat dikatakan bahwa "tidak ada jawaban yang pasti" atau "itu bisa diperdebatkan selamanya", tetapi saya sebenarnya berharap untuk jawaban tepat waktu seperti "Anda dapat melakukan ini di satu pendekatan dan Anda tidak dapat melakukannya dengan yang lain ".


Sesuai komentar scrwtp, saya tidak merujuk hanya ke bagian Penanganan DOM. Pertanyaan saya agak: JQuery adalah perpustakaan. Untuk Javascript. Apa yang saya temukan aneh tentang perpustakaan ini sebagai lawan dari perpustakaan lain untuk bahasa lain adalah bahwa dalam kasus JQyery tampaknya dirancang untuk dapat menggunakannya secara eksklusif dan tidak perlu menyentuh Javascript secara langsung. Ini bertentangan dengan katakanlah Hibernate dan SQL, di mana meskipun perpustakaan (atau lebih tepatnya kerangka kerja dalam kasus ini, tapi saya pikir analoginya masih berlaku) menangani BANYAK aspek, Anda masih bisa menggunakan SQL saat menggunakannya , setidaknya untuk beberapa kasus pinggiran. Namun dalam kasus JQuery & Javascript, Anda dapat melakukan apa pun yang Anda lakukan dengan Javascript hanya menggunakan JQuery (atau setidaknya begitulah menurut saya).


Sesuai komentar Stargazer712: ya, saya setuju dengan Anda, pertanyaannya di sini adalah, seperti yang Anda katakan "hanya masalah bagaimana Anda akan menggunakan JavaScript". Itulah yang sebenarnya ingin saya tanyakan, tetapi saya telah membuat beberapa formulasi yang buruk. Berikut analogi lainnya: Spring Expression Language. Itu adalah perpustakaan Java. Anda tidak dapat menggunakannya tanpa Java, ini didasarkan pada Java, dan melalui semua itu Anda masih bisa menggunakan Java. Tetapi dalam praktiknya apa yang dapat Anda lakukan adalah menambahkan pustaka ini ke proyek Java, dan kemudian menulis semua kode Anda menggunakan bahasa ekspresi Spring EL yang secara efektif membuat kode Anda tidak menyerupai Java sama sekali, dan bahkan pergeseran paradigma (misalnya Anda tidak lagi memiliki penegakan tipe yang kuat saat menggunakan ini). Meskipun saya mengerti bahwa JQuery hanyalah sebuah pustaka JS, bagi saya sepertinya dalam praktiknya ia memiliki efek yang sama seperti Spring EL dengan Java, yaitu Anda hanya dapat menggunakan API itu melalui proyek dan menghindari API JavaScript. Dan saya bertanya-tanya apakah itu hal yang baik untuk dilakukan, apa yang mungkin menjadi jebakan dll

(dan ya, setelah membaca jawaban semua orang, saya mengerti bahwa:

Sebuah. pertanyaan saya agak tidak masuk akal sampai titik tertentu

b. bahkan jika pertanyaannya benar-benar akurat, jawabannya akan cukup banyak "tidak, Anda tidak bisa hanya menggunakan JQuery-only sepanjang waktu)


25
Tidak benar mengatakan "hanya gunakan JQuery" _ JQuery adalah perpustakaan JavaScript.
superM

4
Tidak untuk atau sementara loop, tidak ada variabel, tidak ada fungsi? Semua itu JavaScript.
superM

2
Dengan 'JavaScript lama biasa' yang Anda maksud adalah JavaScript DOM API. Anda mungkin ingin memeriksanya dan mengedit pertanyaan untuk menghindari kebingungan.
scrwtp

4
Apakah kompatibilitas lintas browser tidak cukup alasan?
Simon Whitehead

10
"Ini (jquery) tampaknya dirancang untuk dapat menggunakannya secara eksklusif dan tidak perlu menyentuh Javascript secara langsung". Secara faktual itu hanya salah. jQuery hanyalah kumpulan fungsi JavaScript (walaupun dengan nama aneh seperti "$"). Salah satu bagian penting dari memahami jQuery adalah realisasi ini. Ini hanya fungsi ekstra yang menangani manipulasi dan perulangan DOM.
Graham

Jawaban:


113

Pertama - tidak mungkin menggunakan jQuery saja, yang dilakukan jQuery adalah menambahkan $ object ke lingkup global Anda, dengan banyak metode di dalamnya. Pustaka yang lebih manipulatif seperti prototipe bukan alternatif untuk javascript, mereka adalah toolbelt untuk memecahkan masalah umum.

Keuntungan utama menambahkan jQuery ke toolbelt Anda adalah:

  • kompatibilitas browser - melakukan sesuatu seperti .attr () jauh lebih mudah daripada alternatif asli, dan tidak akan menembus browser.
  • penyederhanaan operasi yang biasanya rumit - jika Anda ingin melihat versi yang kompatibel dengan cross browser yang ditulis dengan baik dari metode XHR, lihat sumbernya seharga $ .ajax - untuk metode ini saja hampir sepadan dengan jQ.
  • Pilihan DOM - hal-hal sederhana seperti acara mengikat & memilih elemen DOM bisa rumit dan berbeda per-browser. Tanpa banyak pengetahuan, mereka juga dapat dengan mudah ditulis dengan buruk dan memperlambat halaman Anda.
  • Akses ke fitur masa depan - hal-hal seperti .indexOf dan .bind adalah javascript asli, tetapi belum didukung oleh banyak browser. Namun, menggunakan versi jQuery dari metode ini akan memungkinkan Anda untuk mendukungnya lintas browser.

Javascript tidak lagi hanya bahasa sisi klien, dan karena jQuery sangat bergantung pada DOM, itu adalah kandidat yang mengerikan untuk pindah ke server. Saya sangat merekomendasikan meluangkan waktu untuk memahami mengapa Anda menggunakan jQuery (mengajukan pertanyaan ini adalah langkah pertama yang bagus!), Dan mengevaluasi kapan diperlukan. jQuery bisa berbahaya, beberapa bahaya utama adalah:

  • kualitas kode - jQuery memiliki komunitas besar dan kurva belajar yang rendah. Ini adalah badai yang sempurna untuk banyak plugin open source yang ditulis dengan buruk.
  • inefisiensi - jQuery mudah ditulis secara tidak efisien. Misalnya, menggunakan jQuery's masing-masing alih-alih untuk loop tidak perlu dan dapat memiliki dampak kinerja dalam beberapa kasus. Banyak info bagus tentang hal ini di JSPerf
  • bloat - jQuery adalah perpustakaan besar. Sebagian besar waktu, Anda akan menggunakan sebagian kecil dari fitur itu, dan ambil seluruh perpustakaan. Ada beberapa alternatif hebat yang akan memberi Anda himpunan bagian dari fitur, seperti zepto.js, dan underscore.js - tergantung pada situasi Anda, Anda dapat menghemat beberapa byte dengan memilih perpustakaan yang tepat untuk kebutuhan Anda.

Pada akhirnya, jQuery adalah pustaka yang sangat berguna dan bermanfaat, bila digunakan dengan benar. Namun, ini bukan alternatif untuk javascript. Ini adalah perpustakaan, seperti zepto.js , YUI , Dojo , MooTools , dan Prototype - salah satunya mungkin merupakan pilihan yang jauh lebih baik untuk proyek Anda saat ini.

Javascript adalah bahasa yang disalahpahami, dan baru-baru ini dianggap sebagai sesuatu yang lebih dari bahasa scripting oleh kebanyakan orang. Saya sangat merekomendasikan untuk membaca lebih lanjut, inilah beberapa tempat yang bagus untuk memulai:

Sunting 07/2014 - Saya perhatikan posting ini masih mendapatkan perhatian, jadi saya menambahkan banyak tautan. Ini tidak ada urutan tertentu, tetapi harus membantu.

  • Blog Ben Alman - banyak praktik terbaik yang baik di sini. Saya tidak setuju dengan mereka semua, tetapi saya belajar hal-hal baru dari blognya sepanjang waktu.
  • Code Academy - pelatihan javascript dan jQuery dasar. Terkadang kembali ke dasar sangat membantu.
  • Javascript Garden - posting mengenai fitur javascript yang lebih rumit atau disalahpahami. Harap baca ini dari waktu ke waktu, sampai semuanya masuk akal.
  • Bocoup - ini adalah kelas pelatihan. Jika Anda dekat satu, pergi ke sana. Banyak pembicara dan guru JS terbaik mengajar ini.
  • Blog Paul Irish - tidak sepenuhnya JS, tetapi banyak praktik terbaik ditulis di sini. Umpan twitter Him dan Ben keduanya bagus untuk diikuti.
  • Javascript: The Good Parts - sering disebut sebagai 'The Javascript Bible', buku ini oleh Douglas Crockford adalah tempat yang luar biasa untuk mulai memahami javascript.
  • Blog Isaac Schlueter - Isaac adalah pencipta npm, dan bekerja pada inti node. Dia menulis banyak tentang komunitas javascript daripada tentang konvensi kode, tetapi jika Anda benar-benar masuk ke js itu adalah bacaan yang bagus.
  • Douglas Crockford's Javascript - Jika Brendan Eich adalah bapak javascript, Douglas adalah paman vokal javascript. Dia adalah penulis spec JSON, Alkitab javascript, dan banyak posting menakjubkan tentang kebiasaan dan peningkatan meteorik javascript.
  • Blog Brendan Eich - Brendan adalah pencipta javascript - ia menulis tentang segala macam hal konyol di blognya, dan sementara ia memiliki kesalahan sebagai pribadi, posting javascriptnya sangat berharga.
  • James Halliday's (@substack) Blog - Substack adalah pengembang node.js yang paling penting dalam komunitas - dengan sekitar 400 (dan terus bertambah setiap hari) modul npm dan filosofi panduan modul kecil, seperti-unix, semua yang ditulisnya bernilai bacaan.
  • Max Ogden's Blog Max Ogden adalah penulis node.js yang produktif, dan sangat baik dalam menulis posting blog yang mengajarkan Anda sesuatu. Dia juga penulis (dengan orang lain saya percaya) tentang javascript untuk kucing.
  • Javascript untuk Kucing - Ini adalah tutorial singkat yang akan membawa Anda melalui dasar-dasar javascript dari perspektif kucing. Jika Anda seorang pemula, bacalah ini. Sangat menyenangkan, dan mengajarkan dalam satu jam apa yang dibutuhkan banyak buku untuk berkomunikasi dalam satu jam.
  • Blog Nicholas Zakas Nicholas adalah penulis beberapa buku javascript yang fantastis: Pemrograman Berorientasi Objek dalam Javascript , Javascript yang Dapat Dipertahankan , Javascript Profesional untuk Pengembang Web , dan Javascript Kinerja Tinggi . Dia berfokus terutama pada klien, tetapi memiliki banyak praktik terbaik dan kiat kinerja.
  • Guillermo Rauch's Blog - Guillermo adalah node produktif lainnya, yang sebagian besar terkenal dengan Socket.io dan Mongoose. Blog-nya (dan buku barunya, Smashing Node.js , keduanya adalah sumber yang bagus.

Saya yakin ada lebih banyak sumber daya hebat yang tidak saya pikirkan atau tidak saya ketahui, penjawab lain harus merasa bebas untuk menambah daftar itu.


3
Memberi +1 untuk komentar di JS tidak lagi menjadi bahasa sisi klien saja dan bagaimana JQuery cocok dengan semua ini.
Shivan Dragon

1
Perhatikan bahwa semua fungsi adalah objek tetapi sangat dekat dengan semua yang ada di JavaScript. $ lebih baik dideskripsikan sebagai fungsi dengan properti "level-level" yang disematkan padanya misalnya ( $.ajax) yang memuntahkan objek pembungkus set elemen dom yang dimaksudkan untuk membuat metode DOM secara umum jauh lebih sedikit dari PITA dengan membuatnya lebih ringkas, memiliki metode auto-loop atas set objek dom setiap kali masuk akal untuk, dan berbagi API yang umum dan dapat diprediksi di seluruh browser (yang kurang dari masalah yaitu IE <= 8).
Erik Reppen

1
Ini adalah posting yang bagus, tetapi saya ingin membahas satu hal - "Perpustakaan besar ... gunakan Zepto / Garis Bawah" - Pertama, Underscore adalah jenis perpustakaan yang sama sekali berbeda - terutama untuk berurusan dengan array / objek - plus menggunakan LoDash sebaliknya, lebih cepat. Kedua, Zepto lebih kecil KARENA itu tidak mencakup hal-hal yang dilakukan jQuery. Itu bisa mengarah ke bug yang akan diperbaiki jQuery. Terakhir, jQuery TIDAK terlalu besar / monolitik, ini sekitar 30Kb setelah di-gzip, dan Anda dapat menyimpannya dengan menggunakan 1 gambar lebih sedikit. Bagi saya, efisiensi dev yang didapat bernilai byte tersebut.
LocalPCGuy

1
@LocalPCGuy pasti beberapa poin bagus. Posting ini (tepatnya!) 2 tahun yang lalu, dan banyak hal telah berubah dalam ekosistem js sejak itu. Sebagai contoh, saya pribadi menggunakan browserify dan modul-modul kecil sebagai ganti perpustakaan yang ditempatkan secara global sama sekali. Namun, saya pikir premis dasar masih benar, yaitu bahwa untuk banyak (kebanyakan?) Kasus, perpustakaan wastafel dapur jarang diperlukan. Saya akan menempatkannya pada sebagian besar pengembang untuk memastikan mereka membenarkan biaya ukuran perpustakaan sebelum memutuskan untuk menggunakannya hanya karena itu lebih mudah daripada menjadi spesifik tentang apa yang Anda butuhkan.
Jesse

1
Bereaksi semua hal, apakah saya benar!?!?! / sarkasme - bagaimana kalau memilih alat yang tepat untuk pekerjaan @Andy, dan itu tidak selalu Bereaksi. Saya pikir React melakukan beberapa hal yang baik, tetapi jangan berpura-pura itu adalah obat semua untuk dunia JavaScript.
LocalPCGuy

17

Ada beberapa keuntungan, tetapi masih bisa diperdebatkan apakah mereka benar-benar lebih besar daripada kekurangannya.

Yang utama adalah Anda menghemat bandwidth dan mendapatkan respons yang lebih cepat. jQuery menambahkan ~ 30kb ke respons Anda. Pada beberapa jaringan (dan di beberapa negara), itu bisa berarti beberapa milidetik lagi. Di sisi lain, Anda dapat mengatur caching untuk itu dengan lebih mudah menggunakan server web Anda (atau seperti kata Xion, gunakan itu dari situs Google sehingga tidak akan berdampak pada Anda sendiri, dan masih di-cache).

Yang kedua adalah bahwa Anda mungkin hanya membutuhkan beberapa fungsionalitas yang sangat sederhana, dan hanya mengunduh dan mengatur jQuery dapat membutuhkan waktu lebih lama daripada hanya mengimplementasikan apa yang Anda butuhkan.

Dan terakhir, Anda mungkin ingin menggulung kerangka kerja Anda sendiri, yang sebagian besar merupakan ide yang buruk, tetapi beberapa orang punya alasan sendiri.

Namun jika Anda membuang jQuery hanya karena Anda terintimidasi oleh kurva belajar, maka Anda harus mempertimbangkan kembali. Terutama karena itu agak lembut.


Setuju, terutama tentang bagian bandwidth. JQuery 1.8.2 memiliki 92Kb dalam versi diminimalkan / dikaburkan. Setuju juga bahwa ini adalah alasan yang tidak terlalu kuat untuk tidak menggunakan JQuery. Terima kasih!
Shivan Dragon

1
@ ShivanDragon: Anda lupa gzip. Itu membuatnya jauh lebih kecil.
ThiefMaster

@ThiefMaster: itu benar, terima kasih sudah menunjukkannya.
Shivan Dragon

10
Jika Anda menggunakan jQuery dari CDNs (seperti Google), kemungkinan besar pengguna akan menggunakannya untuk mengunjungi situs lain. Karenanya dampak pada waktu respons rata-rata Anda (meskipun tidak maksimal) akan lebih kecil.
Xion

1
@Phil Mengapa Anda bahkan menggunakannya sama sekali?!?! jQuery tidak pernah dan tidak akan pernah dibutuhkan. Itu adalah kejahatan setan murni (bersama dengan anggota geng iblis lainnya: ReactJS, Underscore, LoDash, Modernizr, CommonJS, Angular, Google Analytics, terutama AMD, dll.). Secara pribadi, saya tidak pernah memasukkan seluruh perpustakaan (walaupun saya jarang mengekstrak dan mengoptimalkan fungsi spesifik yang saya butuhkan dari perpustakaan), saya tidak akan pernah memasukkan seluruh perpustakaan, dan hampir setiap halaman web yang saya buat memuat banyak pada dial up internet dalam waktu kurang dari 11 frame (1/59 detik).
Jack Giffin

14

Sejauh yang saya tahu benar-benar hanya ada dua keuntungan menggunakan vanilla javascript dibandingkan perpustakaan seperti JQuery , MooTools , dll.

  • Perpustakaan memiliki muatan yang memakan bandwidth. Tetapi seperti yang sudah ditunjukkan orang di jawaban lain, Anda dapat membatasi ini dengan gzipping dan caching. Jika Anda hanya menginginkan subset dari jQuery yang dapat Anda lakukan dengan SizzleJS dan dengan Mootools Anda memiliki pilihan untuk memilih set fitur yang Anda inginkan dengan cara yang sama seperti apa yang dilakukan Modernizr .
  • Perpustakaan itu besar dan membutuhkan waktu untuk belajar. Kemudian lagi, ini adalah investasi satu kali untuk pengembang ... dan terlihat bagus di resume Anda untuk mengetahui perpustakaan javascript.
  • (BONUS) Perpustakaan bukan peluru perak jadi jika Anda ingin menemukan kembali roda maka ini pasti cara untuk pergi.

Perlu menunjukkan mengapa Anda ingin menggunakan perpustakaan javascript, yang ada banyak:

  • Anda tidak perlu menulis kerangka kerja Anda sendiri untuk mendukung pengembangan Anda. Jika Anda penasaran bagaimana cara kerjanya Anda dapat memeriksa kode karena ini adalah open source.
  • Perpustakaan memecahkan kompatibilitas browser. Baik DOM dan javascript memiliki beberapa perbedaan antara browser. Percayalah, ini waktu yang sangat lama jika Anda harus memperbaiki sendiri.
  • Ini adalah standar internet de facto untuk menggunakan perpustakaan javascript, kebanyakan dari mereka sudah didokumentasikan dengan baik sekarang dan sebagian besar pengembang web (yang tahu javascript) tahu cara menggunakannya.
  • Anda tidak benar-benar menyerah javascript saat menggunakan perpustakaan. Anda masih perlu tahu Javascript dengan jenis, objek, cara penutupannya , dll.
  • Kebanyakan perpustakaan termodulasi dan tidak membutuhkan waktu yang lama untuk menulis plugin atau menggunakan membutuhkan dan pola AMD .
  • Elemen pemilihan CSS dari DOM sangat membantu.
  • (BONUS) Anda dapat menggunakannya dengan CoffeeScript juga.

Saya dulu bekerja di toko web yang bersikeras menggunakan vanilla javascript karena jQuery besar dan menakutkan. Keputusan ini, sebagian besar dipengaruhi oleh "pengembang javascript" tunggal, adalah sumber dari banyak bug browser dan perkembangan lambat dan mencoba masuk ke basis kode-nya adalah pengalaman yang menarik. Menulis kerangka kerja Anda sendiri mungkin tampak seperti ide yang bagus, tetapi jika Anda ingin merekrut pengembang baru maka mereka tidak dapat dengan cepat masuk dan membantu. Lalu ada juga masalah faktor bus untuk dipertimbangkan.

Seperti yang saya katakan dulu bekerja di sana ... ada padang rumput yang lebih hijau di tempat lain. : ^)


10

Kebetulan saya mencampur keduanya cukup sedikit. Alasan terbesar untuk ini adalah bahwa untuk beberapa aplikasi (pikirkan ekstensi chrome) Anda tidak memerlukan dukungan lintas browser. Yang berarti bahwa saya dapat mengambil keuntungan dari kemajuan baru seperti CSS3 yang dengan hal-hal seperti transisi dapat menyederhanakan kode Anda satu ton dibandingkan penggunaan jquery.

Juga saya sering melakukan sesuatu kebiasaan. Dengan segala cara, seperti yang lain mengatakan Anda tidak harus menciptakan kembali roda. Tetapi ketika Anda diminta untuk melakukan beberapa fungsi gila, saya sering menemukan lebih mudah untuk menulisnya sendiri kemudian mencoba dan meretas beberapa plugin jquery yang dekat tetapi bukan pasangan yang sempurna.

Saya juga pernah bekerja dengan pengembang yang hanya bekerja dengan jquery. Dan saya harus mengatakan bahwa mereka berkompromi pada fungsionalitas jauh lebih sering daripada tidak jika mereka tidak dapat menemukan plugin jquery yang melakukan apa yang mereka inginkan.

Pada titik tertentu dalam pengembangan web Anda akan diminta untuk melakukan sesuatu yang tidak dipaket sebelumnya di perpustakaan. Jadi pada titik itu Anda lebih baik memastikan Anda memahami bagaimana bahasa dasar benar-benar berfungsi.

Jadi TLDC : Gunakan keduanya, Anda berada pada posisi yang kurang menguntungkan dengan menggunakan vanilla saja dan Anda berada pada posisi yang kurang menguntungkan jika Anda tidak tahu vanila di dalam dan luar dan bersikeras untuk selalu menggunakan jquery.


3
vanilla js murni adalah cara untuk pergi!
marko

Ryan sedikit tahu bahwa jQuery diam-diam menyalahgunakan di document.querySelectorAllbelakang layar.
Jack Giffin

6

Satu-satunya hal yang dapat saya pikirkan bahwa Anda tidak dapat melakukannya tanpa JQuery adalah menggunakan plugin JQuery; bahkan kemudian, Anda dapat menulis perpustakaan JS Anda sendiri yang akan menyediakan apa yang dibutuhkan oleh plugin.

Pikirkan seperti ini: JQuery adalah pustaka Javascript open-source yang ditulis dalam Javascript; Anda dapat melihat sumbernya, dan dengan demikian belajar bagaimana melakukan apa pun yang dilakukannya.

Anda tidak dapat menggunakan JQuery tanpa menggunakan Javascript biasa. Anda mungkin tidak akan menggunakan document.getElementById, tetapi Anda masih akan mendefinisikan fungsi dan variabel dengan cara Javascript standar; Anda bahkan mungkin menulis forloop standar .

Manfaat utama menggunakan JQuery hampir sama dengan pustaka pihak ke-3 lainnya dalam bahasa apa pun: Anda tidak perlu menulis kode sebanyak mungkin untuk mengimplementasikan logika yang spesifik untuk aplikasi Anda.

Jangan biarkan ukuran itu membuat Anda takut. Versi CDN adalah unduhan ~ 33k yang akan di-cache oleh browser pengguna setelah klik halaman pertama.


6

Jika Anda khawatir tentang kinerja, Anda harus mencoba menggunakan vanilla js kapan pun memungkinkan. kerangka kerja tidak hanya menambah overhead bandwidth tetapi juga memproses overhead. Dan jQuery hadir dengan kompatibilitas browser untuk browser yang cukup lama juga.

jika Anda bekerja pada aplikasi atau game seluler (atau keduanya digabungkan), Anda memerlukan kinerja dan efisiensi sumber daya terlebih dahulu.

jQuery dan plugins mungkin mempercepat pengembangan Anda, tetapi terutama jika Anda mengandalkan plugin jquery pihak ketiga Anda harus tahu apa yang mereka lakukan di dalam. Banyak dari mereka adalah contoh buruk dari kualitas dan efisiensi kode.

jQuery bisa 2 hingga 10 kali lebih lambat dari JavaScript asli. Dan itu dapat dengan mudah mendorong pengembang untuk tidak mendesain antarmuka mereka dengan benar dan terlalu bergantung pada pemilih jQuery yang jauh lebih lambat daripada yang asli.


+1, saya setuju dengan Anda membuat game adalah alasan yang bagus untuk meninggalkan JQuery demi vanilla JS, karena alasan kinerja. Ini cukup benar untuk sebagian besar bahasa ketika membuat game dengan mereka. Sebagai contoh, orang-orang Google merekomendasikan dalam dokumen Android mereka tidak hanya untuk membuang perpustakaan ketika membuat game (di Jawa, untuk Android) tetapi untuk selanjutnya membuang beberapa praktik pengkodean yang baik demi kecepatan.
Shivan Dragon

... jika Anda tahu banyak tentang manipulasi DOM efisien seperti orang-orang yang menulis jQuery, ya.
Erik Reppen

@ErikReppen tolong selidiki kode sumber asli dari "orang yang menulis jQuery." Aku buta selama hampir sebulan karena kengerian yang kulihat hanya dalam 23 baris pertama.
Jack Giffin

Banyak yang berubah di JQ sejak 2013.
Erik Reppen
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.