JavaScriptのみ：Webプロジェクトの同種のアーキテクチャ

フロントエンド開発者の作業には、コードの最適化、既製のフラグメントをプロジェクトのバージョン間で転送するなどのタスクがいっぱいです。その複雑さは、開発自体に対する歴史的に確立されたアプローチによって決定されることがよくあります。 6月5日にサンクトペテルブルクで開催されるHolyJS会議での彼のレポートで、フロントエンド開発者のAlexey Ivanovは、アプリケーションが「all-in-JS」を支持する異種のパーツで構成される場合、通常のアプローチを放棄することでこれらの問題をどのように減らすことができるかを説明します。 会議の前夜、私たちはアレクセイと彼のアイデアがどのような困難をもたらしたのかを正確に話しました（アイデア自体はレポートでより詳細に開示されます）。







-あなた自身とあなたの仕事について簡単に教えてください。



-私の名前はAlexey Ivanovです。私はEvil Martiansのフロントエンド開発者です。 これは、eBayやGrouponなどの大企業やさまざまなスタートアップを短時間で、問題なく、急速な成長を期待してインターネットプロジェクトを立ち上げるのを支援する分散開発グループです。

火星人では、現在、ロシアのeBayオフィスでeBay Socialと呼ばれるフロントエンドサービスを行っています。 これは、Reactで記述された個別のインタラクティブなパーツを備えたクラシックなRuby on Railsアプリケーションです。

Martianの前に、Backboneでridero.ruの最初のバージョンのSPAアプリケーションを作成し、bem-toolsを使用してYandexのいくつかのサービスを立ち上げ、さまざまなサイズのさまざまなサーバーおよびSPAアプリケーションを開発しました。開発。 私は、さまざまな方法論やツールで使用される、コードの編成、依存関係の操作、競合の解決のさまざまな方法を研究および比較するのが好きです。



- 開発アプローチの世界的な変化のアイデアはどこから来たのですか？



-火星のフロントエンド入札は、主に2つのタイプのプロジェクトで機能します。

最初に、古典的なRuby on Railsプロジェクトを作成します。 そのようなプロジェクトでは、テンプレートはRails自体の内部のサーバーにレンダリングされ、CSSとJavaScriptのアセンブリはNode.jsとGulpまたは別のコレクターに別々に存在します。 プリプロセッサとポストプロセッサを使用し、個々のファイルを共通のバンドルに収集し、Clean CSSとUglifyJSコードを圧縮しますが、CSSとJavaScriptはお互いについてほとんど知識がなく、使用するHTMLについては何も知りません。



次に、HTMLを作成するシングルページアプリケーション（SPA）を作成します。多くの場合、ブラウザですぐにCSSを使用し、データレベルでのみサーバーと通信します。

実際、これらは現代のフロントエンドの2つの平行した世界です。 ある時点で、SPAは従来のサーバーアプリケーションから独立した進化的ブランチに生まれ変わり、独自の突然変異と新しいアイデアを独自の方法で採用しました。 その結果、これら2つのタイプのプロジェクトで使用されるツールキットは大きく異なります。



現代のSPAで使用されるツールとアプローチにより、グローバルネームスペースの変数名とCSSクラスの共通部分、未使用のコードとスタイルの削除、特定のセクションとページのCSSとJavaScriptアセンブリの作成など、フロントエンド開発の多くの古典的な問題を最小限の労力で解決できます。 最良の部分は、最小限の介入でマシンが大部分の作業を行うことです。



したがって、SPAを使用した後、従来のサーバーアプリケーションに戻ると、痛みと苦痛が生じます。 SPAですぐに使用できたものは、現在は動作しないか、実装に多くの時間と労力を必要とします。



私は普通の人として、痛みや苦しみを取り除く方法を探しています。 そして、私のレポートはこれらの検索の結果です。 既存の問題、SPAでそれらを解決する方法、SPAに登場したが、サーバーで使用できるツール、およびサーバーアプリケーション用の既製ソフトウェアの形でまだ実装されていないSPAの概念（ただし、ソフトウェアが実装されていれば、現在解決されていない多くの問題の解決に役立ちます）。



-サーバーアプリケーションの開発に固有の前述の問題の例を挙げることができますか？



-大規模なプロジェクトでは、ダウンロード速度の最適化とブラウザーに送信されるコード量の削減に関連する多くのタスクがあります。



ユーザーにHTMLページ、CSS、およびJavaScriptを送信するとします。 CSSはBEM方法論に従って記述されています。 最適化の方法の1つは、他のクラスとの競合を避けるために、開発時に自分用に書いた長いCSS名を減らすことです。



クラスがあるとします：

.block__element_modificator {}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、そのような行は数千ほどあります。 代わりに、より短いものを送信したい、と言いましょう：

 .b1 {}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これをどうやってやるの？

CSSクラスはいくつかの場所で使用されます。1つ目はCSSファイル自体、2つ目はHTML、3つ目はJavaScriptです。

CSSファイルから始めましょう。 最初に行う必要があるのは、CSSファイルを1つにマージすることです。異なるファイルの置換を処理する場合、競合がないことを確認できないため（技術的には、1つのファイルに結合せずに名前を短縮できますが、中間リストが必要になります）各新しいファイルの処理中にロードする必要がある置換。このオプションは、必要なリソースの観点から実装するのが難しく、より高価です-Ed。 ） 次に、いくつかのプログラムで受信したファイルを調べて、出力に次の2つの情報を取得します。名前が置換されたファイルと、フォーム内の置換のリストです。

 { 'block__element_modificator': 'aBc' }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これまでのところ、すべてがシンプルです。 続けましょう。

次に、これらのクラスをHTMLで置き換える必要があります。 これはそれほど単純ではありません：クラスは別々の文字列から組み立てることができ、テンプレートの変数はクラスの一部にすることができ、クラス属性内ではなく、どこか別の場所からこれらの部分からクラス名を収集できます。 さて、私たちの場所のどこかで、単一のクラスをタグで使用できます。 これらすべてのポイントを特定する必要があります。

 <div class="block__element  block__element_{some_variable_name} {some_other_class_from_variable}">
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのような場所を少なくとも1つ見逃すと、レイアウトが壊れます。



さらに、JavaScriptではクラス名を使用します。 そこでは、クラスの名前が正確に何であるかを判断することはさらに困難です。

 var className = "block__element_modificator"; $elem.addClass(className);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、余分なものは編集しないでください。

 var block = ...;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

JavaScriptのクラスは単純に変数として格納できることに注意する価値がありますが、これがクラスであることは明らかではありません。 繰り返しますが、クラス名を作成するときに任意のロジックを使用できます。または、変数をクラスとして呼び出すことができます。 正規表現だけで置き換えることはできません。



その結果、単純なタスク（クラス名の略語）は、私たちにとって取るに足らないものに変わります。



これらすべてのことから、クラス名を圧縮してもサイズがそれほど大きくなることはありません。 スタイルのサイズを最適化するより効果的な方法があります-たとえば、未使用のルールからファイルを削除します。 BootstrapのようなライブラリやFont Awesomeのような象徴的なフォントを使用すると、何百もの未使用のルールがアセンブリに取り込まれます。 同様に、リファクタリング中にスキップされてクリーニングされないルールに重みが追加されます。 実際に使用されているルールのみをブラウザに送信できれば、これによりサイズが大幅に向上します。



-アセンブリから未使用の要素を削除することも難しいですか？ そして、この「歴史的な尾」は本当にアセンブリのサイズを大きく増加させますか？



-プロジェクトが数年にわたって開発されている場合、大量のゴミが蓄積する可能性があります。 そして今、私は個々のクラス名だけでなく、ネストを伴う複雑なセレクターについても話します。 たとえば、次のルール：

 .news .title {}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このサイトでは、ニュースクラスとタイトルクラスの両方を別々に使用できます。 さらに、このような組み合わせでは、ルールのように、それらは決して発生しない可能性があります。 この状況では、ルールも安全に削除できます。 その結果、未使用のコードを削除するには、現在の状態だけでなく、可能なすべてのページの構造を理解する必要があります（ページは、ポップアップ、パーソナライズされた広告、またはフレンドストリーム内の特定の種類のレコードの選択を使用して、許可されたユーザーまたは許可されていないユーザー用にできます）。 ページの構造を理解するには、HTMLだけでは十分ではないことを考慮する価値があります。 このすべてを変更できるJavaScriptがあります。 良い方法では、ページの可能な状態のツリーを構築した後、JavaScriptがこのツリーをどのように変更できるかを正確に理解する必要があります。



そして、私たち全員がこれを理解して初めて、良心をもってCSSからルールを削除できます。



JavaScript短縮についても同じことが言えます。 未使用の変数と関数を自動的に削除できます。 ただし、HTMLの操作に関するコードを削除することはできません。ページの構造がわからなければ、実際に必要なものと、決して使用されないものを理解できないからです。



-最適化中に他のアプローチを単に使用することは可能ですか？



-反対側から入ろうとすることができます。 たとえば、共通のCSSおよびJavaScriptバンドルを異なるページの個別のバンドルに分割し、現在のページに必要なもののみがユーザーに送信されるようにします。 彼がメインページに来たとします-メインページに必要なものだけを送って、それが速く見えるようにし、残りをなんとかしてロードしましょう。 単純化するために、ページを作成することはできませんが、ユーザーの状態に応じて-承認済みまたは未承認（つまり、承認後にパーツを追加）します。



これを迅速に行うためには、どのページにあるのか、またHTML、CSS、JavaScriptが互いにどのように影響するのかを再度知る必要があります。 もちろん、これらすべてを手作業で処方することもできますが、この作業は非常に長く、恩知らずです。



そして、これまでのところ、ブラウザーに送信されるファイルのサイズの縮小についてのみ説明しました。 また、名前の競合、依存関係の解決、何かを忘れないようにプロジェクトからプロジェクトにコードを転送する、エディターなどのソースから不要なものを削除するという問題もあります。



-これらの問題を解決するツールは本当にありませんか？ この「悪循環」から抜け出す方法は？



-インタビューの冒頭で、フロントエンドには、サーバーアプリケーションの世界とSPAの世界という2つの並行する世界があると言いました。 SPAの世界では、上記の問題の多くは正常に解決されており、誰もそれを覚えていませんが、サーバーアプリケーションの世界では、それらは依然として関連しています。



同時に、すべてを取り込んでSPAの作成を開始することはできません。ページ上にダイナミクスがほとんどない領域がまだ多数あり、検索エンジンによるインデックス付けと最大数のデバイスからのアクセシビリティが関連しているためです。これらはオンラインストア、ディレクトリ、政府サイトアクセシビリティなどに対する高い要件。



残念ながら、既存のSPAツールを使用することはできません。 それらは異なる要件を持つ異なる環境用に作成されました。 しかし、ここでは、これらのツールで使用されているアイデアとアプローチが著しく引き継がれ、どこでも使用されています。 さまざまな環境でのアプリケーションのこれらのアイデア、アプローチ、機能、および問題についてだけでなく、そこで使用できるものについても、 HolyJSについての私の報告があるでしょう。



-アイデアは表面上にあるようです。 なぜ大衆に行きませんか？



-アイデアはまだ大衆に向かっています。 同型のアプリケーションがあり、 ReactをDjangoおよびRailsとクロスさせようとします 。 bem-toolsがあり、その作成の理由はレポートで説明する多くの問題でした。 私の同僚のSasha Madyankinによって書かれたpstcss-modulesを介して、サーバー上で友人にHTMLとCSSを作成する試みがあります。 つまり、広く一般に受け入れられている一般的な解決策はありませんが、さまざまな側面からこの問題に対する多くのアプローチがあります。



私の意見では、このソリューションがまだ登場していない主な理由の1つは、SPA開発者の数がサーバーアプリケーション開発者の数よりもはるかに少ないことです。 後者の中でも、レポートで説明するすべてのツールと概念に出会って作業した人はそれほど多くありません。



できるだけ多くの人々がこれらの概念について学び、これらの用語で考え始め、サーバー上でそれらと連携するためのツールを書くことを望んでいるので、レポートを準備しています。



会話ありがとうございました！



会話の一環として、フロントエンド開発者が毎日直面する問題について簡単に説明しました。 「JSのすべて」アプローチが状況を単純化する方法については、HolyJSに関するAlexey Ivanovのレポートをお読みください。 さらに、会議には、Webアプリケーションのアーキテクチャに関連する他のいくつかのレポートがあります。 もちろん、今日の対話者は、その場で興味のある質問をすることができます。