Pengembangan JavaScript yang Bertanggung Jawab Bagian 1

Angka-angka memberi tahu kami bahwa pertumbuhan kode JavaScript memiliki efek buruk pada kinerja proyek web. Jika ini terus berlanjut, maka segera, ketika memuat halaman tengah, setidaknya 400 Kb kode JS akan ditransfer. Dan ini hanya jumlah data yang ditransfer. Seperti sumber daya teks lainnya, kode JavaScript hampir selalu ditransmisikan dalam bentuk terkompresi. Kompresi mungkin satu-satunya hal yang biasanya dilakukan dengan benar ketika mentransfer kode dari server ke klien.



Sayangnya, walaupun mengurangi waktu transfer sumber daya tertentu memberikan kontribusi serius pada apa yang kita sebut "kinerja", kompresi tidak memengaruhi berapa banyak waktu yang diperlukan browser untuk mem-parsing dan memproses skrip setelah penuh. .

Jika server mengirim 400 KB kode JS terkompresi ke klien, maka jumlah sebenarnya kode yang perlu diproses browser setelah mendekompresi data yang diterima akan berada di area megabyte. Seberapa baik perangkat yang berbeda menangani jenis pekerjaan ini tergantung pada perangkat itu sendiri. Banyak yang telah ditulis tentang ini, tetapi kita hanya dapat mengatakan dengan pasti bahwa waktu yang diperlukan bahkan untuk mem-parsing jumlah kode yang cukup biasa untuk waktunya sangat bervariasi antara perangkat yang berbeda.

Lihatlah, misalnya, pada proyek sederhana saya ini. Selama pemuatan halaman, sekitar 23 Kb kode JS terkompresi ditransfer ke klien. Chrome, berjalan di MacBook Pro, yang dirilis pada pertengahan 2017, memproses jumlah kode yang agak kecil ini sekitar 25 ms. Namun pada ponsel cerdas Nokia 2 Android, angka yang sama melebar hingga 190 ms. Ini bukan untuk mengatakan bahwa itu sangat kecil, tetapi bagaimanapun, halaman menjadi cukup cepat interaktif.

Sekarang, pertanyaan penting. Bagaimana menurut Anda, bagaimana cara ponsel Nokia 2 sederhana mengelola rata-rata halaman modern? Bahkan - hanya mengerikan. Menjelajahi halaman web, bahkan pada koneksi Internet cepat, memaksa pengguna untuk bersabar, karena bekerja dengan halaman yang dimuat dengan kode JavaScript menjadi mungkin hanya setelah masa tunggu yang lumayan.


Tinjauan umum kinerja Nokia 2 saat melihat halaman yang berisi sejumlah besar kode JS, yang prosesnya memblokir utas utama

Meskipun perangkat yang mereka gunakan untuk menelusuri halaman web dan jaringan di mana data ditransmisikan telah meningkat secara signifikan dalam beberapa tahun terakhir, penelitian menunjukkan bahwa semua perbaikan ini "dimakan" oleh sejumlah besar kode JS yang termasuk dalam halaman. Kita perlu menggunakan JavaScript secara bertanggung jawab. Tanggung jawab dimulai dengan pemahaman tentang apa yang kita ciptakan dan bagaimana kita melakukannya.

Perbandingan ideologi "situs" dan "aplikasi"

Hal-hal aneh terjadi dengan istilah yang tidak akurat yang kita gunakan untuk menyebut sesuatu, meskipun artinya, pada tingkat intuitif, dapat dimengerti oleh semua orang. Kadang-kadang kita membebani arti kata "lebah", menyebutnya "lebah" dan tawon, meskipun perbedaan antara lebah dan tawon sangat signifikan. Mempertimbangkan perbedaan seperti itu dapat mengarah pada fakta bahwa "lebah" dan "tawon" akan bertindak secara berbeda. Sebagai contoh, kita akan menghancurkan sarang lebah, tetapi jika kita berbicara tentang lebah, serangga jauh lebih berguna dan rentan, sarang mereka yang terletak di tempat yang salah mungkin akan diputuskan untuk tidak menghancurkan, tetapi untuk memindahkannya ke suatu tempat.

Kebebasan yang serupa dapat diamati dengan cara kita menggunakan istilah "situs web" dan "aplikasi web". Perbedaan antara konsep-konsep ini jauh lebih jelas daripada perbedaan antara tawon nyata dan lebah madu, tetapi jika konsep ini digabungkan, ini dapat menyebabkan konsekuensi yang sangat tidak menyenangkan. Permasalahan dimulai ketika kita membiarkan diri kita sesuatu, tergantung pada apakah suatu proyek adalah "hanya sebuah situs web" atau "aplikasi web yang lengkap". Jika Anda membuat situs informasi untuk perusahaan, maka kemungkinan besar Anda tidak akan bergantung pada kerangka kerja yang kuat untuk mengelola perubahan DOM atau untuk menerapkan perutean pada klien. Minimal, saya harap begitu. Menggunakan alat yang tidak cocok untuk memecahkan masalah tertentu tidak hanya akan membahayakan mereka yang akan menggunakan situs ini, tetapi juga mungkin akan mempengaruhi proses pengembangan dengan buruk.

Saat mengembangkan aplikasi web, semuanya terlihat berbeda. Kami menginstal paket, yang disertai dengan penambahan ratusan, jika tidak ribuan, ketergantungan pada proyek. Selain itu, kami bahkan tidak yakin dengan keamanan beberapa dari mereka. Kami menulis konfigurasi kompleks untuk bundler. Ketika bekerja di lingkungan pengembangan gila di mana-mana, Anda perlu pengetahuan dan perhatian untuk memastikan bahwa apa yang dikumpulkan cepat, bahwa proyek akan bekerja di tempat yang seharusnya bekerja. Jika ragu, jalankan perintah npm ls --prod di direktori root proyek Anda dan lihat apakah Anda dapat menyebutkan tujuan menggunakan segala yang ditampilkan oleh perintah ini. Bahkan jika Anda bisa melakukannya, ini tidak berlaku untuk skrip pihak ketiga. Saya yakin beberapa skrip seperti itu juga digunakan dalam proyek Anda.

Kami lupa bahwa baik situs web maupun aplikasi web menempati “ceruk ekologis” yang sama. Keduanya berada di bawah pengaruh lingkungan yang sama, yang terdiri dari berbagai jaringan dan perangkat. Pembatasan seperti itu tidak akan hilang jika kita memutuskan untuk menyebut apa yang kita kembangkan sebagai "aplikasi", dan perangkat pengguna kita tidak akan secara ajaib menjadi lebih cepat jika kita menyebut "situs web" sebagai "aplikasi".

Adalah tanggung jawab kita untuk mengetahui siapa yang menggunakan apa yang kita buat, kita harus memperhitungkan fakta bahwa kondisi di mana pengguna yang berbeda terhubung ke Internet mungkin berbeda dari yang kita andalkan. Ketika menciptakan sesuatu, kita harus mengetahui tujuan yang kita ciptakan itu, dan setelah itu kita harus mengembangkan apa yang membantu untuk mencapai tujuan ini - bahkan jika perkembangannya ternyata tidak terlalu menarik .

Ini berarti kebutuhan untuk mengevaluasi kembali ketergantungan kita pada JavaScript, dan bagaimana penggunaannya, khususnya yang merugikan HTML dan CSS, dapat mengarahkan kita pada penggunaan pola irasional yang merusak kinerja dan aksesibilitas proyek web.

Jangan biarkan kerangka kerja memaksakan pola irasional pada Anda

Saya menyaksikan penemuan hal-hal aneh dalam basis kode ketika saya bekerja dengan tim tergantung pada kerangka kerja untuk membantu mereka menjadi lebih produktif. Banyak dari temuan ini memiliki satu kesamaan, yaitu bahwa cara mereka ditulis sering menimbulkan masalah dengan ketersediaan dan kinerja situs. Misalnya, pertimbangkan komponen Bereaksi berikut:

import React, { Component } from "react"; import { validateEmail } from "helpers/validation"; class SignupForm extends Component {  constructor (props) {    this.handleSubmit = this.handleSubmit.bind(this);    this.updateEmail = this.updateEmail.bind(this);    this.state.email = "";  }  updateEmail (event) {    this.setState({      email: event.target.value    });  }  handleSubmit () {    //      -      if (validateEmail(this.state.email)) {      // ...    }  }  render () {    return (      <div>        <span class="email-label">Enter your email:</span>        <input type="text" id="email" onChange={this.updateEmail} />        <button onClick={this.handleSubmit}>Sign Up</button>      </div>    );  } } 

Di sini Anda dapat menemukan beberapa masalah penting mengenai aksesibilitas proyek:

1. Formulir yang tidak menggunakan elemen <form> tidak lagi berupa formulir. Bahkan, Anda dapat memperbaikinya dengan hanya menentukan role = "form" dari elemen induk <div> , tetapi jika Anda membuat form, dan apa yang kami lihat benar-benar tampak seperti form, gunakan elemen <form> , atur sesuai dengan itu. atribut action dan method . Atribut action memainkan peran penting di sini, karena memungkinkan formulir untuk melakukan setidaknya sesuatu bahkan jika JavaScript tidak tersedia (tentu saja, jika komponen itu diberikan di server).
2. <span> bukan pengganti <label> , yang menyediakan beberapa fitur mengenai ketersediaan proyek yang tidak dimiliki <span> .
3. Elemen <button> tanpa atribut type="submit" hanyalah sebuah tombol, mengklik pada panggilan mana event handler terikat padanya. Jika kita ingin melakukan sesuatu dengan data sebelum mengirimkan formulir, kita perlu menetapkan atribut type="submit" ke tombol dan memindahkan kode dari penangan event onClick ke penangan onSubmit form onSubmit .
4. Ngomong-ngomong, mengapa menggunakan JavaScript untuk memverifikasi alamat email, sementara HTML5 menempatkan kontrol pembuangan kami yang mendukung memeriksa data input di hampir semua browser - hingga IE10? Di sini kita melihat peluang yang terlewatkan untuk memanfaatkan fungsionalitas yang sudah ada di browser dan menerapkan tipe elemen yang sesuai, serta atribut yang diperlukan . Namun, dengan menggunakan konstruksi seperti itu, perlu diingat bahwa pengaturan interaksi normal mereka dengan pembaca layar akan membutuhkan usaha .

Mempertimbangkan hal di atas, kami memperbaiki kode komponen:

 import React, { Component } from "react"; class SignupForm extends Component { constructor (props) {   this.handleSubmit = this.handleSubmit.bind(this); } handleSubmit (event) {   //    ,         XHR   // (      ,     ,     JS).   event.preventDefault();   //  … } render () {   return (     <form method="POST" action="/signup" onSubmit={this.handleSubmit}>       <label for="email" class="email-label">Enter your email:</label>       <input type="email" id="email" required />       <button type="submit">Sign Up</button>     </form>   ); } } 

Sekarang, fakta bahwa komponen ini menghasilkan tidak hanya lebih mudah diakses, tetapi lebih sedikit kode JS yang digunakan untuk mengimplementasikan fungsi yang sama seperti sebelumnya. Di dunia yang benar-benar tenggelam dalam JavaScript, menyingkirkan beberapa baris kode harus dilihat sebagai sesuatu yang positif. Peramban memberi kami banyak peluang , dan kami harus berusaha untuk menggunakan peluang ini sesering mungkin.

Saya tidak ingin mengatakan di sini bahwa masalah dengan aksesibilitas halaman muncul secara eksklusif saat menggunakan kerangka kerja tertentu. Maksud saya, terlalu mengandalkan JavaScript, pengembang, sebagai hasilnya, hanya akan kehilangan banyak fitur HTML dan CSS yang penting. Kesenjangan dalam pengetahuan ini sering menyebabkan kesalahan, terlebih lagi, kami bahkan tidak menduga kesalahan ini. Kerangka kerja dapat menjadi alat yang berguna yang meningkatkan produktivitas pengembang, tetapi studi konstan tentang kemampuan teknologi web dasar sangat penting dalam menciptakan produk yang nyaman dan bermanfaat, terlepas dari alat bantu yang digunakan dalam pengembangannya.

Andalkan kekuatan platform web dan berikan proyek Anda masa depan yang cerah

Karena kita berbicara tentang kerangka kerja, perlu dicatat bahwa platform web, dengan sendirinya, juga merupakan kerangka kerja besar. Seperti yang ditunjukkan pada bagian sebelumnya, kami berada di posisi yang lebih baik jika kami dapat mengandalkan pola yang sudah ada untuk bekerja dengan kemampuan markup dan browser. Alternatif untuk fitur-fitur standar ini adalah menciptakannya lagi. Tak perlu dikatakan, "penemuan" seperti itu penuh dengan kesulitan yang cukup besar. Tetapi bagaimana jika masalah seperti itu, masing-masing dengan caranya sendiri, akan diselesaikan oleh penulis dari semua paket JavaScript yang kita instal?

▍ Aplikasi Halaman Tunggal

Salah satu kelemahan pengembang yang mereka dapat dengan mudah membeli adalah penggunaan model Aplikasi Halaman Tunggal (SPA), bahkan dalam proyek-proyek yang model ini tidak cocok. Tentu saja, proyek-proyek tersebut mendapat manfaat dari fakta bahwa mereka dianggap oleh pengguna sebagai lebih produktif karena perutean yang dilakukan oleh klien. Tapi apa kerugian menggunakan model SPA? Kemampuan navigasi halaman built-in browser, meskipun dibangun pada model sinkron, memberi proyek banyak keuntungan. Salah satunya adalah bahwa manajemen sejarah kunjungan dilakukan melalui penerapan spesifikasi yang kompleks . Pengguna tanpa JavaScript, apakah mereka menonaktifkannya sendiri atau tidak , tidak akan kehilangan kemampuan untuk bekerja dengan proyek. Agar aplikasi satu halaman tersedia di browser dengan JavaScript dimatikan, tiba-tiba ternyata perlu perhatian besar untuk rendering server.


Perbandingan berbagai opsi untuk memuat aplikasi eksperimental pada saluran komunikasi lambat. Render aplikasi di sebelah kiri sepenuhnya tergantung pada JavaScript. Aplikasi di sebelah kanan diberikan di server, tetapi kemudian menggunakan, pada klien, metode hidrat () untuk menghubungkan komponen ke markup yang sudah dibuat di server

Di sini Anda dapat melihat bahwa aplikasi, yang diberikan pada klien, selama beberapa detik menunjukkan pengguna layar kosong, dan kemudian menampilkan antarmuka yang selesai.

Aplikasi yang dirender di server dan dirender operasional pada klien dengan cepat menampilkan elemen utama antarmuka, tetapi Anda dapat menggunakannya setelah sekitar waktu yang sama dengan aplikasi yang diberikan sepenuhnya pada klien.

Ketersediaan aplikasi juga menderita jika router yang berada di klien tidak dapat memberi tahu pengguna tentang apa yang telah berubah pada halaman yang dilihatnya. Ini dapat memaksa pengguna untuk bergantung pada teknologi bantu untuk mengetahui apa yang sebenarnya telah berubah pada halaman, akibatnya, pekerjaan pengguna dengan situs jauh lebih rumit.

Selanjutnya, Anda dapat segera bertemu musuh lama kami - beban yang berlebihan pada sistem. Beberapa router klien sangat kecil. Tetapi jika Anda membuat proyek pada Bereaksi , menggunakan router yang kompatibel, dan, mungkin, perpustakaan untuk mengelola keadaan aplikasi, ini berarti Anda harus menerima bahwa itu akan berisi sejumlah kode layanan, dari mana Anda tidak bisa mendapatkan di mana pun. Yaitu, dalam hal ini kira-kira 135 Kb dari kode tersebut. Analisis proyek yang Anda buat dengan hati-hati dan apakah perutean klien sepadan dengan beban tambahan pada sistem. Biasanya terjadi bahwa lebih baik menolak sistem perutean klien.

Jika Anda khawatir tentang perasaan pengguna, jika Anda ingin situs itu terlihat cepat baginya, maka Anda dapat mengandalkan atribut rel = prefetch link, yang memungkinkan Anda untuk mengatur pemuatan dokumen dari sumber yang sama. Menggunakan atribut ini memiliki dampak besar pada peningkatan kinerja proyek, dirasakan oleh pengguna, karena halaman yang ditautkan dengan menggunakan atribut ini, ketika Anda mengklik tautan ini, langsung dimuat dari cache. Selain itu, karena preloading data memiliki prioritas rendah, tidak mungkin bersaing untuk bandwidth dengan sumber daya penting.


Kode HTML yang direferensikan dengan menulis / dimuat sebelum Anda mengunjungi halaman utama situs. Ketika pengguna mengklik tautan yang sesuai, kode HTML langsung dimuat dari cache browser

Masalah utama yang mungkin timbul dengan halaman pramuat, dan yang perlu Anda ketahui, adalah bahwa pemuatan tersebut dapat menjadi pemborosan waktu dan sumber daya. Untuk mengatasinya, Anda dapat, misalnya, menggunakan skrip Quicklink kecil dari Google, yang mengurangi masalah ini. Ini memeriksa apakah klien saat ini menggunakan koneksi yang lambat, apakah itu memiliki mode hemat data diaktifkan , dan, secara default, memungkinkan Anda untuk menghindari bahan prapembuatan dari sumber selain dari sumber halaman.

Untuk membuat situs terlihat cepat di mata pengguna yang mengunjunginya berkali-kali, Anda dapat menggunakan pekerja layanan . Mereka dapat digunakan terlepas dari apakah proyek menggunakan sistem perutean klien atau tidak, mengingat bahwa Anda terbiasa dengan beberapa fitur pekerja layanan. Melakukan caching rute melalui pekerja layanan, kami mendapatkan banyak keuntungan yang sama yang merupakan karakteristik untuk pengunduhan awal beberapa tautan, tetapi kami memiliki kemungkinan yang jauh lebih luas untuk bekerja dengan permintaan dan jawaban. Apakah Anda menganggap situs Anda sebagai "aplikasi" atau tidak, melengkapinya dengan pekerja layanan mungkin merupakan contoh dari salah satu kasus penggunaan JavaScript yang paling kritis saat ini.

▍JavaScript tidak dirancang untuk tata letak

Jika kami menginstal paket JS yang dirancang untuk menyelesaikan masalah yang terkait dengan tata letak halaman, maka sudah saatnya bagi kami untuk sangat berhati-hati dan bertanya pada diri sendiri apa yang ingin kami capai dengan paket ini. CSS dibuat khusus untuk membuat tata letak halaman, agar dapat menggunakannya secara efektif, Anda tidak perlu abstraksi. Sebagian besar tugas membuat tata letak yang berusaha diselesaikan menggunakan JavaScript, seperti menempatkan elemen, meluruskannya, menyesuaikan ukurannya, seperti mengelola teks atau bahkan membuat tata letak sepenuhnya menggunakan JavaScript, kini dapat diselesaikan dengan menggunakan CSS. Alat modern untuk membuat tata letak seperti Flexbox dan Grid didukung dengan baik oleh peramban, jadi kami tidak perlu mengembangkan proyek berdasarkan kerangka kerja untuk bekerja dengan tata letak. Omong-omong, CSS juga merupakan kerangka kerja. Ketika kami siap, ada peluang seperti permintaan properti , peningkatan tata ruang secara progresif untuk mendukung cara baru pembentukannya, ternyata, tidak begitu sulit .

 /*   , ,   ,        CSS Grid. */ /*  @supports  ,     CSS Grid,     . */ @supports (display: grid) { /*      */ @media (min-width: 40em) {   /*       CSS Grid */ } } 

Menggunakan JavaScript untuk memecahkan masalah membuat tata letak halaman dan menyesuaikan tampilannya bukan berita. Inilah yang kami lakukan pada tahun 2009, ketika kami hidup dalam suasana penipuan diri sendiri, dengan mengatakan bahwa setiap situs akan terlihat seperti di IE6 dan juga di browser yang lebih canggih pada waktu itu. Jika hari ini, pada tahun 2019, kami terus mengembangkan situs sehingga mereka terlihat sama di semua browser, ini berarti bahwa kami perlu mempertimbangkan kembali tujuan kami. Akan selalu ada beberapa peramban yang perlu didukung, dan yang tidak memiliki kemampuan yang sama dengan peramban paling modern. Kesamaan eksternal yang lengkap dari proyek-proyek di semua platform tidak hanya membuang-buang energi, tetapi juga merupakan musuh mendasar dari gagasan peningkatan progresif .

Intinya: Saya tidak akan menjadi pembunuh JavaScript

Jangan salah paham, saya bukan milik musuh JavaScript. Berkat bahasa ini, saya telah membangun karier, dan, sejujurnya, JavaScript, selama lebih dari sepuluh tahun, memberi saya banyak kesenangan. Seperti halnya hubungan jangka panjang, semakin banyak waktu yang saya habiskan untuk bekerja dengan JavaScript, semakin baik saya mengenalnya. Ini adalah bahasa yang matang dengan banyak fitur, yang, setiap tahun, menjadi lebih baik.

Namun, terkadang saya merasa ada yang salah dengan hubungan JavaScript kami. Saya mengkritiknya. Atau, lebih tepatnya, saya mengkritik kecenderungan saat ini untuk menganggap JavaScript sebagai alat utama untuk membangun situs, yang terpaksa sejak awal, tanpa melihat apa pun. Ketika saya menganalisis bundel lain yang tampak seperti karangan bunga Natal yang membingungkan, menjadi jelas bagi saya bahwa web itu mabuk dengan JavaScript. Kami menggunakan bahasa ini untuk hampir semua alasan, bahkan dalam kasus di mana keadaan tidak memerlukan ini. Terkadang saya berpikir tentang seberapa parah konsekuensi dari sikap terhadap JS ini.

Saya berencana untuk terus menulis tentang JavaScript dan pengembangan web, untuk terus mencari cara untuk menggunakan teknologi web secara rasional. Semoga bersama-sama kita membuat web modern lebih baik.

Pembaca yang budiman! Apakah Anda pikir web modern benar-benar kelebihan dengan kode JavaScript?