  |
はてなキーワード: JSXとは
2025年、私たちはソフトウェア開発の歴史的な転換点に立っている。大規模言語モデル（LLM）の進化は、GitHub Copilotのようなコード補完ツールに始まり、今や「何を作りたいか」を自然言語で伝えるだけで、アプリケーションの雛形が数分で生成される時代を現実のものとしつつある。この光景を目の当たりにした多くのプログラマが、漠然とした、しかし確かな不安を抱いているだろう。「私たちの仕事は、いずれAIに奪われるのではないか」と。
この問いに対する私の答えは、半分はYesであり、もう半分はNoだ。より正確に言えば、プログラマの仕事の本質が、歴史上かつてないレベルで抽象化され、その役割が再定義されるのだ。私たちは、コードを「書く」作業から解放される一方で、これまで以上に高度な思考を要求されることになる。
本稿では、プログラミングの歴史を「How（いかに作るか）」から「What（何を作るか）」への移行として捉え直し、LLMがこの流れをいかに加速させるかを論じる。そして、その先にある、AIには決して代替できない、人間ならではの競争優位性、すなわち「Why（なぜ作るのか）」を定義し、記述する能力の重要性について深く考察していく。これは、単なる未来予測ではない。今を生きるすべてのソフトウェアエンジニアにとっての、生存戦略の提示である。
LLMの登場を特異点として捉える前に、我々が立っている場所を正確に知る必要がある。ソフトウェア開発の歴史は、常に「抽象化」との戦いであった。そしてその歴史は、プログラマの関心が「How」から「What」へと徐々に移り変わっていくプロセスとして描くことができる。
コンピュータの黎明期、プログラミングとは、計算機が理解できる命令（How）を、一行一行、丹念に記述する作業そのものであった。アセンブリ言語や初期のFORTRAN、COBOLといった言語は、ハードウェアの制約を強く受けており、プログラマはメモリ管理やプロセッサの動作といった、極めて物理層に近いレベルでの「How」を意識する必要があった。
この時代のテストもまた、「How」に強く束縛されていた。書かれた手続きが、意図した通りに順番に実行されるか、特定の入力に対して期待された計算結果を返すか。テストの関心事は、あくまで「手続きの正しさ」の検証にあった。ビジネスロジックと実装の詳細が密結合し、コードは特定の処理手順を記述した、硬直的な塊となっていた。
風向きが変わり始めたのは、ソフトウェアの規模が拡大し、その複雑性が人間の認知能力を超え始めた頃だ。1990年代後半から2000年代にかけて提唱されたエクストリーム・プログラミング（XP）の中で、テスト駆動開発（TDD）という考え方が登場する。
TDDの本質は、単なるテスト手法の改善ではない。それは、プログラミングのパラダイムを根底から覆す思想だった。TDDは、「まずテストを書く」ことを強制することで、プログラマの意識を「これから実装するコード（How）」から「そのコードが満たすべき振る舞い（What）」へと強制的に転換させたのだ。
テストはもはや、書かれたコードの後追いで正しさを検証する作業ではない。それは、これから作られるべきソフトウェアの「仕様書」であり、「振る舞いの宣言」となった。例えば、「ユーザーがログインボタンをクリックしたら、ダッシュボード画面に遷移する」というテストコードは、具体的な実装方法（`onClick`イベントハンドラの中で`window.location.href`を書き換える、など）には一切言及しない。それはただ、達成されるべき「What」を記述しているだけだ。
この思想は、ビヘイビア駆動開発（BDD）へと発展し、`Given-When-Then`といった、より自然言語に近い形式でソフトウェアの振る舞いを記述するスタイルを生み出した。プログラマだけでなく、プロダクトマネージャーやビジネスアナリストといった非技術者をも巻き込み、「What」を共通言語として定義する試みが本格化したのである。
TDD/BDDによってプログラマの意識が「What」に向かい始めると、コードそのものもまた、宣言的なスタイルへと進化していく。この変化を劇的に加速させたのが、モダンなフレームワークの存在だ。
Reactを例に考えてみよう。Reactが登場する前、フロントエンド開発はjQueryに代表されるように、DOMを直接操作する命令的なコード（How）の連続だった。「このボタンがクリックされたら、この要素のテキストを書き換え、あちらの要素を非表示にする」といった具合だ。
しかし、Reactは「UIとは、ある状態（state）に対する純粋な写像である」という宣言的なモデルを提示した。プログラマがやるべきことは、UIの状態（`state`）と、その状態がどのように見えるか（JSXによるコンポーネント）を宣言することだけだ。状態が変更された際に、DOMをどのように効率的に更新するかという面倒な「How」の部分は、Reactの仮想DOMと差分検出アルゴリズムがすべて隠蔽してくれる。プログラマは「What（UIのあるべき姿）」を記述するだけでよくなったのだ。
この「WhatからHowへの変換」は、様々な領域で見られる。
これらのフレームワークやツールは、いわば「特定の制約下における、WhatからHowへの高性能な変換器」として機能してきた。プログラマは、フレームワークが課す「お作法」や「制約」を受け入れることで、退屈で間違いの多い「How」の記述から解放され、より本質的な「What」の定義に集中できるようになった。我々が「生産性が高い」と感じる開発体験は、この優れた変換器の恩恵に他ならない。
現状は、この歴史的変遷の延長線上にある。プログラマの仕事は、手続きを記述する職人から、振る舞いを定義し、それを実現するための最適な「変換器（フレームワーク）」を選択・設定するアーキテクトへと、その重心を移してきたのだ。
フレームワークがもたらした「WhatからHowへ」の潮流は、LLMの登場によって、未曾有のスケールで加速されようとしている。フレームワークが「特定の領域に特化した変換器」であったのに対し、LLMは「あらゆる領域に対応可能な、究極の汎用変換器」としてのポテンシャルを秘めているからだ。
前章で述べたように、ReactやTerraformといったフレームワークは、その恩恵と引き換えに、私たちに特定の「制約」を課してきた。Reactを使うならコンポーネントベースで思考し、状態管理の作法に従う必要がある。Terraformを使うなら、そのエコシステムとHCLの流儀を受け入れなければならない。これらの制約は、WhatからHowへの変換を自動化するための「レール」であり、私たちはそのレールの上を走ることで効率を得てきた。
しかし、LLMはこの前提を覆す。LLMは、特定のフレームワークや言語の知識を事前に学習しているが、その利用において絶対的な制約を課すわけではない。私たちは、より自由な形式で「What」を伝えることができる。
例えば、こうだ。
ユーザー認証機能付きのシンプルなブログアプリを作ってほしい。フロントエンドはReactとTypeScript、UIコンポーネントはMUIを使う。バックエンドはNode.jsとExpressで、データベースはPostgreSQL。ユーザーはGoogleアカウントでログインでき、新しい記事を作成、編集、削除できる。記事にはマークダウン記法が使えて、画像もアップロードできるようにしてほしい。
この要求（What）は、特定のフレームワークの流儀に則ったものではない。複数の技術スタックを横断し、機能要求を自然言語で並べただけのものである。しかし、現在のLLM、特にGPT-4oやそれに類するモデルは、このレベルの要求から、ディレクトリ構造、設定ファイル、APIエンドポイント、フロントエンドコンポーネントに至るまで、驚くほど具体的なコード（How）を生成することができる。
これは、フレームワークが担ってきた「WhatからHowへの変換」が、特定のレールから解き放たれ、より広範で柔軟な領域へと拡張されたことを意味する。これまで自動化が難しかった、あるいは特定のフレームワークが存在しなかったニッチな領域や、複数の技術を組み合わせる複雑なシステム構築においても、AIによる宣言的プログラミングの恩恵を受けられる時代が始まろうとしているのだ。
LLMという汎用変換器の登場により、プログラマの生産性は、「いかに質の高いWhatをLLMに伝えられるか」に直結するようになる。これは、俗に「プロンプトエンジニアリング」と呼ばれるスキルだが、その本質は、ソフトウェア開発における「要求定義」そのものである。
質の高い「What」とは何か。それは、曖昧性がなく、網羅的で、矛盾のない要求である。
これらは、優秀なソフトウェアエンジニアが、プロダクトマネージャーやデザイナーとの対話を通じて、日常的に行ってきた思考プロセスそのものではないだろうか。LLMの登場は、この思考プロセスを、より明確に、よりテキストベースで「記述」する能力を求める。私たちの頭の中にあった暗黙的な仕様が、LLMへの入力（プロンプト）という形で、明示的に言語化されることを要求するのだ。
やがて、ほとんどのプログラミング作業は、この「Whatの記述」に収束していくだろう。TDDがテストコードという形式で「What」を記述したように、私たちは自然言語や、より構造化された要求記述言語を用いて、AIに対して「What」を宣言することになる。コード（How）は、その宣言から自動生成される中間生成物に過ぎなくなる。まさに、コードが蒸発していく未来である。
「What」を伝えれば「How」が手に入る。この魔法のような世界の到来を前に、私たちは一つの重大な問いに直面する。それは、「そのWhatからHowへの変換は、本当に一意に決まるのか？」という問いだ。
答えは、明確にNoである。
ある「What（要求）」を実現するための「How（実装）」は、無数に存在する。そして、どの「How」を選択すべきかを決定するためには、単純な機能要求（What）だけでは情報が全く足りない。そこには、必ず「Why（なぜそう作るのか）」という、背景、文脈、そしてトレードオフの考慮が必要不可欠となる。
簡単な例を考えてみよう。「1億件のユーザーデータを格納し、ユーザーIDで高速に検索できるシステム」という「What」をLLMに与えたとする。LLMは、どのような「How」を提案するだろうか。
これらの選択肢は、どれも「What」を満たしている。しかし、その特性は全く異なる。案Aは多くのエンジニアにとって馴染み深く開発が容易だが、10億、100億件へのスケールは難しいかもしれない。案Bはスケール性に優れるが、厳密なトランザクション管理は苦手だ。案Cは高速だが、運用コストとシステムの複雑性が増す。案Dは安価だが、検索速度は他に劣る。
LLMは、これらの選択肢をリストアップすることはできるだろう。しかし、このプロジェクトにとって最適な選択肢はどれかを、自信を持って決定することはできない。なぜなら、その決定には、LLMが与えられていない「Why」の情報が必要だからだ。
これらの「Why」こそが、無数に存在する「How」の中から、ただ一つの「正解」を選び出すための羅針盤なのである。そしてこの「Why」は、ビジネスの目標、組織の文化、ユーザーの期待、技術的な制約といった、極めて人間的で、文脈依存的な情報の中にしか存在しない。
ここで重要なのは、これまでもエンジニアは、この「Why」に基づく意思決定を、意識的あるいは無意識的に行ってきたという事実だ。
私たちが技術選定を行うとき、単に「流行っているから」という理由だけでReactを選ぶわけではない。「SPA（Single Page Application）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「 Permalink | 記事への反応(0) | 17:09
2025年、私たちはソフトウェア開発の歴史的な転換点に立っている。大規模言語モデル（LLM）の進化は、GitHub Copilotのようなコード補完ツールに始まり、今や「何を作りたいか」を自然言語で伝えるだけで、アプリケーションの雛形が数分で生成される時代を現実のものとしつつある。この光景を目の当たりにした多くのプログラマが、漠然とした、しかし確かな不安を抱いているだろう。「私たちの仕事は、いずれAIに奪われるのではないか」と。
この問いに対する私の答えは、半分はYesであり、もう半分はNoだ。より正確に言えば、プログラマの仕事の本質が、歴史上かつてないレベルで抽象化され、その役割が再定義されるのだ。私たちは、コードを「書く」作業から解放される一方で、これまで以上に高度な思考を要求されることになる。
本稿では、プログラミングの歴史を「How（いかに作るか）」から「What（何を作るか）」への移行として捉え直し、LLMがこの流れをいかに加速させるかを論じる。そして、その先にある、AIには決して代替できない、人間ならではの競争優位性、すなわち「Why（なぜ作るのか）」を定義し、記述する能力の重要性について深く考察していく。これは、単なる未来予測ではない。今を生きるすべてのソフトウェアエンジニアにとっての、生存戦略の提示である。
LLMの登場を特異点として捉える前に、我々が立っている場所を正確に知る必要がある。ソフトウェア開発の歴史は、常に「抽象化」との戦いであった。そしてその歴史は、プログラマの関心が「How」から「What」へと徐々に移り変わっていくプロセスとして描くことができる。
コンピュータの黎明期、プログラミングとは、計算機が理解できる命令（How）を、一行一行、丹念に記述する作業そのものであった。アセンブリ言語や初期のFORTRAN、COBOLといった言語は、ハードウェアの制約を強く受けており、プログラマはメモリ管理やプロセッサの動作といった、極めて物理層に近いレベルでの「How」を意識する必要があった。
この時代のテストもまた、「How」に強く束縛されていた。書かれた手続きが、意図した通りに順番に実行されるか、特定の入力に対して期待された計算結果を返すか。テストの関心事は、あくまで「手続きの正しさ」の検証にあった。ビジネスロジックと実装の詳細が密結合し、コードは特定の処理手順を記述した、硬直的な塊となっていた。
風向きが変わり始めたのは、ソフトウェアの規模が拡大し、その複雑性が人間の認知能力を超え始めた頃だ。1990年代後半から2000年代にかけて提唱されたエクストリーム・プログラミング（XP）の中で、テスト駆動開発（TDD）という考え方が登場する。
TDDの本質は、単なるテスト手法の改善ではない。それは、プログラミングのパラダイムを根底から覆す思想だった。TDDは、「まずテストを書く」ことを強制することで、プログラマの意識を「これから実装するコード（How）」から「そのコードが満たすべき振る舞い（What）」へと強制的に転換させたのだ。
テストはもはや、書かれたコードの後追いで正しさを検証する作業ではない。それは、これから作られるべきソフトウェアの「仕様書」であり、「振る舞いの宣言」となった。例えば、「ユーザーがログインボタンをクリックしたら、ダッシュボード画面に遷移する」というテストコードは、具体的な実装方法（`onClick`イベントハンドラの中で`window.location.href`を書き換える、など）には一切言及しない。それはただ、達成されるべき「What」を記述しているだけだ。
この思想は、ビヘイビア駆動開発（BDD）へと発展し、`Given-When-Then`といった、より自然言語に近い形式でソフトウェアの振る舞いを記述するスタイルを生み出した。プログラマだけでなく、プロダクトマネージャーやビジネスアナリストといった非技術者をも巻き込み、「What」を共通言語として定義する試みが本格化したのである。
TDD/BDDによってプログラマの意識が「What」に向かい始めると、コードそのものもまた、宣言的なスタイルへと進化していく。この変化を劇的に加速させたのが、モダンなフレームワークの存在だ。
Reactを例に考えてみよう。Reactが登場する前、フロントエンド開発はjQueryに代表されるように、DOMを直接操作する命令的なコード（How）の連続だった。「このボタンがクリックされたら、この要素のテキストを書き換え、あちらの要素を非表示にする」といった具合だ。
しかし、Reactは「UIとは、ある状態（state）に対する純粋な写像である」という宣言的なモデルを提示した。プログラマがやるべきことは、UIの状態（`state`）と、その状態がどのように見えるか（JSXによるコンポーネント）を宣言することだけだ。状態が変更された際に、DOMをどのように効率的に更新するかという面倒な「How」の部分は、Reactの仮想DOMと差分検出アルゴリズムがすべて隠蔽してくれる。プログラマは「What（UIのあるべき姿）」を記述するだけでよくなったのだ。
この「WhatからHowへの変換」は、様々な領域で見られる。
これらのフレームワークやツールは、いわば「特定の制約下における、WhatからHowへの高性能な変換器」として機能してきた。プログラマは、フレームワークが課す「お作法」や「制約」を受け入れることで、退屈で間違いの多い「How」の記述から解放され、より本質的な「What」の定義に集中できるようになった。我々が「生産性が高い」と感じる開発体験は、この優れた変換器の恩恵に他ならない。
現状は、この歴史的変遷の延長線上にある。プログラマの仕事は、手続きを記述する職人から、振る舞いを定義し、それを実現するための最適な「変換器（フレームワーク）」を選択・設定するアーキテクトへと、その重心を移してきたのだ。
フレームワークがもたらした「WhatからHowへ」の潮流は、LLMの登場によって、未曾有のスケールで加速されようとしている。フレームワークが「特定の領域に特化した変換器」であったのに対し、LLMは「あらゆる領域に対応可能な、究極の汎用変換器」としてのポテンシャルを秘めているからだ。
前章で述べたように、ReactやTerraformといったフレームワークは、その恩恵と引き換えに、私たちに特定の「制約」を課してきた。Reactを使うならコンポーネントベースで思考し、状態管理の作法に従う必要がある。Terraformを使うなら、そのエコシステムとHCLの流儀を受け入れなければならない。これらの制約は、WhatからHowへの変換を自動化するための「レール」であり、私たちはそのレールの上を走ることで効率を得てきた。
しかし、LLMはこの前提を覆す。LLMは、特定のフレームワークや言語の知識を事前に学習しているが、その利用において絶対的な制約を課すわけではない。私たちは、より自由な形式で「What」を伝えることができる。
例えば、こうだ。
ユーザー認証機能付きのシンプルなブログアプリを作ってほしい。フロントエンドはReactとTypeScript、UIコンポーネントはMUIを使う。バックエンドはNode.jsとExpressで、データベースはPostgreSQL。ユーザーはGoogleアカウントでログインでき、新しい記事を作成、編集、削除できる。記事にはマークダウン記法が使えて、画像もアップロードできるようにしてほしい。
この要求（What）は、特定のフレームワークの流儀に則ったものではない。複数の技術スタックを横断し、機能要求を自然言語で並べただけのものである。しかし、現在のLLM、特にGPT-4oやそれに類するモデルは、このレベルの要求から、ディレクトリ構造、設定ファイル、APIエンドポイント、フロントエンドコンポーネントに至るまで、驚くほど具体的なコード（How）を生成することができる。
これは、フレームワークが担ってきた「WhatからHowへの変換」が、特定のレールから解き放たれ、より広範で柔軟な領域へと拡張されたことを意味する。これまで自動化が難しかった、あるいは特定のフレームワークが存在しなかったニッチな領域や、複数の技術を組み合わせる複雑なシステム構築においても、AIによる宣言的プログラミングの恩恵を受けられる時代が始まろうとしているのだ。
LLMという汎用変換器の登場により、プログラマの生産性は、「いかに質の高いWhatをLLMに伝えられるか」に直結するようになる。これは、俗に「プロンプトエンジニアリング」と呼ばれるスキルだが、その本質は、ソフトウェア開発における「要求定義」そのものである。
質の高い「What」とは何か。それは、曖昧性がなく、網羅的で、矛盾のない要求である。
これらは、優秀なソフトウェアエンジニアが、プロダクトマネージャーやデザイナーとの対話を通じて、日常的に行ってきた思考プロセスそのものではないだろうか。LLMの登場は、この思考プロセスを、より明確に、よりテキストベースで「記述」する能力を求める。私たちの頭の中にあった暗黙的な仕様が、LLMへの入力（プロンプト）という形で、明示的に言語化されることを要求するのだ。
やがて、ほとんどのプログラミング作業は、この「Whatの記述」に収束していくだろう。TDDがテストコードという形式で「What」を記述したように、私たちは自然言語や、より構造化された要求記述言語を用いて、AIに対して「What」を宣言することになる。コード（How）は、その宣言から自動生成される中間生成物に過ぎなくなる。まさに、コードが蒸発していく未来である。
「What」を伝えれば「How」が手に入る。この魔法のような世界の到来を前に、私たちは一つの重大な問いに直面する。それは、「そのWhatからHowへの変換は、本当に一意に決まるのか？」という問いだ。
答えは、明確にNoである。
ある「What（要求）」を実現するための「How（実装）」は、無数に存在する。そして、どの「How」を選択すべきかを決定するためには、単純な機能要求（What）だけでは情報が全く足りない。そこには、必ず「Why（なぜそう作るのか）」という、背景、文脈、そしてトレードオフの考慮が必要不可欠となる。
簡単な例を考えてみよう。「1億件のユーザーデータを格納し、ユーザーIDで高速に検索できるシステム」という「What」をLLMに与えたとする。LLMは、どのような「How」を提案するだろうか。
これらの選択肢は、どれも「What」を満たしている。しかし、その特性は全く異なる。案Aは多くのエンジニアにとって馴染み深く開発が容易だが、10億、100億件へのスケールは難しいかもしれない。案Bはスケール性に優れるが、厳密なトランザクション管理は苦手だ。案Cは高速だが、運用コストとシステムの複雑性が増す。案Dは安価だが、検索速度は他に劣る。
LLMは、これらの選択肢をリストアップすることはできるだろう。しかし、このプロジェクトにとって最適な選択肢はどれかを、自信を持って決定することはできない。なぜなら、その決定には、LLMが与えられていない「Why」の情報が必要だからだ。
これらの「Why」こそが、無数に存在する「How」の中から、ただ一つの「正解」を選び出すための羅針盤なのである。そしてこの「Why」は、ビジネスの目標、組織の文化、ユーザーの期待、技術的な制約といった、極めて人間的で、文脈依存的な情報の中にしか存在しない。
ここで重要なのは、これまでもエンジニアは、この「Why」に基づく意思決定を、意識的あるいは無意識的に行ってきたという事実だ。
私たちが技術選定を行うとき、単に「流行っているから」という理由だけでReactを選ぶわけではない。「SPA（Single Page Application）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「 Permalink | 記事への反応(0) | 17:09
どんな感じでした？？？
https://shannon-lab.co.jp/?p=9737
昨今ではFacebookが開発したJavaScriptフレームワーク「React」が注目を集めています。Facebook、Instagram、Airbnb等の大規模なサービスから、プロトタイプまで幅広い現場で採用されています。
また、GoogleのBaaS（Backend as a Service）「Firebase」が登場し、バックエンドの開発が不要となり、大幅な開発工数の削減が可能となりました。
Reactにフロントエンド、Firebaseをバックエンドとして採用することで、効率的に質の高いWebアプリケーションを開発することが可能になりました。
しかし、ReactやFirebaseは日本語の情報も少なく、学ぶ機会も限られています。本講座では、React、Firebaseの基礎からアプリケーションの開発までマンツーマンで指導を行います。
ReactとFirebaseの基礎を習得し、演習としてSNSの開発を行うことで理解を深めます。
Authentication基礎と会員機能
Firestore基礎とRDBとの違い
Cloud Storage基礎
Cloud Functions基礎
SNS開発演習1
SNS開発演習2
SNS開発演習3
本講座のメリット
開発からデプロイまで、テストツールを使い実際の開発に限りなく近い環境で学ぶことにより、実践で生きるスキルが身につきます。一人でもアプリの開発ができるようにスキルアップしていけます。
受講費 月7万x6ヶ月=42万円+税
'''
技術部顧問レベルでReact知ってる人って少ないよね(実務で使ってる場合)
技術トップがReact知ってると、ちゃんと開発してるんだなあ、って思うけど。
なんも知らないやつマジで知らない落差がすごい。
コンポーネントを細かく分割すると本当に小さい部品、テキストエリアと送信ボタンだけの部品とかになるので。
開発者によってはコンポーネント数は凄まじく増える(いいか悪いかは別として)
コンポーネントは複数まとめて一つのファイルに記載できるから、jsxファイルの数＝コンポーネントの数じゃない。
jsxファイルの数＝コンポーネントの数って前提で話してる技術部顧問と話して、その上絶対自分の間違いを正さないから、話合わなくてめんどくせー
JavaとかやってるからReactもノリで答えられるっしょ〜、みたいなやつ。
この顧問のように勉強しなければ、すぐに時代遅れになるんだなと自戒した
というか十分な知識のない奴はこういう知ったかぶりの言うこと本気にして鬱になるんやろな…。
「えっ、もしかしてjsxファイルの数＝コンポーネントの数だと思ってます？(笑」
何年か前に、Vue.jsとReact.js比較して、Vue.jsを使うことに決めたんだけど、
最近の風潮として、React.js一強になりつつあるから、またReact.jsのことをちょっと調べ始めた。
正直、React.jsって何がいいんだかさっぱりわからない。
JavaScriptの中にHTMLタグが記述されるJSXって、ものすごく筋が悪いように思う。
大昔、Servletの中でちまちまHTMLタグ出力してた時代に戻ったみたい。
後、これってどういうワークフローで開発してくの？
（JSXは別に気持ち悪いとは思わなかった。classNameとhtmlFor以外は）
------------------------------------------------------------------
使いたいデータは data に書けばいいし、使いたい関数は methods に書けばいい。
非常に単純明快だ。
------------------------------------------------------------------
React は、JS をある程度理解していないと使うことすらままならない。
さらに React の設計思想を深く理解していないと、うまく使いこなすことはできず render 地獄が生まれてしまう。
「俺たちの設計思想が理解できない奴は使わなくていいよ。初心者のためにわかりやすくなんか絶対しないよ」と言うメッセージを、駆け出しの私は確かに受け取った（実際そう思ってるんじゃないかな）。
------------------------------------------------------------------
React 推しのエンジニアのほとんどは、発表当初すでに JS に強かった人が多い。
そして Vue すら理解できないエンジニアが世間にはゴロゴロいることも知らない層だと思う。
だから無批判に React を礼賛できる。そりゃ自分や周りが振る分には切れ味最高なわけだからね。
その剣を持ち上げることすらできなかったり、持ち上げられてもうまく振れない人々がいるなんて、思いもしないのだろう。
------------------------------------------------------------------
しかし強いエンジニアに影響された何もわかってない駆け出しが「React 最高〜〜 Vue はクソ」みたく嘯いているのを聞くと「本当にわかってて言ってる？」と思わざるを得ない。
Vue の Options API すら理解できない人々に、useEffect が使えるわけないからだ。
React 信者たちは「俺達が簡単に覚えられたんだからお前らもできるだろ」的な知的マッチョ思想で、不特定多数の駆け出しにReactを勧めるのを今すぐやめるべきだ。
------------------------------------------------------------------
もちろん強いとわかってる後輩には勧めていいけどね。
日本のエンジニアの給与の下限は、Reactを習得する対価としては低すぎるのです。
------------------------------------------------------------------
JSXが嫌いとかそう言うわけじゃない。慣れれば、これはこれで良いかなと感じる部分もある。
何かの入力項目があった場合に、Stateを定義して、入力変更イベントを拾って、Stateに設定し直す処理を毎度書く必要がある。
何十項目とそれがあった場合、面倒だし、それらが単純なものとは言え、無視できないコストになってしまう。
コンポーネントコード中に、あまり本質的でない、Stateの定義と入力変更イベントでStateに設定し直す処理が、何十スクロールと続くのって読んでいて辛くならない？
Stateの定義をObjectでまとめて定義するって言うのも、解決策の一つなんだろうか？
調べてみたらできるっぽいけど、Objectの分割代入を使わなくちゃいけないみたいで、これはこれで面倒。
React Hook Formと言うのもあるみたいだけど、そもそもコアな部分で、それを吸収できる機構が無いのは如何なものかと思ってしまう。
（それをしないのが、React的なシンプルな設計思想でもあるのかな？）
Vue.jsでは、双方向バインディングはv-modelだけで出来ちゃうし、Angularの事は詳しく無いけどAngularも同じノリで出来るみたい。
まとめると、自分的な辛さの原因は『双方向バインディング辛い』ってことだけなんだけど、みんな本当にReactに満足してるのかな？
あと、Reduxに関しても、ちょっと言いたい。大抵のプロジェクトで、そこまでRedux使いたくなるか？
SNSのようなリッチなインタラクティブが求められる尖ったUIを作るのなら、もしかしたら必要なのかもって思うけど、大抵の場合、不要じゃないかって思うんだけど。
DOMというのは、そもそもDocumentObjectModelでオブジェクト指向。
Reactは、これらすべてを一旦ご破産にした。
MVCのVだ、と公式サイトに説明されているが、これは半ば皮肉であって、本当はVは存在しない。Cももちろん存在しない。M、モデル＝ロジックしか存在しない。モデル一元論、それがReact。
VであるDOMは消滅し、JavaScriptの `x` や `a` などその他の変数と同列のファーストクラスの仮想DOMとしてしか存在していない。
つまり、仮想Vは、M（モデル）内で関数型の文脈で自由自在に演算できるわけ。
コードの最後でマウントしておけば、仮想Vは自動的に、実VのDOMとして描画される。
M＝ロジックの外に、あらかじめわざわざ決め打ちしたVを用意するよりも、M＝ロジックに一元化するほうが賢い。それがReactであり、JSX。
ReactはJavaScript界隈の関数型プログラミング化の潮流で登場。
最近、炎上している別の方面で、特にFRPと組み合わせると圧倒的なパワーを発揮すると一部では実例とともに指摘されている。
http://kenokabe-techwriting.blogspot.jp/2016/05/frptimeenginereactjsocaml.html
Reactは、関数型あるいは宣言型に書けるように用意されている。DOMは、「仮想DOM」として、JS（JSX）上の「値」として統合されていて、それは自由に変形し、組み合わされ、リアクティブにJSX上の仮想DOMから実DOMにリアルタイムでマッピングされ描写される。
JQueryも、実DOMを関数型で操作できるような拡張ではあるが、Reactのように宣言的に書くことは不可能。
coffee scriptは、ES6登場までの過渡期の橋渡しみたいなもので、登場したのも消えたのも合理性がある。
React.jsは、関数型の潮流で登場したものでこれも合理性があり、この延長線上でさらに洗練された代替物が登場する可能性はあれど、このパラダイムが消えることはない。
http://anond.hatelabo.jp/20160522003506
ども。
この辺りの一連の発言（特に後二者）を見るに、多分React以前の前提がいろいろ違っています。単にJSやNodeやNPMやSPAやWeb APIといったフロントエンドの世界観に対して、興味がないどころか漠然とした不信があり、サーバ側でヘビーにHTMLを作って吐くスタイルを守り続けたい人なのだ、という印象を受けます。
ユーザの各操作毎にサーバ側で外見のHTMLを組み立て直して配信するという旧来のWebの方が特殊な世界です。それこそAndroid/iOS開発やデスクトップアプリで、そんなやり方はしません。UI関連のことはクライアントで完結し、メニュー遷移程度で通信したりしない。サーバは静的データの配信とDB操作に専念する。SPAとは、やっとブラウザがそういうネイティブアプリのレベルに追いつき、同じやり方ができるようになった、というだけの話です。
とりあえずReactは、まずその前提を受け入れてから使うものです。その前提なしに使えないこともないですが、メリットは活きないでしょう。その時点で既に「よくわかんないんですけどSQLiが…」と漠然とした不安を表出されるようだと、道のりが遠いな…と。もちろん「私の周囲にそういう案件はない」ということなら、それで構いません。
具体例を出せとのことだったので。私の場合は変幻する数百のテキストフィールドとリアルタイム集計が登場する勤務予定表的なものを、1人でjQueryのSPAで作った際、数百行のHTMLと数千行のJSがスパゲティ化し「こりゃいかん、メンテ不能になりそう」と思ったのが、具体的にReactを覚えるきっかけでした。実際非常にうまく行き、10年後の誰かにも「この時代のベスト」として自信を持って残せます。JSXの局所的な見た目の問題など、アプリ全体の構造の見通しやすさと比べたら些細な話です。Angularなら出来たかもしれませんが、サーバ側処理とページ遷移を多用して書くことに関しては検討すらしていません（私の知っているどんなフレームワークを使ってもユーザビリティと、見通しの良いコードを保つことは無理だったと思います）。ビデオ再生や大きな画像処理を伴うアプリでもReactを使っており、そちらではページ遷移などもってのほかです。
「変な独自拡張を入れてまでJSを使い続ける理由がわからん」についても、まるでJSが生来の嫌われ者で、クライアント側でもPythonやRubyを使いたい人が多くいるかのような書き方のように思えるのですが。実際そんなことはないですよね？ たぶんES6は人々から積極的に愛されています。現状、クライアント側にPythonが進出するのではなく、逆にデスクトップやモバイルやサーバ側にどんどんJavaScriptが進出する流れが起きています。
速度に関しては、Reactはやってる内容の割に十分速くて実用的だよね（mustache使うよりは速いよね）ということであり、賢い人が手間暇かけて最適化した生DOM操作より遅いのは言うまでもありません。また、JSXはシンタックスハイライトが出来ないとかも、そうとう昔の話です。今は普通のJS技術者が普通に触れる程度の成熟はしています（枯れたとまでは言いませんが）。
React.js界隈の人に聞きたい
http://anond.hatelabo.jp/20160521163144
最近某所で、React使うとjQueryは不要だ的なタイトルの記事を書いちゃた気がするので一応反応しときます。長文ごめんね。
えーととりあえず、あのタイトルは実際のところ省略しすぎであり、もちろん本来は「場合によってはjQueryは不要」「jQueryは要らないこともある」と長く書いた方が正確です（本文ではちゃんとReactが万能ではない説明をしてる）。でも多少釣りっぽいタイトルの方が読まれるようなので反省はしていない。
そもそも世の中にそんなにSPAがあるのか
世の中の絶対数は知りませんが、自分の脳内ではもう「ページ遷移しない方がずっと楽に開発できてユーザ体験も向上するのに、敢えてそうしない理由がない」という至極単純な話なので、そこは悩むところではないです。ページを複数作り、＜input type="hidden"＞とかセッション変数とか駆使する面倒ごとは、書かないでいいなら二度と書きたくない。
というか、ちゃんと書かれたSPAは使っていてSPAであることにそもそも気づかないので、「SPAだから使いづらい」という主張はよく分かりません。GitHubやTwitterサイトがSPA的なことをしている故に使いづらいでしょうか。偶然タブを開いてたので調べたらそうだったから紹介しますが、例えばWebpackのドキュメントサイトは（Reactではないけど）SPAで、ブラウザでMarkdownをレンダリングしています（ http://webpack.github.io/docs/ )。サーバサイドで動くスクリプトもタスクもゼロ。個人的にはこういう使い方で十分嬉しいです。
何にせよReactのメリットが真に活きるのはある程度の規模以上だと思うので、小規模で導入してjQueryより短くならないことは普通にあります。自分中の閾値としてはJSコードが数百行超えるならもうReact使う。
JSXを使うことに抵抗ないんですか？
んー、要するに「別物であるDartやCoffeeScriptは許すけど、ES6で書く以上はES6外の独自構文を混ぜるのは許さん」という主張だと解釈したのですが、そういうことですか？ 正直その主張を聞いたのは初めてです。歴史的にJSXとES6は完全に独立して発明されました。最近になってBabelが両方同時に扱えるようになりましたし、Babelはまさにそういう拡張性を重視しているツールです。それは「ああ便利になったね」というだけの話であり、なぜ「ES6とJSXは混ぜるな危険」となるのかよく分かりません。現にこれが最も標準的で人気の組み合わせです。
「JSXを使うことへの抵抗」ということなら、とにかく見た目にコレがキモいと感じる人が非常に多いのは事実です。現に、JSXより見た目がキモくないことを売りにしている仮想DOM実装が一定の人気を博していたりします。でもそういうライブラリは「キモさ」軽減のために結局新たな構文やら独自コンパイラやらを編み出して柔軟性を犠牲にしています。JSXは「関数呼び出しのシンタックスシュガーをJavaScriptに1個導入するだけで問題を概ね解決する」というシンプルかつ一番表現力の高い解決方法だと思います。仮想DOMの思想に逆らわない最も素直なやり方であり、将来長持ちする気がしています。
とはいえ所詮JSXはシンタックスシュガーなので、使いたくないなら使わず、本来の関数スタイルで仮想DOMを書いてReactを使ってもいいです。タイプ量が増えて若干見づらくなるだけなんで。
それと、JSXじゃなくてテンプレートでいいじゃん的に思っているようですが、テンプレートは仮想DOMでもなければJavaScriptでもないので、速度や機能の面でReactがやっていることに遠く及ばないと思います。
Reactはもう登場して3年経過して未だに勢いが増していますし、日常で困らないレベルのコンポーネント集も揃っています。React-Bootstrapはいいぞ、心が豊かになる。そろそろ採用してもアーリーアダプターとも言えんでしょう。むしろ真に先端を見るのが好きな人に言わせりゃ、2015年なんて「Reactが淡々と成熟していくのを見ているだけの、つまらない年だった」みたいな感じらしいですし。
Reactは現時点で既に3年に1回レベルのビッグウェーブであることは疑いようがなく、「これが10年に1回、つまりjQuery以来のビッグウェーブなのかどうか」については、そう信じている人と懐疑的な人がいる、という状況です。私はAngularもCoffeeScriptも「3年に1回」レベルに感じたのでスルーしましたが、Reactには「10年に1回」の方になりうる素質を感じています（個人の感想です）。将来もっと凄いものが出るとしたって、それは「ベターjQuery」ではなくて「ベターReact」でしょう。通常は「3年に1回」レベルでも試したり仕事に使ったりして構わないと思いますが、10年に1回の技術でなければ使わない主義の方は、あと2～3年待てばよいと思います。
保守性に関して言うと、Reactは典型的な「ひとつの事だけをとても上手くやる」系のライブラリです。考え方のコツさえ掴めば、記憶すべき要素はjQueryやAngularと比べても圧倒的に少なく、むしろそこらのテンプレートエンジンを覚える方が面倒なくらいです。10年後に見ても何をやっていたのか30分で思い出したいというのであれば、むしろAngularとかよりReactを採用すべきだと思います。
元増田です。
SPAは、クライアントが自立した1プログラムとして状態を管理する。サーバはUIと同様の非同期なイベント発生源/イベント発行先の一つとして扱う。またReactとReduxの組は、データベースサーバとサーバサイドページ生成のスタイルを、サーバとブラウザでやるようにシフトさせたものともみなせるだろう。
手間がかかりません？さらにもともとほぼサーバー側だけで済んでいたものを分けることでCSRFやSQLiなどの変なバグを仕込む可能性だってありますよね。これに見合うメリットが見えないのですがいかがでしょうか。
そしてReact自体には、JSX構文もbabelもいらない。JSXタグを書くよりむしろReact.DOM.div({...},...)等で書いたほうがプログラミングでは扱いやすい。JSXはサーバサイドページ生成のテンプレート言語利用文化に寄せた表現に過ぎないといえる。そして今ではbabelで変換する対象もES6 modulesのexport/importだけだ。これも分割ファイル対応のためにwebpackあたりを使うなら、ついでにbabelでES6 modulesも、といった程度のこと。
というかですね、そもそもVをロジックの中にベタ書きしちゃうの嫌なんですよね。シンタックスハイライトとかインデントも効かないじゃないですか。そういう点ではAngularJSが一番気持ちいいですが。。
まあそれはそれとして、なるほど、JSXは別にどうでもいい、というのはわかりました。まぁそれならわからんでもないです。
すでに一般に忘れられつつあるprototype, Dojo, Mooと同格であるjQueryのほうが五年後も活発にメンテされるのかどうか怪しいだろう。もちろん、レガシーなものとしては残り続けるだろうが。
ここわかんないですね。活発なメンテがそんなに重要なのかな？ということです。まあモダンな感じで書きたいということは理解できますが、それさえクリアされていればいいんじゃないでしょうか。そうでもないですか？
http://anond.hatelabo.jp/20160521163144
内容から誰が書いてるかわかるかもしれんけど、まぁスルーよろしく。
jQueryもそんなにガッツリ使ってるわけでもないし、Reactはまだリリース前の調査兼下地作りの段階だけど
正直言ってjQueryに戻るつもりは毛頭ないぐらいReact便利だと思ってる。
でもjQueryを捨て去れるかというとそれも無理だと思ってる。
その辺のことを適当に書いてみる。
社内サポート的なことやってて、サポートのテンプレート対応を省力化するために
Webでツール作って人が対応するコストを減らすために使ってる。
jQueryで一つツール作ってリリースしてそこそこ人的コスト削れたのはよかったと思ってる。
最大にして一番の理由がこれ。
そんなに大規模なアプリケーション作ってるわけでもないし、関係者も俺一人だけど正直DOMツリーを脳内でくみ上げるのに疲れた。
500行もいかないようなショボいコードでも脳内DOMツリーと格闘するのしんどい。
DOMツリー触るほうが楽ってみんなどの程度のコードでそんなこと言ってんの？
そんなスーパーハカー揃いなの？信じられないんだけど。
オリジナルのbootstrapはどうしても頭に入ってこなかったし、手を付ける気にもならなかったけど
React-Bootstrapはマジで楽だし、スッと理解できる。マジ最高。
Bootstrapってこっちを本筋にすべきじゃね？と割とマジで思ってる。
まだ触って3日も経ってないけど。
これはちゃんとしたWeb界隈の人は利点と思わないのかもしれないけど
一人でいろいろ賄わざるを得ない俺みたいな人間にとってはマジで楽。
ベースのHTMLにはベースのdiv一個載せとくだけで後は全部js。
レイアウトを大元のコンポーネントでReact-Bootstrapで組んで、あとは各コンポーネントを
個別に作っていけばいい。
HTML見て、CSS見て、JS見て、っていちいち記述方式の違うコードを見る必要がないのは
少なくとも俺にとっては一番楽。
やっぱまだReactはコンポーネントがそんなに揃ってないんだよね。
だからjQueryも使わざるを得ないけど、それも一つのコンポーネントに閉じ込められるから
管理が楽。
極力なくす方向で行くつもりだけど、今はまだ両方使ってる。
あの気持ち悪いコード考えた人はマジでいい意味でも悪い意味でも頭イカレてると思う。
気持ち悪くて仕方ない。いまだに大嫌い。
どんなに気持ち悪くても、結果が伴う以上使う。
5年後も自分がこの仕事やってるかどうかもわからんからそんなこと気にしたことない。
今ある仕事をなるべく早く簡潔に実行するために最適だと思ってるツールを使ってるだけ。
それがかつてはjQueryだったし、今も一部jQueryだし、大半がReactになろうとしてるだけ。
将来まだこの仕事やってて、もっと有用なツールがあればそっち使う。
俺みたいな一人前にすら届いてない奴の意見なんぞ必要ないだろうけど、
自分の今の考えを書いておくと後で見返せるかなと思って適当に書いてみた。
まずReactの特徴は、「状態データから変換してビューを生成する」スタイルに統一されることにある。
これはjQueryをはじめとするDOM操作モデルでの、「初期状態ビューの作成」と「(イベントに伴う)状態変化からの部分ビュー変更」で構成するスタイルから脱却され、たとえば部分処理の積み重ねから想定外の状態が生まれることを防ぐ。
SPAは、クライアントが自立した1プログラムとして状態を管理する。サーバはUIと同様の非同期なイベント発生源/イベント発行先の一つとして扱う。またReactとReduxの組は、データベースサーバとサーバサイドページ生成のスタイルを、サーバとブラウザでやるようにシフトさせたものともみなせるだろう。
そしてReact自体には、JSX構文もbabelもいらない。JSXタグを書くよりむしろReact.DOM.div({...},...)等で書いたほうがプログラミングでは扱いやすい。JSXはサーバサイドページ生成のテンプレート言語利用文化に寄せた表現に過ぎないといえる。そして今ではbabelで変換する対象もES6 modulesのexport/importだけだ。これも分割ファイル対応のためにwebpackあたりを使うなら、ついでにbabelでES6 modulesも、といった程度のこと。
すでに一般に忘れられつつあるprototype, Dojo, Mooと同格であるjQueryのほうが五年後も活発にメンテされるのかどうか怪しいだろう。もちろん、レガシーなものとしては残り続けるだろうが。
Reactのモデルは関数型プログラミングのモデルそのものであって、そういう観点ではすでに何年も続いたものであり、React自体は消えたとしてもその手法は長く続くことになる。
**誰かみんなの主張のまとめを作ってくれないですか？** (まあそれこそお前がやれよって話かもしれないので、誰もやってくれなかったら私がしますが。。)
最近、JQueryはもはや不要でReactさえあればOK,みたいな記事をよく見ますね。
論旨としては、どうせトランスパイラ使ってるんだからもっと便利な書き方しようぜ！ってことなんだと思います。(virtual DOMがメインだ！という話もあったけど、じゃあ何でReactなの？というのは聞きたいかな。メジャーだから？)
ちなみに私は昔coffeeとbackbone.jsか何かで業務用のページ（SPAではなかったような気がする）を作るお仕事をしたことがありますが、フロントエンドエンジニアというわけではないです。どちらかというとサーバー管理とかのほうがよく知っていると思いますが、Javascriptもそれなりには書くくらいの感じの人です。Reactは不幸にして一度も触ったことがないので、以下の文章はすべてコードサンプルをみたうえでの感想です。
まずこれ。正直そんなにたくさん動的にがりがり書き換えているページをあんまり見ない気がするんですよね。その上正直そういうウェブページ、あったとしても大体使いづらいです。
世の中のページが全部FBならいいのかもしれませんが、具体的にはどんなところで使ってるんでしょう。業務ページとかですか？あと、なぜSPAにしなければいけないのかもよくわからないです。画面遷移するのだめなの？という感じで。
トランスコンパイラを使うのって、結局「将来的には全部ES6になるのだから、今のうちからES6で書いておけば将来のメンテナンスコストとかも減ってうれしいよね！」っていうことなんだと思います。
こういう例、JS以外にもいろいろあって、例えばboost、Androidのsupport library, Pythonのfrom __future__ importなどなどあると思うんですが、どれもやっぱり将来的なコストを見据えて、非標準のライブラリ・記法を使いましょう、ってことですよね。
でもJSXってそういうのじゃないじゃないですか。いわばsupport libraryを使うのとmonoで全部書くのと、位の違いがあるように見えます（そこまでは違わないかｗ）。そういう考察を一切入れずに、「どうせトランスパイラ使ってるんだから拡張記法使っちゃおうぜ！！」っていうのはかなり危ういように見えます。
そもそも、JSって結構独特な言語ですよね。もちろん今はnode.jsとかあるわけですけど、まあやっぱりスクリプト言語の標準の座ってPythonやRubyですよ。世の大多数の人はそっちのが使いやすいとおもってるんでしょう。ということでそもそもトランスパイラ通すんだったらもっと普通の言語から変えるようなソフトウェアが流行ってもいいんじゃないかなあとか思いますけど、そういうのがないのも謎です。dartとかどうなってるんですかね。(まtypescriptとか一種それだという話もあるか)
五年、十年あとにReact.jsって流行ってるんでしょうか。例えば五年前はcoffee scriptが結構流行ってましたけど、たしかもうサポート打ち切りとかになっちゃったんですよね。もちろん営利企業がバックなので、そこまで急になくなるかはわからないですけど、五年したらみんなまた別のライブラリがすごい！！みたいに言ってるんじゃないでしょうか。
まあだからこれはフロントエンドエンジニア業界全体の問題なのかもしれませんが、そういう将来的な保守コストをどう考えているのかが気になります。特にもし業務ページであるなら、せいぜいがなるべく枯れたライブラリ（≒JQuery）と、テンプレートエンジンあるいはフォーマットストリングでも使ってpure ES6で書いたほうがいいんじゃないでしょうか。そうすると結局SPAにはしないですよね。
まあこれを突き詰めるとじゃあetaxもactivexで、銀行のシステムはcobolで、マシンはpc98で、、、とかなっちゃうかもしれないんで、難しいところではあるとは思いますが、、、
とりあえずこんなところで、有識者の皆さんよろしくお願いします。
React.jsでした。angularと混ざりました。。あと特に喧嘩売ってるつもりとかは全くないですがそう見えたらごめんね。
id:murishinai 主張は単純で、せいぜいES6+トランスコンパイラ(+JQuery)とかでいいんじゃね、遷移はサーバー側でやったほうが楽じゃない？という感じです。
id:wordi virtual domが最大のメリット、ってのはよく見る意見ですね。例えば実際どんな場面で（どのくらいの規模のプログラムで）domの改変コストが効いてくるのか、みたいな実例を教えてくださると助かります。（もちろんFBとかはそうでしょうけど、もっとなんだろう、身近な例でお願いしたいです。）なんかReactががりがり（かつユーザー目線から見て有効的に）使われている例がイメージ出来ないのが問題な気がしてきました。
id:logic ええっと、それはそうなんですけど、なんだろう。標準のもので、少なくとも今後10年はあるだろうと言うもの(たとえばES6+フォーマットストリング)があるのにも関わらず、今後5年持つかもわからないライブラリを全面に押し出すの、ちょっと怖く見えるなあという気持ちです。
id:erukiti 具体的に頭の悪い点をご教授くださるとたいへんありがたいです。小規模だとそもそもvirtual domのメリットもなさそうですし、ES6標準でええんちゃうのんという気がしてならないのですが。
id:manaten もちろんFBやGMailをJQueryだけで作るのは不可能だと思います。だからFBはReactを、GはAngularを作ったのでしょうが、逆にそんなに気軽に使うようなものにも思えないのですよね。それこそ何百ブクマも付くのやべえなあ、と。（ところで私にはReactよりAngularJSのほうがずっと気持ちよく見えます）
SPAが使いづらいってのは言いすぎかな。正確には、「ページ遷移型のUIに比べて、SPAであることのメリットが明らかに生きているページって少なくないですか？」ということです。もちろんFBとかGとかtwとかは例外だと思いますけど、DOMを1000個とか10000個とかいじくり回しているページばっかあるようには思えない。もちろんどーーしてもSPAじゃなきゃダメなんだっていうならこの手のライブラリを使うといいとは思うんですが、どっちかというとニッチな需要じゃないでしょうか。
あとなんか保守点検に関する意識がちょっと違うのかなっていうコメントが散見されたんですけど、うーん、一発書いて書きっぱなしっていう案件そんなにあるんですかね？ちょっとそこがよくわかんないです。一度書いてもやっぱりn年先、さらにもっと言えば自分がその職場からいなくなった後のことまで考えてプログラム書くべきだと思うんです。そうすると、例えば数年後のプログラマにとってのReactは今のprototype.jsになってるかもしれない。そういうリスクが怖いです。勉強すればいいじゃんっていう意見もそうなんですが、なんでしょう、どちらかと言うと保守を気にしているので、そっちじゃないです。まあ幸いにして私は人の書いたJSをいじくり回した経験はないので、ただの推測なんですが。
それともしかしたら「枯れた技術」あるは「標準化」という意識があんまりないのかなとも思いました。まあ確かに「Webの世界は日進月歩！」ってことなのかもしれないんですが…。別のページのブコメとか見ても、「枯れた技術を使う」=「不勉強」みたいなのがあって、不思議です。。
あとcoffeeのころ、っていうコメントありましたが、あの頃はみんな夢がありましたよね。AltJSが世界を救う！みたいな。翻って今はどうか。それを思うと、やっぱり何でもかんでもReactじゃ、という意見には違和感を感じるんですよ。
増田に書いたのは単にみんなが見てくれるというだけの理由です。そもそも今諸般の事情でお仕事としてのエンジニアはしていないですし。ほんとに純粋な質問だと思ってもらえればうれしいです。
まあ長くなってきたので私のブログにまとめ直してもいいのですけど。
そういえばモバイルという話も出ていましたが、先日のandroid instant appsって、アレ「HTMLでモバイル向けに軽快なリッチUI作るの無理だからやめような」ってことかと思ったんですが、どうでしょうか。もちろん今現在は必要ですけど～。
名前から察せる通り、これらはコンピュータとかWebとかそういうのと関係のあるJavaScriptというスクリプト言語に関係する。
そして、この「JSX」という同じ名前のモノが同じ業界に二種類存在してしまっているのだ。ひとつはDeNAが開発したもの、もうひとつはかのFacebookが開発したものだ。
http://facebook.github.io/jsx/
しかも、GitHubで検索したらあといくつかあるらしい。本当に嘆かわしいことだ。
https://github.com/search?q=JSX
私は、DeNAとかいう日本国内だけでは知名度のある企業は、世界的な大企業・Facebookに早くJSXの名前を譲るべきであると思う。
DeNAなんて、日本でいうところの百度や新浪、捜狐に等しい。なんか違法な感じの動画とかちょっとアダルトっぽいコンテンツを見たときに見たことがあるようなないような、というレベルだ。
オープンソースとそのコミュニティーによって支えられている現在のWebというもの、そしてその発展を阻害しないためにはFacebookという巨人に席を譲るべきだろう。
