[1~2章]モダンWebフロントエンド

（追記でJavaScriptの誕生についてもChatGPTで）
（最初はミルクボーイ風にやってもらったが、あまりにもミルクボーイだったので、スタンダップコメディやモンティパイソンの風味を入れてもらった）

シャカとYESの「JavaScript誕生物語」

シャカ
「皆さん、聞いてくださいよ。1995年に、たった10日間で生まれたプログラミング言語があるらしいんですよ！」

YES
「10日間？すごいですね！その10日間、私は毎日寝ながら『プログラムをする夢』を見るだけで終わりましたけどね。」

シャカ
「で、その言語、名前が『JavaScript』らしいんですけど、実は最初は違う名前だったんです！」

YES
「名前違う？ほな、名前はなんやったんです？」

シャカ
「『LiveScript』って言うてたらしいですよ。」

YES
「LiveScript？生きてるスクリプトってことですか？…死んでるスクリプトと何が違うんです？」

シャカ
「さあ、それは分かりませんけどね、Netscapeって会社が作ったらしいです。」

YES
「Netscape？ああ、ブラウザの恐竜ですね！…って、そもそも名前を変えた理由はなんですか？」

シャカ
「それがですね、『Javaって名前を入れたら売れそう』っていうマーケティングの理由ですよ。」

YES
「マーケティングの理由で名前変えたんですか？そんなこと言ったら、私も今日から『シャネルYES』に改名しますわ！」

---

シャカ
「でも、この言語、Javaって名前が入ってるのに、Javaとは全然関係ないらしいですよ。」

YES
「ほな、名前詐欺やないですか！それ、ラベルに『有機栽培』って書いてるのに、実はプラスチックだった野菜やん！」

シャカ
「さらに、作ったのがたった10日間って話なんです。」

YES
「10日間でプログラミング言語？そんなん、私が10日間で建てた家と同じくらい信用ならん！」

シャカ
「しかも、最初は『型の管理』がむちゃくちゃやったって言われてるんですよ。」

YES
「型がむちゃくちゃって…それもう、プログラムやなくて詩やないですか！いや、むしろラップや！『Yo! 変数が何かわからないけど動くYo!』って！」

---

シャカ
「でも誕生の背景には、『Netscape』と『Microsoft』のブラウザ戦争があったんです。」

YES
「ブラウザ戦争？それ、現代の戦争で言うたら、『TikTok vs Instagram』くらいの規模ですか？」

シャカ
「まあ、それくらい壮絶だったらしいですけど、戦争のために10日間で作ったって話、どう思います？」

YES
「それ、軍隊の補給物資をダクトテープで修理したみたいな感じですやん！そら、のちのちバグだらけになりますよ！」

シャカ
「でも、今やJavaScriptはサーバーでも動くようになったんです。」

YES
「ほな、それもう最初の話と全然ちゃうやん！昔の竹槍が、今や核ミサイルくらいの進化遂げたって話やろ！」

---

シャカ
「でも、今ではWebフロントからサーバー、アプリまで、何でも動く万能言語ですよ！」

YES
「それ、まるで『万能薬』って言われたら、めっちゃ苦いハーブ出されるやつやん！ほんまに使えるんか？」

シャカ
「いや、ほんまに使えてますよ。しかも、世界中の開発者が改良を重ねた結果なんです！」

YES
「それ、つまり『最初はクソだったけど、みんなで育てた結果ええ子になった』って話やないですか！Web版の『ベスト・キッド』か！」

---

シャカ
「結局、JavaScriptって名前だけじゃなく、みんなの力で今の地位に登り詰めたわけですよ。」

YES
「いやいや、それもこれも最初の10日間があったからやろ？つまりこう言いたいんです。『雑でもとりあえず作ってみたら、なんとかなることもある』と！」

シャカ
「それ、プログラミング界の真理やん！でも、雑なコードの後始末で泣くのは未来の自分ですよ。」

YES
「未来の自分に感謝！ありがとうJavaScript！でも僕、明日からPython使いますわ。」

全員：
「ほな、JavaScript、ありがとう！」（なぜか観客に拍手を求める）

---

こんな感じで、モンティパイソン風の風刺や皮肉、観客に語りかける不条理感を追加してみました！

（さらにフロントエンド開発の歴史をブラウザの変遷と交えて説明してもらった）
https://chatgpt.com/share/67466743-4c74-8008-9b2b-43988837ba92

ブラウザの変遷と交えたフロントエンド開発の歴史

Webフロントエンド開発の変遷は、ブラウザ技術の進化と密接に関係しています。ブラウザが進化するたびに、開発者が使える技術も飛躍的に進歩しました。以下に、ブラウザの趨勢とフロントエンド技術の進化を絡めて説明します。

---

1. 静的Webサイト時代 (1990年代)

主要ブラウザ: Mosaic → Netscape Navigator → Internet Explorer 3

この時代はWebの黎明期で、ブラウザの進化そのものがWeb体験を定義していました。

• Mosaic (1993):

  • 初のグラフィカルブラウザ。
  • 画像とテキストを同じ画面に表示できる画期的な技術。

• Netscape Navigator (1994):

  • Mosaicをベースに進化。
  • フォームやテーブルが使えるようになり、HTMLが少しリッチに。

• Internet Explorer 3 (1996):

  • Microsoftが開発。
  • CSS1に初対応し、デザインのカスタマイズが可能に。

技術的変化:

• HTML 2.0が標準化され、基本的な構造が整備。
• 静的なWebサイトが主流。デザインの自由度はまだ低かった。

ブラウザ戦争の始まり:

• Netscape NavigatorとInternet Explorerが競争し、各ブラウザが独自仕様を導入。互換性問題が多発。

---

2. デザインとインタラクションの進化 (1995年–2000年)

主要ブラウザ: Internet Explorer 4 → Netscape 4

ブラウザ戦争が本格化し、各社が新機能を競って追加しました。

• Internet Explorer 4 (1997):

  • DHTML（Dynamic HTML）をサポート。
  • DOM操作が可能になり、動的コンテンツが実現。

• Netscape 4 (1997):

  • JavaScriptとCSSの実装に対応。
  • ただし、CSSの実装が不完全で、開発者泣かせの仕様。

技術的変化:

• CSS1（1996年）: デザインとHTMLの分離が可能に。
• JavaScript（1995年）: 動的な動作を追加できるスクリプト言語。
• HTML 4.01（1999年）: フォームや表形式のレイアウトが整備。

ブラウザ戦争の影響:

• 独自タグ（例: <marquee>）や非標準の実装が広がり、互換性問題が深刻化。
• 開発者は複数ブラウザに対応するための多大な労力を強いられた。

---

3. ダイナミックなWebの時代 (2000年–2010年)

主要ブラウザ: Internet Explorer 6 → Firefox → Google Chrome

この時代は、Internet Explorerの一強時代から、FirefoxとChromeが挑む構図へと変化しました。

• Internet Explorer 6 (2001):

  • 当時は革新的なブラウザだったが、標準仕様への準拠が不十分。
  • 長期間アップデートされず「古代兵器」として後々批判される。

• Firefox (2004):

  • Netscapeの後継。W3CのWeb標準に準拠し、開発者に支持される。
  • 初めてタブブラウジングを普及させた。

• Google Chrome (2008):

  • V8エンジンを搭載し、JavaScriptの実行速度が飛躍的に向上。
  • シンプルなUIと高速な動作で急速にシェアを拡大。

技術的変化:

• Ajax（2005年）:
  • ページ全体をリロードせず、部分的に更新可能。
  • GmailやGoogle MapsがAjaxを活用して注目を浴びる。
• jQuery（2006年）:
  • JavaScriptでのDOM操作を簡略化し、開発効率を向上。
• HTML 4.01とCSS 2.1:
  • 標準化が進み、ブラウザ間の互換性が向上。

ブラウザの進化:

• FirefoxがWeb標準の普及を促進。
• Chromeが高速化とモダンなJavaScript開発を推進。

---

4. モダンWebの幕開け (2010年–2020年)

主要ブラウザ: Google Chrome → Firefox → Safari → Edge (Chromium版)

Chromeが市場を席巻し、Web標準化が加速する時代。

• Google Chromeの支配:

  • 高速なJavaScriptエンジン（V8）と頻繁なアップデートで他を圧倒。
  • 開発者ツール（DevTools）が充実。

• Firefoxの地位低下:

  • Chromeの高速性に押されるが、プライバシー重視の姿勢で一定の支持を維持。

• Edge（2015年）→ Chromium版Edge（2020年）:

  • MicrosoftがInternet Explorerを廃止し、ChromiumベースのEdgeに移行。
  • ブラウザ間の互換性が劇的に改善。

技術的変化:

• HTML5とCSS3:
  • ビデオや音声の埋め込み、Canvas描画が標準化。
  • CSS3でアニメーションやレスポンシブデザインが実現。
• モダンフレームワーク:
  • React（2013年）: コンポーネントベースの開発。
  • Vue.js（2014年）: 軽量で柔軟。
• モジュールバンドラ（Webpackなど）:
  • コードの効率的な管理と最適化を実現。

ブラウザの趨勢:

• Chromeが圧倒的なシェアを持つ一方で、FirefoxやSafariが差別化戦略を展開。
• EdgeがChromiumベースに移行し、互換性問題が大幅に緩和。

---

5. 現代と未来 (2020年以降)

主要ブラウザ: Google Chrome → Safari → Edge → Firefox

現代では、ブラウザがWeb開発そのものの方向性をリードするようになっています。

• ブラウザのエンジン戦争:

  • Chromium（Google Chrome, Edge, Brave） vs. WebKit（Safari） vs. Gecko（Firefox）。
  • Chromiumベースが主流化し、ブラウザ間の差異が縮小。

• 新しい技術と標準:

  • WebAssembly（Wasm）: 高速なWebアプリを実現。
  • WebGPU: 高度なグラフィック処理。
  • Service Workers: オフライン対応やプッシュ通知を実現。

• Jamstackと静的サイトジェネレーター:

  • GatsbyやNext.jsで高速なWeb体験を提供。
  • API中心のアーキテクチャが主流に。

未来のブラウザの役割:

• AIやAR/VR技術との統合。
• より軽量でエネルギー効率の良い設計。
• プライバシー保護とセキュリティの強化。

---

ブラウザはWeb技術の発展とともに進化し、フロントエンド開発者が可能性を広げる「舞台装置」として重要な役割を果たしてきました。今後もその進化は続くでしょう。

（オブジェクト指向が出てきたので、こちらも改めて調べ直す）

オブジェクト指向

オブジェクト指向（Object-Oriented）は、ソフトウェア開発やプログラミングにおける設計思想の一つで、データとそれに関連する処理（メソッド）を一つの「オブジェクト」としてまとめ、システム全体を構築する手法です。このアプローチにより、再利用性や保守性が向上し、複雑なシステムの管理が容易になります。

主な特徴:

1. カプセル化: データ（属性）とそれに関連する処理（メソッド）を一つのオブジェクトにまとめ、外部から直接アクセスできないようにすることで、データの保護とモジュール化を実現します。

2. 継承: 既存のオブジェクトの特性や機能を引き継ぎ、新しいオブジェクトを作成することで、コードの再利用性を高めます。

3. ポリモーフィズム（多態性）: 同じメソッド名であっても、オブジェクトの種類によって異なる動作をさせることができ、柔軟な設計が可能となります。

オブジェクト指向のメリット:

• 再利用性の向上: 一度作成したオブジェクトやクラスを他のプロジェクトでも活用でき、開発効率が向上します。

• 保守性の向上: オブジェクトごとに機能が分離されているため、特定の部分の修正や拡張が他の部分に影響を与えにくく、メンテナンスが容易です。

• 拡張性の向上: 新しい機能の追加や変更が容易で、システムの成長や変化に柔軟に対応できます。

オブジェクト指向は、現代の多くのプログラミング言語（Java、C++、Pythonなど）で採用されており、複雑なシステムの設計や開発において重要な役割を果たしています。

コンポーネント指向とオブジェクト指向の違いのまとめ、コンポーネント指向フレームワーク以前のWebフロントエンド開発の振り返り

＊コンポーネント指向とオブジェクト指向の違い
└単純に捉えると、構成単位の違い。開発する対象と目的によって選択されてきた設計思想の違い。
└オブジェクト指向はメソッドやシステムを単位にして再利用する。
└コンポーネント指向はボタンやアイコンなどの分割できないレベルを最小単位にする。
└極端に捉えると、オブジェクト指向はエンジンやコンバータやブレーキモジュールという単位で扱い、コンポーネント指向はネジなどの単一部品を単位に扱う。

＊考察
└深く考えれば、コンポーネントを組み合わせていけば、それはオブジェクト指向でいうところのオブジェクトになっていくのではないか、とも考えられるが、結果的にそれは同様に見えるだけで、オブジェクト指向で扱うオブジェクトはコンポーネントに分解すると逆に扱いづらくなったり煩雑になると思われるので、そういう捉え方が必要ないのではないかと考えられる（そもそも、その設計思想になるまでの過程が違うのもあるだろう）。

＊以前のWebフロントエンド開発
（ここでコンポーネント指向フレームワーク以前を振り返ると、なぜコンポーネントなのかが明らかになる）
（これもChatGPT）

Q.Webフロントエンド開発で、その初期からコンポーネント指向フレームワークの登場以前までは、どんな設計思想だったのか？

A.Webフロントエンド開発の初期からコンポーネント指向フレームワークが登場する以前は、主に以下のような手法や指向が採用されていました。

1. 静的HTMLとCSSの利用: 初期のウェブサイトは、静的なHTMLファイルとCSSを用いて構築されていました。各ページは独立して作成され、再利用性や動的な要素はほとんど考慮されていませんでした。

2. サーバーサイドレンダリング（SSR）: PHPやASPなどのサーバーサイド技術を使用し、サーバー上でHTMLを生成してクライアントに送信する手法が一般的でした。この方法では、ページの更新やユーザーインタラクションに対してサーバーとの通信が必要となり、ユーザー体験が限定的でした。

3. jQueryなどのJavaScriptライブラリの活用: クライアントサイドでの動的な操作やDOM操作を容易にするために、jQueryなどのライブラリが広く使用されました。しかし、これらは主に既存のHTMLに対して動的な効果を追加するものであり、構造的な再利用性や大規模開発に適した設計思想は含まれていませんでした。

4. モジュール指向: JavaScriptのモジュール化を進めるために、RequireJSやCommonJSなどのモジュールローダーが使用されました。これにより、コードの分割や再利用が促進されましたが、UIコンポーネントの再利用や状態管理に関する包括的な指向はまだ確立されていませんでした。

これらの手法は、ページ単位や機能単位での開発が中心であり、UI要素の再利用性や状態管理の一貫性を高めるためのコンポーネント指向の概念は、ReactやVue.jsなどのフレームワークの登場以降に普及しました。

＊考察とまとめ
└大雑把にまとめるとすると、Webフロントエンド開発は粗削りな状態からどんどん洗練されていった過程があり、現在は「細かいパーツと仕組みに分けて、それを管理・運用できるシステムを構築していこう！」となっている状態である。
└そもそも初期の状態はパーツと仕組み、それ自体の概念や技術が土台に出来ていなかったのもあるだろうし、ブラウザの競合やフレームワークの競合、ユーザーの需要の変化など、安定しきらない状態にあったということもあるだろう。

それぞれの成立の経緯

（それぞれの成立の経緯をChatGPTにまとめてもらった）

＊成立の経緯

Atomic Design

Atomic Design（アトミックデザイン）は、2013年にアメリカのウェブデザイナーであるBrad Frost氏によって提唱されました。 この手法は、UI（ユーザーインターフェース）を最小単位から階層的に組み立てることで、デザインの一貫性と再利用性を高めることを目的としています。

1. ウェブデザインの複雑化: 2010年代初頭、ウェブサイトやアプリケーションの機能が高度化し、デザイン要素も複雑化していました。 これにより、デザインの一貫性や効率的な開発手法が求められるようになりました。

2. モジュール化の必要性: 複雑なデザインを効率的に管理・再利用するため、UIコンポーネントのモジュール化が重要視されていました。 この流れの中で、Atomic DesignはUIを「Atoms（原子）」「Molecules（分子）」「Organisms（有機体）」「Templates（テンプレート）」「Pages（ページ）」の5つの階層に分けて考える手法を提案しました。

3. コンポーネント指向フレームワークの登場: 同時期に、React（2013年）やVue.js（2014年）などのコンポーネント指向のJavaScriptフレームワークが登場し、UIの再利用性や保守性を高めるアプローチが広がりました。 これらのフレームワークは、Atomic Designの概念と親和性が高く、デザインと開発の統合を促進しました。

4. デザインシステムの普及: Atomic Designの提唱後、デザインシステムの構築が注目されるようになり、企業やプロジェクト単位でのデザインの一貫性と効率性を追求する動きが加速しました。

これらの背景から、Atomic Designはデザインと開発の両面で効率的かつ一貫性のあるUI構築手法として広く受け入れられるようになりました。

React

Reactは、2011年にFacebookのソフトウェアエンジニアであるジョーダン・ウォーク氏によって開発されました。当時、Facebookの広告管理アプリケーションは機能の複雑化に伴い、コードベースが大規模化し、保守が困難になっていました。この課題を解決するため、ウォーク氏はFaxJSというプロトタイプを作成し、これが後のReactの基盤となりました。

2011年、FacebookのニュースフィードでReactが初めて使用され、翌年にはInstagramでも採用されました。そして2013年5月、Reactはオープンソースとして一般に公開され、開発者コミュニティから広く受け入れられるようになりました。

Reactの登場は、ウェブ開発におけるUI構築の方法に革新をもたらしました。特に、コンポーネントベースのアーキテクチャや仮想DOMの導入により、UIの再利用性やパフォーマンスが向上しました。これにより、開発者は複雑なユーザーインターフェースを効率的に構築・管理できるようになりました。

その後、2015年にはReact Nativeが発表され、Reactのコンセプトがモバイルアプリケーション開発にも拡張されました。これにより、ウェブとモバイルの両方で一貫した開発手法が可能となり、Reactの普及がさらに加速しました。

このように、ReactはFacebook内部の課題解決から始まり、オープンソース化を経て、ウェブおよびモバイル開発における主要なライブラリとしての地位を確立しました。

---

これに続いて次のような質問をした。

エンジニアやデザイナーなどでは共通の問題解決や発展性に対する認識があったが、それを言語化したのがAtomic Designで、構造化したのがフレームワーク？
登場が同時期だったのはたまたま？

↓回答は以下

おっしゃるとおり、Atomic Designとコンポーネント指向フレームワークは、共通の問題意識や課題を背景にして登場しましたが、それぞれが独立して発展し、時期が近かったのは「たまたま」というよりも必然的な流れだったと言えます。以下に詳しく説明します。

---

共通の問題意識

1. 複雑化するUI設計と開発

   • Webアプリケーションの規模拡大に伴い、デザインやコードの一貫性を保つことが難しくなっていました。特に、再利用性の低い設計やスパゲッティコードは保守性の大きな課題でした。

2. デザイナーとエンジニアの連携

   • デザインと実装が乖離する問題がありました。デザインコンポーネントがコードと対応していないため、変更や拡張のたびに両者の間で齟齬が生じていました。

3. 再利用可能性とモジュール化の必要性

   • 再利用可能なUIコンポーネントを構築することは、作業効率を上げるだけでなく、デザインと実装の一貫性を担保する上で重要な課題として認識されていました。

---

Atomic Designの登場と役割

• Brad Frostが2013年に提唱したAtomic Designは、上記の問題を「言語化」し、UIを構造的に考えるフレームワークとして提供しました。
• デザイナーやエンジニアが共通言語として利用できるよう、UIを「原子（Atoms）」「分子（Molecules）」「有機体（Organisms）」といった階層に分ける明確なモデルを提示しました。

---

コンポーネント指向フレームワークの登場

• 同時期（2013年）のReact.js登場が象徴するように、コンポーネント指向フレームワークは、「コードの再利用性」「UIの状態管理」「宣言的プログラミング」のニーズを解決する技術的な基盤を提供しました。
• これにより、Atomic Designの考え方が技術的に支えられるようになり、設計と実装のギャップを埋める実用的な道具が整いました。

---

登場時期が近かった理由

Atomic Designとコンポーネント指向フレームワークの登場がほぼ同時期だったのは、たまたまではなく、以下のような背景が影響しています。

1. Webアプリケーションの進化

   • 2010年代初頭、モバイルファーストやレスポンシブデザインが普及し、複雑なUI設計が求められるようになりました。

2. 再利用可能なモジュールへの需要

   • デザイナーとエンジニアが共通の課題に直面し、それに応える形でAtomic Design（設計の思想）とReact.js（技術的解決策）が登場しました。

3. 業界の成熟

   • Web技術が成熟し、課題が共通化された結果、設計と実装の両面で構造化・最適化の動きが同時進行したと考えられます。

---

まとめ

• Atomic Designは問題を「言語化」して設計の指針を提供し、コンポーネント指向フレームワークはそれを「構造化」して技術的に実現しました。
• 両者の登場時期が近かったのは、業界全体が抱えていた課題への必然的な対応の結果であり、技術と設計思想が相互補完的に発展した事例といえます。

このように、デザインと開発の統合が進む時代背景の中で、Atomic Designとフレームワークは並行して進化し、互いに強い関連性を持つに至りました。

---

＊総評
Brad Frost氏がAtomic Designを提唱したのが2013年であり、ReactはFacebook(Meta)内部の事情により2011年に開発されたとある。そして、2013年5月、Reactはオープンソースとして一般に公開されている。
Brad Frost氏がいつ頃からAtomic Designの構想を考えていたのかは調べられなかったが、問題意識としては2010年代初頭からデザイナーとエンジニアの共通のものだったのではないかと思われ、設計の思想と技術的解決策という別のアプローチでありながら、結果的に符合したのではないかと考えられる。
色々違う点はあるが、これはまるでスタンド・アローン・コンプレックスのようで、とても奇妙な感覚の現象だ。
しかしChatGPTが返したように、当時の状況的にはこれらの設計思想と技術的解決策が考えられたのは「必然的な流れ」であり、「たまたま」ではなく、出来ることをどんどん増やしていったWebフロントエンド開発が、ある時点でそれらを収束させた結果であると見た方が妥当だろう。

なんで静的型付けなのか？

＊そもそも「型」とは？
（以下もChatGPT）

プログラミングにおける「型」とは、データの種類やその取り扱い方法を定義する概念です。例えば、整数、浮動小数点数、文字列、論理値などがあり、それぞれの型に応じてメモリ上の表現や操作方法が異なります。

静的型付けと動的型付けの違い:

• 静的型付け:

  • 型の決定時期: コンパイル時に変数や関数の型が決定され、型チェックが行われます。
  • メリット: 型の不一致やエラーを早期に発見でき、コードの安全性とパフォーマンスが向上します。
  • デメリット: 型を明示的に宣言する必要があり、コードが冗長になる場合があります。

• 動的型付け:

  • 型の決定時期: 実行時に変数や関数の型が決定され、型チェックが行われます。
  • メリット: 型宣言が不要で、コードが簡潔になり、開発の柔軟性とスピードが向上します。
  • デメリット: 実行時に型エラーが発生する可能性があり、デバッグが難しくなることがあります。

静的型付け言語の例として、Java、C、C++、Rust、Goなどがあり、動的型付け言語の例として、Python、Ruby、JavaScript、PHPなどがあります。

静的型付けは、大規模なプロジェクトやチーム開発において、コードの明確性や保守性を高めるのに有効です。 一方、動的型付けは、小規模なスクリプトやプロトタイピングに適しており、開発速度を重視する場合に有用です。

＊分かりやすくしてみる
￥基本の考え方
└根本から考えれば、プログラミングはコンピュータくんにやってもらいたいことを伝える「呪文」。
└でもコンピュータくんは頭が良いけど世間知らずなので、「お前を消す方法」と伝えても、それがUnicodeの文字列とは理解できるかもしれないけど、何をやってほしいのかはわかってくれません。大雑把にいえば、最近のAIの目指しているところは「お前を消す方法」と聞いたら、ネットからカイル君のネタ画像を探してきてくれたり、「私のことは消さないで(´;ω;｀)」とリアクションしてくれるようなことです。
└コンピュータは最小単位だと"0"と"1"、論理的に捉えると"YES"か"NO"で認識します。
└そして「"これ"は"こういうこと"だよ」と教えていくのがプログラミングでもあります。

￥具体化
└さっきの例でいえば、まず「カイル君」＝「文字列」、「やってもらいたいこと」＝「Microsoft OfficeからGoogleドキュメントに乗り換える」などを教えなければなりません。
└バイトの入りたての時期には、先輩から色々教えてもらうようにです。
└ここが大雑把に言うと定数、変数、型の定義といったこと。

└それを教え切ったあと、「教えたことを元に、こういう処理をして」とさらに教えられれば、それがスクリプトやプログラムになります。そうするとコンピュータくんは頭が良いので、人間が真似できないスピードで仕事をしてくれます。
└ここが一般的にプログラミングでイメージされる部分であり、具体的に何をしてもらいたいかの部分。

￥それでいうと「型付け」とは？
└例えばコンビニなんかでのバイトだとすると、タバコが欲しいお客さんは「セブンスター」とか「キャメル」とか言ってくるかもしれませんが、タバコを吸わない店員さんはどれかすぐに分かりません。
└コンビニのレジ奥を見ると分かるように、タバコの種類は多いので、番号が付けられています。喫煙者であっても把握しきれないかもしれません。
└これをコンピュータくんの例に直すと、「"1"は"セブンスター"」と教えておいて、お客さんが「"1"」と言ったら「"セブンスター"」を出すように事前に教えておけば、コンピュータくんはお客さんが言い終わった瞬間に商品を提供できるでしょう。

└しかし、ここで問題となるのが、コンピュータくんは文字列の"1"と数字での'1'をそのままでは判別できないということです。
└人間なら「どっちも"1"でしょ」となりますし、なんなら"１"や"①"や"Ⅰ"や"壱"の違いを理解しながら、それが同じであるとすぐに分かります。
└細かい部分ですが、ここの問題を残したままコンピュータくんに応用的な・大規模な仕事を投げると、お客さんが何か言っても内容が分からないので無視したようになってしまったり、コンビニのバックヤードで過激な遊びをライブ配信したりしてしまうかもしれません。

￥JavaScriptでの「型」とは？
└JavaScriptはオブジェクト指向言語ですが、他のオブジェクト指向言語と比べると少し特殊なようです（なので、JavaScriptからこういった言語に触れた筆者としては、最初はよく分からなかった）。
└ES6からクラス構文が導入されたようですが、実際に動くときはそれをプロトタイプとして実行するという、よく分からん感じで動くそうです。
└同様にオブジェクト指向言語であるJava/C++などとは完全なクラスベースや静的型付けという点で違い、JavaScriptが動きやすさを目的としていることが分かるような気がします。
└しかし、この「動きやすさ」はある種の欠点でもあり、大規模化すると「なんかよく分かんないけど急に壊れた」とか、「なんかパソコンが上手く動かないんだけど、あ、そういえば、ウチの犬がさ」という、よく分からん挙動をしたり、エラーを検証しようとしてもなんでそうなったのか上手く伝えてくれないなどといったことが生じてきます。

＊では、なぜそもそもJavaScriptにその仕組みが無いのか？
└これは究極的にはJavaScriptだったからといえるかもしれません。
└もっと分かりやすくすると、JavaScriptの開発目的としてその仕組みが必要とされなかったことがあるかもしれません。
└まず目的としては「Webページに動的な要素を付ける」、そして「それをすぐにパッと実現させる（スクリプト言語）」といったことでした。それをJavaScriptの神（ブレンダン・アイク）は１０日間で創造しました。神も「私より数日遅いが、Brave賞を授与しよう」と言うかもしれません。
└JavaScriptという名称は当時のJavaの人気にあやかったという説が有力のようですが、最初は別の名前で考えられており、Javaの仕様を踏襲するという考えもなかったようで、Javaはしっかりと型定義を必要としますが、JavaScriptはすぐに動かせるという目的のために厳密な型定義を必要としませんでした。
└それが巡り巡って、結果的にTypeScriptという形で導入されたわけで、それはJavaScriptがそこまで拡張される必要があるだけの重要な言語となったことでもあり、「ちょっと使うおまけ言語」、「逆にちょっと邪魔になることもある言語」と認識されていた時代からは想像もできない結果でしょう。

＊端的にまとめる
└JavaScriptはNode.jsによってさらに拡張され、フロントエンドだけでなくサーバーサイドでも用いられる言語となりました。
└それゆえに、当初のJavaScriptの仕様では（その都度、仕様変更はあったとはいえ）、大規模な開発では安全性を確保しにくい、共同作業で進めるには仕様として問題が出てくるという根本的な問題が発生してきたのだと思います。
└しかしJavaScript以外の言語を選ぶという選択肢はもちろん無く、言語の根本的な仕様を変更するのはリスクが高くメリットも薄いので、AltJSによって拡張することが選択されたのでしょう。