Kenapa (akhirnya) kami memilih BEM — Part 1

Dulu, ketika tim engineer kami belum sebesar sekarang, saat itu jumlah stylesheet pada salah satu platform berita terbesar kami belum lah sekompleks saat ini. Kami mulai membuat style dengan bantuan salah satu library CSS terkemuka, Twitter Bootstrap (selanjutnya kita sebut Bootstrap).

Q3cUg29

Bootstrap merupakan library CSS yang kaya, menyediakan sangat banyak prestyle component siap pakai. Membuat pekerjaan kami menjadi mudah, cepat dan menyenangkan. Setidaknya itu yang kami rasakan ketika platform kami belum mengalami perubahan desain.

Beberapa bulan kemudian, dimulailah perubahan desain. Karena saat itu perubahan desain tidak terlalu banyak, maka kami berpikir tidak masalah untuk melakukan kostumiasi pada Bootstrap, toh masih masih bisa dibaca.

[code language=”css” title=”ourcontroller.less”]
body.ourcontroller {
.ourblock {
.btn-info {
line-height: @slightly-larger;
color: @ourcustomcolor;
}
}
.col-md-8 {
border-right: @custom-grey;
}
}
[/code]

Perubahan demi perubahan terus terjadi, dan memang harus terjadi untuk menjadi lebih baik, maka disanalah kekacauan mulai muncul, style yang tidak independent dan terkait satu dengan yang lain membuat perubahan yang seharusnya mudah justru menjadi sulit untuk dilakukan. Di titik ini akhirnya kami menyadari pentingnya untuk membuat style independent untuk setiap element di dalam halaman HTML.

Kami pun berbenah, mencoba menelusuri tiap baris yang kami tulis sebelumnya yang ternyata cukup besar dan tidak banyak aturan penulisan di dalamnya. Menelusuri baris demi baris, membuang baris css yang dirasa terlalu global, dan memisahkan style yang kami pikir masih berharga untuk diselamatkan ke dalam file baru yang sesuai dengan nama element yang kami miliki.

[code language=”css” title=”components/article-list.less”]
.article-list {
.article-item {
.title {
font-size: @a-bit-smaller;
}
figure {
width: @what-ever-we-want;
}
caption{
font-size: @readable-size;
color: @readable-color;
}
}
}
[/code]

Ketika kedatangan dedicated front engineer pertama kami, kami sedikit bangga memperlihatkan stylesheet kami. Walau baru sebagian yang tertata, setidaknya stylesheet tersebut sudah memiliki aturan. Masih bisa dibaca dan masih diikuti oleh pendatang baru tanpa harus terlalu pusing dengan ketergantungan stylesheet satu komponen dan komponen lain seperti sebelumnya.

Kebanggaan itu tidak berlangsung lama, masalah kembali terjadi ketika diputuskan bahwa platform yang kami bangun harus mendukung multi site. Untuk menghemat waktu pengembangan, kami memutuskan untuk menurunkan style komponen yang sama pada website satu langsung dari style komponen website lain, yang kemudian hanya mengubah bagian yang perlu. Ketergantungan style antar komponen tidak terjadi, digantikan dengan ketergantungan komponen yang sama pada site yang yang berbeda.

[code language=”css” title=”newsite/components/article-list.less”]
@import (reference) “../../components/article-list.less”;

.article-list:extend(.article-list all) {
.article-item {
figure {
width: @wider-than-other-site;
}
}
[/code]

Setelah diskusi panjang lebar, kami mengambil kesimpulan bahwa extend stylesheet bukan ide yang baik.

(Bersambung)

Related Posts

Part II — Understanding about RuleChain

Mengenal dasar RxSwift

Making Backward Compatible Adaptive Colors for Dark Mode in iOS

Automate Your Android App Bundle Publishing using Jenkins

No Comment

Leave a Reply