フロントエンドフレームワーク：ソリューションまたは巨大な問題？

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

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

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

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

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

ページオブジェクトモデルとは

なぜ人々はフレームを着用するのですか

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

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

時は金なり。 プロジェクトを開発していて、クライアントが使用しているフレームワークを気にしない場合（実際、クライアントはおそらく使用しているものを認識していない可能性があります）、結果を取得することだけを気にします。確立されたフレームワークを使用すると、クライアントが1日目から望んでいる、最初からすぐに進歩の感覚を作り出すことができます。また、フレームワークによって解放された時間をリダイレクトできるため、開発が早いほど、より多くのお金を稼ぐことができます。より多くのプロジェクトを引き受けます。

コミュニティがすべてです。 フレームを選ぶとき、これは非常に重要なポイントです：あなたが問題で立ち往生したときに誰があなたを助けますか？あなたと私はそれがいつか起こるだろうと知っています。フレームワークが意図していないことを行う必要がある、またはフレームワークがアクセスを許可するように設計されていないという点に到達するため、背後にコミュニティを設けることが不可欠です。あなたが仮想世界に没頭しているので、そしてあなたが唯一の人であるならば、開発-特に独立した-は難しいかもしれません フロントエンドWeb開発者 チームでは、解決策を見つけるための経験と専門知識を持っているのはあなただけであることを意味します。しかし、使用するフロントエンドフレームワークに強力な互換性がある場合、同じ問題に直面し、あなたを助けることができる誰かが世界の反対側にいるでしょう。

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

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

フレームが失敗したとき

数年前、「私はフレームを使用していません。フレームからの実質的なメリットは見当たりません」と言うと、松明とヘアピンを持った人々が玄関先にやってくるでしょう。しかし、最近では、「なぜフレームを使うべきなのか？」と尋ねる人が増えています。本当に必要ですか？それらなしでコーディングするのは難しいですか？」

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

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

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

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

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

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

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

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

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

SQLServerのパフォーマンスチューニングとは

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

これが、フレームなしでコーディングしない人が増える理由の1つだと思うので、時間をかけてこの点を個別に調べたいと思います。 DOMに何かを追加しようとしたときにほとんどのコードがどのように機能するかを見ると、.innerHTMLプロパティによって挿入されたHTMLがたくさんあることがわかります。私たちは皆、それに同意しているようですeval javascriptコードを実行するのは悪いですが、私は置きたいです .innerHTMLここで脚光を浴びています。 HTMLコードが単純な文字列として挿入されると、作成したノードへの参照が失われます。 getElementsByClassNameを使用してそれらを取得できるのは事実です。またはそれらに idを割り当てることによって、しかしこれは実用的ではありません。いずれかのノードの値を変更しようとすると、すべてのHTMLが再び返されることに気付くでしょう。

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

もあります その他の理由 近づかない.innerHTML通常。

フレームレスコーディングに関する最大の神話

時は金なり。 はい、私はこの概念を以前から持ち帰っています。多くの人は、人気のあるWebフレームワークの使用をやめれば、すぐに90年代のインターネットに切り替えると感じています。これは、みんなのお気に入りのタグであり、Geocitiesサイトの回転GIFはモダンでエッジの効いたものでしたが、AltaVistaは頼りになりました。 .Web検索、およびヒットカウンターはいたるところにありました。

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

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

仲介業者は役に立ちますか？もちろん。しかし、通常は必要ありません。フレームワークの要件に適応する必要がないため、作成するコードの各行には、より意味があります。 DOM要素を作成する方法では、要素を1行呼び出すのではなく、要素を作成してDOMにアタッチし、スタイル設定用のクラスを追加するために行が必要になるため、純粋なJavaScriptでより多くのコードを記述しているように見える場合があります。 JSX。ただし、jQueryやReactなどのライブラリを使用してコードを比較すると、バニラJSの長さは非常に似ている可能性があります。長い場合もありますが、短い場合もあります。

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

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

テストしたい

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

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

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

var brands = ['amazon', 'apple', 'nokia']; var brand_images = document.getElementById('brand-images'); for (var iBrand = 0; iBrand

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

img_out += ' '; function showImage(image){ image.parentNode.style.display = ''; }

コードを数行追加すると、jQueryとvanillaの違いは3行だけになりますが、jQueryでは、img_outの行がわかります。それは急速に成長していて非常に複雑で、一時停止して自分がしていることについて慎重に考える必要があります。ノード関数を使用して属性や関数などを追加することでDOMを直接コーディングする方が長くなる可能性がありますが、各行はより明確で正確な意味を持ち、将来の読み取りと保守が容易になります。

adobexdはいくらですか

Reactを見てみましょう：

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

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

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

結論

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

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