←back

最強のhtml納品環境を考える(2022年版)

2022/10/04

GPAWにおける成果物のパターン

  1. デザインのみ(figmaとかのお渡し)
  2. デザイン+マークアップ(HTML+CSS+JS)
  3. デザイン+FE開発

この記事では2について考えます。

わたしのお気持ち

まずデザイン+マークアップでの納品自体はなるべくやりたくないスタンスです。(詳しくはこの記事)

エンジニアの工数は中間生成物ではなく、保守運用まで含めた最終成果物に使うべきでは？と考えているからです。

とはいえGPAWはクライアントワークを請けるデザイン会社です。

運用や開発体制の主導権はクライアントにあるのでデザインの付属物として、マークアップを求められるケースはまだまだ多くあって、2022年の自分なら「どんな環境環境」で「どんな成果物」を提供するか考えていきます。

わたしのおすすめ構成と、その考え方

TL;DR

Pug+Sass+Typescriptを基本構成にすると思います。

もっとマークアップに求められる要件が複雑なら、NextjsのSSGモードを使うと思います。

Why Nextjs ?

SPAやら、状態管理やら、静的ページ内にバックエンドのリソースをmockレベルでも出し分けたいやら、といった要件が追加になったら、Nextjsを考えます。

状態管理や動的要素が増える場合、HTML内にも型を効かせない気持ちが強くあるのと、パートナーのバックエンドのSchemaをある程度フロント環境にも流用したいからです。

  • schemaが開発段階で流用できていると、マークアップ実装時にデザイナーやパートナーが気づけなかった抜け漏れを拾う見込みが出ます。
    • e.g. 最大文字数とか

ただ、単純なHTMLのみを求められている場合、Nextjsや他のSSG機能を含んだフレームワークを使うと、吐き出されるHTMLのコントロールが難しくなります。いわゆるFragmentが実装されているとはいえ、Componentの実装にかなり気を使わないと、綺麗なHTMLをはかせ続けるのが難しいためです。

パートナーでvercelを導入していい了解が取れれば、検証環境のdeployも非常に楽です。

react系？vue系じゃだめなの？

vueでSSGしようとすると、vue3のままでやるなら、webpack(or vite)をこねないといけないです。

vueコミュニティにおけるnextjsポジションであるnuxtは新version(3)でSSGはまだbetaぽいです。

gridsomeは要件をみたしますが、日本での導入事例が少ない印象なので、外しました。

Why Pug

  • コンポーネント単位でHTMLを管理したい
  • HMRできる
  • lintは効かせたい
  • 素のHTMLで書ける
    • 省略記法は脳内での変換コストがかかるからいや
    • 閉じタグが省略できるからなんだというのだ。というお気持ち。むしろインデント１つで簡単に壊れるようになるので危険が増すと思ってる。
    • railsとかでslim書いてたエンジニアが触るならまだしも、学習コストがかかる

Why Sass

  • lintやpluginが枯れているので安定?の印象
    • というより他に選択肢がない
    • utility系使っていいなら、tailwindがいいと思う
  • @useの登場で無秩序なimportとglobal参照がなくなった
  • prefix/suffixをまとめて付与できる
  • minifyしない選択肢がある

CSSアーキテクチャは？

  • profect名のprefix+BEM+SMACSS
    • prefix+BEM記法
      • e.g. gpaw__header__menu—-active
      • とにかく分離したいのでprefixはつける。
        • 分離されてれば、捨てやすい。。はず。
      • 書く際につけるんじゃなくて、sass-loaderとか噛ませて、出力する際に機械的に付与する
    • ディレクトリはSMACSS
      • BEMのBlock≒SMACSSのModule
  • 複合ルールではあるものの、極力変形させない
    • 変形するとオレオレルールになるので、チーム内の学習コストがかかる。
      • e.g. reactとかの場合、基本的に公式のcliがあるので、そこをベースに環境つくる。的な。
    • CSSに限らず一般に広く普及している概念を大事にする
    • オレオレしたい場合、linterとかで機械的にコントロールできるようにする

Why Typescript

  • マークアップだとutilちょっと書くくらいにしか使わなそうではあるけど、素のJavascript書くくらいなら、tsで書きたい。
    • 画像の最適化とか、コンテンツのprefetchとかを自前でやりたければ、tsが比較的楽。
  • vanilla→tsはよく見る。逆を手作業は見ない。
    • ts→vanillaはbabelがやってるので。。
      • Pug、Sassを入れてるならWebpackとかが入ってる環境なはずなので、成果物の吐き出し口をまとめたい気持ち
    • フロントエンドはテスト書く文化も薄いので、型のあるなしで、まず読みやすさに大きな差がでると思ってます。

How about jQuery ?

  • 単純なdom操作をしたいだけなら、全然最有力だと思ってます。
  • 状態管理や仮想domの概念が入ってくる要件なら、不要。むしろリスクがあって怖い。
  • テストとの相性がとても悪い点、linterによる補助が弱い点で、tsが選べるならtsがいいな。ってお気持ち。
    • パートナーによってはTSかけませんが、往々にしてあるので、jQueryから逃げづらい。

成果物はどうあるべきか

どうありたいか

  • 開発の成果物は基本的に、gitにあればよいスタンス
    • パートナーに用意してもらったrepository上で作業するのが、進捗も見えるし、パートナーのエンジニアに引き継ぎやすいし、メリットが多い。
  • 本当は納品物という形にしたくないお気持ち

とはいえ「納品」しないといけない

Pug+Scss+Typescriptは全て変換される

  • webpackなどをかませて、それぞれ素のHTML+CSS+Javascriptに変換される
    • 素の状態なら、吐き出したdirectoryを丸ごとサーバーにおけば済む。
      • ほんとにどこでもよくなるので、zip渡して、お客さんの環境でブラウザで開いてみて。とかもできる。
    • ts→jsのみリーダブルかどうか微妙なのは悩ましいポイント
    • npm run xxxのコマンド１つで完結させたい
      • 手順書的なdocは書くの辛いですし、少ないにこしたことない

未来の話

GPAWはfigmaでデザイン出してるので、デザインからマークアップができれば素敵なんじゃないですかね (雑)

すでにいくらか実現してます↓

←back