X

Vue vs React vs Angular Part.2

■ このスレッドは過去ログ倉庫に格納されています
0244デフォルトの名無しさん
垢版 |
2019/04/02(火) 14:11:33.61ID:ctuNgHvZ
>>241
なるほど
触ってみるかな
0246デフォルトの名無しさん
垢版 |
2019/04/02(火) 20:16:30.67ID:Vn7qUPir
生jsとか「this」とは。。とかなんでそんな哲学せにゃならんのかって気持ちになるわ。
0248デフォルトの名無しさん
垢版 |
2019/04/02(火) 20:37:17.25ID:YSuDMGX/
Reactもカメラ映像からcanvasに転写して画像処理とかやった時は結構メソッドに.bind(this)とか沢山書いたけどな
0249デフォルトの名無しさん
垢版 |
2019/04/03(水) 08:05:38.53ID:zOJIe3qU
>>232
どうだろ。jQueryの優れている点は後方互換性の高さだからな。

jQueryの古臭い構文に則って書きさえすれば、最新の環境でも10年前の粗大ゴｍ…レガシーな環境でも動くけど、
モダンブラウザでの利用を前提としたvueはレガシー環境ではjQueryの代替にはなりえないかと。

あとはjQueryの馬鹿にでも覚えらる簡単さも、vueには真似できない点じゃないかな。
１日あればそれなりに読めて書けるようになるjQueryと、じっくり数週間は座学を要するvueだと、
即戦力（という名の使い捨て）を確実に揃える際にはjQueryの方がより適切なんじゃないかな。
vueは下手すりゃ時間と労力だけ消費して、結局習得できませんでしたーとか平気でありえるわ。
0251デフォルトの名無しさん
垢版 |
2019/04/03(水) 10:08:11.29ID:GcirtrDg
フレームワーク選びのポイントは
どんな規模を作るのか、最終的にどういった
開発環境を、使えるように成りたいかによるだろう。

Vueはmvvmのテンプレートエンジンが
他よりディープに作り込まれてて、コンポーネントが他より再利用しやすいのが特長。

だけどツールとして使えるように
なるには、かなり熟達してないといけない。。
0253デフォルトの名無しさん
垢版 |
2019/04/03(水) 14:36:12.42ID:fYTnXBwQ
>>249
かと言っていつまでもjQueryは辛すぎるだろう。保守に必要なのはしょうがないが、インタラクティブなページだけvueに置き換えてくだけでも随分楽になるんだがなあ。フォーム周りとか特に。
0254デフォルトの名無しさん
垢版 |
2019/04/03(水) 14:56:25.21ID:pzZNq5v4
jQueryそこまで互換維持してる？結構非互換変更をやってるような気が
propとattrが分離した時なんて大混乱だったし
0255デフォルトの名無しさん
垢版 |
2019/04/03(水) 15:15:33.14ID:0ih4AaLe
> propとattrが分離した時なんて大混乱だったし
それは2011年の話。それが最初で最後の大きな変更
0256デフォルトの名無しさん
垢版 |
2019/04/03(水) 16:14:03.74ID:/cw++oNj
サーバー側フレームワークが足してくるやつとサードパーティースクリプトとクライアント側フレームワークが使ってるやつで３種のバージョンでグチャグチャになってエラってるのに当たった
もうあんなのは嫌だ
0259デフォルトの名無しさん
垢版 |
2019/04/03(水) 21:06:42.61ID:fYTnXBwQ
サーバのフレームワークが吐くscriptだろう。ちょっと違うがカスタムしたwordpressは本当カオスだわ。もう二度とメンテしたくない。今でも元気に動いてるのが不思議。
0262デフォルトの名無しさん
垢版 |
2019/04/04(木) 11:09:20.60ID:I0seNCf/
>>259
function.phpでフックするかプラグインで実装するか、直書きするか、WordPressの標準機能でやるかの4択だから見る箇所多くてな…
0263デフォルトの名無しさん
垢版 |
2019/04/04(木) 15:52:23.56ID:BJ8NtGwy
このくらいデザイナーでもできるのにフロントエンジニアができないってどういうことだよ？
0264デフォルトの名無しさん
垢版 |
2019/04/04(木) 19:01:35.04ID:AP8fvSfz
研修二日、実務経験二年のペテンシ・エンジニアリング・サービス・ソリューション♪
0265デフォルトの名無しさん
垢版 |
2019/04/06(土) 00:11:30.05ID:nqPdyQw0
>>228
いいや、データの双方向的な流れがバグの温床になるって話だった
で、 reactはflux, angularはデータバスにrxjs
angular.jsのアーキテクトだったかがvue.jsのメンテナーへ
小規模なアプリはvue.js,大規模ならangularへ流れても良いと思うんだがなー
angular2が出た初期の頃みたいにボイラープレートを動かすだけに何日も掛かるような糞ではなくなったんだし
0266デフォルトの名無しさん
垢版 |
2019/04/06(土) 00:14:37.44ID:nqPdyQw0
jqueryの作者はreactへ流れてただろ
jquery的な用途で使われるのはvue.jsの方だとは思うが
reactは設定のための学習コストが高すぎて、アホなweb屋たちが使いこなせない
0267デフォルトの名無しさん
垢版 |
2019/04/06(土) 01:16:21.80ID:/WRt9p3o
reactの学習コストが高いっていうけど、
安定したもの作ろうと思ったら他のフレームワークやるとしても結局同じくらい学習コストかかると思うぞ。
0268デフォルトの名無しさん
垢版 |
2019/04/06(土) 08:49:03.93ID:aPuA2bpg
>>266
もう3年も前の話だな。それからのReactの状況はいぜんと何も変わらず
いつになったら普及するのかね？

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

ちょいちょいで終わるようなものを作ろうとしたら大変なんだよ
世間で必要とされるもののほとんどは、ちょいちょいで終わるようなものばかり
0269デフォルトの名無しさん
垢版 |
2019/04/06(土) 09:56:04.81ID:rzMI9gMb
>>265
実際そういう流れになってると思うよ。ただバインディングの仕組み自体がトリッキーだから、フレームワーク関係無く不安定さが付き纏うのはしょうがない。
要求に対してweb標準仕様が貧弱すぎるから、いつまで経ってもどこか不安定なのはwebの宿命だよ。
0270デフォルトの名無しさん
垢版 |
2019/04/06(土) 10:46:57.59ID:nqPdyQw0
本質的にフロントエンド要らないと思うんだよね
デバックにコストが掛かり過ぎて、コストを掛けてまで誰が欲しいのかって話で
片手間のテンプレート的に扱えたangular.jsからvue.jsへ流れると思うけど
frontendの専門部署でreactでなくてvue.jsを使う勢は単に頭が沸いてるだけ
0272デフォルトの名無しさん
垢版 |
2019/04/06(土) 16:11:51.40ID:/WRt9p3o
>>268
ちょいちょいでいいならexcelにボタンでもつけとったらええやんけとか思う。
まあ実際はバカ経営者に見栄えいいのを見せる目的があるから
クソみたいなフレームアピールするんだろうけどな。
心底くだらねーと思うわ。
0273デフォルトの名無しさん
垢版 |
2019/04/06(土) 16:40:40.59ID:uCKV04As
Reactごとき難しいってお前らエセプログラマーだろ
世の中のプログラミングの中では圧倒的に簡単なほうなんだが
0276デフォルトの名無しさん
垢版 |
2019/04/06(土) 18:59:25.24ID:jpD7ojAE
ライセンスの修正じゃないかな。
その前に急落したのもライセンスが問題にされ始めたころじゃないかと思う。
0279デフォルトの名無しさん
垢版 |
2019/04/06(土) 22:41:07.31ID:qQhidKgX
世界中の華橋・華人を動員した結果GitHubスター数はReactを抜いたVueとデッドヒートしてるじゃんｗ
誇っていいだろ
0282デフォルトの名無しさん
垢版 |
2019/04/07(日) 00:33:24.05ID:eWoMr/0V
ははは。そんなことありえない。
ウェブアプリなんて一部でしか作られてないよ
殆どはウェブサイト。だからjQueryが使われ続けている。
0283デフォルトの名無しさん
垢版 |
2019/04/07(日) 10:22:09.78ID:LeEYr30b
>>273
React特有のpropが変わると再描画という形がキツかった
普通に部分的な動きをさせたいだけで全部その形にしなきゃいけないのが不自然
不要な部分の更新まで行われてしまったり何回も同じ更新が走ってまくってしまって原因調べるのがきつい
0285デフォルトの名無しさん
垢版 |
2019/04/07(日) 15:05:55.66ID:IhfdKLBe
何らかのアンチパターンやってるケースでしょ
設計思想とか、中の仕組みを想像出来ないとやらかしてしまうのは分かる
うちのメンバーでそういうのあった
0286デフォルトの名無しさん
垢版 |
2019/04/07(日) 15:40:34.34ID:GYBhj6UR
逆にreactのコンポーネントを使わずにreduxで更新をやるって感じで
入門するのはどうなんだろうか？こっちのがわかりやすいんじゃなかろうか。
0287デフォルトの名無しさん
垢版 |
2019/04/07(日) 17:22:26.91ID:GtbVpKg+
react+reduxは考え方としてはいいんだが、素のreactではコンポーネントのstoreに
閉じていたようなデータまでstore内に混在するのがなんとなく気持ち悪い。
MとVMを分離できたらよかったんだがなぁ。
0290デフォルトの名無しさん
垢版 |
2019/04/07(日) 18:45:56.70ID:PFYq1oCr
javascript歴浅めのものです。
この手のフレームワークのデータバインディンクの仕組みって、buildした後のjavascript的にはどう実現されてるの？
{{data}}とかでマークアップされた箇所にイベントハンドラ付きのjavascriptが挿入されてる感じなんかな？
0291デフォルトの名無しさん
垢版 |
2019/04/07(日) 19:40:14.89ID:P5z2JTjG
>>290
簡単な例ならtwo way binding javascriptでググると沢山出てくると思う。ただこれに仮想domやコンポーネントが絡むからずっと複雑。深追できないしするべきじゃない。
0292デフォルトの名無しさん
垢版 |
2019/04/07(日) 20:09:39.22ID:/0jtn/DN
two way bindingねえ

例えばvar helloのバインディングならglobal(window)にsetter/getterのhello()を追加して、
helloのsetterが呼ばれて値が変わったら<input>.valueにもそれを代入し、
<input>要素にはイベントリスナーで値が変わったときにバインディング変数(hello)に同じ値をセットしてるのかな
0295デフォルトの名無しさん
垢版 |
2019/04/07(日) 20:22:59.94ID:GtbVpKg+
一般のGUIでも常套手段だが、値が変わらなかったらそれ以上伝播しないってことでいいんじゃね。
0296デフォルトの名無しさん
垢版 |
2019/04/07(日) 20:41:31.99ID:pXFOXfTh
>>292
>>295
なるほど、やっぱそれくらいのコード書かないとできないのですね。
となるとリッチなwebアプリケーション作るとなると、どれかしらのフレームワーク使いたくなりますな。
0297デフォルトの名無しさん
垢版 |
2019/04/07(日) 20:46:11.81ID:pXFOXfTh
徐々にだとしても、今後webブラウザベースのアプリが増えるはずと思っていろいろ勉強中なんです。
0298デフォルトの名無しさん
垢版 |
2019/04/07(日) 21:25:39.30ID:UcdrpnVc
>>283
そこ海外フォーラムとかで議論されてるから見ればいい

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

>>286
さすがに全部Reduxにする必要はない
0299デフォルトの名無しさん
垢版 |
2019/04/07(日) 21:46:10.88ID:o4S4akf8
いじめはどこの町にもあるが島本町は特に酷い
「大阪府三島郡島本町のいじめはいじめられた本人が悪い 」なんて
公言する町は他に無い
0300デフォルトの名無しさん
垢版 |
2019/04/07(日) 23:01:30.03ID:IUYTEtUp
>>297
アプリというか、アプリの様に動作するwebサイトだね。storeに登録しない。個人的に最難関はDBのオフライン対応+同期だと思う。
firestoreもあるがフレームワーク側で対応して欲しい。魔境なので難しいとは思うが。。
0301デフォルトの名無しさん
垢版 |
2019/04/07(日) 23:38:09.79ID:pXFOXfTh
>>300
個人的にはオフラインDBは諦めるのがスジがいいと思うけどな。ネットに繋がってて当たり前の時代じゃないですか。
0302デフォルトの名無しさん
垢版 |
2019/04/08(月) 01:33:01.06ID:3hZl3Wdo
>>300
> アプリというか、アプリの様に動作するwebサイトだね。

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

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


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

ウェブサイトからウェブアプリに変更したいという要求は
本質的に違うものへの変更になるから生まれてこないんだよ。
PCアプリ・スマホアプリから、ウェブアプリの場合は、
本質的に同じもので動くプラットフォームが拡大されるからそういう要求はある。
0305デフォルトの名無しさん
垢版 |
2019/04/08(月) 01:56:14.66ID:rY5IQNQb
>>302はいったい何を否定しようとしたんだ？webサイトという言葉の使い方がおかしいということなのか？
0306デフォルトの名無しさん
垢版 |
2019/04/08(月) 02:16:44.05ID:3hZl3Wdo
>>303
> そうか？office365とかgoogle documentとか成功してるじゃん。

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

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

アプリのように動作するウェブサイトという
変なインターフェースは誰も求めてないという話。
例えるならば、ジョイスティックで操作し、美麗な3Dゲームのような
新聞ビューワーみたいなもの。誰もそんなので新聞を読みたいなんて思わんだろ？
0310デフォルトの名無しさん
垢版 |
2019/04/08(月) 11:34:53.34ID:du1Ta1so
>>301
そうなんだよね。オフライン対応って無理がありすぎるんだよね。
以前firebaseのrealtime database使ったが、オフラインからの同期処理に制限が多すぎて厳しい。更新が時系列を保証せず最終更新分だけ同期するとか、かなりクセがある。
WebworkerとindexedDBで効率よくキャッシュする方が当面は幸せになれそう。
0313デフォルトの名無しさん
垢版 |
2019/04/08(月) 14:49:09.97ID:tfxqur1k
excelで作ったドキュメントをなるべくそのままの形でhtml化する方法は無いでしょうか？
excelでhtml形式で保存すると裏側が汚いです
Gatsbyのプラグインにそれらしきモノがあったので試してみたら、色もセル結合もフォントサイズも全部落ちてしまいました

まぁ自分で自作すればいいんでしょうが、気が遠くなるくらいたくさん作り込まねばならず、皆さんはexcelドキュメントをそのままWeb化したいとか要望された事はありませんか？
0314デフォルトの名無しさん
垢版 |
2019/04/08(月) 15:43:06.23ID:8bidG0zI
>>311
いやだから>>305でwebサイトという言葉の使い方がおかしいということなの？って聞いたのによくわからん回答されたから混乱してるんだが…
で、結局webサイトという言葉の使い方がおかしいってことなのね。
0315デフォルトの名無しさん
垢版 |
2019/04/08(月) 15:49:10.83ID:8bidG0zI
要は、office365のようなものをwebサイトと呼ぼうがwebアプリと呼ぼうが話の本筋には何の影響もないのに、>>302の長文で謎の語りが入ったから話がグチャッとなっちゃったって事実に気づいて欲しい。
0317デフォルトの名無しさん
垢版 |
2019/04/08(月) 20:15:16.81ID:itCfkyzI
オフラインデータはクッキーをいじり回すことしか出来ないのね
せめて画像を確実にローカルに保存できればオフラインでも動かせる
アプリが作れるだろうに
0319デフォルトの名無しさん
垢版 |
2019/04/09(火) 07:41:13.08ID:3VmrXHE6
reactは覚える事は少ないけども設計力が必要
宣言型プログラミングと同じで高い論理性が要求されるから苦手な人は多いかもね
0320デフォルトの名無しさん
垢版 |
2019/04/09(火) 23:06:06.17ID:RLI3ERn/
悲しいのはAngularの勢いが無くなり、横ばいのAngularJSの方が残りそうなところ
もうAngularはGoogle Graveyard入りだろ。どうすんだよAngularで作ってる新規プロジェクト
0322デフォルトの名無しさん
垢版 |
2019/04/10(水) 00:52:39.92ID:UQDjmvEN
angular使うくらいならvueの方がええわなぁ
reactは論理性高いから日本人には不向きやろなぁ
0323デフォルトの名無しさん
垢版 |
2019/04/10(水) 01:08:10.98ID:92CfBwCq
ググってみたけどreactはhtml側ではあまり小細工しない感じだねえ
論理的というのがいまいち分からないけど
0324デフォルトの名無しさん
垢版 |
2019/04/10(水) 02:32:35.33ID:RXzVAjqo
個人的にはbackbonejsが好きなんだけどなあ。自分で自由に作れるし
有名どころ使ってるのに、扱いが微妙
0327デフォルトの名無しさん
垢版 |
2019/04/10(水) 12:23:01.13ID:CbhRNE87
>>326
進化させるのは自分の設計、コーディング次第なのがbackbonejsの思想だけど
フルスタックじゃないから足りない部分は自分たちで補えばいいし
そもそもbackbonejsは、つい最近更新されたばかりで死んでないけどな

昨今のフレームワークは全部入ってるから良いと思ってる
Railsやcakeみたいに作るのが簡単ならわかるけど、複雑化したら折角のフルスタックフレームワークがゴミになるだけ
0330デフォルトの名無しさん
垢版 |
2019/04/10(水) 13:50:22.69ID:sSiaigIF
>>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年じゃないか？
0331デフォルトの名無しさん
垢版 |
2019/04/10(水) 16:27:07.49ID:p6PdlM/J
>>328
ひと言で説明すりゃいいのにくどくどとしつこい内容だな
0333デフォルトの名無しさん
垢版 |
2019/04/11(木) 00:19:20.16ID:SMdbPkuM
フレームワークは、先に全体の構造が決まっていて、そこにはめ込む部品を作る。
全体の構造が決まっているから、プロ向き

ライブラリは必要な都度、組み込んで、部分から先に作っていくから、
全体の構造が最後まで決まらないので、スパゲッティ・泥団子になりやすいので危険！
0335デフォルトの名無しさん
垢版 |
2019/04/11(木) 00:26:50.15ID:XplD4nHz
>>333
フレームワークに任せとけば安心って思考停止して、結局何と何が依存してるか
わからなくなってそのフレームに閉じ込められるパターン。
0337333
垢版 |
2019/04/11(木) 02:29:16.00ID:SMdbPkuM
全体の構造を、各人が決めたら、ダメ！
各人によって、構造に違いがあるから、他人と思いを共有できない

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

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

多くのフレームワークも、Rails を基本としている
0339デフォルトの名無しさん
垢版 |
2019/04/11(木) 03:23:58.52ID:GHeRPenA
>>337
> Aが作った構造を、Bが気に入らないなど、トラブルになる
> だから、Rails などの既成のフレームワークを使う。

だからその「既成のフレームワーク」を作ったのAで
それを使うBが気に入らないってトラブルになってるんだろ？
0341デフォルトの名無しさん
垢版 |
2019/04/11(木) 08:16:15.03ID:VwFYHZX6
>>335
規約に則って書きさえすれば、チームのスキル差を減らして、一定の品質が担保できるのがフレームワークのメリットじゃない？

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

もし今使っているフレームワークに不満あるなら、そもそも最初のフレームワーク選定時に意見を言うべきだし、
発言権のない立場なら大人しく従うか、転職なりしてプロジェクトから抜けるしかないんじゃないかな。
0342デフォルトの名無しさん
垢版 |
2019/04/11(木) 08:17:20.21ID:w+9Uk8Mc
思いは共有できなくても、実績があるフレームワークに従いましょう、ってことで平和に収まるって話だろ。
この効果は間違いなくある。
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況