Posting ini adalah jawaban terinci untuk pertanyaan dari percakapan ini di Twitter . Penulis aslinya, Sunil Pye, adalah penulis perpustakaan glamour yang relatif populer dan bekerja sebagai pengembang di Facebook.
Bagaimana Javascript lebih nyaman daripada CSS? Bagaimana cara menulis CSS di dalam JS membuatnya lebih didukung?
Saya akan senang berbicara tentang topik ini. Saya harus segera mengatakan bahwa solusi CSS-in-JS memiliki overhead, tetapi biasanya harga ini dibenarkan oleh keuntungan yang mereka bawa. Terkadang mereka bisa berguna, tetapi juga ini tidak berarti bahwa CSS-in-JS harus digunakan selalu dan di mana-mana.
Jadi, hal terpenting dalam CSS-in-JS (cij) adalah penyeleksi CSS. Keuntungan terbesar dari cij adalah bahwa komputer dapat menghasilkan penyeleksi ini secara otomatis. Konvensi seperti OOCSS, dll. pada prinsipnya, mereka bagus, tetapi didasarkan pada penyeleksi tulisan tangan, yang sulit untuk memastikan keunikan dalam namespace umum, karena selalu ada peluang untuk persimpangan. Jika itu tidak terjadi sekarang, itu bisa terjadi setelah tiga tahun, ketika tim Anda tumbuh dan keadaan berubah. Situasi ini diperburuk dengan menggunakan perpustakaan pihak ketiga. Membatasi ruang lingkup pemilih CSS juga dapat dicapai dengan menggunakan modul CSS , yang populer tepat untuk kesempatan ini.
Namun demikian, dengan semua pendekatan ini, penyeleksi sangat sulit untuk menganalisis secara statis dan menemukan mana yang rusak (atau mengandung kesalahan ketik), yang berarti bahwa mereka harus diperiksa secara manual dalam proses peninjauan kode, yang akan mengurangi efektivitas perintah. Kita harus menggunakan bantuan komputer dan tidak bergantung pada integritas dan ketidakberesan orang (karena ini tidak begitu). CSS-in-JS memungkinkan untuk mengotomatiskan generasi penyeleksi dan pengidentifikasi unik.
Selain itu, peningkatan kontrol terhadap pemilih CSS membuka kemungkinan baru yang tidak mudah diakses sebelumnya. Misalnya, kita cukup menerapkan ekstraksi CSS kritis dengan mencocokkan blok HTML dengan gaya yang mereka butuhkan, sehingga kita hanya dapat memuat 1-2 Kb CSS pada halaman, yang diperlukan untuk tampilan awal halaman. Tanpa runtime! Kerangka kerja seperti Gatsby dan Next secara aktif menggunakan ini untuk meningkatkan indikator kinerja dalam proyek berdasarkan pada mereka. Mereka menyematkan CSS kritis langsung di HTML yang dapat diunduh hanya karena beratnya sangat sedikit sehingga akan lebih baik daripada permintaan tambahan yang memblokir pemuatan halaman. Ini sangat mengurangi waktu rendering halaman awal. Selain itu, ini juga berkontribusi untuk memecahkan masalah ukuran Javascript yang dapat diunduh! Manfaat berasal dari penggunaan CSS kritis, serta penggunaan import() dinamis import() , pemisahan kode dan penghapusan kode yang tidak digunakan. (Berbeda dengan file gaya Legacy yang terus berkembang, di mana pengembang hanya menambahkan kode baru, takut menyentuh yang sudah ada. Ada sedikit analitik tentang topik ini .)
Situasi serupa dengan implementasi tema. Tahukah Anda bahwa variabel CSS , bahkan menjadi hal yang sangat menarik, tidak membuka kasus penggunaan yang semula dimaksudkan, dan semua karena metode mundur untuk browser lama sangat rumit atau lebih rendah? Ini berarti bahwa mereka biasanya digunakan sebagai konstanta global, tetapi sangat jarang sebagai variabel yang nilainya ditentukan secara dinamis di browser. Memiliki CSS CSS runtime berarti Anda dapat meneruskan nilai dari JS ke gaya, memungkinkan hal ini.
Bahkan, Anda akan menyukainya: Anda akhirnya dapat dengan jujur menggunakan variabel CSS di semua browser, yaitu, kemampuan asli tanpa runtime di browser yang mendukungnya, dan runtime khusus untuk browser lama. (Saya menulis lebih banyak tentang ini di sini , dan - jika saya mengerti dengan benar - ini adalah satu-satunya perpustakaan yang telah mencapai ini).
Dalam situasi SPA yang kompleks dengan banyak komponen dan pemuatan sumber daya yang tidak sinkron, seperti skrip dan gaya, Anda tidak dapat menjamin urutan gaya pemuatan yang tepat, jadi Anda harus membuat beberapa jenis solusi runtime untuk menjamin urutan gaya, atau cukup gunakan !important , bahkan jika Anda tetap berpegang pada semacam metodologi CSS . Misalnya, Anda memiliki elemen dengan class=“ab” , tetapi kelas a dan b didefinisikan dalam file style yang berbeda, maka Anda tidak dapat memastikan bentuk akhir dari blok jika Anda tidak memiliki urutan urutan yang jelas dari file style. Basis kode Facebook berisi ribuan penggunaan !important , meskipun kode ini ditulis oleh pemrogram yang memenuhi syarat menggunakan prinsip SOLID dan interaksi yang baik dengan tim desain.
Ini sering merujuk pada penanganan CSS seolah-olah itu Javascript - mengingat bahwa 10 tahun yang lalu kami sudah menyelesaikan masalah yang sama untuk JS - perpustakaan dan modul mendaftarkan diri di namespace global ( $ dan sejenisnya) dan kami harus cukup berhati-hati dengan urutan koneksi skrip dalam HTML. Tapi kami tidak terjebak di sana selamanya - sekarang kami menggunakan modul, dan sistem perakitan menjahitnya dalam urutan yang benar dan terjamin. Ini sederhana dan transparan bagi kami.
Menyaksikan proyek nyata, saya juga memperhatikan bahwa Anda masih dapat menggunakan pendekatan arsitektur tradisional (seperti OOCSS atau SMACSS, dll.) Di dunia CSS-in-JS - elemen arsitektur tersebut diwakili di sini oleh objek-JS, alih-alih blok pemilih + gaya. Saya mengambil pendekatan ini dan itu bekerja dengan baik untuk saya. Di sini Anda dapat membaca lebih lanjut tentang itu.
Saya juga menyadari kelemahan CSS-in-JS. Bahkan, inilah tepatnya mengapa tidak ada satu perpustakaan "kanonik" yang mewakili CSS-in-JS - ini adalah spektrum solusi yang berbeda, dari vanilla static CSS di satu sisi ke perpustakaan yang sepenuhnya dinamis seperti komponen bergaya di sisi lain. Praprosesor seperti SASS atau KURANG mungkin tampak tegak lurus terhadap spektrum ini, karena mereka secara teoritis dapat digunakan oleh perpustakaan mana pun atas kebijaksanaan penulisnya. Masing-masing perpustakaan memiliki kekurangannya - beberapa terlibat dalam mengekstraksi gaya pada tahap perakitan sehingga tidak ada biaya dalam runtime, beberapa berfokus pada ketepatan atau kenyamanan bagi pengembang, yang lain fokus pada implementasi efektif dari animasi yang kompleks, dan seterusnya dan seterusnya. Keragaman ini merupakan reaksi alami terhadap kebutuhan akan solusi yang berbeda untuk tugas kerja yang berbeda, dalam industri yang terlalu cepat berkembang. Dan ini terjadi tidak hanya dengan perpustakaan - pengembang standar web (ShadowDOM dan lainnya) dengan gagah berani mencoba untuk memecahkan masalah ini juga, tetapi solusi mereka juga memiliki kelemahan, yang paling tidak adalah bahwa mereka belum tersedia di mana-mana, yang membuatnya tidak dapat diterima untuk digunakan di banyak tim.
Dulu saya memiliki perasaan yang kuat tentang hal ini, tetapi saya telah menahan pandangan saya selama beberapa bulan terakhir. Ternyata kebenaran sebenarnya terletak di suatu tempat di tengah - itu tergantung pada tim, persyaratan, waktu, dokumentasi, dan banyak faktor lainnya. Selain itu, saya tidak berpikir bahwa teks ini mewakili "bentuk akhir" dari ide ini. Kami harus mendorong eksperimen di bidang ini sehingga kami dapat mengetahui apa lagi yang dapat kami lakukan dengan lebih baik, dan bahkan menanamkan beberapa hal ini di browser.
PS Terlambat saya menyadari bahwa saya lupa mencentang kotak "Terjemahan", jadi diterbitkan seperti ini. Tautan ke aslinya .
Habr, perbaiki antarmuka, mengapa Anda tidak dapat menambahkan bendera terjemahan setelah publikasi?