Kerangka Kerja Front-end: Solusi atau Masalah Kembung?

Kerangka kerja front-end modern mengharuskan Anda mengunduh lingkungan pengembangan, lengkap dengan dependensi, dan mengompilasi kode Anda bahkan sebelum mencoba melihatnya di browser Anda. Apakah ini hal yang baik? Apakah masalahnya adalah bahwa kami sedang membangun situs yang lebih kompleks, atau apakah kerangka kerja itu sendiri kompleks, memperkenalkan tingkat kerumitan yang tidak perlu?

Pengembangan web saat ini telah banyak berkembang sejak tahun 90-an; kami dapat menciptakan seluruh pengalaman yang sangat mirip dengan apa yang dapat dilakukan oleh aplikasi asli mana pun, dan proses pengembangan juga telah berubah. Lewatlah sudah hari-hari ketika menjadi pengembang web front-end adalah masalah membuka Notepad, mengetik beberapa baris kode, memeriksanya di browser, dan mengunggahnya ke folder FTP.

Pengembangan Web Front-end di Masa Lalu

Saya harus mulai dengan menyatakan yang sudah jelas: Dunia tidak seperti 10 tahun yang lalu. (Mengejutkan, saya tahu.) Satu-satunya hal yang tetap konstan adalah perubahan. Kembali pada hari itu, kami memiliki sangat sedikit browser, tetapi ada banyak masalah kompatibilitas. Saat ini, Anda tidak melihat hal-hal seperti "terbaik dilihat di Chrome 43.4.1", tetapi saat itu, itu cukup umum. Kami memiliki lebih banyak browser sekarang, tetapi lebih sedikit masalah kompatibilitas. Mengapa? Karena jQuery . jQuery memenuhi kebutuhan untuk memiliki standar, perpustakaan umum yang memungkinkan Anda untuk menulis kode JavaScript yang memanipulasi DOM tanpa perlu khawatir tentang bagaimana itu akan berjalan di setiap browser dan di setiap versi setiap browser—sebuah mimpi buruk yang nyata di tahun 2000-an .

Peramban modern dapat memanipulasi DOM sebagai standar, sehingga kebutuhan akan pustaka semacam itu telah sangat berkurang dalam beberapa tahun terakhir. jQuery tidak diperlukan lagi, tetapi kami masih dapat menemukan sejumlah plugin yang sangat berguna yang bergantung padanya. Dengan kata lain, kerangka kerja web mungkin tidak diperlukan, tetapi masih cukup berguna untuk populer dan digunakan secara luas. Ini adalah sifat yang umum untuk sebagian besar kerangka kerja web populer di luar sana, mulai dari React, Angular, Vue, dan Ember hingga model gaya dan pemformatan seperti Bootstrap.

Mengapa Orang Menggunakan Kerangka

Dalam pengembangan web seperti dalam kehidupan, memiliki solusi cepat selalu berguna. Pernahkah Anda melakukan router sebelumnya di JavaScript? Mengapa harus melalui proses pembelajaran yang menyakitkan ketika Anda dapat menginstal npm framework front-end untuk mengatasi masalah tersebut? Waktu adalah kemewahan ketika klien menginginkan sesuatu dilakukan kemarin atau Anda mewarisi kode dari pengembang lain yang dirancang untuk kerangka kerja tertentu, atau jika Anda berintegrasi dengan tim yang sudah menggunakan kerangka kerja tertentu. Mari kita hadapi itu—kerangka kerja memang ada karena suatu alasan. Jika tidak ada manfaat bagi mereka, tidak ada yang akan menggunakannya.

Jadi apa saja manfaat dan sifat unik menggunakan kerangka kerja pengembangan web?

Waktu adalah uang. Saat Anda mengembangkan proyek dan klien tidak peduli kerangka kerja mana yang Anda gunakan—bahkan, mungkin tidak menyadari apa yang Anda gunakan—mereka hanya peduli untuk mendapatkan hasil, dan semakin cepat semakin baik. Kerangka kerja yang mapan memungkinkan Anda menciptakan rasa kemajuan instan dari awal, yang didambakan klien sejak hari 1. Selain itu, semakin cepat Anda berkembang, semakin banyak uang yang Anda hasilkan, karena waktu yang dibebaskan oleh kerangka kerja dapat dialihkan untuk mengambil lebih banyak proyek.

Ini semua tentang komunitas. Saat memilih kerangka kerja, ini adalah poin yang sangat penting—siapa yang akan membantu Anda saat Anda terjebak dalam suatu masalah? Anda dan saya sama-sama tahu bahwa itu akan terjadi di beberapa titik. Anda akan mencapai titik di mana Anda perlu melakukan sesuatu yang tidak dimaksudkan untuk dilakukan oleh kerangka kerja, atau bahwa kerangka kerja tidak pernah dirancang untuk memberi Anda akses, jadi memiliki komunitas yang mendukung Anda sangat penting. Pengembangan—terutama pekerja lepas—bisa jadi sulit, karena Anda tenggelam dalam dunia virtual, dan jika Anda adalah satu-satunya pengembang web front-end dalam sebuah tim, itu berarti Andalah satu-satunya yang memiliki pengalaman dan keahlian untuk menemukan larutan. Tetapi jika kerangka kerja front-end yang Anda gunakan memiliki dukungan yang kuat, akan ada seseorang di belahan dunia lain yang menghadapi masalah yang sama dan mungkin dapat membantu Anda.

Standar itu indah. Pernahkah Anda memperhatikan bahwa, ketika Anda melihat bagian lama dari kode Anda sendiri, Anda dapat menavigasinya dengan cukup mudah? Atau setidaknya, lebih mudah daripada sepotong kode yang ditulis oleh orang lain? Anda berpikir dengan cara tertentu, dan Anda memiliki cara Anda sendiri untuk menamai sesuatu dan mengatur kodenya. Itu standar. Kita semua mengikuti mereka, bahkan jika itu hanya untuk diri kita sendiri. Kita cenderung makan hal yang sama untuk sarapan, bangun pada jam tertentu, dan meletakkan kunci kita di tempat yang sama setiap hari. Dan memang, jika kita mengubah rutinitas kita setiap hari, hidup akan jauh lebih sulit hanya dengan memikirkan bagaimana melakukan sesuatu. Pernah kehilangan kunci Anda karena Anda meletakkannya di tempat yang berbeda dari biasanya? Standar membuat hidup lebih mudah. Saat bekerja sebagai bagian dari tim atau komunitas pengembang, mereka menjadi sangat diperlukan.

Kerangka kerja memberikan standar sejak Anda menginstalnya, membimbing Anda untuk berpikir dan membuat kode dengan cara tertentu. Anda tidak perlu menghabiskan waktu membuat standar dengan tim Anda; Anda bisa mengikuti bagaimana hal-hal dilakukan dalam kerangka kerja. Ini membuatnya lebih mudah untuk bekerja sama. Lebih mudah untuk mencari suatu fungsi ketika Anda tahu bahwa fungsi tersebut harus berada dalam file tertentu karena dibuat untuk menambahkan rute di SPA, dan dalam kerangka kerja Anda, semua rute ditempatkan dalam file dengan nama itu. Orang-orang dengan tingkat keahlian yang berbeda dapat bekerja sama jika Anda memiliki tingkat standarisasi ini, karena meskipun pembuat kode tingkat lanjut tahu mengapa hal-hal dilakukan dengan cara itu, bahkan pengembang junior pun dapat mengikuti standar itu sendiri.

Ketika Kerangka Gagal

Beberapa tahun yang lalu, mengatakan sesuatu seperti "Saya tidak menggunakan kerangka kerja—saya tidak melihat manfaat nyata darinya" akan membawa orang-orang dengan obor dan garpu rumput ke pintu Anda. Tetapi hari ini, semakin banyak orang bertanya pada diri sendiri, “Mengapa saya harus menggunakan kerangka kerja sama sekali? Apakah saya benar-benar membutuhkan mereka? Apakah sulit untuk membuat kode tanpa mereka? ”

Saya tentu saja salah satunya—saya tidak pernah menjadi penggemar kerangka kerja tertentu, dan saya telah membuat kode tanpa mereka sepanjang karier saya. Jika saya memiliki pilihan dalam hal ini, pilihan saya selalu, "Tidak, terima kasih." Saya telah mengembangkan JavaScript selama bertahun-tahun dan di ActionScript sebelumnya. Saya sedang mengkode di Flash ketika kebanyakan orang sudah menganggapnya mati. (Saya tahu, saya tahu... tapi saya melakukan banyak animasi, dan animasi dalam HTML biasa itu sulit.) Jadi, jika Anda salah satu dari banyak orang yang tidak pernah berpikir tentang pengkodean tanpa kerangka kerja, izinkan saya menunjukkan beberapa alasan mengapa Anda mungkin berjuang.

"Satu ukuran cocok untuk semua" adalah bohong. Bisakah Anda bayangkan menulis satu perangkat lunak yang dapat melakukan semua yang telah Anda capai dalam karir Anda? Itulah salah satu masalah utama dengan kerangka kerja pengembangan web. Proyek Anda memiliki kebutuhan yang sangat spesifik, yang cenderung kami selesaikan dengan menambahkan pustaka, plugin, atau add-on untuk memperluas cakupan kerangka kerja. Tidak ada kerangka kerja yang menawarkan 100% dari apa yang Anda butuhkan, dan tidak ada kerangka kerja yang 100% terdiri dari hal-hal yang menurut Anda berguna.

Memiliki terlalu banyak kode yang tidak Anda gunakan dapat mengakibatkan jeda waktu muat untuk situs Anda, yang menjadi lebih penting dengan setiap pengguna tambahan. Masalah lainnya adalah bahwa pola pikir “satu ukuran cocok untuk semua” menghasilkan kode yang tidak efisien. Ambil, misalnya, $('sku-product').html('SKU 909090'); , yang merupakan kode jQuery yang, pada akhirnya, kita semua tahu akan diterjemahkan ke dalam sesuatu seperti document.getElementById('sku-product').innerHTML = 'SKU 909090'; .

Perbedaan semacam itu pada satu baris mungkin tampak tidak penting, tetapi mengubah konten elemen tertentu dari halaman justru merupakan keunggulan React. Sekarang, React menjalani proses pembuatan representasi DOM dan menganalisis perbedaan dalam apa yang Anda coba render. Bukankah lebih mudah untuk menargetkan konten yang ingin Anda ubah dari awal?

Jalinan rerumputan yang Anda lewati adalah duri yang tumbuh. Pernahkah Anda berada dalam situasi di mana Anda menggunakan kerangka kerja Anda dan mencoba menambahkan pustaka ke dalamnya, hanya untuk menyadari bahwa versi pustaka yang Anda butuhkan tidak bekerja dengan baik dengan versi kerangka kerja yang Anda gunakan? Terkadang dibutuhkan lebih banyak upaya untuk membuat dua bagian kode bekerja bersama daripada hanya menulis kode sendiri. Dan karena kerangka kerja dan pustaka yang Anda gunakan sering kali dibangun di atas kerangka kerja dan pustaka lain yang mungkin memiliki inkompatibilitas tersembunyi yang bahkan tidak dapat Anda antisipasi, masalahnya bisa menjadi lebih kompleks secara eksponensial, mencapai titik di mana tidak mungkin untuk dikelola jika Anda ingin proyek terus berkembang.

Bersaing dengan keluarga Jones adalah suatu hal. Pernah mengerjakan proyek di AngularJS hanya untuk mengetahui bahwa Anda memerlukan sesuatu yang tidak muncul hingga Angular 4 dirilis? Tahukah Anda bahwa Angular 5 telah dirilis? Ini adalah masalah besar lainnya; bahkan jika Anda tetap berpegang pada kerangka kerja front-end tunggal, ketika rilis besar baru terjadi, banyak hal dapat berubah sehingga kode yang Anda buat dengan susah payah bahkan tidak akan berjalan pada versi baru. Ini dapat mengakibatkan apa saja, mulai dari perubahan kecil yang mengganggu yang perlu dilakukan pada banyak file hingga penulisan ulang kode Anda secara lengkap.

Mengikuti perkembangan kerangka kerja terbaru itu menantang, tetapi pada catatan yang sama, kerangka kerja lain menderita ketika pembaruan berhenti sepenuhnya dan mereka tidak dapat mengikuti teknologi lainnya. Pada tahun 2010, baik AngularJS dan Backbone dirilis untuk pertama kalinya. Hari ini, Angular berada di versi utama kelimanya, dan Backbone benar-benar keluar dari sorotan. Tujuh tahun sepertinya waktu yang lama. Jika Anda membangun situs web, mereka mungkin telah berubah total dalam estetika dan fungsi. Jika Anda sedang membangun sebuah aplikasi, bertaruh pada kerangka kerja yang salah dapat menempatkan perusahaan dalam situasi yang sulit—dan mahal—di kemudian hari, ketika segala sesuatunya perlu ditulis ulang.

Ketika semua yang Anda miliki adalah palu, semuanya tampak seperti paku. Jika Anda sering menggunakan kerangka kerja pengembangan web, ini mungkin terjadi pada Anda, di mana basis kode tunggal mendefinisikan bentuk kode yang Anda gunakan di masa mendatang, meskipun itu hanya terkait periferal. Katakanlah Anda akan membangun platform seperti YouTube dan Anda ingin menggunakan Framework X. Mungkin ada titik di mana, meskipun kedengarannya konyol di zaman sekarang ini, Anda memutuskan untuk menggunakan Flash untuk video karena itulah yang datang dibangun dengan kerangka.

Kerangka memiliki pendapat, dan mereka kuat; React, misalnya, memaksa Anda untuk menggunakan BEJ dengan cara tertentu. Anda dapat melihat kode yang digunakan dengan cara itu di mana-mana. Apakah ada alternatif? Ya. Tapi siapa yang menggunakannya? Ini tidak selalu merupakan hal yang buruk, tetapi jika Anda perlu melakukan animasi yang kompleks, Anda mungkin hanya memerlukan kerangka kerja untuk menganimasikan dan bukan keseluruhan React. Saya telah melihat orang melakukan hal-hal gila seperti menambahkan jQuery ke halaman hanya untuk menambahkan simpul ke elemen, sesuatu yang dapat dicapai di Vanilla JS dengan document.getElementById('id_of_node').appendChild(node); .

Eval Itu Jahat, tapi .innerHTML Adalah Machiavellian

Saya ingin meluangkan waktu untuk menjelajahi poin ini secara terpisah karena saya pikir ini adalah salah satu alasan mengapa lebih banyak orang tidak membuat kode tanpa kerangka kerja. Saat Anda melihat cara kerja sebagian besar kode saat mencoba menambahkan sesuatu ke DOM, Anda akan menemukan sekumpulan HTML yang disuntikkan oleh properti .innerHTML . Kita semua tampaknya setuju bahwa eval buruk untuk menjalankan kode JavaScript, tetapi saya ingin menempatkan .innerHTML dalam sorotan di sini. Saat Anda menyuntikkan kode HTML sebagai string biasa, Anda kehilangan referensi yang mungkin Anda miliki ke salah satu node yang Anda buat. Memang benar bahwa Anda mungkin mendapatkannya kembali dengan menggunakan getElementsByClassName atau memberi mereka id , tetapi ini kurang praktis. Saat mencoba mengubah nilai salah satu node, Anda akan mendapati diri Anda merender seluruh HTML kembali.

Ini bagus ketika Anda mulai membuat kode. Anda dapat membuat banyak hal sederhana dengan mudah tanpa banyak pengalaman. Masalah terjadi dengan kompleksitas situs web modern, yang cenderung lebih mirip aplikasi—ini berarti bahwa kita perlu terus-menerus mengubah nilai node kita, yang merupakan operasi berbiaya tinggi jika Anda melakukannya dengan memasang kembali seluruh struktur melalui .innerHTML . React memecahkan masalah ini secara efisien melalui shadow DOM, dan Angular mengatasinya dengan menggunakan binding sebagai cara mudah untuk mengubah nilai yang ditampilkan pada halaman. Namun, itu juga dapat diselesaikan dengan cukup mudah dengan melacak node yang Anda buat dan menyimpan node yang akan digunakan kembali atau diperbarui dalam variabel. Ada juga alasan lain untuk menjauh dari .innerHTML secara umum.

Mitos Terbesar tentang Coding Tanpa Kerangka

Waktu adalah uang. Yap, saya membawa konsep ini kembali dari sebelumnya. Banyak orang merasa jika mereka berhenti menggunakan kerangka kerja web yang populer, kita akan langsung beralih ke internet tahun 90-an, ketika <marquee> adalah tag favorit semua orang, memutar GIF di situs Geocities sedang trendi dan edgy, Alta Vista adalah pilihannya. untuk pencarian web, dan hit counter ada di mana-mana.

Dengan kerangka kerja web, baris kode pertama Anda tampaknya membuat banyak kemajuan yang menghemat waktu, tetapi pada titik tertentu, keuntungan berubah menjadi kerugian. Anda menghabiskan waktu Anda membaca tentang bagaimana membuat kerangka kerja melakukan hal-hal yang tidak dibuat untuknya, bagaimana mengintegrasikan perpustakaan dan membuatnya bermain bagus dengan kerangka kerja, dan mengetahui bahwa kode yang Anda buat saat mengikuti standar kerangka kerja tidak berjalan dengan baik. untuk bekerja sama sekali dan sekarang Anda perlu menulis ulang. Ketika Anda melakukan sesuatu tanpa kerangka kerja, Anda mulai lebih lambat, tetapi Anda membuat kemajuan yang stabil. Pada akhirnya, ini semua tentang di mana Anda menginginkan bagian yang mudah. Itu tidak akan membuat banyak perbedaan dalam total waktu.

Kode saya akan lebih panjang dari Tembok Besar. Menulis tanpa kerangka kerja seperti membeli film alih-alih berlangganan layanan streaming. Anda tidak mendapatkan akses instan ke ratusan film yang ingin Anda tonton, tetapi Anda juga tidak perlu mengeluarkan uang untuk ribuan film lain yang bahkan tidak pernah Anda pertimbangkan untuk diunduh dari toko. Anda hanya dapat menulis apa yang Anda butuhkan.

Apakah perantara itu berguna? Tentu. Tapi itu biasanya tidak perlu . Setiap baris kode yang Anda tulis memiliki lebih banyak makna, karena Anda tidak perlu beradaptasi dengan persyaratan kerangka kerja. Rasanya seperti Anda menulis lebih banyak kode dengan JavaScript murni karena cara membuat elemen DOM membutuhkan garis untuk membuat elemen, melampirkannya ke DOM, dan mungkin menambahkan kelas untuk penataan gaya, bukan memanggil satu baris kode di BEJ. Tetapi jika Anda membandingkan kode menggunakan perpustakaan seperti jQuery atau React, panjang vanilla JS bisa sangat mirip. Kadang lebih panjang, tapi kadang juga lebih pendek.

Tidak perlu menemukan kembali roda. Mantra profesor ilmu komputer di mana-mana. Dan itu benar—itu tidak harus berarti kerangka kerja secara khusus. Mengirim permintaan Ajax untuk memuat atau menyimpan data adalah persyaratan di hampir setiap aplikasi web, misalnya, tetapi tidak memiliki kerangka kerja tidak berarti Anda harus menulis kode baru setiap saat. Anda dapat membuat perpustakaan atau basis kode Anda sendiri, atau Anda dapat mengekstrak kode dari orang lain. Semakin kecil, semakin mudah untuk memodifikasi atau menyesuaikan sesuai kebutuhan, sehingga sangat berguna ketika Anda membutuhkan sesuatu yang spesifik untuk suatu proyek. Lebih mudah untuk memodifikasi 100-200 baris kode daripada menavigasi melalui tumpukan file yang mungkin berisi perpustakaan atau kerangka kerja pihak ketiga.

Ini hanya akan bekerja untuk proyek kecil. Ini adalah mitos yang sangat umum, tetapi tidak benar sama sekali; saat ini, saya sedang mengerjakan seluruh sistem untuk mengelola semua aspek perusahaan secara online di satu tempat, termasuk modul yang mirip dengan Google Drive. Baik dengan kerangka kerja atau tanpa kerangka kerja, saya melalui langkah-langkah yang sangat mirip dan menghadapi masalah yang sangat mirip. Perbedaannya dapat diabaikan. Namun, tanpa kerangka kerja, seluruh kode saya lebih kecil dan lebih mudah dikelola.

SAYA INGIN BUKTI

Baik. Mari kita berhenti berbicara tentang teori dan beralih ke contoh dunia nyata. Beberapa hari yang lalu, saya perlu menunjukkan daftar merek dengan logo untuk sebuah toko. Kode awal menggunakan jQuery, tetapi memiliki masalah ketika memuat di Mozilla, itu menunjukkan ikon gambar rusak untuk merek yang belum diunggah logo. Kami tidak dapat membuat toko terlihat belum selesai hanya karena Perusahaan X belum menyelesaikan pekerjaan mereka, tetapi fitur tersebut perlu ditayangkan.

Kode berikut menggunakan jQuery yang setara dengan .innerHTML :

 var list_brand_names = ['amazon', 'apple', 'nokia']; var img_out = ''; for (i=0;i<list_brand_names.length;i++) { var brandName = list_brand_names[i].toLowerCase(); img_out += "<a href='/pages/" + brandName + "'><img src='images/" + brandName + "' /></a>"; } jQuery("#brand-images").html(img_out);

Tanpa terlalu mendalami pro dan kontra jQuery, masalahnya di sini adalah kita tidak memiliki referensi ke gambar yang kita buat. Meskipun ada solusi yang tidak melibatkan perubahan kode, mari gunakan kesempatan ini untuk melihat bagaimana hal itu dapat dilakukan tanpa pustaka sama sekali:

 var brands = ['amazon', 'apple', 'nokia']; var brand_images = document.getElementById("brand-images"); for (var iBrand = 0; iBrand < brands.length; iBrand++) { var link = document.createElement('a'); link.setAttribute('href', '/pages/' + brands[iBrand]); link.style.display = 'none'; brand_images.appendChild(link); var image = new Image(); image.src = "images/" + brands[iBrand] + "png"; image.onload = function(){ this.parentNode.style.display = ''; } link.appendChild(image); }

Kode jQuery asli panjangnya enam baris, sedangkan solusi vanilla JS membutuhkan dua belas. Untuk mengatasi masalah, menyembunyikan setiap gambar hingga dimuat, membutuhkan waktu dua kali lebih lama untuk dikodekan. Jadi mari kita lihat alternatifnya. Bisakah itu diselesaikan di jQuery juga? Coba lihat:

 img_out += "<a href='/pages/" + brandName + "'><img src='images/" + brandName + "' onload="showImage(this)"/></a>"; function showImage(image){ image.parentNode.style.display = ""; }

Dengan beberapa baris kode tambahan, sekarang hanya ada perbedaan tiga baris antara jQuery dan vanilla, tetapi di jQuery, Anda dapat melihat bahwa baris img_out dengan cepat berkembang sangat kompleks, ke titik di mana Anda perlu menjeda dan pikirkan baik-baik tentang apa yang Anda lakukan. Mengkodekan DOM secara langsung dengan menggunakan fungsi node untuk menambahkan atribut, fungsi, dan sejenisnya mungkin lebih panjang, tetapi setiap baris memiliki makna yang lebih jelas dan tepat, sehingga lebih mudah dibaca dan dipelihara di masa mendatang.

Mari kita lihat Bereaksi:

 function BrandLink(props) { var url = "images/" + props.brand + ".png"; return (<a href="{props.brand}"><img src={url}/></a>); } class Brands extends React.Component { constructor() { super(); this.state = {brands: ['amazon', 'apple', 'nokia']}; } render() { const links = this.state.brands.map((step, move) => { return (<BrandLink brand={step} key={step}/>); }); return (<div className="brands">{links}</div>); } } ReactDOM.render(<Brands />, document.getElementById("root"));

Versi ini jelas kurang optimal. Kodenya tidak lebih pendek dari yang ada di vanilla, dan kami bahkan masih belum sampai pada titik memecahkan masalah dan menyembunyikan tautan sampai gambar di dalamnya dimuat.

Untuk setiap contoh, hasilnya akan berbeda. Terkadang, jQuery akan lebih pendek. Terkadang, React akan menang. Ada kalanya vanilla JS bisa lebih pendek dari keduanya. Bagaimanapun, tujuannya di sini bukan untuk membuktikan bahwa yang satu secara inheren lebih unggul dari yang lain, tetapi untuk menunjukkan bahwa tidak ada perbedaan yang signifikan antara menggunakan Vanilla JS dan menggunakan kerangka kerja dalam hal panjang kode.

Kesimpulan

Seperti hampir semua masalah kehidupan nyata, tidak ada yang hitam atau putih. Pengodean tanpa kerangka kerja pengembangan web mungkin merupakan solusi terbaik untuk beberapa proyek Anda dan mimpi buruk di proyek lainnya. Seperti halnya setiap alat, kuncinya adalah mempelajari bukan hanya bagaimana menggunakannya, tetapi kapan, dan apa keuntungan dan kerugian menggunakannya. Pengkodean dalam JavaScript murni sama seperti kerangka kerja apa pun—menguasainya membutuhkan waktu sebelum Anda merasa nyaman menggunakannya.

Tetapi perbedaan utama, setidaknya bagi saya, adalah bahwa kerangka kerja datang dan pergi, dan bahkan jika kerangka kerja populer untuk waktu yang lama, itu dapat berubah secara dramatis dari satu versi ke versi lain. JavaScript murni akan menjadi pilihan lebih lama, sampai berhenti menjadi relevan sepenuhnya dan beberapa bahasa lain muncul. Meskipun demikian, akan ada lebih banyak konsep dan strategi yang dapat Anda migrasikan secara langsung dari satu bahasa ke bahasa lain daripada yang dapat Anda lakukan dengan kerangka kerja tertentu ke bahasa lain. Waktu dan upaya kira-kira setara dengan satu proyek, pengurangan penyusutan pengetahuan dan pelajaran yang dapat Anda ambil untuk tantangan berikutnya adalah faktor yang sangat penting untuk dipertimbangkan.