メドピア開発者ブログスマートフォン用の表示で見るメドピア開発者ブログ集合知により医療を再発明しようと邁進しているヘルステックリーディングカンパニーのエンジニアブログです。Tumblr10km40分切りが2020年の目標、メドピア長距離部の小宮山です。CSSはご存知でしょうか。tailwindとは「追い風」を意味します。最高に気持ちよく走れるコンディションですね。CSSがもたらしたものまとめサービス概要まずは今回新たに立ち上げたサービスの紹介です。「MedPeerスポット×リクルートメディカルキャリア」という医師向けスポット求人マッチングサービス(以下、本サービス)が11月にリリースされました。medpeer.co.jpログインや応募などサービスのコアな部分はMedPeer医師会員限定になってしまいますが、サイトの雰囲気自体は非会員でも十分に味わえますので是非ともサイトを開いてみてください。医師向けスポット求人という普段なかなか見ることができない世界を覗くこともできます。本サービスの技術的な構成をざっと紹介していきたいと思います。Rails(以下、Rails)です。最新ほやほやの6.0です。自分はフロントエンド畑な人間でそれほどRailsに精通しているわけでもなくそのすごさをちゃんとは理解していませんが、きっとすごいことなんだと思います。以前のMedPeerなら、「Railsを使っています、以上です。」で終わってしまっていたところですが、なんと今回はもうひとつ目玉技術があります。Nuxt.js(以下、Nuxt)です。ja.nuxtjs.org実はNuxtの利用自体はMedPeerでは初めてではありませんでした。静的サイトのジェネレータとしてシンプルなLPを作成した実績はすでにあります。かかりつけ薬局化支援サービス「kakari」のLPがまさにそれにあたります。kakari.medpeer.jpではなぜ再度Nuxtを強調し直すのか。なんと今回は、Nuxtを本番運用してSSR(サーバーサイドレンダリング)するというMedPeer初の挑戦だったのです。バックエンド(Rails)とフロントエンド(Nuxt)をリポジトリもAWSリソースも分離してしまうというMedPeer初だらけの野心的な技術構成となっていました。非常に申し訳ないのですが、今回伝えたいのはNuxtのことでもフロントエンド分離のことでもありません。開発プロセスやVue.jsの話題ですらありません。CSSのことを伝えたいモチベーションが高すぎました。新大陸の大地そのものよりも、そこに吹いていた追い風にこの心を掴まれてしまったのです。CSSとは何かtailwindとはずばり「追い風」を意味します。今日の走りは絶好調だと思ったら折返しで現実に引き戻されるやつですね。公式サイトの文言をここに引用します。override.一応CSSフレームワークという分類になりそうですが、BootstrapやVuetifyといった所謂一般的なCSSフレームワークとはやや毛色が異なります。CSSが提供してくれるのはスタイルを便利に指定するためのツール類だけです。CSSでは用意されたツールを組み合わせてダイアログというコンポーネントを自力で作らなければいけません。CSSが提供してくれるのは自動車本体ではなく、その名前が意味する通り、自力で走る者たちへの追い風です。HTMLとCSSWebページを構成する3要素といえば、HTML・CSS・JavaScriptです。HTMLはWebページの構造を、CSSはレイアウトや装飾を、JavaScriptは何かをしてくれます。(今回はJavaScriptについてはあまり掘り下げません。)ja.wikipedia.org文書の構造と体裁を分離させるという理念を実現する為に提唱されたスタイルシートの、具体的な仕様の一つ。令和を生きる私はCSSが登場したころの状況を実際には知らないのですが、どうやらCSSはHTMLからスタイルを分離させることを目的に生み出されたもののようです。実際に、文章構造とスタイルやHTMLとCSSそれぞれに切り出して役割分担させるのがWebの作法だという認識が広く広まっていたと思います。}なんの変哲もない例を出すとこんな感じでしょうか。HTML側ではタグにclassを付け、CSS側ではそのclassをセレクタとしてスタイルを付与しています。一方でこんなHTMLはどうでしょうか。2</li></ul>スタイルをCSSに分離することなく、タグにそのまま書き込んでいます。所謂インラインスタイルです。基本的に、インラインスタイルが歓迎されることはほとんどないと思われます。実際に私もこのコードだけを見たらレビューコメントを入れる手を止めることはできないでしょう。歓迎されないのでしょうか?実のところ「そういうもの」で終わらせてしまうことが多く、あまり深く考えたことはありませんでした。実際にCSSは誕生目的からして「そういうもの」なのですが、改めてその問題点をざっと考えてみました。HTMLが冗長になるclass指定が不要とはいえ、styleで書き込むので文字数の絶対量は増えてしまいます。スタイルの共通化ができないタグ毎にstyleを書き込むしか無いので、リストアイテムなどには大量に同じstyle属性を書き込まないといけません。HTML冗長化をさらに後押しします。CSS関連のエコシステム(Sass、PostCSS、Stylelintなど)が使えない最近のフロントエンド開発ではこれが相当のデメリットではないでしょうか。(もしかしたらインラインスタイルにもいい感じに変換やlintを当ててくれる仕組みがあるかもしれません。)レスポンシブ対応が難しい若干思いつきベースですが、インラインスタイルでレスポンシブなスタイルって作れるんでしょうか?やるなら下記のようになりそうですが、試そうと思ったこともなさすぎて効くのかどうかは未検証です。</ul>HTMLとCSSとコンポーネント時代は変わりつつあります。変わってしまっているのかもしれません。その変化の主役となる存在がコンポーネントです。HTMLとCSSは文章構造とスタイルという役割で分離するのが当たり前だったのに、コンポーネントという新たな区切がより重視されるようになってきています。従来のWebページ構成コンポーネント指向なWebページ構成その1コンポーネント指向がもたらす大きなメリットは、コンポーネントという明確な区切りが生まれることです。今までのHTML・CSS・JavaScriptという3層では、互いに分離されてはいるものの、その層内はほぼグローバル空間と化していました。良く言えば自由で手軽に作れてすぐに変更可能、悪く言えば分かりにくく壊れやすくて変化に弱い。コンポーネントという区切りは、この3層のより上位の区切りとしてWebページのグローバル空間を分割します。コンポーネント内でHTML・CSS・JavaScriptの3層が存在するようなイメージです。双方ともにメリットとデメリットは様々にありますが、今のフロントエンド界隈はコンポーネント指向が勢い付いていると見て間違いないでしょう。シンプルに考えると、Webページがコンポーネントによってまず区切られ、コンポーネント内部では従来の3層区切りがそのまま再現されているだけです。確かにコンポーネントが注目されだした当初はそうだったかもしれません。変化はそこで留まってはくれませんでした。コンポーネントという閉じた安全な世界が作られたことで、その内部ではかつて常識と考えられていた壁の存在感が薄れだしました。コンポーネント指向なWebページ構成その2コンポーネントとして完結していて、外部との連携で求められるインタフェースが満たされてさえいれば、コンポーネント内部の実装が多少暴れん坊になっていても大した問題にはなりません。いや問題ではあるんですが、コンポーネント内部はいわばprivateな部分なので大した問題ではないことがほとんどです。コンポーネントという区切りが明確に存在しているので、どうしようもなくなったら丸ごと取り替えてしまうことだって可能です。してコンポーネントの躍進により、HTMLとCSSの境界は薄れだしました。完全になくなったわけではありませんが、CSSが生まれた目的そのものであったHTMLとスタイルの分離は、コンポーネントというより大きな関心事にかき消されつつあります。コンポーネントと雑なセレクタコンポーネントという概念によってHTMLとCSSの間にあった従来の区切りは曖昧になり、両者の距離はぐっと近づいています。区分けされた両者を繋ぐために必須だったclassを軽視する、こんな手抜きスタイル指定も横行しているのではないでしょうか。}階層を指定しているとはいえ、セレクタとしてliを直で指定しています。従来のHTML・CSS分離の方針に従うなら真っ先にレビュー指摘が入りそうなコードです。実際に私もこんなコードを素の状況で見つけたらおそらく指摘を入れます。このコードがコンポーネントに関するものであれば話は別で、CSSにHTMLの構造が漏れ出していてもそれほど気にしません。1つはスタイルがコンポーネント内に閉じているからです。liという豪快なセレクタ指定がされていようと、そのセレクタがコンポーネント内のHTMLに限定されているのなら、コンポーネント外の予期せぬ箇所でスタイルが崩れることはありません。(セレクタのパフォーマンス観点については今回は立ち入りません。)もう1つは、classを丁寧に付けるほうがむしろコストが高くなるかもしれないからです。classを増やせば当然HTMLの文字数は増えて汚れます。適切なclass名を文書構造と翻訳サイトを往復しながら考えなくてはなりません。HTMLとCSS間の視点移動だって必要です。単発では小さな手間かもしれませんが、それを数百数千回と繰り返すのはとても面倒くさいのです。早く家に帰って走りたいんです。コンポーネントとインラインスタイルコンポーネントという箱庭の存在によって、雑なセレクタが許されるようになってきたとしましょう。エンジニアというのはどこまでも怠惰を求める生き物らしいです。一度雑になったセレクタ指定はどこまでも雑になっていきます。雑になればなるほどHTMLとCSSは近づいていきます。行き着く先に何があるかというと、インラインスタイルの再登場です。2</li></ul>コンポーネント指向という前提に立ち、改めて先に挙げたインラインスタイルのデメリットを再評価してみます。HTMLが冗長になる基本的には従来と同様だと思います。スタイルの共通化ができないコンポーネント単位での共通化という大きな道が開けます。利用するフレームワーク依存となりますが、v-forやjsxなどで効率的に記述する手段も多くあります。CSS関連のエコシステム(Sass、PostCSS、Stylelintなど)が使えない基本的には従来と同様だと思います。レスポンシブ対応が難しいコンポーネントごと表示を切り替えるなどの手段が生まれてきそうですが、ほぼ従来と同様と思われます。JSなどのJavaScript側からのアプローチによって解決は可能かもしれません。CSSばかり使っているのでこのあたりの動向には疎いです。)場面によってはインラインスタイルで済ませてしまうことも十分に可能ですが、大勢をそれだけでなんとかするのはやはり厳しい印象です。CSS系のエコシステムとの相性と、レスポンシブ対応のやりにくさは致命的です。インラインでベンダープレフィックスを付けていく作業以上の苦痛はなかなか見つからないと思います。人生は短いし早く帰って走りたいんです。CSSの話題にたどり着きました。CSSで書くとこうなります。2</li></ul>ご理解いただけたでしょうか。CSSの良さへと至る道筋です。CSSはスタイルとほぼ1対1に対応したclassを提供してくれます(一部複合的なスタイル付きclassがあったり、独自で拡張することも可能です)。実質class方式でスタイルを指定しているだけなので、autoprefixerやpurgecssなどとの連携が容易です。lg:)が用意されているので、レスポンシブ対応に苦慮する必要もありません。PCサイズ以上でだけ横並びにしたい場合はこう書けます。インラインスタイルの良さを残しつつ悪さを緩和する、絶妙な具合ではないでしょうか。2</li></ul>HTMLが冗長になるという点に関しては、インラインスタイルよりは改善されているものの、class形式でスタイルを当てていくときほどには軽量にならないです。スタイルとclassがほぼ1対1になっているので、この点は受け入れるしかないというのが現時点の評価です。CSSは決して強力なCSSフレームワークではありません。フレームワークと呼んで良いのか怪しいくらいに具体的なものは何も提供してくれません。公式サイトに掲げられている通り、utility-firstなツールを提供してくれるだけです。ツールをどう使うか、何を作るかは完全に使い手に委ねられています。そこに心地よさを感じかどうか個々人で評価が分かれるかもしれません。CSSを使い続けた私の感想としては、「次もまた使いたい」し「発展に貢献したい」です。その理由を端的に表現するのはとても難しいです。具体的にこれが良いと言い切れるようなものではなく、この記事で述べてきたように、Webフロントエンドの潮流の中で味わう様々な要因が組み合わさって到達した良さだからです。その良さを実感しているのは事実です。CSSの使い方自体はほとんど紹介できませんでしたが、最近は利用事例も増えて情報も多く出ているので探すのに困ることはないと思います。CSS利用事例として改めて記事化するかもしれません。CSSの巻き起こす追い風、みなさんも是非味わってみてください。՞)☝︎是非読者になってくださいメドピアでは一緒に働く仲間を募集しています。SREの侘美(たくみ)です。開発事例公開~こんにちは。サーバーサイドサウナーの川井田(@tamamushi_2)で...2019-07-04開発合宿に行ってきました!@松本メドピアのサーバーサイドサウナーの川井田です。エンジニアの宮原です。月別アーカイブリンク医師専用サイト「MedPeer」エンジニア採用はこちら!スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。