私たちが現在武器庫に持っている道具はただのおとぎ話です！
Andrey Okonechnikov、15年の経験を持つ開発者のうち、10以上がユーザーインターフェイスに与えられたAndreyは、HolyJSでPostCSSとWebpackを使用してフロントエンド開発の問題を解決する方法を説明します。 Andreyの講演は「モジュラーCSS」と呼ばれ、JavaScriptとASTを使用して大規模プロジェクトでCSSを使用する方法に焦点を当てています。 レポートの主題に基づいて、フロントエンド開発者の作業とUI / UX接続の深さ、および大規模プロジェクトでのCSSの問題と将来について理解できるように、Andreyにいくつかの質問をしました。
現代のフロントエンドの主な問題はスローダウンです
-UIデザイナーと開発者は2人だけでなく、特に大規模なプロジェクトでは、ほとんどコミュニケーションが取れないという事実に多くの人が慣れています。 あなたの意見では、そのような不一致がもたらす結果は何ですか？
-2007年、私は最初のRITでレポート「Profession Frontend-architect：who is this？」で話しました。そこで、この問題が発生しました。 ほぼ10年が経ち、状況はそれほど変わっていないのは面白いです。 開発者とデザイナーは快適な領域を離れないようにします。ドリブルに美しい「インターフェース」を投稿する人もいれば、新しいテクノロジーを使用して毎月フロントエンドを書き換える人もいます。 結果は通常非常に悲しいです。 インターネットには、不便で疑わしい品質のサイトやWebアプリケーションがたくさんあります。
-あなたの意見では、現代のフロントエンドの主な問題は何ですか？ これらの問題のうち、エンドユーザーに最も影響するのはどれだと思いますか？
-速度、またはむしろ抑制。 読み込みが遅いこと、特にモバイルデバイスで顕著であるため、ユーザーは読み込みを待つことなくサイトを離れます。 また、SPA（シングルページアプリケーション）の人気は状況を改善しません。ほとんどのWebアプリケーションは、少なくとも何かを表示する前に最初に巨大なJSファイルをダウンロードします。 まだ、カスタムフォントの読み込みを正しく行う人はほとんどいません。 したがって、近い将来、モバイルユーザー向けの最適化と、アセンブリおよび分析用ツールの改善に大きな重点が置かれると思います。
- レポートはPostCSSとWebpackに焦点を当てています。 なぜ正確にそれらですか？ なぜSASSではないのですか？
-私のレポートは、特定のタスクに適したツールを選択することに関するものです。 私の意見では、PostCSSとWebpackは、他のツールでは解決できない、または不十分にしか解決できない問題をこのコンテキストで解決します。 これは、SASSが悪いことを意味するものではありません。 私が話している問題を解決するだけでは、あまり適していません。
ボックス化されたソリューションは、ボックス化されたタスクに適しています
「ツールキットの地獄の問題についてどう思いますか？」 cssのポストプロセッサ、個別のテンプレートエンジン、このオーバーヘッドはすべて最終結果に影響しますか？ 特定のツールセットを使用すると技術的なパフォーマンスが競合する開発プロセス中に機能が破棄されることはありませんか？
-私は15年以上ウェブ開発に携わっており、私の意見では、私たちが現在武器庫に持っているツールは単なるおとぎ話です！ ベンダープレフィックスの自動配置、最新のWeb用の組み込みベストプラクティスを備えたアセットバンドラー、または構文用のプラグインを備えた最新のCSSリンターが機能の開発にどのように干渉するか理解できません。 それどころか、フロントエンドの複雑さが増すと、最新のツールを使用せずに機能を時間通りに効率的に実行することは不可能だと思います。 私はこれらすべてを研究し、調整し、維持しなければならないことを主張しません。もちろんこれは時間の価値があります。 これらのツールが最終的にどれだけの時間を節約するかについて話す人はほとんどいません。
-ブートストラップ、マテリアルUI、セマンティックUIなどの「ボックス化」CSSソリューションの人気の高まりについてどう思いますか？ 多くの開発者は、これが開発プロセスと結果に課す制限について不満を述べています。 おそらく、より統一された視覚的に予測可能なWebがより一貫したUXを作成するでしょうか？
-「ボックス化」ソリューションは「ボックス化」タスクに適していると思います。 ユーザーインターフェイスをすばやく作成するタスクがある場合、そのようなフレームワークがないと、おそらく非常に困難になります。 しかし、タスクが何かユニークなことをすることである場合、そのようなことは通常干渉するだけです。 2016年にドロップダウンを書くのはばかげていると思います。 ただし、フレームワークを選択する場合、開発者は自分が課すすべての制限を十分に理解する必要があります。 理想的には、頻繁に使用されるコントロールの標準ライブラリを実装して、プレゼンテーションと動作の両方を非常に簡単に変更できるようなフレームワークを見たいと思います。
-最新の標準のCSSは、その初期のミニマルな宣言的設計をやや「大きくなった」と思いませんか？ アニメーション、複雑なセレクター、徐々にXPathに似始めています。 これが、ミックスイン、変数、およびその他の構成要素を命令型言語でよりよく追加する理由ですか？
-はい、そのような感じがあります。 CSSはプログラミング言語になろうとしているように思えます。 さらに、分離、モジュール性、決定論など、通常の言語では長い間問題にならなかったその他の問題を解決することはできません。 CSSはWebアプリケーションおよびSPA用ではなく、ハイパーテキストドキュメントの設計用に作成されました。 だからこそ、CSS-in-JSの分野で大きな活動を見ているようです。「通常」または少なくとも1つのプログラミング言語を使用してUIを記述および表現する誘惑が大きすぎるのです。 私はこれに何の問題も見ていませんし、CSSをコンパイルターゲットとして検討する準備ができています。 理想的には、CSSコミュニティは、使用状況の変化を考慮した根本的に新しい標準を見たいと考えています。 しかし、CSSキャンプとJSキャンプの開発者がほとんど重複しないという問題があります。 言語の一般的な問題を伝え、理解することで問題を解決し始めるべきだと思います。
開発者エクスペリエンスはユーザーエクスペリエンスに影響を与えないと誤解されています。
-プロジェクトが非常に大きくなり、CSSでより組織的な作業を行うためのツールが必要になる瞬間をどのように判断しますか？ このツールキットに慣れると、小さなチームの開発が遅くなりますか？
-これは、プロジェクトを作成する決定が下された瞬間だと思います。 ただし、ここで関心のある問題があります。ビジネスでは、できるだけ早く開始する必要があると言われているため、6か月間、シャベルで1つの山（JS、CSS）でrowぎます-関係ありません。 ただし、リリース後、新しい機能のサポートと開発が開始されます。 そして、この時点では、誰もあえて古いコードに触れることはないので、すべてを書き直す必要があります（書き直す時間もありません）。 コード品質ツールが最初に使用されていた場合、書き換えの時間を節約できるため、このアプローチは非常にばかげているように見えます。CSSまたはJSは重要ではありません。 これがどれだけ遅くなるかは、チームによって異なります。 理想的には、ツールは遅くなるのではなく、加速されるべきです。
-適応型フロントエンド-2016年のユーザーのほぼ標準。 あなたのアプローチは、障害を持つ人々のためにサイトを適応させることで、膨大な数の許可で作業を簡素化しますか？
-私のレポートはもちろんこれに関するものではありませんが、プロジェクトの優れたアーキテクチャの結果として、アダプティブバージョンの作成とアクセス可能性の両方のためにより多くの時間が表示される可能性が高いです。 しかし、一般に、プロジェクトのアーキテクチャはこれに一切影響しません-これらはプロジェクトの品質に対する追加要件にすぎません。
-フロントエンドフレームワークの開発の現在の方向性はやや自己陶酔的であるという意見があります。 コードの美しさ、正確さ、モジュール性、互換性に焦点を当てていますが、一見したところ、UX自体にはほとんど影響しません。 おそらくあなたは反対する何かを持っていますか？
-これは、デベロッパーエクスペリエンスがユーザーエクスペリエンスに影響を与えないという誤解だと思われます。 コードの美しさとモジュール性は、コードを変更するときの開発者の自信に直接関係しており、それは製品の品質に関連しています。 バグの数、新機能のリリースの速度、細部への注意-これもUXの一部です。 優れた開発者は、多くの問題があり、誰も気にしないプロジェクトに取り組むことを望みません。
モジュラーCSSのトピックをさらに深く掘り下げたい場合は、HolyJSカンファレンスのAndrewのレポートをご覧ください。JavaScript開発者なら、他にも多くの興味深いトピックを見つけることができます。