フロントエンドにおけるインデント記法のすゝめ
こんにちは、Gaji-Labo の森田です。
この記事は Gaji-Labo Advent Calendar 201516日目の記事です。
先月より、Adobe Creative Stationにて「現場で役立つ実践Sass」の連載をスタートしました。是非、超お暇な時にでもお読みください。
さて、宣伝から入りましたが、その中でSASS記法について触れており、こう書きました。
私は、CSSはSassのSASS記法で、HTMLはSlimで、JavaScriptはCoffeeScriptで。と全てインデント記法で書いております。
https://blogs.adobe.com/japan/web-practical-sass-01-dev-environment/
Ruby on Railsプロジェクトのフロントエンド開発を多く担当している弊社は、Railsのアセットパイプラインを使いSASS記法(以下SASS)、Slim、CoffeeScriptで開発することが必然的に多くなりました。
なので、このインデント記法は私というよりもGaji-Laboのフロントエンドの書き方であります。(Gaji-Laboのお客さまの書き方とも言える)
元々SCSS記法で書いていた私も、Gaji-Laboにジョインしてからその様になりました。
上記の記法は、Railsに関係なくコンパイルできる環境があれば使うことができます。
gulpやGrunt、CodekitなどのGUIコンパイラーを使えば簡単に使用することができるでしょう。
Adobeブログでも書いたのですが、インデント記法を推してはいますが、インデントしない記法をdisしているものではございません。悪しからずご了承ください。
どちらの記法が正しい・速いというわけではありません。好みです。
https://blogs.adobe.com/japan/web-practical-sass-01-dev-environment/
もしかしたら、私のように SASS記法がしっくりくるかもしれません。
フロントエンドによるインデント記法のメリット・デメリット
メリットは記述量が減る。これにつきます。
スピートアップよりも、楽だと感じます。
デメリットは、コンパイルできる環境構築が必要です。
また、納品後どうするかはコンパイル言語の永遠の課題と言えます。
そして、インデントをタブかスペースで書くか、宗教的な問題がまれに起こります。
この問題については .editorconfig でルールを共通化するといいでしょう。
では、SASS、Slim、CoffeeScript の各言語のメリット・デメリットを簡単にですが、考えてみました。
SASSのメリット・デメリット
(SASS例文 – 公式サイトより抜粋)
#main
color: blue
font-size: 0.3em
a
font:
weight: bold
family: serif
&:hover
background-color: #eee
=large-text
font:
family: Arial
size: 20px
weight: bold
color: #ff0000
h1
+large-text
SASS記法のメリットはセミコロン、波括弧がいらないので、閉じ波括弧も無くなり行数が減ります。SCSSであった入れ子が多くて閉じタグが分からなくなる様なことは無くなります。
@mixinが「=
」、@includeが「+
」で書けるのが地味に楽です。でもなぜか@extendはそのままです。
これはメリットともデメリットとも言えるのですが、書き方が厳密になります。
例えばコロンと値の間に半角スペースが必須で、一つでもスペースがないとコンパイルエラーになります。SCSS と比べると相当キッチリ書かないといけないです。
デメリットとしては、CSS からコピーしてきても互換性が無いのでセミコロンなどを消す必要があります。
また、変数は1行に書かないといけないので、配列が書きづらいです。
このあたりが地味に不便です。
そして、なんと言っても SCSS が圧倒的多数派ですので、SASS記法に対応していないツールも多いです。
Sublime Text のスニペットなどは SCSS しかなかったので自作しました。
Slimのメリット・デメリット
(Slim例文 – 公式サイトより抜粋)
doctype html
html
head
title Slim Examples
meta name="keywords" content="template language"
meta name="author" content=author
javascript:
alert('Slim supports embedded javascript!')
body
h1 Markup examples
#content
p This example shows you how a basic Slim file looks like.
== yield
- unless items.empty?
table
- items.each do |item|
tr
td.name = item.name
td.price = item.price
- else
p
| No items found. Please add some inventory.
Thank you!
div id="footer"
= render 'footer'
| Copyright © #{year} #{author}
メリットは何と言っても SASS 記法と同じ様に html が書けることです。
マークアップをそのままコピーしてコーディングができます。
また、変数やループなども使えます。
Rails の HTML テンプレートエンジン「ERB」や「Haml」と比べるとコンパイルも速いです。
デメリットは慣れないと、とても見づらいです。
brが必要なテキストを書く際に、要素にパイプ |
をつけるのも面倒です。
同じインデント記法で、Jade というさらに色々できるテンプレートエンジンもあります。
CoffeeScriptのメリット・デメリット
(CoffeeScript例文 – 公式サイトより抜粋)
# Assignment:
number = 42
opposite = true
#Conditions:
number = -42 if opposite
#Functions:
square = (x) -> x * x
#Arrays:
list = [1, 2, 3, 4, 5]
#Objects:
math = root: Math.sqrt square: square cube: (x) -> x * square x Splats: race = (winner, runners...) -> print winner, runners
#Existence:
alert "I knew it!" if elvis?
#Array comprehensions:
cubes = (math.cube num for num in list)
メリットはfunctionを ->
で書けたり、varを付けてくれたり、if文を簡単に書けたり(三項演算子は逆に面倒)と、私の様な記述ミスをしまくる人間をとても助けてくれます。
また、クラスや、ファットアロー =>
というECMAScript 6(ECMAScript 2015)を先行した便利な機能もあります。
デメリットは将来性の無さです。
巷では CoffeeScript は、オワコンと言われています。。
こちらの記事「さよなら CoffeeScript」にわかりやすく書かれています。
とはいえ、すぐに無くなるものではないので当分は使うと思いますが。
まとめ
プロジェクトや環境によってインデント記法に向き/不向きはあるかもしれませんが、もし時間があったら、試してみてください。
私のようにしっくりくるかもしれません。