🙌🏼 💪🏾 🗾 Javascriptフレームワーク：1つだけにする必要があります 🤙 🐆 😓

セルゲイ・アヴェリン（ XEK ）

最初は、フレームワークの比較に関するレポートを作成したかったのですが、その後、それらがトマトを投げると思ったので、レポートはいつものように地獄のようなトローリングです。そして、彼はむしろ、HighLoadについてではなく、フロントエンドを含めて、このビジネスよりも重要な管理タスクについてです。

それにもかかわらず、何を報告しましたか？新しいフレームワークの選択方法、選択する理由、およびそれらが解決したタスクに関するレポート。

最初に、会社について少し説明し、次に問題の領域、タスク、見たとおり、会社が現在持っているものについて説明します。一般的に、選択する方法を選択する方法。オプションの評価方法。彼らが最終的に自分自身に適したオプションの1つをやり直すことを決定し、2つの競合する技術のパイロットプロジェクトを比較した方法。結果はどうだったのか、そして最終的にどのように進んだのか。

そして今、物語を明らかにする時が来ました。

会社について少し：

アクロニスは、500万人のユーザーにサービスを提供するロシアの非常に大規模な企業であり、そのうち約10％が企業クライアントであり、ライセンスで作品を購入しています。したがって、会社自体も非常に大きく、17の異なるオフィスがあり、研究開発は3つの異なる国にあり、最大の研究開発はモスクワにあります。しかし同時に、私たちの開発は分散されており、ここでは数え切れなかったリモートワーカーがいます。

開発中のソフトウェアの規模は大きく異なります：Windows用のボックス版ソフトウェア、企業に販売するWebインターフェイスを備えたボックス版ソフトウェア、自社で販売および実装するソフトウェアがあります。これは、ボックス版とクラウドベースの両方のソフトウェアが混在しています。クラウドソフトウェアもあります。これは、ホームユーザーと企業ユーザーの両方にサブスクリプションで販売しています。私たちが最初に大手ホスティング会社に販売するソフトウェアもありますが、それは彼ら自身のために最終的なユーザーに彼ら自身のブランドでそれを販売します。そして、このすべてのビジネスには膨大な数のWebインターフェースがあります。これはWeb製品の問題であり、Webサイト自体の問題ではありません。

私が会社に来たとき、私たちが何を持っているか、すべてがどのように起こるのかを理解し始めました.Ext JSなどの真のフロントエンドから始めて、さまざまな技術ですぐにさまざまな種類のWeb管理者が社内にいることがわかりましたAngularJS。Rubyon Railsで記述されたサイトで終わり、jQueryは単にページまたはグラフィックを切り替えます。

チームはそのような問題に直面しました。

まず、多くのテクノロジーがあり、それらはすべて異なっており、開発者をある部門から別の部門にドラッグすることはできません。プロジェクトを支援することもできません。jQueryで記述するRuby on Rails開発者はAngularJSについて何も知らないからです。第二に、バックエンド開発者またはフロントエンド開発者として、かなりの数の人々がパートタイムで働いていることがわかりました。たとえば、PHPで書く人がいて、AngularJSでバックエンドとして動作するサイトを作成しています。それらの多くはありません、彼らは小さなプロジェクトを持っており、別のフロントエンド開発者を開始する理由はありません。

その結果、フロントエンドを行うJavaの人々、Rubyの人々、Pythonの人々、PHPの人々がいると計算しました。同時に、会社にはレイアウトデザイナーがなく、単一のデザイナーもありません。つまりこの分野を熟知している人は数人いますが、通常はAngularJSのエンコーダーとして働いています。その結果、これらのプロジェクトは完全に異なるコードスタイル、完全に異なるコメントスタイルを持ち、さまざまな方法でデプロイされます。Rubyon Railsを使用して、Rubyのコレクターを使用してAngularJSアプリケーションを構築します。そして最後に-どこでも異なる動物園。各部門には独自の動物園があります。要するに、Ext JSが書かれているフラッグシップ製品は巨大な管理パネルであり、何百もの画面があり、バージョン4に基づいて構築されており、最近では2015年にバージョン6がすでにリリースされていますこのフレームワークは、使用しているフレームワークのバージョンより5年遅れています。おそらくあなたもそれについて何かをする必要があります。

もちろん、ボスが来てタスクを設定しました。タスクは上から与えられました：

可能な限りステートレスバックエンドAPIと通信するフロントエンドテクノロジーを使用するファットクライアントが必要です。 UIコンポーネントの単一のライブラリ、会社全体の単一のルックアンドフィールが必要です。これは、フォントがどこかで異なり、ピクセルがどこかでレイアウトが浮いており、最終的には2つの隣接する部門は、すべての管理領域に共通の要素をいくつか描画します。デザイナーは同じ方法で、少し異なる方法で描画します。HTMLレイアウト、レイアウトは何らかのネイティブテンプレートエンジンのJSコードに詰め込まれます。また、CSSレイヤーも根本的に異なり、3つまたは4つのファイルを重ねて配置し、既存のフレームワークを破棄します。

最終的に通常のレイアウトデザイナーをつなぎ、給料の低いデベロッパーを雇うことができます。デベロッパーは、一方でデザイナーとコミュニケーションを取り、デザインを準備し、一方でJavaスクリプトを持ってくることができます。、彼らはそれを望んでいます、ここではこのインターフェイスをアニメーション化する必要があります... "。同時に、トップレベルではないプロジェクトでJSエンコーダーを雇うことができました。今、私たちには火と水を経験した多くの人がいます。彼らはJavaを知っています。彼らは.Netを知っています。この点で、彼らは原則として非常に経験豊富なので、どんなJavascriptフレームワークも問題ではありません。したがって、どうにかして、100人に1人ではなく、50人に2人を採用できるようにしたいと考えています。

そして、そのような別のpqrityがあります。フロントエンドを作成する人々の大部分は、前者または現在のバックエンドのいずれかであるため、これらすべてをバックエンド開発者に理解してもらいたいと思っています。管理者がJSでコードを見ると、「くそ、何も理解していない、すべてが悪い、書き直そう」と言い始めますが、そうではないことがよくあります。

会社に実際にあるものを見ました。 Dojoで作成されたアフィリエイト製品があることがわかりました。彼のために、Dojoのプラグインを作成します。これは非常に古いフレームワークであり、非常に特別で、コンポーネントモデルとして機能します。これは完全にMVCではありませんが、他のフレームワークを使用できないため、このアフィリエイトプログラムで作業することができないため、何もしないことにしました。

実際、このサイトでは、ダイナミクスはほとんどありません。検索エンジンがインデックスを作成することが重要であり、迅速に機能することが重要です。そこにJavascriptは本当に必要ありません。したがって、彼のためのある種のスーパーフレームワークは、一般に休みませんでした。これは解決すべきではないタスクです。

管理者が実際に作成された残りから、これは最初のバージョンのAngular JS、これはRuby on Rails、さらにバックエンドでページを生成し、さらに何らかのダイナミクスを作成するjQueryの補足です。また、ほとんどの製品はExtJS 4で記述されています。これらは、.NetまたはQTに最もよく似た非常に高レベルのフレームワークであり、同社の製品のほとんど（真面目および成人）が記述されています。

このExtJSが何であるかを理解しました。それは巨大な巨像であり、コードの機関車であることが判明しました。メインページでは、このフレームワークの395クラスが説明されています。

各クラスには非常に深い継承ツリーがあります。この点で、QT、.Net、およびその他のMVCフレームワークがどのように構築され、Windowsまたはデスクトップ用のLinuxのどこかで機能することから非常になめられています。その結果、多くの場合、ディベースするコードは、現在必要なコードよりも3レベル高いことがわかります。これを理解するのは本当に難しいです。

Ext.panelクラス：

これらは、そこからのメソッドにすぎません。さまざまなプロパティと同じ数のイベントがまだあります。開発者がこれらのメソッドをすべて覚えていないことは明らかです。したがって、私たちは常にドキュメントを操作して、コンポーネントのサイズのために、最も単純なものを作成する方法を理解する必要があります...すでに3つの異なるメソッドがあり、それぞれ独自の方法で3つの異なるサイズを返します。

結局、私はとても悲しかったです。最初は何も理解していなかったので、全体を見て、次の質問を自問しました。「主よ、なぜこれをすべて書いたのですか？」

フラッグシップアプリケーションのインデックスページは、シートA0に印刷され、フォント6で51シートを占めていました。

拡大した例を次に示します。

これはDOMツリーであり、32,000のノードがありました。これは、フレームワークによって生成された単なるインデックスページです。まだボタンを1つも押していません。ページをロードし、すべてをレンダリングしました。ここで奇妙なことが起こっていることは明らかです、明らかにこれにはゴミがあります。

彼らは、このフレームワークでUIがどのように行われるかを見るために登りました。ユーザーがUIコンポーネントのライブラリをすぐに受け取り、CSSによって破棄されることが判明しました。 CSSを上に追加してから、カスタムスキンを取得する必要があります。そこになかった多くのコンポーネントは、ゼロから実装する必要がありました。その結果、多くの場合、どこでもではなく、非常に頻繁に、私はそのような何かに出くわしました。これはjavascriptクラスであり、一方でUIコンポーネントですが、一方で、3つの異なるエンティティが混在していることがよく見られます-javascriptコード、htmlコード、およびこれらはローカルテンプレートエンジン、xindex、xcountの非常に奇妙なディレクティブですまたは、この中括弧で囲まれた文字列の値の文字列...

もちろん、これをすべて理解することは非常に難しく、維持することは非常に困難です。また、コンポーネントが相互に継承されると、多くの場合、このテンプレートの断片を切り取って断片に分割できることがわかりました。つまりテーブルがあり、セルテンプレートがあり、ヘッダーテンプレートがあり、コンポーネントは互いに2〜3回継承されます。 1つでは、何かが変化し、すべてが壊れます。または、フレームワークの新しいバージョンが公開され、その上に作成されたコンポーネントが機能しなくなります。

そして、これがレイアウトのようなジョークを持っている唯一のフレームワークであることがわかりました。彼らは、これらのタグが何から、どのように、なぜ、どこから来たのかを確認するために登りました。ウィンドウのサイズを変更すると、一部のコンポーネントのサイズを変更すると、フレームワークはデスクトップと同様に、ブロック自体のサイズを計算し、CSSにインラインで挿入することが判明しました。左、右、幅、高さを入力します。それだけでなく、テキストを取得してそのサイズを推定し、目に見えないdivに詰め込み、このdivが特定の幅でどのサイズになったかを調べる非常にトリッキーなアルゴリズムがあります。そして彼は、テキストのサイズ、このテキストがこのブロックにどれだけかかるかを推定する機能を模倣し、これらのブロックを計算します。そして、このアルゴリズムもツリーのようなもの、つまり彼は、ブラウザのように、干渉しないコンポーネントにつまずき、それを増やし始め、親コンポーネントも再カウントするため、6〜7パスを行います。その結果、ブラウザの適切なページを移動し始め、このフレームワークのサイズ変更に関する鈍味がはっきりとわかります。しかし、一方で、すべてのブラウザでまったく同じように機能するという利点があり、この質問を最大限に閉じているため、ブラウザ間の互換性の問題を心配する必要はありません。

その過程で、コンポーネントは非常に図に近いことが判明しました。そして、これらすべてのコンポーネントは、それぞれ3〜5レベル、または7〜8レベルの継承を持つjavascriptクラスのインスタンスです。これらのそれぞれについて、このマジックレイアウトによってサイズが推定され、計算および設定されます。次に、親がサイズを計算し、その結果、全体が非常に面白い小さなものを生成します-これらのコンポーネントのdivに直接挿入され、タグに直接挿入されるインラインcsss。したがって、非常に大きなDOMツリーであることがわかります。

このレイアウトがどのように機能するかを理解しようとして、私はそのような非常に奇妙な場所に出会いました。

その瞬間、私は非常に気分が悪くなり、これがどのように起こるのか決して理解できないことに気付きました。

パフォーマンスに関するものであることを今でも覚えていますか？

全体が既に圧縮された状態で約2 MBを占有しているため、「モバイルでの動作はどうですか？」などのテストが驚くほどの負荷になることはありません。しかし、それにもかかわらず、これは私たちにとってそれほど大きな問題ではありません。なぜなら、ほとんどのクライアントは企業であり、何かを設定する必要があるとき、管理パネルに行くからです。製品の購入後最初の週、または地獄のピペット、すなわちバックアップを取得する必要があります。そして、クソ男の地獄を持っている人は、管理パネルが最終的にロードされるまで16秒待つ準備ができています。さらに、ここではかなり細いチャネルについて説明しています。

フレームワークを使用すると、明確で非常に複雑でわかりにくくなります。アプリケーション自体はどうですか？私たちはアプリケーションコードに乗り込みました。

コードにはコメントがほとんどないことがわかります。いくつかの難しい場所は説明されていません。すべてのアプリケーションは密結合されています。 1つのクラスではなく、2.5千行の長いクラスの代わりに、通常1000行の3つまたは4つのクラスを処理します。これらは互いに非常に厳密に認識しているため、通信し、イベントを自身に転送し、内部の状態を変更します。また、モデルとビジネスロジックの間、およびビジネスロジックとビューの間の境界には非常に大きな問題があります。「特定の機能パネルを実装する魔法のパネル」のようなものと呼ばれるビュークラスがあり、同時に自分自身を描画し、子コンポーネントを描画します。さらに、次に、内部のパネル、および通知を送信することができますが、ビュークラスからサーバーに登ることもよくあります。

したがって、（非常に条件付きで）そのようなmvcがありましたが、M + CVであることが判明しました。つまりコントロールとビューの境界は非常に不明確です。モデルにはビジネスロジックがあり、コントローラーにはビジネスロジックがあり、ビューにはビジネスロジック、UIロジックがあり、アプリケーションの状態も3種類すべてのクラスに広がっていることがわかりました。したがって、たとえば、このデータがどこから来たのか、誰が信頼できるポイントであり、このデータがどこから来たのか、そして現時点でこのデータの最も信頼できるコピーを誰が保管しているのかを理解することは困難です。なぜなら、それはアプリケーションのいくつかの部分にあるからです。

また、Ext JSフレームワーク自体がすべてのユーザーをパブリッシュ/サブスクライブで構築されたアーキテクチャに向かわせることも判明しました。これは、原則として、すべてのUIコンポーネントがこのメカニズムに関連付けられており、プログラマーがフレームワークが提供するものを知らずに選択するためです。また、パブリッシュ/サブスクライブが正しいパターンですが、100ページのアプリケーションを見ると、それを理解しようとしていることがわかります。「くそ、このパネルでこのボタンをクリックするとどのような影響がありますか」そして彼女は何を引きますか？」

そして、最初に、イベントは暗黙的に親クラスに分類され、その結果、ビジネスロジックを持ついくつかのクラスに分類されるセカンダリイベントが生成され、さらに多くのイベントが生成されることがわかりました。その後、フレームワークによってイベントの一部が無視され、モデルが変更されると、このモデルは「自分のデータが変更された」というイベントを生成します。さらに5つのクラスが表示され、その変更にサブスクライブされます。これらのクラスは、このモデルの状態に応じて状態を変更します。

その結果、3時間後にようやく調和のとれた画像を構築し、すべてのイベントが非常に類似した名前を持ち、どこでもonclickがあることを理解します。理解する必要があります。これは、押したこのボタンからのonclick、または押した隣のボタンからのonclickです。フレームワークは、任意のコンポーネントのサブスクリプションを禁止しないためです。つまり誰かのスーパーコントローラーから特定のパネルのボタンにアクセスして、onclickでサブスクライブできます。そして、それは引用符でオンクリックされます。これらのコンポーネントには独自の選択性がないため、そのようなことを議論するのは非常に困難です。つまり XPathに似たComponentQueryと呼ばれる独自のメカニズムがあり、「特定の名前で特定のパネルにネストされているすべてのボタンを見つける」というRegExクエリを作成できます。したがって、何かをリファクタリングしようとすると、一般的に、特定のイベントに反応する場所をすべて見つけることは非常に困難です。多くの場合、これにより、アプリケーションがフリーズするときにイベントサイクルが発生しました。これは、子イベントが常に表示され、処理を開始するためです。このサイクルは無限です。「このイベントがすでに私に届いている場合、私はそれを処理しません」のようにトリッキーを書くまで、それ以上処理しません。つまり複雑なアーキテクチャについてです。

すべて順調です。

そして今、大きな質問があります。ビューロジック間、異なるクラス間での機能の広がりと、言語、技術、その他の間の責任範囲の非常に貧弱な境界の間の密接な関係がある大規模なアプリケーションのコードでは、通常そうではありませんか？

そしてそれが起こった。そして、実際には、なぜそれが起こったのかは明らかではありません。私の意見では、より良いかもしれないからです。しかし、要するに、Arrayオブジェクトをチェックし、残りはそれがどのように行われるかです。そして、この永遠の物語は、テストの作成を開始すると、アプリケーションについて多くのことを学ぶということです。実際、1つの関数を呼び出すために15個のオブジェクトをロックするのは非常にhemoなので、それほど多くの接続を行う必要はありません。そして、この点で、彼らはテストを「さようなら」に受けました。

調査結果は何ですか？もちろん、そのような結論は...

しかし、本当に、本当の結論は何ですか？

開発者、特にJavaで博士論文を擁護したことがない開発者にとって、フレームワークを理解するのは非常に難しいこと。第二に、出てきたコードは非常に紛らわしいです。多くの接続があり、すべてのクラスがお互いを知っており、表示されるイベントは誰にも制御されません。これにより、アプリケーションの状態変更が花火のような爆発につながります。 , - … , . , , , JS-, html, CSS . ? … ? 40-60 . « », UI JS- JS-. つまり , , , , .

, — ? , , . . publish/subscribe, mv, , mvc. dependency injection , , …

, , , , , — , , , , , . , , , , , - , .

: , -, API, – . , -, - , JS- - , , , .. .

, , , . - . , . UI .

( ) — , « , ». , , , , , . つまり .

, , - - , - , , - .

, . , ? .

, , PHP, JS , .

そして、これらの数千のフレームワークは、それぞれが2滴の水と同様に、特にフラックスフレームワークで互いに類似していることがよくあります-それは直接「あなたの名前をJSポイントと考えてください」。そして、Google Web Toolkitが長い間死んだこの地獄から、私たちはどういうわけか選択しなければなりません。どうする？もちろん、何かを考え、他の人がインターネット上で何かを選択する方法を確認し、結果を盗むためにどこかに登る必要がありました。

その結果、結果を消去することはできませんでした。結果はすべて非常に異なるため、正直な評価を行う必要があります。したがって、当局に対しては、企業やあらゆる種類のサイトがどのようなフレームワークを使用しているかを現実的かつ公平に評価する試みが行われました。

そこからスライドを切り取ったのは企業やサイトについてでした。それは正直な数字のままです。これは、Githubがさまざまなテクノロジーに登場してから一般的に記述されたコードの行数です。プラスまたはマイナス。

このスライドは、2015年に海外で行われた主要なカンファレンスで、どのテクノロジーがどのように報告されたかを示しています。

そして、どこでも絵は異なります。

この写真では、Googleの傾向が人気を検索しています。それらのいくつかがあります...ここで、よく見ると、React jsとAngular jsを除くすべてのテクノロジーが実際に減少していることがわかります。

Dojo、Yahoo ui dip、そして愛するExt jsの古いフレームワークを採用すると、すべてが衰退します。この点で、React jsとAngular jsと戦う人はいません。これは、これが唯一の問題だからです。

このような調査では、2.5千人の開発者が調査され、それぞれが1つのテクノロジーを選択しました。

これは、クラウドIDEを作成および販売するアメリカの会社です。結果は、まったく異なる写真でした。つまり製品をサポートする開発者はまだ強力です。たとえば、一般的には時代遅れのBackboneですが、それにもかかわらず、まだ完成中のプロジェクトが数多くあります。

そしてこれがロシア市場です。私たちは宇宙で働いていないことは明らかであり、会社で製品を作る必要があり、多くの製品と計画があり、誰かを雇う必要があるため、誰を雇うことができるかを評価しようとしました。ここで、一般的に、写真は異なります。 ExtJSのバージョンの1つ（かなり長いため）とBackboneのバージョンのいくつか（2008年に生まれたため）で、何らかの形で誰かが対処していることが判明しました。つまりこれは、このフレームワークでこの人がリアルタイムで何かを行う準備ができていることを保証するものではありませんが、それにもかかわらず、React jsとAngular jsの成長している技術の中で、BackboneとExtJSが突然現れ、それらがあり、それらの多くがあります。 Reactの知識を超えるバックボーンジョブこれはロシア市場のすばらしい写真です。

その結果、これらすべての研究を可能な限り横断し、興味のあるものを残しました。彼らはそこにDojoを追加し、最初に切り替えたいExtJS 6を追加しました。 Dojoは、Parallelsで使用されており、Parallelsと密接に統合されており、その上に何かが書かれているためです。

ここでは、5つのスライドが大胆に彫られています。そこにある話は非常に退屈なので、私たち全員に合わなかった理由については語りません。私はそこで止まりません。自分のために勉強するために登ったら、自分のために何らかの絵を描くでしょう。目標に基づいて評価しました。タスクの1つは、既存のコードの一部にテクノロジーを多かれ少なかれ埋め込むことでした。モノリシックなフレームワークではなく、徐々に導入できるいくつかのテクニックとライブラリのセットが必要です。この点で、Knockoutはフレームワークではなく、UIライブラリであるDojoは単なるマンモスであり、ExtJS 6は新しいアーキテクチャを導入していますが、実際にはExtJS 4と大差ないことがわかりました。何らかの種類のサポートが登場し、モバイルデバイスでの動作が改善されましたが、コンセプトは変更されていません。そこのアーキテクチャは少し良くなりましたが、私たちが推定したように、ExtJS 6で正直にアーキテクチャを書き換えるのとほぼ同じです。他のフレームワークでそれを改造することを提案するのと同じです-コストはほぼ同じです。その結果、すべて同じUIレイヤー、すべて同じパブリッシュ/サブスクライブのために拒否されました。

実際、真の候補者は2人しかいませんでした。

最初の-AngularJS-明らかな理由で、会社のいくつかの部門と一部の外部アドバイザーによってまだ非常に積極的に支持されていました。しかし、彼には非常に興味深いジレンマが生じました。一方で、それは本当に非常に良い解決策に見えましたが、一方で、Habrと、一般的には英語のインターネットで多くの記事を見ました。とてもクールですが、私たちは混乱しています。

この問題に関する私たちの見解は、私たちが2つのプロジェクトを持っているバージョン1を採用し、ソースコードを座って吸うと、このフレームワークは個別の部分に分割する非常に優れたモジュール性を持ち、それぞれが独自の小さな機能を作ります-これは非常に便利で優れています。しかし、単一のスタイルのファイルレイアウトはなく、単一のスタイルの変数の命名や単一のスタイルのコードフォーマット、つまりこれはどういうわけかフレームワークでヒープに到達したいものですが、ネバーマインドは失敗します。そして、時間の経過とともに、このレイアウトスタイルは変わります。また、コードには、良い意味で別のクラスにする必要がある場所がしばしばあることを自分から付け加えますが、何らかの理由で、それらは関数を持つオブジェクトの形でそこに押し込まれます。デバッグが難しく、さまざまなトリッキーな「マジック」、いくつかの新しいテクノロジーとの統合は非常に困難です。これは、標準が完全に独自のものであるためです。このビジネスを組み立てる方法も明確ではありませんが、この問題は解決できます。しかし、最悪なのは、当局に販売できなかったことです。みんな、「みんな、新しいバージョンを作っているのに、コードに互換性がない」と言ったからです。次に何をすべきかは不明です。

わかりました。彼らはバージョン2を視聴しました。バージョン2は、一般的に見た目は素晴らしく、必要なもの、このようなバックエンド指向のアプローチ、すべてが棚に配置されている、非常に優れたTypeScript構文が必要です。しかし、それはいまいましい、一般に、リリースの可能性はありません。私は、最も重要なこととして、このスーパーメガグーグル社を理解していない、それは長い間Pythonで働いてきました... pythonがバージョン2から3に切り替える方法の例は、これを行う方法の単なる教科書の例です。古いバージョンの構文を維持する必要があり、バックワード互換でなければなりません。そして、ここでいくつかの地獄のような地獄は簡単です。互換性がなくなります。「私たちは今、何か新しいことをしています。こちらがアルファ版です。ドキュメントはありません。開始時は不明確であり、最も重要なことは、3つの言語すべてで異なる構文を使用していることです。まあ、病気になる、気にしないでください！

これは解決策ですか？申し訳ありませんが、これはフロントエンド開発エンジンですか、誰もが大好きな最もクールなフレームワークですか？そして、4人が現在AngularJSで書いている管理者はどうすればよいですか？来て、言ってください：「みんな、あなたは知っている、私たちはただ座ってすべてを書き直す。私たちには何も良くなることはありません。新しいバージョンに移行するだけです。」 -「なぜ動くの？」-「まあ、彼らは古いものを捨てたから」そして、もちろん、彼らは私に尋ねます：「聞いてください、しかし、Pythonのようなものがあります、例えば、2から3で」。つまり何らかの種類のパーサーを設定してみましょう。コードを再フォーマットし、何らかの形でアセンブルを開始します。「ごめん、いや。さらに、それだけでなく、いや、それでもすべてを変えます。明日は別の構文になります。」そして、これは誰にも売ることも不可能です。取締役会は私を見て、明日のために私を解雇します、それがすべてです。つまり AngularJSをどうするかは不明です。

さらに調査を開始し、2番目の解決策がありました-これはFacebookが作成したReact JSです。驚いたことに、これはフレームワークではなく、単なるUIライブラリであることが判明しました。非常に明確な理解可能な構造を持ち、これは単一のデータフローであり、データのみを受け取り、それらを描画するだけであることは明らかです。各コンポーネントは分離されており、各コンポーネントは、入力として受け取るもの、最終的に描画するもの、内部状態として保存するものの宣言を持っています。いいえ、一般的に、どこかから接続し、それがどのように機能するかを学び、知る必要があるある種の魔法のフィルターやその他のゴミ...この点で、すべてが予測可能で非常にクールです。パフォーマンスを調整するための非常に簡単な機会があることを気に入っています。それがどのように機能するか、それをどのように使用するかが明確であり、それについて非常に複雑なものはありません。必要のないサーバーレンダリングもありますが、それは素晴らしいことです。

Facebookが積極的に推進しているFluxアーキテクチャは、これまでずっと進んでいます。私たちはすべてを見ていたが、私たちはそうであったように、まあまあだった。一方で、その一方向のデータフロー、および同期処理は、アプリケーションの特定の状態が明確に理解されるステートマシンのようなものです。しかし、アプリケーションを独立したブロックに分割する方法と、Angular JSのようにそれをいくつかの個別のエンティティに分割する方法はあまり明確ではありません。どうやら、ストアデータを格納するフォームには明らかにアンチパターンがあり、同時にビジネスロジックを実装し、このデータを変更するためのロジックも実装しているようです。つまりモデルであると同時にコントローラーでもあります。ユニークな名前のイベントを持つ単一のイベントバスとしての単一のディスパッチャというアイデアは、コード内で何かが変更された箇所をすばやく見つけ、迅速なリファクタリングを実行し、コンポーネントが相互に分離して動作するという点で非常に優れています。しかし、ダイナミクスがどのように提供されるか、たとえば、互いに独立して動作すると同時に同じイベントを生成する1つの画面で2つのウィンドウを開く方法などは完全に理解不能です...

概して、Facebookはコードに張り出していませんでした。そこにはありません。これはフレームワークではなく、一種のアーキテクチャのアイデアです。また、イベントバスと呼ばれる80年代に発明されました。

わかったこのゴミを実装するサードパーティのフレームワークを見てみましょう。私は5つの作品をレビューしましたが、それらはすべて2滴のようであり、AngularJSよりもこの点ではるかに悪く、Ext JSよりもはるかに悪いです。はい、アーキテクチャがどのように機能するかを確認する方が良いですが、ストアの動的な作成、アンロード、およびストア間のUIコンポーネントの何らかのリンクにより、アプリケーションの一部が相互に分離して動作し、 2つのコンポーネントは、同じビューと2つのコントローラーを使用して同じように作成され、これらのイベントで互いに戦うことはありませんでした。したがって、この点で、Webアプリケーションの開発では、すべてが非常に奇妙です。多くの場合、これを行う方法は明確ではありません。しかし、これらのフレームワークでは、過去5年間のjavascriptの開発を、同型、npm-modules、ライブラリ機能のレンダリングの形式、ES6サポートの形式で見ることができます-これは良いことです。ただ、それは気にせず、イチジクはありません、一般的に、彼らはテストインフラストラクチャを持たず、テストを書く方法は明確ではありません。特にこの新しいスーパー階層では、テストの書き方が不明確です。そして、国際化はありません。

途中で、タイプスクリプトに遭遇しました。この点で、それは一般に爆弾です。

最も素晴らしいこと-自分で「バイク」を作りたいと思うさまざまな開発者から不必要な創造性を取り除くこと-これで完璧にできると思いました。 Typescriptはトランスコンパイラです。型を設定するだけで、同じ構文でjavascriptのようなコードを記述します。つまり各変数には型があり、複雑になる場合があり、同時に複数の型を持つことができ、その結果、これらの型が削除され、これらの型が単純に削除されるまったく同じ構文を持つjavascriptファイルが作成されます。 ECMAScript 2006規格に準拠した便利な構文シュガーがいくつかあります。 ECMAScript 6から5の単なるコンパイラ。

たとえば、契約全体を作成できるとき、つまりそのような複雑なデータ型があります。ネストされた構造を持つオブジェクトがあり、そのようなunningなネストされたオブジェクトがAPIから来ていること、またはたとえばフィールドが繰り返されていることを事前に知っているアプリケーションのさまざまな部分があります。これをアプリケーションの別々の部分間の接着剤の一種として使用します。誰もが何らかのビジネスインターフェイスに焦点を当ててこのビジネスロジックを作成します。また、コンパイラは、これらのフィールドへのアクセスを正しく整理している場合、フィールドの正しい型を意味している場合、コンパイルできるかどうかをビルドするときにすぐにチェックします。

次に、インターフェースがあります。将来を見据えて-私たちが書いたフレームワークはインターフェースに大きく基づいています。私たちは、固体の原則に導かれ、より小さな責任領域に分割し、さまざまなクラスを小さなインターフェースに依存させます。アプリケーションのデカップリングが大きくなっていることがわかります。

Pythonの場合と同様に、一般的なサポートがあります。 Pythonのようにデコレータがあり、C ++の世界では慣例となっているジェネリックがあり、積極的に使用しています。また、複合型があります。まれに、回避できない場合は、この変数に文字列または数値のいずれかが含まれると言うことができます。彼もこれでうまく動作します。

その結果、この研究の後、質問はさらに多くなりました。どのアーキテクチャを選択しますか？どのソリューションが正しいですか？ ECMAScript 6の形式のjavascriptの開発に遅れずについていく方法は？ UIコンポーネントのライブラリはどこで入手できますか？

この点で、Ext JSは打撃を保持するのに非常に積極的です。独自のアセンブリ、国際化のメカニズム、明確なアーキテクチャなどを備えています。つまりその後起こったことは奇妙であることが判明したが、代替手段はない。まあ、彼女はそうですが、彼女は自分でやらなければなりません。その結果、Typescriptフレームワークが必要であり、この時点で誰もがTypescriptフレームワークを望んでいました。なし-誰も望んでいません。

さて、何をすべきか？自分でタスクを書きましょう。 JSエンコーダーはコードを記述する必要があります。レイアウト設計者は、組版して設計者とやり取りする必要があります。明らかに、デザイナーが理解できるようにUIレイヤーをできるだけシンプルにする必要があり、プログラマーがコンポーネントをひどく継承せずに3レベルまたは4レベルでCSSスタイルをひどく継承せずに理解できるようにする必要があります。明確でわかりやすいアーキテクチャ、バックエンド開発者が理解できるコードを作成する必要があり、責任の領域を分離する必要があります-個別のレイアウト、個別のコード、個別のコントローラー、個別のデータストレージ、アプリケーション状態を1種類のクラスタイプに詰め込み、モデルと呼びますそして、最も重要なことは、より多くの境界、規則、および標準：ネーミング、コードのフォーマット、ファイルレイアウトなどです。そして同時にTypescriptで。そして同時に、全体が既存のコードに埋め込まれる必要があるため、この全体がモノリシックフレームワークではありません。

最終的に、Este.jsというフレームワークを使用しました。彼はあなたに何も語りません;彼は最も革命的で革新的でした。彼が何もなくなるまで、彼らはスムーズにコピーしました。

最後に、いくつかの問題がありました。

最初の問題。 storeは流動的なアンチパターンの一種であることがわかります。実際には、良いことは何もありません。その結果、データを保存して変更できるクラスに戻し、コントローラーのビジネスロジックを個別に分割しました。これは、状態を持つオブジェクトを別々に杭打ちしたときにフラックス開発が行われる場所とほぼ同じです。このオブジェクトには、単にストアと呼ばれる状態があります。

そんな感じでした。

次のような結果になりました。

つまり AngularJSとほぼ同じ、モジュールと同じメカニズムを持つ分離ブロック。各モジュールには、複数のコントローラーの1つと通信する1つ以上のストアがあります。そして最終的に、この全体がビューとは別に機能します。 Viewはストアデータのみを読み取り、単一のディスパッチャーがコントローラー間で分散する特定のアクションを生成します（実際には、単一のブロックではなく、各分離ブロックが独自に持つことができます）。コントローラーはそれぞれイベントにサブスクライブし、応答するかどうかを決定しますこのイベントかどうか。その結果、私たちのアプリケーションは、互いに埋め込まれたアプリケーションのセットとして機能し、それぞれがフラックスの内側にあります。これは、ビューが単純にネストされ、コントローラーが分離されている階層型MVCです。

2番目の問題は、Facebookが次のようなテンプレートの実行を提案していることです。

もちろん、私たちは長い間苦しんでいましたが、これはまったく選択肢ではないことに気付き、自分で足を撃ちました。 UIコンポーネントの本質が、ある種のテンプレートを取り、それをレンダリングすることである場合、多くのJSコード、ブレース、括弧、ロジック、およびすべてを一緒にUIコンポーネントに混在させる必要がある理由はまったくわかりません。ブラウザで。 wix-react-templatesのようなプロジェクトを見て、非常によく似た独自のプロジェクトを作成しました。しかし、そこにはコードがありません。 else、変数、それ以外の場合、繰り返しを提供するブロックのみがあります。つまりコンポーネントのタスクは、この変数に表示される内容を事前にこの変数に詰め込むことです。また、コンポーネントのタスクは、どのブロックをどのデータで反復するかを示すことです。テンプレートは次のようになります。

ここでは、これらのテンプレート用に独自のパーサーを作成しました。これにより、DOMツリーが作成され、JSXによって生成されたテンプレートと非常によく似たテンプレートが生成されます。

現在、このケースはすでに自動的に生成されており、Reactはこのケースで動作します。

UIコンポーネントの本質は、いくつかの小道具を宣言し、いくつかの状態を宣言し、最も簡単な方法でこれらの小道具をブロックと変数に詰め込むことです。彼らは特定のツリーを構築し、それをレンダリングします。

翻訳のために、これらのテンプレートのテキストを噛み合わせてファイルを生成する小さなものを作成しました。このファイルをペンでロシア語に翻訳します。何らかの種類のレイアウトをそこに追加できます。最後の行にスパンが追加されていることに注意してください。私たちは言葉の多元化のためにこのビジネスを築いています。

, , , span .

, Facebook , , . .

?

, , , java. dependency injection, , — React lodash. — , , MVC — MVC. React. web-pack…

— Ext JS 6, React. , , , , . , - .

— , , , - , , , , json rest, , API .

:

, , , , flux + react 2- 5- . , UI , ExtJS, , , , , .

, . , , , 60 , 15 — , - , , , -, — .

. react', - 4 .

, 10 , , 2 . 4 2 - UI , .

, , , , UI . , « » « , ». , , , , . , UI Ext JS, , - , - - , , , - . , , , , .

, : ; , , — . , , . つまり react' , , , , , .