Vue vs React vs Angular Part.2

**デフォルトの名無しさん** · 2019/03/09(土) 22:02:33.71

実際どうなん？
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/
-
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured
※前スレ
Vue vs React vs Angular
http://mevius.5ch.net/test/read.cgi/tech/1545395856/

★ここではjQueryの話題は禁止です
★jQuery房が書き込んでも無視してください

**デフォルトの名無しさん** · 2019/04/04(木) 00:50:17.12

redux-sagaやばげ
https://qiita.com/kuy/items/716affc808ebb3e1e8ac

**デフォルトの名無しさん** · 2019/04/04(木) 01:57:56.93

今さらかよｗ何年遅れだｗｗ

**デフォルトの名無しさん** · 2019/04/04(木) 11:09:20.60

>>259
function.phpでフックするかプラグインで実装するか、直書きするか、WordPressの標準機能でやるかの4択だから見る箇所多くてな…

**デフォルトの名無しさん** · 2019/04/04(木) 15:52:23.56

このくらいデザイナーでもできるのにフロントエンジニアができないってどういうことだよ？

**デフォルトの名無しさん** · 2019/04/04(木) 19:01:35.04

研修二日、実務経験二年のペテンシ・エンジニアリング・サービス・ソリューション♪

**デフォルトの名無しさん** · 2019/04/06(土) 00:11:30.05

>>228
いいや、データの双方向的な流れがバグの温床になるって話だった
で、 reactはflux, angularはデータバスにrxjs
angular.jsのアーキテクトだったかがvue.jsのメンテナーへ
小規模なアプリはvue.js,大規模ならangularへ流れても良いと思うんだがなー
angular2が出た初期の頃みたいにボイラープレートを動かすだけに何日も掛かるような糞ではなくなったんだし

**デフォルトの名無しさん** · 2019/04/06(土) 00:14:37.44

jqueryの作者はreactへ流れてただろ
jquery的な用途で使われるのはvue.jsの方だとは思うが
reactは設定のための学習コストが高すぎて、アホなweb屋たちが使いこなせない

**デフォルトの名無しさん** · 2019/04/06(土) 01:16:21.80

reactの学習コストが高いっていうけど、
安定したもの作ろうと思ったら他のフレームワークやるとしても結局同じくらい学習コストかかると思うぞ。

**デフォルトの名無しさん** · 2019/04/06(土) 08:49:03.93

>>266
もう3年も前の話だな。それからのReactの状況はいぜんと何も変わらず
いつになったら普及するのかね？

>>267
すごいものを作ろうとしたらどれも大変
ではなくてだな、

ちょいちょいで終わるようなものを作ろうとしたら大変なんだよ
世間で必要とされるもののほとんどは、ちょいちょいで終わるようなものばかり

**デフォルトの名無しさん** · 2019/04/06(土) 09:56:04.81

>>265
実際そういう流れになってると思うよ。ただバインディングの仕組み自体がトリッキーだから、フレームワーク関係無く不安定さが付き纏うのはしょうがない。
要求に対してweb標準仕様が貧弱すぎるから、いつまで経ってもどこか不安定なのはwebの宿命だよ。

**デフォルトの名無しさん** · 2019/04/06(土) 10:46:57.59

本質的にフロントエンド要らないと思うんだよね
デバックにコストが掛かり過ぎて、コストを掛けてまで誰が欲しいのかって話で
片手間のテンプレート的に扱えたangular.jsからvue.jsへ流れると思うけど
frontendの専門部署でreactでなくてvue.jsを使う勢は単に頭が沸いてるだけ

**デフォルトの名無しさん** · 2019/04/06(土) 13:37:29.72

Reactは難し過ぎた
みんなあんなの使えてるの凄いね

**デフォルトの名無しさん** · 2019/04/06(土) 16:11:51.40

>>268
ちょいちょいでいいならexcelにボタンでもつけとったらええやんけとか思う。
まあ実際はバカ経営者に見栄えいいのを見せる目的があるから
クソみたいなフレームアピールするんだろうけどな。
心底くだらねーと思うわ。

**デフォルトの名無しさん** · 2019/04/06(土) 16:40:40.59

Reactごとき難しいってお前らエセプログラマーだろ
世の中のプログラミングの中では圧倒的に簡単なほうなんだが

**デフォルトの名無しさん** · 2019/04/06(土) 17:30:04.31

>>271
学習した教材が悪かったんじゃない？

**デフォルトの名無しさん** · 2019/04/06(土) 18:07:30.00

React2018年初めからV字回復してんな。なんかあったっけ？
https://cdn-images-1.medium.com/max/2600/1*4zlVkNSR8T8KivcDaOD5Dw.png

**デフォルトの名無しさん** · 2019/04/06(土) 18:59:25.24

ライセンスの修正じゃないかな。
その前に急落したのもライセンスが問題にされ始めたころじゃないかと思う。

**デフォルトの名無しさん** · 2019/04/06(土) 19:40:00.22

>>275
2017後半-2018前半頃のトレンドって言ったらPython/機械学習に注目が集まった時期かな

**デフォルトの名無しさん** · 2019/04/06(土) 21:39:49.85

>>275
Angularが今後、死ぬ運命ということだけはわかった

**デフォルトの名無しさん** · 2019/04/06(土) 22:41:07.31

世界中の華橋・華人を動員した結果GitHubスター数はReactを抜いたVueとデッドヒートしてるじゃんｗ
誇っていいだろ

**デフォルトの名無しさん** · 2019/04/06(土) 23:29:44.99

>>276
それだ！
落ち込み、反転、両方説明がつく。
スッキリしたありがとう。

**デフォルトの名無しさん** · 2019/04/06(土) 23:33:50.04

そのうちページ全体が<canvas>になる時代がくるんだろうか

**デフォルトの名無しさん** · 2019/04/07(日) 00:33:24.05

ははは。そんなことありえない。
ウェブアプリなんて一部でしか作られてないよ
殆どはウェブサイト。だからjQueryが使われ続けている。

**デフォルトの名無しさん** · 2019/04/07(日) 10:22:09.78

>>273
React特有のpropが変わると再描画という形がキツかった
普通に部分的な動きをさせたいだけで全部その形にしなきゃいけないのが不自然
不要な部分の更新まで行われてしまったり何回も同じ更新が走ってまくってしまって原因調べるのがきつい

**デフォルトの名無しさん** · 2019/04/07(日) 14:30:36.12

shouldComponentUpdateでfalse返してもダメなパターン？

**デフォルトの名無しさん** · 2019/04/07(日) 15:05:55.66

何らかのアンチパターンやってるケースでしょ
設計思想とか、中の仕組みを想像出来ないとやらかしてしまうのは分かる
うちのメンバーでそういうのあった

**デフォルトの名無しさん** · 2019/04/07(日) 15:40:34.34

逆にreactのコンポーネントを使わずにreduxで更新をやるって感じで
入門するのはどうなんだろうか？こっちのがわかりやすいんじゃなかろうか。

**デフォルトの名無しさん** · 2019/04/07(日) 17:22:26.91

react+reduxは考え方としてはいいんだが、素のreactではコンポーネントのstoreに
閉じていたようなデータまでstore内に混在するのがなんとなく気持ち悪い。
MとVMを分離できたらよかったんだがなぁ。

**デフォルトの名無しさん** · 2019/04/07(日) 17:22:32.93

content apiで十分。

**デフォルトの名無しさん** · 2019/04/07(日) 17:22:49.73

contextだった

**デフォルトの名無しさん** · 2019/04/07(日) 18:45:56.70

javascript歴浅めのものです。
この手のフレームワークのデータバインディンクの仕組みって、buildした後のjavascript的にはどう実現されてるの？
{{data}}とかでマークアップされた箇所にイベントハンドラ付きのjavascriptが挿入されてる感じなんかな？

**デフォルトの名無しさん** · 2019/04/07(日) 19:40:14.89

>>290
簡単な例ならtwo way binding javascriptでググると沢山出てくると思う。ただこれに仮想domやコンポーネントが絡むからずっと複雑。深追できないしするべきじゃない。

**デフォルトの名無しさん** · 2019/04/07(日) 20:09:39.22

two way bindingねえ

例えばvar helloのバインディングならglobal(window)にsetter/getterのhello()を追加して、
helloのsetterが呼ばれて値が変わったら<input>.valueにもそれを代入し、
<input>要素にはイベントリスナーで値が変わったときにバインディング変数(hello)に同じ値をセットしてるのかな

**デフォルトの名無しさん** · 2019/04/07(日) 20:10:59.60

あ、でもそれじゃ無限ループするか（てへぺーろ

**デフォルトの名無しさん** · 2019/04/07(日) 20:13:30.94

逮捕されんぞ

**デフォルトの名無しさん** · 2019/04/07(日) 20:22:59.94

一般のGUIでも常套手段だが、値が変わらなかったらそれ以上伝播しないってことでいいんじゃね。

**デフォルトの名無しさん** · 2019/04/07(日) 20:41:31.99

>>292
>>295
なるほど、やっぱそれくらいのコード書かないとできないのですね。
となるとリッチなwebアプリケーション作るとなると、どれかしらのフレームワーク使いたくなりますな。

**デフォルトの名無しさん** · 2019/04/07(日) 20:46:11.81

徐々にだとしても、今後webブラウザベースのアプリが増えるはずと思っていろいろ勉強中なんです。

**デフォルトの名無しさん** · 2019/04/07(日) 21:25:39.30

>>283
そこ海外フォーラムとかで議論されてるから見ればいい

>>284
それ完全ではないから
あと配列は浅い更新しかみてないから注意

>>286
さすがに全部Reduxにする必要はない

**デフォルトの名無しさん** · 2019/04/07(日) 21:46:10.88

いじめはどこの町にもあるが島本町は特に酷い
「大阪府三島郡島本町のいじめはいじめられた本人が悪い」なんて
公言する町は他に無い

**デフォルトの名無しさん** · 2019/04/07(日) 23:01:30.03

>>297
アプリというか、アプリの様に動作するwebサイトだね。storeに登録しない。個人的に最難関はDBのオフライン対応+同期だと思う。
firestoreもあるがフレームワーク側で対応して欲しい。魔境なので難しいとは思うが。。

**デフォルトの名無しさん** · 2019/04/07(日) 23:38:09.79

>>300
個人的にはオフラインDBは諦めるのがスジがいいと思うけどな。ネットに繋がってて当たり前の時代じゃないですか。

**デフォルトの名無しさん** · 2019/04/08(月) 01:33:01.06

>>300
> アプリというか、アプリの様に動作するwebサイトだね。

それは増えない。アプリの様に動作するwebサイトはjQuery Mobileが
失敗したことからも必要とされていないことがわかっている

※ jQuery Mobile は jQueryとは違うもので、
jQuery UI（こちらもjQueryではない）がデスクトップ用のUIなのに比べて
jQuery Mobile はスマホ用のUIを作るもの

webブラウザベースのアプリが増えるとしても、それはwebサイトからの
変更ではなく、PCアプリ・スマホアプリから、ウェブアプリへの変更となる。

ウェブサイトからウェブアプリに変更したいという要求は
本質的に違うものへの変更になるから生まれてこないんだよ。
PCアプリ・スマホアプリから、ウェブアプリの場合は、
本質的に同じもので動くプラットフォームが拡大されるからそういう要求はある。

**デフォルトの名無しさん** · 2019/04/08(月) 01:51:55.70

>>302
そうか？office365とかgoogle documentとか成功してるじゃん。

**デフォルトの名無しさん** · 2019/04/08(月) 01:53:28.98

いや、そう言ってるのか。

**デフォルトの名無しさん** · 2019/04/08(月) 01:56:14.66

>>302はいったい何を否定しようとしたんだ？webサイトという言葉の使い方がおかしいということなのか？

**デフォルトの名無しさん** · 2019/04/08(月) 02:16:44.05

>>303
> そうか？office365とかgoogle documentとか成功してるじゃん。

それらは、もともとデスクトップアプリだったもの
ウェブサイトだったわけじゃない。

>>305
> webサイトという言葉の使い方がおかしいということなのか？

アプリのように動作するウェブサイトという
変なインターフェースは誰も求めてないという話。
例えるならば、ジョイスティックで操作し、美麗な3Dゲームのような
新聞ビューワーみたいなもの。誰もそんなので新聞を読みたいなんて思わんだろ？

**デフォルトの名無しさん** · 2019/04/08(月) 08:10:05.44

>>306
ん？だったら例えばoffice365はアプリのように動作するwebサイトで成功してるじゃん。

**デフォルトの名無しさん** · 2019/04/08(月) 09:08:14.77

>>302
jQueryMobileは単純にBootstrapとかにとって代わられただけじゃん

**デフォルトの名無しさん** · 2019/04/08(月) 09:15:13.85

>>307
どうせ使ったことないだけじゃね？

**デフォルトの名無しさん** · 2019/04/08(月) 11:34:53.34

>>301
そうなんだよね。オフライン対応って無理がありすぎるんだよね。
以前firebaseのrealtime database使ったが、オフラインからの同期処理に制限が多すぎて厳しい。更新が時系列を保証せず最終更新分だけ同期するとか、かなりクセがある。
WebworkerとindexedDBで効率よくキャッシュする方が当面は幸せになれそう。

**デフォルトの名無しさん** · 2019/04/08(月) 13:53:28.07

>>307
office365はアプリのように動作するウェブアプリであって
ウェブサイトじゃないんだよ

**デフォルトの名無しさん** · 2019/04/08(月) 13:57:09.46

まあこれでも読んで勉強して。IBMだからそれなりに信用できるでしょ？

第 1 回 Web サイトと Web アプリケーションの違い
https://www.ibm.com/developerworks/jp/web/library/wa-websiteapp/index.html

**デフォルトの名無しさん** · 2019/04/08(月) 14:49:09.97

excelで作ったドキュメントをなるべくそのままの形でhtml化する方法は無いでしょうか？
excelでhtml形式で保存すると裏側が汚いです
Gatsbyのプラグインにそれらしきモノがあったので試してみたら、色もセル結合もフォントサイズも全部落ちてしまいました

まぁ自分で自作すればいいんでしょうが、気が遠くなるくらいたくさん作り込まねばならず、皆さんはexcelドキュメントをそのままWeb化したいとか要望された事はありませんか？

**デフォルトの名無しさん** · 2019/04/08(月) 15:43:06.23

>>311
いやだから>>305でwebサイトという言葉の使い方がおかしいということなの？って聞いたのによくわからん回答されたから混乱してるんだが…
で、結局webサイトという言葉の使い方がおかしいってことなのね。

**デフォルトの名無しさん** · 2019/04/08(月) 15:49:10.83

要は、office365のようなものをwebサイトと呼ぼうがwebアプリと呼ぼうが話の本筋には何の影響もないのに、>>302の長文で謎の語りが入ったから話がグチャッとなっちゃったって事実に気づいて欲しい。

**デフォルトの名無しさん** · 2019/04/08(月) 15:51:36.81

>>313
スレチだけどレスすると、
htmlにせずGoogleDocsとかにインポートして公開した方がいいんじゃね
こういうの
https://www.howtonote.jp/google-document/open/index1.html

**デフォルトの名無しさん** · 2019/04/08(月) 20:15:16.81

オフラインデータはクッキーをいじり回すことしか出来ないのね
せめて画像を確実にローカルに保存できればオフラインでも動かせる
アプリが作れるだろうに

**デフォルトの名無しさん** · 2019/04/08(月) 20:22:17.47

>>317
Webストレージで画像保存できるじゃん

**デフォルトの名無しさん** · 2019/04/09(火) 07:41:13.08

reactは覚える事は少ないけども設計力が必要
宣言型プログラミングと同じで高い論理性が要求されるから苦手な人は多いかもね

**デフォルトの名無しさん** · 2019/04/09(火) 23:06:06.17

悲しいのはAngularの勢いが無くなり、横ばいのAngularJSの方が残りそうなところ
もうAngularはGoogle Graveyard入りだろ。どうすんだよAngularで作ってる新規プロジェクト

**デフォルトの名無しさん** · 2019/04/10(水) 00:47:58.78

Angular1の方が好評だったってこと？ｗ

**デフォルトの名無しさん** · 2019/04/10(水) 00:52:39.92

angular使うくらいならvueの方がええわなぁ
reactは論理性高いから日本人には不向きやろなぁ

**デフォルトの名無しさん** · 2019/04/10(水) 01:08:10.98

ググってみたけどreactはhtml側ではあまり小細工しない感じだねえ
論理的というのがいまいち分からないけど

**デフォルトの名無しさん** · 2019/04/10(水) 02:32:35.33

個人的にはbackbonejsが好きなんだけどなあ。自分で自由に作れるし
有名どころ使ってるのに、扱いが微妙

**デフォルトの名無しさん** · 2019/04/10(水) 10:00:46.62

そういえばchromium版Edgeのプレビュー出たけどおまえら使ってみた？

**デフォルトの名無しさん** · 2019/04/10(水) 10:11:11.18

>>320
これ以上進化する予定のないものが残るわけないじゃん

**デフォルトの名無しさん** · 2019/04/10(水) 12:23:01.13

>>326
進化させるのは自分の設計、コーディング次第なのがbackbonejsの思想だけど
フルスタックじゃないから足りない部分は自分たちで補えばいいし
そもそもbackbonejsは、つい最近更新されたばかりで死んでないけどな

昨今のフレームワークは全部入ってるから良いと思ってる
Railsやcakeみたいに作るのが簡単ならわかるけど、複雑化したら折角のフルスタックフレームワークがゴミになるだけ

**デフォルトの名無しさん** · 2019/04/10(水) 12:30:50.16

これ読むと良いかも。
フレームワークとライブラリの違いがわかってない人は特に

フレームワークは善か悪か，その両方か？
https://www.infoq.com/jp/news/2019/04/frameworks-libraries-axon

**デフォルトの名無しさん** · 2019/04/10(水) 13:13:49.79

>>327
AngularJSの話してんだけどアンカ先くらい見ようや

**デフォルトの名無しさん** · 2019/04/10(水) 13:50:22.69

>>327
> そもそもbackbonejsは、つい最近更新されたばかりで死んでないけどな

https://backbonejs.org/#changelog

1.3.3 ? Apr. 5, 2016 ? Diff ? Docs
～それから3年の月日が流れようとしていた～
1.4.0 ? Feb. 19, 2019 ? Diff ? Docs

ほぼ死んどるがなｗ
1.4.0リリース作業の前のコミットは2018年5月だし、
ドキュメントや些細なミスを除けば、機能追加は2017年じゃないか？

**デフォルトの名無しさん** · 2019/04/10(水) 16:27:07.49

>>328
ひと言で説明すりゃいいのにくどくどとしつこい内容だな

**デフォルトの名無しさん** · 2019/04/10(水) 22:25:31.68

>>322
その文からは、お前さんに論理性が無い事しか分からんな。

**デフォルトの名無しさん** · 2019/04/11(木) 00:19:20.16

フレームワークは、先に全体の構造が決まっていて、そこにはめ込む部品を作る。
全体の構造が決まっているから、プロ向き

ライブラリは必要な都度、組み込んで、部分から先に作っていくから、
全体の構造が最後まで決まらないので、スパゲッティ・泥団子になりやすいので危険！

**デフォルトの名無しさん** · 2019/04/11(木) 00:20:57.76

全体の構造なんて先に決めればいいだけやんｗ

**デフォルトの名無しさん** · 2019/04/11(木) 00:26:50.15

>>333
フレームワークに任せとけば安心って思考停止して、結局何と何が依存してるか
わからなくなってそのフレームに閉じ込められるパターン。

**デフォルトの名無しさん** · 2019/04/11(木) 01:02:55.46

>>335
Angularの悪口はそこまでだ！！

**333** · 2019/04/11(木) 02:29:16.00

全体の構造を、各人が決めたら、ダメ！
各人によって、構造に違いがあるから、他人と思いを共有できない

Aが作った構造を、Bが気に入らないなど、トラブルになる

だから、Rails などの既成のフレームワークを使う。
そのフレームワークの構造を共有できるから

多くのフレームワークも、Rails を基本としている

**デフォルトの名無しさん** · 2019/04/11(木) 02:33:37.60

nuxtの出力jsが乱数名みたいになるのなんとかならんのかな

**デフォルトの名無しさん** · 2019/04/11(木) 03:23:58.52

>>337
> Aが作った構造を、Bが気に入らないなど、トラブルになる
> だから、Rails などの既成のフレームワークを使う。

だからその「既成のフレームワーク」を作ったのAで
それを使うBが気に入らないってトラブルになってるんだろ？

**デフォルトの名無しさん** · 2019/04/11(木) 03:24:46.97

Rails 作ったやつは他人なんだから
思いを共有できないわな

**デフォルトの名無しさん** · 2019/04/11(木) 08:16:15.03

>>335
規約に則って書きさえすれば、チームのスキル差を減らして、一定の品質が担保できるのがフレームワークのメリットじゃない？

フレームワークに閉じ込められるって表現してるけど、それ単にチームで設けた規約に不満を述べてるだけかと。

もし今使っているフレームワークに不満あるなら、そもそも最初のフレームワーク選定時に意見を言うべきだし、
発言権のない立場なら大人しく従うか、転職なりしてプロジェクトから抜けるしかないんじゃないかな。

**デフォルトの名無しさん** · 2019/04/11(木) 08:17:20.21

思いは共有できなくても、実績があるフレームワークに従いましょう、ってことで平和に収まるって話だろ。
この効果は間違いなくある。

**デフォルトの名無しさん** · 2019/04/11(木) 08:18:25.70

ジャップのくせに

**デフォルトの名無しさん** · 2019/04/11(木) 14:38:55.28

japjs

**デフォルトの名無しさん** · 2019/04/11(木) 18:06:29.66

某個人アプリ制作者のブログで「5ちゃんのプログラミングスレはqiitaと比べて全然遜色しない内容だ」
って感じで書かれてるから初めて見に来たけど生産性のあるレスほぼなくてワロタ

**デフォルトの名無しさん** · 2019/04/11(木) 18:32:42.76

>>341
規約があればいいがほとんどない。
>もし今使っているフレームワークに不満あるなら、そもそも最初のフレームワーク選定時に意見を言うべきだし、
>発言権のない立場なら大人しく従うか、転職なりしてプロジェクトから抜けるしかないんじゃないかな。
そもそも選定時にはその会社にいないし選定してった奴は転職なりしてプロジェクトから抜けてるわけで
マジクソだよ。

**デフォルトの名無しさん** · 2019/04/11(木) 18:33:55.90

>>346
さっさ転職しろ

**デフォルトの名無しさん** · 2019/04/11(木) 19:27:20.19

>>345
このスレじゃなさそうだな。。今angularを勉強してるが、これじゃないとという理由が見つけられないでいる。学習曲線や人員的な問題は置いといて、明らかに有利な点や逆にangularで困る事があったら教えて欲しい。

**デフォルトの名無しさん** · 2019/04/11(木) 19:42:22.98

日本にいるとVue人気だから勘違いしそうになるがやっぱ採用実績はReactが圧倒してるんだな。475kサイト vs 64kサイトか……
しかしなぜかGitHubのスター数だけタメ張ってるｗ
Top JavaScript Frameworks For 2019
https://www.codementor.io/nikhil21tyagi/top-javascript-frameworks-for-2019-s8881i8ga

パフォーマンスについてはReactよりVueのほうがいいな。
AppRunってやつ速くて気になる。
しかしAngularいくらなんでも酷すぎる……
A RealWorld Comparison of Front-End Frameworks with Benchmarks (2019 update)
https://medium.freecodecamp.org/a-realworld-comparison-of-front-end-frameworks-with-benchmarks-2019-update-4be0d3c78075

**デフォルトの名無しさん** · 2019/04/11(木) 23:55:39.98

>>349
AngularJSは確かにダントツで遅いけどAngularは別に悪くないじゃん

**デフォルトの名無しさん** · 2019/04/12(金) 00:57:20.94

>>349
hyperAppもなかなか。

**デフォルトの名無しさん** · 2019/04/13(土) 12:59:41.28

SPAでログイン画面というかログイン機構作る場合はどうするのがベストプラクティス？認証用のアカウント情報はサーバー側のDBにあるとして

**デフォルトの名無しさん** · 2019/04/13(土) 13:42:39.23

>>352
使ってるフレームワークとやりたい事で変わるからなんとも。。
例えばログイン後は各ユーザ用の専用ページがあるって感じ？でなければセッションに保存して分岐するだけで済むはずだが。

**デフォルトの名無しさん** · 2019/04/13(土) 14:51:30.35

Angularは脂肪確定でよろしいか？
ReactかVue.jsの二つやっとけはいいのかな

**デフォルトの名無しさん** · 2019/04/13(土) 16:25:49.51

>>354
俺も悩んでる。普段reactとvue(nuxt)使ってて、今angular勉強中なんだが乗り換える必然性が見つからん。もちろんangularは力技使わなくても色々解決出来そうな感じで良さげなんだが。
ただもう少し勉強せんと冷静な判断できんわ。

**デフォルトの名無しさん** · 2019/04/13(土) 16:36:03.16

>>352
Firebase Authentication使えばよくあるGoogleアカウントでログインだのFacebookアカウントでログインなんかが出来るよ。

面倒くさいDBでのアカウント管理も全部Firebase上で出来るから実装に無駄な時間を掛けなくて済むよ。

**デフォルトの名無しさん** · 2019/04/13(土) 17:51:56.66

Google I/O 2019 (5月7日～9日)で
Angularと対立することになる Flutter for Web (Hummingbird) の新たな発表があるそうだから
Angularを考えるのはその後にした方が良いと思うよ

**デフォルトの名無しさん** · 2019/04/13(土) 21:46:54.35

>>357
Flutter面白そうだね。たしかにクロスプラットフォーム開発はスタンダードが無いから学習するなら狙い目なのかも。現状swiftとkotlinでゴリゴリ書いてるけどどうしてもrealmが必要なんだよね。
Webアプリの弱点の一つオフラインDBをある程度解決できるなら真面目に検討したいんだが。

**デフォルトの名無しさん** · 2019/04/13(土) 21:50:11.69

>>358
オフラインDBが弱点って具体的にどういうこと？

**デフォルトの名無しさん** · 2019/04/13(土) 22:53:34.64

>>359
ユーザデータを大量に保存してローカルで処理する系のアプリは現状webアプリだと厳しい。主に速度面で。
indexedDB+lovefieldみたいな組み合わせでsqlぽい事はできるけど、flutterがアプリ+webのクロスを狙うならソコどうするのかなって。DBの同期まではできなくても、一つのスキーマから全プラットフォームで動作するDB作れたら夢だよね。