Vue vs React vs Svelte Part.7
レス数が1000を超えています。これ以上書き込みはできません。
実際どうなん？
※Angularは残念ながら全く話題にならなかったのでSvelteに差し替えました
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Svelte
https://svelte.dev/
※前スレ
Vue vs React vs Svelte Part.6
https://mevius.5ch.net/test/read.cgi/tech/1603771745/
★ここではjQuery, Ruby, C#, Blazorの話題は禁止です
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
Angular, Next, Nuxt, Sapper, Gatsby, VuePress, RedWoodなどはおｋ。 >>2
GatsbyがややNegativeに動いてるのが意外。Svelteはみんな試し出してるのが分かるね。しかしReact圧倒的だな…
https://2020.stateofjs.com/en-US/technologies/arrows_overview react、reduxあたりまではいいけどホンマにredux-sagaとか使ってんのか？ってのは思う。 redux sagaの良さを理解できてない。thunkもそうだけど。
素直にサーバーからのレスポンス待ってdispatchすれば良いと思うけどね 昔は使われた。
今はrecoilあるしわざわざ新しく始めることはない。 reduxはオワコンだと思う
俺は前から現場でアクションをswitch caseで管理する
バカらしさを批判してきたが
なぜか誰も聞き入れることはなかった
あんなのアクションの爆発的増加を生んで管理できなくなるのは明らか
C言語かよ ReactやVueのアプリの設定値ってどこに設定するの？
Widowsネイティブアプリだとiniファイルとかconfigファイルの相当するファイルだけど。 >>8
それはお前のアプリケーションではreduxが必要なかったってだけでしょ。 >>11
意図としてはそうかもです。
ネイティブアプリの設定は外部設定ファイルに個別設定が多かったのですが、
それは出来ないのでしょうか？
(ネイティブアプリの場合)
xxxxx.exe
xxxxx.ini --- これに相当するもの >>12
.env が一般的かも
.env reactとかで調べてみると出てくると思う ContextAPIを"正しく"扱うための学習コストを考えたらRedux toolkitで良くない？って思うんだけどなぁ >>4
vue.jsすごいな85%もあるよ
んで、その下に書いてある、vue.js 12ってのは何だ？
Backboneは18だぞ。jQueryは22だぞ 今からreduxまじめに勉強するのめんどいから早くrecoilに殺されてくれ redux使って開発したけど面倒くさすぎる
こんなゴミクソ誰が考え出したんだか jotaiとrecoil何が違うのかいまいち理解してない reactみたいに使うライブラリが徐々に更新されるような軽いフレームが好きなんだが、
やっぱ趣味でいじってるのと仕事でやるのは違うかもな。 皆ユーザ認証は何使ってるん？
やっぱりAuth0？ recoilこれダメだろ。。reduxの100倍くらいデータの流れがわからなくなるわ。。 >>29
firebaseも人気あるみたいだね。
使ったことあるけどライブラリがでかいイメージある auth0なんか覚えること多すぎて覚えるまでかなりしんどそう JWT一択
仕様としてはかなり簡単だし
この程度はフロントエンドの人でも自力で実装すべき いやJWTがバックエンドありきだろ…
それを何使ってますかって話。 普通に自前実装だが何を使うとは？
ライブラリとかフレームワークのこと？ 自前実装は絶対にしない方がいい。
jwtの認証は簡単に作れるけど、セキュリティホールになりえるからセキュリティのプロの人たちが実装した idaas使った方がいい まぁ、自分たちがセキュリティに精通してると胸張って言える人は自前実装でもいいと思うけど。 そのライブラリがセキュアだという保証は？
それにライブラリがない言語は自前しかないし
セキュリティはもうライブラリ作者の個人が担保するものではないよ
セキュリティ担当者がいないならすぐ雇うか
どこかに依頼すべき セキュリティに関しては、完璧な知識を持った上でシステムを隅々まで理解し、時節に変化があれば即時にキャッチし、情報が漏れたときに全責任を負う。自前でやるならそれぐらいの覚悟が必要だと感じてる。 セキュリティを専門とするエンジニア（コンピューターサイエンスに深い理解を待ってる人）を雇えるならいいよ。
でも大抵の企業がセキュリティ担当に1000マン以上出して雇おう！って感じではないでしょ
auth0とかfirebaseはセキュリティに精通しているエンジニアを雇ってるからね。どっちが信用できるかの問題だよ。自社のエンジニアを信用するならそれでいいと思う。
クリティカルな部分のセキュリティに関しては、専門家じゃないやつの理解って大切だけど、本質的にはあまり意味ないと思ってる。何故なら知識が浅いから >>41
これに関しては自社で実装しててもしなくても一緒だと思う まず自前実装ってどこからどこまでの話なのか
自社のバックエンド側で認証の仕様が決められてて
それに基づいてフロントエンド側を実装するって話なら分かるが ここでもう認証はこれにしろ！ってのを決着つけてほしい vue3になって更に混沌としてきた感すごい
節操なさすぎだろこれ vue3が出て以降npm trendsじゃangularと抜きつ抜かれつだったのが明確に離されて着てる印象 >>51
呼んだか？
https://w3techs.com/technologies/history_overview/javascript_library/all/y
jQueryのシェアは2021年1月時点で77.2%だったが
1ヶ月で77.3%に増えた。まだ増加傾向にあるようだ。
なおReactのシェアは0.4%。その程度のレベル VueはcompositionAPIの影響でごちゃごちゃするんだろうなぁーっていう感じ >>56
とりあえずreact hooksパクってみました感が凄い
調べれば調べるほどreactで良くね？ってなる >>60
Vueの売りはフロントエンド技術者にとっての分かりやすさだったけど今となっては無いよね
reactの方が明らかに明確で分かりやすい
全然違う方向に進化して欲しかったから残念だわ いつものことじゃん。思想が明確じゃないから
ぶくぶくと機能を追加して破綻する
「シンプルでわかりやすい」というのはどれもが主張してくるメリットだけど
それは単にできたばっかりで実装が追いついてないだけ
バージョンアップするたびに複雑になっていく
そしてまた次の「シンプルでわかりやすい」新しいフレームワークが
登場しまたぶくぶくと太って繰り返し
基本的な機能に絞り込むという発想がない
jQueryはその点最初からブレずにやってるから
こうやって長く使い続けられる jQueryは先進的な層から誰も目を付けられてないから発展しないんだろうね
結果的にそういう利点も生まれるわな vueって最初better angular的な思想だったのに
Reactを取り入れて魔改造してキメラになったイメージ Reactとvueとアンギュラーの違いが抽象的にしか説明しとらんじゃん
具体的に何がよくて何が嫌なのか伝えられんの？ みんなvue2→reactに行ってんの？
せっかくvueの勉強始めたのに 両方やったらええわ。
そこまで大きな違いなんかないから。 一部のピエロが最先端を〜最先端を〜と言ってるが
世界中の大半の人々は最先端になんか興味ないんだ >>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使ってるから ネットの情報見てても、同じ事してる記事がJSとTSでそれぞれあったら、TSの方がレベル高い傾向あるね。
稀にこいつぜってーC♯かJava屋だ、みたいなTSらしからぬコードなことあるけど。 そうそう。TS使ってる所がマトモな所で
マトモな所をみると全部TSを使ってる TSを作ったのはマイクロソフト
やはり開発ツール大手の言語が一番信用できる >>31
Reduxは一元管理
Recoilは分散管理
だから当然
同じ球技として野球とサッカーを比べてるみたいなもんだ React触ってるやつの気が知れんよね
JSXとかいうゴミ未満は触る気まじでおきない
CSSもライブラリなしだとどうしようもないしバニラHTML、CSS、JSのサイトを置き換えるのに向いてなさすぎる。置き換えたら置き換えたら他ライブラリに不可逆だし 他のライブラリと互換性がないのはどのライブラリでも基本同じでは？
Reduxとかは一応Vueとかでも使えるけど > Hooksがなかったら正直vue使ってたと思うわ
このスレ史上一番の同意 >>86
IT老人が新しい技術触りたくないだけのワガママにしか聞こえないっす
ｊQueryを永遠に触ってれば良いんじゃないっすか？ まあクソ技術でも新しいってだけで喜んで使うバカも大概老害だけどな。 新しい技術に飛びついた結果が、vueなんですよね？ｗ 一年くらい前にRouterのみ(状態管理？なにそれ)でダイナモのdataを出し入れする奴を1から作ったことあるレベルなんだが
今から簡単な管理画面作ろうとしたらどっちがええんや？
ReactAdminとかいうのがあるしやっぱりReactかな？
フロントエンド極めるぜーとかは無い コーポレートサイトでもJamstack使う感じか？
Gatsbyとnextjsどっちがいい？ コーポレートサイトこそ速度重視(SEO)でJamstackかなと思ってる。
後は好み コーポレートサイトなんてWPでさっくり作ってCDNでキャッシュすれば済むんじゃないの？
わざわざJamstack構成で手書きとかする意味あるの？ それ、結局慣れてるってだけでWP+CDNのほうがふつうに複雑な構成だと思うんだけど…
WPにはApacheやphpも含んでるわけだろ？
慣れ親しんだ構成は簡単（に感じる）ただそれだけでは？ それってSSRでないといけないのかどうか、を考えたら自ずと答えは出てくると思うけどな svelte ってdocument.getElementbyIdできないよね？ Vue3なんてでるのか
Nuxtが対応したら考えてみるかな わかりました
recoilってのも気になったけどおいときますね 状態管理はuse.stateとuse.contextで充分よ
recoileとかそびえ立つなんとか 状態管理って
ネイティブクライアントつくってれば
当たり前の機能でしかなくて、
Webアプリしか作った事ないのが
騒いてるにしか見えんね。
しかも、これらのライブライリ
使うと著しく見通しが悪いコードになる。
普段通り要件に合わせて
都度作った方が良いね。 コードから無理やり状態を排除しようとした結果
状態を扱うだけの高機能な巨大なオブジェクトが出来上がってしまったという
笑うに笑えない間抜けな事態になってる
状態が"必要ない"ものであれば、状態をなくすのは理にかなってるが
そもそも状態が必要なものは、状態をなくすことは不可能なので
部屋に散らかったゴミを押入れに入れるように一箇所に隠すことしかできないのだ
一見きれいに見えたとしても、それはいずれ大きな負債となり管理できなくなる stateもreducerもrecoilもcontextも
必要に応じて使い分けるがなあ
reduxを使わない(使う技術と根気がない)からかもしれんけど >>118
＞状態を扱うだけの高機能な巨大なオブジェクトが
それが正しく抽象化されていて、管理の手間も掛からないなら、何の問題もないだろ
何ならオブジェクトって単語をライブラリに置き換えるだけで、受ける印象が全然違うし
＞状態を扱うだけの高機能な巨大なライブラリが出来上がってしまった 明らかにReactの事わかってない（もしくは使ったことない）文章だし、触るだけ無駄だって Context APIは適切にメモ化して再レンダリング抑制して場合によっては正規化もやって云々
って色々とやっていくうちにreduxのしょぼい版が完成するだけ
じゃあ最初からreduxで良かったじゃんってなる あるある
オレオレフレームワークの末路も大体そんなだな
結局、シェアが大きいのは大きいなりの理由があるわけだ フレームワーク開発者の実験に突き合わされてるって
いい加減気づかないものかね？
それなりの人が作ってるものはどれでもいいんだよ
あとは将来性で考えればいい
重要なのはどれだけ長く使えるかだ reduxって単体で便利なライブラリなのに、
reactとセットが当たり前みたいに扱われたせいで、とんだとばっちりだな redux使わないレベルの規模ならhooksでいいけどな
しょぼいのしか作ってなさそう まあそもそも、SPAフレームワークとか状態管理とかこのゴミのようなブラウザやネット、htmlやらjsの仕様に合わせて仕方なくやってることだよな
状態管理は後付けで出てきたようなもんだし
何もかも非効率 >>139
angularはUIとデータベースをうまく紐付けないといけないので高度な設計能力が必要になる
その反面、設計能力が高ければUI関するコードを減らせるので
かなりシンプルにすることができる
reactとかはデータとUIに直接のつながりがないので
適当に作っても、それなりにどうにかなる
その反面JavaScriptでUIをゴリゴリと書いてる フロントみたいなデザイン的な面を最初からうまく設計できるって仮定自体が馬鹿げてるわ。 本来データ構造と見た目を分離するのがHTML/CSSなんだけどな
フロントやってるやつはCSSが苦手
CSSの命令は知っていても最低限の機能しか使えず
CSSだけで高度なデザインする能力がない
デザイン作るのにHTML構造を弄くらないと作れない >>144
当たり前やん
それデザイナーの領域やし angularは単になんでも入りが受け入れられなかっただけでしょ
バンドルサイズでかくなるし >>145
ゴミクソ自称フロントエンジニアwww
デザイナーがjsxいじるのか？ >>147
おまえデザインも完璧に出来るんやな？（笑）
そんな奴がフロントエンドのコードまともにかけるわけ無いやん（笑） >>145
だからデザイナーにやらせればいいということになる
そこをうまく分離できておらずプログラマがやらなければいけなくしてるため
メンテナンス性とパフォーマンスが低下して、生産性もスケールしなくなった 高い技術を持っていればAngularは素晴らしい道具なんだが
それを使いこなせる技術者・デザイナーが少ないという話 具体的に言えば、
デザイナーは最低限これぐらいは自力で実装できるぐらいの技術力が必要
CSSだけで作るドロップダウンメニュー（多階層）サンプル8
https://webdesignday.jp/samples/p5793/sample8/
そしてプログラマは、自分で作れなくともHTMLとCSSだけでこれらを作れると知っており
それを作るために必要なHTMLをカスタムタグなどを使いより簡潔に生成するために
HTMLやフレームワークの機能を熟知していなければいけない
ここまでの技術者が揃うのは少ないのでAngularを使いこなすことができない
そこでちまちまとJavaScriptで生成してる >>152
低能だから直ぐ発狂するんだな（笑）
朝鮮人かよ（笑）
どうせデザイン能力も大したことなければコードもまともに書けないという事がバレバレやな（笑）
あ、また発狂するの？（笑） >>149
だからjsxとstyleComponentをデザイナーにやらせるのか？
オメーがやれよって話
stateによって可変させるUIとかどっちがやるんだよ？
自称フロントエンジニアどものゴミのようなUI作成能力どうにかならねえのか >>153
お前の目ん玉腐ってるからデザインもできないわ、コードもゴミだわで存在価値ゼロだろ >>154
> だからjsxとstyleComponentをデザイナーにやらせるのか？
jsxとstyleComponentはウェブ標準技術じゃないよ
ウェブ標準はプログラマとデザイナーの両方にとってより良い技術だったのに
それをぶち壊している技術がたくさんあるってだけの話
ウェブ標準に戻りましょう >>154
> stateによって可変させるUIとかどっちがやるんだよ？
プログラマはstateの管理までをやればいい。
最終的にそれはHTMLのクラス属性やdata属性などに反映される
そのstateに応じたUIを作るのはデザイナ
一人で作るのは大変なんだからさ、分業しようぜ 高い技術があれば〜とか、超人的能力あればアセンブラで十分ていう狂人と一緒だぞそれ。 >>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に入り組んでいるのが今のフロントエンド
センスゼロ再現能力ゼロの無能君たちはフロントエンドエンジニアではない
ゴタクを並べて言い訳しかできない単なる使えない産廃 ぶっちゃけ色んな技術を配属されたチームの習熟度や要件に合わせて使えることが重要なわけで
Redux嫌いとかVue嫌いとか、TypeScriptいらないとか言ってる暇なんて実際ないからな
結局は技術をアップデートできない奴が淘汰されていくだけの話
過去の技術に固執したいのなら勝手にひとりでやってれば良い まあ、問題は技術のアップデートではなくて技術の変更になってるってところなんだよな
やり方が変わるだけで、何も良くなってないというね 技術？に群がってるだけじゃん。
その技術っうのは
只の流行りネタなだけという。 別に技術に群がるでも良くね？
それが要求されているのならやるだけなんだが？ ごめん、スレタイとあんまり関係ない動画貼っちゃった
なんか上みたら Web 3.0 がどうとか喧嘩してたから調べたのよね まぁ、そもそも俺が技術選定する側の人間じゃないからそう思うだけなんだけどな
別に必要ないから使わないって選択のできる人は使わなきゃ良い話 >>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使ってたと思うけどそういうのに必要だよなって記事に
そうだよなーって感想もっただけ 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の選択理由が簡単で分かりやすい
はずだったんだけどな。 ReactはHooksを覚えるだけで万能感得られるのがでかい
余計なこと覚えなくていい
ただしHooksをちゃんと理解するのが難しい 一概に難しいとも言えんだろ。
useStateみたいに簡単なのから難しいのまでいろいろある。 NuxtがISRできるようになる頃にはNextがまた新しいほげふがレンダリング出来るようになってるぞ ISRなんていらんやろ・・・
こんな間抜けな機能を提供しようと良く思ったなｗ これからはSSGだ！とかISGすごい！とか長々と説明してる記事多いけどさ、それただのキャッシュしてCDN配信してるだけじゃん
そのために新たな技術やコーディング方法が必要ってむしろ面倒くさくしてるだけだろ
頭おかしいんじゃねえの それキャッシュとCDNで十分じゃん、みたいなパターンは結構見かけるね。
それはそれとして、技術としては別モンだと思う。 それな
元々、Ajaxの系列だからな
Ajax -> SPA -> SSR -> SSGと来ているわけで、SPA要素がない従来の技術とは系統が違う
まあ、本来はシングルページ”アプリケーション”を作る技術の延長で、ウェブページを作る技術じゃねぇよって話なんだが SPAなど関係なくサーバーサイドで静的HTML生成は何十年も前からやってた
それをSPA界隈の人達が違うパラダイムでやろうとしてるというだけのことだと思う シンプルにしとけばか
自分で複雑にしておいて、複雑しているのが解決しましたドヤ
ってやってるのがフロント 動的にやるしろ静的にやるにしろ
サーバー側で何かしないといけないのは間違いない
個人的には各言語にReactのサーバーサイドSDKみたいなのを用意するのがベストなんじゃないかと思ってる
そうすれば既存のフレームワークからも使える 所詮お前らはフレームワーク開発の実験台にされてるだけだからな
最終的にはブラウザネイティブで対応し、フレームワーク自体の機能は極小化する
つまり今頑張っても数年後には無駄になってるということさ 今やってる事が遠い未来もそのまま役立つとは思わないけど、逆に全然役に立たないなんて事無いよ。
UFOが降ってきて宇宙人が全く新しく異質なプログラミング手法を伝授するレベルのパラダイムシフトでもない限り、技術は陸続きで、だんだん便利になってくわけで。
それとも、20年後もCOBOLやVBAやりたいの？ Reactは10年に一度レベルのパラダイムシフトのフレームワークだぞ
Railsが出た時と似てるが持続の長さを考えるとそれ以上
これをガッツリ使うかどうかで今後のエンジニアとして生き残れるかが決まる
dhhをみろ
Railsこじらせてhotwireみたいな珍妙なものを作ってしまった Rails勉強中のぼくちんはhotwireに期待しとる。
Reactぱっと見むずいんでvue跨ぐわ vueのほうがむずい気がするけどなあ
リファレンス見ながらじゃないと書けぬｗ 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の書き味とは似てないと思う NextとかNuxtにtailwindを使うケースが増えてるらしい
実際どうなん？ センスゼロのプログラマがどんなcssフレームワーク使ってもまともなUIを作れないからどうにもならん >>270
ん？会話成り立ってないよお前
コミュ症か？ プログラマのゴミのような酷いUI構築力
画面設計にはあるのに必要な要素が存在しない
レスポンシブにするとどこかに消える要素
画面の外にはみ出したり追い出されるコンポーネント
スクロールすらまともに作れない
マージンバラバラ
フォントサイズ超適当
正しいレイアウトになっていない
デザインどおりに組めない
→ それ俺の仕事じゃないと言い訳しかできない
これが自称フロントエンドエンジニア
マジで無能 >>274
いままで使ってみたことなかったけど
それ読んだら今後も使わないだろうと思った 指示もうまく出来てないし、マニュアルもないし
フロントとバックエンド両方の技術求めているし
こいつを使えるような指示を出せないお前が無能 >>282
指示しないと作れない無能のお前ごときに反論が必要なのか？
どっちにしてもお前のゴミのようなセンスどうするんだよ？
生まれつき目ん玉腐ってるから見たものすら理解不能なんだろうが >>269
Tailwind 好きだけどreactには向いてないと感じる 海外のトレードサイトで、reactで作られたUIで割とキビキビ注文板が動いてるの見たから、案外パフォーマンスも良いんだな レンダリングのスピードはvdom使ってるから遅いけどな。直のdomを弄るよりも。 >>286
そら直の更新で最小の更新だけすれば、そっちの方が早いだろうけど
差分更新のメリット活かせないなら、そっちの方が早いのは当たり前じゃね 速度だけ見たら阿部寛のホームページが最強だわ。
カス企業は無駄に動的にしたがるがこれで十分だろ。 でも阿部寛のホームページはLight Houseのスコア弱いから ネタだろうけど目的と手段が入れ替わってるぞｗ
Light Houseのスコアを上げるモチベは検索上位に行くためだろう
阿部寛は一番上で、おそらくリストロジック上特別扱いも既になされているのではないか？
だとしたらLight Houseのスコアを上げるモチベはまったくないだろう >>288
確かにこれで良いんだけどな。
速いし読みやすいし。
なぜ企業はこうしないのだろうか。 適切な技術ではなく新しい技術を使うことが正義だと思ってるアホが多いから
jQueryはオワコンとかネガティブキャンペーンしてるやつが当てはまる 別にもう新しくもねえだろ
アホはいつまでも最新って思ってるらしいが >>294
SSGってある意味でこれへの回帰では？
流石にHTML手打ちするのはアホらしいので、そうしないだけで 阿部寛のサイトは、内容がないから速い。
何の処理も、操作もない
そういう簡単なページは、誰でも作れるから、プロにお金を払わない >>296
「新しい」っていうのは、何年以内のものを指す言葉じゃないぞ
何かと何かを比べて新しいかどうかだ
それとも別の何かが登場して
オワコンなったんか？ >>298
内容＝装飾とエフェクトとか思ってる人いるよね
中身が無いのに着飾ってるだけ >>299
お前みたいなゴミカスが吠えたところでうるせーゴミカスとしか思わない みんなweb siteとweb appを同列に語ってるからややこしくなるんだって。
阿部のサイトは明らかに性的なwebサイトの部類。静的なものに関してはreactを使わずにhtmlと単純なjsで書くべき。もしくは templateとしてjsxを使うとか。 性的（アダルト）サイトはトラフィックが半端ないらしいな。フロントでどうこうの世界では無さそう 阿部寛の活動内容を伝えるって目的を考えればあれで十分だろ。
あれに糞エフェクト入れたら逆に鬱陶しいわ。 react使ったからって装飾もエフェクトもついてくれませんけども Googleで「SSL」を検索すると、Reactを使った最新のサイトがダダーッと出てくる。
説明を読んでみる。
> 皆さんこんにちはテクノロジーエフェクト株式会社CEOの山田（仮名）です。
> 本日は、社会人1年目の皆さんのために「SSL」について解説します。
※クルクル回るエフェクトで1分待たされる
> 皆さんも社会人となったのでクレジットカードを持たれたのではないでしょうか？
※ ネットショッピングについて2ページ
> というわけで、SSLという仕組みが必要になったのです。
> 次回は担当役員佐藤が、SSLとは何か説明いたします。
> ご期待ください。 Reactと聞くだけでイラッとすると、あわしろ氏が言ってた。 SSLの解説と称してネットショッピングについて説明し、内容豊富なコンテンツですと！！？？ ウェブアプリなので、ネットショッピングについての2ページが通信必要なしに表示できるんですよ！！
ってあほか！
普通にSSLの説明書けよ。 あわしろ氏は、フロント界隈はクズしか居ないと言ってた。 最近の高卒初心者は凄いな
私が初心者の頃だったらReact+Reduxとか絶対に理解できなかったわ おっさんたちには理解できないんだよ
おれはおっさんだが 動画だのサロンだのばかり見て、全然手を動かして（勉強して）無いんだなと言うのが伝わってくる コロナで宣伝書き込み増えまくったよなｗ
生きるために必死ｗｗｗ 我々はjqueryに代わる世界標準なライブラリを求めている この世からjavascript無くなればみんな幸せになるのに Next.jsのIncremental static regeneration て
一定時間がたてば、必ず生成するのですか？
例えばマークダウンからページを生成するとして、マークダウンに変更があったら
ページも生成しなおさなければならないけど、なければ生成する必要がない。
だからキャッシュの更新時間と、ページのもとになるマークダウンの更新時間を比較して必要がなければ生成しないようにしたい。
そうするには、どの関数、どの引数戻り値をいじればいいのでしょうか？ >>340
そうなんですか。
単純なマークダウンの変換からのブログとかには向いてないのかな。
ありがとうございました。 もしかしたら再生成は変更された場合のみで、apiへの確認は毎回行うみたいな感じかも たかがブログやるのにこんなに複雑で面倒くさいことしないといけないっておかしいだろ cdnを挟めば、同じことできるしね。
でもcache頑張りたくないです！な場合は有効かもね CMSも昔はMovableTypeのような静的なものが主流だったのが
WordPressで動的なものが主流にはなったものの遅いとかで
また静的に戻ろうとしているのかも知れないが
静的は静的でメンドクサイんだよなｗ
だから今後はサーバーの性能が上がるだけなのにわざわざ静的にする
必要性が普通は無い
よっぽど高アクセス対策しないと行けないみたいな特殊な例はあるかもしれないけどなｗ たかがブログやりたいだけなのにシステムがどうのこうのってのがおかしい
アメブロ並に簡単に作れるブログでいいわけ 揺り戻しでSSG(静的サイトジェネレータ)が静かに流行ってると聞いたが そんなあなたにWordPress。なんだけど、キャッシュとか使っても思いの外鈍足。安いCDN無いかなぁ wordpressがクソな理由はphpが介入することなんだよね リファレンスとかニュースみたいな情報提供系サイトは極限まで軽くして穂いい。
そっから必要最低限の機能を追加してほしい。
要するに、長年積み重ねてきた中の無駄要素を排除して再構築。 >>350
php7にしていない古いのが一杯ありそうだし
そういうホスティングしているところが詰め込み過ぎで遅いというのもある
php自体は今は相当早くなってるよ
ruby(笑)なんかよりかなり早いし phpがクソというわけで言ったわけじゃなかった。すまんこ
webの開発をわざわざphpでしたくないよねっていう話。
jsで統一したい。
現在wordpressにphpが使われてる理由に合理的なものってないよね。初期設計がそうだからとかでしょ？ 久しぶりにjsで書いて「なんだこれ？」「どうしてこうなった」ってなる大体の原因は非同期を忘れたから
ま、phpも他もそれぞれそういうのあるんやけどね jsのシンタックスと伝統的なサーバーサイドの書き方がいまいち相性悪いんだよね
ちょっと複雑なことやると
あらゆるところでasync await連発しなきゃいけないし
サーバーサイドからしたら非同期の要素なんて入らなくて
シーケンシャルに高速に動いて欲しい
その方がパフォーマンス計測もデバッグもしやすい 伝統的なサーバーサイドってなんやねん
async awaitが嫌なら、goもrustもc#も大体の言語書けないわ。
jqueryおじさんと非同期おじさんという二大ガイジがいるんだなあ 非同期なJavaScriptに慣れすぎたのか、同期的な言語使うと、これ一見自然だけど割り込みを隠蔽してて良くないよな。
みたいな感覚になる なんならthisもわりと自然に感じる。
だがprototypeとnewの関係。オメーは駄目だ そんでキミたちはどんなSPAアプリ作ってんの？
こっちはちょっと特殊な業界でreactフロントの業務基幹システム作っとる >>358
複雑なことやるならpromise使うんやで それな。nodeがc10k問題をコード上特に工夫することもなく易々と突破したときの他勢力のsurprised pikachu faceといったらｗ 基本、CUI は同期。
GUI みたいに割り込まれる事がないから
だから、サーバー言語のRuby は同期。
非同期はオプショナル
一方、JavaScript はGUI が先にあったので、非同期が基本
Node.js がRubyを真似て作られたのが、2010ぐらい。
Rubyの10年後ぐらい CUIが割り込み無いとか、何言ってんだよ。割り込みなんてコンピュータの基礎じゃん。
sleepも割り込み、ネットワーク応答も割り込み。OSなくたって割り込みは存在するのに JavaScriptが非同期を意識したコードを書かないといけないというのが根本的な問題
しかも常に非同期なのではなく同期的に処理される場合もある 例えばファイル読み込みで非同期処理は必要か？
SQLのフェッチで非同期は必要か？
その辺りを考えれば俺のいってることは理解できるだろう シングルスレッドのJavaScriptは非同期にせざるを得ない
他の言語であればマルチスレッドで実行するので非同期はいらない DBアクセスとかマルチスレッドこそ非同期要るじゃん。
同期処理と非同期が混ざってるのが良くないってのは確かにそう。ただ、現在の環境では希少かと。 >>373
いらんよ。どうせデータベースから値を取得しないとその次の処理はできないんだから イマイチわからんのだけど、node.jsってプロセスが一つだからリクエストあってもグローバル変数は共有されるよね
サーバーレスだとアクションのたびにプロセスが立ち上がるからグローバル変数は共有されないの？
となるとnode.jsのメリットってどうなるんですか？ >>375
お前がいいたいのは何だ？
グローバル変数の有無がどうメリットの話に結びつくんだ？
そもそもお前はnode.jsのメリットがなんだと思ってたんだ？ >>375
プロセス間でどうやって変数を共有するんだよ >>376
メリットはプロセスが一個ってこと
グローバル変数はどうとかは知らん
>>377
知らんけどメリットあるっていろんなnode説明にあるけど
>>378
まあな >>375
調べてみたら確かにそうなんだね。勉強になった。
シングルスレッドだとプロセスが独立してないからグローバル変数が共有されるんだ。 >>379
> 知らんけどメリットあるっていろんなnode説明にあるけど
じゃあお前がnodeのメリットを勉強しろってだけの話だろ >>380
> シングルスレッドだとプロセスが独立してないからグローバル変数が共有されるんだ。
マルチスレッドでもグローバル変数は共有されるが？
そもそも一部のメモリを共有したいという要求があって
マルチスレッドが登場したというのに
それから共有されるからなんだっていうんだよ？
なんにもデメリットはないだろ 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 で標準化中だけど。 非同期ではなく
完了まで待って次に移行するメソッドを
コールバックを一切排除して
関数定義側のみで定義する方法はないのか。
呼び出し側に特殊な構文が必要なのは無しにしてくれ
呼び出し側をそもそも関数で囲む必要がある
というオチはやめにしてくれ。
メソッド内で呼び出される非同期処理も
その内部の非同期呼び出しも
全部完了まで待つようにしてくれ 非同期だけど同期的に見せたいっていうのは
やっぱり同期的な方が人間にはわかりやすいってことなんだよな そらそうよ。
並行して二つ仕事やるよか、一つづつこなす方が明らかに仕事の精度が高い。 >>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みたいに簡単に出来るようになれば良いのだけどもうちょっと様子見かな 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できる人材がいなくてね >要件がしっかりしてるなら、とか
そんなプロジェクト見たことないわ マジで今のフロントエンドは空き巣だと思う
サーバーサイドの人は今更フロントに来たがらないし
これまでフロントの人は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の勉強する方法を思いつかない つまりツイッターやfacebookみたいなものちょい劣化版を一人で開発できるレベルがアプリ開発できるという
できるんだよな？ フロントは作れるけど、ああいう数千万ユーザの同時アクセスに耐える技術とか、ユーザを集める技術とかは無いです そりゃあreactはフロントサイドのフレームワークなんだし当たり前よな component.vueで「なんでこの変数undefinedなんだよ！」って小一時間やってたら、
途中で変数に$付けてるのに気付いた
消したら動いたのでコーヒー飲んでパソコンを落とした svelte触ってみた
意外と良いのか？
ReactとVueを同時に触っているような不思議な感覚 Next.jsのWebAPI機能って使ってる？
バリデーション無いのが嫌だからついついFastify使っちゃうけど、なんか良いやり方あんのかな？ SSRをやりたい、かつVercel使いたくない場合はNextjsよりNuxtjsの方がいいんすかね？ 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しちゃうからなぁ >>500
switch文が嫌いなので……という冗談は置いといて、最近使えた局面あったわ。復習大事だなぁ。 やっぱredux-saga使おうかと思い始めてる。hooksでも非同期処理は全然楽にならんし。 なんで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 推奨ＮＧワード： 総帥
推奨ＮＧワード： 日経
推奨ＮＧワード： ディス鳥
推奨ＮＧワード： 動画
推奨ＮＧワード： 香具師
推奨ＮＧワード： 世界でも あわしろ氏は、僕の最大のアンチは僕自身だと言ってた。 あくどいオンラインサロンではないんだろうけど
ここまで誰かに心酔できるってちょっと危ないよな
教祖様がこう仰っていた！の一点張り
自分の意見が一つもない vueとreactどっちが楽に覚えられる？
出来ればフロント触りたくなかったんだけど次やらされそう… 最初ぱっと見たとき10秒でvueファイルは大まかにやってること理解できたけど、reactは無理だった
JS、TSの熟練度にも依るだろうから色々見たほうがええんでない？ >>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トークンはヘッダ
相変わらずリフレッシュはよくわからない
このへん標準化しといてほしいね いやCookieそのものが無くなるわけじゃないから Bearerはヘッダやろ
トークンをヘッダにのせる(jsで触れるようにする)とXSSにやられるんやと reactquery使ってますけど
イベントを発火させるところに置いてloadingを受けとるのがいいのか
storeにまとめてロジックとの分離を目指した方がいいのか分からないです
loadingはstoreから取ると可読性落ちそうですし APIなのにcookie使っているプロジェクトがウザいｗ
headerにtoken仕込む方がやりやすいわ Reactってイマドキの若者はHooks？ってやつ使ってんの？
Reduxはオワコン？おじさんに教えてくれ >>547
hooksでいいと思うけど
完全にステートやアクションを自分で管理したい人はreduxでもいいんじゃないか 年齢と性別を比較してるようなもの。
Reduxもhooks api提供してるんだが。
reduxはrecoilやjotaiと比べなさい。
hooks apiはReactの機能をクラスを書かずに使えるようにしたAPIの規約のようなもの。useStateなどはあくまでその一例。 大規模システムで状態管理すると状態管理が大規模になるが一元化してるのでわかりやすい
hooks使うと状態管理がバラバラだからそれぞれのコンポーネントで管理する 状態の一元化ってようするに巨大なグローバル変数では？
本当にそれでいいの？ hooksとreduxを同列に語るって
いったいどういった思考なの？ おじさんにはわからないんだ
いじめないで教えてくれ おじさんであることは自分で勉強しないいいわけにはならない。
事実ここにいる奴みんなおじさんである。 reactは直感的じゃないからやっぱダメだなｗ
useState()だけでも誰だよこんな頭の悪い実装考えた奴はって思う むしろuseStateには感心した。状態と関数型プログラミングはこうやって両立させるものなのかと。美しいとすら思った。 useState使った関数コンポーネントって、関数プログラミングと呼べるようなものなのかね
あれを関数プログラミングとか呼んだら、その方面の人達に怒られそうだ rootにstore持たせて上から順にprops渡して行けばいいと思う
そのほうが純粋関数っぽくてわかりやすいしテストしやすい useEffectとか実質algebraic effectsだし >>558
確かに怒られそう。あくまで両立ということで許してください…… preactのhooksのソース読んでこの機能のヤバさが理解できたね
まともなエンジニアなら絶対こんなインターフェース思いつかねえ
関数型界隈の凄さを知ったね それ面白そう。preactならコードも短くて、丁度いい勉強になりそう >>563
マジでおすすめ
あまりに美しくて久々に感動したよ
それと同時にhooksがってることが全て理解できた
最小のコードで最大の効果を得るっていうのが自分の中で優れたエンジニアリングなので
まさにそういうコードがあった class形式のComponentってどんな時に使うんすか？ なあ、いい事考えたぞ
UIや画面を完全排除したアプリを開発しよう！
そういう仕事あるかな？
いつまでやらされんだよこんな無駄な作業 コマンドラインですべての操作を行うアプリに決まってんだろ コマンドラインはあぶなくてこわい
がちがちのお子様用ＵＩなら何も間違ったことは起こらない >>567
今後は増えていくと思う
UIなんてものはユーザーがノーコードローコードで適当作ればいい >>566
Reactの話だったらもう使う意味、無いです。 >>574
こういう人ってどこにこんなことする時間あるの？
キータに長文記事書く時間あるのはヒマなの？
毎日残業毎日勤務の俺からは想像できん >>575
忙しい=勤務時間をフルに使う人と
忙しい＝残業しなければいけない人の違い Apollo使ってる人おりゅ？
GraphQL推進派に取り込まれそう GraphQL初めて見たときは凄い良さそうに見えたけど、普通にアプリ作る分にはRESTで十分だった…… >>585
reactもそうだけど独自ルール過ぎるんだよな
実装が簡単ならいいけど逆にめんどくさいし
Vueくらい自然な感じだと理解しやすいんだけどな う〜ん。
個人的にはGraphQLは簡単そうに見えていざ使ってみると面倒くさかったし、Reactは難しそうに見えて実際に使うと簡単だったかな。 俺もそんなイメージ
Vueのほうがパッと見簡単に見せるために恣意的な決めごとに載せてる感ある
Reactは自分で簡易クローン作って理解することもできるだろ
JSXは飛ばしていいからさ Vueはちょっと難しくなり過ぎたな
初期のbetter angular路線でやれば良かったのに Reactのclassコンポーネントのインスタンスフィールドとstateってどう違うの？ ヨシ！React完全に理解した！
Next.js？まだなんかあんのか… React把握してればその一部がサーバ側にシームレスに移行するだけだからNext.jsは楽だった。getStaticPropsとgetStaticPaths覚えればとりあえずはNext.jsのメリットを生かせるし しかもそのアトまだReduxとかあんだろ…
めんどくせーわ vue(nuxt)だとvscodeの補完が効きづらくてなあ >>601
リコイルってのがいいのか？
最近始めたばかりなんだ
とりあえず素のReactは完全に理解した Vue3は今のところ別に使わなくてもいいやって感じではあるな
処理速度よりも分かりやすさを追ってほしいわ そもそもReactが嫌いって人がVueに走ってたのに、
なんでVueはReactの真似しちゃったの？
中の人は阿呆なの？ jsの中にまでhtmlやcss来やがってキモいよな React使わなくてもコンポーネント化を推めればどのみちそうなるので違和感は無い フィールドコンポーネントに状態をもたせる
フィールドコンポーネントはを純粋関数にして
フォームコンポーネントに状態を持たせる
フォームコンポーネントを純粋関数にして
ページコンポーネントに状態を持たせる
どれがええんや
リアクト最初は感動するけど規模が大きくなるとわけわからんなるな >>612
クライアントAPPの初心者だからじゃねーーの？ >>614
好きなのでやればよろし。
状態管理なんてクライアントアプリなら
基本中の基本のコード。
ライブラリーなんて昔から使わんで
自分で都度考えるのが普通。 angularな俺は振り回されずに済むぜと呟いてみる ReactでDrag&Dropで要素入れ替えとか要素追加ってできる？ >>617
Reactからevent.currentTarget経由で生DOMに触れるので、やろうと思えば何でもできる。でも、もっと良いやり方や既存コンポーネントがあるかも知らないので、とりあえず英語でググるかな。 一昔前はSvelteやAurelia使うならVueでいいじゃん？って言えたけど、
今はもうVue3使うならReactでいいじゃん？って思うし、
先行き不透明なVue2使うならSvelteやAureliaの方がいいかも？って思うよね
Vue3ってVue使いには歓迎されてるの？ 別にVue2で間に合ってるしなぁ
人数少ないプロジェクトでやってるしヘルプは大抵jsフレームワーク未経験
(jqueryは経験あり)が来るからVueの方が教えやすくて楽だわ angular(v1)とreactぐらいしかなかったころ、迷った末にjsxが気に入らなくてangular採用したんだけど、その後angularがこんなんなるとは思わなかったわ
しばらくwebから離れたけどまた触るようになってvueとreactで迷ったけど、今度はreact選択した。jsxにはやはり抵抗あったけどhooksが分かりやすく感じたので。
その後しばらくreactいじってるけど、今となっては昔あれだけ抵抗感じていたjsxが、これほど良いものに感じるようになるとは。 hooksが分かりやすいって
どんな感覚なんだろう？
class(オブジェクト指向)未経験とか
なのだろうか？ 直感的にはclassのがわかりやすいと思う
ただJavaScriptは文法的にclassを書きにくい
イベントハンドラのthisが別物にすり替わったり
関数のほうが書き心地がスッキリ
ただそれだけ C#でjsxを再実装したらclassのが良いわってなると思うよ >>626
あ！
自分Typescript使ってるんで
その場合はC#とあんまかわらんからねーー。
hooksが良いという人は生js使ってる人なのかーー。納得！
自分の場合
主要所のclassは
殆ど自前のbaseクラス継承させてるんで、
関数だと辛いわーー クラスに万能感感じてる人は00年代からタイムスリップして来たのかな？ オブジェクトリテラルの存在するJSであえてclassを使う場面はなんらかの理由がある時ぐらい。
それは主に継承と副作用（カプセル化含む）で、どちらもモダンプログラミングでは避けるべきとされてたりする 継承の使い手なんで
なかなかそれは難しいね。
その避けるべきとされてるものを巧みに利用して、
暗黒面の高度な技を連発してるのだから...
C#よりJSのが技に制限がなくて無双に感じる イミュータブルOOPは関数型より良いよ
関数型のメリットは完全に享受できたうえで
人間の感性によくマッチしてて理解しやすい 好き勝手言ったけど、OOPを否定するつもりは全然無いよ。
OOPと関数型は適材適所で使ってこそ本領を発揮すると思うだけで。
>>632
黒魔術楽しいからね。仕方ないね。 function hoge () {}; ←これやめてほしい
const hoge = () => {}; ←これがいい function hoge () {}
形式は巻き上げがあるのと、hogeに代入可能なのと、thisが使えちゃうから、もっぱらconstとアロー関数で書いてる >>637
それはあくまで実装にすぎない
そんな事を言ったら全てはビットだ
高級言語というのは意味のないビットに人間がコードを理解するための
情報を追加できる言語のことだ。
関数の引数に使うという意味を込めれば値になるのだ functionとアロー関数は、微妙に挙動が違うのが辛い
jQueryとか古いライブラリを使うと、ハマることがしばしばあるわ jQueryとなんか関係あるの？
何を渡すかでしょ そもそもnewするのなんて
ImageとDateぐらいじゃなかったか？ class導入以前のJSは組み込みコンストラクタとパフォーマンス（と稀にプロトタイプチェーン）以外の面でnewするメリット無かった印象。
今の方がnew使ってるかな 他言語見ながら驚き最小を目指せば大体こうなるよね
って感じの機能追加がほとんどじゃね >>639
JavaScriptの仕様がポンコツなだけでまともな仕様だったらそもそも必要無かった アロー関数と普通の無名関数の違いを新人に説明したら意味不明みたいな顔された
わけがわかりませんと javaは8から使えるし、phpでは7.4から使える jsのアロー関数ってthisの扱いが既存のfunctionと違うだけでしょ。
どっちも無名関数にできるから無名関数との違いなんてない。 PHPはサーバーのバージョンが不安で、結局まだ使えないのよな
未だにfunction現役だわ 機能に差異がある場合、機能的に正しく使い分けることで、コードの意図をはっきりさせる事ができるよね。
逆に差異が無いのに混在かますと混乱する Javaのはラムダ式だろ
演算子をアローと呼んでるだけでJavaScriptのアロー関数とは別物 >>666
無名の場合thisを呼び出したオブジェクトにバインドするけどアローはされないんだよ
これ以上わかりやすい説明もないと思うが意味不明ですと言われた >>669
その辺はthis地獄体験してないとピンとこないよな
thisが排除されつつある現状だと理解されないと思う >>669
新人さんにそのへんの有り難みはわからんかもね。
なんでや、とりあえず便利そうだしthisバインドしとけばええやんけとか思ってそう 今ならthisはclass構文の中で使うもの
って決めつけちゃって良いと思う
イベントのthis？知らない子ですね… >>669
それで誰に対しても伝わると思ってんなら頭おかしい >>669
新人「は？アロー関数だって無名だろ？マジ意味不明ｗｗｗ」
とか言われたわけじゃないとすれば、jsのthisがそもそもどういうものか伝わってないんじゃね？ ところがどっこいvue.jsだとかなりthisを使うんですよね 慣れてるからとか使える奴がいるからとか実績があるからとか言って、レガシー技術での新規案件が山程生まれる。そしてガラパゴスへ……。
マジレスするとVueはまだ全然レガシーでも無いんちゃう。知らんけど。 bindするthisを差し替えて汎用的に使える関数を作ったら凄く便利だったが、俺以外は誰も使う奴がいなかった。
バックエンド上がりに多いがthisはいつもクラス本体を指すと認知が歪んでるからな Vueはscript setupのシンタックスシュガーがイケてる
しかし現状だとIDEの解析が弱いのが難点か >>683
お前が作ったもの（ゴミ）
・汎用的に使える関数.bind(this)
本当に必要だったもの
・汎用的に使える関数(this)
ってことでOK？ >>685
＞>>683
＞お前が作ったもの（ゴミ）
＞・汎用的に使える関数.bind(this)
＞
＞本当に必要だったもの
＞・汎用的に使える関数(this)
＞
＞ってことでOK？
関数内にはthisを渡し、関数の中でthisをbind
日付を求めて値をセットするが、差し替えるstateはthisによって変わるという塩梅 稀にthisの動的特性が役に立つ事が確かにある。ほんとに稀に HooksきてからReactでthis使う場面とかある？
Vueはしらない >>686
うん、つまりfunction foo(obj) { ... }という関数を
foo(this)と呼び出すってことでしょ？
そのobjをthisとしてbindしてthis.setDate(日付)とかやってるんだろうけど
普通に obj.setDate(日付) とやればいいだけだよね？ >>688
ないっすね
Reactはthis排除に成功した thisを排除した結果、フレームワーク固有の仕組みに依存するようになったわけだが
それで本当に幸せなのか、甚だ疑問がある フレームワークスレだけどアンチフレームワーク住み着いてるからね。仕方ないね reactは独自過ぎなんだよ
だからアンチが居てもおかしくない >>698
独自性？どこがやねん？( ﾟ∀ﾟ)？？ 私はReactがJavaや.NETの開発者向けではないことに気がついた。
この場合は、デザインパターンが似ているAngularが適切な選択だったろう。 おれはまさにフレームワーク屋だよ。
クラスを使って開発者の自由を奪って
羽交い締めにするのが俺のお仕事♪ 開発者の自由を奪う行為は必ずしも悪じゃなくて、それは効率を上げるルールてあったり、思想だったりするよね。
Reactで言うとdangerouslyuSetInnerHTMLとか明らかに使ってくれるな的な名前と長さで結構好きだw Typescriptによる型強要による圧政政治
それがオレのフレームワーク♪ フレームワークがちゃんとした型パズル書いてくれてたら、使う側はほぼ型推論だけで書けるから楽ちん Reduxって必要か？
rootにstateとmodifierを持たせてpropsで渡していくだけじゃないの?? hooksも大規模になるとだんだんキツくなってきた
銀の弾丸はないのかよ 最初から大規模分かってるならRedux使った方がええぞよ 誰だよhooksあればReduxいらんとかほざいてた奴ら いうても大抵はhooksで事足りるのもまた事実なんや
見極めできるようになるにはある程度経験が必要 static変数に必要に応じてグローバルスコープのデータを
保持しとけばイイだけじゃないの？ お前らの用途では○○で十分なのに
これからの流行だとかに乗っかって必要がないのに
無駄に複雑なものを取り入れてるツケが回ってきたな
落ち着いてよく考えてみろ
jQueryで十分やろ ホームページ屋さんにはjqueryがぴったりだよね hooksからreduxへ移行できるパスがあればいいのだけど
全部作り直しレベルになるのがきついなあ
hooksのredux対応って良いのかね？ reduxってグローバル変数みたいで好きじゃないんだよね redux調べたら数年前とは別物になってる
reduxtoolkitやselectorとかこれが欲しかったんだよって奴が揃ってる
connectだとかmapStateToPropsとかもういらないんだな
これは最高かもしれん >>724
えっじゃあhooks房どうすんのwww >>725
感触としては昔のreduxはダメだが今のredux最高
hooksイラネって感じかな
hooksってuseEffectの無限ループとか
if文の中でうっかり使ったりして
どハマりするんだよな
その辺が地味にストレスになってた そして今日もレガシーコードが積み上げられるのである。 hooksイラネ？
じゃなんでreduxは公式でhooks api提供してるのｗｗｗ 俺だけかもしれんけど、hooks無かったらReactの魅力半減だなぁ。 一生懸命覚えたreduxがいらない子扱いされたから悔しかったんだね
つらかったね reduxは覚えるってほどの難しいものじゃない
Reactとの接続部分が面倒だっただけ
reduxtoolkitにより全てが解決された
アクションのswitch caseもいらない
state分割の仕組みもある
とんでもなく素晴らしいよ >>734
reduxtoolkitでSliceって仕組みがある
これが神でactionとaction creatorsとreducersを兼ねた化け物的な責務を持ったオブジェクトなのよ
reducersの名前とアクションが自動でマッピングされるというこれが欲しかったんだよ！って機能を持ってる
さらにuseSelectorによりstateから状態を抽出する機能とuseDispatchによりstoreを隠蔽する
ちなみにこれを全部理解するのに30分くらいしかかからなかった
マジでわかりやす過ぎる このスレでは話題にもならないSWRとreact-queryさん concurrentモードがstableになったら死ぬし thisおじさんいなくなったらreduxおじさんがきた しかしなんつーか、フレームワーク屋の実験に突き合わせれて可愛そうだな
新しく出たものを使って今までよりもなにか改善されたか？
変わっただけで労力は変わってないだろ C#おじさんと一緒にしないでくれ
上の説明でわかる通り俺の説明は簡潔で特徴を捉えるのがうまいんだ
hooks以降のreduxについてzennとかqiitaでも最近はあんまりトレンドにならないから
勉強したがあまりに素晴らしくてびっくりした 今から開発するなら使わない方が主流じゃないか？
Reactだったらcreate-react-app か babelはそろそろ要らなそうだけど、webpackは少なくともあと5年は使わざるを得ないだろうという認識
はやく全部ESMになるとええな create-react-app使ったって結局ejectするでしょ？
中でwebpack使ってるからその知識がないとメンテできない。 webpackを回避するのが茨の道だから使った方が楽 ツリーシェイキングとかメリットもあるからあんまり目の敵にしないであげて欲しいな こういうところめんどくせーよな
マイクロソフトを見習えっての めんどくせーって人向けにはcreate-react-appとかcreate-next-appとかありますし。MSもあのライブラリとSDK入れろとかあるので五十歩百歩かと どっちが良いとかじゃなくてエンタープライズとWebフロントエンドの文化の違いだなぁこれは。
読んでるだけで胃が痛くなるな >そして私は、各開発者がサードパーティーのライブラリを習得する時間について考えていなかった。
>私は2つのReactプロジェクトで同じ依存関係、プロジェクト構造、ガイドラインを持っているのを見たことがない。
ゴミじゃん reactがエンタープライズに向いてないって話じゃなくて著者がエンタープライズ案件を管理できなかったっていう話だよな 「関数コンポーネント？ ダメダメダメ。我たちは好きじゃないからクラスコンポーネントを使いましょう！」
↓
開発者たちは関数コンポーネントがクラスコンポーネントと同じくらい良いことに気づき、それらを使い始めた。その結果、進行中のプロジェクトは元々のコーディング規約に従わなくなっていた。 これは各開発者が個人で選択したようなものだ。そして私はそれを許容していた。
.NETカス爺ほんまｗｗｗｗ オブジェクト指向は手続き型に破れた
オブジェクト指向なんて必要なかったんや >>767
まさかJSのクラスがここまでゴミとは思わなかったんだろうな
.NETの感覚でやったらclass使うのが正解で当たり前だし オブジェクト指向言語の99%以上は手続き型言語だけど…
一応研究用概念実証用でPrologにオブジェクト指向導入した実装とかあるにはあるからそれはオブジェクト指向言語かつ非手続き型だけどね
> オブジェクト指向は手続き型に破れた
例えて言うとこれ、「日本人は男に破れた」みたいな文だよ
オブジェクト指向かそうでないかは手続き型言語かそうでないかと直接関係ない（直交する）
日本人かどうかは男かどうかと直接関係ない（直交する） jsから動的にHTML要素に付与や剥奪、上書きされたclass属性や
style属性などを、
その操作を行ったjsソースまで追跡して特定するいい方法は
あるかね？
Devtoolsの機能で出来る？ >>769
関数型プログラミングできないんですね。わかります Ruby からElixir
オブジェクト指向から、関数型へ
RubyからGo
is-a・継承を無くして、has-a・ダックタイピングへ
Rubyは、ダックタイピングかつオブジェクト指向 Ruby on Rails でも、Webpack, Babel が標準で、
Bootstrap, jQuery, React、規約だけのフレームワーク・Stimulus
RailsがHTMLを返す。
Reactはコンポーネントとして使う
また、サーバー側がRails、GUI がReactと分けることもできる。
RailsのAPI モードで、JSON, GraphQL でやり取りする 推奨ＮＧワード： Ruby
推奨ＮＧワード： Rails Vueは生物じゃないから最初から生きてないし死んでもない 死んでないけどreactとreduxとhooksの思想をごちゃ混ぜにして
機能追加したせいでカオスになってる vueは3.1からかなり使いやすくなったと思うけどなぁ
script setup のシンタックスシュガーのおかげでとても読みやすい ジャバパーとcシャーパーにReact使わせる案件は絶対に回避せねばならない むしろ日本っぽいなと思った
どういう会社か知らんがアメリカじゃ使えない奴は全員クビにするし 基本、米国人は米国企業のものを使う。
だから、React, Bootstrap
中国っぽいものは、危険なので使わない 米国人というか世界言うならBootstrapはもう一番じゃないよ。
https://2020.stateofcss.com/
和訳：
https://coliss.com/articles/build-websites/operation/css/the-state-of-css-2020.html
フレームワークは2020年で大きな変動がありました。Tailwind CSSが1位になり、Bootstrapは大きく順位を落としています。
Tailwind CSS: 87%
PureCSS: 71%
Bulma: 61%
Ant Design: 60%
Materialize CSS: 53%
ちなみに、Bootstrapは48%、Foundationは31%です。 bootstrapのデザインあんまし好きじゃないな >>789
それ満足度じゃん
使用率だとBootstrap86tailwind26だぞ Bootstrapは馴染めないよな
どこに需要があるのかもよく分からない
デザイナー？ 問題は日本語環境のドキュメントがあるかどうか
理解出来ることと、マルチバイトにうまく適合すること両方必要 >>786
この場合の使えないやつとは、Reactを採用させてプロジェクトを破綻させたやつってことだよ >>792
Bootstrapは開発者がアプリのプロトタイプを開発するときに
適当でそれっぽいデザインにするために使う
デザインを重視する場合、Bootstrapのフレームワークに適合させつつ
思った通りのデザインにするのは、苦労するだけ デザイン指定ありの場合は100%自作する
そうでなければフレームワーク使うよ >>795
プロトタイプねー
そのぐらいしか無いよね フロントエンジニアは指定されたデザインどおりに作れないゴミしかいないからな
生まれつき目ん玉腐ってるから見たまますら作ることができない 30機種くらいのスクリーンプロファイルごとに全部デザイン出してほしいね。
あと付けでiPhone5で見きれるからこの時はここのフォントサイズを小さくとかそんなんばっか。
こっちが忖度で勝手にフォントサイズ小さくできないからね！？ >>801
お前アホなの？知識ゼロだろ
話にならんわ どんなcssフレームワーク使おうが生まれつき脳みその品質低いからどんなデザインすら実現出来ないだろ
できるならやってみろ そこまで仰るからには貴方はさぞ素晴らしいデザインが出来るのでしょうね。
やってみてくださいよ 明日また来てください。本当のデザインをお見せしますよ フロントエンジニアを名乗るならデザイナーの要求を完璧に実現できて当然
実現できない奴はフロントエンジニアではない
フロント業界の質が下がるからバックエンドエンジニアを名乗ってくれるか フロントだけの人なんている？
ホームページ屋さん？ 大手というか募集しているところは割とフロントとバックエンド分けてるよね
小さなプロジェクトしかしてないからいつも両方やってるけど
本番インフラやデザインは別の人がやってるけどね デザイナーの要求を完璧に実現できて三流
要求以上のものに仕上げてようやく二流
お前らはいつになったら一流になるんだ？ vue作ってると.vueファイルがめっちゃ長くなるんやが、なんか対策ってあるます？ ちょっと極端だと思うけど、一つのファイル（やclass）はだいたい200行以下にするし、関数は概ね20行以下にしてる。
長いスコープを管理できるほど頭が良くないので Vueほんと分かりにくくなったね
reactの方が全然楽 reactよりややこしいvueって存在意義なくね… useEffectやuseCallbackが10も20も出てくるようになるときっついなあっておもってたけど
vueはもっときっつくなってるのかな…… >>824
やってることはreactのFCと一緒
そこでreactで良くね？ってまず思う
我慢して使ってるとreactを再解釈した弊害か目的がよく分からないものがチラホラでてくる
これ一体なんだ？と調べ始めるとドキュメントやユーザーの薄さから情報は得られずソース追いはじめるがアップデートで破壊的な変更
だんだんバカバカしくなってくる
先の知れてるVueに詳しくなってもしょうがないし結局reactで良くね？ってなる 言うほどvue難しいか？
3.1になってから更に簡単になったと感じてるけど >>822
vue3で追加されたものだけを使うってやればシンプルなのだけどね
既存コードはどうにもならん vueのどこが難しいんだ？
vue使ってるプロジェクトのコードベースがよっぽど酷いのか？ Reactもそうだけどコードが増えるのがね。
単純なことしかしないのに、なんであんなに大量なコードを書かせるのか
必要なら大量になっても構わないが、単純なことは少ないコードで実現できるようにしろと 単純な事、というのが何かわからないけど、それは使い所を間違ってるんじゃないかなぁ？
ちょっとDOM操作が多かったり、あるコンポーネントのパラメータが別のコンポーネント（やエレメント）に絡むような内容だと、コード長は普通に減ると思うけど。
Reactの話ね。 サンプルはカウンターかtodoだけどカウンターもtodoも開発では作らん
カウンター作って、どうだ！？Reactは簡単だろ！！
ってなるわけねーだろ
これの1万倍は複雑なものを作ってる >>830
そうだよ。そしてReactやVueが適さないユースケースがたくさんある >>831
そもそも複雑なものを作らないほうがいい
なぜ単純にしようとしないのか >>833
んなこと誰だって思ってるしそれが理想だけど、現実はもっと複雑なこと求められるだろ
一人で作ってんならともかく 複雑な要件は断れば良い
仕事も面倒も無くなって一番シンプル >>833
実際に開発するとわかるが、実業務が複雑だから複雑にならざるを得ない React（とNext.js）上手く使うと10000倍複雑なものが500倍くらいの複雑さで済むと思うんだよなぁ。
リアクティブである事と有用なコンポーネントが揃ってる事はそれぐらいのポテンシャルある コンポーネントを作りやすいなら別にSPAじゃなくてもいい気がしたけどコンポーネント1番作りやすいのがReactだった SPAとMVCの組み合わせってアリ?
ログインだけMVCでやりたい paypalのエンジニアも言ってたけど、小・中規模だとContext分離やuseCallback、useMemoってほとんど使わんよな
とにかく使え、とにかく分離しろみたいな解説多すぎ せやで。だからウェブサイトだとjQueryでいいってことになるんだよ どんな小規模でももうjQueryは嫌だな
CDNでReactをロードしてJSXで書いちゃう そして炎上する
「デジタル庁創設に向けた準備サイト」がスクリプト無効で閲覧できない
https://blog.w0s.jp/643 >>846
CDNでReactロードするくらいなら、Preact使った方が小規模良向けじゃね？
tree shakingしてないReactとかめちゃデカいし、ブラウザのプライバシー強化で共有ライブラリのキャッシュ効かなくなっちゃったし。
小規模が開発規模を意味して、環境構築を楽したいって事ならCDNか
>>847
15年からタイムスリップしてきたのかな？
デジタル庁にはこういう奴の意識改革を本旨に据えて欲しいな >>849
無駄なことをしないというのも意識改革だよ この準備サイトとやらがこの段階で10年後やらを見据える必要あるのかとか考えてなさそう
JSにアレルギーとかありそうw
ま、代替テキスト全くないのもどうかとは思うがね Nextjs使うよりもreact単体で作った方がいいケースってあるか？ >>852
規模次第じゃないの？
vueでも何でもnuxtってのはどうかと思うし 10年後を見据えるとvueもnuxtもなくなってるだろうな >>854
そうか？reactの方が無くなってるかもよｗ
正直流行るような要素無いやんｗ
独自ルール多すぎで >>855
実際に流行ってきてる
https://w3techs.com/technologies/history_overview/javascript_library/all/y
ぶっちゃけな。技術なんて大差ないんだよ。
あとはうまく宣伝できたほうが勝ち
2018/1/1 2019/1/1 2020/1/1 2021/1/1 2021/5/4
jQuery 73.1% 73.6% 74.2% 77.2% 77.8%
React 0.5% 0.2% 0.3% 0.3% 1.8%
Vue 0.1% 0.2% 0.3% 0.5% 0.5%
nuxt 圏外 Reactは今年ようやくjQueryの成長率を超えることができた
これはJavaScript全体でみてもまれな革命的な事例だ
誇っていいぞ
あとはどこまでこの快進撃が続くか
どこまでjQueryに追いつけるかだな
前みたいに一時的なものじゃないといいな jQueryの何が不味いかって、ECMAScriptやDOMの進化に付いていけない奴が量産された事なんだよなぁ。
fetch()がある現代にajax()使うためダケにjQuery突っ込まれてもね（IE非対応サイトなのに） 今のVueを見てるとクラスと関数コンポーネントでごたごたしていた頃のReact思い出すわ >>859
それでECMAScriptやDOMの進化についていくと
どういうメリットがあるんですか？ >>859
進化論で有名なダーウィンが言った言葉の話を知っていますか？
https://gendai.ismedia.jp/articles/-/70729
> “進化論を唱えたダーウィンは、「この世に生き残る生き物は、
> 最も力の強いものか。そうではない。最も頭のいいものか。そうでもない。
> それは、変化に対応できる生き物だ」という考えを示したと言われています”
↑こんなことはダーウィンは "言っていない" として有名な話です（笑）
自民Twitter炎上で注目 「ダーウィンの進化論」とは
https://www.tokyo-np.co.jp/article/37932
> ◆自民広報キャラ「生き残るのは変化できる者」に批判殺到
> 投稿直後から「進化論とも関係ないし、ダーウィンも一言も言ってない」
>「あんまり適当なこと言わない方がいいよ」などと批判の投稿が相次いだ。
> つまり、ダーウィンの進化論は、環境により適応した個体が子孫を残していくということ。
> 変化の結果で生き残ることはあっても、生き残ろうと変化していくものではないのだ。
jQueryは環境により適応しているため生き残ったわけですね。 すげーどうでもいい話ありがとう
ところでこのスレjqueryの話題扱ってないんだけどどう思う？ jqueryとreact/vueの使う場面って全然違うじゃない？
アプリケーション作るためにreactとか使ってるわけでそこでjqueryがどうこう言われても困っちゃうわけよ
ホームページ作ってるんじゃないの
わかる？ 同じことがreactにも言えるわけで
アプリ作ってるんじゃないの
わかる？ 確かにネット上の記事やコミュニティなんかを見てもjQueryの混じったコードは、Reactのそれに比べて明確にダサい（平均技術レベルが低い） 昔はVueがあればjQueryは要らないとか、明確にポストjQueryとして語られてたのに、言うことコロコロ変わるよな だってJavaScriptからのアプローチ（HTML+CSSはJavaScriptで生成）と
HTML+CSSからのアプローチ（JavaScriptは追加機能）とで
全然アプローチが違うんだもの、ポストjQueryになんてなるわけがないよ
今までHTMLとCSSメインで作っていて、一部分にjQuery使ってた所が
これからはJavaScritptに埋め込んで、ビルドして生成するだ！って
なるわけがないっつーの CDNでreactを直接参照してscript type="babel"
小さいサイトならこれでいい commonJS絶滅して欲しい
明日から急に使えなくなってくれ >>874
HTML+CSSからのアプローチなら今はプレーンJS+DOMで事足りちゃうんだよなぁ >>877
jQuery+DOMでも事足りるんじゃね？ jQueryおじさんなんとかならんかな
老害って言葉がぴったり 使ったほうが楽になるんだから
使わない理由がないってことだよ jQueryは帯（ウェブアプリ）に短し襷（ウェブサイト）に長しだし、変なクセは強いし、ランタイム無駄にデカい（上に下手すると使いまわせない）し、おまけに遅いし、楽さより面倒臭さが強くない？ >>847
SSRすることで解決するようで良かった。
これでCSRしないと空白ページのみという駄目サイトを脱せますね。
JS前提とせずともせめて閲覧だけは出来るべきですし、
JS有効環境でもReact等の重いダウンロード待ち＆CSR待ちで表示までの悪体感だけは避けて欲しいですね。 この手のサイトならSSGが一番良いかと。表示は確実にされる、速い、サーバに負担がかからない。
>>885
React単体は存外速くて軽いので、体感悪いサイトは色々突っ込み過ぎなんだろうね JSがいつか死ぬかもしれないとか詭弁だな
それならブラウザもHTMLもいつか死ぬかもしれないだろう JSは意外と快適なぐらいには育ってしまったので駆逐は難しいだろう Wasmはjavascriptにとって脅威にならず、互いに補完するものらしい。。
って、どういうことやねん！！ SvelteってjQueryの代わりにはなってもReactの代わりにはならんよね
html in JavaScriptなのか
JavaScript in htmlなのかで根本的に目的が違ってくる JavaScriptをオフでも見れるならjQueryの代わりになる いやそれじゃSSRとかいい出すから違うな
ウェブデザイナーがJavaScriptを使わずにウェブページを作成できるなら
jQueryの代わりになると言ったほうがいいか JavaScriptオフでも見られるｗｗｗｗｗｗ
jQueryってスゲーｗｗｗｗｗｗ
ｗｗｗｗｗｗ こういうバカってjQueryを何だと思ってるんだろうな。
JavaScriptで書かれたJavaScriptから呼び出すJavaScriptのライブラリだというのに。 >>902
それな。DOM APIでやれることを簡潔に記述できるようにしただけで
デメリットがあるとしたら僅かなパーフォーマンス低下とデータ転送量の増加があるだけ
ブラウザネイティブの機能と基本的に変わらないわけで
jQueryを否定するっていうことはブラウザのDOM APIを否定するのと同じなんだよな
ReactとかはそのDOM APIを否定してるわけだけどね
（DOM APIを使うな、混ぜて使うなっていう設計） スレタイの3つだとsvelteがシェアでは一歩遅れてる感じ？ ReactはDOMの補完じゃなくて、DOMをリアクティブに変える事がキモだからね。
DOMの補完だったjQueryはブラウザの進化で価値が無くなったけど、Reactがブラウザに取り込まれるとは今の所は思えない。
Reactが世代交代するのはもっと便利なパラダイムが出てきた時かな。 まだバーチャルDOMの概念をわかってない奴がいるのか
jQueryだとかDOM APIだとかいってるやつは根本的に理解できてないから必死で勉強しな
React使いは遥か高みにいる
ここまで登ってきな？ >>904
ライトユーザーから見たらコード数が少なく済むのが魅力的に見えるらしいがベビーユーザーから見たら別に不必要にコード数を減らしたい訳じゃないしな > DOMの補完だったjQueryはブラウザの進化で価値が無くなったけど
jQueryにはDOM API を簡潔に記述できるという価値が残っていて
それを理由に今もシェアを伸ばしてるんだけど知らない？
https://w3techs.com/technologies/history_overview/javascript_library/all/y
もうちょっとでjQueryのシェアは78%に到達するよ。1年で2%伸びてたりもするから
今年中は無理でも来年中には80%に到達するかもしれないね >>906
バーチャルDOMはDOM操作が速くなったら不要になる技術だよ >>910
残念ながら全然違ってる。
jQueryにおけるインスタンスはDOM要素のツリー
DOM要素のツリー毎にイベントハンドラが閉じた状態
そしてインスタンスをまたぐような処理はDOMのイベントではなく
DOMインスタンスのイベントとして送信される
その図に書いてあるようにReactが一つの巨大なstateオブジェクトを持っているのと違って
jQueryの場合はインスタンスごとに小さくstateを持っていて
インスタンス動詞の結合度は弱く、少ないイベントで通信する >>910みたいなものを見ると
自分でぐちゃぐちゃに壊しておいて壊れてる！って
言ってるだけなんだよなってわかる >>909
早くなることはないよ
canvasみたいなAPIじゃないと高速描画は無理 >>910
この図初めて見たけど、React触ってるときの感触めっちゃこれだわ！
あっちでイベント書いてこっちでインターフェイス書いて、そことここの処理の時系列による噛み合わせを考えて……な生DOM世界からの脱出だった。
Web標準コンポーネントで楽になるかと思いきや、それはそれで手続きが面倒くさかったし >>911
一つの巨大なState？？
React使ったこと無いの？ >>913
バーチャルDOMが最終的にDOM APIを呼び出してるって知ってる？
バーチャルDOMがDOM APIより速くなることはないよ
そういう意味なら、そのとおり >>916
Reactって仕組みの中にStateがいくつか入ってる図に見えるけど？？？ 複数のイベントから、同じstateに書き込んで
stateをグローバル変数のように使ってるやろ その図は本質ではない
一つのグローバルステイトを用意すればjQueryでも同じことはできる
Reactの本質はコンポーネントという単位で関心ごとを一つにまとめ上げたことだと思う
その中で状態の更新を一方通行でやれること いや功績と言うならreactというよりフレームワーク化とエディタ含めた統合環境だろ。少なくとももうjQueryは使いたくねえよ
あとスレチだからjQueryの話は止めとこうぜ >>917
それはコンパイラがアセンブラより速くなることはないといういつもの話。 >>921
自分で答えいっちゃってるじゃん
その図は本質ではない。
クソプログラマがメチャクチャなコードを持ってきて
ほらメチャクチャだと言ってるだけで
そんなやり方はしない
が正解なんだろ jQueryおじさんがReact触ったことないのはわかった みんなの職場は
デザイナーに投げたデザインページを
動的ページに合わせこみはどうやってるの？
俺はHTMLでもらって埋め込みを全部やり直してるけど
超めんどくさいわ
特にjsで動的にな動きをデザインに合わせて再実装するのが
苦行で死にそう
デザイナーが作ったcssクラスの解読とか
特にアイコンや
before after要素とかがまじで嫌い >>928
そういう所に使うのがそもそも間違ってる
見た目なんかどうでもいい所に使うのが正しい >>928
お前が無能なだけ
デザインから構築すらできないならフロントエンドエンジニアやめろ
html cssなんてデザイナーよりできて当たり前だろ
style componentやjsxをデザイナーにやらせるのかよ？ >>929
そういうところに使うもんだろが
アホなの？ デザイン分業ができなくなった言い訳
全部自分でするもんなんだよ！ >>928
あいつらなんでbefore afterとかハック的なCSS多用したがるんだろうね
解読＆再実装が手間なの、普通にわかるわ
ソースは読まず、見た目だけで再実装する方が早い説、あると思うよ 従来のフローの中でreactやvueを採用したならデザイナにStorybook覚えてもらってパーツ作ってもらうのが良いだろね デザイナーはXDとかでモックつくるだけでいいだろ
jsxとcssはフロントエンジニアの仕事だよな？
できないお前らの責任 たぶんデザイナーは、SASS, Bootstrap を勉強しないからだろう
レスポンシブ対応できないでしょ ぶっちゃけイラストレーターとかで
こんな感じのデザインですってのさえ示してくれればいい
小汚いソースをよこされるよりはｗ >>933
ようするにあなたは理解できないんですよね？
馬鹿なんですよ。あなたが。 >>936
sass、bootstrapはウェブデザイナーが使うものですが、
あなたはreactでsass使ってるんですか？
作ってないくせに、言っちゃったんですか？ ウェブデザインというのはCSSやHTMLで構造やデザインを定義していくものなので
JavaScriptで手続き型的にデザインを構築するのと発想が違うんだよな どちらでも出来るけどjsのほうがわかりやすくて簡単という意味ですね 静的に定義するという能力が足りないんだよな
HTMLとCSSは静的ファイル。静的に定義されている。 おめーらさんたちはstyle componentとjsxをデザイナーにやらせるんだな
ただのプロップス屋じゃん たしかにデザイナとの協業は今でも難しい
10年前より難易度上がったと思うわ それだけデザイナに求められる技能が増えたか、もしくはデザイナが不要になってきたんだろな
個人的には二度手間三度手間になるのでHTMLやcssをいじらずデザインだけ考えてて欲しい 意訳 うちのような弱小企業には
まともなウェブデザイナーがいない
そんな会社にまともな技術者がいると思うかね？ デザイナーはカンプだけ作ってれば十分だろ
昔と比べて求められる知識も増えてるんだからさ
下手にコーディングされても足手まといだし UIUX考えられないデザイナとかゴミ
っていうか邪魔 >>947
でもフロントエンジニアはカンプすら再現できないゴミじゃん
目ん玉と脳みそが生まれつき腐ってるから見たものが何かすら理解できない Emotion使ってみたけどCSSinJSって、Bootstrapとかと違ってCSS全部書かないといけないんか
それとも別でそれ用のCSSライブラリある？
Bootstrapと組み合わせるのは違うよな 2019/9
Build a Mini-Course Website with React, Ruby on Rails, Webpacker, and Bootstrap
https://www.youtube.com/watch?v=B0SxxHAImhc
React コンポーネントのJumbotron に、
pt-4 mt-4 text-center とか、Bootstrap の属性を付けてる GitHub における大規模なモノリポのパフォーマンスの向上
https://github.blog/jp/2021-03-19-improving-large-monorepo-performance-on-github/
＞ GitHub の有名な Ruby モノリスを解体し、GitHub のすべてのユーザーのためにリポジトリのパフォーマンスを向上させる新しいマイクロサービスを Go で作成しています。 PCサイトをレスポンシブに変えることはできるんだけど、
htmlとcssを新規で作る時って、PCファーストとスマホファーストって難易度はどっちが高い？
そもそもスマホファーストの定義ってPCで見た時に横幅いっぱいに広がること？
横幅変えた時に動的に変わるのって％だと思うけど、かなり難しそう
ブレイクポイントは580pxぐらいの1つにする予定です htmlやcss書くデザイナーと仕事したことないわ
かなりレガシーな話してないか？
DreamWeaver的な時代の IEなんてもうサポート切れるぜって言っても頑なに要件から外さなかったあの会社
ゆるさねえわ JSのフレームワークをこれから習得するならReactが安定なのかな
業務で使うというよりは、試作や書き捨てな用途が多いから学習コストが低めのほうが良いのだけど
vueは3になってからReactと大差ないとも聞くしどうなんだろ？ 自分が作りやすいと思う方を選択した方がいいと思う
個人的にはVueの方が今でも良いな
reactはやはり書き方が気持ち悪すぎる フロントは移り変わり激しいからReact頑張って覚えた頃には時代遅れになる可能性がる
あと先進的なことを追う傾向にあるから仕様も破壊的に変わったりもする
実務だったりサクサク読み進められる人じゃなければ、趣味ならVueでいいかもってどこかに書いてあった ここ数年はReact一強が続いてきたし、移り変わりが激しいと言っても5年くらいのスパンだろ。
新しいものを覚えるだけで数年かかるような人は仕方がないが、普通の人は自分が
使っているものが時代遅れになったと感じてから乗り換えても十分間に合う。
将来性に賭けて青田買いすると外した時が痛すぎるしな。 移り変わり激しい言うてもReact上のレイヤーの技術が新しく出てきた、とかが多いしな それな
以前フロントの若い連中がやたらとイキってバックエンドを見下してくるから
Reactってやつは新進気鋭の若手スーパープログラマじゃないと扱えない高度なライブラリなのかと内心ビビリまくってた
でも必要にかられていざやってみるとクソ簡単で拍子抜けしたものだ
フロントの連中はこんなものでマウントを取ろうとしてたのかと正直呆れたよ
バックエンドのほうが万倍難しかったね >>965
JSのフレームワークっていうか、SPA用のフレームワークだぞ
用途に合ってるならいいけど >>973
素のReactだけならめっちゃ簡単だしな
フレームワークが薄いし Reactは難しいものを簡単にする為のライブラリだからね。
しかし、フロントとバックエンドがいがみ合ってるとか、嫌な会社だなw JSXって使った事ない人にはhtmlとjsを悪魔合体させたガバガバ言語だと思われがちだけど
実際習得してみたらめちゃくちゃ厳密なルールの下JavaScriptの中にタグは入ってるからな
逆に<br>タグとか書いてるヤツにキレたくなってしまう 簡単と言ってる奴ほど何もできない
Reactで大規模開発やってみろ
お前らの無能さがすぐわかるから で、でたー。クソかんたんなReactでマウントマン 今頃フロント始めてみるゴミクソw
いつまでバックエンドやってんだか バックエンドで忙しいからねー
暇なときは片手間にフロントやるのもいいかな
頭空っぽにしてコーディングできるから休憩にちょうどいい >>965
用途に適したフレームワークや用途に適した手法を使うべきです。
Reactにも向いていないことは山のようにあります。
あと記述面だけでなくReactにかぎらないですが、遅さ重さという犠牲により仮想DOM等を実現しています。
それらも用途により必要ないもしくは効率優先など様々な理由でReactを避けたいことも多々あります。
もちろん各々の用途で、無駄とか非効率とか記述しにくいとか向いてないので複雑になるケースとかを全て無視してもいいなら、Reactだけでもやっていけないことはないでしょう。
用途に応じてそれぞれ適切なものを選びましょう。 Next.js以前はそうだったね。というか仮想DOM遅くないよ。 Ruby on Rails では、React, Bootstrap が多い。
Vue.js は少ない
Reactは米国企業で、JSX で書けるので、米国で多い。
Vue.js はローディングアニメ・トランジションなど、CSS アニメが強い感じ 注目度では、YouTube で有名な、雑食系エンジニア・KENTA のサロンの、
Ruby on Rails 初心者用コースに、React ではなく、Vue.js SPA が加わった。
つまり、日本のプログラミング学校・自社開発系の転職市場では、Vue.jsなんだろう
Rails, Linux, Docker Compose, Node.js(Webpack, Babel), Bootstrap
VSCode(Remote Container, WSL2 ならRemote WSL), Heroku, CircleCI、データベース
今までは、Docker Compose までが初心者用コースだったが、
最近は誰でも、Docker出来るから、
AWS Fargate, Terraform, Vue.js, TypeScript が主戦場
だから、AWSのくろかわこうへいのサロンにも、入る必要がある。
今では、1年の未経験者が、10年以上のプロよりも技術力が上になってる！
KENTA、2021/4
2021年のWeb系エンジニア転職を成功させる3つの技術要素
https://www.youtube.com/watch?v=70VrB7LTe9g それにしてもangularは話題にのぼらんなあ
やり方決まってるしそんな難しくないんだけど Electronではじめるアプリ開発
~JavaScript/HTML/CSSでデスクトップアプリを作ろう、2017
この本では、Electron, React, JSX, Firebase, Spectron, Mocha
サーバーがNode.js なだけで、
サーバーがRuby なら、Ruby on Rails, React, RSpec, Selenium Webdriver と同じ
まあ、Windows デスクトップアプリに限り、Electron, Reactで作る事もありかな
>>953
は、Rails, React, Bootstrap だけど、
Rubyの本も出してる、ソニックガーデンの伊藤淳一は、既に4年前に、Vue.js を使っている
伊藤淳一、2017/2
Rails 5.1で作るVue.jsアプリケーション 〜Herokuデプロイからシステムテストまで〜
https://www.youtube.com/watch?v=ycOeM2umXkY ガイジの宣伝するなよｗ
RubyはマジでNGワード入りだなｗ >>985
仮想DOM方式は明白に遅くて重いです。
ただしそのコストを払う犠牲と引き換えに管理が楽にできるメリットを得るのが仮想DOM方式です。 >>995
https://ics.media/entry/190731/
メモリはともかくとしてそれ以外では明白に遅いと言えるほどの差はないだろ DOM描画コストに比べたら仮想DOMツリーの走査（JavaScript処理）コストなんて誤差みたいなものだよね 仮想DOMが遅いっていうのは大抵不必要な描画を抑止できていない場合 このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 125日 12時間 7分 36秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
