Entry Web

JavaScriptフリーのフロントエンド

2019-03-16

author:

JavaScriptフリーのフロントエンド

Matt Reyer      
リードエンジニアおよびデザイナー、新製品の開発。シミュレーションとビジュアライゼーション、リアルタイムグラフィック、データ指向設計、双方向性、そして思いもよらないユーザーエクスペリエンスの作成に興味があります。

シリーズ 「Slimvoice – JavaScriptを使わないWebアプリ」

「Slimvoice – JavaScriptを使わないWebアプリ」は、私ができる限りJavaScriptを使用せずに、Slimvoiceというアプリを改造した方法を綴ったシリーズです。このシリーズにJavaScriptのタグ付けをすることで、JavaScriptの代替案を提示し、すべてのプロジェクトについて再考するためSPA(シングルページアプリケーション)を追い求める人々を奨励します。


はじめに

私は2014年にNode.jsバックエンドとMongoDBを使用し(当時は大流行でした)、Angular 1でSlimvoiceの最初のバージョンを作りました。2015年にはユーザーインタフェースに大幅な改良を施し、Reactで再設計・再構築することにしました。今振り返ってみると、すべてたいした物でもありませんが…。その新しいバージョンでは、コードの複雑さを大幅に減らし、信頼性を最大限に高め、そしてエンドユーザーのコストを最小限に抑えながら、優れたデザインで素晴らしいユーザー体験を実現できる、ということを証明したいと思っていました。私は本当に誇りに思えるフロントエンドを手に入れたのです。ここでは、フロントエンドで行った決定を分析し、その過程で学んだJavaScriptフリーのユーザーインタフェース作成の秘訣をいくつかご紹介しましょう。

シングルページアプリケーション

Webサイトの膨張問題は、Web全体としては全く改善されていません。そんなに信頼性も高くない、ロードの遅いWebアプリにはうんざりです。最近、誰かAsana(注:プロジェクト管理ツール)のカードの説明を修正したんでしょうか?ひどく遅くなっているんですが!入力とユーザーインタフェースへの反映に、訳もなくタイムラグが発生します。まず第一に、私はインターネット接続が毎秒2メガビットしかない農村地域に住んでいます。ウォーミングされたキャッシュでは、Asanaのユーザーインタフェースが使用可能になるまで14秒かかります。第二に、下図を見ると、アプリが10MBを超える非圧縮のJavaScriptで構成されていることがわかります。実行されるコードは莫大な量になりますね。果たしてこんな物を容認できるでしょうか?

それ程複雑でない「プログレッシブWebアプリ」を使用するには、それを動かすためのチームが必要になります。結果としてコードベースの大部分が、フロントエンド専用になってしまいます。冗談じゃありません。私たちが次から次とソフトウェアを投げつけている中(Redux and friends 参照)、それを正しい順序でロードしていくのは難しいことです。もし仮に、そのすべてを取り除けばどうなるでしょうか。コードが長ければ長いほど、速度は低下します。コードは大事なものではなく負債、まるでタールのようなものです。JavaScriptライブラリはどんどん大きくなっており、その実際の必要性について、批判的に見ている人はそう多くないように思います。人々はJavaScriptを単なるダウンロードコストであるかのように、よくキロバイトやメガバイトで測定しますが、それは間違いです。CPUが解析・実行するまで待たなくてはいけません。

さあご安心を!よく聞いてください。私がフロントエンド開発について発見した秘密を共有しましょう。これを知っている人は殆どいないので、むやみやたらと口外してはいけませんよ。JavaScriptを使用していない場合、フロントエンドは決してクラッシュしません。これはHTMLも例外ではありません。少ないコードというのは常に良いものなのです。

だけど、Elmはとても素晴らしいものだから感謝を表しておくように…。

旧世代のプレーンHTML・CSS

私はSlimvoiceでは、現代のJavaScript誇大広告の性質に逆らって、アプリを完全にサーバーレンダリングにしたいと思っていました。皆さんは、「ああ、でもMatt!君のアプリを使用するとき、ユーザーはすべてのページをリロードしないといけないから、速度が遅くなるじゃないか!」と言うでしょうか。いやいや、馬鹿言っちゃいけません。大事なものはすべてgzipに圧縮しキャッシュしてあるので、やり取りの際に転送されるのはHTMLだけです。ロード中に表示される、くるくる回るスピナーなんてものはありません。私が使っている多くのプログレッシブWebアプリよりも、確実に速いのです。これを言葉どおりに受け取らないで、開発ツールのネットワークパネルを開いて、Slimvoiceといくつか人気のあるプログレッシブWebアプリとを比べてみてください。ああそうだ、私はコンソールでデバッグするためのJavaScriptの例外は持っていませんので。まあ、いずれにしてもページが画面に表示されるか、表示されないかのどちらかでしょう。

チェックボックス・ラベルの小技

もちろん、ページをリロードできなくなるような干渉というのもいくつか存在します。ここで、静的なHTMLページにインタラクティブ機能を追加するための、とっておきの小技を紹介しましょう。Slimvoiceのすべてのドロップダウン、モーダルウィンドウ、そしてフィルタリングユーザーインタフェースにこれを使っています。当然、JavaScriptはなしで。

  1. 表示または非表示にしたいユーザーインタフェースを含んだ、<div id = “myToggledUI”>タグを作ります。
  2. そのすぐ上に、<input type = “checkbox” id = “myToggle” style = “display:none;”>タグを作ります。これにより、DOMに見えないチェックボックスが現れます。
  3. トグルスイッチとして使用する任意のDOMのノードを、<label for = “myToggle”> </label>タグで囲みます。for属性がチェックボックスのidと一致するようにします。
  4. それらすべてを繋げるために、こちらのCSSを使用します。
#myToggledUI {
    display: none;
}
#myToggle:checked ~ #myToggledUI {
    display: block;
}

このCSSは、チェックされた#myToggle要素の直前にある#myToggledUI要素の表示・非表示を指定します。~演算子は最高ですね!実際の動作例を挙げましょう。

これは<label>タグ、<div>タグ、それにチェックボックスから成るモーダルウィンドウです。「キャンセル」ボタンは同じチェックボックスの別の<label>タグなので、クリックするとモーダルウィンドウが閉じます。モーダルウィンドウの後ろにグレーのオーバーレイ(position:fixed;)があり、これも同じチェックボックスの<label>タグになっているので、モーダルウィンドウの外をクリックしても閉じます。Reactコンポーネントも、クリックイベントリスナーも無い、単純明快なHTMLです。

No JavaScript!

ここではしていませんが、この小技にお好きなCSSのトランジションを追加することも可能です。ReactCSSTransitionGroupは必要ありません。

No JavaScript!

<details>要素・<summary>要素

Slimvoiceで使用する様々なオープンソースソフトウェアのライセンスをAcknowledgementページで表示・非表示するために使用しました。早くて簡単、JavaScriptは不要で、どこでも動作します。

見た目の大部分をコントロールできないのは残念ですが、あなたのブランド規格に合った小さな三角の閉じるボタンを作ることが、ユーザーにJavaScriptによる数メガバイトの負担を強制する価値があるとは思えません。

フォームと入力の検証

多くの入力には検証オプションが組み込まれています。Mozillaのドキュメントは包括的です。

  • 特定のフィールドに入力するまでフォームが送信されないようにする、required属性を忘れないこと。
  • 数値入力には、min、max、stepがあります。
  • テキスト入力は、emailまたはカスタムのpatternになります。
  • テキスト入力には、minlength、maxlengthがあります。
  • CSSセレクタ、:validと :invalidは、より良いユーザー体験を可能にします。
No JavaScript!

ますますシンプルに

本当を言うと、新しいSlimvoice中にはJavaScriptを少し使用した箇所がありますが、それは干渉が他の方法で複製できなかった場合だけです。例えば、クライアントリストにファジー検索を実装して、クライアントを簡単にフィルタリングできるようにしました。プロダクションコードを見てください(私のサーバーはホットリンクを防ごうとするので、新しいタブでURLをコピー・ペーストする必要がある場合もあります)。何も複雑なことはありません。

私は請求書の品目をドラッグ&ドロップで仕分けできるようにすることが重要だと考えたので、請求書編集のユーザーインタフェースにのみMithrilを採用しました。これがプロジェクト全体(そして単一のページでのみ)で唯一、JavaScriptに頼った箇所です。そのうち時間があれば、これも完全に削除したいと思っています。このアプリにはJavaScriptが殆ど使われていないので圧縮しても何も変わらず、そのためもう圧縮はしていません。私のソースコードを是非読んでみてください。

将来の展望

プレーンHTMLの入力は私のニーズのほとんどをカバーしていましたが、もっと多くの入力をカバーしてJavaScriptの必要性を完全に排除するため、私はHTMLの仕様の更なる革新を望んでいました。

  1. クライアント側でリストをフィルタリングする標準的な検索要素が無いのはなぜでしょうか?(ng-repeat | filter: がAngular 1で機能したのと同じように)
  2. ドラッグ&ドロップによる仕分けのための標準的なHTML要素は素晴らしいものではないでしょうか?
  3. 2つの異なるフォームフィールドの同等性を比較する等の、より高度な検証機能。
  4. ハッキングしているように感じたり、奇妙なCSSを書いているように感じたりすることなく、モーダル・チェックボックスの小技を使う能力。

HTML仕様のユーザーインタフェースオプションが停滞し、カスタムのJavaScriptで動く要素を構築するために残されているのはなぜでしょうか?より堅牢な、標準的なユーザーインタフェース要素を持つことは、WebVR、WebBluetooth、また近頃作られている他のどんな愚行の産物よりもはるかに重要であると思います。

結論

果たして、上手くいくんでしょうか?ええ、もちろんです。最大ページのフルリロードは、インターネット上で230キロバイトです。私はすべてをキャッシュしてgzipに圧縮しているので、その後の各ページビューは約6キロバイト、今まで目にした、同等の機能を持ったシングルページアプリケーションよりもはるかに小さいものです。Slimvoiceは速くて小さいですが、ユーザー体験では妥協しません。ユーザーはこれまでのところ大変気に入ってくれています。https://slimvoice.coから、あなた自身でご覧になってください。

私のコードに複雑な点は何一つありません。何の説明もなしに、コードベース全部を他人に渡しても問題ないでしょう。React / Webpackフロントエンドについて現実的なことを言える人を、私は一人も知りません。

私は10年以上前からプログラミングを続けており、うち6年間はフルタイムでWebアプリ開発をしていました。その頃の経験から、JavaScriptとプログレッシブWebアプリにはそれ程大きな利点は無いと分かりました。一方、それらの欠点は非常に大きく、そして多くの場合無視されています。私はJavaScriptを、近い将来の主要言語とは見ていません。

  • おそらく「プログレッシブWebアプリ」は必要ないでしょう。もしあなたのアプリがその様な複雑さを必要としているなら、一度真剣に評価することです。上司やクライアントは、格好良く人気のあるプログレッシブWebアプリを要求して、曖昧な理由をとやかくつけて来るかもしれません。その理由が正当であることを確かめてください。
  • 人の後追いはやめることです。あなたに代わる他者がそうすることも許してはいけません。あなたはGoogle Analyticsなしで生き残ることができるでしょう。Intercomなしでも大丈夫。すべて自分のドメインで何とかなります。
  • 恐れてはいけません。自分自身で作り出すことができます、フレームワークなど必要ありません!
  • 誇大広告に惑わされてはいけません。マーケティングページに書かれていることや、他の皆がしていることに関わらず、あるアプローチが別のアプローチよりも優れている理由について批判的な目で決定をするのです。クールで新しいものを販売している人々は、その欠点を隠しているものです。すべてにおいて、費用は掛かるものなのです。

Slimvoiceのこのバージョンがもたらした結果について、私はこの上なく満足していますが、もちろんJavaScriptの使用をゼロにする方法を探しています。設計や開発経験に関する質問には、喜んでお答えします。

最後に、スプラッシュページをデザインし、ユーザーインタフェースのことで手伝ってくれ、そして私にこの記事を書くよう勧めてくれた、素晴らしい妻に感謝したいと思います!

次回:Slimvoiceバックエンドについて、それが長年に渡ってどの様な進化を遂げてきたか、そしてサーバーレンダリングされたアプリの開発プロセスを可能な限り簡単にするために私がやったことに関して、詳細をお話しします。

この記事は、著者の許可を得て翻訳しています。なお、原文はこちらです。