19/01/16 12:06:14.30 vG26s5l3a.net
>>123
その辺の派閥でVue派とReact,Angular派に分かれるんだと思う
128:デフォルトの名無しさん
19/01/16 12:28:49.87 qfBMRYbTM.net
>>124
でも会社で使うなら、派閥起こしてる場合じゃなくね？
129:デフォルトの名無しさん
19/01/16 22:42:48.72 t0cjBe1r0.net
会社ならそれこそ会社で何使うか方針決めるんじゃない？
130:デフォルトの名無しさん
19/01/16 23:13:02.72 Xh3PQjx50.net
>>126
それは上が決めること
131:デフォルトの名無しさん
19/01/17 14:53:18.25 SGpR1rMEa.net
だから会社で方針が決まれば別に会社内部で派閥が分かれる事はないだろ？
それでいいじゃん何に対して突っかかってんの？
132:デフォルトの名無しさん
19/01/17 15:29:34.40 UwMlXiCx0.net
フレームワーク使いたいって言ってるのに
上に今までのやり方（jQuery）でいいやろ？って言われて
理解してくれないって突っかかってるんじゃねーの？
やるべきことはここで愚痴を垂れるんじゃなくて
「これからはフレームワークの時代なんです！」
以外のまともな理由を言うってことだよ
133:デフォルトの名無しさん
19/01/17 15:55:27.16 SGpR1rMEa.net
フロンエンドフレームワークの導入しやすさってバックエンド何使ってるかにも依るよね
134:デフォルトの名無しさん
19/01/17 16:08:31.53
135:UwMlXiCx0.net
136:デフォルトの名無しさん
19/01/17 18:52:05.06 rJrV68JMr.net
>>130
はあ？それはねーだろ
お前は無能晒して恥ずかしくねえの？
137:デフォルトの名無しさん
19/01/17 19:17:46.19 zQ8cL02fa.net
フロントフレームワーク使うことが即座にバックエンドがREST ONLYに繋がるわけではない
MVCとVueの組み合わせはかなりいい感じにまとまる
でもJSPやWebFormsでは全くミスマッチだろう
138:デフォルトの名無しさん
19/01/17 19:39:00.55 SGpR1rMEa.net
>>131
データのやり取り以前に初期導入時の敷居の違いの話
139:デフォルトの名無しさん
19/01/17 19:41:40.36 rJrV68JMr.net
>>134
そもそもバックエンドなくてもフロント作れるのがフロントフレームワークなのだが？
140:デフォルトの名無しさん
19/01/17 20:07:34.50 SGpR1rMEa.net
>>135
そんなシステムとして完結してないモノを見せて凄いでしょ？とか言うヤツばっかりだからjQueryのシェアが強いまんまなんだよ
XSSやらずにバックエンドのDBとどうやり取りすればいいかとか説明できんだろ？
141:デフォルトの名無しさん
19/01/17 20:28:06.33 rJrV68JMr.net
>>136
説明できんだろ？とかテメェ何様なんだよ？
XSSごときで偉そうなカス野郎www
142:デフォルトの名無しさん
19/01/17 20:47:57.11 SGpR1rMEa.net
>>137
話の主題はXSSじゃなくてデータベースの読み書きについてだが
>>135の言い分だとproxy設定とかロクに書いたことないだろ？
143:デフォルトの名無しさん
19/01/17 20:48:56.11 /uGhZ0I9d.net
ぷろきしｗｗｗ
144:デフォルトの名無しさん
19/01/17 21:03:54.46 9dtdj8/p0.net
フロントのスレだしリバースプロキシまで書かないと意味伝わんないんじゃないかな
145:デフォルトの名無しさん
19/01/17 21:34:00.77 Kv6gfvjN0.net
分からない人にはリバースプロクシって言ってもやっぱ分からないんじゃないかと思うけど
入門ならそんな事しなくてもいいLaravel-Mixが楽でいいと思う
146:デフォルトの名無しさん
19/01/19 11:35:33.75 /UsDDQKM0.net
いやそこの分離は本質だろ。
147:デフォルトの名無しさん
19/01/19 12:20:44.34 yV3NTFxEa.net
最終的には分離開発するにしても導入検討時から分離を強制してちゃ検討も進まないから結局導入されない
148:デフォルトの名無しさん
19/01/20 09:24:17.87 IfY+qP5bd.net
vueのテンプレート作成
ジェネレーターみたいなモノはないよな。(๑´ڡ`๑)
簡単な文法からVueライクなHtmlタグ入りのソリューションを提示してくれるような奴
149:デフォルトの名無しさん
19/01/20 11:30:01.35 DSIw24dXr.net
いくらでもありそう
150:デフォルトの名無しさん
19/01/20 15:22:05.46 NUl3GMJ00.net
>>144
vue template generator
でググったらそれっぽいのあったよ
151:デフォルトの名無しさん
19/01/21 16:34:43.42 hL7e9xxHd.net
それらしきモノって「ieoman」のことかな？
windowsの解説サイトが無くてフォルダーは手動で構築したけど
なんか半分ぐらい動く感じになった。文法は簡素な感じだけどGroovyやってる感覚になる。
yo mcs:component
ポチッとやたけど、成功パターンがそんなに
判らんので、実用的か、どうかも判らん
152:デフォルトの名無しさん
19/01/21 21:01:03.39 RUoLo0z1M.net
yeomanだろWwwWwWw
153:デフォルトの名無しさん
19/01/21 21:27:33.85 UOzXXkDMM.net
なんて読むの
154:デフォルトの名無しさん
19/01/21 22:29:18.49 63LMimZ70.net
>>149
URLﾘﾝｸ(dictionary.cambridge.org)
155:デフォルトの名無しさん
19/01/22 11:19:28.91 un/UAVV90.net
宇宙兄弟かな
156:デフォルトの名無しさん
19/01/23 22:47:18.07 QZsSw4x7p.net
今のプロジェクトでangular使ってるけどvue使ってみたかった
まだangularの事全然知らないけど、コンポーネントがts,html,cssでそれぞれ別れてるせいでファイル数膨大になるのが嫌だ
157:デフォルトの名無しさん
19/01/24 02:03:59.48 i2cda/I3M.net
Vueは小規模、Angularは中規模以上
という感じがしたな。手間的にも。
Angularの方がアプリ的な作りとして
しっかりしててわかりやすいかな
ただちょっとしたことですぐに動かなくなる
Vueもちゃんとルール決めして作れば
短期間で作れるしよいね
Reactはやってないからわからん…教えて
158:デフォルトの名無しさん
19/01/24 07:41:20.08 b/q9eM/c0.net
Angularを開発しているGoogleチームの敵は
別のGoogleチームかもしれない
Google、FlutterアプリをWebアプリへ変換する「Hummingbird」発表
URLﾘﾝｸ(www.publickey1.jp)
159:デフォルトの名無しさん
19/01/31 19:03:37.44 cDCUatpE0.net
Reactで静的サイト作るならGatsbyが素晴らしいよ
モダンなSSR、Webpack、GraphQL対応してるし
かっこいいサイトのテンプレートも充実してる
Reactの勉強用として使い始めたけどGatsbyハマったわ
160:デフォルトの名無しさん
19/01/31 21:00:28.63 +v5hiY8Ya.net
SPAフレームワークでSSRってなんか目的を見失ってませんか？
従来のMVCフレームワークでいいじゃないですか
161:デフォルトの名無しさん
19/01/31 21:12:30.75 6KX5syxR0.net
イエス。サーバーサイドフレームワークとjQueryで十分
162:デフォルトの名無しさん
19/01/31 21:20:31.38 JEItRzDdM.net
お前ら例に漏れずgatsbyの「SSR」を勘違いしてトンチンカンなこと言っててワロタｗｗｗｗｗ
ヒント： gatsbyは「静的」サイトジェネレータ
163:デフォルトの名無しさん
19/01/31 21:26:46.94 CYJz288f0.net
もうflutterでええやん。
164:デフォルトの名無しさん
19/02/01 06:19:45.77 mVBo/SPW0.net
>>155
サイトのテンプレートって
デモサイトどこかにある？
165:デフォルトの名無しさん
19/02/01 07:11:27.78 yx2noT3I0.net
Markdown方式（超簡単）で記事かけたりとまじGatsbyいいよ
>>160
URLﾘﾝｸ(www.gatsbyjs.org)
166:デフォルトの名無しさん
19/02/01 07:13:47.87 mVBo/SPW0.net
>>161
ありがと
トップページからだと
ここまでたどりつけんかった
167:デフォルトの名無しさん
19/02/01 09:13:31.45 hKW0Cv4Va.net
今大手サイトのフレームワーク利用状況ってどうなんだっけ？
ニコニコ、pixiv、Amazon辺りがReact使ってた気はするけど
168:デフォルトの名無しさん
19/02/01 09:20:37.92 Bt0WWmH6M.net
Netflix。サービスページほぼすべてに採用。
一部ランディングページから軽量化のためにlodashなどとともに取り除かれた際はアンチから「NetflixがReactやめたｗ」とデマ流されるほど。
あとTwitter。
URLﾘﾝｸ(www.infoq.com)
あと当然Facebook。
169:デフォルトの名無しさん
19/02/01 11:19:03.16 hKW0Cv4Va.net
そのサイトで使ってるかどうかはfirefoxのプラグインとかで分かるけどたしかにトップページにはないみたい
利用規約では検知した
170:デフォルトの名無しさん
19/02/01 12:44:24.16 V8zRexTTM.net
任天堂SwitchのeShopがReact
ZOZOがVue
という記事を読んだことある
171:デフォルトの名無しさん
19/02/01 15:34:39.74 1OLKpSdz0.net
大手サイトじゃなくて、大手企業のフレームワーク利用状況を知りたい
特に自社で何かしらのサービスを提供してない会社の
ほぼゼロであることはわかっていってますがなにか？ｗ
172:デフォルトの名無しさん
19/02/01 17:53:53.62 h+AyUO7aa.net
JSF使ってます
SPAはオモチャみたいなアプリにしか使えないから大手企業は採用しないと思います
173:デフォルトの名無しさん
19/02/01 18:25:03.74 Bt0WWmH6M.net
twitterはともかくfacebookおもちゃかあれ？
すごいアプリ製作してるんだね。
174:デフォルトの名無しさん
19/02/02 01:22:26.04 Oj61oPwf0.net
Amazonって欲しいものリストの部分だけReact入ってるみたいだね
175:デフォルトの名無しさん
19/02/02 04:16:46.09 W7PHwOVUM.net
WappalyzerっていうChrome拡張入れるといいよ
サイトでReact使ってたら素晴らしいしReact+Gatsby使ってたらナカマだし、違った見方でネットブラウジングできる
jqueryのみだとダサってなる（実際サイトの用途にはよるし使ってる人ごめんなさい）
他にも使ってるサーバーとかDBとかWordPressだ～とかわかるよ
176:デフォルトの名無しさん
19/02/03 19:47:52.31 1rPAmYno0.net
vuetify使ってる人いない？
公式のマニュアルが説明不足で全然わからんのだけど、
どこで情報仕入れてる？
formのresetボタンすら動作しない
もっと見やすくてわかりやすいUIはないものか
177:デフォルトの名無しさん
19/02/03 22:23:42.35 WjHZzJrh0.net
vuexに依存しないvueコンポーネントってどうやって作ってる？
頑張ってpropで渡すか、コンポーネントextendsしてメソッドオーバーライドするしか
思いつかないんだけどみんなもっと上手いことやってるの？
178:デフォルトの名無しさん
19/02/04 00:48:04.11 QWfNHn9SM.net
てかなぜvuex使わないのか
179:デフォルトの名無しさん
19/02/04 08:07:14.34 G7sMcdiQ0.net
全般的にUIコンポーネントって部品の説明不足だよな
180:デフォルトの名無しさん
19/02/04 08:32:32.96 +iZnVKUhM.net
>>174
書き方が悪かったかも知れん。現状でもvuexは使ってる。
例えばvuexにstore/user/flowerFlag:boolean がある
flowerFlag === trueなら ボタンコンポーネントの色を花っぽくにするって時にどうしてる？
1.propでflowerFlagを渡す
2.コンポーネント内にgetColoer()メソッド作って個別にextend/overwriteする
この2つの方法以外にももっといいやり方あるんかな？
181:デフォルトの名無しさん
19/02/04 09:29:22.24 Qx+SAuX0r.net
UIコンポーネントは自作すればいい
182:デフォルトの名無しさん
19/02/04 09:42:43.98 wHc+gudyM.net
flowerFlagって名前が気に入らない
何をするフラグなのかさっぱり分からない
useFlowerTheme: boolean とかにしろや
183:デフォルトの名無しさん
19/02/04 12:27:23.88 jZQr0rin0.net
shoriKbnFlg
184:デフォルトの名無しさん
19/02/04 14:15:30.10 d7fkSk13p.net
makeBrainFlower === true
185:デフォルトの名無しさん
19/02/04 19:55:50.85 ssiW6pqzM.net
havingDirtyFireworks = true;
URLﾘﾝｸ(www.urbandictionary.com)
186:デフォルトの名無しさん
19/02/06 17:54:
187:16.50 ID:cXGNS95ra.net
188:デフォルトの名無しさん
19/02/06 18:43:12.38 259i/glJ0.net
そう思いたくて必死なのが笑えるｗｗｗ
そうやって得た安心は妄想だぞｗｗｗｗ
Rendertronを使ったダイナミック レンダリングの実装手順をGoogleが解説
URLﾘﾝｸ(www.suzukikenichi.com)
189:デフォルトの名無しさん
19/02/08 18:47:35.85 J+/qVGg10.net
Reduxってムズイよな
190:デフォルトの名無しさん
19/02/08 20:58:46.78 Waqd0NNdr.net
どのへんが？
191:デフォルトの名無しさん
19/02/09 08:15:58.88 RdduHrOP0.net
Vueに乗り換えます
じゃあな
192:デフォルトの名無しさん
19/02/09 08:16:45.44 RdduHrOP0.net
めっちゃIDがReduxっぽいけど
193:デフォルトの名無しさん
19/02/09 08:29:03.30 6iVlgEPUr.net
ここvueスレでもあるけどよくわからんがさよなら
194:デフォルトの名無しさん
19/02/09 13:36:35.69 R3UI++NJ0.net
スレタイのやつ3つとも触ったことないままAureliaってやつを採用しようと思ってるんだが、お前らの評価はどんな感じ？
採用の理由としてはVueが選ばれるのと同じだと思う
195:デフォルトの名無しさん
19/02/09 14:04:19.59 F2V9krnu0.net
調べてみたら3年くらい前にちょっと流行ったみたいだけど
未だに話題になってないって事はそういう事なんじゃない？
196:デフォルトの名無しさん
19/02/09 18:48:21.70 JM+D9hMz0.net
流行り廃れでフレームワークを選ぶんじゃねえ！
自分に一番合ったフレームワークを選ぶんだ！
197:デフォルトの名無しさん
19/02/09 21:03:07.28 OJ6TU+cc0.net
そうするとjQueryでいいということになる
198:デフォルトの名無しさん
19/02/09 22:38:36.16 +053I9atM.net
URLﾘﾝｸ(jquery.com)
jQuery: The Write Less, Do More, JavaScript "L i b r a r y".
ライブラリであることに負い目でもあるのかな？ｗ
フレームワークの流儀を押し付けられず、どこでも好きなように自由に使えるのがライブラリの強みだと言うのに。
199:デフォルトの名無しさん
19/02/09 23:21:06.75 OJ6TU+cc0.net
どこ見て負い目があると感じたんだ？
ライブラリだからライブラリって書いてあるだけだろう
200:デフォルトの名無しさん
19/02/09 23:22:07.95 YyhK9/uE0.net
angularはwebエンジニア以外の血が流れてるんじゃないのか？ゲームエンジニアでhtmlもjavascriptも経験がなかったときの俺には非常に使いやすかった。
web関連の経験値がたまってきた今となっては大がかりに感じちゃってあえて使おうという気はでないが…
201:デフォルトの名無しさん
19/02/09 23:54:11.39 w7h73/LU0.net
フレームワークと言われるのがウゼーから強調してると思うが
Reactもライブラリって名乗ってるな
202:デフォルトの名無しさん
19/02/10 00:23:54.54 0+1G/wKUa.net
結局MVC+jQueryが一番バランスとれてんだよな
SPAなんて作る側にも使う側にも画面遷移が超早いぐらいしかメリットねえもん
203:デフォルトの名無しさん
19/02/10 01:13:27.71 Ewu7Fccw0.net
>>197
それは流石にSPA作った事無いやつの暴論
204:デフォルトの名無しさん
19/02/10 02:19:44.57 EmtOscou0.net
jQueryの功績は確かに大きい。その次の世代として仮想domありきのvueやreactなんだから、jQueryとの比較は意味が無い思う。
205:デフォルトの名無しさん
19/02/10 02:53:41.79 rzMRhZmV0.net
大雑把にいうとライフサイクルメソッドみたいなイベントとか状態管理などの枠組み含むものがフレームワークで
枠組は使用者が作って機能を呼び出すのがライブラリだろ
206:デフォルトの名無しさん
19/02/10 13:00:31.92 h0ljrL+B0.net
>>199
> 仮想domありきのvueやreactなんだから、
仮想DOMはメリットじゃないよ
フレームワークの設計上どうしても遅くなるという問題を
回避するための手段でしか無い
遅くなければ仮想DOMなんて無いほうが良い
207:デフォルトの名無しさん
19/02/10 15:30:08.63 rzMRhZmV0.net
そういやスタイル側のフレームワークって何がいいの？
基本はBootstrapなんだろうけど
208:デフォルトの名無しさん
19/02/11 18:23:39.83 33lwyeb6d.net
やりこめば
やるこむほど
思うけど、vueは簡単じゃあないと思う。
209:デフォルトの名無しさん
19/02/11 19:34:12.30 s7yVsu1/r.net
reactとvueどっちがむずいのかね
210:デフォルトの名無しさん
19/02/11 20:28:50.21 HASh9YeP0.net
よう分からんけど、日本じゃ wasm は話題にならないね。
情報が遅れてるんだろうか？
211:デフォルトの名無しさん
19/02/11 21:18:49.40 34Z/DRMs0.net
javascriptが十分に速いから
212:デフォルトの名無しさん
19/02/11 21:4
213:0:45.56 ID:9qVoQSgPM.net
214:デフォルトの名無しさん
19/02/11 21:46:24.07 wrnl7DNU0.net
wasmが必要となるようなものは、
ウェブじゃなくてアプリにするから
215:デフォルトの名無しさん
19/02/12 08:51:23.06 dWGWBM0h0.net
なるほど、日本では、「JavaScript を高速にしたもの」と思われている段階なんだね。
アメリカではパラダイムシフトが起きると思われているらしく、色々と恐れられて
いたりもするらしい。
216:デフォルトの名無しさん
19/02/12 10:58:51.22 qsQxhdCu0.net
ﾜｯﾁｮｲがVueやんけ
217:デフォルトの名無しさん
19/02/12 12:14:49.91 3leffBPz0.net
>>209
パラダイムシフトと言っても所詮
ウェブがアプリに追いつくぐらいの意味でしか無いから
218:デフォルトの名無しさん
19/02/12 12:37:49.91 06lg1M4xa.net
C#がクライアントで使えるようになるだけでもかなり有り難い
Microsoftなら開発者に優しいエコシステムを提供してくれる
219:デフォルトの名無しさん
19/02/12 13:41:43.16 KSl1FEVj0.net
あんなもの昔の時代へのパラダイムシフトでしかないだろ
負の遺産を再び抱え込むだけだよ
220:デフォルトの名無しさん
19/02/12 14:02:56.84 dWGWBM0h0.net
>>212
wasmでは、C#は使えるようにならないはず、一生。
221:デフォルトの名無しさん
19/02/12 14:38:31.80 poZCG/I0p.net
NaClが出始めの頃や、なんならActionScriptやSilverlightのRIAでもパラダイムシフトだのなんだの言われてたな。
222:デフォルトの名無しさん
19/02/12 15:14:29.49 dWGWBM0h0.net
>>214
すまん。既に使えるらしい。
.Net 仮想マシンを、wasm に移植したのかな。
223:デフォルトの名無しさん
19/02/12 15:24:18.10 dWGWBM0h0.net
WinForm か WPF か知らないけど、そういう標準的な作り方をしたC#が
ブラウザでそのまま動くということではなくて、Razorを使って専用に
作らないといけないらしいね。
224:デフォルトの名無しさん
19/02/12 15:50:17.94 dWGWBM0h0.net
JavaのGUIの場合、Swingは、完全にJavaで書かれていて、OSに
依存せずに全部自前で書かれているので、Java仮想マシンさえ動けばどんなOS
でも完全にGUIアプリが動く。
でも、C#の場合はライブラリがWin32 APIなどを呼び出しているから、そうは
行かないみたいだね。よく知らないけど。
225:デフォルトの名無しさん
19/02/12 17:33:20.32 tia7IyO5M.net
razorてメチャメチャ容量大きくなっちゃってまだまだ使い物にならないんでしょ？モバイル用にでも使えるくらい小さいの吐いてくれないかなぁ…
226:デフォルトの名無しさん
19/02/12 19:00:48.09 1MzWJDZPd.net
webの技術にパラダイムシフトって言われるような変化起こすにはjavascriptの標準仕様が劇的に変わるか、革命的なブラウザが出てきてとんでもないシェアを握るってパターンしかないという理解だわ。
227:デフォルトの名無しさん
19/02/12 19:36:10.46 1aNudvIBa.net
無理して既存の資産をwasmに移植するメリットはないと思うね
最初はへんな抽象化せずにDOMによく馴染むHTMLフレンドリーなライブラリをC#で実装してくれればいい
なんならjQuery.Netみたいなパクりでもかまわない
手を出しやすい土台を作って欲しい
228:デフォルトの名無しさん
19/02/12 20:54:50.86 3leffBPz0.net
wasmって既存の資産を移植するためのものだよ？
最初から作れるのならJavaScriptを使えば良いわけだし
229:デフォルトの名無しさん
19/02/12 21:13:01.75 II9d+pHTd.net
>>219
Blazorな
230:デフォルトの名無しさん
19/02/12 22:15:31.30 zazJl4ej0.net
HTML5によってFlashなどのプラグインが死んでいったり
JavaScriptからカメラやマイクにアクセス出来るようになったりとそれなりに影響があった
WebAssemblyはそれらをさらに強化する
JavaScriptでは限度があった動画/音声データのリアルタイム解析なども可能になる
プラグインが死んだUnit
231:yも今はWebGL+WebAssemblyで動く プラグインでバラバラ対処してたことが標準化されたって感じかね 劇的に変わる、と言うのはちょっと違う気もするが
232:デフォルトの名無しさん
19/02/12 22:37:43.88 Jl2Y8iQt0.net
HTML+CSS+javascriptでの開発って他の分野に比べると独特だから実は参入障壁高いんだよね。使いこなせないだけなのに技術そのものがショボいと言いだす。
だからwebフロントエンド以外の開発者がwebフロントエンドの開発したくなったときにいろんな手法を見つけて何とかしようとするんだけど、なれてくると別にHTML+CSS+javascriptでいいやってなる。
そんなイメージ。
233:デフォルトの名無しさん
19/02/12 22:51:06.28 Lzw+Arvw0.net
メモリの扱いというかデータの受け渡しがだるいから、TypedArrayに対して高速に計算するだけの何かを導入してくれたほうがマシだった
234:デフォルトの名無しさん
19/02/12 23:16:46.90 qsQxhdCu0.net
wasmってiOSとAndroidに対応してる(する)の？
235:デフォルトの名無しさん
19/02/12 23:20:52.48 tia7IyO5M.net
>>226
これ。
236:デフォルトの名無しさん
19/02/12 23:49:27.70 mBIHBqGr0.net
>>227
もちろん
Web標準やで？
237:デフォルトの名無しさん
19/02/13 00:50:15.15 wb3NGc0D0.net
んなことよりpush通知実装しろ。iOS safariテメーのことだ。
238:デフォルトの名無しさん
19/02/13 00:55:06.05 GHq8zte20.net
>>225
JVM の代わりとなる仮想マシンと考えた場合、C++ で書けることは重要なんだ。
C++は型があるので、ミスをコンパイラが発見してくれる事が多いから。
例えば、JSだと関数の引数が多くても少なくてもエラーにならない場合がある
と思うけど、C++では敢えて分かっていてそうする場合以外は必ずエラーになる。
C++ では整数型を受け取るつもりの仮引数に浮動小数点型の実引数を渡すだけでも
エラーになる。ところが、JavaScript ではエラーにならない。
このようなことがあるので、JavaScirpt は大規模アプリをC/C++で組んだことの
有るプログラマからは嫌われている。特にアメリカで。
239:デフォルトの名無しさん
19/02/13 00:56:36.75 dfUEINu60.net
TypeScript使えばいいだけじゃね？
240:デフォルトの名無しさん
19/02/13 01:03:22.46 GHq8zte20.net
JavaScript だと、プロパティーには文字列と数値、Objectのどれでも入れられるので
単に書き間違えているだけなのに、エラーにならないので原因不明の不具合が直らずに
困る可能性がある。例えば、1,2,3 の 3つの数値を用いて、何か3種類を区別する
目的でプロパティー aaa を作ったとしよう。
aaa = 1;
aaa = 2;
aaa = 3;
と書くことをプログラマは想定している。ところが間違って、
aaa = "x";
と文字列型を入れてしまった場合、どこかで不具合が起きるだろうが、ソースが何10万行も有る
プログラムの場合、この間違えて書いてしまった行を探し出すのに苦労することになる。
こういう間違いが、C++ では、魔法のようにコンパイラが発見してくれる。だからC++は
安全で安定性が高いために人気がある。
241:デフォルトの名無しさん
19/02/13 01:06:00.32 dfUEINu60.net
テスト書くんだからすぐ見つかるでしょ？
242:デフォルトの名無しさん
19/02/13 01:06:08.06 GHq8zte20.net
>>232
その言語を多くの人は知らない。ずっと古くからC言語があり、とても人気があって、
その後継にC++があって今でも続いている。アメリカではC/C++経験をつんだ
プログラマが日本よりも沢山いるためか(?)、C/C++ で wasm が使えることで
game changer, pardigm shift などと喝采が起きているらしい。
243:デフォルトの名無しさん
19/02/13 01:06:59.54 GHq8zte20.net
>>234
なぜ、C/C++ が型を書いているかは、言語が古いからではなく、まさに
エラーチェックのためなんだよ。
244:デフォルトの名無しさん
19/02/13 01:12:36.84 WxTmz2dr0.net
245:typescriptはもう半数が使ってるくらいの感じでしょ
246:デフォルトの名無しさん
19/02/13 01:14:25.09 GHq8zte20.net
>>234
テストで結果が異常であると分かっても、どこに原因があるかが分からないことがある。
だから、細かく実験していく必要があり、それには時間がかかる。
型の間違いをコンパイラが見つけてくれるだけでもミスが判明することが
かなり多くあり、開発時間の節約・短縮に大幅に貢献することになる。
ミスったときには、型や引数の個数まで間違っている確率は意外と高いので、
それだけでも8割くらいの単純ミスは発見できてしまう。
247:デフォルトの名無しさん
19/02/13 01:15:17.87 GHq8zte20.net
>>237
Webプログラマから入った人にはそう思えるかもしれないが、昔からの
普通のデスクトップアプリを作ってきた人はそうではない。
248:デフォルトの名無しさん
19/02/13 01:16:31.85 5ssU2x9I0.net
C++ソース（型がある）→コンパイル（型情報に基づきエラー）→バイナリ（型はない）→ネイティブ実行
Type Script（型がある）→トランスパイル（型情報に基づきエラー）→JS（型はない）→ブラウザ実行
あんま変わらん。
wasmが出てきてから聞かなくなったけどJSはWebのアセンブラとは言い得て妙だったな。
249:デフォルトの名無しさん
19/02/13 01:17:39.67 dfUEINu60.net
>>235
> その言語を多くの人は知らない。
大丈夫。TypeScriptはJavaScript＋αだから
α（型）の部分を除けばJavaScriptそのもの
250:デフォルトの名無しさん
19/02/13 01:18:26.87 dfUEINu60.net
>>238
> テストで結果が異常であると分かっても、どこに原因があるかが分からないことがある。
十分にモジュール化されてればすぐに分かるよ
251:デフォルトの名無しさん
19/02/13 01:19:20.67 GHq8zte20.net
>>240
TypeScript という言語自体を今までの大部分のプログラマは知らない。
言語はなるべく1種類を学ぶだけの方が楽だから、C/C++ という事になる。
252:デフォルトの名無しさん
19/02/13 01:19:47.09 WxTmz2dr0.net
逆だな。javascriptをすごく理解してるWebプログラマのほうがjavascriptで粘ってて、
javascript理解しがたいと思ってる人らがtypescriptに救いを求めて移行した感じがある
253:デフォルトの名無しさん
19/02/13 01:22:34.41 GHq8zte20.net
>>241
そこまで頑くなに C/C++ を拒絶する理由がない。
C/C++ を1つ覚えるだけで組み込みから何から何まで作れるようになり、
速度も現存する高級言語の中でTOPな上に、エラーも少なく、安全。
過去からの資産も多い。例えば、画像処理、AI、音声解析、文字認識、
3D描画、物理計算、何から何まで C/C++ は存在している。
敢えて後から出てきた言語を覚えるの無駄。
254:デフォルトの名無しさん
19/02/13 01:24:05.31 GHq8zte20.net
>>244
でも、ハイレベルなプログラマはそうは思ってないと思うよ。
実際に作った作品で勝負したら C/C++ の圧勝だと思う。
機能面でも速度面でも安定性も品質も。
255:デフォルトの名無しさん
19/02/13 01:25:16.64 5ssU2x9I0.net
>>243
js抜きにしてもtypescriptの型システムは良くできててC系文法の型システムとはこうあるべしといったお手本みたいだけどな。
c++の型システムは継ぎ足しキメラの失敗作だけど今さらどうしようもできねえしな…
256:デフォルトの名無しさん
19/02/13 01:36:11.82 GHq8zte20.net
>>247
仮に TypeScript に色々良いところがあったとしても、今迄から高い定評の有る
C/C++をまず、覚えてしまうほうがずっと将来性がある。
だから、人々はC/C++を覚えようとしてきたし、少なくともアメリカのプログラマ
はそうしてきた。いったんC/C++を習得すると、それだけでほとんどあらゆることが
簡単にできて、成果物の効率や速度もとても高く、エラーも少ないものが出来る。
その状態で敢えて、TypeScriptを覚えるのは非効率。だから、C/C++ が
ブラウザで動くのはすごく魅力的な話という事になる。
257:デフォルトの名無しさん
19/02/13 01:37:20.24 vNuAntxeM.net
S： もうかなり時間がたったしね、C++ が時間の無駄だということにはほとんどの人が気がついたとは思うけど、でも当初予想していたよりはずいぶん時間がかかったな。
I： 具体的に何をどうやったのかな。
S： 最初はほんの冗談のつもりでね、みんながあの本を真に受けるとは思ってもみなかったんだ。脳みそが半分でもあれば、オブジェクト指向プログラミングが非直感的で、非論理的で、非効率なことくらいはわかるよね。
I： え？
S： それに「コードの再利用性」ときたら…。どこかの会社がコードを再利用したなんて話を聞いたことがある？
I： いや、実はないんだけども、でも…。
258:デフォルトの名無しさん
19/02/13 01:40:07.00 dfUEINu60.net
>>245
> そこまで頑くなに C/C++ を拒絶する理由がない。
C/C++は開発効率が悪いから。
ポインタを使うのに、std::auto_ptrを使わないといけない
そして世界が混沌としていて、ポインタという基本的なものでさえ
時代が変われば使い方がガラッと変わってしまう（皮肉）
259:デフォルトの名無しさん
19/02/13 01:41:57.50 SgfrIpbp0.net
>>250
>ポインタを使うのに、std::auto_ptrを使わないといけない
5ch/2ch の言うことを真に受けるとそうなるが、普通に、
BYTE *ptr;
TYPE *ptr;
で済む。昔から、C++ といえばこのスタイルで、auto_ptr 自体はずっと後発で、
C++ ではないといっても過言ではない。
260:デフォルトの名無しさん
19/02/13 01:42:17.61 dfUEINu60.net
>>248
> だから、C/C++ がブラウザで動くのはすごく魅力的な話という事になる。
既存のC/C++の資産をJavaScriptから使うのに便利だよね～
261:デフォルトの名無しさん
19/02/13 01:42:56.75 dfUEINu60.net
>>251
今どきそんなコード書かないよ？
既存のライブラリのソースコード見ろよ
262:デフォルトの名無しさん
19/02/13 01:43:28.32 GHq8zte20.net
>>250
>C/C++は開発効率が悪いから。
そんなことはない。メモリリークのことを気にしているなら、デストラクタの
中で解放するように1行書くだけで、ほとんどの場合はリークしないし、
危険なこともない。
263:デフォルトの名無しさん
19/02/13 01:44:23.63 GHq8zte20.net
>>253
ネットはおかしい情報が多い。
ちゃんと本を見たほうがいいよ。
264:デフォルトの名無しさん
19/02/13 01:45:15.56 dfUEINu60.net
>>254
デストラクタの中で解放する1行を書き忘れた場合、それでも動くから
どこかで不具合が起きるだろうが、ソースが何10万行も有る
プログラムの場合、この間違えて書いてしまった行を探し出すのに苦労することになる。
265:デフォルトの名無しさん
19/02/13 01:45:52.84 dfUEINu60.net
ミスったｗ
デストラクタの中で解放する1行を書き忘れた場合、それでも動くから
どこかで不具合が起きるだろうが、ソースが何10万行も有る
プログラムの場合、この間違えて書き忘れた行を探し出すのに苦労することになる。
266:デフォルトの名無しさん
19/02/13 01:46:57.29 GHq8zte20.net
>>253
std や auto_ptr を使うから難しく感じるんだよ。
何度も言うが、それは C++ ではない。これはマジ。
今の std:: 系のライブラリはSmalltalk の信者が作ったものらしい。
C++ の標準化委員会がおかしなことになっていて、もはや、本来のC++
ではなくなってきており、だから、C++が難しいと感じる人が増えている
気がする。
267:デフォルトの名無しさん
19/02/13 01:47:47.99 dfUEINu60.net
>>258
え？お前C++使いこなせないの？
268:デフォルトの名無しさん
19/02/13 01:48:20.38 GHq8zte20.net
>>257
クラスが 100種類の場合、デストラクタは 100 個しかない。
だから、ソースが数10万行あっても、100箇所を調べるだけで済むよ。
269:デフォルトの名無しさん
19/02/13 01:49:31.69 dfUEINu60.net
>>260
調べる箇所が100箇所でも
何を解放し忘れたかを確認するのは大変
270:デフォルトの名無しさん
19/02/13 01:49:40.75 GHq8zte20.net
>>259
日本だと auto_ptr みたいなのが C++ だと思ってる人がいるけど、
勘違いだよ。
271:デフォルトの名無しさん
19/02/13 01:51:15.37 dfUEINu60.net
stdなんちゃらを使わなかったら
バッファオーバーランで脆弱性になるし
それでも動くから
どこかで不具合が起きるだろうが、ソースが何10万行も有る
プログラムの場合、この間違えた行を探し出すのに苦労することになる。
272:デフォルトの名無しさん
19/02/13 01:51:20.27 GHq8zte20.net
>>261
だから新しい言語を次々に覚えて C/C++ だけは覚えないで過ごしてきたのかな、
あなたは？
数十の言語を覚えるより、C/C++ を1つ覚えるだけが良いと思うよ。徹底的に
それだけを学んだほうが良い。
273:デフォルトの名無しさん
19/02/13 01:51:48.19 dfUEINu60.net
>>262
勘違いとかそうでも良いわｗ
auto_ptrが使えて、実際にauto_ptrが使われるがC++だから
274:デフォルトの名無しさん
19/02/13 01:53:24.20 dfUEINu60.net
>>264
はいそうですね。C/C++は数十の言語を覚えるのと同じぐらい苦労しますもんね
いろんな言語の機能をキメラのように組み合わせた言語ですから
人によって書き方がぜんぜん違う
auto_ptrを使ってるだって！？これC＋＋じゃないよ！
って言う人がいるぐらいだから
だから開発効率が悪い
275:デフォルトの名無しさん
19/02/13 01:54:19.14 5ssU2x9I0.net
さもTypeScriptが競合であるかのように突っかかってきてるが全く的外れ。
TypeScriptのトランスパイルターゲットはJS。
競合はその他AltJS。
この中では既に天下取って安泰。
C++のコンパイルターゲットはWASM。
競合はRust、Kotlin、.NET、、、どんどん増えるぞｗ
がんばってな！ｗ
もちろんナマのJSはWeb界のグルー言語として残り続けるよ。
シェルスクリプトが性能を理由に消えないようにね。
276:デフォルトの名無しさん
19/02/13 01:54:36.76 GHq8zte20.net
>>263
そうならないように、C から C++ に進化してきたんだ。
そのために、コンストラクタ、デストラクタの概念が導入された。
それだけでも十分に安全で簡単に書ける。
逆に、std ライブラリは構造が理解しにくいので難しく感じるんだろう。
auto_ptr とか使おうとすると、C++ は一気に煩雑で嫌いになってしまうと思う。
だから、auto_ptr も std:: 系ライブ来も SmallTalk 信者が作ったものであって、
C++ の流儀とは全く異なる異質なもの。C++ で SmallTalk をやろうとするので
めちゃくちゃ複雑になってしまっている。
277:デフォルトの名無しさん
19/02/13 02:22:49.78 GHq8zte20.net
>>266
>はいそうですね。C/C++は数十の言語を覚えるのと同じぐらい苦労しますもんね
C++98 まで覚えれば大体C++の基本は習得できていて、それはそんなに大変
ではない。
・auto_ptr 系は、uniq, smart など沢山ありすぎるので、初心者には難しく、
下手に使うと、生ポインタより危険かも知れない。これらはかなり後発のものなので、
最初は覚える必要はない。
・std:: 系ライブラリは後から習得すればよい。
278:デフォルトの名無しさん
19/02/13 03:28:22.27 NEY8ay330.net
>>229
マジで？！
だって公式のデモはiPhoneだと動かへんで？
279:デフォルトの名無しさん
19/02/13 04:23:45.97 VGvE+KfY0.net
>>270
まさかSafariとか使ってないよね？
280:デフォルトの名無しさん
19/02/13 08:13:08.13 a9PctXZid.net
C/C++は使うべき場面が決まってるから他の言語と揉めたりしないと思ってたんだが。
281:デフォルトの名無しさん
19/02/13 09:05:05.03 yk1KGOSba.net
なんかSafariだけで動くwasmの代替品独自に作ってなかったっけ？
282:デフォルトの名無しさん
19/02/13 09:40:07.95 SgfrIpbp0.net
>>271
SafariもWasmはサポートしてると読んだけど、確か。
283:デフォルトの名無しさん
19/02/13 09:53:24.60 GHq8zte20.net
TypeScript って、MSの独自言語なんだよね、知らないけど。
284:デフォルトの名無しさん
19/02/13 10:06:57.83 GHq8zte20.net
>>261
例えば、VS の VC++ で C++ ソースをデバッグモードでビルドして、できたバイナリを
デバッガで実行すると、そのアプリの終了時に、メモリーリークが起きているか
どうかがIDEの Output Pane に出力されるようになっていて、その
285:際、どのソースの 何行目で new TYPEしたオブジェクトが解放し忘れているかが、ずらずらと一覧表示される。 で、その場所が分かったら、多くの場合は、そのポインタをメンバ変数に「持っている(have a)」 class のデストラクタに、1行、delete ptr; と書くだけで、メモリーリークは直る。 例外として、複数のポインタから同じオブジェクトを参照していて、かつ、そのポインタ が永続的にグローバル変数や、何らかのクラスのメンバ変数に格納されている場合には、そこまで 単純には行かない。その場合は、プログラマが頭で考える必要がある。
286:デフォルトの名無しさん
19/02/13 10:21:08.64 uBt5bsN50.net
C++の方向性は最初から何も変わっていない
ctor/dtor, RAII, ムーブとより整理されていっただけ
1985 C++ / TYPE * (Cfront 1.0)
1986 C++ / (実装予定のtemplateなどの説明した文書が公開)
1991 C++ / T* (template可能, Cfront 3.0)
1992 C++ / auto_ptr (STL実装, 例外導入, RAII)
1998 C++ / (最初の標準化, C++98)
2011 C++ / unique_ptr (ムーブセマンティクス, C++11, auto_ptr非推奨化)
2015 Rust / 言語レベルで所有権システムを導入 (デフォルトがムーブ, Rust 1.0)
wasmに絡むとはいえスレチ気味で
しかも古いやり方の話を何レスしてるんだか・・・
287:デフォルトの名無しさん
19/02/13 12:08:13.64 ARXdU5axd.net
>>274
カバーしてる範囲が他のブラウザーに比べてかなり狭い
288:デフォルトの名無しさん
19/02/13 12:29:26.16 PdBWBPPzd.net
このスレ的にはわざわざC++使うんじゃなくてTS→wasmじゃないの
289:デフォルトの名無しさん
19/02/13 13:09:58.06 cmhWA5saM.net
tsnativeかts.net来ないとwasmにはコンパイル出来ないだろ。
せっかくAltJS戦争に勝ってブラウザのjsに対する忖度パワーをすべて手に入れたのにわざわざwasm戦争に参入する必要はないだろ。
c++の構文が古くさすぎ冗長すぎで嫌、rustの構文はキモすぎて嫌と言うならkotlinかc#にすれば。
290:
19/02/13 18:53:44.11 Wb2hS8BD0.net
>>249
C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために
さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが
簡単に生産されるようになってる。正直いって、C を選ぶ理由が C++ プログラマーを
追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
C++ はトンでもなく悪い設計の元になりうる。どうせこの言語ではいつも STL やら
Boost やら、その他ゲロゲロベロベロの「素敵な」ライブラリの機能を使って、
それがあんたのプログラムに「役立つ」んだろうが、以下のことが起きる:
- うまく動かないときにもたらされる際限のない苦痛 (あと STL とか、特に Boost が
安定してるとか移植性があるとかいう奴は、どいつもこいつも大ウソつきで、
もはや笑えるレベルを超えている)
- 非効率な抽象プログラミングモデルで、2年たった後にこれらが実はそんなに
効率的じゃなかったことに気づくケース。でもそのときにはすでに全部の
コードがその素晴らしいオブジェクトモデルに依存していて、直すためには
アプリ全体を書き直さなきゃなんない。
言いかえれば、唯一まともで、効率がよくて、システムレベルで使えて、移植性がある
C++ ってのは、基本的に C で使える機能だけに限ったときなんだ。そして C だけに
限定するってことは、他の人がそれをめちゃくちゃにしないってことで、
ついでに沢山のプログラマが実際に低水準の問題を理解することができて、アホらしい
「オブジェクト・モデル」のたわごとを持ちこまないってことだ。
291:デフォルトの名無しさん
19/02/13 20:56:27.69 kDMwAzYp0.net
VuexとReduxってどっちがムズイの？
292:デフォルトの名無しさん
19/02/13 20:56:51.46 kDMwAzYp0.net
もしかして考え方同じ感じ？
293:デフォルトの名無しさん
19/02/13 21:10:22.40 tuDfzjia0.net
Angularってwikipediaには「フロントエンドWebアプリケーションフレームワーク」って書かれてるけどまさにその通りだよな。javascriptのフレームワークって感じではないわ。
HTMLとCSSとjavascriptの技術を採用したweb�
294:Tイト開発フレームワークって感じ。
295:デフォルトの名無しさん
19/02/13 21:18:15.13 sgtLrhrBr.net
Reduxのほうがムズいけど、これからやるならReduxがいい
296:デフォルトの名無しさん
19/02/13 21:20:44.51 dfUEINu60.net
>>284
JavaScriptのフレームワークって感じではないって意味がわからんぞ。
普通はJavaScript製のフレームワークって意味だろ
○○（何かしらの言語）製のフレームワークなのだから
AngularはJavaScript（製）のフレームワークだ
別の言語なら、〇〇（言語）のフレームワークなんてものが存在するのか？
297:デフォルトの名無しさん
19/02/13 21:31:05.74 kDMwAzYp0.net
angularとReact、Reduxってどっちが簡単？
298:デフォルトの名無しさん
19/02/13 21:51:18.70 jwc/pNVH0.net
学生時代、英単語の暗記が得意だったやつはangular、数学が得意だったやつはreact
299:デフォルトの名無しさん
19/02/13 22:24:48.70 tuDfzjia0.net
>>286
なるほど。
ピュアjavascripで書いたら大変な記述をちゃちゃってやってくれるからスレタイの3つとかjqueryとかはjavascript(の)フレームワークって呼ばれてると思ってたんだがとんだ勘違いだったのね。
300:デフォルトの名無しさん
19/02/13 22:28:21.60 tuDfzjia0.net
冷静に考えれば>>289はライブラリか。
301:デフォルトの名無しさん
19/02/13 22:33:40.93 cHKWNBlR0.net
jqueryとreactは自称ライブラリ、vueとangularは自称フレームワーク
公式サイトのトップを見た限り
302:デフォルトの名無しさん
19/02/13 23:20:38.84 dfUEINu60.net
>>289
それを言ったら、jQueryで使うのはピュアJavaScriptだし
Angularで使うTypeScriptやReactで使うJSXは
ピュアJavaScriptではないけどさ
303:デフォルトの名無しさん
19/02/13 23:44:57.61 D91GFqhb0.net
react捨てるにしてもreduxの考え方は学んどいて損はないよ。
304:デフォルトの名無しさん
19/02/13 23:51:17.06 jwc/pNVH0.net
hook apiとcontext apiデフォで使えるようになるから個人ユースの規模ならredux必要なくなるよ。
305:デフォルトの名無しさん
19/02/14 08:50:15.44 4Gf71Z9ua.net
>>284
Angularと比べるならVueとよりもNuxtと比べる方が合理的だな
306:デフォルトの名無しさん
19/02/14 08:51:45.88 4Gf71Z9ua.net
>>286
コーディングはすべてTypeScriptだけどね
307:デフォルトの名無しさん
19/02/14 09:00:56.39 kPGufiyx0.net
ものは試し
初心者だがAngular勉強してみるわ
308:デフォルトの名無しさん
19/02/14 11:29:40.87 MlsuSDTjr.net
reactにしとけ
309:デフォルトの名無しさん
19/02/14 12:15:57.21 nZj2/pMr0.net
React勉強したがやっぱりウェブサイトの殆どには適用できない技術だな
例えばニュースサイトにReactを導入するメリットはないだろう
310:デフォルトの名無しさん
19/02/14 12:30:22.33 mbps9XCNa.net
融通が利くのはVue
311:デフォルトの名無しさん
19/02/14 12:39:53.13 HVhxRx5Ma.net
MVC+Vueが世界最強
312:デフォルトの名無しさん
19/02/14 12:43:26.84 QUGQ3bvOr.net
>>299
画面遷移がなくなるからメリットはありだろ
313:デフォルトの名無しさん
19/02/14 13:14:13.76 kPGufiyx0.net
Reactにした
Angularバージョンで詰みそうになる感じだし
学習リソース少ないし
314:デフォルトの名無しさん
19/02/14 13:22:31.29 MhXZGfUyd.net
潰しの効かなさを除けばAngularが一番いいと思う。ガッチリした設計な分だけ迷わずに使えるしプロジェクト管理もしやすい。
ただ習得してもキャリア的なメリットが薄そうだから自分で選択する気になれん。
315:デフォルトの名無しさん
19/02/14 13:27:23.06 DBAMfZpK0.net
当分は問題ないだろうけどAngularは将来的にはどうなるんだろうな
同じくGoogle製でしかも競合となるFlutter/Hummingbirdのリリース準備が進んでるみたいだし
316:デフォルトの名無しさん
19/02/14 14:07:13.01 MlsuSDTjr.net
世の中的にはReactが主流
317:デフォルトの名無しさん
19/02/14 14:42:13.00 nZj2/pMr0.net
>>302
画面遷移をなくせなんて誰からも要望来てないんだが？
318:デフォルトの名無しさん
19/02/14 14:43:08.15 nZj2/pMr0.net
VueもReactもAngularも将来性はないよ
近い将来にWebComponentに
置き換わることが決定している
319:デフォルトの名無しさん
19/02/14 14:51:21.14 kPGufiyx0.net
>>308
逆って聞いたけど
320:デフォルトの名無しさん
19/02/14 15:15:15.70 nZj2/pMr0.net
逆って今WebComponentがないのに
今WebComponentを使ってるわけ無いだろ
321:デフォルトの名無しさん
19/02/14 15:35:58.92 MlsuSDTjr.net
>>307
お前バカだろ？
だいぶバカだな
322:デフォルトの名無しさん
19/02/14 18:38:55.70 MhXZGfUyd.net
結局ピュアjavascriptを真面目に身につければOK？
323:デフォルトの名無しさん
19/02/14 18:54:26.61 nZj2/pMr0.net
ピュアJavaScript + jQueryだな
URLﾘﾝｸ(w3techs.com)
73.8%に増加。今でもjQueryのシェアは圧倒的で伸び続けている。
324:デフォルトの名無しさん
19/02/14 18:58:38.20 pR+IykPzM.net
どうせwpだろｗｗｗ
railsが使われてるからrubyが死にきれないのと似たようなもんｗｗｗ
325:デフォルトの名無しさん
19/02/14 19:03:26.19 nZj2/pMr0.net
だから「本当にやりたいこと＝WordPressでできる範囲のこと」なんだから
フレームワークもいらんし、どうせjQuery使われてるからjQueryでいいってことなんだよ
326:デフォルトの名無しさん
19/02/14 19:04:04.42 nZj2/pMr0.net
需要と供給
いくらすごいことができるようになっても
求められてないんだよ。
327:デフォルトの名無しさん
19/02/14 19:07:18.73 pR+IykPzM.net
間違ってないと思うがなぜwpのスレに籠らずこんなスレ来て啓蒙活動してるのかｗ
他人が勉強するのが不安で怖いんだろ？ｗｗ
そんな女の腐ったようなセコい性格だからいつまでたっても童貞なんだよｗｗｗ
328:デフォルトの名無しさん
19/02/14 19:08:13.46 nZj2/pMr0.net
wpを持ち出してきたのお前じゃん？
頭大丈夫か？
329:デフォルトの名無しさん
19/02/14 19:14:23.47 pR+IykPzM.net
論理に破綻はないが？wp圧倒してるの事実だし。現状に安穏としたいならしてれば？俺らは勉強するから、ってこと。図星刺されて恥ずかしくなっちゃったのかなｗ
お前のやってることってテストの前に勉強してるやつをガリ勉・ダサいとレッテルはって集団でみんなで堕落しようとセコい行動する女みたいなんだよｗ
男でそれじゃダメだよ。
330:デフォルトの名無しさん
19/02/14 19:14:29.36 fSoz/vTj0.net
angularは勧めんな。railsもそうだがああいう丸ごと全部なものになれると
それ以外なんもできなくなる。
331:デフォルトの名無しさん
19/02/14 19:17:17.50 MlsuSDTjr.net
wpしか使えない底辺カスは死ぬまでjquery使ってろ
332:デフォルトの名無しさん
19/02/14 19:20:32.23 nZj2/pMr0.net
>>319
> 論理に破綻はないが？wp圧倒してるの事実だし。
wp圧倒してるの事実である根拠は？
事実だとしてそれがjQueryにどれだけ影響してるの？
wpのシェアなんてウェブ全体からすればたいしたことないじゃない
333:デフォルトの名無しさん
19/02/14 19:21:17.93 DfU+cSuaa.net
新しいフロントフレームワークが出た時に丸ごとすげ替えれるならなんでもいいよ
俺はMVCがベストバランスの正解だと思うがね
334:デフォルトの名無しさん
19/02/14 19:22:01.34 nZj2/pMr0.net
backboneを勉強した人は無駄になった。
Angularも1系を勉強した人は無駄になった。
jQueryは登場してから13年使われ続けている。
これが現実やで
335:デフォルトの名無しさん
19/02/14 19:25:35.68 OfZpiUzn0.net
wpの保守死ぬほど大変だけどな。てかフレームワークとwpは全く別物だろうよ。ブログのフレームワークと言えない事も無いが。
336:デフォルトの名無しさん
19/02/14 19:38:24.66 pR+IykPzM.net
>>322
ビルトインされてるよ。テーマによってはwpビルトイン版と競合を避けるため他のバージョンを別に導入する場合もある。
そしてwpのシェアはcms中では60%、全Web中では33%
だからwp除くならjQueryは40%程度だなｗ
337:デフォルトの名無しさん
19/02/14 19:43:27.31 nZj2/pMr0.net
> だからwp除くならjQueryは40%程度だなｗ
圧倒的シェアじゃないか！
338:デフォルトの名無しさん
19/02/14 19:50:59.92 pR+IykPzM.net
最初からシェア小さいとは言ってないだろｗ
増加してるのはwpのシェア増につられてだろうと予測しただけ。
おそらく合ってるなｗ
jQueryバカが威張るのは滑稽。
339:デフォルトの名無しさん
19/02/14 20:14:34.64 MlsuSDTjr.net
jqueryしか使えないバカが多い
バカのくせにバカを賛美している
340:デフォルトの名無しさん
19/02/14 20:27:26.21 nZj2/pMr0.net
所で仮想DOMのアプローチって本当に速いのかな？
仮想DOMはDOMを触らないって言うけど、
結局最終的な形にするためにDOMを構築するでしょう？
そのときに要素を作ったり削除したり
そんな事しないで、CSS使って要素を隠したり表示したほうが速いない？
jQueryはDOM操作が得意なわけだけど、DOMを作ったり削除したりするんじゃなくて
classを変更して見た目を変えることで擬似的にDOMが表示されたり消えたりするって
いうのがベストプラクティスだと思ってる。この場合はDOMの構築をやらないので
仮想DOMのアプローチよりも速いんじゃない？
341:デフォルトの名無しさん
19/02/14 20:30:52.74 RyxU72PZ0.net
cssのが早いのは当たり前だろ…
お前、こういうスレ来るのは10年早いよ。
真摯に勉強しろやマジで。スレタイ読まずに荒らしてないでさぁ
342:デフォルトの名無しさん
19/02/14 21:08:57.94 kPGufiyx0.net
VuexとReduxって難易度変わらない？
343:デフォルトの名無しさん
19/02/14 21:10:34.79 nZj2/pMr0.net
どちらも単に面倒くさいだけじゃないの？
344:デフォルトの名無しさん
19/02/14 21:11:54.44 nZj2/pMr0.net
正直Reduxとか使うよりも、カスタムイベントを使ったほうが楽だと思う
345:デフォルトの名無しさん
19/02/14 21:25:16.30 MlsuSDTjr.net
マジでお前来るなよ
スレチクソキチガイが
テメーの妄想なんかどうでもいいんだよ
勝手にjqueryスレ立ててそっちでやれバーカ
346:デフォルトの名無しさん
19/02/14 21:53:19.44 nZj2/pMr0.net
だが断る
347:デフォルトの名無しさん
19/02/15 07:48:37.76 ayjwUPM20.net
>>304
そういう観点ならNuxtでもいいと思う
348:デフォルトの名無しさん
19/02/15 08:12:30.75 +Jrl5jTr0.net
Vueが最強なんじゃね？
仕事ならReact
349:デフォルトの名無しさん
19/02/15 08:39:56.97 5wBlw8GS0.net
仕事でもnuxtつこてるわ
angularとreactは敷居が高め
他のメンバーが嫌がるのよ
350:デフォルトの名無しさん
19/02/15 08:56:20.31 EFNDTiKGa.net
そういやVueでもjsx使えるとかVueの和書の一番厚い本に書いてあったな
351:デフォルトの名無しさん
19/02/15 09:54:44.63 Nwwq6bubM.net
reactのために作ったってだけである種類の関数の入れ子をxml風に記述できるというだけの独立した仕組みだからreact関係なく使えるよ。
352:デフォルトの名無しさん
19/02/15 13:09:17.41 YF3F5Mzod.net
>>337
そうなのか。興味湧いてきたのでちょっとNuxt試してみます。
353:デフォルトの名無しさん
19/02/15 19:10:03.96 s9lB6bHor.net
ReactやVueやる奴らは当たり前だがフロントデザインやUXできるんだよな？
354:デフォルトの名無しさん
19/02/15 19:14:19.75 uyGcnsGR0.net
>>330
仮想domのメリットは最終的にはリアクティブ。その例で言えばjQueryは要素を消すのに.hide()して直接domを操作するが、リアクティブでは単に変数をfalseするだけになる。
複雑な入力フォームも恐ろしく作りやすくなるから、一度vueの公式見るといい。
355:デフォルトの名無しさん
19/02/15 19:47:12.24 fQG3bb7RM.net
勉強しなくていい言い訳探しに来てる奴に何言ってもムダ
356:デフォルトの名無しさん
19/02/15 21:10:18.28 Tr9ixmy70.net
>>344
> その例で言えばjQueryは要素を消すのに.hide()して直接domを操作するが、
あー、それがお前の根本的な間違いなんだよ。
お前っていうか、世間一般？使い方間違えてるんだよね。
そういうDOM操作なんてしません。
jQueryでは単にHTMLのclassの（例えば）activeをdeactiveにするだけになる。
複雑な入力フォームも作れるし、classを変えるだけで全く違った表示にすることができる
そのフォームを使ってる間JavaScriptは全く使用しない。
デザイナが自由に好きなデザインで作ることができる。
そしてjQueryではclassの値を変えるだけになる。
357:デフォルトの名無しさん
19/02/15 21:28:10.41 LmytZ3o2d.net
>>343
むしろそっちのが専門や
358:デフォルトの名無しさん
19/02/15 21:31:08.33 fQG3bb7RM.net
jQueryのhideはdisplay: noneだろ。
active、deactive（笑）に至っては意味不明。
jQueryではそういうときはactiveクラスをtoggleClassで付けたりはずしたりするんであって、active外してdeactive（笑）つける、deactive（笑）外してactive付ける、なんてマヌケなことはしません。
やっぱりね、自分が勉強したくないもんだから他人の足を引っ張ろうとするような女の腐ったような童貞は自分が上げてるライブラリもまともに使いこなせないｗｗミジメ過ぎｗｗｗｗｗ
359:デフォルトの名無しさん
19/02/15 21:33:20.85 kkRd+/gL0.net
jQueryからreactならそこまで乗り換えコストかからんと思うけどな。
360:デフォルトの名無しさん
19/02/15 21:46:27.22 s9lB6bHor.net
>>347
合格
361:デフォルトの名無しさん
19/02/15 21:48:11.36 Tr9ixmy70.net
>>348
ん？お前俺が言ったことと大差ないよな？
activeクラスを 付けるor 外す ことで表示の切り替えを行うから
そんなことでDOM操作なんてしないってことだろ？
でそれが>>330で書いたことにつながるんだよ。
仮想DOMは最終的にDOM操作をするから遅くなるが、
jQueryではCSSによって見た目を切り替えるだけだから速いってこと
362:デフォルトの名無しさん
19/02/15 21:51:50.27 zC296ldL0.net
いやDOM APIを通じて操作するんでしょ
363:デフォルトの名無しさん
19/02/15 22:06:11.07 Tr9ixmy70.net
>>352
そりゃVueやReactだって最終的にはDOM APIを通じて操作するよ
ただしその操作の内容を、DOM要素の削除や追加じゃなくて
クラス名を変えて表示を切り替えるだけにすると速いってこと
364:デフォルトの名無しさん
19/02/15 22:07:28.91 NXuVhChr0.net
Angularの方が難しいの？ Reactの方が自由に構成決めたりコーディングしたり出来る分、
自分で決めなきゃいけない事が多くなって逆に難易度高いって聞いたけど。
Angularの方が環境構築も規約も全部世話してくれるから楽だって聞いたからAngularから入ったんだけど。もしかして騙された？
365:デフォルトの名無しさん
19/02/15 22:10:09.24 I8iEDAq80.net
>>354
英語などの単語の暗記が得意だったならangular
数学が得意だったならreact
366:デフォルトの名無しさん
19/02/15 22:14:49.66 fQG3bb7RM.net
さすがjQueryバカ。伊達に名前にバカって付いてないな。
クラスの付け外しも厳然たるDOM操作。
そんなことも分からないとは…使われるjQueryもかわいそうだ。
367:デフォルトの名無しさん
19/02/15 22:20:03.31 I8iEDAq80.net
そもそもjQueryのコア機能はDOM操作なんだが…
DOM操作しないならjQuery要らねーよ。
贔屓のライブラリの存在理由否定してどうする。
368:デフォルトの名無しさん
19/02/15 22:22:45.45 Tr9ixmy70.net
>>357
DOM操作のうち、class属性を変えるだけにするということ
そしてCSSでブラウザにネイティブ処理させるから速いんだよ
要素の追加や削除は必要最小限にするのが鉄則
369:デフォルトの名無しさん
19/02/15 22:29:21.05 Tr9ixmy70.net
>>354
自分がやりたいことと、フレームワークが提供してくれる機能とのバランスだよ
業務アプリみたいに複雑なインターフェースのアプリをガッツリと大量（＝画面数が多い）に
作らなきゃいけないならAngularがいいだろうけど、そうでもないなら
Reactで適当にデータ管理してやれば楽ってこと
Angularはいろんなことを面倒見てるけど、そこまでやることないじゃん？って思うならReact
更に言うならウェブサイトみたいなものはjQueryで十分ってこと
370:デフォルトの名無しさん
19/02/15 22:30:21.14 fQG3bb7RM.net
> ネイティブ処理させるから速いんだよ
だったらネイティブのDOM API使うわｗ
You Don't Need jQuery!
URLﾘﾝｸ(blog.garstasio.com)
371:デフォルトの名無しさん
19/02/15 22:33:24.44 Tr9ixmy70.net
>>360
それもバランスの問題だな。
そこ見ても分かるだろ？いずれの例もjQueryの方が短く書けている
開発効率の高さがあるからjQueryのほうが良い訳
372:デフォルトの名無しさん
19/02/15 22:34:33.79 fQG3bb7RM.net
せっかくだから日本語版
jQueryは必要ない（You Don't Need jQuery）
URLﾘﾝｸ(github.com)
373:デフォルトの名無しさん
19/02/15 22:37:44.38 Tr9ixmy70.net
フレームワークの欠点は単純なウェブサイトでは
生産性を落とすという大きな問題があるってこと
374:デフォルトの名無しさん
19/02/15 22:38:05.96 s9lB6bHor.net
URLﾘﾝｸ(i.imgur.com)
375:デフォルトの名無しさん
19/02/15 22:38:49.90 Tr9ixmy70.net
ついでだから、jQueryは必要ない（？）から一例を抜粋
8.7 slideToggle
スライドを伴って、エレメントの表示・非表示を切り替えます。
// jQuery
$el.slideToggle();
// Native
let originHeight = '100px';
el.style.transition = 'height 3s';
let { height } = el.ownerDocument.defaultView.getComputedStyle(el, null);
if (parseInt(height, 10) === 0) {
el.style.height = originHeight;
}
else {
el.style.height = '0px';
}
376:デフォルトの名無しさん
19/02/15 22:41:31.02 fQG3bb7RM.net
css tricksのYou Might Not Need jQuery
URLﾘﾝｸ(css-tricks.com)
その翻訳
URLﾘﾝｸ(coliss.com)
377:デフォルトの名無しさん
19/02/15 22:43:21.30 s9lB6bHor.net
DOMにノードを追加すると、DOM APIと直接対話するVanillaを1回呼び出すだけで済みますが、jQueryは多くの操作を実行します（スタックが長すぎて画像に収まりません）。違いは明らかです。
Vanilla：4ミリ秒
jQuery：95.3ミリ秒
Vanilla Javascriptは、追加時のjQueryよりも約25倍高速です。
378:デフォルトの名無しさん
19/02/15 22:44:41.61 Tr9ixmy70.net
>>367
いや、だからそんなことをしないで、クラスの書き換えだけを
やることで高速化できるって言ってるんだよ
話ついてきてね
379:デフォルトの名無しさん
19/02/15 22:48:19.07 zC296ldL0.net
>>359
使い分けって言いながらフレームワーク要らないって言うから意味不明になるんだよ
「自分の仕事では」要らないって話だろ？
380:デフォルトの名無しさん
19/02/15 22:51:08.66 s9lB6bHor.net
>>368
class追加するだけでもjqueryより10倍速いんですが？
URLﾘﾝｸ(i.imgur.com)
381:デフォルトの名無しさん
19/02/15 22:51:38.93 7RVZ/4z70.net
削除はともかく、追加がクラスの書き換えだけの訳ないわな。その書き換える対象がまだ無いんだから。
382:デフォルトの名無しさん
19/02/15 22:51:58.45 fQG3bb7RM.net
jQueryはネイティブに比べて遅い上にサイズも大きすぎる。
画像でもないのに数十kBとかアホか。
短く書けりゃいいのならnanoなど代替ライブラリもある。
nanoのコード例：
$(".someClass").css("background-color:green;").html("Hello World");
$('#c').animate('2.3', '1.2','0','1','1','0','0', '0','0','1').css('background-color:red').text('Hello');
$("#a").on("click", function(){
$("#someDiv").css("background-color:green;color:#fff;");
})
nanoは0.6kB。
jQueryは100倍もコード容量かけて何やってんのｗｗｗｗｗ
383:デフォルトの名無しさん
19/02/15 22:54:11.02 I8iEDAq80.net
ボコボコでワロタｗ
我が物顔でスレチ荒らしするからこうなるｗｗ
384:デフォルトの名無しさん
19/02/15 22:54:50.30 Tr9ixmy70.net
>>372
じゃあnano使えば良いんじゃないですか？
フレームワークよりも大幅に小さいし
385:デフォルトの名無しさん
19/02/15 22:56:00.99 Tr9ixmy70.net
ウェブサイトではフレームワークは重すぎで生産性を下げるという
大きな問題があるが、jQueryやnanoはDOM APIの冗長性を省くだけだから
生産性は上がるしか無いというのが大きなメリットなんだよ
386:デフォルトの名無しさん
19/02/15 22:59:32.27 fQG3bb7RM.net
まあjQueryがいらないのは確かだね。
要素のstyle操作程度ならなおさらね。
「DOM操作しない方がいい」って言ってたし、じゃあDOM操作ライブラリのjQueryはいらないねｗ
え、やっぱりDOM操作したい？そして短く書きたいって？
100倍軽いnanoがあるよｗ
387:デフォルトの名無しさん
19/02/15 23:04:02.60 Tr9ixmy70.net
nano信者か・・・
388:デフォルトの名無しさん
19/02/15 23:05:15.16 Tr9ixmy70.net
そういやzeptoとかもあったけど、
今までの経験上、軽いだけの代替ライブラリは
結局本家を超えることって無いんだよな
nanoが普及すると良いね
389:デフォルトの名無しさん
19/02/15 23:09:04.09 ca0WBun30.net
すまん、ガチで話についていけてないんだが、>>351でjQueryは速いって書いてあるからjQueryは速いのか！って思ってたんだけど結局遅いの？
390:デフォルトの名無しさん
19/02/15 23:11:01.96 zC296ldL0.net
何をもって速いとするかに依る
391:デフォルトの名無しさん
19/02/15 23:11:48.08 ca0WBun30.net
>>380
速さを求めるときに使うもの？
392:デフォルトの名無しさん
19/02/15 23:12:36.21 fQG3bb7RM.net
GitHubがjQuery辞めたので URLﾘﾝｸ(ushirock.hateblo.jp)
jQuery が DOM 操作の際に eval() を多用しているため CSP を safe モードで使えないらしい
これは jQuery の核になる部分の仕様らしく、 .html() はどんな時でも任意のコードを実行する可能性があると
やっぱり jQuery といえば Sizzle でのセレクタ解析が遅いとか（querySelectorが使える場合優先されるらしい）ネイティブへの置き換えとかに目が行きがちだけどもこういう深い話でのデメリットもあるんだなと
393:デフォルトの名無しさん
19/02/15 23:14:27.13 Tr9ixmy70.net
>>379
jQueryが速いなんて言ってないんだが？
ファイルサイズではフレームワークよりも小さいから
初回ダウンロードは速いだろうけど。
速いって言う話はDOM操作で要素を消したり作ったりするよりも
classを変更するだけにしてCSSで表示したり見えなくしたりするほうが
速いだろうってこと。
394:デフォルトの名無しさん
19/02/15 23:15:42.26 fQG3bb7RM.net
jQuery。それは、
・遅い
・重い
・アンセキュア
なDOM操作ライブラリ。
395:デフォルトの名無しさん
19/02/15 23:16:58.62 Tr9ixmy70.net
>>382
ソースコードざっと見たけど、evalが見当たらないんだけど何行目にある？
URLﾘﾝｸ(code.jquery.com)
396:デフォルトの名無しさん
19/02/15 23:17:08.57 NXuVhChr0.net
jQueryを使うのって、速さ云々より一つのコードがどんな環境でも同じ様に動くって所なんじゃないの？
ブラウザの種類やバージョンでJavascriptの挙動の違いがあるから、それを吸収する為にjQueryを使うんじゃない？
397:デフォルトの名無しさん
19/02/15 23:17:55.89 zC296ldL0.net
>>381
はっきり言ってjQueryが遅いとは思わない
熟練した人が地道に管理すれば十分速い
それが手間じゃねぇの？ってのがフレームワークの意義
398:デフォルトの名無しさん
19/02/15 23:21:18.07 Tr9ixmy70.net
>>384
jQueryってDOM APIを使ってるだけなのに
なんでアンセキュアになるの？
399:デフォルトの名無しさん
19/02/15 23:21:36.55 ca0WBun30.net
>>383
そうか、なんかすまん。
>仮想DOMは最終的にDOM操作をするから遅くなるが、
>jQueryではCSSによって見た目を切り替えるだけだから速いってこと
この部分読んで仮想DOMは遅くてjQueryは速いのか！って解釈しちゃったんだが仮想DOMに比べて速いだけでjQueryも速くないんだな。
400:デフォルトの名無しさん
19/02/15 23:25:42.00 ca0WBun30.net
>>387
>>367の結果だけ見ると遅すぎ(10回やると1秒！？)って思っちゃったんだが……
webは基本的には静的コンテンツだから気にならない世界なのかな。
とりあえず俺にはこのスレの会話を理解する能力が足りないっぽい。
401:デフォルトの名無しさん
19/02/15 23:28:54.96 ca0WBun30.net
まあ1つの処理に4ミリ秒って時点で衝撃的な遅さだしweb開発の世界はそんなもんなのか。
402:デフォルトの名無しさん
19/02/15 23:31:51.99 I8iEDAq80.net
jQuery使うと100ミリ秒になるけどなｗ
403:デフォルトの名無しさん
19/02/16 00:34:30.68 oKtXVOCjd.net
vue.jsが
やたらめってら、もてハヤサれる昨今だけど
ぶっちゃ毛v-forが仕様としてオワッテると思うわ。
それとuidの生成パターンをC言語なら「ポインターが理解でないワケ」や
「ポインター徹底攻略」、、、JAVAならデザイパターン本みたいな
分厚い本で説明しなきゃ
いけないのに、それを全くやってないよな。
俺が考えるvue.jsが広まらないワケだよ。コンポーネントをどうユーザーが
受けとるべきかも、簡単な再帰などを使ってイラストレートしなきゃいけないのに
これも全くやってない。細々としたシステムは売り込んでるけど
vueの長所が全くされてない
404:デフォルトの名無しさん
19/02/16 00:34:57.77 fcnsYPNW0.net
早い遅いじゃなくて開発効率の話だろ。domを直接指定して操作云々はもう止める、最小限にするて事。今後確実にそうなるのは皆分かってると思うが。
405:デフォルトの名無しさん
19/02/16 00:44:30.53 HVh9Xg4td.net
実行速度の話をしてる人たちに、いきなり開発効率の話をしだすのは草。なんの関係もないじゃんw
406:デフォルトの名無しさん
19/02/16 01:34:13.23 SPTGalft0.net
実行速度については、DOM要素を作成したり削除したりするよりも
CSSで表示したり隠したりしたほうが速いんじゃないかってだけのこと
それをやるにはVue/React/AngularよりもjQueryの方が楽ってこと
DOM操作がネイティブよりも速いなんて話はしてない。
CSSによる表示切り替えの方が速いって話をしてる。
そのCSSによる表示切り替えを楽にやる（開発効率が良い）のは
jQueryってだけのこと
407:デフォルトの名無しさん
19/02/16 01:47:37.10 P5gjDjW+0.net
DOM要素の追加削除とCSSの表示切り替えって役割が違わね？
408:デフォルトの名無しさん
19/02/16 01:49:25.92 P5gjDjW+0.net
CSSの表示切り替えは既に存在する要素に対して行うのに対してDOM要素の追加は動的に要素を追加するためにやるもんだと思うんだが。
この2つは比べるべきものなの？
409:デフォルトの名無しさん
19/02/16 01:59:26.44 P5gjDjW+0.net
スレタイの3つとかはSPAのような高性能なブラウザアプリを作成するものでしょ。例えばofficeとかslackとか。CSSの切り替えだけでいけるの？
410:デフォルトの名無しさん
19/02/16 02:11:14.67 yZTjSyit0.net
相手せんでええよキチガイだから。
411:デフォルトの名無しさん
19/02/16 04:00:16.99 H80q57B70.net
>>354
難しいというより学習コストが高い＝最低限として覚えなきゃいけない事が多い
その反面必要な機能をサードパーティーから探してくる必要性がかなり低い
412:デフォルトの名無しさん
19/02/16 04:05:31.34 H80q57B70.net
>>379
普通にUIとして使う分にはそんなに気になるほどの事でもないけど
Canvasに連続的に描画とか行う場合はダイレクトにその遅さが目立つってくらいかな
413:デフォルトの名無しさん
19/02/16 06:51:31.57 fcnsYPNW0.net
早いからじゃなくて便利だからjQueryを使うんだろ。なんで今更速度の話になってんの？
414:デフォルトの名無しさん
19/02/16 07:10:24.28 H80q57B70.net
最近ブラウザでWebRTCとかやるのもわりとあるケースだし遅いってのは無視できない問題でもあるよ
415:デフォルトの名無しさん
19/02/16 07:20:20.26 Ka3Sv0NV0.net
>>403
jQueryは仮想DOM操作より早いと信者が言い出したから。
416:デフォルトの名無しさん
19/02/16 08:04:12.49 SPTGalft0.net
>>405
デマ乙
>>330を見れば分かるが仮想DOMよりも
classの変更で表示・非表示の切り替えをしたほうが速いって言ってる
417:デフォルトの名無しさん
19/02/16 08:58:01.91 P5gjDjW+0.net
もう一度聞くけど、classの変更でできることって限られてるでしょ？見た目の操作だけかな？
それが仮想DOMより速くてもどうしようもなくないか？役割が違うんだから。
なんか自分の間違いを認めたくないから無理やり話をすり替えようとしてるようにしか見えないんだが…
418:デフォルトの名無しさん
19/02/16 09:01:46.50 mve
419:ZudXk0.net
420:デフォルトの名無しさん
19/02/16 11:06:01.11 fcnsYPNW0.net
スレタイから逸脱しすぎてると思ったらjQueryと比較してる奴がいるのか。。もう何年
421:も前に通り過ぎた話題だぞ。前見ようぜ。
422:デフォルトの名無しさん
19/02/16 11:13:52.65 jR4qOrfsr.net
ReactとかVueすら使えない超低レベルなクソジジイが騒いでるだけだから
423:デフォルトの名無しさん
19/02/16 11:14:50.85 SPTGalft0.net
>>407
> もう一度聞くけど、classの変更でできることって限られてるでしょ？見た目の操作だけかな？
要素の追加削除の代わりに見た目を変更するっていうのは、
単に要素を追加削除するコストだけではなく
イベントハンドラの設定のコストも減らせる
もともとjQueryはデリゲートが簡単にできるから、要素が増えたり減ったりしても
イベントハンドラは最初に一回だけ設定すれば良いんだが、
それを使わなくても例えば要素のonclick属性とかに直接やる場合でも
要素が追加したときに新たにイベントハンドラを設定しなくてすむ
仮想DOMではDOM操作を最適化して必要な場合だけ実行するが
速度の話をするならそもそもDOM操作自体を減らそうという発想にしたほうが良いと思う
要素ごとにイベントハンドラを設定するよりも、
要素の親に一つだけイベントハンドラ設定したほうがいいわけだし
424:デフォルトの名無しさん
19/02/16 11:35:47.92 H80q57B70.net
こっちでやったら？
Webフロントエンドで脱jQueryを目指すスレ
ｽﾚﾘﾝｸ(tech板)
425:デフォルトの名無しさん
19/02/16 11:38:28.40 auHH3gBua.net
使える使えないと使う使わないは別のこと
jQueryが殆どの場合最適解でSPAが勝てる領域はかなり狭いという事実を見失っちゃいかん
426:デフォルトの名無しさん
19/02/16 11:41:22.10 SPTGalft0.net
SPA、シングルページアプリケーションであって
シングルページウェブサイトじゃないからな
アプリケーションの時点で、ならネイティブアプリにしろよって
言われる時代
427:デフォルトの名無しさん
19/02/16 11:52:58.50 R2hmaITu0.net
勝手にそんな時代を作るな
428:デフォルトの名無しさん
19/02/16 11:56:31.80 H80q57B70.net
まぁ正直フレームワークは知らなくてもいいかも知れんがNodeを知らないと確実に困る時代にはなってくると思う
429:デフォルトの名無しさん
19/02/16 12:00:35.69 auHH3gBua.net
ネイティヴアプリは環境差異とデプロイメントがめんどくさいんだよね
dockerがGUIをサポートしてくれたら乗り気になるかもしれんがな
430:デフォルトの名無しさん
19/02/16 12:09:05.56 SPTGalft0.net
>>417
それはウェブでも変わらん。カメラ使おうと思ったら
ブラウザごとに使うAPIは違うし、端末ごとに対応してる
解像度も違うし散々だったぞ
dockerってLinuxの話してる？ それならSnapsやFlatpakなどが登場してる。
Dockerはあくまで開発者向けで自分で作ったアプリをデプロイするときに使うもの。
一般ユーザー向けにアプリを配布するならSnapsなどを使う
GUI対応でディストリ非依存のパッケージ管理システム
431:デフォルトの名無しさん
19/02/16 12:16:07.61 H80q57B70.net
>>417
ネイティブの面倒なところはそこよりも
OSの差異で動かなくなったりするところだな特にiOSとか
432:デフォルトの名無しさん
19/02/16 12:19:58.87 auHH3gBua.net
>>418
Snapsってdockerのように依存関係や実行時の環境もカプセル化してくれんの？
433:デフォルトの名無しさん
19/02/16 12:34:18.62 msvpDp2N0.net
>>419
その差異をブラウザは吸収できないんだよね
だからみんなネイティブアプリにする
434:デフォルトの名無しさん
19/02/16 12:41:53.08 R2hmaITu0.net
みんなって誰だよ
勝手に決めるな
435:デフォルトの名無しさん
19/02/16 12:43:59.75 P5gjDjW+0.net
>>411
具体例をお伝えした方がいいのだろうか？
例えばサーバーのDBに対して検索かけてとってきた要素を並べてコンテンツだすとかclassだけでなんとかなるの？
そもそも要素を出したし消したりでなんとかなるような簡単なものにReactとか使わないものじゃね？
436:デフォルトの名無しさん
19/02/16 12:47:43.95 P5gjDjW+0.net
サービス提供する側としてはネイティブよりSPAの方がよいケースはままあるでしょ。
例えばインストーラーが不要、そもそも技術者がいない、今までの資産をそのまま流用できる、とかとか。
ハードを
437:限定しないソフトウェアの提供形態って殆どの場合は都合できまるもんだと思う。
438:デフォルトの名無しさん
19/02/16 12:50:25.75 0+4MW20ta.net
ネイティブはストアにリリースすんのがイチイチめんどくさい
439:デフォルトの名無しさん
19/02/16 13:05:39.77 jR4qOrfsr.net
jqueryしか使えない無能の自己紹介はいらん
消えろカスジジイ
440:デフォルトの名無しさん
19/02/16 13:13:23.51 dSQ6SPUO0.net
Angular習得した後にjQueryで書かれたコード見たら吐き気がしてくるわ。
「こんなコードわざわざ書かなくても取ってきたデータバインディングすりゃ良いのに」って思う箇所が多々ある…。
まぁ、古いブラウザでも動くようにしなきゃならないからjQuery使ってんだけどね。
441:デフォルトの名無しさん
19/02/16 13:19:34.25 H80q57B70.net
>>427
Windows7のサポートが切れればなぁ
442:デフォルトの名無しさん
19/02/16 14:02:04.13 msvpDp2N0.net
>>427
お前が書くコードがクソなだけｗ
443:デフォルトの名無しさん
19/02/16 16:10:27.79 dSQ6SPUO0.net
>>428
サポート切れてても「壊れてないから」とか「投資できる余裕がない」とか「基幹システムが新しいOSに対応していないから」って理由で
古いOSと機械を使い続ける客もいるんだよなぁ。あんまりよろしくは無いんだけど。
>>429
jQueryベースでデータバインディングみたいなコード書けるん？
書けるなら書き方教えてくれや。こちとら嫌々でもjQueryとは付き合っていかなきゃなんねーんだよ。
444:デフォルトの名無しさん
19/02/16 16:16:01.06 sYjKK7tj0.net
イベント使え
445:デフォルトの名無しさん
19/02/16 17:30:33.50 fcnsYPNW0.net
>>430
使ったことないが、backboneやKnockoutやらのIE7でも動くライブラリ使ってみれば？ただ今更勉強する意義を考えると辛いなあ。。
446:デフォルトの名無しさん
19/02/16 18:08:11.34 auHH3gBua.net
旧ブラウザサポートはお高くなりますよ？
これでほとんどの客が黙る
447:デフォルトの名無しさん
19/02/16 19:11:18.01 LE6s3aZE0.net
やっすい案件ほどクソ要求してきやがる。
448:デフォルトの名無しさん
19/02/16 19:38:01.61 H80q57B70.net
>>430
少なくともイントラではなグローバルサイトではサポート切れたOSの対応は打ち切っていいだろ
449:デフォルトの名無しさん
19/02/16 19:40:47.09 msvpDp2N0.net
Androidだとサポート切れといっていいOSはどれ？
450:デフォルトの名無しさん
19/02/16 20:08:25.91 4RfOpqIfr.net
>>433
最新バージョンのreact使ってるけどIE11で問題なく動作しとる
451:デフォルトの名無しさん
19/02/16 21:03:12.87 H80q57B70.net
正直互換性の点ではIE11よりもEdgeの方が癖があるんだよね
まぁEdgeもChromiumベースになる計画があるらしいしEdgeのChromium化とWindows7のサポート打ち切りが来ればパブリックサイトは随分シンプルになるんじゃないかと思う
452:デフォルトの名無しさん
19/02/16 22:09:54.11 gLKxbWo30.net
chromiumになってもなんかしらイレギュラーがありそう
信用できない
453:デフォルトの名無しさん
19/02/17 08:20:58.26 O/E0SKNM0.net
フロントエンドなんてそんなもんだとしか言いようがない。
454:デフォルトの名無しさん
19/02/17 09:26:47.38 x12h9xDW0.net
逆に言えば進化の余地ありありと言うこと。でもフレームワーク競争もひと段落して数年は安定じゃないかな。ブラウザもChromiumとSafariに収束されつつあるし。あとはiOS safariにpush通知実装されればなあ。
455:デフォルトの名無しさん
19/02/17 09:30:51.46 Y22Zw0Bq0.net
プログラマには、Apple機がなくなった方が楽になると思われている。
IEが消滅して言ったのと同じ状況がApple機に対しても起きつつあると思う。
iPhoneは売れなくなった。
456:デフォルトの名無しさん
19/02/17 09:44:50.06 E0TCVuWu0.net
フロントエンドは端末とブラウザの進化の影響をもろに受けるからねぇ…。
クロスプラットフォームの分野でも、SPAが技術的に枯れる前にどんどん新しいフレームワーク出て来るからな。最近だとFlutterとか。
SPAだけでも選択肢多いのに、xamarinだのcordovaだのFlutterだのと。
こっちとしては「クロスプラットフォームアプリ開発するなら結局どれ選べばいいんだよ」的な状態だわ。
457:デフォルトの名無しさん
19/02/17 09:48:46.68 Y22Zw0Bq0.net
結局、大きい組織が作ったものを使っていくようになるんだろう。
458:デフォルトの名無しさん
19/02/17 09:49:49.70 eXZp7YPc0.net
Apple機さえ無視すれば、プログラミングが色々便利になる。
459:デフォルトの名無しさん
19/02/17 10:25:00.47 vi4O111wa.net
>>443
どれでもいい
フロントは使い捨て
簡単に乗り換えできるようにビジネスロジックと疎結合に作る
そこだけ死守すればなにを使ってもいい
460:デフォルトの名無しさん
19/02/17 10:44:59.94 1mijhG+I0.net
cordova使うならIonicでいいんじゃない？
最近はAngularだけじゃなくVueにも対応したらしいし
そういやReactNativeにもVue版出てたな
461:デフォルトの名無しさん
19/02/17 15:29:11.35 KFkN1Yft0.net
vueはreactパクってばっかだな。
storybookもパクってなかったか？
nuxtもnextのパクりだろ？
さすが中国人プロジェクトｗ
462:デフォルトの名無しさん
19/02/17 16:09:57.46 E0TCVuWu0.net
別にパクっていてもそれで良くなるなら別に何でもいいけど。ただvueは元Google社員とはいえ中国人でしかも個人開発だろあれ。
いつ開発が止まるかもわからない、信用のない国の人間が作ったもんを率先して基礎にしたがる奴なんているのかな。
vue使いたがる奴なんて、vueを使いたいから使うんじゃなく、技術力低いからvueしか選択肢が無いんじゃないかと。
463:デフォルトの名無しさん
19/02/17 16:17:22.57 YF9uE98b0.net
技術力低くても使えるなんてコスト低くて最高だな
464:デフォルトの名無しさん
19/02/17 18:12:29.77 jxnSJIL40.net
どうせWebComponentsが完成したら
またガラリと世界が変わるんだから
どれ使っても一緒
465:デフォルトの名無しさん
19/02/17 18:17:28.09 1mijhG+I0.net
>>451
過大評価しすぎ
466:デフォルトの名無しさん
19/02/17 19:04:36.50 vi4O111wa.net
何れにせよあっという間に時代遅れになることは確かだ
467:デフォルトの名無しさん
19/02/17 19:11:48.12 8CydzgAW0.net
金融系取引先においてある、およそ10年前に作られた当時先端のActionScript製RIA業務システムを見るとふふってなる。
468:デフォルトの名無しさん
19/02/17 19:15:44.06 jxnSJIL40.net
10年前、2009年か。なら当時最先端のAngularJSを使っていればよかったのに
469:デフォルトの名無しさん
19/02/17 19:19:23.16 jxnSJIL40.net
Reactは2013年だから10年前には選べない
Vueも2014年だから無理
Backboneは2010年だからギリ間に合うか？
Knockoutも2010年だな
10年前の最先端は、すべからくオワコン
ReactもVueもあと5年程度の命だろ
470:デフォルトの名無しさん
19/02/17 19:27:54.46 GfPZMs79M.net
*すべからく
471:デフォルトの名無しさん
19/02/17 19:39:34.68 6yF6+Ynsr.net
Reactオワコンだからこれからはjqueryオススメ
472:デフォルトの名無しさん
19/02/17 20:02:00.60 4TiEHd4P0.net
>>448-449
やっぱ、Aureliaだな
473:デフォルトの名無しさん
19/02/17 20:17:50.30 1mijhG+I0.net
>>459
この前のレスで気になってたから今ちょうどインストールしてた
何気にAngularの一番厚い本(アプリケーションプログラミング)で主要なフレームワークとして挙がってるのな
>>448
パクリから始まったのは確かだけど今やNuxtはSSRの為だけのものじゃなく
Vueベースのフルスタックフレームワークなんだよな
474:デフォルトの名無しさん
19/02/17 20:40:36.87 SrJ5Oa/9p.net
Reactがオワコンって即ちjsがオワコンって事だと思うんだけどそれはないんじゃないか？
475:デフォルトの名無しさん
19/02/17 21:28:50.33 6yF6+Ynsr.net
ReactがオワコンになってjsもオワコンになってjQueryだけが使われると思ってるクソジジイが一匹いるけど
476:デフォルトの名無しさん
19/02/17 21:36:36.53 1mijhG+I0.net
jQueryは別にいいんだけどWebpackは知らんとこの先ついて行けんくなると思うよホント
今やブラウザでなんでもできる時代やしなんでも作らないかんくなるから何も勉強しなくても余裕とは思わん方がいい
477:デフォルトの名無しさん
19/02/17 22:05:35.95 x12h9xDW0.net
jQueryが長生きなのは認める。
478:デフォルトの名無しさん
19/02/17 22:23:23.44 jxnSJIL40.net
babel使うんだからwebpackぐらい使うだろ？
479:デフォルトの名無しさん
19/02/17 22:57:23.05 6yF6+Ynsr.net
普通に使うよな
480:デフォルトの名無しさん
19/02/17 23:02:22.78 1mijhG+I0.net
もしかしてAureliaってCliでプロジェクト作っても碌にデモ画面も表示されない？
481:デフォルトの名無しさん
19/02/17 23:57:17.64 AOpTaf3U0.net
単刀直入に質問。Vue.jsとReactを勉強するための書籍を探してる。今は
両方のチュートリアル見たりしながら写経しつつ、我流で勉強中。
●Vue.jsは技評のVue.js入門と基礎から学ぶシーアンドアールのVue.jsで迷ってる
●Reactはどれも評価高いものがなくて迷ってるが今は見送り？
ちなみにＪＳの知識だが、今までjavascriptは紫の山田本一通り通したことがあり、AngularJS1.5で簡単な
検索システム組んだことあるぐらい。いちおうjQueryも一通り触れてプログラムに
色々システムを手書きで組み込めるレベルはある。
482:デフォルトの名無しさん
19/02/18 00:24:29.50 ZveW3gOd0.net
>>468
vueだけど、俺は「基礎から学ぶvue.js」買ったよ。技評の方は読んでない。公式webとその本で十分網羅されてると思う。
483:デフォルトの名無しさん
19/02/18 00:32:34.18 PvqzGaNZ0.net
おお、サンクス。なら、そっちも買うか
484:デフォルトの名無しさん
19/02/18 01:01:22.40 qsq8EO4j0.net
Nuxt.jsビギナーズガイド―Vue.js ベースのフレームワークによるシングルページアプリケーション開発、
花谷 拓磨、2018/10/17
基礎から学ぶ Vue.js、mio、2018/5/29
Node.js超入門、掌田津耶乃、2017
Electronではじめるアプリ開発
~JavaScript/HTML/CSSでデスクトップアプリを作ろう
野口 将人・倉見 洋輔、2017
入門 React ―コンポーネントベースのWebフロントエンド開発、2015
Reactビギナーズガイド ―コンポーネントベースのフロントエンド開発入門
Stoyan Stefanov, 2017
URLﾘﾝｸ(github.com)
初めてのJavaScript 第3版 ―ES2015以降の最新ウェブ開発、オライリー、2017
JavaScript 第6版、2012、David Flanagan
485:デフォルトの名無しさん
19/02/18 01:12:07.61 TCe7B/Jv0.net
↓Reduxに関しては一番詳しく書いてあるけどサンプルプログラムの入手先が本誌に書いてない・やっぱちょい古い
React入門 React・Reduxの導入からサーバサイドレンダリングによるUXの向上まで
↓構成は悪くないしサンプルプログラムがしっかりしてる点はいいがバージョンが古いのとRedux�
486:ｪ載ってない いまどきのJSプログラマーのための Node.jsとReactアプリケーション開発テクニック ↓これはやめといたほうがいい React開発 現場の教科書 とりあえず一番上がいいかな
487:デフォルトの名無しさん
19/02/18 01:14:46.55 TCe7B/Jv0.net
>>471
Node.js超入門は全然役に立たんし買う必要ないと思う
てか全般的に2017年以前の書籍勧めちゃいかんだろ