フロントエンドフレームワーク：解決策または肥大化した問題？

最新のフロントエンドフレームワークでは、開発環境をダウンロードし、依存関係を完備し、ブラウザで表示する前にコードをコンパイルする必要があります。 これは良いことですか？ より複雑なサイトを構築しているという問題ですか、それともフレームワーク自体が複雑で、不必要なレベルの複雑さをもたらしているという問題ですか？

今日のWeb開発は、90年代から大きく進化しました。 ネイティブアプリケーションで実行できるものに非常に近いエクスペリエンス全体を作成でき、開発プロセスも変更されました。 フロントエンドのWeb開発者であることが、メモ帳を開き、数行のコードを入力し、ブラウザーでチェックして、FTPフォルダーにアップロードするという問題であった時代は終わりました。

過去のフロントエンドWeb開発

私は明白なことを述べることから始めなければなりません：世界はそれが10年前であったようではありません。 （衝撃的です、私は知っています。）一定のままである唯一のものは変化です。 当時、ブラウザはほとんどありませんでしたが、互換性の問題がたくさんありました。 今日では、「Chrome 43.4.1で最もよく表示される」などはあまり見られませんが、当時はかなり一般的でした。 現在、ブラウザは増えていますが、互換性の問題は少なくなっています。 なんで？ jQueryのため。 jQueryは、DOMが各ブラウザーおよび各ブラウザーの各バージョンでどのように実行されるかを心配することなく、DOMを操作するJavaScriptコードを記述できる、標準の共通ライブラリーを持つ必要性を満たしました。これは2000年代の真の悪夢です。 。

最近のブラウザはDOMを標準として操作できるため、このようなライブラリの必要性は近年大幅に減少しています。 jQueryはもう必要ありませんが、jQueryに依存する非常に便利なプラグインを見つけることができます。 言い換えれば、Webフレームワークは必要ないかもしれませんが、それでも人気があり広く使用されるのに十分有用です。 これは、React、Angular、Vue、Emberから、Bootstrapのようなスタイルやフォーマットのモデルまで、一般的なWebフレームワークのほとんどに共通する特徴です。

人々がフレームワークを使用する理由

人生のようにウェブ開発では、迅速な解決策を持つことは常に便利です。 これまでにJavaScriptでルーターを作成したことがありますか？ 問題を克服するためにフロントエンドフレームワークをnpm-installできるのに、なぜ苦痛な学習プロセスを経るのですか？ クライアントが昨日物事をやりたいと思っている場合、特定のフレームワーク用に設計された別の開発者からコードを継承している場合、または特定のフレームワークをすでに使用しているチームと統合している場合、時間は贅沢です。 それに直面しましょう—フレームワークには理由があります。 それらに利益がなければ、誰もそれらを使用しないでしょう。

では、Web開発フレームワークを使用することの利点と独自の特性にはどのようなものがありますか？

時は金なり。 プロジェクトを開発していて、クライアントがどのフレームワークを使用するかを気にしない場合（実際、おそらく何を使用するかさえ知らない場合）、結果を得ることにのみ関心があり、高速であるほど優れています。 確立されたフレームワークを使用すると、クライアントが1日目から切望する、最初から即座に進歩の感覚を作り出すことができます。プロジェクト。

それはすべてコミュニティに関するものです。 フレームワークを選択する場合、これは非常に重要なポイントです。問題が発生したときに、誰があなたを助けてくれるのでしょうか。 あなたも私も、それがいつか起こることを知っています。 フレームワークが意図していないこと、またはフレームワークがアクセスできるように設計されていないことを行う必要がある場所に到達するため、コミュニティがあなたをサポートすることが不可欠です。 仮想世界に没頭しているため、開発（特にフリーランス）は難しい場合があります。チーム内で唯一のフロントエンドWeb開発者である場合、それはあなたが経験と専門知識を持っている唯一の人であることを意味します。解決。 しかし、使用するフロントエンドフレームワークがしっかりとサポートされていれば、同じ問題に直面し、あなたを助けることができるかもしれない誰かが世界の反対側にいるでしょう。

基準は美しいです。 自分のコードの古い部分を調べると、非常に簡単にナビゲートできることに気付いたことがありますか？ または、少なくとも、他の誰かが書いたコードよりも簡単ですか？ あなたは特定の方法で考え、物事に名前を付け、コードを整理する独自の方法を持っています。 それが標準です。 彼らが私たちだけのためであっても、私たちは皆彼らに従います。 私たちは朝食に同じようなものを食べ、特定の時間に目を覚まし、毎日同じ場所に鍵を置く傾向があります。 そして確かに、私たちが毎日ルーチンを変更した場合、物事を行う方法を理解するというオーバーヘッドだけで、人生ははるかに困難になります。 通常とは別の場所に置いたために鍵を紛失したことがありますか？ 標準は生活を楽にします。 チームまたは開発者のコ​​ミュニティの一部として働くとき、彼らは絶対に不可欠になります。

フレームワークは、インストールした瞬間から標準を提供し、特定の方法で考えてコーディングするようにガイドします。 チームで標準を作成するのに時間を費やす必要はありません。 フレームワークで物事がどのように行われるかをたどることができます。 これにより、一緒に作業するのが簡単になります。 関数はSPAにルートを追加するために構築されており、フレームワークではすべてのルートがその名前のファイルに配置されるため、関数が特定のファイルに含まれている必要があることがわかっている場合は、関数を探すのが簡単です。 このレベルの標準化があれば、さまざまなスキルレベルの人々が協力できます。これは、高度なコーダーがそのように行われる理由を知っている一方で、後輩の開発者でも標準自体に従うことができるためです。

フレームワークが失敗したとき

数年前、「私はフレームワークを使用していません。フレームワークから実際のメリットは見られません」などと言うと、松明や熊手を持っている人があなたの家にやってくるでしょう。 しかし、今日、ますます多くの人々が自分自身に問いかけています。 本当に必要ですか？ それらなしでコーディングするのは難しいですか？」

私は確かにその一人です。特定のフレームワークのファンになったことがなく、キャリア全体を通してそれらなしでコーディングしてきました。 私に選択肢がある場合、私の選択は常に「いいえ、ありがとう」です。 私はJavaScriptで何年も開発しており、それ以前はActionScriptで開発してきました。 ほとんどの人がすでにFlashが死んでいると考えていたとき、私はFlashでコーディングしていました。 （私は知っています、私は知っています…しかし、私はたくさんのアニメーションをやっていて、プレーンHTMLでのアニメーションは難しいです。）それで、あなたがフレームワークなしでコーディングすることを決して考えない多くの人の一人なら、あなたがそうするかもしれないいくつかの理由をあなたに見せましょう苦労している。

「ワンサイズですべてに対応」は嘘です。 自分のキャリアで達成したすべてのことを実行できる単一のソフトウェアを作成することを想像できますか？ これは、Web開発フレームワークの主な問題の1つです。 プロジェクトには非常に具体的なニーズがあり、フレームワークの範囲を拡張するためにライブラリ、プラグイン、またはアドオンを追加することで解決する傾向があります。 必要なものを100％提供するフレームワークはなく、有用と思われるもので100％構成されているフレームワークもありません。

使用しないコードが多すぎると、サイトの読み込みタイムラグが発生する可能性があります。これは、ユーザーを追加するたびに重要になります。 もう1つの問題は、「1つのサイズですべてに対応」という考え方が非効率的なコードになることです。 たとえば、 $('sku-product').html('SKU 909090'); 、これはjQueryコードであり、最終的にはdocument.getElementById('sku-product').innerHTML = 'SKU 909090'; 。

1行でのこの種の違いは重要ではないように思われるかもしれませんが、ページの特定の要素のコンテンツを変更することは、まさにReactのおかげです。 ここで、Reactは、DOMの表現を作成し、レンダリングしようとしているものの違いを分析するプロセスを実行します。 最初から変更したいコンテンツだけをターゲットにするほうが簡単ではないでしょうか。

あなたが歩いている雑草のもつれは、とげを成長させています。 フレームワークを使用していて、それにライブラリを追加しようとしている状況で、必要なライブラリバージョンが、使用しているフレームワークバージョンではうまく機能しないことに気付いたことがありますか？ 自分でコードを書くよりも、2つのコードを連携させる方が手間がかかる場合があります。 また、使用するフレームワークとライブラリは、予測できない非互換性を隠している可能性のある他のフレームワークとライブラリに基づいて構築されていることが多いため、問題は指数関数的に複雑になり、管理が不可能になる可能性があります。プロジェクトを成長させ続けたい。

ジョーンズに追いつくことは事です。 AngularJSでプロジェクトに取り組んだことがありますが、Angular 4がリリースされるまで表示されなかったものが必要であることがわかりましたか？ Angular 5がリリースされたことをご存知ですか？ これはもう1つの大きな問題です。 単一のフロントエンドフレームワークに固執している場合でも、新しいメジャーリリースが発生すると、状況が大きく変化する可能性があるため、作成に苦労したコードは新しいバージョンでも実行されません。 これにより、多くのファイルに加える必要のある煩わしい小さな変更から、コードの完全な書き直しまで、あらゆる結果が生じる可能性があります。

フレームワークの最新のビルドに追いつくのは困難ですが、同じように、更新が完全に停止し、他のテクノロジーに追いつくことができない場合、他のフレームワークは苦しみます。 2010年には、AngularJSとBackboneの両方が初めてリリースされました。 今日、Angularは5番目のメジャーバージョンにあり、Backboneは完全に脚光を浴びていません。 7年は長い時間のようです。 あなたがウェブサイトを構築するならば、それらはおそらく美学と機能において完全に変わったでしょう。 アプリを構築している場合、間違ったフレームワークに賭けると、後で書き直しが必要になったときに、会社が困難で費用のかかる状況に陥る可能性があります。

あなたが持っているのがハンマーだけであるとき、すべては釘のように見えます。 Web開発フレームワークを頻繁に使用している場合、これはおそらくあなたに起こったことです。単一のコードベースが、周辺にのみ関連している場合でも、将来使用するコードの形状を定義します。 YouTubeのようなプラットフォームを構築し、Framework Xを使用したいとします。この時代ではばかげているように聞こえても、動画にFlashを使用することにした場合があります。フレームワークに組み込まれています。

フレームワークには意見があり、強力です。 たとえば、Reactは、特定の方法でJSXを使用するように強制します。 どこでもそのように使用されているコードを見ることができます。 代替手段はありますか？ はい。 しかし、誰がそれを使用しますか？ これは必ずしも悪いことではありませんが、複雑なアニメーションを実行する必要がある場合は、React全体ではなく、アニメーション化のためのフレームワークのみが必要になる場合があります。 要素にノードを追加するためだけにjQueryをページに追加するなど、人々がクレイジーなことをしているのを見てきました。これは、バニラJSでdocument.getElementById('id_of_node').appendChild(node);を使用して実現できます。 。

Evalは悪ですが、 .innerHTMLはMachiavellianです

多くの人がフレームワークなしでコーディングしない理由の1つだと思うので、時間をかけてこの点を個別に調べたいと思います。 DOMに何かを追加しようとしたときにほとんどのコードがどのように機能するかを見ると、 .innerHTMLプロパティによって挿入された一連のHTMLが見つかります。 evalはJavaScriptコードの実行に悪いことに同意しているようですが、ここで.innerHTMLにスポットライトを当てたいと思います。 HTMLコードをプレーンな文字列として挿入すると、作成したノードへの参照が失われます。 getElementsByClassNameを使用するか、 idを割り当てることで元に戻すことができるのは事実ですが、これは実用的ではありません。 ノードの1つの値を変更しようとすると、HTML全体を再びレンダリングしていることに気付くでしょう。

これは、コーディングを開始するときに適しています。 経験がなくても簡単にたくさんの簡単なものを作ることができます。 問題は、アプリに似ている傾向がある最新のWebサイトの複雑さで発生します。つまり、ノードの値を絶えず変更する必要があります。これは、構造全体を再接続して行う場合、コストのかかる操作です。 .innerHTML経由。 ReactはシャドウDOMを介してこの問題を効率的に解決し、Angularはページに表示される値を変更する簡単な方法としてバインディングを使用してこの問題に対処します。 ただし、作成したノードを追跡し、再利用または更新されるノードを変数に保存することで、かなり簡単に解決することもできます。 一般的に.innerHTMLから離れる理由は他にもあります。

フレームワークなしのコーディングに関する最大の神話

時は金なり。 はい、私はこの概念を以前から持ち帰っています。 多くの人は、人気のあるWebフレームワークの使用をやめれば、すぐに90年代のインターネットに移行するだろうと感じています。 <marquee>がみんなのお気に入りのタグであり、Geocitiesサイトで回転するGIFが流行に敏感で、AltaVistaが人気でした。 Web検索用に、ヒットカウンターはいたるところにありました。

Webフレームワークを使用すると、コードの最初の行で時間を大幅に節約できるように見えますが、ある時点で、利益は損失に変わります。 フレームワークに構築されていないことを実行させる方法、ライブラリを統合してフレームワークとうまく連携させる方法、およびフレームワークの標準に従って構築したコードが機能しないことを確認するために時間を費やします。まったく機能するためには、今度はそれを書き直す必要があります。 フレームワークなしで物事を行うと、開始は遅くなりますが、着実に進歩します。 結局のところ、それはあなたが簡単な部分をどこに置きたいかということです。 合計時間に大きな違いはありません。

私のコードは万里の長城より長くなります。 フレームワークなしで書くことは、ストリーミングサービスに加入する代わりに映画を購入するようなものです。 見たい何百本もの映画にすぐにアクセスすることはできませんが、ストアからのダウンロードを考えたこともない他の何千本もの映画にお金をかける必要もありません。 必要なものを書くだけです。

仲買人は役に立ちますか？ もちろん。 ただし、通常は必要ありません。 フレームワークの要件に適応する必要がないため、作成するコードのすべての行には、より多くの意味があります。 DOM要素を作成する方法は、要素を作成し、それをDOMにアタッチし、おそらくスタイリング用のクラスを追加するための行を必要とするため、純粋なJavaScriptを使用してより多くのコードを記述しているように感じることがあります。 JSXのコード。 ただし、jQueryやReactなどのライブラリを使用してコードを比較すると、バニラJSの長さはかなり似ている可能性があります。 長い場合もあれば、短い場合もあります。

車輪の再発明をする必要はありません。 いたるところにあるコンピュータサイエンスの教授のマントラ。 そしてそれは真実です—それはフレームワークを具体的に意味する必要はありません。 たとえば、ほとんどすべてのWebアプリでデータをロードまたは保存するためのAjaxリクエストを送信する必要がありますが、フレームワークがないからといって、毎回コードを新たに作成する必要があるわけではありません。 独自のライブラリまたはコードベースを作成することも、他の人からコードを抽出することもできます。 小さいほど、必要に応じて変更や調整がしやすいので、プロジェクトに固有の何かが必要な場合に便利です。 サードパーティのライブラリまたはフレームワークに含まれている可能性のある大量のファイルをナビゲートするよりも、100〜200行のコードを変更する方が簡単です。

小さなプロジェクトでのみ機能します。 これは非常に一般的な神話ですが、まったく真実ではありません。 現在、Googleドライブのようなモジュールを含め、会社のすべての側面を1か所でオンラインで管理するためのシステム全体に取り組んでいます。 フレームワークの有無にかかわらず、私は非常によく似た手順を実行し、非常によく似た問題に遭遇します。 違いはごくわずかです。 ただし、フレームワークがないと、コード全体が小さくなり、管理しやすくなります。

証明したい

わかった。 理論について話すのをやめて、実際の例にジャンプしましょう。 数日前、店舗のロゴが付いたブランドのリストを表示する必要がありました。 最初のコードはjQueryを使用していましたが、Mozillaにロードすると、ロゴがまだアップロードされていないブランドの壊れた画像アイコンが表示されるという問題がありました。 X社がまだ作業を終了していないという理由だけで、ストアを未完成のように見せることはできませんが、機能を稼働させる必要がありました。

次のコードは、 .innerHTMLと同等のjQueryを使用しています。

 var list_brand_names = ['amazon', 'apple', 'nokia']; var img_out = ''; for (i=0;i<list_brand_names.length;i++) { var brandName = list_brand_names[i].toLowerCase(); img_out += "<a href='/pages/" + brandName + "'><img src='images/" + brandName + "' /></a>"; } jQuery("#brand-images").html(img_out);

jQueryの長所と短所を深く掘り下げることなく、ここでの問題は、作成した画像への参照がないことです。 コードの変更を伴わないソリューションもありますが、この機会を利用して、ライブラリなしでどのように実行できるかを見てみましょう。

 var brands = ['amazon', 'apple', 'nokia']; var brand_images = document.getElementById("brand-images"); for (var iBrand = 0; iBrand < brands.length; iBrand++) { var link = document.createElement('a'); link.setAttribute('href', '/pages/' + brands[iBrand]); link.style.display = 'none'; brand_images.appendChild(link); var image = new Image(); image.src = "images/" + brands[iBrand] + "png"; image.onload = function(){ this.parentNode.style.display = ''; } link.appendChild(image); }

元のjQueryコードは6行の長さでしたが、バニラJSソリューションは12行かかりました。 この問題を解決するには、ロードされるまで各画像を非表示にすると、コーディングに2倍の時間がかかります。 それでは、代替案を見てみましょう。 jQueryでも解決できますか？ 見てみな：

 img_out += "<a href='/pages/" + brandName + "'><img src='images/" + brandName + "' onload="showImage(this)"/></a>"; function showImage(image){ image.parentNode.style.display = ""; }

コードを数行追加すると、jQueryとバニラの違いは3行だけになりますが、jQueryでは、 img_out行が急速に複雑になり、一時停止する必要があることがわかります。何をしているのかよく考えてください。 ノード関数を使用して属性や関数などを追加してDOMを直接コーディングする方が時間がかかる場合がありますが、各行の意味がより明確で正確になり、将来の読み取りと保守が容易になります。

Reactを見てみましょう：

 function BrandLink(props) { var url = "images/" + props.brand + ".png"; return (<a href="{props.brand}"><img src={url}/></a>); } class Brands extends React.Component { constructor() { super(); this.state = {brands: ['amazon', 'apple', 'nokia']}; } render() { const links = this.state.brands.map((step, move) => { return (<BrandLink brand={step} key={step}/>); }); return (<div className="brands">{links}</div>); } } ReactDOM.render(<Brands />, document.getElementById("root"));

このバージョンは明らかに最適ではありません。 コードはバニラのコードよりも短くはなく、問題を解決してリンクを非表示にするまで、内部の画像が読み込まれるまでには至っていません。

すべての例で、結果は異なります。 jQueryが短くなる場合があります。 時々、Reactが勝ちます。 バニラJSが両方よりも短くなる場合があります。 いずれにせよ、ここでの目標は、一方が他方より本質的に優れていることを証明することではなく、コードの長さに関して、バニラJSを使用することとフレームワークを使用することの間に大きな違いがないことを示すことでした。

結論

ほぼすべての現実の問題と同様に、黒でも白でもありません。 Web開発フレームワークを使用しないコーディングは、一部のプロジェクトにとっては最善の解決策であり、他のプロジェクトでは悪夢である可能性があります。 すべてのツールと同様に、重要なのは、ツールの使用方法だけでなく、いつ、どのように使用することの長所と短所を学ぶかです。 純粋なJavaScriptでのコーディングは、他のフレームワークとまったく同じです。習得するには、使い心地が良くなるまでに時間がかかります。

しかし、少なくとも私にとって重要な違いは、フレームワークが行き来することです。フレームワークが長い間人気があったとしても、バージョンごとに劇的に変化する可能性があります。 純粋なJavaScriptは、完全に関連性がなくなり、他の言語が出現するまで、ずっと長い間オプションになります。 それでも、特定のフレームワークから別の言語に移行できるよりも、ある言語から別の言語に直接移行できる概念と戦略が増えます。 時間と労力は、単一のプロジェクトに関してはほぼ同等であり、知識の減価償却の削減と、次の課題に取り組むことができる教訓は、考慮すべき非常に重要な要素です。