Kerangka Kerja CSS Atau Kotak CSS: Apa yang Harus Saya Gunakan Untuk Proyek Saya?
Diterbitkan: 2022-03-10Di antara pertanyaan yang paling sering saya tanyakan adalah beberapa variasi pertanyaan, “Haruskah saya menggunakan CSS Grid atau Bootstrap?” Pada artikel ini, saya akan melihat pertanyaan itu. Anda akan menemukan bahwa alasan untuk menggunakan kerangka kerja bervariasi, dan tidak hanya berpusat pada penggunaan sistem grid yang terkandung dalam kerangka kerja itu. Saya harap dengan membongkar alasan ini, saya dapat membantu Anda membuat keputusan sendiri, dalam hal apa yang terbaik untuk situs dan aplikasi yang sedang Anda kerjakan, dan juga untuk tim yang bekerja dengan Anda.
Pada artikel ini ketika saya berbicara tentang framework , saya menjelaskan framework CSS pihak ketiga seperti Bootstrap atau Foundation. Anda mungkin berpendapat ini benar-benar pustaka komponen, tetapi banyak orang (termasuk dokumen mereka sendiri) akan menggambarkannya sebagai kerangka kerja sehingga itulah yang akan kita gunakan di sini. Faktor penting adalah bahwa ini adalah sesuatu yang dikembangkan secara eksternal untuk Anda, tanpa mengacu pada masalah spesifik Anda. Alternatif untuk menggunakan kerangka kerja pihak ketiga adalah dengan menulis CSS Anda sendiri — yang mungkin melibatkan pengembangan kerangka kerja internal Anda sendiri, menggunakan sekumpulan file umum sebagai titik awal, atau membuat setiap proyek sebagai hal baru. Semua hal ini dilakukan dengan mengacu pada kebutuhan spesifik Anda sendiri daripada kebutuhan yang sangat umum.
Mengapa Memilih Kerangka CSS?
Pertanyaan apakah akan menggunakan Grid atau framework adalah salah, karena CSS Grid bukanlah pengganti drop-in untuk hal-hal yang dilakukan oleh framework CSS. Setiap eksplorasi subjek perlu mempertimbangkan kerangka kerja apa yang akan diganti oleh Grid CSS kita. Saya ingin memulai dengan mencari tahu mengapa orang memilih untuk menggunakan kerangka kerja CSS sama sekali. Jadi saya beralih ke Twitter dan memposting tweet ini.
Sebuah pertanyaan: jika Anda telah memilih untuk menggunakan kerangka kerja CSS (Bootstrap, Foundation, dll.) untuk proyek Anda, apa alasan utama untuk melakukannya?
— Rachel Andrew (@rachelandrew) 16 Oktober 2018
Ada banyak tanggapan. Seperti yang saya harapkan, ada lebih banyak alasan untuk menggunakan kerangka kerja daripada sekadar sistem grid yang dikandungnya.
Kerangka Kerja Memberi Tim Anda Dokumentasi Siap Pakai
Jika Anda mengerjakan proyek dengan sejumlah pengembang lain, maka sistem internal apa pun yang Anda buat juga perlu menyertakan dokumentasi untuk membantu anggota tim Anda menggunakannya secara efektif. Membuat dokumentasi yang berguna adalah pekerjaan yang memakan waktu dan terampil, dan sesuatu yang dilakukan dengan sangat baik oleh kerangka kerja besar.
Dokumentasi kerangka muncul lagi dan lagi, dengan banyak pengembang front-end berpengalaman yang ikut serta dan menjelaskan mengapa mereka akan merekomendasikan dan menggunakan kerangka kerja CSS. Saya terkadang mendengar pendapat bahwa orang menggunakan kerangka kerja karena mereka tidak benar-benar tahu CSS, banyak dari orang-orang yang menjawab, bagaimanapun, saya kenal sebagai pengembang ahli CSS. Saya yakin mereka terkadang frustrasi dengan pilihan yang dibuat oleh kerangka kerja, namun, aspek positif dari pilihan itu lebih besar daripada itu.
Komunitas Online: Akses Mudah Untuk Membantu
Saat Anda memutuskan untuk menggunakan alat tertentu, Anda juga mendapatkan komunitas pengguna untuk meminta bantuan. Kecuali Anda memiliki masalah CSS yang sangat jelas, dan dapat menghasilkan kasus penggunaan yang dikurangi untuk menunjukkannya, meminta bantuan dengan CSS bisa jadi sulit. Terutama jika Anda ingin bertanya bagaimana pendekatan membangun komponen tertentu. Menggunakan kerangka kerja dapat memberi Anda titik awal untuk pertanyaan Anda; secara umum, Anda akan bertanya bagaimana memodifikasi atau menata komponen tertentu daripada memulai dari awal. Ini adalah hal yang lebih mudah untuk ditanyakan, serta hal yang lebih mudah untuk dijawab.
Sistem Grid
Terlepas dari kenyataan bahwa kami memiliki CSS Grid, banyak orang menjawab bahwa alasan utama mereka memutuskan untuk menggunakan kerangka kerja adalah untuk sistem grid. Tentu saja, banyak dari proyek ini mungkin telah dimulai jauh sebelum CSS Grid tersedia. Namun, bahkan hari ini, kekhawatiran tentang kompatibilitas mundur atau pemahaman tim tentang metode tata letak yang lebih baru dapat menyebabkan orang memutuskan untuk menggunakan kerangka kerja daripada mengadopsi CSS asli.
Kecepatan Pengiriman Proyek
ketika memiliki desain yang unik dan css yang efisien adalah prioritas yang jauh lebih rendah daripada tanggal jatuh tempo
— CodingBlocks.net (@CodingBlocks) 16 Oktober 2018
Memilih kerangka kerja akan, secara umum, membuatnya jauh lebih cepat untuk mengirimkan proyek Anda, khususnya jika proyek itu sangat cocok dengan cara kerangka kerja melakukan sesuatu dan tidak memerlukan banyak penyesuaian.
Dalam hal mengembangkan MVP untuk ide baru, kerangka kerja mungkin merupakan pilihan yang sangat baik. Anda akan memiliki banyak hal untuk menghabiskan waktu, dan masih menguji asumsi dalam hal apa yang dibutuhkan proyek. Mampu mengembangkan versi pertama menggunakan kerangka kerja dapat membantu Anda menampilkan produk di hadapan pengguna dengan lebih cepat, dan menghemat banyak waktu untuk mengembangkan hal-hal yang kemudian Anda putuskan untuk tidak digunakan.
Saya menggunakan kerangka kerja pada apa pun yang merupakan MVP — upaya pengembangan minimal pada perkakas dan kerangka kerja untuk mengoptimalkan waktu mengerjakan konsep yang sebenarnya.
— Ben Bodien (@bbodien) 16 Oktober 2018
Saya membuat "kerangka" CSS saya sendiri pada apa pun yang merupakan pengulangan dari situs/aplikasi skala besar yang ada.
Tempat lain di mana kecepatan dan sekumpulan komponen siap pakai bisa sangat berguna adalah saat mengembangkan sistem admin backend untuk situs atau aplikasi. Jika Anda hanya perlu membuat beberapa layar admin, kerangka kerja dapat menghemat banyak waktu untuk menata bidang formulir dan komponen lainnya! Bahkan ada tema dasbor untuk Bootstrap dan Foundation yang dapat memberikan titik awal yang membantu.
Saya Bukan Seorang Desainer!
Poin ini adalah alasan saya memilih kerangka kerja CSS di masa lalu. Saya bukan seorang desainer, dan jika saya harus merancang dan membangun sesuatu, saya akan menghabiskan waktu lama untuk mencoba membuat keputusan desain yang sama sekali tidak memenuhi syarat untuk saya buat. Akan menyenangkan untuk memiliki dana untuk menyewa seorang desainer untuk setiap proyek sampingan, namun, saya tidak, dan kerangka kerja mungkin berarti perbedaan antara pengiriman barang dan tidak.
Menangani Bug CSS Dan Masalah Kompatibilitas Browser
Disebutkan kurang dari yang saya kira mungkin adalah fakta bahwa pembuat kerangka kerja telah menangani masalah browser, baik itu karena bug yang sebenarnya atau kurangnya dukungan untuk fitur tertentu. Namun, ini masih menjadi faktor dalam pengambilan keputusan bagi banyak orang.
Untuk Membantu Dengan Desain Responsif
Responsivitas halaman web. Saya merasa sulit untuk memutuskan breakpoint untuk halaman web.
— Faisal Ali (@f_a_akhtar) 18 Oktober 2018
Ini muncul beberapa kali; orang-orang memilih kerangka kerja secara khusus karena fakta bahwa kerangka kerja itu responsif, atau bahwa saya membuat keputusan tentang titik henti sementara untuk mereka. Saya pikir menarik bahwa ini secara khusus adalah sesuatu yang disebut sebagai faktor dalam memilih untuk menggunakan kerangka kerja.
Mengapa Tidak Menggunakan Kerangka Kerja?
Di antara alasan positif mengapa kerangka kerja dipilih adalah beberapa masalah yang dihadapi orang dengan pilihan itu.
Kesulitan Mengganti Kode Kerangka
Banyak orang mengomentari fakta bahwa mungkin sulit untuk mengganti kode yang digunakan dalam kerangka kerja, dan kerangka kerja itu adalah pilihan yang baik jika mereka tidak membutuhkan banyak penggantian. Manfaat kemudahan penggunaan, dan semua orang di tim yang memahami cara menggunakan kerangka kerja dapat hilang jika ada sejumlah besar penyesuaian yang diterapkan.
Semua Situs Web Akhirnya Terlihat Sama
Kesalahan untuk semua situs web yang mulai terlihat sama telah ditempatkan tepat di depan kerangka kerja CSS yang terkenal. Saya telah melihat situs di mana saya yakin kerangka kerja tertentu telah digunakan, kemudian menemukan bahwa itu adalah CSS khusus, begitu lazim pilihan desain yang dibuat dalam kerangka kerja ini.
Kesulitan dalam mengganti gaya kerangka kerja yang telah disebutkan adalah sebagian besar alasan mengapa situs yang dikembangkan menggunakan kerangka kerja tertentu akan cenderung terlihat serupa. Ini bukan hanya masalah kreatif, ini bisa sangat aneh karena pengguna beberapa situs web yang semuanya memilih kerangka kerja yang sama untuk merasa bahwa semuanya adalah hal yang sama. Dalam hal menyampaikan merek Anda, dan menjadikan pengalaman pengguna yang baik sebagai bagian dari itu, mungkin Anda kehilangan sesuatu saat memilih pilihan kerangka kerja yang umum.
Mewarisi Masalah CSS di Seluruh Dunia
Baik front-end atau back-end, alat atau kerangka kerja apa pun yang berupaya mencapai arus utama harus menyelesaikan sebanyak mungkin masalah. Kecuali jika alat ini digabungkan dengan erat untuk memecahkan satu kasus penggunaan tertentu, alat itu akan berisi banyak kode yang sangat umum, dan kode yang memecahkan masalah yang tidak Anda miliki, dan tidak akan pernah Anda miliki.
Anda mungkin berada dalam posisi yang beruntung karena hanya membutuhkan pengalaman penuh Anda untuk dilihat di browser terbaru, memungkinkan pengalaman yang lebih terbatas di Internet Explorer, atau versi Chrome yang lebih lama. Menggunakan kerangka kerja dengan banyak dukungan bawaan kembali ke IE9 akan menghasilkan banyak kode tambahan — terutama mengingat peningkatan tata letak CSS baru-baru ini. Ini mungkin juga mencegah Anda menjadi kreatif, karena semua yang ada di kerangka kerja mengasumsikan persyaratan untuk dukungan ini. Hal-hal yang mungkin menggunakan CSS mungkin dibatasi oleh kerangka kerja.
Sebagai contoh, sistem kisi dalam kerangka kerja populer tidak memiliki kemampuan untuk merentangkan baris, karena tidak ada konsep atau baris dalam sistem tata letak sebelum Tata Letak Kotak. Tata Letak Grid CSS dengan mudah memungkinkan untuk ini. Jika Anda terikat pada Bootstrap Grid dan desainer Anda muncul dengan desain yang menyertakan elemen yang mencakup baris, Anda tidak dapat menerapkannya — meskipun faktanya Grid mungkin didukung oleh browser target Anda.
Masalah perfoma
Terkait dengan hal di atas adalah masalah kinerja yang melekat dalam menggunakan kode yang cukup umum, daripada sesuatu yang dioptimalkan untuk kasus penggunaan persis yang Anda miliki. Saat mencoba meningkatkan kinerja, Anda akan menemukan diri Anda menghadapi keputusan kerangka kerja.
Peningkatan Utang Teknis
Kecepatan, terutama, meskipun kami dengan cepat menemukan bahwa itu adalah ekonomi yang salah karena menciptakan utang teknis yang besar dalam jangka panjang.
— Tim Cthulhuegdon (@nefarioustim) 16 Oktober 2018
Sementara kerangka kerja mungkin merupakan cara yang bagus untuk membuat startup Anda cepat keluar, dan pada saat membuat keputusan itu Anda yakin akan menggantinya, apakah ada rencana untuk mewujudkannya?
Mempelajari Kerangka Daripada Mempelajari CSS
Ketika berbicara dengan peserta konferensi dan lokakarya, saya menemukan bahwa banyak orang hanya pernah menggunakan kerangka kerja untuk menulis CSS. Tidak ada yang salah dengan datang ke pengembangan web melalui salah satu alat ini, mengingat kompleksitas platform web hari ini saya membayangkan itu akan menjadi rute bagi banyak orang. Namun, itu bisa menjadi pilihan yang membatasi karier, terutama jika kerangka kerja yang Anda gunakan berdasarkan keterampilan Anda tidak disukai.
Memiliki pengembang front-end tanpa pengetahuan CSS harus membuat perusahaan khawatir. Sangat sulit untuk menjauh dari kerangka kerja itu jika tim Anda tidak benar-benar mengerti bagaimana melakukan CSS tanpanya. Meskipun ini bukan alasan untuk tidak menggunakan kerangka kerja, ini adalah sesuatu yang perlu diingat saat menggunakannya. Ketika saatnya tiba untuk pindah, Anda akan berharap bahwa tim akan siap untuk melakukan sesuatu yang baru, tidak perlu mengingat (atau belajar untuk pertama kalinya) cara menulis CSS!
Pilihan Tidak Mempertimbangkan Pengguna Akhir
Nicole Sullivan menanyakan pertanyaan yang hampir sama beberapa hari sebelum pertanyaan saya ketika saya berpikir untuk menulis artikel ini, meskipun dia mempertimbangkan kerangka kerja front-end secara keseluruhan daripada hanya kerangka kerja CSS. Jeremy Keith mencatat bahwa tepat nol dari jawaban yang bersangkutan pengguna akhir. Ini juga terjadi dengan tanggapan atas pertanyaan saya.
Dalam perlombaan kami untuk membuat situs kami dibangun dengan cepat, keinginan kami untuk membuat hal-hal sebaik mungkin untuk diri kami sendiri sebagai perancang dan pengembang situs, apakah kami lupa untuk siapa kami melakukan ini? Apakah keputusan yang dibuat oleh pengembang kerangka kerja sesuai dengan kebutuhan pengguna situs yang Anda bangun?
Bisakah Kita Mengganti Kerangka Dengan CSS "Vanilla"?
Jika Anda mempertimbangkan untuk mengganti kerangka kerja Anda atau memulai proyek baru tanpa kerangka kerja, apa saja hal yang dapat Anda pertimbangkan untuk mempermudah proses tersebut?
Pahami Bagian Kerangka Yang Anda Butuhkan
Jika Anda mengganti penggunaan kerangka kerja dengan CSS Anda sendiri, tempat yang baik untuk memulai adalah mengaudit penggunaan kerangka kerja Anda saat ini. Cari tahu apa yang Anda gunakan dan mengapa. Pertimbangkan bagaimana Anda akan mengganti hal-hal itu dalam desain baru.
Anda dapat mengikuti proses serupa ketika memikirkan apakah akan memilih kerangka kerja atau menulis kerangka kerja Anda sendiri. Bagian mana dari ini yang secara wajar Anda harapkan akan dibutuhkan? Seberapa cocok dengan kebutuhan Anda? Akankah ada banyak kode yang Anda impor, berpotensi meminta pengunjung untuk mengunduh, tetapi tidak pernah menggunakannya?
Buat Pustaka Pola atau Panduan Gaya Terdokumentasi
Saya penggemar berat bekerja dengan perpustakaan pola dan Anda dapat membaca posting saya di sini di Majalah Smashing tentang penggunaan Fractal kami. Pustaka pola atau panduan gaya memungkinkan pembuatan dokumentasi bersama dengan semua komponen Anda. Saya memulai semua proyek saya dengan mengerjakan CSS di pustaka pola.
Anda masih perlu menulis dokumentasi, sebagai seseorang yang menulis dokumentasi, bagaimanapun, saya tahu bahwa seringkali hal tersulit adalah mengetahui dari mana harus memulai dan bagaimana menyusun dokumen. Pustaka pola membantu dengan ini dengan menyimpan dokumen bersama dengan CSS untuk komponen itu sendiri. Pendekatan ini juga dapat membantu mencegah dokumen menjadi kedaluwarsa karena terkait erat dengan komponen yang dirujuk.
Kembangkan Pedoman Kode CSS Anda Sendiri
Konsistensi di seluruh tim sangat berguna, dan tanpa kerangka kerja, mungkin tidak ada yang mendikte itu. Dengan metode tata letak yang lebih baru, khususnya, seringkali ada beberapa cara di mana sebuah pola dapat dibangun, jika setiap orang memilih yang berbeda maka inkonsistensi cenderung muncul.
Tempat yang Lebih Baik Untuk Meminta Bantuan
Selain mengirim orang ke arah Stack Overflow, tampaknya hanya ada sedikit tempat untuk meminta bantuan tentang CSS. Secara khusus tampaknya ada beberapa tempat yang dapat didekati untuk pemula. Jika kita ingin mendorong orang menjauh dari alat pihak ketiga, maka kita perlu memenuhi kebutuhan akan dukungan yang ramah dan membantu yang berasal dari komunitas di sekitar alat tersebut.
Dalam sebuah perusahaan, ada kemungkinan bahwa pengembang yang lebih berpengalaman dapat menjadi dukungan CSS untuk anggota tim yang lebih baru. Jika beralih dari kerangka kerja ke solusi Anda sendiri, sebaiknya pertimbangkan pelatihan apa yang mungkin diperlukan untuk membantu menjembatani kesenjangan, terutama jika orang terbiasa menggunakan bantuan yang disediakan di sekitar alat pihak ketiga ketika mereka membutuhkan bantuan di masa lalu .
Panduan Gaya Atau Titik Awal Untuk Non-Desainer
Saya mengikat diri saya dalam simpul dengan pertanyaan seperti, "Font mana yang harus saya gunakan?", "Seberapa besar judul yang harus dikaitkan dengan teks isi?", "Apakah boleh menggunakan drop shadow?" Saya dapat dengan mudah menulis CSS — jika saya tahu apa yang saya coba lakukan! Yang benar-benar saya butuhkan adalah beberapa aturan untuk membuat desain yang tidak buruk, semacam titik awal tipografi, atau seperangkat pedoman dasar yang akan menggantikan kemampuan menggunakan default kerangka kerja dalam banyak kasus.
Mendidik Orang Tentang Keadaan Interoperabilitas Peramban Modern
Saya telah menemukan bahwa orang-orang yang telah tenggelam dalam pengembangan berbasis kerangka kerja selama beberapa tahun, sering kali memiliki pandangan tentang interoperabilitas browser yang beberapa tahun ketinggalan zaman. Kami belum pernah berada dalam situasi yang lebih baik dalam hal CSS bekerja lintas-browser. Mungkin beberapa browser tidak mendukung satu CSS baru yang mengkilap, tetapi secara umum, CSS (bila didukung) tidak akan penuh dengan bug aneh. Misalnya, di hampir semua kasus jika Anda menggunakan CSS Grid di satu browser, CSS Anda akan bekerja dengan cara yang persis sama di browser lain.
Jika mencoba membuat alasan untuk tidak menggunakan kerangka kerja kepada anggota tim yang percaya bahwa kerangka kerja menyelamatkan mereka dari bug browser, poin ini mungkin berguna untuk diangkat. Apakah masalah kompatibilitas browser itu nyata, atau berdasarkan kekhawatiran di masa lalu?
Akankah Kita Melihat Kerangka Kerja Baru?
Sesuatu yang menarik bagi saya adalah apakah metode tata letak baru kami akan membantu mengantarkan generasi baru alat dan kerangka kerja. Akankah kita melihat alat yang memanfaatkan metode tata letak baru, memungkinkan lebih banyak kreativitas tetapi masih memberi tim dan individu beberapa keuntungan tak terbantahkan yang keluar dari tanggapan terhadap tweet saya.
Mungkin dengan mengandalkan metode tata letak baru, daripada sistem grid inbuilt, kerangka gaya baru bisa jauh lebih ringan, menjadi kumpulan komponen yang berguna. Mungkin kemudian dapat lolos dari beberapa masalah kinerja yang melekat dalam kode yang sangat umum.
Area yang dapat dibantu oleh kerangka kerja adalah membantu membuat fallback yang solid untuk browser yang tidak mendukung metode tata letak yang lebih baru, atau dengan memasukkan aksesibilitas yang sangat solid ke dalam komponen. Ini dapat membantu memberikan panduan tentang cara kerja yang mempertimbangkan interoperabilitas dan aksesibilitas, bahkan bagi orang-orang yang tidak memikirkan hal-hal ini sebelumnya.
Saya tidak berpikir bahwa hanya dengan mengganti Bootstrap Grid untuk CSS Grid Layout akan mencapai ini. Sebagai gantinya, penulis yang datang dengan kerangka kerja baru, mungkin harus melihat beberapa alasan yang diuraikan di sini, dan mencoba menyelesaikannya dengan cara baru, menggunakan fungsionalitas baru yang kami miliki di CSS untuk melakukannya.
Haruskah Anda Menggunakan Kerangka Kerja?
Anda dan tim Anda harus menjawab pertanyaan itu sendiri. Dan, terlepas dari apa yang orang coba yakinkan kepada Anda, tidak ada jawaban benar atau salah yang universal. Hanya ada apa yang benar atau salah untuk proyek Anda. Saya berharap artikel ini dan banyak tanggapan atas pertanyaan awal saya dapat memberi Anda beberapa hal untuk didiskusikan saat Anda merenungkan pertanyaan itu.
Ingatlah bahwa jawabannya akan berubah seiring waktu. Mungkin ini merupakan eksperimen pemikiran yang berguna untuk tidak hanya mempertimbangkan apa yang Anda butuhkan saat ini, dalam hal melakukan pengembangan situs pada awalnya, tetapi juga mempertimbangkan umur situs. Apakah Anda berharap ini masih ada dalam lima tahun? Apakah pilihan Anda akan positif atau negatif?
Dokumentasikan keputusan Anda, jangan takut untuk meninjaunya kembali, dan pastikan bahwa Anda dan tim Anda mempertahankan keterampilan Anda di luar kerangka kerja apa pun yang Anda putuskan untuk digunakan. Dengan begitu, Anda akan berada di tempat yang baik untuk melanjutkan di masa depan dan membuat keputusan terbaik untuk fase selanjutnya dari proyek Anda.
Saya ingin percakapan yang dimulai di tweet itu berlanjut. Beri tahu kami cerita Anda di komentar — mereka mungkin membantu orang lain yang mencoba mencari tahu apa yang terbaik untuk proyek mereka saat ini.