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/03/10(日) 09:49:18.69

>>11
React、VueはJavaScriptでHTMLを作るものだから。
AngularはHTMLをベースにそこに特殊な属性をつける。

**デフォルトの名無しさん** · 2019/03/10(日) 09:50:04.54

>>1
乙！

>>2-5
死ね

**デフォルトの名無しさん** · 2019/03/10(日) 09:55:40.09

1から2への移行、というか再構築の苦労話見るとなあ。個人的に習得すべきかずっと迷ってる。

**デフォルトの名無しさん** · 2019/03/10(日) 09:56:45.26

>>11
今って言うか前スレで殆ど話題に上がらなかったなと

**デフォルトの名無しさん** · 2019/03/10(日) 10:08:10.61

>>12
何でAngularってあまり使われないんだろうな。

自由に構成を変えられない分、チームとして協業した時に構成を統一出来るし、
ベースとなるTypeScriptで型宣言出来るから変数に違う型をぶち込もうとしてたらIDEが教えてくれるからバグも少なく書ける。

これだけ大規模開発と堅牢なコーディングに向いてて、何故どこの企業もAngularで開発しようってならないんだろ。

一度Angularで開発始めてしまうと後戻りできなくなるからとか、
そもそもHTML、CSS、Javasceiptしか出来ない人間にAngularは荷が重いからとか？

**デフォルトの名無しさん** · 2019/03/10(日) 10:57:03.30

あとバージョン更新が速すぎる
7で安定すんのかな

**デフォルトの名無しさん** · 2019/03/10(日) 10:59:39.20

>>17
用途が違うから。

Reactを使ってるのはウェブサイトじゃなくて
ウェブアプリを作ってる。
ウェブサイトはReactでは作りづらい

ウェブサイトはAngularが適しているが、
その程度の用途ならjQueryで十分

**デフォルトの名無しさん** · 2019/03/10(日) 11:18:18.33

>>18
もう8のBetaが来てる

**デフォルトの名無しさん** · 2019/03/10(日) 11:20:50.23

Angular使ってる部署は使ってるな
自分のところで使わないのは、
・大胆に仕様が変わる
・その割りに飽きてポイ捨てするgoogleの体質
で使ってないな
googleの信用問題な気がw

**デフォルトの名無しさん** · 2019/03/10(日) 11:35:33.25

Reactもライフサイクルメソッドとか大幅に廃止になってたりするけどね

**デフォルトの名無しさん** · 2019/03/10(日) 11:46:45.99

まだまだ先とはいえ、GoogleはいずれAngularを捨てて
Flutter for Webを推していくようになると思うぞ

**デフォルトの名無しさん** · 2019/03/10(日) 11:49:48.39

それはReactも同じだよ。
Web Componentsがすべてを置き換える。

まあReactと互換性がないReact Nativeは別だけどな。
React Nativeはアプリ用であってウェブ用ではないし

**デフォルトの名無しさん** · 2019/03/10(日) 11:56:52.21

>>23
AngularDartってのもあるからな

**デフォルトの名無しさん** · 2019/03/10(日) 12:02:33.55

>>17
webの構成要素html、js、cssはとても壊れやすく脆い。altcss、altJSも結局はラップに過ぎん。そして動作するブラウザもどこかで不安定。

だからwebはライブラリやフレームワークが優秀でも堅牢とは言い切れない、どこか不安定な感じが拭えないんだよ。

その上流れの早い業界だから、速攻習得できて早く捨てられる。次に備える。そういうスタイルがwebに合ってる気がしてる。angularには腰が重くなる。

**デフォルトの名無しさん** · 2019/03/10(日) 12:19:44.77

>>26
html、js、cssは登場してから大きく変わることはなく安定してると思うけど？
壊れやすいのはその周辺技術。同じことを違うやり方をしては消えていく
生HTML、生JS、生CSSに近いものほど長く生きている

**デフォルトの名無しさん** · 2019/03/10(日) 13:50:12.38

生たって小規模ならともかくjsの長ったらしいのなんかメンテできないだろ
ちゃんとしたlintツールとかあってチームとかでメンテできるわけで

**デフォルトの名無しさん** · 2019/03/10(日) 14:08:14.61

lintツール使ってもjs自体はjsそのものだろ

生じゃないjsというのは、jsをjsではないものにするってこと
例えばCoffeeScriptとかね。

HTMLで言えば、HAMLとかあったがあれも死んだ
HTMLではないからだ。XHTMLもほぼ死んだ状態

jsもAltJSは殆ど死んだ。残っているのはTypeScriptというjs+αという
互換性があるものだけ。

CSSも生き残ってるのは、CSSと高い互換性があるSASSぐらい

標準の構成要素は消えないし、標準から離れれば離れるほど死滅するのが早くなる
ウェブのフレームワークも標準のDOMとは違うやり方をするので、すぐ消えるよ

**デフォルトの名無しさん** · 2019/03/10(日) 14:12:35.25

CoffeeScriptにしてもSassにしてもRails由来のものはあんま流行らなかったな
ScssはSassの一形式みたいに言われてるが本来のSass形式が受け入れられなかった結果だしな

**デフォルトの名無しさん** · 2019/03/10(日) 14:14:23.21

>>30
俺が言ってるSassっていうのはプロジェクトの名前で
構文自体はScssだからね。

**デフォルトの名無しさん** · 2019/03/10(日) 14:48:02.33

インデントスタイルのほうが絶対いじりやすいのに

**デフォルトの名無しさん** · 2019/03/10(日) 15:00:02.28

そんなものよりも互換性のほうが重要だし
テキストエディタの機能で小さな差は吸収される

**デフォルトの名無しさん** · 2019/03/10(日) 15:31:18.74

>>29
AltJsてことね、失礼
TypeScriptはやっぱ便利だね
Vueでもやりたいんだが周りがjsでやろうとするんだよな

**デフォルトの名無しさん** · 2019/03/10(日) 15:34:45.50

>>25
普通に考えれば
AngularはDartでやるべきなんだろうけど

**デフォルトの名無しさん** · 2019/03/10(日) 15:34:57.99

>>32
逆にインデント入れたらダメってルールはないし

**デフォルトの名無しさん** · 2019/03/10(日) 16:02:25.93

>>27
すまん言い方が大雑把だった。エンジンがどうこうじゃなく、最近は減っただけでブラウザ依存は無くなってないし、生cssやdomは貧弱すぎる。

本来の用途ではないのを時代の要求に合わせて無理やり実現してる感が凄い。それをフレームワークやIDEが必死の努力で隠してくれてる。

それは凄く有難いし新技術はワクワクするしvue reactは楽しい。でも独自記法が象徴する様に「コレは一時的なものです。今はこう書きます」というキナ臭さ凄い。ガッツリコミットできない。

**デフォルトの名無しさん** · 2019/03/10(日) 16:28:15.01

でも、なんかこのスレ見てたらangular勉強する気が湧いてきたわ。しばらく独学して判断するよ。

**デフォルトの名無しさん** · 2019/03/10(日) 16:31:35.17

>>38
これからGoogleMapもPWAになるって聞くしな

**デフォルトの名無しさん** · 2019/03/10(日) 20:26:48.77

Vue.jsは仕事で使ったけどイマイチな感じがした。
ちょっと入院するからreact native勉強するつもり。
このままサーバサイドエンジニアに追い込まれて終わらんよ

**デフォルトの名無しさん** · 2019/03/10(日) 22:13:45.27

>>40
どんなところがイマイチ？

**デフォルトの名無しさん** · 2019/03/10(日) 22:13:50.36

>>40
そうだね、pwaは必須になると思う。よりネイティブアプリに近づく流れは避けようがない。
あとスレタイにある様に、現時点でjsフレームワークは3種類に絞られたと言って良いと思う。松茸梅じゃないけど、いい感じに出揃った。腰を据えて松のangular学んで良い時期なのかなと。

**デフォルトの名無しさん** · 2019/03/10(日) 22:15:05.06

ごめん安価間違えた。>>39へのレスでした。

**デフォルトの名無しさん** · 2019/03/10(日) 22:19:55.62

Angularに詳しい人に質問。

個別のコンポーネントで管理されてる状態を表す変数（例えばユーザーが入力した文字情報や、サーバーから取得したJSONデータ）を
コンポーネント間で共有したい場合、どこで保管するのが適切？

最初は単一のserviceに全ページの状態を示す変数をぶち込んで、単一のservice↔各コンポーネント間でデータのやり取りやデータバインディングやってたんだけど、
ページ数が増えるに連れて変数の管理がし辛くなっていったわ。

あと、データがserviceなんかにあるもんだから、データバインディングする際にも各コンポーネントのhtmlにクソ長い名前付けなきゃならなくてかったるい。

実現したいポイントは、

①コンポーネント間のデータ共有
②どのデータがどのコンポーネントの状態を示すのかを明確にする
③データバインディングのコードの書きやすさ

なんだけど、なんかアイディアない？

**デフォルトの名無しさん** · 2019/03/10(日) 22:23:07.40

PWAの実行環境としてウェブブラウザは最適なんだろうか。

**デフォルトの名無しさん** · 2019/03/10(日) 22:29:16.09

前スレでAureliaってのが出てたから試してみたけど
cliでプロジェクト作っても初期状態でnpm startすら碌にできんとか
流石にスレタイの3フレームワークとは同列じゃないなって思った

**デフォルトの名無しさん** · 2019/03/10(日) 22:32:21.87

>>45
PWA=実行環境だよ

ブラウザをベースとしてOSがアプリのように
見える仕組みを追加する拡張されたブラウザ機能のこと

素のウェブブラウザが最適ではないからこそ
OSがその機能を追加してる

**デフォルトの名無しさん** · 2019/03/10(日) 22:41:57.30

>>44
すまん横槍なんだけどangularだけの問題じゃないので。
ネイティブアプリでもwebでもRxを使うのがトレンドだと思うんだが、それではダメ？

**デフォルトの名無しさん** · 2019/03/10(日) 22:57:26.28

>>48
えぇ…駄目って事は無いと思うけど、RxJSで一度取得した情報をページ遷移ごとに再度取得したり、ユーザーが仮で入力した入力情報を一々RxJSで送るって、面倒臭過ぎない？

俺は一度取得したデータや入力したデータはコンポーネント外のどこかに保管して、
データの更新がある時に再利用する、という方法が良いと思うけど。処理的にも通信量的にも。

もちろん、作るものによってデータの扱いは異なるだろうから、俺の考えが絶対に正しいとは思わないけど。

**デフォルトの名無しさん** · 2019/03/11(月) 00:23:57.94

>>49
それは結構範囲が広い問題だねえ。設計思想にも関わってきそうな。ただデータの再利用部分なんだけど、単に通信量を減らすキャッシュ的なもの？なら簡単だろうけど、なにやら複雑そうだね。

**デフォルトの名無しさん** · 2019/03/11(月) 00:26:48.86

>>41
描画し終わった後に呼ぶメソッドはアレとか、前だとコレとかとっつきにくい。
まあriotよりはマシだが

**デフォルトの名無しさん** · 2019/03/11(月) 00:36:16.62

>>44
それがfluxなんじゃないの？

**デフォルトの名無しさん** · 2019/03/11(月) 10:44:37.63

>>49
ブラウザのデータ永続化も絡んでる？

**デフォルトの名無しさん** · 2019/03/12(火) 00:33:48.58

>>53
いやそこまでは。精々ユーザーが使っている間、具体的にはブラウザタブ開いている間くらいで考えてる。

JSONにしてsession storageにぶち込もうかとも思ったけど、データバインディングもしたいから
今んとこはserviceで管理するのが一番無難かなぁと。

**デフォルトの名無しさん** · 2019/03/12(火) 02:23:44.41

Model(Application/Data) <----> View Model (JQuery/AnimeJS/DOM) <----> View(HTML/CSS)

**デフォルトの名無しさん** · 2019/03/12(火) 09:34:20.66

>>54
5chじゃ詳しく話せないと思うんだけど少し範囲が広すぎるから、なにが具体例があると分かりやすい。今までの内容から、storeやrxやstorage,indexedDBでも解決に至らない問題って事だよね。

>データバインディングする際にも各コンポーネントのhtmlにクソ長い名前付けなきゃならなくてかったるい。

ここが核心で他は不便ではない、という事なら解決方法は全然違ってくると思うし。

**デフォルトの名無しさん** · 2019/03/12(火) 10:16:12.94

>>51
俺の場合はReactNativeを仕事で使って、同じようなとっつきにくさを感じたから、今はVueやってる。たぶん大差無いんじゃないかな。

**デフォルトの名無しさん** · 2019/03/12(火) 12:10:25.68

vueのtsサポートってどんな感じ？
普通に使える？

**デフォルトの名無しさん** · 2019/03/12(火) 12:47:29.02

>>58
俺は普通に使ってる。特に問題ないよ。

**デフォルトの名無しさん** · 2019/03/12(火) 22:43:17.38

Fluxってsetterで値をセットし、getterで値を取得しましょうってことでいいの？

それともsetterの代わりに、メソッドで連想配列に値を入れて
getterは使わず、内部構造の連想配列をそのまま取得ってこと？

**デフォルトの名無しさん** · 2019/03/13(水) 00:03:24.50

>>56
「解決に至らない問題」というとちょっと違ってて、やりたい事は出来るんだけど、「もう少しシンプルで書きやすく、分かりやすい書き方はないか」と悩んでる。
今やってる事の目的と具体例を出すと、次の様な感じ。
【やりたい事とアプローチ】
コンポーネント間で画面遷移しても画面の状態が保持されるようにしたい。
そこでコンポーネントではなく、サービスにサイトの状態を保持させる。
【具体例】
『component』
・A.component.ts / html
・B.component.ts / html
『service』
・test.service.ts
　public val: any = null; // Aの状態を保持するメンバー変数。
　
１）TestServiceをA、Bそれぞれのコンストラクタで読み込む。
２）Aのcomponent.tsでデータを取得し、serviceのvalに格納。
this.testService.val = result; // 中身は { res : "OK" }

３）Aのcomponent.html上でデータをバインディングで表示。
{{this.testService.val.res}}

４）AからBに画面遷移。
５）component.tsで、取得したデータをオブジェクトの一部に格納。
var result = { res : this.testService.val.res, num : 123 }

結論としては↑のやり方でAで取得したデータをBで参照する事には成功したが、次の問題が出て来た。
・TestServiceにもっと多くの変数があると、どの変数がどのページの状態を示すかが分からなくなる。
・VS Code だとhtml編集時にtsの補完が効かず、htmlのバインディングの構文
{{this.TestService.val.res}}
を書くのが面倒。

何かズラズラと書き上げてて、だんだん設計がよろしく無い気がしてきたわ。いっぺん設計を考え直してみるわ。

**デフォルトの名無しさん** · 2019/03/13(水) 01:32:34.62

>>61
ちょっと俺もangular勉強中だから近日中に答えるわ。
ただ気になるのが4)のA>Bに遷移した後、リロードが発生したら表示できなくなる気がするんだけど。。urlが同じならAに戻るだけだから問題ないと言えば無い。のかな？
または、A>Bへの遷移後Aは破棄されず再び更新が発生した場合サービス側で注意深く処理しないとせっかくのBのバインドが外れてしまう。
ごめん実装と例は違うんだろうけど、パッと見て気になったところ。

**デフォルトの名無しさん** · 2019/03/13(水) 06:45:39.95

それ
リロードが発生するとデータが消えるのは論外なのでリロードしても大丈夫なようにしないといけない

**デフォルトの名無しさん** · 2019/03/13(水) 07:00:36.64

名前が長くなるのはいやがらない方がいいと思うけどな。シンプルな名前にすると背後に潜む仕組みがわかりにくくなって逆に不安になったりしない？

**デフォルトの名無しさん** · 2019/03/13(水) 07:03:11.66

{{this.TestService.val.res}}

こう書いてあると、他の人が見たときにわかりやすくてよい名前だと思う。

**デフォルトの名無しさん** · 2019/03/13(水) 08:57:38.95

ReduxならlocalStrageのミドルウェアがあったな

**デフォルトの名無しさん** · 2019/03/13(水) 09:40:05.85

現段階での改善案なんだけど、
1:Aのロード部分はサービスへ。
2:AB共にサービスからrx経由で取得。
が基本だと思う。要はコンポーネント内で直接ロードしない。この修正だけで随分見通し良くなると思うよ。
あとはサービス側でキャッシュなり永続化なりお好きな様に。

**デフォルトの名無しさん** · 2019/03/13(水) 11:07:16.09

頑張らなくっちゃ～　頑張らなくっちゃ～
うんちもプリップリッ　おしっこもジャージャー
頑張らなくっちゃ～　頑張らなくっちゃ～ 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b)

**デフォルトの名無しさん** · 2019/03/13(水) 11:20:41.84

・サービスの根幹に関わる部分はflux概念で管理
・その部分はどのページでリロードしても破綻しないように管理する
・見た目とかリロードで変更されても問題ないstateはそれぞれのコンポーネントで管理

こんな感じかね

**デフォルトの名無しさん** · 2019/03/13(水) 12:36:13.64

リロードしてもステート変わらないの？
何のためにリロードするんだろうな。
そんな糞サイト二度と行かないわ

**デフォルトの名無しさん** · 2019/03/13(水) 12:56:53.92

何のためにリロードするのかってユーザーが勝手にリロードするからだろ
糞サイトだろうが優良サイトだろうがリロードするやつはリロードする
そんなことすら理解できないバカを自己紹介すんな

**デフォルトの名無しさん** · 2019/03/13(水) 13:27:25.76

何を期待してリロードするのかということなんだが…
リロードしてもリロード前とステートまったく変わらないの？
そんな糞サイト二度と行かないわ

**デフォルトの名無しさん** · 2019/03/13(水) 14:00:09.36

>>72
お前がバカだから理解できないのはわかった

**デフォルトの名無しさん** · 2019/03/13(水) 14:51:42.99

馬鹿と馬鹿が言い争っていてワロタ
jQueryおじさんの俺が説明してやろう

リロード自体が要求になってるんじゃないんだよ。
重要なのはURLに対応した表示になるということだ

例えば、誰かにこのページ見てくださいってLINEかなにかで送った時、
相手もそれを同じ内容で見れるということが重要なんだよ。
それが出来てれば自然とリロードにも対応する

それから進むと戻るな。ブラウザで進むや戻るを押したとき
URLが変わるが、内容もそれに対応して変わらないといけない
これもURLい対応した表示ができるならば自然と実装できてることになる

リロードした時に表示内容が変わる変わらないは関係ない
データが更新されりゃそりゃ変わるだろ。それは問題ではなく
URLに対応して表示がされてるということが重要なんだよ。

**デフォルトの名無しさん** · 2019/03/13(水) 14:55:47.58

>>72
逆だよ逆。リロードしてもステートは基本変わっちゃダメなんだが。。別の何かと勘違いしてない？

**デフォルトの名無しさん** · 2019/03/13(水) 15:05:53.98

URLに乗っけるべき情報（ステート）と
そうでない情報を明確に区別して考えてるかい？
それぐらいSPAの基本になってるはずだろう？

なんかそういう前提基礎知識無いまま
フレームワーク使ってる！SPAが得意！俺SPAやってる！
みたいな馬鹿多そうだよね

**デフォルトの名無しさん** · 2019/03/13(水) 15:08:42.76

>>74
お前は巣に戻れ

**デフォルトの名無しさん** · 2019/03/13(水) 15:16:56.45

そうだな、皆さんスルーの方向で。

**デフォルトの名無しさん** · 2019/03/13(水) 15:22:27.03

じゃあID変えるわｗ

**デフォルトの名無しさん** · 2019/03/13(水) 15:41:41.69

仲良くしろよマン参上！

仲良くしろよ

**デフォルトの名無しさん** · 2019/03/13(水) 16:02:58.96

だからlocalStrage使う方法調べりゃいいだけしゃね？
どのフレームワークの話かはしらんけど

**デフォルトの名無しさん** · 2019/03/13(水) 16:56:50.71

今angular入れて色々弄ってるんだけど、思ってたより分かりやすかった。これは食わず嫌いだったかも知れん。lonic2も良い。

**デフォルトの名無しさん** · 2019/03/13(水) 22:36:26.58

今入院中でこの暇な時間使ってmacbookでreact nativeの開発環境構築したんだが、再起動しようとしたらmacOsの更新で引っかかってtimemachineで今朝に戻ってまたやり直しだよ。
Iphoneのデザリングは思わぬところで使えないな。
今日だけでパケット使用量が27.5GB超えたわw

**デフォルトの名無しさん** · 2019/03/13(水) 23:12:47.46

ツッコミ待ちか？

**デフォルトの名無しさん** · 2019/03/14(木) 01:02:58.29

>>67
あぁそうか。コンポーネント基準で状態を保持するんじゃなく、RxJSを基準に取得した情報の管理をすりゃいいのか。なんとなく分かったわ。

あと、サイトのリロードについては特に書いてなかったけど、リロード時にはクエリにレコードのidでも埋め込んで、
ABそれぞれでTestService呼べばいいか。

>>65
説明が悪かったわ。変数名が長いのが「めんどくさい」の根本原因じゃなく、
VS Codeでコンポーネントのhtmlに変数を書く時に補完が掛からないからいちいち変数部分だけコンポーネントで書いて、
それをhtmlにコピペするって作業してるけど、その作業がめんどくさいんだよ。

htmlにクソ長い変数名貼り付ける際にコピー範囲間違えて、貼り付けた内容の間違いに気付かなくて、
serveして動かねー！なんて事も結構あったから、何か予防出来る良い方法（出来れば補完を効かせる方法）無いかなぁと。

**デフォルトの名無しさん** · 2019/03/14(木) 01:08:44.08

Angularの人多そうだね
自分はReact派なので話がよく分からないわ

**デフォルトの名無しさん** · 2019/03/14(木) 08:12:54.12

きちんとIE11でも動くように確認してる？

**デフォルトの名無しさん** · 2019/03/14(木) 09:12:46.32

>>86
前スレでは殆ど話題にならなかったけどな

**デフォルトの名無しさん** · 2019/03/14(木) 09:48:52.88

>>85
ロードはそれで良いと思う。

あと補完部分だけど、俺はwebstorm使ってるからすまんけどvscodeだとどうなるのか分からない。でもそれ補完できるのが普通だから設定でどうにか出来そうな気がするんだけどね。。

**デフォルトの名無しさん** · 2019/03/14(木) 09:49:55.66

>>85
まだangular初心者なんで勘違いしてるかも知れんけど、webstormだと補完効いてる様に見える。少なくともコンポーネントのpublicな変数がhtmlで補完効かないという事は無い。注入したサービス内のプロパティも補完効く。

一度試してみたら？30日のトライアルあるし。インスコしてプロジェクト読み込むだけですぐ確認出来るよ。少し高いが。。サブスクだし。

**デフォルトの名無しさん** · 2019/03/14(木) 09:58:02.68

>>86
俺もreact vue派だよ。ただ聞いてた様なangularの急な学習曲線は無いと、現段階では思う。まだ全体を比較できるほど知ってる訳じゃないけど。

**デフォルトの名無しさん** · 2019/03/14(木) 17:30:00.98

ふと思ったんだけど、vscodeにangularのextension入れて無いから補完効かないとかじゃ、、違ったらすまんね。

**デフォルトの名無しさん** · 2019/03/15(金) 09:00:46.58

nuxtとかVuepress使ってる方いたら、使用感とか不満点とか教えてください。

**デフォルトの名無しさん** · 2019/03/15(金) 10:31:41.22

>>93
Nuxtでssrにexpress使用する場合って事？仕事で使ってるよ。
create-nuxt-app で pwa, express, vuetify 指定。
色々世話焼いてくれるのは良いけどカスタムしようとすると少しトリッキー。ルータ周りとか。元が緩いから常に複数のやり方がある。たまにコレで正しいの不安になる。不満点としてはそんなもん。

**デフォルトの名無しさん** · 2019/03/15(金) 11:49:10.14

職場のとなりのおっさんが秀丸でAIのフロント作ってた
設計もデザインもコーディングも全部一人で完結させてた
Reactも丸暗記してるみたいで秀丸で手打ち

手練れの人ならvscodeなんて要らない

**デフォルトの名無しさん** · 2019/03/15(金) 11:54:10.30

つメモ帳

**デフォルトの名無しさん** · 2019/03/15(金) 12:31:05.49

Webstormと違ってVSCodeは無料なんだから、そこまで嫌わなくてもいいだろう

**デフォルトの名無しさん** · 2019/03/15(金) 12:36:40.24

>>95
凄え。。俺には到底真似できん。

**デフォルトの名無しさん** · 2019/03/15(金) 13:26:57.92

vimじゃねえのかよ

**デフォルトの名無しさん** · 2019/03/15(金) 14:43:00.90

一方俺はVS Codeでバグが見つかり一時間考えてもわからず人に聞いたらただの変数名の間違いだった

**デフォルトの名無しさん** · 2019/03/15(金) 15:53:30.81

Reactで長いスペルって
componentDidMountとかライフサイクルメソッドくらいじゃない？

あとパッケージ名とか

**デフォルトの名無しさん** · 2019/03/15(金) 18:30:15.60

>>95
残念ながら、それでは比較になっていない。

同等の手練の人でvscodeを使う人と秀丸を使う人の
両方を用意して比較して初めて意味がある。

**デフォルトの名無しさん** · 2019/03/15(金) 19:23:38.69

そういうの文系ではapple to appleの比較って言うけど理系ではカッコよくなんて言うんだっけ？

**デフォルトの名無しさん** · 2019/03/15(金) 21:07:09.57

まあ実際のところメソッドの綴り思い出すくらいのことで生産性が上がったり下がったりはせんわ。

**デフォルトの名無しさん** · 2019/03/15(金) 21:43:10.81

つーか仕事で縛りプレイするなよ

**デフォルトの名無しさん** · 2019/03/15(金) 22:57:48.26

vscode嫌ってるとかでなく、よく知らない・導入面倒そう・そのうち考える　くらいの感覚で
現状維持（秀丸継続）してるだけだと思うよ

**デフォルトの名無しさん** · 2019/03/15(金) 23:07:57.45

(知り合いなの？)

**デフォルトの名無しさん** · 2019/03/15(金) 23:19:53.06

秀丸でもホットリロード効くのかね。試すつもりもないが。

**デフォルトの名無しさん** · 2019/03/15(金) 23:52:43.11

>>108
ホットリロードはwebpack-dev-serverの構成だろ

**デフォルトの名無しさん** · 2019/03/17(日) 09:13:50.38

正直コード補完って要らなくね？

**デフォルトの名無しさん** · 2019/03/17(日) 09:52:45.29

うそつきコード補完ならいいのか

**デフォルトの名無しさん** · 2019/03/17(日) 16:31:11.50

>>110
お前さんだけ補完オフにして使えば良いじゃん。

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

ﾜｯﾁｮｲなくなったからとれか分からんくなったけどReactマスターのｵｯﾍﾟｹはどんな環境でコーディングとかデザインとかやってるの？