エントリー
トースターは私に議論する場所がないことを明快に説明してくれましたが、このトピックは私にとって重要です-ここで小さなながらも非常に落ち着いた議論を手配してください。 理性的なご意見をお聞かせください。
考え自体
プログラミングには2つの意味があることに同意すると思います。 1つ目は複雑な問題を解決するための強力なツール（簡単な場合もあります）、2つ目は創造性です。 後者ですべてが明確な場合-最適なアルゴリズムを考案するか、新しいものを作成することでプロセスを楽しんでください。前者では完全ではありません。
コードを記述すると、製品が作成されます（良いかどうかは関係ありません）。 この製品は問題の解決策です。 写真/ビデオで人を認識する必要があります-タスク、これを行うプログラムは製品であり、コードはツールです。 そしてあなたの仕事は、最終製品が最初の問題を解決することです。 私はあなたが必要なものについて話しているのではありません/ govnokodを書いて人生を楽しむことができます-いいえ、そうではありません。 アルゴリズムの最適性と消費されるリソースについて覚えておく必要があります。 しかし、私の意見では、完璧なコードの追求は良い考えではありません。 黄金の平均値を検索して検討することが常に必要です。これにより、消費される力と解の最適性の最適なバランスが得られます。
以前は、何かを開発するために、人は言語を学び、アプリケーションを構築/作成する方法を学びました。 その後、彼は製品を作成し、次のタスクに進みました。 過去の製品の一部が新しい問題を解決するために必要な場合、ソースコードが取得され、目的の状態にドラフトされました。 さらに、エントリーのしきい値は現在よりも低く、高くなっています。 以下は、言語を知っている人向けです。 何も知らない人のために。
現在、ほとんどの開発者は、完成した製品をすばやく吐き出して、そのフレームワークが使用されている製品の対価を得ようとしています。 人は特定の単語のセットを記憶し、それらを単にコピーし、出力で多かれ少なかれ完成品を得ることができます。 この場合、何が起こっているのかを理解して理解する必要はまったくありません。 そして、何かがうまくいかない場合は、フレームワークのコード全体を切り抜けて、何が間違っているのかを理解するのに多くの時間を費やします。
フレームワークの問題は、フレームワークにあなたを駆り立て、自由と理解を奪うことです。 ライブラリは、他の誰かが作成した既製の関数を提供し、必要な場所で使用できます。 同時に、あるプロジェクトから別のプロジェクトに、ある言語から別の言語に切り替える場合、ライブラリをこの言語の類似のライブラリに簡単に置き換えることができ、アプリケーションの構造を再学習/変更する必要はありませんでした。 ライブラリは、自然で裸の言語の単なるラッパーです。
フレームワークはあなたを束縛し、それ自体に結び付けます。 それぞれに独自の組み込みの作業ロジックがありますが、これは必ずしも簡単に理解できるとは限りません。 また、ある言語から別の言語に、またはあるチームから別の言語に切り替える場合、新しいフレームワークの使用方法を理解するために数日を費やすことがよくあります。 そして、プロジェクトを転送するとき、実際には、製品全体を再作成する必要があります。 裸の言語を使用した場合、このような問題に直面することはないでしょう。 言語は言語であり、チームの新しい開発者はフレームワークを理解するのにそれほど時間を費やす必要はなく、すぐに作業できます。
最も強力で人気のあるフレームワーク「vanilla.js」について最近収集しているジョークを思い出す価値があります。