Vue vs React vs Angular

2018/12/21(金) 21:37:36.86

実際どうなん？
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/

VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

**デフォルトの名無しさん** (ｱﾒ MM03-5/sk) · 2019/02/01(金) 18:25:03.74

twitterはともかくfacebookおもちゃかあれ？
すごいアプリ製作してるんだね。

2019/02/02(土) 01:22:26.04

Amazonって欲しいものリストの部分だけReact入ってるみたいだね

2019/02/02(土) 04:16:46.09

WappalyzerっていうChrome拡張入れるといいよ
サイトでReact使ってたら素晴らしいしReact+Gatsby使ってたらナカマだし、違った見方でネットブラウジングできる
jqueryのみだとダサってなる（実際サイトの用途にはよるし使ってる人ごめんなさい）
他にも使ってるサーバーとかDBとかWordPressだ～とかわかるよ

2019/02/03(日) 19:47:52.31

vuetify使ってる人いない？

公式のマニュアルが説明不足で全然わからんのだけど、
どこで情報仕入れてる？

formのresetボタンすら動作しない
もっと見やすくてわかりやすいUIはないものか

2019/02/03(日) 22:23:42.35

vuexに依存しないvueコンポーネントってどうやって作ってる？
頑張ってpropで渡すか、コンポーネントextendsしてメソッドオーバーライドするしか
思いつかないんだけどみんなもっと上手いことやってるの？

**デフォルトの名無しさん** (ｱﾒ MM03-LWaQ) · 2019/02/04(月) 00:48:04.11

てかなぜvuex使わないのか

2019/02/04(月) 08:07:14.34

全般的にUIコンポーネントって部品の説明不足だよな

2019/02/04(月) 08:32:32.96

>>174
書き方が悪かったかも知れん。現状でもvuexは使ってる。

例えばvuexにstore/user/flowerFlag:boolean がある
flowerFlag === trueならボタンコンポーネントの色を花っぽくにするって時にどうしてる？

1.propでflowerFlagを渡す
2.コンポーネント内にgetColoer()メソッド作って個別にextend/overwriteする

この2つの方法以外にももっといいやり方あるんかな？

2019/02/04(月) 09:29:22.24

UIコンポーネントは自作すればいい

2019/02/04(月) 09:42:43.98

flowerFlagって名前が気に入らない
何をするフラグなのかさっぱり分からない
useFlowerTheme: boolean とかにしろや

2019/02/04(月) 12:27:23.88

shoriKbnFlg

2019/02/04(月) 14:15:30.10

makeBrainFlower === true

2019/02/04(月) 19:55:50.85

havingDirtyFireworks = true;
https://www.urbandictionary.com/define.php?term=Dirty%20Firework

2019/02/06(水) 17:54:16.50

SPAフレームワークでSSRが醸し出す、一周回ってMVCフレームワークに戻ってきた感が笑える

2019/02/06(水) 18:43:12.38

そう思いたくて必死なのが笑えるｗｗｗ
そうやって得た安心は妄想だぞｗｗｗｗ

Rendertronを使ったダイナミックレンダリングの実装手順をGoogleが解説
https://www.suzukikenichi.com/blog/google-explains-how-to-implement-dynamic-rendering-with-rendertron/

2019/02/08(金) 18:47:35.85

Reduxってムズイよな

2019/02/08(金) 20:58:46.78

どのへんが？

2019/02/09(土) 08:15:58.88

Vueに乗り換えます
じゃあな

2019/02/09(土) 08:16:45.44

めっちゃIDがReduxっぽいけど

2019/02/09(土) 08:29:03.30

ここvueスレでもあるけどよくわからんがさよなら

2019/02/09(土) 13:36:35.69

スレタイのやつ3つとも触ったことないままAureliaってやつを採用しようと思ってるんだが、お前らの評価はどんな感じ？
採用の理由としてはVueが選ばれるのと同じだと思う

2019/02/09(土) 14:04:19.59

調べてみたら3年くらい前にちょっと流行ったみたいだけど
未だに話題になってないって事はそういう事なんじゃない？

2019/02/09(土) 18:48:21.70

流行り廃れでフレームワークを選ぶんじゃねえ！
自分に一番合ったフレームワークを選ぶんだ！

2019/02/09(土) 21:03:07.28

そうするとjQueryでいいということになる

**デフォルトの名無しさん** (ｱﾒ MMcd-z8kj) · 2019/02/09(土) 22:38:36.16

https://jquery.com
jQuery: The Write Less, Do More, JavaScript "L i b r a r y".

ライブラリであることに負い目でもあるのかな？ｗ
フレームワークの流儀を押し付けられず、どこでも好きなように自由に使えるのがライブラリの強みだと言うのに。

2019/02/09(土) 23:21:06.75

どこ見て負い目があると感じたんだ？
ライブラリだからライブラリって書いてあるだけだろう

2019/02/09(土) 23:22:07.95

angularはwebエンジニア以外の血が流れてるんじゃないのか？ゲームエンジニアでhtmlもjavascriptも経験がなかったときの俺には非常に使いやすかった。
web関連の経験値がたまってきた今となっては大がかりに感じちゃってあえて使おうという気はでないが…

2019/02/09(土) 23:54:11.39

フレームワークと言われるのがウゼーから強調してると思うが
Reactもライブラリって名乗ってるな

2019/02/10(日) 00:23:54.54

結局MVC+jQueryが一番バランスとれてんだよな
SPAなんて作る側にも使う側にも画面遷移が超早いぐらいしかメリットねえもん

2019/02/10(日) 01:13:27.71

>>197
それは流石にSPA作った事無いやつの暴論

2019/02/10(日) 02:19:44.57

jQueryの功績は確かに大きい。その次の世代として仮想domありきのvueやreactなんだから、jQueryとの比較は意味が無い思う。

2019/02/10(日) 02:53:41.79

大雑把にいうとライフサイクルメソッドみたいなイベントとか状態管理などの枠組み含むものがフレームワークで
枠組は使用者が作って機能を呼び出すのがライブラリだろ

2019/02/10(日) 13:00:31.92

>>199
> 仮想domありきのvueやreactなんだから、

仮想DOMはメリットじゃないよ

フレームワークの設計上どうしても遅くなるという問題を
回避するための手段でしか無い
遅くなければ仮想DOMなんて無いほうが良い

2019/02/10(日) 15:30:08.63

そういやスタイル側のフレームワークって何がいいの？
基本はBootstrapなんだろうけど

2019/02/11(月) 18:23:39.83

やりこめば
やるこむほど
思うけど、vueは簡単じゃあないと思う。

2019/02/11(月) 19:34:12.30

reactとvueどっちがむずいのかね

2019/02/11(月) 20:28:50.21

よう分からんけど、日本じゃ wasm は話題にならないね。
情報が遅れてるんだろうか？

2019/02/11(月) 21:18:49.40

javascriptが十分に速いから

**デフォルトの名無しさん** (ｱﾒ MMcd-z8kj) · 2019/02/11(月) 21:40:45.56

wasm盛り上げたいgoogleもjs速くし過ぎたと後悔してることだろう

2019/02/11(月) 21:46:24.07

wasmが必要となるようなものは、
ウェブじゃなくてアプリにするから

2019/02/12(火) 08:51:23.06

なるほど、日本では、「JavaScript を高速にしたもの」と思われている段階なんだね。
アメリカではパラダイムシフトが起きると思われているらしく、色々と恐れられて
いたりもするらしい。

2019/02/12(火) 10:58:51.22

ﾜｯﾁｮｲがVueやんけ

2019/02/12(火) 12:14:49.91

>>209
パラダイムシフトと言っても所詮
ウェブがアプリに追いつくぐらいの意味でしか無いから

2019/02/12(火) 12:37:49.91

C#がクライアントで使えるようになるだけでもかなり有り難い
Microsoftなら開発者に優しいエコシステムを提供してくれる

2019/02/12(火) 13:41:43.16

あんなもの昔の時代へのパラダイムシフトでしかないだろ
負の遺産を再び抱え込むだけだよ

2019/02/12(火) 14:02:56.84

>>212
wasmでは、C#は使えるようにならないはず、一生。

2019/02/12(火) 14:38:31.80

NaClが出始めの頃や、なんならActionScriptやSilverlightのRIAでもパラダイムシフトだのなんだの言われてたな。

2019/02/12(火) 15:14:29.49

>>214
すまん。既に使えるらしい。
.Net 仮想マシンを、wasm に移植したのかな。

2019/02/12(火) 15:24:18.10

WinForm か WPF か知らないけど、そういう標準的な作り方をしたC#が
ブラウザでそのまま動くということではなくて、Razorを使って専用に
作らないといけないらしいね。

2019/02/12(火) 15:50:17.94

JavaのGUIの場合、Swingは、完全にJavaで書かれていて、OSに
依存せずに全部自前で書かれているので、Java仮想マシンさえ動けばどんなOS
でも完全にGUIアプリが動く。
でも、C#の場合はライブラリがWin32 APIなどを呼び出しているから、そうは
行かないみたいだね。よく知らないけど。

**デフォルトの名無しさん** (ｱﾒ MMcd-z8kj) · 2019/02/12(火) 17:33:20.32

razorてメチャメチャ容量大きくなっちゃってまだまだ使い物にならないんでしょ？モバイル用にでも使えるくらい小さいの吐いてくれないかなぁ…

2019/02/12(火) 19:00:48.09

webの技術にパラダイムシフトって言われるような変化起こすにはjavascriptの標準仕様が劇的に変わるか、革命的なブラウザが出てきてとんでもないシェアを握るってパターンしかないという理解だわ。

2019/02/12(火) 19:36:10.46

無理して既存の資産をwasmに移植するメリットはないと思うね
最初はへんな抽象化せずにDOMによく馴染むHTMLフレンドリーなライブラリをC#で実装してくれればいい
なんならjQuery.Netみたいなパクりでもかまわない
手を出しやすい土台を作って欲しい

2019/02/12(火) 20:54:50.86

wasmって既存の資産を移植するためのものだよ？
最初から作れるのならJavaScriptを使えば良いわけだし

2019/02/12(火) 21:13:01.75

>>219
Blazorな

2019/02/12(火) 22:15:31.30

HTML5によってFlashなどのプラグインが死んでいったり
JavaScriptからカメラやマイクにアクセス出来るようになったりとそれなりに影響があった
WebAssemblyはそれらをさらに強化する

JavaScriptでは限度があった動画/音声データのリアルタイム解析なども可能になる
プラグインが死んだUnityも今はWebGL+WebAssemblyで動く

プラグインでバラバラ対処してたことが標準化されたって感じかね
劇的に変わる、と言うのはちょっと違う気もするが

2019/02/12(火) 22:37:43.88

HTML+CSS+javascriptでの開発って他の分野に比べると独特だから実は参入障壁高いんだよね。使いこなせないだけなのに技術そのものがショボいと言いだす。
だからwebフロントエンド以外の開発者がwebフロントエンドの開発したくなったときにいろんな手法を見つけて何とかしようとするんだけど、なれてくると別にHTML+CSS+javascriptでいいやってなる。
そんなイメージ。

2019/02/12(火) 22:51:06.28

メモリの扱いというかデータの受け渡しがだるいから、TypedArrayに対して高速に計算するだけの何かを導入してくれたほうがマシだった

2019/02/12(火) 23:16:46.90

wasmってiOSとAndroidに対応してる(する)の？

**デフォルトの名無しさん** (ｱﾒ MMcd-z8kj) · 2019/02/12(火) 23:20:52.48

>>226
これ。

2019/02/12(火) 23:49:27.70

>>227
もちろん
Web標準やで？

2019/02/13(水) 00:50:15.15

んなことよりpush通知実装しろ。iOS safariテメーのことだ。

2019/02/13(水) 00:55:06.05

>>225
JVM の代わりとなる仮想マシンと考えた場合、C++ で書けることは重要なんだ。
C++は型があるので、ミスをコンパイラが発見してくれる事が多いから。
例えば、JSだと関数の引数が多くても少なくてもエラーにならない場合がある
と思うけど、C++では敢えて分かっていてそうする場合以外は必ずエラーになる。
C++ では整数型を受け取るつもりの仮引数に浮動小数点型の実引数を渡すだけでも
エラーになる。ところが、JavaScript ではエラーにならない。

このようなことがあるので、JavaScirpt は大規模アプリをC/C++で組んだことの
有るプログラマからは嫌われている。特にアメリカで。

2019/02/13(水) 00:56:36.75

TypeScript使えばいいだけじゃね？

2019/02/13(水) 01:03:22.46

JavaScript だと、プロパティーには文字列と数値、Objectのどれでも入れられるので
単に書き間違えているだけなのに、エラーにならないので原因不明の不具合が直らずに
困る可能性がある。例えば、1,2,3 の 3つの数値を用いて、何か3種類を区別する
目的でプロパティー aaa を作ったとしよう。
aaa = 1;
aaa = 2;
aaa = 3;
と書くことをプログラマは想定している。ところが間違って、
aaa = "x";
と文字列型を入れてしまった場合、どこかで不具合が起きるだろうが、ソースが何10万行も有る
プログラムの場合、この間違えて書いてしまった行を探し出すのに苦労することになる。

こういう間違いが、C++ では、魔法のようにコンパイラが発見してくれる。だからC++は
安全で安定性が高いために人気がある。

2019/02/13(水) 01:06:00.32

テスト書くんだからすぐ見つかるでしょ？

2019/02/13(水) 01:06:08.06

>>232
その言語を多くの人は知らない。ずっと古くからC言語があり、とても人気があって、
その後継にC++があって今でも続いている。アメリカではC/C++経験をつんだ
プログラマが日本よりも沢山いるためか(?)、C/C++ で wasm が使えることで
game changer, pardigm shift などと喝采が起きているらしい。

2019/02/13(水) 01:06:59.54

>>234
なぜ、C/C++ が型を書いているかは、言語が古いからではなく、まさに
エラーチェックのためなんだよ。

2019/02/13(水) 01:12:36.84

typescriptはもう半数が使ってるくらいの感じでしょ

2019/02/13(水) 01:14:25.09

>>234
テストで結果が異常であると分かっても、どこに原因があるかが分からないことがある。
だから、細かく実験していく必要があり、それには時間がかかる。
型の間違いをコンパイラが見つけてくれるだけでもミスが判明することが
かなり多くあり、開発時間の節約・短縮に大幅に貢献することになる。

ミスったときには、型や引数の個数まで間違っている確率は意外と高いので、
それだけでも8割くらいの単純ミスは発見できてしまう。

2019/02/13(水) 01:15:17.87

>>237
Webプログラマから入った人にはそう思えるかもしれないが、昔からの
普通のデスクトップアプリを作ってきた人はそうではない。

2019/02/13(水) 01:16:31.85

C++ソース（型がある）→コンパイル（型情報に基づきエラー）→バイナリ（型はない）→ネイティブ実行

Type Script（型がある）→トランスパイル（型情報に基づきエラー）→JS（型はない）→ブラウザ実行

あんま変わらん。
wasmが出てきてから聞かなくなったけどJSはWebのアセンブラとは言い得て妙だったな。

2019/02/13(水) 01:17:39.67

>>235
> その言語を多くの人は知らない。

大丈夫。TypeScriptはJavaScript＋αだから
α（型）の部分を除けばJavaScriptそのもの

2019/02/13(水) 01:18:26.87

>>238
> テストで結果が異常であると分かっても、どこに原因があるかが分からないことがある。

十分にモジュール化されてればすぐに分かるよ

2019/02/13(水) 01:19:20.67

>>240
TypeScript という言語自体を今までの大部分のプログラマは知らない。
言語はなるべく1種類を学ぶだけの方が楽だから、C/C++ という事になる。

2019/02/13(水) 01:19:47.09

逆だな。javascriptをすごく理解してるWebプログラマのほうがjavascriptで粘ってて、
javascript理解しがたいと思ってる人らがtypescriptに救いを求めて移行した感じがある

2019/02/13(水) 01:22:34.41

>>241
そこまで頑くなに　C/C++ を拒絶する理由がない。
C/C++ を1つ覚えるだけで組み込みから何から何まで作れるようになり、
速度も現存する高級言語の中でTOPな上に、エラーも少なく、安全。
過去からの資産も多い。例えば、画像処理、AI、音声解析、文字認識、
3D描画、物理計算、何から何まで C/C++ は存在している。
敢えて後から出てきた言語を覚えるの無駄。

2019/02/13(水) 01:24:05.31

>>244
でも、ハイレベルなプログラマはそうは思ってないと思うよ。
実際に作った作品で勝負したら C/C++ の圧勝だと思う。
機能面でも速度面でも安定性も品質も。

2019/02/13(水) 01:25:16.64

>>243
js抜きにしてもtypescriptの型システムは良くできててC系文法の型システムとはこうあるべしといったお手本みたいだけどな。
c++の型システムは継ぎ足しキメラの失敗作だけど今さらどうしようもできねえしな…

2019/02/13(水) 01:36:11.82

>>247
仮に TypeScript に色々良いところがあったとしても、今迄から高い定評の有る
C/C++をまず、覚えてしまうほうがずっと将来性がある。
だから、人々はC/C++を覚えようとしてきたし、少なくともアメリカのプログラマ
はそうしてきた。いったんC/C++を習得すると、それだけでほとんどあらゆることが
簡単にできて、成果物の効率や速度もとても高く、エラーも少ないものが出来る。

その状態で敢えて、TypeScriptを覚えるのは非効率。だから、C/C++ が
ブラウザで動くのはすごく魅力的な話という事になる。

**デフォルトの名無しさん** (ｱﾒ MMcd-z8kj) · 2019/02/13(水) 01:37:20.24

S：もうかなり時間がたったしね、C++ が時間の無駄だということにはほとんどの人が気がついたとは思うけど、でも当初予想していたよりはずいぶん時間がかかったな。

I：具体的に何をどうやったのかな。

S：最初はほんの冗談のつもりでね、みんながあの本を真に受けるとは思ってもみなかったんだ。脳みそが半分でもあれば、オブジェクト指向プログラミングが非直感的で、非論理的で、非効率なことくらいはわかるよね。

I：え？

S：それに「コードの再利用性」ときたら…。どこかの会社がコードを再利用したなんて話を聞いたことがある？

I：いや、実はないんだけども、でも…。

2019/02/13(水) 01:40:07.00

>>245
> そこまで頑くなに　C/C++ を拒絶する理由がない。

C/C++は開発効率が悪いから。
ポインタを使うのに、std::auto_ptrを使わないといけない
そして世界が混沌としていて、ポインタという基本的なものでさえ
時代が変われば使い方がガラッと変わってしまう（皮肉）

2019/02/13(水) 01:41:57.50

>>250
>ポインタを使うのに、std::auto_ptrを使わないといけない

5ch/2ch の言うことを真に受けるとそうなるが、普通に、

BYTE *ptr;
TYPE *ptr;

で済む。昔から、C++ といえばこのスタイルで、auto_ptr 自体はずっと後発で、
C++ ではないといっても過言ではない。

2019/02/13(水) 01:42:17.61

>>248
> だから、C/C++ がブラウザで動くのはすごく魅力的な話という事になる。

既存のC/C++の資産をJavaScriptから使うのに便利だよね～

2019/02/13(水) 01:42:56.75

>>251
今どきそんなコード書かないよ？
既存のライブラリのソースコード見ろよ

2019/02/13(水) 01:43:28.32

>>250
>C/C++は開発効率が悪いから。

そんなことはない。メモリリークのことを気にしているなら、デストラクタの
中で解放するように1行書くだけで、ほとんどの場合はリークしないし、
危険なこともない。

2019/02/13(水) 01:44:23.63

>>253
ネットはおかしい情報が多い。
ちゃんと本を見たほうがいいよ。

2019/02/13(水) 01:45:15.56

>>254
デストラクタの中で解放する1行を書き忘れた場合、それでも動くから
どこかで不具合が起きるだろうが、ソースが何10万行も有る
プログラムの場合、この間違えて書いてしまった行を探し出すのに苦労することになる。

2019/02/13(水) 01:45:52.84

ミスったｗ

デストラクタの中で解放する1行を書き忘れた場合、それでも動くから
どこかで不具合が起きるだろうが、ソースが何10万行も有る
プログラムの場合、この間違えて書き忘れた行を探し出すのに苦労することになる。

2019/02/13(水) 01:46:57.29

>>253
std や auto_ptr を使うから難しく感じるんだよ。
何度も言うが、それは C++ ではない。これはマジ。
今の std:: 系のライブラリはSmalltalk の信者が作ったものらしい。
C++ の標準化委員会がおかしなことになっていて、もはや、本来のC++
ではなくなってきており、だから、C++が難しいと感じる人が増えている
気がする。

2019/02/13(水) 01:47:47.99

>>258
え？お前C++使いこなせないの？

2019/02/13(水) 01:48:20.38

>>257
クラスが 100種類の場合、デストラクタは 100 個しかない。
だから、ソースが数10万行あっても、100箇所を調べるだけで済むよ。

2019/02/13(水) 01:49:31.69

>>260
調べる箇所が100箇所でも
何を解放し忘れたかを確認するのは大変

2019/02/13(水) 01:49:40.75

>>259
日本だと auto_ptr みたいなのが C++ だと思ってる人がいるけど、
勘違いだよ。

2019/02/13(水) 01:51:15.37

stdなんちゃらを使わなかったら
バッファオーバーランで脆弱性になるし
それでも動くから
どこかで不具合が起きるだろうが、ソースが何10万行も有る
プログラムの場合、この間違えた行を探し出すのに苦労することになる。

2019/02/13(水) 01:51:20.27

>>261
だから新しい言語を次々に覚えて C/C++ だけは覚えないで過ごしてきたのかな、
あなたは？
数十の言語を覚えるより、C/C++ を1つ覚えるだけが良いと思うよ。徹底的に
それだけを学んだほうが良い。

2019/02/13(水) 01:51:48.19

>>262
勘違いとかそうでも良いわｗ
auto_ptrが使えて、実際にauto_ptrが使われるがC++だから

2019/02/13(水) 01:53:24.20

>>264
はいそうですね。C/C++は数十の言語を覚えるのと同じぐらい苦労しますもんね
いろんな言語の機能をキメラのように組み合わせた言語ですから
人によって書き方がぜんぜん違う

auto_ptrを使ってるだって！？これC＋＋じゃないよ！
って言う人がいるぐらいだから

だから開発効率が悪い

2019/02/13(水) 01:54:19.14

さもTypeScriptが競合であるかのように突っかかってきてるが全く的外れ。

TypeScriptのトランスパイルターゲットはJS。
競合はその他AltJS。
この中では既に天下取って安泰。

C++のコンパイルターゲットはWASM。
競合はRust、Kotlin、.NET、、、どんどん増えるぞｗ
がんばってな！ｗ

もちろんナマのJSはWeb界のグルー言語として残り続けるよ。
シェルスクリプトが性能を理由に消えないようにね。

2019/02/13(水) 01:54:36.76

>>263
そうならないように、C から C++ に進化してきたんだ。
そのために、コンストラクタ、デストラクタの概念が導入された。
それだけでも十分に安全で簡単に書ける。
逆に、std ライブラリは構造が理解しにくいので難しく感じるんだろう。
auto_ptr とか使おうとすると、C++ は一気に煩雑で嫌いになってしまうと思う。

だから、auto_ptr も std:: 系ライブ来も SmallTalk 信者が作ったものであって、
C++ の流儀とは全く異なる異質なもの。C++ で SmallTalk をやろうとするので
めちゃくちゃ複雑になってしまっている。

2019/02/13(水) 02:22:49.78

>>266
>はいそうですね。C/C++は数十の言語を覚えるのと同じぐらい苦労しますもんね
C++98 まで覚えれば大体C++の基本は習得できていて、それはそんなに大変
ではない。

・auto_ptr 系は、uniq, smart など沢山ありすぎるので、初心者には難しく、
　下手に使うと、生ポインタより危険かも知れない。これらはかなり後発のものなので、
　最初は覚える必要はない。
・std:: 系ライブラリは後から習得すればよい。