CSS BEMの記述を好きになれない理由
先に結論から言うと、自分は制作チームでの共通ルールは必要だと思っています。
ただ、BEM記述法が絶対に正解とは思わないし、実体として広まっているBEMルールは、なんだか好きになれない(嫌い)、という考えです。
以下、説明します。
目次
BEMを嫌いな理由
単純にコードが長すぎて見づらい
なんか、あんまり誰も突っ込まないんですけど、第一に主張したいのは、「BEM記述、普通に長すぎないっすか?」ということ。
HTMLコードはアホみたいに長くなるし、画面の幅を大きく占有するし、たかだかスタイル記述を書き換えるだけのことに、なんでこんな長い文字列がいるんだよ、と。
CSSも同様で、SASS使ってない人にとっては地獄でしかない。(まあSASSなしでBEMやろうとする人はいないと思うけど……。)
特定のエリア部分があった時、その最上位に「#top_mv_area」とかidで名前つけて、あとは階層化の「.btn」とか「.txt」とか「.video」とかclass指定すれば、要件としては事足りる。CSS側でもちゃんと階層つけて命名すれば、クラス名が他でバッティングする心配もなし。
なにが悲しくて、「.top_mv_area」⇒「.top_mv_area__btn」とか「.top_mv_area__txt」なんて二重に書かないといけないのだろう。タグ構造次第では、どんどん深い階層になって、すごく見づらくなる。微小ではあるけどファイル容量も増えるし、ロジカルシンキングのMECE観点からいっても美しくない。
もちろん、深い階層になるほどセレクタの数が減るから、ブラウザ実行時、レンダリングでのフォーマンス改善の意味はある。でも、最近は通信環境も整っているし、ウェブサイトの仕様にもよるけど、cssだけでいえば、そんなミリ秒ミリ秒にめちゃくちゃこだわるほど、クリティカルになることも少ないだろうし、HTMLとCSS側で管理する時にパッと見からしんどいほうが個人的にはキツイ。
BEM記述には必ずチーム独自のルールが付随しがち
「BEM書けます」って人が、他の会社だったり制作チームに入って、そのまま何も気をつけることなく記述できるかというと、そんなことはない。
ほぼほぼ必ず、それぞれの環境ごとに、BEMルールの中にオリジナルのルールがあったりして、結局はそれを覚える時間が必要になる。しかも、マニュアルや手順書の作り込みなんてあったもんじゃなく、「あ、こういう時はこうします。自分は」などと、いわゆる俺流ルールまで並立して存在していたりする。
さらに悪質なケースだと、緊急時や急ぎの時になると、ルールのことはおざなりになったり、外注にお願いして、ルールがめちゃくちゃになることもある。また、BEMを仕切っていた人が退職すれば、どんどんルールは劣化していくことも予想される。
ついでにいえば、BEMやる人がいれば、恐らくタスクランナーなどもセットになっているだろうから、そこの環境条件を揃えるのも面倒くさい。(同じ会社で常駐の人同士でやるなら良いけど、ある程度の外注が混合する場合だと、そこの調整だけで工数を削りそう。)
だったら、べつにBEMなしで、最初から独自のルールでスマートなの用意したほうが賢いんじゃないの、と自分は思ってしまう。
そもそもマークアップ正しくできてる?
これはBEM以前の話になってしまうけど、なんかフレームワークやツールに頼りがちな人って、きちんと基礎をやっていないから、色々と怪しいイメージがある。
アホみたいにdiv連打してたり、テキストはすべてpで済ませたり、imgのaltが空っぽだったり、他にも、けっこう信じられない記述をしている人も少なくない。
フロントエンド界隈は、記述法どうこうの前に、まずは正しい論理構造を共通認識させるように広めるべきだと思う。(自分もきちんと正しい理解をしたい……。)
もちろんきちんと制作・運用できているところはOK
BEMで美しく制作している人からすれば、自分の考えは「は? なにいってんの? ばかなの?」くらいの感じだと思います。
もちろん、きちんと制作が流れていて、BEMの書き方を確認するといった無駄な工数なく、スマートに制作できているなら、まったく問題ないです。ただ、実体として、そうなっていない場所については「なんだかなぁ?」と思いませんか、という話でした。
【参考】
・フロントエンドエンジニア – いろいろ考察2017年版 その壱
https://blog.ogaaaan.com/computer/web/suck-frontend-world-2017-01