Vue vs React vs Svelte Part.7 YouTube動画>4本 ->画像>2枚

実際どうなん？
※Angularは残念ながら全く話題にならなかったのでSvelteに差し替えました
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Svelte
https://svelte.dev/
※前スレ
Vue vs React vs Svelte Part.6
http://2chb.net/r/tech/1603771745/

★ここではjQuery, Ruby, C#, Blazorの話題は禁止です
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
Angular, Next, Nuxt, Sapper, Gatsby, VuePress, RedWoodなどはおｋ。

いつの間にか出てたstateofjs
https://2020.stateofjs.com/en-US/

>>2
GatsbyがややNegativeに動いてるのが意外。Svelteはみんな試し出してるのが分かるね。しかしReact圧倒的だな…
https://2020.stateofjs.com/en-US/technologies/arrows_overview

Angularの落ちっぷりよ…
https://2020.stateofjs.com/en-US/technologies/front-end-frameworks/

react、reduxあたりまではいいけどホンマにredux-sagaとか使ってんのか？ってのは思う。

redux sagaの良さを理解できてない。thunkもそうだけど。

素直にサーバーからのレスポンス待ってdispatchすれば良いと思うけどね

昔は使われた。
今はrecoilあるしわざわざ新しく始めることはない。

reduxはオワコンだと思う
俺は前から現場でアクションをswitch caseで管理する
バカらしさを批判してきたが
なぜか誰も聞き入れることはなかった
あんなのアクションの爆発的増加を生んで管理できなくなるのは明らか
C言語かよ

ReactやVueのアプリの設定値ってどこに設定するの？

Widowsネイティブアプリだとiniファイルとかconfigファイルの相当するファイルだけど。

>>8
それはお前のアプリケーションではreduxが必要なかったってだけでしょ。

>>9
環境変数の設定の仕方ってこと？

>>11
意図としてはそうかもです。

ネイティブアプリの設定は外部設定ファイルに個別設定が多かったのですが、
それは出来ないのでしょうか？

(ネイティブアプリの場合)
xxxxx.exe
xxxxx.ini --- これに相当するもの

>>12
.env が一般的かも

.env reactとかで調べてみると出てくると思う

>>13
OK！

ContextAPIを"正しく"扱うための学習コストを考えたらRedux toolkitで良くない？って思うんだけどなぁ

>>15
そもそも目的が違うから何とも…

>>4
vue.jsすごいな85%もあるよ

んで、その下に書いてある、vue.js 12ってのは何だ？
Backboneは18だぞ。jQueryは22だぞ

>>17
そんなん俺に言われても…

>>759
草

今からreduxまじめに勉強するのめんどいから早くrecoilに殺されてくれ

redux使って開発したけど面倒くさすぎる
こんなゴミクソ誰が考え出したんだか

俺はjotai推し

jotaiとrecoil何が違うのかいまいち理解してない

除隊？女体？

女体はにょたいと読むだろ普通

redux toolkitはいいぞ

reactみたいに使うライブラリが徐々に更新されるような軽いフレームが好きなんだが、
やっぱ趣味でいじってるのと仕事でやるのは違うかもな。

皆ユーザ認証は何使ってるん？
やっぱりAuth0？

仕事で使うのはfirebaseが多いなぁ

Password

recoilこれダメだろ。。reduxの100倍くらいデータの流れがわからなくなるわ。。

>>29
firebaseも人気あるみたいだね。
使ったことあるけどライブラリがでかいイメージある

auth0なんか覚えること多すぎて覚えるまでかなりしんどそう

JWT一択
仕様としてはかなり簡単だし
この程度はフロントエンドの人でも自力で実装すべき

いやJWTがバックエンドありきだろ…
それを何使ってますかって話。

普通に自前実装だが何を使うとは？
ライブラリとかフレームワークのこと？

自前実装は絶対にしない方がいい。
jwtの認証は簡単に作れるけど、セキュリティホールになりえるからセキュリティのプロの人たちが実装した　idaas使った方がいい

まぁ、自分たちがセキュリティに精通してると胸張って言える人は自前実装でもいいと思うけど。

https://www.google.co.jp/amp/s/auth0.com/blog/amp/jp-a-look-at-the-latest-draft-for-jwt-bcp/

ここでも書かれてるけど、専門家以外は自前実装するべきじゃないよ

そのライブラリがセキュアだという保証は？
それにライブラリがない言語は自前しかないし
セキュリティはもうライブラリ作者の個人が担保するものではないよ
セキュリティ担当者がいないならすぐ雇うか
どこかに依頼すべき

セキュリティに関しては、完璧な知識を持った上でシステムを隅々まで理解し、時節に変化があれば即時にキャッチし、情報が漏れたときに全責任を負う。自前でやるならそれぐらいの覚悟が必要だと感じてる。

s/セキュリティ/ユーザ認証/

セキュリティを専門とするエンジニア（コンピューターサイエンスに深い理解を待ってる人）を雇えるならいいよ。
でも大抵の企業がセキュリティ担当に1000マン以上出して雇おう！って感じではないでしょ

auth0とかfirebaseはセキュリティに精通しているエンジニアを雇ってるからね。どっちが信用できるかの問題だよ。自社のエンジニアを信用するならそれでいいと思う。

クリティカルな部分のセキュリティに関しては、専門家じゃないやつの理解って大切だけど、本質的にはあまり意味ないと思ってる。何故なら知識が浅いから

>>41
これに関しては自社で実装しててもしなくても一緒だと思う

まず自前実装ってどこからどこまでの話なのか
自社のバックエンド側で認証の仕様が決められてて
それに基づいてフロントエンド側を実装するって話なら分かるが

ここでもう認証はこれにしろ！ってのを決着つけてほしい

ライブラリすらないマイナーな言語なんか使うなよ

vue3になって更に混沌としてきた感すごい
節操なさすぎだろこれ

>>48
糞化し始めた感じなのかな？

svelte最強伝説が始まりそう

そろそろjqueryおじさんが出てくる予感w

>>51
NGワードだぞ！

vue3が出て以降npm trendsじゃangularと抜きつ抜かれつだったのが明確に離されて着てる印象

vue3は完熟してから頂きます

鼻毛認証という言葉を思いつきました。

>>48
そんな違うんだっけ？

>>51
呼んだか？

https://w3techs.com/technologies/history_overview/javascript_library/all/y
jQueryのシェアは2021年1月時点で77.2%だったが
1ヶ月で77.3%に増えた。まだ増加傾向にあるようだ。

なおReactのシェアは0.4%。その程度のレベル

jQueryおじさんきたあああああああああ

塩まいとけ！

VueはcompositionAPIの影響でごちゃごちゃするんだろうなぁーっていう感じ

>>56
とりあえずreact hooksパクってみました感が凄い
調べれば調べるほどreactで良くね？ってなる

>>60
Vueの売りはフロントエンド技術者にとっての分かりやすさだったけど今となっては無いよね
reactの方が明らかに明確で分かりやすい
全然違う方向に進化して欲しかったから残念だわ

いつものことじゃん。思想が明確じゃないから
ぶくぶくと機能を追加して破綻する

「シンプルでわかりやすい」というのはどれもが主張してくるメリットだけど
それは単にできたばっかりで実装が追いついてないだけ
バージョンアップするたびに複雑になっていく

そしてまた次の「シンプルでわかりやすい」新しいフレームワークが
登場しまたぶくぶくと太って繰り返し

基本的な機能に絞り込むという発想がない
jQueryはその点最初からブレずにやってるから
こうやって長く使い続けられる

jQueryは先進的な層から誰も目を付けられてないから発展しないんだろうね
結果的にそういう利点も生まれるわな

vueって最初better angular的な思想だったのに
Reactを取り入れて魔改造してキメラになったイメージ

Reactとvueとアンギュラーの違いが抽象的にしか説明しとらんじゃん
具体的に何がよくて何が嫌なのか伝えられんの？

みんなvue2→reactに行ってんの？
せっかくvueの勉強始めたのに

両方やったらええわ。
そこまで大きな違いなんかないから。

>>54
完熟する前に腐りそう

>>64
現実はこれな
https://tr.twipple.jp/p/58/263bc0.html

一部のピエロが最先端を～最先端を～と言ってるが
世界中の大半の人々は最先端になんか興味ないんだ

>>67
FCとHooksによる状態管理こそフロントエンドに必要なもの
それ以外は枝葉
まず最初にReactをやってこの概念をしっかり身につけるべき

railsAPIと組み合わせたサイト作ろうと思うんだけど、完全SPAで行くならvueでもreactでも学習コストは同じくらい？Vueのほうが簡単？

vueはeasy、reactはsimpleという印象だけど

学者コストはVueの方が多いんじゃないかな
入り口はeasyなんだけどその先が魔窟

vueだけなら、まだしも、
ここに、vuetify , webpack , electron などが入ってくると、覚えること多すぎて、発狂する。
　

vuetifyはきっついね
ブレイクポイント調整するのでさえ調べるのに苦労したｗ

WebpackはReactのついでに覚えたけど、2つ同時に新しい事やるのはしんどかったな。
どっちで間違えてて動かんのかわからなくなるから

typescriptもあるしな
最近まともなところはみんなts使ってるから

ts使ってる所は、まともなところだから当然だな

ネットの情報見てても、同じ事してる記事がJSとTSでそれぞれあったら、TSの方がレベル高い傾向あるね。

稀にこいつぜってーC♯かJava屋だ、みたいなTSらしからぬコードなことあるけど。

typescriptもかなり難しいと思うわ。

そうそう。TS使ってる所がマトモな所で
マトモな所をみると全部TSを使ってる

TSを作ったのはマイクロソフト
やはり開発ツール大手の言語が一番信用できる

>>31
Reduxは一元管理
Recoilは分散管理
だから当然
同じ球技として野球とサッカーを比べてるみたいなもんだ

React触ってるやつの気が知れんよね
JSXとかいうゴミ未満は触る気まじでおきない
CSSもライブラリなしだとどうしようもないしバニラHTML、CSS、JSのサイトを置き換えるのに向いてなさすぎる。置き換えたら置き換えたら他ライブラリに不可逆だし

Hooksがなかったら正直vue使ってたと思うわ

他のライブラリと互換性がないのはどのライブラリでも基本同じでは？
Reduxとかは一応Vueとかでも使えるけど

cssだけは外出ししてscssにしてる

俺は中出ししまくりだわ

> Hooksがなかったら正直vue使ってたと思うわ

このスレ史上一番の同意

vuexじゃダメなん？

>>86
IT老人が新しい技術触りたくないだけのワガママにしか聞こえないっす
ｊQueryを永遠に触ってれば良いんじゃないっすか？

まあクソ技術でも新しいってだけで喜んで使うバカも大概老害だけどな。

老害の自覚が無いのも老害の特徴

新しい技術に飛びついた結果が、vueなんですよね？ｗ

一年くらい前にRouterのみ(状態管理？なにそれ)でダイナモのdataを出し入れする奴を1から作ったことあるレベルなんだが
今から簡単な管理画面作ろうとしたらどっちがええんや？
ReactAdminとかいうのがあるしやっぱりReactかな？
フロントエンド極めるぜーとかは無い

コーポレートサイトでもJamstack使う感じか？
Gatsbyとnextjsどっちがいい？

コーポレートサイトこそ速度重視(SEO)でJamstackかなと思ってる。
後は好み

コーポレートサイトなんてWPでさっくり作ってCDNでキャッシュすれば済むんじゃないの？
わざわざJamstack構成で手書きとかする意味あるの？

それ、結局慣れてるってだけでWP+CDNのほうがふつうに複雑な構成だと思うんだけど…
WPにはApacheやphpも含んでるわけだろ？
慣れ親しんだ構成は簡単（に感じる）ただそれだけでは？

>>92
正直とっつきづらくない?

それってSSRでないといけないのかどうか、を考えたら自ずと答えは出てくると思うけどな

ものによるだろ
コーポレートサイトでもぴんきり

svelte ってdocument.getElementbyIdできないよね？

んなわけねえだろ

Vue3どうや

Vue3ッピ

Vue3なんてでるのか
Nuxtが対応したら考えてみるかな

もうとっくに出てるぞ

react今からなら関数でhooksなん？

はい

わかりました
recoilってのも気になったけどおいときますね

りあくと！っていう同人誌読んでおけ

大岡さんじゃないですか

状態管理はuse.stateとuse.contextで充分よ
recoileとかそびえ立つなんとか

状態管理って
ネイティブクライアントつくってれば
当たり前の機能でしかなくて、
Webアプリしか作った事ないのが
騒いてるにしか見えんね。

しかも、これらのライブライリ
使うと著しく見通しが悪いコードになる。

普段通り要件に合わせて
都度作った方が良いね。

コードから無理やり状態を排除しようとした結果
状態を扱うだけの高機能な巨大なオブジェクトが出来上がってしまったという
笑うに笑えない間抜けな事態になってる

状態が"必要ない"ものであれば、状態をなくすのは理にかなってるが
そもそも状態が必要なものは、状態をなくすことは不可能なので
部屋に散らかったゴミを押入れに入れるように一箇所に隠すことしかできないのだ
一見きれいに見えたとしても、それはいずれ大きな負債となり管理できなくなる

ま～た来てんのか懲りないなぁ

stateもreducerもrecoilもcontextも
必要に応じて使い分けるがなあ
reduxを使わない(使う技術と根気がない)からかもしれんけど

>>118
＞状態を扱うだけの高機能な巨大なオブジェクトが
それが正しく抽象化されていて、管理の手間も掛からないなら、何の問題もないだろ

何ならオブジェクトって単語をライブラリに置き換えるだけで、受ける印象が全然違うし
＞状態を扱うだけの高機能な巨大なライブラリが出来上がってしまった

明らかにReactの事わかってない（もしくは使ったことない）文章だし、触るだけ無駄だって

JotaiよりValtioのほうが好き

Reactは糞

じゃあ何が紙なんですか？

jqueryですよ

ハイハイ別スレまで立ててんならそっちでやれよ（藁

Context APIは適切にメモ化して再レンダリング抑制して場合によっては正規化もやって云々
って色々とやっていくうちにreduxのしょぼい版が完成するだけ

じゃあ最初からreduxで良かったじゃんってなる

あるある
オレオレフレームワークの末路も大体そんなだな
結局、シェアが大きいのは大きいなりの理由があるわけだ

フレームワーク開発者の実験に突き合わされてるって
いい加減気づかないものかね？
それなりの人が作ってるものはどれでもいいんだよ
あとは将来性で考えればいい
重要なのはどれだけ長く使えるかだ

やっと時代がsvelteに追いついてきたな

なんかあったのか？

redux + hooksが良さげだな。

reduxの時代はもうすぐ終わる

reduxはやく死ね

reduxって単体で便利なライブラリなのに、
reactとセットが当たり前みたいに扱われたせいで、とんだとばっちりだな

reduxしねって言ってる奴は基地外なんだよなぁ

redux使わないレベルの規模ならhooksでいいけどな
しょぼいのしか作ってなさそう

angularは何がまずかったのか

reduxが糞言われるのと同じ感じゃね？

まあそもそも、SPAフレームワークとか状態管理とかこのゴミのようなブラウザやネット、htmlやらjsの仕様に合わせて仕方なくやってることだよな

状態管理は後付けで出てきたようなもんだし
何もかも非効率

>>139
angularはUIとデータベースをうまく紐付けないといけないので高度な設計能力が必要になる
その反面、設計能力が高ければUI関するコードを減らせるので
かなりシンプルにすることができる

reactとかはデータとUIに直接のつながりがないので
適当に作っても、それなりにどうにかなる
その反面JavaScriptでUIをゴリゴリと書いてる

フロントみたいなデザイン的な面を最初からうまく設計できるって仮定自体が馬鹿げてるわ。

本来データ構造と見た目を分離するのがHTML/CSSなんだけどな
フロントやってるやつはCSSが苦手
CSSの命令は知っていても最低限の機能しか使えず
CSSだけで高度なデザインする能力がない

>>144
当たり前やん
それデザイナーの領域やし

angularは単になんでも入りが受け入れられなかっただけでしょ
バンドルサイズでかくなるし

>>145
ゴミクソ自称フロントエンジニアwww
デザイナーがjsxいじるのか？

>>147
おまえデザインも完璧に出来るんやな？（笑）
そんな奴がフロントエンドのコードまともにかけるわけ無いやん（笑）

>>145
だからデザイナーにやらせればいいということになる
そこをうまく分離できておらずプログラマがやらなければいけなくしてるため
メンテナンス性とパフォーマンスが低下して、生産性もスケールしなくなった

高い技術を持っていればAngularは素晴らしい道具なんだが
それを使いこなせる技術者・デザイナーが少ないという話

具体的に言えば、

デザイナーは最低限これぐらいは自力で実装できるぐらいの技術力が必要

CSSだけで作るドロップダウンメニュー（多階層）サンプル8
https://webdesignday.jp/samples/p5793/sample8/


そしてプログラマは、自分で作れなくともHTMLとCSSだけでこれらを作れると知っており
それを作るために必要なHTMLをカスタムタグなどを使いより簡潔に生成するために
HTMLやフレームワークの機能を熟知していなければいけない


ここまでの技術者が揃うのは少ないのでAngularを使いこなすことができない
そこでちまちまとJavaScriptで生成してる

>>148
ゴミクズのお前はコードすらゴミじゃん

>>152
低能だから直ぐ発狂するんだな（笑）
朝鮮人かよ（笑）
どうせデザイン能力も大したことなければコードもまともに書けないという事がバレバレやな（笑）
あ、また発狂するの？（笑）

>>149
だからjsxとstyleComponentをデザイナーにやらせるのか？
オメーがやれよって話
stateによって可変させるUIとかどっちがやるんだよ？
自称フロントエンジニアどものゴミのようなUI作成能力どうにかならねえのか

>>153
お前の目ん玉腐ってるからデザインもできないわ、コードもゴミだわで存在価値ゼロだろ

>>154
> だからjsxとstyleComponentをデザイナーにやらせるのか？

jsxとstyleComponentはウェブ標準技術じゃないよ
ウェブ標準はプログラマとデザイナーの両方にとってより良い技術だったのに
それをぶち壊している技術がたくさんあるってだけの話
ウェブ標準に戻りましょう

>>154
> stateによって可変させるUIとかどっちがやるんだよ？

プログラマはstateの管理までをやればいい。
最終的にそれはHTMLのクラス属性やdata属性などに反映される
そのstateに応じたUIを作るのはデザイナ
一人で作るのは大変なんだからさ、分業しようぜ

いつもの奴じゃん。相手するなよ

高い技術があれば〜とか、超人的能力あればアセンブラで十分ていう狂人と一緒だぞそれ。

NGしたらほぼ見えなくなった

なにでNGしたんだ？

>>159
高い技術ある人で、アセンブラで十分なんて言う人いないだろ？
その例えはおかしい

そもそも開発コストの話をしてるわけで
記述量が圧倒的に増えるアセンブラは
高い技術がある人が使っても開発コストは増える

フロントエンド開発が複雑になりすぎて、デザイナの手に負えなくなったからフロントエンドエンジニアって職種が出てきたのに
デザイナにコード書かせるとか、お前らいつの時代の話してるんだよ
分業っていうなら、デザイナの仕事はあくまでデザインで、コーディングじゃねぇよ

> フロントエンド開発が複雑になりすぎて

ここが根本的な問題で解決すべきこと

>>163
デザイナが書くのはHTML+CSSだぞ。これをコードとも言うけどな
あと正確にはウェブデザイナな
フォトショでカンプ作るとかいうやつじゃないからｗ

自称フロントエンドエンジニアはhtmlやcssすらまともに使えない
使えないからデザイナーガーとしか言えない
例えデザイナーがカンプ作ってもセンスゼロだからhtml cssで再現できない
マジでフロントエンドエンジニア名乗るのやめたほうがいいぞ

>>165
それがいつの時代の話してるんだって言ってるのに、会話成り立たなすぎて草

このスレに限らないけど、5chってXHTML時代から情報更新されてないやつ多すぎないかね
Web関連の話になると、こういうやつがうじゃうじゃ湧いてくる
bootstrap全盛時代とかWP全盛時代の常識がガンガン出てきて、びっくりする
平成の半ばにタイムリープしたかと思うわ

それな。
首だけ突っ込んできてなんにも学ばない不毛な人が一定数居る。
そういう人はどういうわけかいつもイライラしてるようだ。

勉強して知識アップデートするか、首突っ込んで来なければ、今よりは幸せになれるだろうに

>>167
ウェブ標準団体が、Web3.0とかいいだしましたか？ｗ
いつの時代って普通に現役
ウェブ標準の仕様は何も変わってない

>>170
Web標準仕様の話なんてしてないのに、本気で会話成り立たなくて草
どういう読解力してるんだよ

そもそもWeb3.0って、Web2.0は仕様ですらねぇよ
腹筋崩壊するわ

文書構造とデザインの分離はウェブ標準団体が言ってることなんですが？
いつ方針を変えましたか？

昔はwebの役割としてdocumentのような静的なものを求められてきたけど、今はネイティブアプリのようなアプリケーション寄りの要件が出ることが多いからね。

webにロジックが入り込むことが多くなってきてデザイナーは基本的にfigmaとかでデザインするだけでマークアップも書かなくなってきてる。

> 今はネイティブアプリのようなアプリケーション寄りの要件が出ることが多いからね。

ほとんどのウェブサイトではそのような要件はでてきません
あなたが趣味でググって見つけたサイトは、ネイティブアプリのような機能がありますか？
そういうことです。

この人WordPressスレに行ったら幸せになれるじゃねーかな

文書もデザインもロジックもすべてjsに入り組んでいるのが今のフロントエンド
センスゼロ再現能力ゼロの無能君たちはフロントエンドエンジニアではない
ゴタクを並べて言い訳しかできない単なる使えない産廃

ID:7Hox7ISB
こいつは無能

やっぱりワッチョイの方が良かったんじゃ

盛り上がってますねぇ

ぶっちゃけ色んな技術を配属されたチームの習熟度や要件に合わせて使えることが重要なわけで
Redux嫌いとかVue嫌いとか、TypeScriptいらないとか言ってる暇なんて実際ないからな
結局は技術をアップデートできない奴が淘汰されていくだけの話
過去の技術に固執したいのなら勝手にひとりでやってれば良い

まあ、問題は技術のアップデートではなくて技術の変更になってるってところなんだよな
やり方が変わるだけで、何も良くなってないというね

技術？に群がってるだけじゃん。

その技術っうのは
只の流行りネタなだけという。

別に技術に群がるでも良くね？
それが要求されているのならやるだけなんだが？

バーナーズリーってなんか、話し方大丈夫この人？
前からこんな感じだったっけ

ごめん、スレタイとあんまり関係ない動画貼っちゃった
なんか上みたら Web 3.0 がどうとか喧嘩してたから調べたのよね

まぁ、そもそも俺が技術選定する側の人間じゃないからそう思うだけなんだけどな
別に必要ないから使わないって選択のできる人は使わなきゃ良い話

>>185
めちゃくちゃあがってるな笑

>>188
あがってるのかこれ？
なんか他の動画見ても最近のやつはこんな感じで、
薬やってんじゃないかとかコメント欄で言われてる

新しいってだけでゴミ屑使おうとするからレガシー化するっていう事にもう少し気を使ってほしいわ。

新しいってだけでゴミ屑使おうとするからレガシー化するっていう事にもう少し気を使ってほしいわ。

>>187
誰それがこれからは○○だって言ってましたーみたいなのが多すぎる

新しいものを使うのがなぜか前提となってる
今の問題点を言ってないか古いから、新しいからみたいな
意味がない理由しかない

こういうヤツがチームに紛れ込むとめんどくせーんだよな😅

頓珍漢なこと言われたら普通に議論して論破すれば良いと思う

それができなければ自分が選んだ技術選定も間違ってることになるし

web標準にやたらこだわってる奴がなんでjqueryを使おうとするのかよくわからないけどね。

今ならjqueryを使うならvanilajsで事足りるしね。確かGitHubかbootstrapだったかもjqueryを排除してvanilajsに移行するって言ってたしね。

ただ過剰にreactやvueが使われてるなとも思う。


https://bundlephobia.com/result?p=react@17.0.1
https://bundlephobia.com/result?p=react-dom@17.0.1

reactを選択すると必然的に約43kbバンドルサイズに含まれることになるからね。かなりパフォーマンス的にはクリティカルだよ。

個人的には　webcomponentが宣言的にssrできるようになり、かつweb標準でjsxのようなテンプレートが実装されれば良いなと思う。

それReactでやるほどか？ってのを見かけたり
vanillaで記述してクソ共有しにくいオレオレを多用してるのがあったり
Reduxのstyle guideとしての側面を無視して話すヤツがいたり

適材適所って言葉知らんのか？って思うことは多々ある
極端すぎるねん

>>195
jQueryはvanilajsの「書き方」を変えただけだからだよ
vanilajsを使う場合と同じやり方でウェブサイトが作れる

>>197
style guideとしてのreduxってどういう意味？

>>199
状態管理を扱う時のひとつの規約というかルール、パターンでも良いかな

それに則ることで、エンジニア間の差異を減らしたり、共有しやすくなるよね
でも場合によっては煩雑になったり、持て余してしまうこともあるよね
だから適材適所だと思うよってこと
公式も言っている通り、無理に使う必要はない

そういう意味ね。なるほど。

まぁreactとかvueを採用すると途中から参画してきたエンジニアでもコストが少なく開発に参加できるよね。

結局どういうwebを作るのかにもよるけど

https:ar.al/notes/the-documents-to-applications-continuum/

↑ここでweb siteとweb applicationの定義がされてる。ようはweb siteにはreactやvueのようなフレームワークは不要だと思う。もし使用する場合はクライアントのバンドルに含まれないようにサーバー側でのみ使用するといった工夫が必要になると思う。

確かに適材適所はその通りなんだけど。
その適材適所をうまく言語してるような記事とかあったら読みたい

その辺はgatsbyみたいなのもあるし線引き曖昧になって来た感ある

そもそもクライアントサイドで動く素のReactとSSRは区別しろって話ではあるけどな
素のReactが適するケースは意外と少ないっていうのはその通りで、
だから汎用的に利用する為にSSRだのJAMStackだのが増えたわけで

けど、そんなことをごちゃごちゃやらなくても、jQueryで済む話が多いのも確かなのよ

でも二度とjQueryでアプリ作りたくないっていうのも事実だよな

gatsbyやnetjsのssgは結局クライアントでhydrationしてるから、バンドルにreactやreact-domが含まれちゃうでしょ。

俺が言ってるのはrenderToStringでhtmlを送るだけ。
uiにインタラクションを持たせたかったらvanilajsで実装するということ。

>>204
区別は良くない。クライアントでもサーバーでもコードを共有できるってのはいい設計だと思う。

jQueryなんてIE対策としてとしか使ってなかったわ
そもそもDOM操作とかは絶対やりたくねーし
それやるぐらいならサーバーサイドからHTML返してもらうよ

サーバーサイドからHTML返してもらうほうがきついかな自分は
JSPのトラウマが蘇ってきてさあ

>>201
さらっと読んだけど面白かった
とはいえ「それWordPressとCDNでよくね？」みたいなサイトも国内外問わず今は無理やりJS技術使ってるところ多いよね
昔フロントエンドが面倒くせえことになってるのはお前ら自身がめんどくさくしてるからだってのを読んだことあるがまさにそのままだなー

逆だろｗｗｗｗｗｗ
どう考えても静的サイトで十分なのに「WordPress入れましょう」で高単価案件にして鯖管費までふんだくってんだろうがｗｗｗｗｗｗ

ゴキブリ倒すのにブラックキャップ買ってきたら池沼に「それ核爆弾でよくね？」って言われた。こんな感じのナンセンスさ

wordpressはフロントエンドとバックエンドの分離が難しいから採用するのは良くないかな。

そうかな
技術者集めるコストとか考えたら全然安いと思うし完全な静的サイト(DBナシ)は想定してない
日本だとnoteとかそういうサービス

まぁほとんどのwebサイトはそれで充分なんだよね
このスレで取り扱ってるフレームワークとはあまり関係無いはずなんだけど意見かごっちゃになってるのは必要ない場所で使ってる人が多いからなんだろうね

noteとかそういうサービスをwordpressを使用して開発するってこと？

>>216
WordPress云々はどうでも良くて読み物ならサーバサイドレンダリングでいいじゃんってだけ
わざわざ読み物サイトをフロント側でごちゃごちゃやる意味がわからんのよね
確かWordPressも管理画面はReact使ってたと思うけどそういうのに必要だよなって記事に
そうだよなーって感想もっただけ

>>217
その通りだね。

Svelte Material UI + snowpack 使ってる人いる？
環境作れなくて涙目

Nuxt.js使ってる人ならnext.jsの学習コストそんなかからないよね？

vueとreactは別もんじゃん
そりゃおなじnode.jsだけどさ
vueは従来どおりのテンプレート型
reactは関数言語の応用だし。

tailwindっぽいutility firstなcssフレームワークって昔のHTMLをカッコつけた感じが半端ないな

どんなに優れたcssフレームワーク使ってもお前らのゴミのようなセンスだとまともなUI作れないよな
デザイナーガーで召喚しても指示どおり作れないし救いようがない

はいはい、今日もご苦労さん

最近Vue使い始めて便利さが実感出来た。
なにより手軽。

それがreactのほーーが
究極シンプルで手軽なんだよ。

vue.jsの次に手掛けてわかった。
vue.jsの選択理由が簡単で分かりやすい
はずだったんだけどな。

一番手軽なUIソフトはexcelですよ

>>227
機能が無い分面倒だよ。

ReactはHooksを覚えるだけで万能感得られるのがでかい
余計なこと覚えなくていい
ただしHooksをちゃんと理解するのが難しい

一概に難しいとも言えんだろ。
useStateみたいに簡単なのから難しいのまでいろいろある。

>>229
楽だよな
Vue使う理由が無くなる

NuxtもそのうちISRできるようになるんか？

NuxtがISRできるようになる頃にはNextがまた新しいほげふがレンダリング出来るようになってるぞ

ISRなんていらんやろ・・・
こんな間抜けな機能を提供しようと良く思ったなｗ

逆張りかっけー^^

これからはSSGだ！とかISGすごい！とか長々と説明してる記事多いけどさ、それただのキャッシュしてCDN配信してるだけじゃん
そのために新たな技術やコーディング方法が必要ってむしろ面倒くさくしてるだけだろ
頭おかしいんじゃねえの

それキャッシュとCDNで十分じゃん、みたいなパターンは結構見かけるね。
それはそれとして、技術としては別モンだと思う。

それな
元々、Ajaxの系列だからな
Ajax -> SPA -> SSR -> SSGと来ているわけで、SPA要素がない従来の技術とは系統が違う

まあ、本来はシングルページ”アプリケーション”を作る技術の延長で、ウェブページを作る技術じゃねぇよって話なんだが

こいつらReactを理解してるのか？

どうしてそう思うの？

SPAなど関係なくサーバーサイドで静的HTML生成は何十年も前からやってた
それをSPA界隈の人達が違うパラダイムでやろうとしてるというだけのことだと思う

シンプルにしとけばか
自分で複雑にしておいて、複雑しているのが解決しましたドヤ
ってやってるのがフロント

動的にやるしろ静的にやるにしろ
サーバー側で何かしないといけないのは間違いない
個人的には各言語にReactのサーバーサイドSDKみたいなのを用意するのがベストなんじゃないかと思ってる
そうすれば既存のフレームワークからも使える

React server components

入り乱れてめちゃくちゃになってきてるな

所詮お前らはフレームワーク開発の実験台にされてるだけだからな
最終的にはブラウザネイティブで対応し、フレームワーク自体の機能は極小化する
つまり今頑張っても数年後には無駄になってるということさ

今やってる事が遠い未来もそのまま役立つとは思わないけど、逆に全然役に立たないなんて事無いよ。
UFOが降ってきて宇宙人が全く新しく異質なプログラミング手法を伝授するレベルのパラダイムシフトでもない限り、技術は陸続きで、だんだん便利になってくわけで。

それとも、20年後もCOBOLやVBAやりたいの？

Reactは10年に一度レベルのパラダイムシフトのフレームワークだぞ
Railsが出た時と似てるが持続の長さを考えるとそれ以上
これをガッツリ使うかどうかで今後のエンジニアとして生き残れるかが決まる
dhhをみろ
Railsこじらせてhotwireみたいな珍妙なものを作ってしまった

Rails勉強中のぼくちんはhotwireに期待しとる。
Reactぱっと見むずいんでvue跨ぐわ

vueのほうがむずい気がするけどなあ
リファレンス見ながらじゃないと書けぬｗ

jsxとテンプレート構文、どっちが良い？

jsx

Reactの最初とっつきにくいように見えるけど、慣れればむしろシンプルで楽ってのは、関数型プログラミング始めた頃の体験と似てるように感じたな。

あとはUI系のライブラリが揃えば完璧なんだけどな
CSS系は増えてきたけど
UIライブラリはよ

jsにjsxを記述するとコードが増えてぐちゃぐちゃだよな
ここにさらにstyle component入るとカオスだろ

無理にあれこれ入れる必要無いだろ
必要なら使えば良いだけ

>>256
ロジックとjsxが混在したソースってどうなんだろ？
一貫性があっていいのかもしらんけどjsの中にhtmlを書くって未だに馴染めない

主体がjsかhtmlかの違い
テンプレートの方が融通が利かないので肥大化しやすいと思う

コードが読みやすいし
めちゃくちゃ柔軟性ですわ。

>>257
stateや様々な条件に応じてdomを出し分けたりすることが多いからね。
ロジックと混在してるのは便利だよ。

例えばSpotifyみたいなアプリケーションを書こうとしたときに、サーバーからはアーティスト一覧が帰ってきます。その一覧を表示してくださいとか。
ロジックかけた方が宣言的にかけるでしょ

アーティストを人気順や名前順に並び替えたいという要件が出てきた時。その条件をobserveしてロジックを実行したい時とか。これはuseEffectを使うと簡単にできるし。

やはり便利やわ

Vueのように分離したってワンクッション増えてしょうもない問題が入り込むだけ
それならシンプルに一緒にした方が楽

ReactもVueも気持ち悪いからどっちでもいいや

実際はカスタムフックを作成したり、コンテナに集中させたりしてロジックは分離するけど
チュートリアルとか初学者向けのものはひとつのコンポーネントに詰め込みまくるから余計に複雑に見えて嫌になるのかなって思う

JSXをいじりまくってる時はPHPerの気持ちがわかるね

最近のPHPの事は知らないけど、Reactは階層構造を強く意識して（疎結合なJSXを）書く事になるから、個人的にはPHPの書き味とは似てないと思う

React坊が大嫌いになったのでVueにします

ええで、多様性は善や。
俺はReact使うけど

NextとかNuxtにtailwindを使うケースが増えてるらしい
実際どうなん？

センスゼロのプログラマがどんなcssフレームワーク使ってもまともなUIを作れないからどうにもならん

これひょっとしてボット？

>>270
ん？会話成り立ってないよお前
コミュ症か？

tailwindはCSSのエポックメイキング

Tailwind CSSが私には合わなかった理由
https://coliss.com/articles/build-websites/operation/css/why-tailwind-css-is-not-for-me.html

プログラマのゴミのような酷いUI構築力

画面設計にはあるのに必要な要素が存在しない
レスポンシブにするとどこかに消える要素
画面の外にはみ出したり追い出されるコンポーネント
スクロールすらまともに作れない
マージンバラバラ
フォントサイズ超適当
正しいレイアウトになっていない
デザインどおりに組めない

→ それ俺の仕事じゃないと言い訳しかできない

これが自称フロントエンドエンジニア
マジで無能

なるほど類は友を呼ぶ、か

>>274
いままで使ってみたことなかったけど
それ読んだら今後も使わないだろうと思った

>>275
お前が無能じゃん

指示もうまく出来てないし、マニュアルもないし
フロントとバックエンド両方の技術求めているし
こいつを使えるような指示を出せないお前が無能

さっそく言い訳かよ
恥ずかしい

マ板に行け

>>280
反論できないのは事実だからでは？

>>282
指示しないと作れない無能のお前ごときに反論が必要なのか？
どっちにしてもお前のゴミのようなセンスどうするんだよ？
生まれつき目ん玉腐ってるから見たものすら理解不能なんだろうが

>>269
Tailwind 好きだけどreactには向いてないと感じる

海外のトレードサイトで、reactで作られたUIで割とキビキビ注文板が動いてるの見たから、案外パフォーマンスも良いんだな

レンダリングのスピードはvdom使ってるから遅いけどな。直のdomを弄るよりも。

>>286
そら直の更新で最小の更新だけすれば、そっちの方が早いだろうけど
差分更新のメリット活かせないなら、そっちの方が早いのは当たり前じゃね

速度だけ見たら阿部寛のホームページが最強だわ。
カス企業は無駄に動的にしたがるがこれで十分だろ。

動的ページに親を殺された奴が定期的に湧くな

でも阿部寛のホームページはLight Houseのスコア弱いから

ネタだろうけど目的と手段が入れ替わってるぞｗ
Light Houseのスコアを上げるモチベは検索上位に行くためだろう
阿部寛は一番上で、おそらくリストロジック上特別扱いも既になされているのではないか？
だとしたらLight Houseのスコアを上げるモチベはまったくないだろう

https://twitter.com/mizchi/status/1365163040019128320?s=19
> Svelte しばらく使ってみた感想だけど、これはたぶん将来的に Vue と食い合うことになると思う

ふむ、確かにそうかも
https://twitter.com/5chan_nel (5ch newer account)

この人当たり前体操してるな

>>288
確かにこれで良いんだけどな。
速いし読みやすいし。
なぜ企業はこうしないのだろうか。

適切な技術ではなく新しい技術を使うことが正義だと思ってるアホが多いから
jQueryはオワコンとかネガティブキャンペーンしてるやつが当てはまる

別にもう新しくもねえだろ
アホはいつまでも最新って思ってるらしいが

>>294
SSGってある意味でこれへの回帰では？
流石にHTML手打ちするのはアホらしいので、そうしないだけで

阿部寛のサイトは、内容がないから速い。
何の処理も、操作もない

そういう簡単なページは、誰でも作れるから、プロにお金を払わない

>>296
「新しい」っていうのは、何年以内のものを指す言葉じゃないぞ
何かと何かを比べて新しいかどうかだ

それとも別の何かが登場して
オワコンなったんか？

>>298
内容＝装飾とエフェクトとか思ってる人いるよね
中身が無いのに着飾ってるだけ

おう、そう思うならw3mでも使っとけ

>>299
お前みたいなゴミカスが吠えたところでうるせーゴミカスとしか思わない

みんなweb siteとweb appを同列に語ってるからややこしくなるんだって。

阿部のサイトは明らかに性的なwebサイトの部類。静的なものに関してはreactを使わずにhtmlと単純なjsで書くべき。もしくは templateとしてjsxを使うとか。

明らかに性的

性的（アダルト）サイトはトラフィックが半端ないらしいな。フロントでどうこうの世界では無さそう

試しに広告を1個追加しよう

笑

阿部寛の活動内容を伝えるって目的を考えればあれで十分だろ。
あれに糞エフェクト入れたら逆に鬱陶しいわ。

react使ったからって装飾もエフェクトもついてくれませんけども

Googleで「SSL」を検索すると、Reactを使った最新のサイトがダダーッと出てくる。
説明を読んでみる。

> 皆さんこんにちはテクノロジーエフェクト株式会社CEOの山田（仮名）です。
> 本日は、社会人1年目の皆さんのために「SSL」について解説します。

※クルクル回るエフェクトで1分待たされる

> 皆さんも社会人となったのでクレジットカードを持たれたのではないでしょうか？

※ ネットショッピングについて2ページ

> というわけで、SSLという仕組みが必要になったのです。
> 次回は担当役員佐藤が、SSLとは何か説明いたします。
> ご期待ください。

Reactと聞くだけでイラッとすると、あわしろ氏が言ってた。

推奨ＮＧワード： あわしろ

>>310
それサーバが遅すぎでは……

SSLの解説と称してネットショッピングについて説明し、内容豊富なコンテンツですと！！？？

ウェブアプリなので、ネットショッピングについての2ページが通信必要なしに表示できるんですよ！！

ってあほか！

普通にSSLの説明書けよ。

あわしろ氏は近年の風潮に危惧されているぞ！

あわしろ氏？あー登山家でしんじゃった人か

業界の重鎮を知らん奴はモグリ。

推奨ＮＧID:lzDnqtNz

あわしろってLinux界隈の人しか知らない

あわしろ氏は、フロント界隈はクズしか居ないと言ってた。

フロント=高卒初心者。

このスレはゴミクズが集まりやすいな

最近の高卒初心者は凄いな
私が初心者の頃だったらReact+Reduxとか絶対に理解できなかったわ

おっさんたちには理解できないんだよ
おれはおっさんだが

KENTAのサロンで学びなおすべき。

自分で宣伝するなよカス

動画だのサロンだのばかり見て、全然手を動かして（勉強して）無いんだなと言うのが伝わってくる

推奨ＮＧワード： KENTA

あわしろって誰や

推奨ＮＧワード： あわしろ

誰も知らない重鎮ｗ

ケンタガイジまだ生きとるんか？

カモ探しは大変やな

コロナで宣伝書き込み増えまくったよなｗ
生きるために必死ｗｗｗ

我々はjqueryに代わる世界標準なライブラリを求めている

この世からjavascript無くなればみんな幸せになるのに

心の底からどうでもいいと思う。くっだらないな。

Next.jsのIncremental static regeneration て
一定時間がたてば、必ず生成するのですか？

例えばマークダウンからページを生成するとして、マークダウンに変更があったら
ページも生成しなおさなければならないけど、なければ生成する必要がない。
だからキャッシュの更新時間と、ページのもとになるマークダウンの更新時間を比較して必要がなければ生成しないようにしたい。
そうするには、どの関数、どの引数戻り値をいじればいいのでしょうか？

>>339
必ず再生成されると思うよ。

>>340
そうなんですか。
単純なマークダウンの変換からのブログとかには向いてないのかな。
ありがとうございました。

もしかしたら再生成は変更された場合のみで、apiへの確認は毎回行うみたいな感じかも

たかがブログやるのにこんなに複雑で面倒くさいことしないといけないっておかしいだろ

cdnを挟めば、同じことできるしね。
でもcache頑張りたくないです！な場合は有効かもね

CMSも昔はMovableTypeのような静的なものが主流だったのが
WordPressで動的なものが主流にはなったものの遅いとかで
また静的に戻ろうとしているのかも知れないが
静的は静的でメンドクサイんだよなｗ
だから今後はサーバーの性能が上がるだけなのにわざわざ静的にする
必要性が普通は無い
よっぽど高アクセス対策しないと行けないみたいな特殊な例はあるかもしれないけどなｗ

昔よりサーバの性能向上鈍化してないかなあ

たかがブログやりたいだけなのにシステムがどうのこうのってのがおかしい
アメブロ並に簡単に作れるブログでいいわけ

揺り戻しでSSG(静的サイトジェネレータ)が静かに流行ってると聞いたが

そんなあなたにWordPress。なんだけど、キャッシュとか使っても思いの外鈍足。安いCDN無いかなぁ

wordpressがクソな理由はphpが介入することなんだよね

>>348
今こそMovableType復活の時

リファレンスとかニュースみたいな情報提供系サイトは極限まで軽くして穂いい。
そっから必要最低限の機能を追加してほしい。

要するに、長年積み重ねてきた中の無駄要素を排除して再構築。

>>350
php7にしていない古いのが一杯ありそうだし
そういうホスティングしているところが詰め込み過ぎで遅いというのもある
php自体は今は相当早くなってるよ
ruby(笑)なんかよりかなり早いし

phpがクソというわけで言ったわけじゃなかった。すまんこ

webの開発をわざわざphpでしたくないよねっていう話。
jsで統一したい。

現在wordpressにphpが使われてる理由に合理的なものってないよね。初期設計がそうだからとかでしょ？

jsで統一するのは良いが、非同期で統一したくない

まあ適材適所だよね

久しぶりにjsで書いて「なんだこれ？」「どうしてこうなった」ってなる大体の原因は非同期を忘れたから

ま、phpも他もそれぞれそういうのあるんやけどね

jsのシンタックスと伝統的なサーバーサイドの書き方がいまいち相性悪いんだよね
ちょっと複雑なことやると
あらゆるところでasync await連発しなきゃいけないし
サーバーサイドからしたら非同期の要素なんて入らなくて
シーケンシャルに高速に動いて欲しい
その方がパフォーマンス計測もデバッグもしやすい

伝統的なサーバーサイドってなんやねん
async awaitが嫌なら、goもrustもc#も大体の言語書けないわ。

jqueryおじさんと非同期おじさんという二大ガイジがいるんだなあ

rubyガイジが一番酷い気がするｗ

非同期なJavaScriptに慣れすぎたのか、同期的な言語使うと、これ一見自然だけど割り込みを隠蔽してて良くないよな。
みたいな感覚になる

なんならthisもわりと自然に感じる。
だがprototypeとnewの関係。オメーは駄目だ

そんでキミたちはどんなSPAアプリ作ってんの？
こっちはちょっと特殊な業界でreactフロントの業務基幹システム作っとる

>>358
複雑なことやるならpromise使うんやで

サーバーサイドが非同期いらないとはこれいかに

それな。nodeがc10k問題をコード上特に工夫することもなく易々と突破したときの他勢力のsurprised pikachu faceといったらｗ

基本、CUI は同期。
GUI みたいに割り込まれる事がないから

だから、サーバー言語のRuby は同期。
非同期はオプショナル

一方、JavaScript はGUI が先にあったので、非同期が基本

Node.js がRubyを真似て作られたのが、2010ぐらい。
Rubyの10年後ぐらい

推奨ＮＧワード： Ruby

CUIが割り込み無いとか、何言ってんだよ。割り込みなんてコンピュータの基礎じゃん。
sleepも割り込み、ネットワーク応答も割り込み。OSなくたって割り込みは存在するのに

JavaScriptが非同期を意識したコードを書かないといけないというのが根本的な問題
しかも常に非同期なのではなく同期的に処理される場合もある

例えばファイル読み込みで非同期処理は必要か？
SQLのフェッチで非同期は必要か？
その辺りを考えれば俺のいってることは理解できるだろう

シングルスレッドのJavaScriptは非同期にせざるを得ない
他の言語であればマルチスレッドで実行するので非同期はいらない

DBアクセスとかマルチスレッドこそ非同期要るじゃん。
同期処理と非同期が混ざってるのが良くないってのは確かにそう。ただ、現在の環境では希少かと。

>>373
いらんよ。どうせデータベースから値を取得しないとその次の処理はできないんだから

イマイチわからんのだけど、node.jsってプロセスが一つだからリクエストあってもグローバル変数は共有されるよね
サーバーレスだとアクションのたびにプロセスが立ち上がるからグローバル変数は共有されないの？
となるとnode.jsのメリットってどうなるんですか？

>>375
お前がいいたいのは何だ？
グローバル変数の有無がどうメリットの話に結びつくんだ？
そもそもお前はnode.jsのメリットがなんだと思ってたんだ？

>>375
プロセス間でどうやって変数を共有するんだよ

>>375
狂ってる

>>376
メリットはプロセスが一個ってこと
グローバル変数はどうとかは知らん

>>377
知らんけどメリットあるっていろんなnode説明にあるけど

>>378
まあな

>>375
調べてみたら確かにそうなんだね。勉強になった。

シングルスレッドだとプロセスが独立してないからグローバル変数が共有されるんだ。

> サーバーレスだと独立してプロセスが走る
リソースは有限で、無限にプロセスが走るわけではないから、メリットはあると思うよ
https://www.grandream.jp/blog/understanding-aws-lambda-container/

>>379
> 知らんけどメリットあるっていろんなnode説明にあるけど

じゃあお前がnodeのメリットを勉強しろってだけの話だろ

>>380
> シングルスレッドだとプロセスが独立してないからグローバル変数が共有されるんだ。

マルチスレッドでもグローバル変数は共有されるが？
そもそも一部のメモリを共有したいという要求があって
マルチスレッドが登場したというのに

それから共有されるからなんだっていうんだよ？
なんにもデメリットはないだろ

>>383
スレッド間では共有されないでしょ？

Next.jsに手を出したけども、始めるまで勝手にイメージしてたSSR vs SSGの図式は間違ってた。
そこはハイブリッドで良いし、結構簡単に切り替えられるんやな

グローバル変数はマルチスレッドで「不完全に共用」される。（ロックや排他制御しなければ）
他のスレッドから見られない共有されない変数は「スレッドローカル」変数。
スレッドはそもそも時分割処理をするために生まれたのであって変数を共有するためじゃない。
また物理的なメニーCPUコアが最初でもない。

>>373
当然ながら非同期はマルチスレッドじゃない。

Vue vs React vs Svelte vs Angularとかもう飽きたわ根本的にJSX系はいい加減にしてほしい

>>384
スレッドはメモリを共有できるという特徴があるんだよ
勉強しなおしてきな

マルチスレッドの地獄に比べたら非同期なんて大したことないだろ

>>386
> スレッドはそもそも時分割処理をするために生まれたのであって変数を共有するためじゃない。

時分割処理をするなら複数プロセスを起動することで実現していた。
それが古来のUNIXのマルチタスク機能
スレッドは後からメモリを共有できる改良版として作られたもの

>>388
マルチスレッドは地獄だから、局所的に使用する
グローバル変数を含むは共有メモリ
特別注意してコーディングすることになる

そしてマルチスレッドに関する局所的なコードを
除く、大部分のコードは同期的な処理で書きやすい
つまりマルチスレッドの地獄はごくわずかしかない

JavaScriptの非同期は、プログラム全体にわたって広く使われる

スレッドとプロセスの違いくらい勉強しとけよ

ああ俺がTwitterで嫌いな部分ってルビーだったんだ

プログラムなんだからメモリに展開されるから、共有される可能性はあるだろうけどね。

ある程度ライブラリで安全性を担保しようと頑張って実装してるでしょ、多分。

libuvはシングルスレッドだから、設計的にそこら辺の安全性を担保するのが難しいって話をしているよ

ファイバとかコルーチンがトレンド入りですよ。

繰り返すが、マルチスレッドもシングルスレッドもメモリは共有される

マルチスレッドの場合は複数のスレッドが同じ変数（グローバル変数）を
参照する必要があるから注意が必要。シングルスレッドはその必要がない
からシングルスレッドの方が簡単

それと非同期の話は関係ない
シングルスレッドの方が簡単だが、そうすると同時に一つの処理しか行えないから
シングルスレッドの問題を解決するのが非同期

非同期でシングルスレッドの問題を解決出来るが
同期と非同期のコードが混ざることになりややこしくなる
シングルスレッド＋非同期で頑張るよりも、マルチスレッドの方が簡単になることも多い

ストランドとか知ってる？

あわしろ氏が提案して、いまC++ Networking TS で標準化中だけど。

よしよし

非同期ではなく
完了まで待って次に移行するメソッドを
コールバックを一切排除して
関数定義側のみで定義する方法はないのか。
呼び出し側に特殊な構文が必要なのは無しにしてくれ
呼び出し側をそもそも関数で囲む必要がある
というオチはやめにしてくれ。
メソッド内で呼び出される非同期処理も
その内部の非同期呼び出しも
全部完了まで待つようにしてくれ

>>399
アホすぎる

人はそれを同期と呼ぶ

>>399
それがasync awaitでしょ

非同期だけど同期的に見せたいっていうのは
やっぱり同期的な方が人間にはわかりやすいってことなんだよな

そらそうよ。
並行して二つ仕事やるよか、一つづつこなす方が明らかに仕事の精度が高い。

>>389
The history of threads http://www.faqs.org/faqs/os-research/part1/section-10.html
コピペ＆略

1965年にはBerkeley Timesharing Systemでと呼んでいた。しかしそれまでに並行性の概念
がなかったのではなく、当時は「プロセス」と呼ばれていた。

1970年にMax SmithがMultics上でスレッドのプロトタイプを作っていて、これは1つの重量
プロセスに複数のスタックを持たせる試みだった。
プログラミング言語における「スレッド」の創始者はおそらくIBMによるPL/I(1965〜)
TASKコールはプロセスにマップされないし、スレッド間どうしはメモリが丸見え。

そしてUnixが出現する。Unixは「プロセス」という言葉を「スレッド＋仮想アドレス空間」の
意味に使った。そういうわけで、Unix的な意味での「プロセス」は仮想アドレス空間の切り替え
を伴う重たいものになってしまった。プロセスはそれぞれが個別にアドレス空間を持ってるから
メモリを共有することはできないがパイプやシグナルを使って相互作用することはできた。共有
メモリの機能が追加されるのはもっと後の話。

>>405
つづき

しばらくすると、Unixユーザーは、メモリを共有できる古いプロセスを懐かしむようになりました。
これがスレッドの「発明」につながった。つまり、1つのUnixプロセスのアドレス空間を共有する
古いスタイルのプロセスである。重い」Unixプロセスとは対照的に、「軽い」とも呼ばれていました。
この区別は、70年代後半から80年代前半、つまり最初の「マイクロカーネル」
（Thoth（V-kernelとQNXの前身）、Amoeba、Chorus、RIG-Accent-Machファミリーなど）にまでさかのぼります。

UNIX屋はスレッドは後からメモリを共有できる改良版として作られたものと考えるが、元々は
時分割処理をするシステムの発想があったから、貴重な計算リソースを時分割するだけのOSが
最初です。これがユーザー側で使えるようになった段階をスレッドと呼びたいならそうしたら
ええですが、伝えたいことは以上です

全部最初から訳したほうが良さそうｗ

[93-04-21-13-32.11] [92-01-27-17-05.54] 逐次的な制御の流れとしてのスレッドの概念は、
少なくとも1965年のBerkeley Timesharing Systemにさかのぼります。
ただ、当時はスレッドとは呼ばれておらず プロセスと呼ばれていました[Dijkstra, 65]。
プロセスは共有変数、セマフォ、および同様の手段によって相互に作用しました。
マックス・スミスは1970年頃、Multics上でスレッド実装のプロトタイプを作っていました。
アックグラウンドコンパイルをサポートしていました。

スレッドの最も重要な祖先は、1965年頃に開発されたプログラミング言語 1965年頃に開発されたプログラミング言語「PL/I」です。
IBMが定義したこの言語は IBMによって定義されたこの言語は、`CALL XXX (A, B) TASK;' という構文を提供していました。
これはXXXのスレッドをフォークするものです。 IBMのコンパイラがこの機能を実装していたかどうかは
定かではありませんが この機能が実装されていたかどうかは定かではありませんが Multicsが設計されている間、
この機能は綿密に検討されました。定義されたTASKコールはプロセスにマッピングされませんでした。
定義されたTASKコールはプロセスに対応できないと判断されました。 そこで、Multicsは別の方向へ
TASK機能はIBMによってPL/Iから削除されました。ABNORMAL属性やその他多くの奇妙なものと一緒にね。

その後、1970年代初頭にUnixが登場しました。 Unixの「プロセス」の概念は、制御のシーケンシャルなスレッドに加えて、
仮想アドレス空間を持つようになりました（ちなみに、Unixのプロセスの概念は、Multicsのプロセス設計[Saltzer, 66]から直接派生したものです）。
ですから、Unixの意味での「プロセス」は非常にヘビー級のマシンです。 プロセスはメモリを共有できないので
（それぞれが独自のアドレス空間を持っている）、パイプやシグナルなどを通じて相互に作用します。
共有メモリ（これもかなり厄介なメカニズムです）はずっと後になって追加されました。

しばらくすると、Unixユーザーは、メモリを共有できる古いプロセスを懐かしむようになりました。
これがスレッドの「発明」につながった。つまり、1つのUnixプロセスのアドレス空間を共有する
古いスタイルのプロセスである。重い」Unixプロセスとは対照的に、「軽い」とも呼ばれていました。
この区別は、70年代後半から80年代前半、つまり最初の「マイクロカーネル」
（Thoth（V-kernelとQNXの前身）、Amoeba、Chorus、RIG-Accent-Machファミリーなど）にまでさかのぼります。

>>407
> 元々は時分割処理をするシステムの発想があったから、
どこを見ていってますか？

>>412
「スレッド」の創始者はおそらくIBMによるPL/I(1965〜)

時分割処理をするシステムの発想があったがそれはスレッドと呼ばれておらず
プロセスと呼ばれていたそうです。

じゃあスレッドじゃなくてプロセスですよね

>>413
それはスレッドと呼ばれておらず、実装もされなかったんですよね？

そうしたいならそうすればええやん？UNIX屋はこれだから嫌だ、しつこい
そもそも別メモリアドレスに別処理を貼り付けるだけの処理で、メモリ共有が先という発想がおかしい
以上です。

重要なのはここですね。

> しばらくすると、Unixユーザーは、メモリを共有できる古いプロセスを懐かしむようになりました。
> これがスレッドの「発明」につながった。つまり、1つのUnixプロセスのアドレス空間を共有する

メモリを共有できる古いやつ＝プロセス
スレッドの発明

>>416
「メモリを共有できる古い”プロセス”」がどうかしたのでしょうか？

この文章の主張は

1. 古いプロセスはメモリが共有されていた
2. でもメモリが共有されていたのだからスレッドの祖先だ
3. つまり、メモリの共有の有無が、プロセスとスレッドの違いである

という結論になりませんか？

スレチはやめろっての

スレッドを発明したのは、あわしろ氏の可能性もあるような気がするのだが。

なんでそんな基礎レベルのとこをドヤ顔ではっぴょうかいしてんだか……

Vueはなぜいかんのか
役割分担がしっかりしてて完璧にみえる

俺はvue好きだよ
仕事ではangularメインだが

過去に３回ほどVueのプロジェクトやったけど、途中参加でもある程度作ってあって
画面追加するぐらいなら、他の画面の作りを見て大抵の人は出来てたので
理解のしやすさはかなり高いかと思う

何も無い所から作れというのは大変だろうけどね

ある程度の規模まではvueがよくて規模が大きくなるとreactがいいとは聞くものの、具体的にどういいのか悪いのかのはっきりした答えを今まで聞いたことがない
みんな説明できずにモヤっとしかわからんの？

Reactしか使ってないからなぁ。
でも大規模に向いてるのはわかる。状態をあんまり持たないし、疎結合にしやすいかんね

俺も規模小さくてもわざわざvueに手は伸びないなｗ
ちょっとしたものならバニラjs
それ以上は全部reactだわ

TypeScriptには生きて欲しいけど、Angularまじ死んで欲しい、誰得だよ

HTMLのscriptタグの中で
require使えますか？
htmlからreactコードをどうやって読み込めばいいでしょうか？

今ならscriptタグにmodule属性付けてimport使った方が楽なのでは？ボブは訝しんだ

ごめん下の行読んでなかった。
公式チュートリアルに書いてあるよ。

すっかり慣れちゃったから忘れてたけど、WebpackとReact覚えるのは初心者にはハードル高いな。場合によってはnpmも同時進行。
かといってcreate-react-appだと、普通運転免許も持ってないのにいきなり重機のハンドル握ってるみたいな感じで戸惑うし

まあ初心者はバンドルとかは特にしなくてもいいでしょ
その辺でハマるのは目に見えてる

webpackまわりはマジでどうにかしてシンプルにして欲しい

webpakeから解放されたのがdeno
denoやってるやついる？

今はLaravelを利用しているのでLaravel Mixで割と簡単に設定は書いている
フロントはVueを使ってる

Denoみたいに簡単に出来るようになれば良いのだけどもうちょっと様子見かな

koaが流行らなかったのと同じ流れになりそう

Ruby on Rails 6 の、Asset Pipeline では、
JavaScript は、Node.js, yarn, webpack がデフォルト

ただし、CSS は、Sprockets のまま。
webpack だと遅いから

アコーディオンとかバーガーメニューとか
折りたたみ式のUI考えたやつ全般に殺意が湧く

ゲームアプリみたいにXボタンを押したら
メニューが開くとかにしてほしかったんか？

Reactで業務アプリをフロント1人で開発できる奴ってどのくらいいる？
大企業レベルのシステム
あらゆるシステムがAPI連携されつつデータをReactで管理してそれらが全て権限毎にcrudできるくらい

他部署のエンジニアやインフラ・バックエンドエンジニアは含まない

そんなん規模と要件次第だし、イントラ内かそれ以外かで全然……
と思ったらバックエンドは全部やってくれるのか、それならう～んどうなんでしょ

Ruby on Rails, Bootstrap, React の方が、はるかに簡単だろ。
サーバーからHTML を返すから

これらをすべて、JavaScript で作ると思うと、ゾッとする

>>444
規模が小さくても大きくてもやることは少ないか多いかの違い
ただGoogleAnalyticsみたいな独特なUIだときついかも？

規模に合わせて納期がそのぶん伸びるならある程度の技術力があれば可能では？
業務アプリなら単一ページってわけにも行かないだろうし、React単体だとルーティングが面倒なので俺ならNext.jsとか使うけど

要件がしっかりしてるなら、とか
複雑なスタイルが必要、とか
そういうのがなければいけるかもだけど、
大規模で１人てのが何かあったときに4ぬ

>>447
単一ページではないからnext使ってもよいかな
さすがに素のReactだと厳しいからライブラリは使うけれども

>>448
提案してみたがReactできる人材がいなくてね

>要件がしっかりしてるなら、とか
そんなプロジェクト見たことないわ

>>447
ルーティングが面倒？？

マジで今のフロントエンドは空き巣だと思う
サーバーサイドの人は今更フロントに来たがらないし
これまでフロントの人はReactとか触れるレベルの人が少ない
仕事多すぎて過労死するわ

>>451
React Routerで頑張るのがめんどい。かといって1ページずつベタ書きはしたくない。読み込むデータも重複を避けて節約したい。
のでNext.jsでサクッとやりたい

>>452
そうなの？ 勉強会とか見てる感じ、Reactと色々組み合わせてバリバリやってます～みたいな奴多くて、フロント専心だとReactできて当たりになりつつあるかと思ってた。
生DOMとJavaScriptを使いこなせていれば、React覚えるのなんてそれほどの苦じゃないと思うんだけどなぁ。

>>454
そういう技術的なとこだけやってりゃいいって分野でもないだろ。
フロントはめちゃくちゃな要望言ってくるユーザーばっかな印象がある。

>>455
452の言うこれまでのフロントの人は当然今までそれをこなしてきていると思うが。

>>455
それはそうかもだけど。
それはフロントの顧客対応の話であって、技術であるReactは別の次元の話では？

フロントでReactガッツリできる人はほとんどいないよな。
できるといって実際にはアプリ開発できない。

プログラミングできる＝アプリ開発ができる

わけではない。

Next.jsはルーティング周りとかもろもろ親切過ぎて、アレから入ると基本的なところの理解が疎かになりそうな予感がする

Next.jsはReact知ってる使ってる人が使うものだからあれで良いんじゃないかな。
React知らないならSvelteとか行く……と思うんだけど、いきなりNext.jsって人もいるの？

reactのみで作ったあと
nextを知って
全部作り直したくなった思い出

nextはssg使わないのならvercel使わなくていいの？
vercel使うとベンダーロックしそうで怖い

Vercel使わなくてもSSG使えるよ。
画像最適化をSSGで使いたい場合はVercelなりCDNの利用が必要になるみたい

なるほど！

DOMとJavaScriptに精通しててReact使ってウェブアプリ作れるレベルならブルーオーシャンなの？

はい
React使えますってだけで即採用の会社は多い
それほど難しい概念なのよ
ついでにサーバーサイドもできますってなったら年収1000万以上は確実か

ははは、ご冗談を。
そんな条件鯖立ててWeb技術勉強してれば普通に満たせるやんけ

Reactできる＝アプリ作れる
なわけない

プログラミングできる奴が全員アプリ作れるのか？

Reactできる=Reactでアプリ作れるのつもりだが？
そんなのは当たり前だろ
アプリ作れないのにReactできるってなんだよそれは
嘘つきだろ

アプリ作る以外にReactの勉強する方法を思いつかない

>>468
ちょっと何言ってるか分からない

reactできるもアプリ作れるも意味が広すぎるわ

つまりツイッターやfacebookみたいなものちょい劣化版を一人で開発できるレベルがアプリ開発できるという

できるんだよな？

時間は相応にかかるとして、まあできるだろうな

まあ色んな前提を抜きにすりゃあなあ

フロントは作れるけど、ああいう数千万ユーザの同時アクセスに耐える技術とか、ユーザを集める技術とかは無いです

そりゃあreactはフロントサイドのフレームワークなんだし当たり前よな

component.vueで「なんでこの変数undefinedなんだよ！」って小一時間やってたら、
途中で変数に$付けてるのに気付いた
消したら動いたのでコーヒー飲んでパソコンを落とした

ガシャーン

svelte触ってみた
意外と良いのか？
ReactとVueを同時に触っているような不思議な感覚

大規模開発にはやはりreduxが一番なの？

hooksでよか

Next.jsのWebAPI機能って使ってる？
バリデーション無いのが嫌だからついついFastify使っちゃうけど、なんか良いやり方あんのかな？

redux hooks便利だよな

SSRをやりたい、かつVercel使いたくない場合はNextjsよりNuxtjsの方がいいんすかね？

Naxtjs一択

Nixtjs一択

NextかNuxtかはVercel云々よりReactかVueかで選ぶものかと。Nodeさえ動けば動くし

いろいろありすぎて何がなんだか

最近のJSは落ち着いたとはなんだったのか
SSAの議論やHooksの登場で無限の可能性が出て
さらに混沌としてきた

SSAて何？
Static Single Assignment？
さいたまスーパーアリーナ？

ReactいろんなhookあるけどなんだかんだでuseStateとuseEffectとuseRefしか使ってない気がしてきた

>>490
数年前の混沌と比べればかなり改善したと思うよ
とりあえずreactと指針決めやすいだけ随分マシ

ブラウザに閉じ込められた世界なぞまっぴらだ

>>492
useCallbackもなんかよく分からないけど使うだろ

>>495
useCallbackは分かって使わないとメリット無くね？

>>492
計算コストが高いものはuseMemoは必須

useLayoutEffectとかuseImpなんとかとか使い所全く分からんな

>>497
Nextに行ったので、計算コスト掛かりそうなのはなるべくSSGしちゃうからなぁ

>>492
useReducerは?

>>500
switch文が嫌いなので……という冗談は置いといて、最近使えた局面あったわ。復習大事だなぁ。

復讐は大事

やっぱredux-saga使おうかと思い始めてる。hooksでも非同期処理は全然楽にならんし。

非同期はスリル、ショック、suspense

なんでredux、hooksと
非同期処理が関係すんの？

webのUI部品なんて死ぬほどあるのに
Reactコンポーネント化して再利用する価値あるか？

具体的な文言や色、
縦横サイズやマージン、文字の大きさ
背景画像やアイコンはコンポーネント内部に静的に組み込むの？

UIパーツはjquery UIやbootstrapを完全に利用するだけじゃ
ダメなのか？
つまり、再利用パーツを利用して楽をするのはいいが
それを自ら定義する必要性がどれだけあるのか
車輪の再発明ではないのか？

javascript制御やイベントリスナ、ajaxは再利用諦めて
使い捨てるしかないと思うが

Ruby on Rails で、Bootstrap, React から、部品をコピペして使っているだけ

HTML, CSS は、よく知らない

SASS は知ってる。
JavaScript も、そこそこ知ってる

>>506
デザインはコンポーネントに引数で渡せば良いじゃん。
ロジックは使い回せるじゃん。
なんなら自分で作らずに、一般的なコンポーネント使っても良いし。

>>508
それが一番だな
引数を組み立てるルールと
コールバックの仕様を覚えるのは面倒だが
それは他のライブラリでも同じか

Reactのコンポーネント定義の構文を覚えたり
トランスパイルだかなんだかを自作で行う
メリットは皆無だと思う

推奨ＮＧワード： Ruby
推奨ＮＧワード： Rails
推奨ＮＧワード： Bootstrap
推奨ＮＧワード： 知らない
推奨ＮＧワード： 知ってる

svelteのツールがもっと揃ったらsvelteに手出したい...

しかし荒らしが暴れてた頃は、もう5chは老害しかおらんのやなオワコンなんやなと思ってたけど、そうでもないもんだなぁ

>>512
賢い人々は、みな twitter に移ったと聞いていますが？

ケンタガイジだけ隔離しとけばよか

しとけよばか

推奨ＮＧワード： KENTA
推奨ＮＧワード： あわしろ

今のTwitterは地獄だろ
マウントの取り合い
何かあればすぐ袋叩き
まだ掲示板の方が健全だと思う

>>516
あわしろ氏、って最近よく聞きますが、どんな人ですか？

>>517
確かに実名でマウント合戦とか壮絶な気がしますね‥

>>518
日本でトップクラスのプログラマー
日本一のケンタとほぼ互角と言われている

推奨ＮＧワード： KENTA
推奨ＮＧワード： ケンタ
推奨ＮＧワード： あわしろ

あわしろは、Linux 総帥。
たまに、日経Linux に記事を書いてる

昔、Linux板に、デル男という、
Xeon で、数十のディス鳥を起動した動画を上げていた香具師がいた

動画内で、他人の音楽を無断使用していたので、すべての動画を削除して消えたけど、
そいつが、あわしろと推測されている

数十のディス鳥を起動できるのは、世界でもデル男だけ

推奨ＮＧワード： あわしろ
推奨ＮＧワード： デル男
推奨ＮＧワード： KENTA
推奨ＮＧワード： ケンタ
推奨ＮＧワード： Ruby
推奨ＮＧワード： Rails

>>522
天才すぎる

推奨ＮＧワード： 総帥
推奨ＮＧワード： 日経
推奨ＮＧワード： ディス鳥
推奨ＮＧワード： 動画
推奨ＮＧワード： 香具師
推奨ＮＧワード： 世界でも

これあれだろ、あわしろ信者に見せかけたアンチだ

というアンチにみせかけたステマ

あわしろ氏は、僕の最大のアンチは僕自身だと言ってた。

あくどいオンラインサロンではないんだろうけど
ここまで誰かに心酔できるってちょっと危ないよな

教祖様がこう仰っていた！の一点張り
自分の意見が一つもない

vueとreactどっちが楽に覚えられる？
出来ればフロント触りたくなかったんだけど次やらされそう…

最初ぱっと見たとき10秒でvueファイルは大まかにやってること理解できたけど、reactは無理だった
JS、TSの熟練度にも依るだろうから色々見たほうがええんでない？

>>529
プペの悪口は許さん

>>530
用途によるかと……。
Reactはある程度のJavaScriptやDOM知識は求められるし、hookの動作に最初は混乱する。
その代わり覚えちゃえばかなりフロント開発が楽になる。

>>531>>533
なるほど～ほぼ知識ゼロなんでとりあえずvueから触ってみますわ
どうもサンクスです！

すまんSPAの認証ってどうやるん？

ログイン
{id,password}をOAuth鯖？にpost→t:={Token, リフレッシュToken}戻り
tをLocalStrageに保存←これでええんか？クッキー？XSS対策は？

API
LocalStrageからtを取得
TokenをヘッダにのっけてGET/POST/他
リクエストフォージェリ対策とか要らんの？

乗っ取られたとき？？
LocalStrageかたtを取得
リフレッシュTokenを乗っけてリフレッシュendpointにpost？←リフレッシュよくわからない

OAUTHやOIDCはブログパクるしかない
言葉で言い表すのは無理

リダイレクトlocationを使うことを前提として
強制的に画面遷移を伴うのでSPAではおそらく無理

とりあえずlocalstorageに認証情報を保存するのはバッドプラクティスとしか
サードパーティの認証サービス使うかHTTP OnlyのCookieで認証するのが一番いいのでは？

せやな
調べたがトークンはクッキーがいいらしい
CSRFトークンはヘッダ
相変わらずリフレッシュはよくわからない
このへん標準化しといてほしいね