あなたはJSを知りません:始められます:第1章ノート


第1章:JavaScriptは何ですか?


JavaScriptはJavaのスクリプト部分ではありません.
  • TC 39によって指定され、ECMA標準体によって正式化された言語の正式名称はECMAScriptです.

  • TC 39-JSを管理する技術的な運営委員会は、Mozilla、Google、アップルとサムスンのような異なる会社からおよそ50 - 100の人々を含みます.

  • ECMA -標準組織.
  • すべてのTC 39提案は、ここで見つかります:https://github.com/tc39/proposals

  • V 8エンジン-クロームのJSエンジン

  • Spidermonkeyエンジン- MozillaのJSエンジン
  • ウェブは(js)についてすべてを支配する

  • JSを実行する環境の配列は、常に拡大しています.
  • しかし、JSを支配する1つの環境は、ウェブです.
  • すべてのウェブ.

  • 様々なJS環境(ブラウザjsエンジン、node . jsなど)は、ユーザーのブラウザで警告スタイルボックスを開くことができるように、環境固有の機能を与えるJSプログラムのグローバルスコープにAPIを追加します.
  • これらは実際のJS仕様に記載されていません.
  • このようなAPIのいくつかのexmaplesは以下の通りです.getcurrentLocation ()getusermedia ()とfs手紙を書く.
  • コンソールさえ.log ()および他のすべてのコンソールメソッドはJS仕様では指定されていませんが、ほとんどすべてのJS環境で使用されます.
  • クロスブラウザの違いの人々のほとんどは、JSと不平不満です!クレームは実際には、JSそのものがどのように動作するかではなく、それらの環境行動がどのように働くかにおける違いによるものです.
  • 必ずしもJSではない


  • コンソール/REPL(読み取り評価印刷ループ)は、js環境ではなく、開発者ツールです.
  • 彼らの主な目的は、開発者のための生活を容易にすることです.
  • 私たちは、これらのツールの目的ではないので、JSプログラムが処理される方法に、常にそのようなツールを常に遵守するのを期待してはいけません.
  • 多くの顔

  • 典型的なパラダイムレベルのコードカテゴリは以下を含みます.

  • 手続き-は、トップダウン、線形アプローチは、事前に決定された一連の操作に従います.

  • オブジェクト指向-クラスと呼ばれる単位に論理とデータを集めます.

  • 機能-コードを関数に整理します.
  • パラダイムは、その問題に解決策に近づくためにプログラマを導く指向です。


    HaskellがFPである間、
  • Cは手続き的です、JavaとC +はオブジェクト指向です.
  • いくつかの言語は、1つ以上のパラダイムのミックスとマッチから来るコードをサポートします、これらの言語は「マルチパラダイム言語」と呼ばれています.
  • JavaScriptは、最も間違いなくマルチパラダイム言語です.

    後方へ転送

  • JavaScriptの練習後方互換性の保存.

  • 後方互換性:何かが有効なJSとして受け入れられるならば、そのコードが無効なJSになる原因となる言語へのどんな将来の変更もありません.

  • TC 39メンバーは、しばしば「我々はウェブを壊しません!」と宣言します!

  • 前方互換性:前方に互換性があることは、プログラムの言語に新しい追加を含むことが古いJSエンジンで実行された場合、そのプログラムが中断する原因にならないことを意味します.

  • JSは互換性がない.

  • HTMLとCSSは互換性があります.たとえば、2020年からコードを取り出し、古いブラウザで実行しようとすると、認識されないHTML/CSSをスキップしますが、ページを壊しません(ページが同じように見えないかもしれませんが).それらは後方互換性がありません.
  • ジャンピングザギャップ


    JS以降の
  • はフォワード互換性がないので、常に有効なJSであるいくつかのコードがありますが、古いブラウザや環境では動作しません.
  • これにより、JS開発者はこのギャップに対処するために特別な注意を払う必要がある.新しくて非互換の構文のために、解決は蒸しています.

  • Translation :新しいJS構文バージョンを古いブラウザーと環境がサポートする同等の古い構文に変換します.
  • 最も一般的なトランスポーターはBabelです.
  • は、開発者が最新のバージョンのJSを使用して、コードがきれいで、そのアイデアを最も効果的に伝えるように強く推奨します.
  • 隙間を埋める

  • 前方互換性の問題が新しい構文のためではないが、最近追加されたAPIメソッドのために、解決策は古い環境が既に定義されているかのように機能する最近追加されたAPIを定義することです.
  • このパターンはポリフィルと呼ばれます.
  • 例:
  • // getSomeRecords() returns us a promise for some
    // data it will fetch
    var pr = getSomeRecords();
    // show the UI spinner while we get the data
    startSpinner();
    pr.then(renderRecords).catch(showError).finally(hideSpinner);
    // render if successful
    // show an error if not
    // always hide the spinner
    
    このコードはES 2019機能を使用しますので、前のES 2019環境では動作しません.メソッドが存在しない場合、エラーが発生します.
    それを働かせるには、最終的にメソッドとして
    if (!Promise.prototype.finally) {
      Promise.prototype.finally = function f(fn) {
        return this.then(
          function t(v) {
            return Promise.resolve(fn()).then(function t() {
              return v;
            });
          },
          function c(e) {
            return Promise.resolve(fn()).then(function t() {
              throw e;
            });
          }
        );
      };
    }
    
    警告:これは、(完全に仕様に準拠していない)ポリフィルの簡単な説明だけです.コードにこのポリフィルを使用しないでください常に堅牢、公式ポリフィルを使用して、可能な限り、ポリフィル/コレクションシムズのコレクションのような.

    解釈には何があるか


    JSの
  • コードWriiten:それは解釈されたスクリプトかコンパイルされたプログラムですか?
  • JSが解釈されるか、またはコンパイルされたかどうかの明確な絵を持つ問題がそれにどのように扱われるかに関する本当の理由.
  • 歴史的に、解釈されるかまたはスクリプト言語は、一般にトップダウンおよびライン・バイ・ラインにおいて、実行された.
  • いくつかの言語は、実行前に処理ステップ(一般的に構文解析)を行います.この構文解析は、プログラム全体の抽象構文木(AST)を作成します.

  • JSの
  • は、実行される前にソースコードを解析します.
  • JSは構文解析言語ですが、コンパイルされますか?答えは、No .
  • よりイエスに非常に近いです
  • 解析されたJSはバイナリ形式に変換され、バイナリ形式が実行されます.
  • したがって、JSはコンパイルされた言語です.したがって、この事実のために、私たちは、それが実行される前にさえ、我々のコードの誤りについて知らせられます.

    Webアセンブリ( WASM )


    2013年の
  • 、ASM.JSはJSのランタイム性能に対する圧力に対処する1つの方法として導入されました.
  • ASM .JSはJSエンジンで動くことができた形式に変換される非JSプログラム(Cなど)のためのパスを提供することを意図しました.数年後の
  • 、別のセットのエンジニアがWebアセンブリをリリースしました.
  • WASMは、JSエンジンが正常に行う構文解析/コンパイルをスキップすることによって、JSエンジンによって処理されるアセンブリにより多くの表現形式です.
  • WASMをターゲットとしたプログラムの解析/コンパイルは、事前に起こります分散されているのはJSエンジンのために準備されたバイナリパックされたプログラムです.
  • 厳密に言えば


    ES 5(2009)のリリースによる
  • 、JSはより良いJSプログラムを励ますためのオプトインメカニズムとして「厳しいモード」を加えました.
  • JSエンジンがコードを最適化し、効率的に実行する絶好のチャンスがあるように、最善の方法をガイドとして考えるべきです.
  • 厳密なモードは特別なpragmaでファイルごとに切り替えられます(コメント/空白を除く前に何も許されません).
    // only whitespace and comments are allowed
    // before the use-strict pragma
    "use strict";
    // the rest of the file runs in strict mode
    
  • 厳格モードは、代わりに、1つの機能範囲
  • の上でオンにされることができます
  • 興味深いことに、ファイルが厳格モードになった場合、関数レベルのstrict modeプラグマは禁止されます.だから、1つまたは他を選択する必要があります.
  • これがこの章です.次の章のノートで戻ります.
    それまで、ハッピーコーディング!
    これらのノートを読んで楽しんだり、提案や疑問がある場合は、コメントであなたの意見を聞かせてください.
    以下のリンクに従ってください.
    唐辛子