Redux(react-redux)における適切な配列要素の更新
2021年8月23日…
Meteorのブームが来るか来ないと言われれば、来ないと思ってしまった件
2017年4月22日
2016年秋頃から、2017年3月頃まで、Meteor(v1.3.3)で動いているシステムを実際に開発に携わってみて感じたことを知見として書いておくことにする。基本的には、表題についての根拠がつらつらと書かれている。主に技術選定をするという目線で読んでいただきたい。
DB選択肢がMeteorの長所を活かし切るとMongo DB固定になる
Meteorのリアクティブ動作の恩恵を受ける場合、前提としてDBはMongo DBを選択することになる。Mongo DBで事足りたり、ノウハウがあれば全く問題はない。だが、例えばECサイトなどでトランザクションが使いたかったり、整合性を気にしだすとMeteorが悪いというより、Mongo DB自体が不得手な分野になるので、選定を考える必要がある。プログラムは単にデータベースのラッパーと考える人もいると思うが、プログラムというより、そもそものデータベースの扱いが分からないと致命的だ。正直、Meteor が悪いのではなく、Mongo DBというまだまだメインDBとしてガンガン使われていないDBをいきなり運用することになるので、そこが辛いように思えた。
パッケージの選定から、パッケージ自体のメンテナンス性まで多くの不安が残る
Rails界隈ほどうまくいってないように思える。何かしらやりたいことだったり、Githubでちょっとしたパッケージを探した際に最終更新が「2 years ago」と平気で書かれていたりする。あとは、気になる点として、Meteorはrouterから純正またはサードパーティのパッケージを選択可能で、わりとアプリケーションの根幹の部分から割れている。routerは案外重要で、iron-routerとflow-routerで使用可能なパッケージが異なるケースがよくある。技術選定の際、ベストな選択がすぐに決まらないのはネックだろう。
Meteorは該当バージョンに対応するNode.jsしか使えない上、サポートするNode.jsのバージョンが古い
現状2017年4月現在、最新安定板のMeteorはv1.4だが、対応するNode.jsのバージョンはなんとv4と、現状のNode.js環境(2017年４月22日現在最新はv7、長期サポートバージョンはv6)と比較し、かなり遅れをとっている。ES2015の記法が徐々に現場に浸透してきている中、Node.jsの最新の長期サポートバージョンの6ではなく4でロックされる状態は少し考えてしまう。
Meteor自身が時代に合わせたユーザを魅了するパワフルなアップデートをしていない(これは完全に主観)
Railsでいうならv5でActionCableが実装され、WebSocketを扱うRails開発者に恩恵を与えた。Meteorが特に話題性のあった(?)時期の2012年頃の場合は、Meteorの基本機能のリアクティブ同作、それ自身がメリットであったが、特に他は聞かない気がする。とはいえ、Meteorはすでに基本的にはリアクティブ動作だし、Cordovaを使いネイティヴアプリのコードも出力できるし、コンセプト的にこれ以上必要か？と言われると盛り過ぎな感じもする。
期待するとしとら、個人的にはrouter機能を強化した上で、Meteor自身に内包すること、あとはAPIを作りやすい機能を入れるなどするなどしたら面白いのではないかと思った。なぜこれを思ったかというと、Meteorはあまりに制約がなく、かなり自由度が高い。ある程度制限されても、例えばJSONを出力するAPIをすぐに作れることは結構メリットなのではないかと感じたからだ。
フロントエンドフレームワークのBlazeを選択するとmetaタグで簡単にハマる
詳細については、1つ前の別なエントリーに状況を書いたので、そちらを参照して欲しい。Blazeについては正直、Meteor公式のミスリードと思っている。Meteor v1.3くらいまではBlazeを公式がバックアップして推していた印象があるが、実際Blazeを使ってみてかなりの残念具合だったので、Blazeが公式から分離されたという事実も踏まえると、Meteor自体の動向も少し怪しい印象すら個人的には感じてしまう。強い言葉でいうと、リアクティブ動作に最適化したフロントエンドの構築にMeteor公式が失敗した、という見方をしてしまった。
MeteorのGitHubのスター数に対しての注目度合いについて、若干の疑問が残る
2017年4月22日現在、MeteorはやはりGithubスター数はどのWebアプリケーションフレームワークよりも多いことが確認できた(Github / Web application frameworksを参照し、37,187)。一方で、少しクラスタが狭まるが、2016年で注目度が上がったWebアプリケーションフレームは、Expressであることが、下記の記事により分かる。
JavaScript ベスト・オブ・ザ・イヤー 2016
この状況から、Meteorのスター数は実際は2015年から劇的には変わっておらず、これだけのスター数がありながら、注目度が上がっているかといえば実際はそうでもない。実際にMeteorに手を出してみると、ちょうど今から2年前、2015年で更新が滞っているようなパッケージも多い。インターネット上で記事を探すと、2012年頃が多かったりなど、なんとなく情報も停滞している状況も感じられたりする。
Meteorは、Githubスター数がRaisを超えてかなり多かったため、本ブログでもMeteorを複数回取り上げることに至ったが、実際のところ実情はどうなのかという話になると、GitHubのスター数を指標にするだけではちょっとアヤシイ印象を今では持っている。
現状ではMeteorの使いどころは難しいように思える。Node.jsで組むならExpressで良いし、メンテナンス性、周辺環境が優れたフルスタックフレームワークにいくならRailsで良い気がする
以上のことから、Meteorは注目されているようで、そうでもないし、フルスタックといえども、Rails並みに環境が揃っていて、メンテナンスされているモジュールに恵まれているかといば、そうでもない。印象的には、かなり中途半端なフレームワークと認識している。色々と中途半端な環境が仇となり、扱いが難しいような気がしている。あまりここでは触れないが、mup-xなど、ソースコードをDockerコンテナ化してデプロイするなど、デプロイ方法も変わっているし、おそらくスタンダードが確立されていない。
では、そのような状況の中、Meteorを取り扱おうと思っていた人がMeteor以外のWebフレームワークを選択しようとする場合、何を選定すれば良いのか。答えはわりと簡単で、Meteorに周辺環境の充実を求めていたならRailsに行けば良い。Railsでは、定番のモジュールが長くメンテナンスされているし、Meteorと異なり、ルーティングだったり、ORMがRails公式のロジックが強く、既にRailsに内包されたものを使うことになる。よって、Meteorのrouterのように、アプリケーションのコア部分から覆されたり、妙なロックインにハマることはまずない。また、好みが別れるが、Railsのほうが規約が多い上、知見も多い。そのため、開発・運用上のベストプラクティスを見つけやすいだろう。
Meteorに、Node.jsの高速な処理速度かつ、よくメンテナンスされているフレームワーク環境求めていた場合は、Expressに行けば良い。Expressは、2017年4月22日現在、現状はv4だが、v5のリリースも控えている。Node.jsの黎明期からこれまでスタンダードのポジションは揺るがず、フレームワークが提供するAPIがよくメンテナンスされていることだろう。
Meteorにまつわる本ブログの関連記事へのむすび
本ブログは、2017年4月現在で、圧倒的にMeteor関連記事による自然流入が多いわけだが、Meteorに関する記事が多いからといってMeteorを激推ししているわけではないので、このような否定的な内容の記事を書いた。技術選定にまつわる話ということで今回はシビアな内容だが、作っていて面白いフレームワークではあるので、製品レベルみたいな話でないのなら、他のWebフレームワークにはない特徴を有する、最も面白いフレームワークはMeteorという認識は今でも変わらない。
＞＞＞
最後に、JavaScriptのフレームワーク論争は、プログラミング言語の論争とたいして変わらないと思っています。ですので、純粋にJavaScriptを学びたい！という気持ちでここは一歩踏み出して、まずはここで挙がっているモダンフレームワークのどれか1つにトライしてみることをお勧めします。僕が挙げたフレームワークの中では、最初に学習するフレームワークとして選択するものはVue.jsがとっつきやすいと思います。Reactができると今後の人材市場でかなりポイントが高いと思いますが、僕はデータバインド以外にテンプレート向け構文があるなど、ある程度の機能がまとまっているVue.jsを標準として覚えていったほうが、今後JS好きさんが他のフレームワークを学ぶにあたり良い軸になるのではないかと思っています。
ここまで、自分が使ったことのないVue.jsをお勧めしておいて、このまま投げっぱなしも嫌なので、リクエストがあれば、責任を持ってチュートリアルか何かの記事を書くことをお約束します(もちろん、Reactでもいいですが)。
こちらのコメントを見て、投稿させてもらいます。
生のJSの基礎を学んだ者ですが、生のJSだけでJS中心の仕事ができれば一番ですが、
ちょっとしたWEBサイトの動き程度の仕事しかなく、SPAなどJS中心の仕事をやりたいなら、絶対に
フレームワークをやらないと仕事にはならないとこちらに記載があり、現在react、vueどちらをやるべきか迷っています。
つい最近までreactが圧倒的に中心でしたら、今年あたりからvueに移り始めたと聞きます。
そろそろreactは、angulerのように一昔前の古いものになり、vueが最新になるのかなと思っています。
癖もvueはreactより少ないと聞きます。
ただ需要という意味では圧倒的にreactであることは数年は変わらないので、vueをやっても、ほとんど仕事にありつけず、
結局元請けからreactをやってくれと言われるのが現状でしょうか？
恐れ入りますが、アドバイスいただけれが幸いです。
meteorはフルスタックのようで効率がいいと思いましたが、もうはやりそうにないのですね。
残念
>> Vueさん
こんにちは。
コメントありがとうございます。
そうなんですよね、JavaScriptは技術の流行り廃りが非常に激しいのでJavaScriptそのものがちゃんと書けるのはそれはそれで必要だとは思います。
ですが、JavaScriptの技術者は、数年間隔で様変わりするフレームワークの変遷にも、時代に合わせて着いて行かないといけないのが辛いところです。
自分も最近疲れて来て、どうしたものかと思っております。
>>そろそろreactは、angulerのように一昔前の古いものになり、vueが最新になるのかなと思っています。
癖もvueはreactより少ないと聞きます。
Vueは腰を据えて勉強できていないのですが(チュートリアル的なコードを少し書いたくらいです)、ドキュメントの整備状況だったり(日本語ドキュメントがしっかりしている)、Github上での注目度、使用者からの評判では良さそうだなと思っています。
Vueは去年から今年にかけて注目度が上がり、今も注目度が高いようですね。
たまにGithubのTrending(https://github.com/trending)を見ますが、よくVueを見かけますね。先ほど確認したところやはりVueがランクインしていました。
実際のReact開発では、Reactコンポーネントを生成するにあたり、HTMLに代わるJSXタグをひたすら打っていく感じだと思いましたが、このJSXタグ記法が冗長と感じた場合、Vueはタグっぽくないコンポーネントの作り方をするので感覚的にはReactよりは合うのではないかと思います。
Reactはフレームワークではなくライブラリですので、Reactを選んだ場合、必然的にReactでは足りない機能を継ぎ足して使うことになるので、その点が注意です。
React開発では、時間的な意味でReactがサポートしていない変なところでイニシャルコストを取られると思います。例えば、Reactコンポーネント外で状態管理をおこなうRedux(http://redux.js.org/)の学習では、Reduxの概念自体は簡単なのですが、Reduxでの状態管理を突き詰めていった場合、さらにRedux向けのミドルウェア(Redux-Sagaなど)を足していったりするので、分かりにくいと感じるシーンもあると思います。React開発は、React単体を使うまではそれほど時間を要さないが、より複雑なアプリケーションを作る際には学習コストが思った以上に増えるといった認識です。
>> ただ需要という意味では圧倒的にreactであることは数年は変わらないので、vueをやっても、ほとんど仕事にありつけず、
結局元請けからreactをやってくれと言われるのが現状でしょうか？
少しずれますが、技術選定にまつわる根本的な話をまずしたほうがこの辺は分かりやすいと思います。
結局、趣味の開発ではなく、何かの事業のための開発となった場合の技術選定では「現時点である程度流行っていて、今後廃れにくそうな技術」を軸することがわりと多いのではないかと思います。
理由は、リリース後の運用段階で運用できる人が安定して欲しいからと、あと流行っている技術ということは、ある程度は技術がメンテナンスされていることが見込まれるからです。
そういうわけで、Reactは1〜2年前から開発者の界隈では勢いを増してきて、知名度が現状の採用の市場にまで確実に浸透しています。そうなると、何かを作る時にReactを採用しやすくなるわけです。
ReactとVueを比較した場合、採用の市場ではReactの求人はまだまだ多いし、市場からの需要は衰える気配はないので、あと1年くらいはこの調子なんじゃないかと思っています。
一方、Vueは昨年の半ばくらいから最近までにかけて特に勢いを伸ばしたフレームワークだと思っています。そのため、まだまだ採用の市場までにVueの認知が浸透する、Vueを扱える技術者が増えるまでには時間がかかるのではないでしょうか。
ちなみに、残念ながら僕が生活していて、Vueについての求人は今現在見たことがないです(知人のスタートアップではVueを採用していました)。やはりまだVueの認知度は低いようです。
参考までに、シリコンバレーの局所的な需要の比較データを載せておきます。2017年6月時点のReact, Angular, Vueの求人の需要です。
Hacker News Hiring Trends – Most Popular Programming Languages (June 2017)
http://www.ryan-williams.net/hacker-news-hiring-trends/2017/june.html?compare1=react&compare2=AngularJS&compare3=Vue&compare4=
市場自体の需要の話は抜きにして、技術選定の権利を得てする仕事がある場合、JavaScriptの技術者の中ではVueは既に評判は良いですから、今の段階で使ってみるのはありだとは思います。僕も個人の製品でVueを適用してみようと思っています。
元請けさんに、効率性やSPAはバーチャルdomでないとやってられないなどの理由から、react、ExpressでTODOアプリが作れないと生のJSでは仕事はやれないといわれてしまい大変迷っています。
やっと生のJSがある程度分かるようになったばかりなのですが、SPAなどJSメインの仕事をしたいなら、元請けがreactを採用していることが圧倒的に多い現在reactをやるしかないでしょうか？
今はvueの方が最新で数年後にはreactすら、オワコンになってvueの時代になっているのではと心配です。
また、Expressまでやるのは正直いっぱいいっぱいなのですが、SPAの仕事はExpressはどこまで要求されることが多いでしょうか？
ajaxで変更したい要素をWEBサーバからダウンロードする程度で十分なのでしょうか？
色々と大変恐縮ですが、アドバイスいただければ幸いです。
>> Vueさん
続けてコメントをお返します。
>> 元請けさんに、効率性やSPAはバーチャルdomでないとやってられないなどの理由から、react、ExpressでTODOアプリが作れないと生のJSでは仕事はやれない
そうですね、生DOMの更新コストの高いことについての言及だと思いますが、よく分かります。
生のDOM変更コストがかさんでくると、しまいにはDOMのレンダリングが遅くなり、ユーザビリティが低下してしまいます。
現行流行っているJavaScriptフレームワークについて、どれを選んでもそれほど悪くはない結果が待っているとすれば、DOMの変更コストをほとんど意識せずに開発に専念できることでしょうか。
>> また、Expressまでやるのは正直いっぱいいっぱいなのですが、SPAの仕事はExpressはどこまで要求されることが多いでしょうか？
ajaxで変更したい要素をWEBサーバからダウンロードする程度で十分なのでしょうか？
SPA前提のExpressだったりする場合は、おそらくはほとんどのケースでAPIを開発することになると思います。
端的にいうと、Reactレンダリングするために必要なデータをExpressへリクエストし、JSONなどの形式で取得するスタイルだと思います。ですので、Ajaxで変更したい要素を〜とコメントされていますが、この認識で間違っていないと思います。
Expressでやる基本的なことに言及するとすれば、POST, GETなどのHTTPリクエストに対し、意図するJSONデータを返すことができれば良いかと思います。
また、一概に「APIの開発」といっても、要求する仕様や担当範囲は色々あるので、こればかりは本当ケースバイケースだと思います。
Expressは軽めのフレームワークなので、データベースのアクセスに使うORマッパーだったりドライバは自分で選定する必要があります。
あくまでAPI開発のExpressを使う範囲でいうなら、APIのルーティングだったり、ORマッパーなどを通じて、データベースから必要なデータを取り出すことになります。
しかし、Expressから取り出すデータ自体の設計はどうするのか、そもそもデータベースはMongo DBなのかMySQLなどのRDBMSなのか、など言い出したら、もちろんもっとやることが増えます。
お返事大変ありがとうございます。
＞＞＞
ですが、JavaScriptの技術者は、数年間隔で様変わりするフレームワークの変遷にも、時代に合わせて着いて行かないといけないのが辛いところです。
自分も最近疲れて来て、どうしたものかと思っております。
サーバサイドはPHPに落ち着いているようですが、本当にWEBのフロントは、htmlもcssもjsもデザインも数年で変わってしまうので、
普通の人のような生活が出来ずに疲れてしまいます。
常に最新のものができないといけないなら、数年後にvueに変わったらreactがわかる人もvueをやらざる負えなくなるのですね。
すっとこのままだとやめるまで独り身でいるしかないといっても過言ではないですね。
家族から頭のおかしい引きこもりのオタクと言われますねWWW
＞＞＞
ReactとVueを比較した場合、採用の市場ではReactの求人はまだまだ多いし、市場からの需要は衰える気配はないので、あと1年くらいはこの調子なんじゃないかと思っています。
一方、Vueは昨年の半ばくらいから最近までにかけて特に勢いを伸ばしたフレームワークだと思っています。そのため、まだまだ採用の市場までにVueの認知が浸透する、Vueを扱える技術者が増えるまでには時間がかかるのではないでしょうか。
ちなみに、残念ながら僕が生活していて、Vueについての求人は今現在見たことがないです(知人のスタートアップではVueを採用していました)。やはりまだVueの認知度は低いようです。
参考までに、シリコンバレーの局所的な需要の比較データを載せておきます。2017年6月時点のReact, Angular, Vueの求人の需要です。
Hacker News Hiring Trends – Most Popular Programming Languages (June 2017)
http://www.ryan-williams.net/hacker-news-hiring-trends/2017/june.html?compare1=react&compare2=AngularJS&compare3=Vue&compare4=
技術面からみるとvueはreactに劣らず、しかもreactより、簡単（生のJSに文法などが似ている？？）なので、今から初めてライブラリをやるなら、
一番良い選択肢ではあるが、
仕事を請けるという面では仕事がほぼない状況なので、今後一年間はreactしか選択肢がないと言い切っても良い状況なのですね。
すると仕事をこの一年に欲しい場合は必然的にreactで決定するという事ですね。
下記のようにいくつかは存在するようですが、非常に少ないため、現実そのような企業から仕事を請けることは不可能に近いのが現状なのですね。
https://employment.en-japan.com/desc_802586/
一年以上とは結構長いですね。そう考えると供給もいいでしょうが、reactは3から5年は仕事に困らないでしょうね。
＞＞＞
市場自体の需要の話は抜きにして、技術選定の権利を得てする仕事がある場合、JavaScriptの技術者の中ではVueは既に評判は良いですから、
今の段階で使ってみるのはありだとは思います。僕も個人の製品でVueを適用してみようと思っています。
自分でWEBアプリやネイティブアプリを作るならvueでよさそうですね。
ただこれでは、おこずかい程度で、生活は難しいでしょうね。
私はWEBのフロント周りと簡単なWEBアプリ制作しかできたことはありませんが、
もし個人でWEBアプリ制作をされる際に、人手が必要で、渡し程度の初心者でもよろしければ教えていただければ幸いです。
＞＞＞
そうですね、生DOMの更新コストの高いことについての言及だと思いますが、よく分かります。
生のDOM変更コストがかさんでくると、しまいにはDOMのレンダリングが遅くなり、ユーザビリティが低下してしまいます。
現行流行っているJavaScriptフレームワークについて、どれを選んでもそれほど悪くはない結果が待っているとすれば、DOMの変更コストをほとんど意識せずに開発に専念できることでしょうか。
やはり、WEBサイトのインタラクション程度以上は、生でというのは絶対にありえないのが現状なのですね。
生が一番早いとは聞きますが、DOM操作がかさむと、reactより重くなるのですね。
それではSPAなどで、生はあり得ないですね。
＞＞＞
SPA前提のExpressだったりする場合は、おそらくはほとんどのケースでAPIを開発することになると思います。
端的にいうと、Reactレンダリングするために必要なデータをExpressへリクエストし、JSONなどの形式で取得するスタイルだと思います。ですので、Ajaxで変更したい要素を〜とコメントされていますが、この認識で間違っていないと思います。
Expressでやる基本的なことに言及するとすれば、POST, GETなどのHTTPリクエストに対し、意図するJSONデータを返すことができれば良いかと思います。
また、一概に「APIの開発」といっても、要求する仕様や担当範囲は色々あるので、こればかりは本当ケースバイケースだと思います。
Expressは軽めのフレームワークなので、データベースのアクセスに使うORマッパーだったりドライバは自分で選定する必要があります。
あくまでAPI開発のExpressを使う範囲でいうなら、APIのルーティングだったり、ORマッパーなどを通じて、データベースから必要なデータを取り出すことになります。
しかし、Expressから取り出すデータ自体の設計はどうするのか、そもそもデータベースはMongo DBなのかMySQLなどのRDBMSなのか、など言い出したら、もちろんもっとやることが増えます。
Node.jsに関しては、生でできなくても、Expressを使ってPOST, GETなどのHTTPリクエストに対し、意図するJSONデータを返すことができれば、とりあえず合格ラインという事ですね。
つまり入門がExpressでできればいいのですね。
そこまで深く必要がなさそうで安心しました。これ以上なら分業が多いと助かります。
DBは分業の場合はわからなくてもいいが、分業でない場合は、入門程度やらないといけないのですね。