JavaScriptフレームワークはまだ必要ですか?

Web開発者として、私はツールボックスを定期的に評価し、このツールまたはそのツールなしで実行できるかどうかを判断しようとしています。最近、フロントエンドフレームワークなしで複雑なフロントエンドアプリケーションを開発することがいかに簡単かを調査しています。

JavaScriptフレームワークとは何ですか?

簡単に言うと、JavaScriptフレームワークは、高度なWebアプリケーション、特にSPAを開発するために活用できるツールです。

当時、Web開発者は、バニラJSとjQueryに大きく依存することでフロントエンドロジックを実装していました。しかし、フロントエンドアプリケーションがますます複雑になるにつれて、ツールはその複雑さに対応するようになりました。

今日人気のあるフレームワークには、いくつかのコア共通点があります。VueからReactまでのほとんどのフロントエンドフレームワーク/ライブラリは、次の組み合わせを提供します。

  • 状態とビューの同期
  • ルーティング
  • テンプレートシステム
  • 再利用可能なコンポーネント

フレームワークはまだ必要ですか?

それはあなたが必要な言葉をどのように強調するかに依存します多くの人が、フロントエンドフレームワークは必要ではなく、必要でなかったと主張するでしょう。ただし、これらは非常に便利なツールです。

だから問題は:フレームワークは今日のjQueryですか?彼らが解決する問題は、DOM APIへの変更のような変更によって対処されますか?

言うのは難しいですが、ネイティブJS、Webコンポーネントの仕様、および簡単に構成できるビルドツールの進歩により、フレームワークなしのSPAの開発がこれまでになく簡単になりました。

これをさらに調べるために、バニラJavaScript、ネイティブWebコンポーネント、およびParcelのみを使用してシングルページアプリケーションを開発しました。JSフレームワークの長所を浮き彫りにする、いくつかの落とし穴と困難がありました。

同時に、最初のハードルを超えた後、バニラJSだけでシングルページアプリケーションを作成することがいかに簡単であるかに驚きました。

概要概要

アプリケーションは簡単です。これは、基本的なCRUD機能を備えたレシピアプリケーションです。ユーザーは、レシピのリストを作成、編集、削除、お気に入りに追加、およびフィルタリングできます。

コンポーネント

Webコンポーネントの作成も簡単です。拡張HTMLElement(またはHTMLParagraphElementなど)するクラスを作成し、そのクラスを使用してカスタム要素を定義します。

また、connectedCallback、disconnectedCallback、attributeChangedCallbackなどのライフサイクルフックを利用することもできます。

ルーティング

レシピアプリケーションのルーティングも非常に簡単です。ナビゲーションイベントが与えられた場合、アプリケーションのコンテンツを対応するWebコンポーネントに設定します。

当初、私はVanillaJSRouterと呼ばれるnpmパッケージを使用していました。ブラウザ履歴APIを使用すると、100行未満のコードで独自の実装を行うのはそれほど複雑ではありません。注:ルートガードなどの非常に複雑なロジックは実装していません。

それは簡単な要約です。この記事を妥当な長さに保ちたいと思います。アプリケーションのより完全な説明を含むフォローアップ投稿を書くことがあります。無限スクロール、カスタムドラッグアンドドロップアップローダーなどの楽しい機能をいくつか実装しました。

回顧展

アプリケーションを作成した後、最初から最後までのプロセス全体の長所と短所について考えるのに少し時間がかかりました。悪い知らせから始めましょう。

短所

スペックはまだ流動的です

Webコンポーネントの仕様は古いものと新しいものの両方です。それは私が最初に思っていたよりずっと長い間存在していました。Webコンポーネントは、Fronteers Conference2011でAlexRussellによって初めて紹介されました。ただし、Webコンポーネントの背後にあるプッシュは、過去1〜2年で実際に成長しました。そのため、仕様にはまだ多くの混乱があります。たとえば、HTMLのインポートは中止されましたが、ほとんどのドキュメント/リソースはまだそれらを参照しています。

テスト

ネイティブWebコンポーネントをテストするための専用のリソースはそれほど多くありません。skatejsssrやPolymerのWebコンポーネントテスターなどの有望なツールがいくつかあります。しかし、これらのツールは実際にはそれぞれのライブラリで使用するためのものです。これは、ネイティブWebコンポーネントでの使用にいくつかの問題をもたらします。

変化の検出

ビューをデータモデルと自動的に同期させる基盤となるシステムがあることは素晴らしいことです。そもそもAngularや他のフレームワークに多くの人を惹きつけたのはそれです。

状態をビューと同期させることは、小規模ではそれほど難しくありません。しかし、それはすぐに制御不能になる可能性があり、大量のイベントリスナーとクエリセレクターを追加していることに気付くでしょう。

ShadowDOM

私はシャドウDOMについて本当に引き裂かれています。一方で、私はカプセル化のアイデアが大好きです。これは賢明なデザインパターンであり、スタイルカスケードをより管理しやすくし、懸念事項を簡素化します。ただし、特定のもの(共有スタイルシートなど)をそのカプセル化に浸透させたい場合にも問題が発生し、これを行うための最良の方法については継続的な議論があります。

DOM構造の生成

AngularやReactのようなフレームワーク/ライブラリの素晴らしさの一部は、それらがDOMainのマスターであるということです。つまり、DOMで構造を効率的にレンダリングおよび再レンダリングするのに優れています。AngularUniversityブログから:

AngularはHTMLを生成してからブラウザーに渡して解析するのではなく、AngularがDOMデータ構造を直接生成しています。

たとえば、Angularは、jQueryとは異なり、DOMデータ構造を直接レンダリングします。つまり、HTMLをブラウザに渡して解析し、DOMデータ構造にレンダリングする代わりに。これは、その解析ステップを排除するため、よりパフォーマンスが高くなります。仮想DOMは、ビューを更新する必要があるたびにすべてを再レンダリングすることを防ぐため、非常に便利です。

長所

一方、この方法でアプリケーションを開発することには、否定できない利点がいくつかあります。

バンドルサイズ

最終製品は、最新のフレームワークで開発されたものよりもはるかに小さく、コンパクトになる可能性があります(缶に重点を置いています)。たとえば、フル機能のレシピアプリの最終ビルドは、新しいAngularビルドの半分未満のサイズでした。

注:これらは、更新され、最適化されたバンドルサイズです。

理解

フレームワークとそのCLIを使用して実際に開発しただけの場合は、追加のツールを使用せずにWebアプリケーションを作成することは素晴らしい演習になる可能性があります。Web開発をある程度(可能な範囲で)習得したい人として、ビルドツール、ブラウザーAPI、デザインパターンなどを実際に体験することが不可欠です。

パフォーマンス

これらのフロントエンドフレームワークとライブラリが舞台裏で行っていることは驚くべきことです。ただし、それらのいずれかを使用することにした場合は、パフォーマンス価格を支払うことができます。無料のランチなどはありません。無駄な再レンダリング、冗長なリスナー、詳細なオブジェクト比較、不要で大規模なDOM操作など、大規模なパフォーマンスの低下が発生する可能性があります。ゼロから実装することで、ここで多くの複雑さを取り除くことができます。

AngularチームとReactチームはこれらの落とし穴を認識しているようで、パフォーマンスをさらに最適化する手段として、shouldUpdateメソッドのオーバーライドやonPushChangeDetectionなどを提供しています。

シンプルさとコードの所有権

サードパーティのコードを持ち込むときはいつでもリスクを冒します。このリスクは、試行錯誤されたライブラリ/フレームワークによって軽減されますが、真に排除されることはありません。自分自身またはチームでコードを書くことをやめることができれば、そのリスクを減らし、内外で知っているコードベースを維持することができます。

メモと興味深い情報

私はParcelで大いに働いていました。特定のエッジケースを回避しようとすると、Webpackよりも少し制限されているように感じましたが、ほとんどの場合、「zeroconfig」タグラインが当てはまることがわかりました。

また、多くのレーベルReactが「ライブラリ」でVueが「プログレッシブ」フレームワークであることも私には明らかです。私はこの理由を理解していますが、React、Vue、Angularは同じ問題の多くを解決すると思います。したがって、私は「フレームワーク」という用語の下でそれらをすべて一緒に検討しています。

ステンシルやポリマーを使ってみませんか?パッケージ、ライブラリ、フレームワークの使用はできるだけ避けたかったのです。私は、(ビルドツールを除いて)現代の開発に対応するためにWeb標準がどこまで上昇したかを見たかったのです。

主要なフレームワークやライブラリを使用せずに、SPAまたはフロントエンドアプリケーションを開発する方法は他にもたくさんあると思います。ここで1つの方法を試しましたが、他の方法についても聞いてみたいと思います。

概要

フレームワークを使用するかどうかを決定するための優れたヒューリスティックは、私が「転換点」と呼んでいるものです。アプリケーションが成長するにつれて、機能と構造を再利用するために独自のフレームワークを作成することになります。たとえば、フォームがたくさんあり、事後検証用の再利用可能なロジックを作成したいとします。

この時点で終わった場合は、フレームワークまたはライブラリですばやく達成できることを達成するために、システムの作成に時間を費やす価値があるかどうかを判断する必要があります。時間の制約や予算の制約に応じてさまざまな転換点がありますが、適切なシナリオがあれば、フレームワークは依然として非常に関連性があります。

とは言うものの、フレームワークが行うことの多くは、時間が経つにつれて、おそらく小さなライブラリやネイティブコードでより簡単に行えるようになるでしょう。例として私のアプリケーションを取り上げます。同時に、大規模なフレームワークとライブラリが多用途のままである場合、それらは変形し、適応し、固執する可能性があります。そうでない場合は、jQueryのようになってしまう可能性があります—ほとんどの場合、過去のツールです。

結論

結論として、フレームワークなしで複雑なフロントエンドアプリケーションを開発する有望な方法があります。ただし、Webコンポーネントなどの仕様はまだ進化しており、解決すべき問題があります。フレームワークはまだ多くの驚くべきことを行い、開発をはるかにスムーズにすることができます。

現時点では、私が知る限り、フレームワークを使用することの長所は短所を上回ることがよくあります。ただし、フレームワークが新しい問題の解決を開始せず、進化し続けない場合、フレームワークは最終的には消えていきます。

リソース

初心者向けAngularガイド:なぜAngularなのか?主なメリット

注:この投稿は、進行中のAngular for Beginnersシリーズの一部です。完全なシリーズは次のとおりです:Angular ForBeginners blog.angular-university.io他のフレームワークとの比較-Vue.js

Vue.js-プログレッシブJavaScriptフレームワークvuejs.orgパフォーマンスの最適化-React

内部的には、Reactはいくつかの巧妙な手法を使用して、… reactjs.orgWebコンポーネントの更新に必要なコストのかかるDOM操作の数を最小限に抑えています。

開発者として、コードを可能な限り再利用することは良い考えであることは誰もが知っています。これは伝統的にそうではありませんでした… developer.mozilla.org現代のJavaScriptフレームワークが存在する最も深い理由

React、Angular、Vue.jsなどの最新のフレームワークを盲目的に使用している人をたくさん見ました。これらのフレームワークは… medium.com共有スタイルシートを使用したWebコンポーネントのスタイリングを提供します

Webコンポーネントは、Webの驚くべき新機能であり、開発者が独自のカスタムHTML要素を定義できるようにします… www.smashingmagazine.com