Vue vs React vs Angular vs Svelte Part.9
レス数が1000を超えています。これ以上書き込みはできません。
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/
Svelte
https://svelte.dev/
※前スレ
Vue vs React vs Svelte Part.7
https://mevius.5ch.net/test/read.cgi/tech/1610901677/
Vue vs React vs Angular vs Svelte Part.8
https://mevius.5ch.net/test/read.cgi/tech/1621744952/
★ここではjQuery, Ruby, C#, Blazorの話題は禁止です
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
Next, Nuxt, Sapper, Gatsby, VuePress, RedWoodなどはおｋ。 どういう連鎖アボン正規表現入れたら快適になるかな？ Next.jsはええぞ。SSRもSSGもISRもSPAも行ける そもそもvsだから変なの湧くんじゃね
普通にタイトル4つの総合でいいやん このスレが、いつもの荒らしが立てたもの！
いつもテンプレに、自分が有利なように追加してる
>1
>★ここではjQuery, Ruby, C#, Blazorの話題は禁止です
>★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
>Next, Nuxt, Sapper, Gatsby, VuePress, RedWoodなどはおｋ。
多くのPython のスレでも、いつもテンプレを変えている。
>・当スレにRubyのソースコード類を書くことを禁ず
>・Ruby等、Pythonではないプログラミング言語での回答類・質問を書くのも禁止
>・「Ruby では」「Rubyでは」「Rails」正規表現→「^クソチョンw$」をNGワード登録推奨
多くのJavaScript のスレでも、
jQuery, Lodash を禁止とか書いている
いつも、この荒らしがスレを立てて、テンプレを変えてくるので、
漏れらは荒らしの立てたスレから、正規のスレへ誘導してきた このスレの削除依頼を出して、下の正規のスレへ移ってください！
Vue vs React vs Angular vs Svelte Part.9
https://mevius.5ch.net/test/read.cgi/tech/1642316327/l50 ここで良い
向こうのスレは無関係なjQueryが唐突に入れられている 向こうのスレは荒らしが立てた事を証明する捨て台詞がご丁寧にも書いてあるしね Reactはいいフレームワークだけどフロントって非同期使いまくるのに非同期の扱いが残念なのがちょっとね
他のSPAフレームワークって使った事ないけど非同期はどうなんだろう >>13
まず最初にお前が理想のフレームワークをいえ
Reactが残念なんじゃなくて
お前が非同期処理を理解できないだけだろ
まるでプログラミングを勉強したくないけど
なんか凄いものを作りたい、簡単に使える言語ないの？って
言ってるようだ >>14
レベル低すぎて相手するのも面倒なレスだけどreactが非同期ニガテなのは常識だよ
今までずっと正解らしい正解がみんなで共有できてなくてuseState、useEffectで分かりにくい処理を地道に書く、それらをラップするオレオレフックを作る、別のサードパーティフレームワークを付け足して使う、などなどそれはもう、迷走しまくってた
reactが世に出てもう何年経ったかわからんが、最近になってようやっと公式が重い腰を上げて、Suspenseに取り組み始めたけど、これだって今までよりはマシかもって程度であって、けして非同期が楽だとは言えない代物
そんで楽してすごいものを作りたい、というのはフレームワークの存在意義そのものであって、それを否定するのは何も理解してない車輪の再発明マニアだけだ >>13
そうかなぁ、useEffectで非同期拾ってstate変えたら全部スパッと変わるんだから、やりやすいと思う。useEffectは非同期関数食ってくれないけども >>16
いや、あれはわかりにくい
依存関係とか諸々含めて、誰でもすんなり理解して間違いなく使える仕様とは思えん
必ずどこかでハマるように出来てる
つうか、完全に理解したとしても冗長な記述が多すぎる
reactの仕様を大きく変えてasync JSXタグをサポートするべきだと思うんだよな
例えばこういうの↓
const FooView = async () => {
try {
const foo = await fetchFoo();
return <View>
<Text>{foo.name}</Text>
<Text>{foo.age}</Text>
<View>
}
catch (e) { return <ErrorView error={e} /> }
}
もし仮にここまで出来れば俺は「reactは非同期が楽」と言っていいと思うぞ
つーかこんなんreactの開発者レベルならとっくに気付いてる筈なんだが
怠慢なのかわからんが、非同期をずっと放置し続けてきた >>18
あーなるほど。確かにそこまでサポートされてれば楽かもな～。
待ってる間はFragmentが入るようになってれば（多少柔軟性は落ちても）同期部分とも連携は取れると。
俺はそこまでは要らないかな。でもなるほどね >>18
いや待て、そこでfetchしたら駄目じゃね？ >>20
機能を提供するのはよいぞ
どう使うかは宗教のもんだい fetchFooが何度も走るからその場所はマズくね？ useSWRを使ってみるとか
(まだ使ったことないけど)
見た感じそれなりに使いやすそう?
import useSWR from 'swr'
function Profile() {
const { data, error } = useSWR('/api/user', fetcher)
if (error) return <div>failed to load</div>
if (!data) return <div>loading...</div>
return <div>hello {data.name}!</div>
} >>23
単純なケースでしか通用しない気がするけどいけるんかな？ >>18
コンポーネントにガッツリ副作用入れてどうすんだよw はっはっは、だから言ったろ
お前が非同期処理を理解してないって
想像した通りに動いてくれるわけじゃないのだよ
不可能なことは、不可能 >>18
そんなバグの温床になりそうなコード書くくらいなら、
componentDidMountでfetchして、素直にsetStateしとけ
それで済む話だろ このスレは、荒らしが立てたスレです。
まともな人は、移動してください！
>>9-10
を参照 >>26
具体的な事言わずに批判だけするとか……老害かな？ >>22
パラメータが変わらなければ同じpromiseが再利用されるので問題ない >>30
fetchFooは（シングルトンみたく）何度呼び出しても同じPromiseを返すって事か。それなら確かに問題ない。
そう云うPromiseを作るhookと待ってる間はFragment（か何かをDOMに接続）、あとエラー時用のインターフェイス（Promise関連だからcatchメソッドで良いか）が必要、と。
う～ん、俺はuseEffectでいいやw >>31
そうじゃない
react側で不要な再実行を避けてpromiseを再利用するように作るだけ FooViewが発行したPromiseインスタンスを再利用するという事？ lazyとSuspense、ErrorBoundaryを使う
データ単位で制御したいならRecoilを組み合わせる（Atomのdefaultやselectorで非同期処理）
>>13はRecoilとConcurrentModeがまさにそれ
あと>>16の"非同期関数食ってくれない"という表現が良く分からないのだが、即時関数を使えば良いという話ではないのだろうか >>34
useEffectの引数に直接async function入れられなくて少し不便ってだけの話で特に特に問題無いから無視してええよ <ErrorBoundary onErrorComponent={ErrorView} >
<Suspence fallback={<Loading />}>
<Text>{props.foo.read().name}</Text>
</Suspence>
</ErrorBoundary>
一見すると良さそうだけど間違ってる
Textをラップするコンポーネントを作ってやらんとダメ
なんか書くものが多くてめんどくさい
後は純粋に醜い
処理フローの制御をタグで書きたくない
recoilって正直なとこContext APIやReduxより多少スマートだけど根本的なとこはあんま変わってないと思う
というかrecoilって基本は状態管理ライブラリだし非同期のめんどくささとはまた別の話では？ ラッパー高階関数なりhookでも書けばええんちゃうか……。
目的を最小のコードて書けるライブラリは用途特化ライブラリであって、汎用たり得ないと思うんだ。 Suspenseでラップされたコンポーネントで使われているAtomで
非同期処理を実行している間はfallbackが呼ばれるため、loading stateが不要であったりと
RecoilはConcurrent Modeを意識した作りになっている
というのを踏まえた上で、Reactはv18から非同期でコンポーネントを扱う場合は
Suspenseでラップする形を押していくようなので
その手法が嫌なら何とも言えない（あなたの提案が悪いというわけではなく、Reactの方針的に） そうやって過剰な設計をするならReactとかの
フレームワークは重くなるんですよね 重いってのは色んな要素や意味があるし、かなり曖昧表現だな。
スピードテストベンチマークも増えて、一時期に比べればみんな速度を意識しだして、Webって早くなってきたよ。 ここ数ヶ月で重すぎてブラウザバックした記憶はqiitaだけだな
あれは何のフレームワーク使ってるんだろ >>41
なる程。となると容量だな。
帯域制限状態を256kbpsとするとminify+gzipなReact(ReactDOM含む)で36KBなら1.125秒か。時間かかるっちゃかかるけど、この速度域だと画像すら重すぎてそれ以前の問題だなw 結局のところ単純で速い方がいい
reactでゴテゴテに装飾したSNSより伍ちゃん戦ブラが良いんだな そもそも目的や規模感、場合によってはチームの習熟度で不足にも過剰にもなる
結局は毛嫌いせず、状況に応じて使い分ければ良いだけの話 >>42
あれフレームワークっていうより遅延ローディングの問題な気がしてる
バックエンドが詰まってる印象 >>42
> ここ数ヶ月で重すぎてブラウザバックした記憶はqiitaだけだな
普通にネット見ていてもReactのような
重量系フレームワークを使ってるところなんて殆どないからね
QiitaはReact使ってるみたいだけど、一体あれのどこに必要なんだろうか とりあえずSSG使ってCDNにpushすれば解決するのだがそういう改良する人材もいないんだろうな
元々優秀な技術者集団がいたはずだけど
技術のコモディティ化でその人たちも凡人になったのか
人がいなくなったのか >>50
Qiitaの親会社の偉い人に合った事あるけど、技術や技術者の事なんてどうとも思ってなさそうな人だったよ。それからしばらくしてあの炎上騒ぎが起きて、さもありなんと思った。 >>49
Zenn、Twitter、Instagram、Facebook、LINE、Yahoo、ZOZO、はてなブログ、AmazonのAWSの管理画面などなど
これらはフロント全体もしくは部分的にReactだけど？
Googleは多くのサービスでAngularだし
普段ネットで見てんの？ 掲示板のレスの1つ1つに開閉式のメニューをつけるのってどうやるんだ？
下はyahooニュースだが、レス一覧の「非表示・報告」ってとこ押したら出てくるような奴
https://news.yahoo.co.jp/articles/5d52fe0f406f1aa3e9f2263f58966858786bf8a0/comments
vue だったらレス一個一個にコンポーネントマウントしないといかんのか？？ >>54
VueでもReactでもAngularでもそう >>55
なるほど。内部的には各ボタンにイベントリスナーつけるわけだから当然と言えば当然ではあるか。
サーバ側ではレスをPHPでforeach で回して出力するけど、そのタイミングでvueがマウントするためのコードを生成する必要があるってことなのか？ vue選んだ会社はどうするんだろうか
オワコンまっしぐらなのに 生田勇人(39)
高知市朝倉中学校卒業
恐喝と暴行、偽証、傷害容疑で逮捕、起訴。
://togetter.com/li/1227954
://pbs.twimg.com/media/DbUOGw1VQAAqJcx.jpg:large
://i.imgur.com/tuUldwv.jpg
://www.youtube.com/watch?v=UyNXI8usCrM
取り調べで「事実無根」と容疑を否認。
卓球所に松岡学(39)と出入りし賭け試合を被害者に強要、一回ミスったら1000円払えと発言。
2万円を取ろうとした。親にチクったらただじゃ済まんぞと被害者の胸倉をつかみ壁に叩き付け2000円を脅し取り、後日腹を複数回殴った疑い。
生田勇人の両親も被害者の親にたかっていた。 >>56
一例だけど、ページが読み込まれてCommentListコンポーネントがマウントされたタイミングでサーバからコメントを取得して
メニューを持ったCommentコンポーネントをcomments.mapで回す
この時のcommentひとつひとつをCommentコンポーネントのpropsに渡して描画していく Vueはそもそもの背景にAngularがあるのに
Composition登場以降、React寄りになったのが何とも
今のVueはどこに向かっているのか分からん >>54
https://codesandbox.io/embed/dark-dawn-0sk8t?fontsize=14&;hidenavigation=1&theme=dark
↑ でけたで！！！
VueじゃなくてReactやけども
みんなもよかったらコードレビューしてや！
これ思たんやが、メニューの中身共通やんか
ヤフコメの仕様に合わせて同時に複数開けるようにしたからこうしたけど、同時に複数開かなくてもいいっていう仕様やったらばよ
各コメントのカードの中にメニュー含めず、メニューは外に出して1個だけ記述する方が無駄なさげな気するんやがどないなん
コード的には同じもんが複数あるってイメージが湧いてしまうわけやが、基本マウントされてないから別にええんか
意味わからんかったらすまんやで その考え方で良いと思う
表示非表示といっても、仮想DOMのおかげで差分が更新されるだけなので
ひとつのメニューを座標などを保持してまで使い回すメリットがほとんどない
表示されているメニューをひとつだけとするなら
メニューを透明なBackdropと共に描画して、メニュー外がクリックされた場合はメニューを閉じるようにする
これはMUIのBackdropやMenuコンポーネントを参考にすると分かりやすいと思う
他にはグローバルステートにして、ひとつが表示状態となった場合、他が非表示となるようにする
これはReduxで複数のダイアログの状態を扱う場合なんかに使われたりする
規模感にもよるが、今だとRecoilで管理するのがシンプルでおすすめ
他にはonMouseLeaveで非表示にするのもアリかもしれない >>60
やっぱりコメント自体を非同期で取得してくるしかないのかあ・・・。
現在の仕様やと、サーバ側でコメントをhtml生成してからレスポンス返しているから、作り直すの大変やなあ。
開閉メニューだけをvueでコンポーネント作ってってことをできんかと思ってたけど厳しいかもなあ。
ちなみに生JSで開閉メニューを作成済みなのだが、それをvue に書き換えたかった。
>>62
うおおおおおおおおすげええええ
でもreactわからん・・・・・・vueでも同様のことができるんやろなあ。
メニューの中身は共通やけど、yahooの例で言えば非表示と報告やからそのコメントを特定できるIDみたいなものをサーバに送るために仕込んどかんといかんのや。。。 >>42
Railsは、GitHub, Airbnb, Disney, Hulu, SoundCloud, Shopify といった世界的に有名な企業や、
日本国内でも、note、クックパッド、freee、マネーフォワード、Progate、Qiita などで使われている
2021年10月には、Railsを使い続ける宣言をしている、GitLab が上場し、時価総額は約1.9兆円！
時価総額1兆円ぐらいまでは、Railsで行ける。
その後、Go へ移行する
ここで、URL を入力して、サイト分析できる
https://builtwith.com/ 女の娘が1人で起業した、食べチョクは、Rails, React
食べチョクは、生産者と消費者を結ぶ、農林水産物の直販サイトだけど、
コロナで取引量が30倍になったとか
海外のRailsでは、ほとんどReactが多い
ただ日本は特殊で、YouTube で有名な、雑食系エンジニア・KENTA のサロンでも、
未経験者の転職用にはReactよりも、Vue.js を使うように指示している Rails では、命名規約だけのフレームワーク・Stimulus もある。
イベントの書き方だけを決めている
Railsの作者・DHH が、デモなどでよく使う
1つのDOM に、コントローラーを複数設定できる
<div data-controller="hello goodbye"></div>
また、同じコントローラーを複数のDOMに設定できる
<div data-controller="hello"></div>
<div data-controller="hello"></div>
つまり、多対多
アクションはクリックで、helloコントローラーのgreet メソッドを呼ぶ
<button data-action="click->hello#greet"></button>
ターゲットを設定すると、this.nameTarget, this.outputTarget で、
ターゲットとなるDOMを取得できる
static targets = [ "name", "output" ]
greet() {
this.outputTarget.textContent =
`Hello, ${this.nameTarget.value}!`
}
ターゲットとなるDOM。helloコントローラーのname・outputターゲット
<input data-hello-target="name" type="text">
<span data-hello-target="output"></span> >>62
ややこしいstate管理してるな、コメントカードをコンポーネントにしてstate持たせりゃコード半分で済むやんけ、と思ったらメニュー使いまわそうとか考えてたのね。なるほど。
細かい所言うとfetchはPromiseな方がそれっぽい雰囲気になってええんちゃう、くらいかな。
>>64
html生成をjson生成に変えるだけだから楽なもんよ（悪魔のささやき）
Vue使う使わない以前に、コメントにはID付けた方が良いし、コメントは生htmlじゃなくてjsonあたりから都度生成の方が良いと思う。 プライベートなシステムの管理画面で複雑なReact使ってるけど重くもなくむしろ速い
どちらかというとサーバーにアクセスするAPIのほうが遅くてローディングアイコンくるくるしてる
閉鎖的なシステムだから業務ロジックはバックエンドではなくほぼtsで書いてるから処理は速い >>53
お前のインターネットの世界には
それだけしかないのか？ コンピュータ用語と関係ない用語で検索してTOP10のサイトが
どのフレームワークを使っているか確認してみればいい
例えば「ネコ」で検索するとかな 殆どない、に対してのレスだから
適当に列挙してもこれだけあるよ？って話でしょ 適当に列挙したと言う割に
有名なコンピュータ関連の会社に偏ってるから
ダメだって話をしてる
適当に列挙させるために
コンピュータ用語と関係ない用語で
検索したサイトで調べろと言ってる そんな謎調べ物させる前に重いサイト列挙すりゃ済む話やろ ループ内でuseState使えるようにはできないのかなー
これ完全にフレームワーク設計の欠陥だよね
自分も>>62みたいな書き方をよく書くけど配列から子コンポーネントに渡すpropsに変換する手間がかかって面倒くさい
しかも配列の1要素を変更しただけで配列全体が変更されたとみなされてイベントハンドラが更新されて子コンポーネントも更新されるのが気になる
純粋な子コンポーネントをラップしてstateを持たせたコンポーネントをプライベートスコープに書いて
そのラップコンポーネントを使うって手も有るけどこれはこれでめんどくさい
かと言って子コンポーネント自体に副作用を持たせるとテストがめんどくさくなって再利用性も下がる >>73
“殆どない”に対して”あるけど？”ってことなんだが大丈夫か？ >>76
いや、仕組みを考えればなぜそういう仕様なのかはわかるよ ListやListItemなら再利用前提だけど
CommentListやCommentListItemとかになる固有だったりするから内部に状態を持たせたらいい
テストが大変、ってことならカスタムフックでロジックを分離すればいい >>78
仕組みの問題なのはわかるけど
利用者の立場を考えたインターフェースデザインになってないのはフレームワークとしては残念ポイントだね
本当に良いフレームワークはまず使いやすいインターフェースがあってそこに実装を合わせていく
「実装の都合のせいで関数トップレベルにしかフックかけません」ってのはそう言う意味では怠慢かな
「どこでも書けるように実装の方で勉強しました」こういう姿勢が必要 >>76
状態を呼び出されたインデックスで管理してるんだからむしろわかりやすいと思うが
「副作用の内容」は全く意識しなくて良いのよ
そこはreactに丸投げできる
これこそHooksの素晴らしさ
わかりにくいと感じるのは副作用を意識してなさすぎるから
react難しいと言ってる人は関数型言語などの副作用、参照透過性、冪等性、(できればモナド)などその辺りを勉強し直した方が良い >>80
そういう意見もわからんでもない。
ただ、俺はそういう制約はあえてやってると感じるな。一見不便な制約だけど、それがある事によってコードが統制される。React的に正しい書き方に矯正される。 ドキュメントにフックがトップレベルでしか呼び出せない理由って説明されてるけどな CommentListも再利用前提ならプレフィックスを付けてArticleCommentListにしたらいい
ファイル数は増えていくが、コンポーネントをシンプルに保つ恩恵の方が圧倒的にでかい 結局はチームで統一されてれば良いって話ではあるけどね >>68
axios で投稿一覧取得して vue で表示する処理を書いたけど、
サーバ側でphpのforeachで回してた時htmlspecialcharsでエスケープしたり文字列操作したりしてたことをvue側でせないかんってことだよな？
なかなかめんどくさい気がしてきたがこのあたりどうしてるんだろうか マスタッシュ構文ならふつうにエスケープしてくれるはずだが >>87
逆に今時それを自動でやらないフレームワークなんてあるのか？ dangerouslySetInnerHTMLとかいう長くて物騒なパラメータ名大好き >>69
>サーバーにアクセスするAPIのほうが遅くて
そりゃ、データベースの外部キーとか、インデックスの張り方による。
N + 1 問題とか
Ruby on Rails の単一テーブル継承とか、多対多・1対多・1対1 とか、
高度資格のdatabase specialist みたいな国家資格とか
>>76
>配列の1要素を変更しただけで配列全体が変更されたとみなされて
Vue.js では、key を付ければ、他の要素に影響がないけど、
React には、そういう機能が無いの？ >>77
まったくないじゃなくて
殆どないって言ってるんだから
あるのは最初からわかってるだろ
お前ゆとり蚊？ >>93
もう終わったよｗ
ほんと有名な事例だけ上げて
それが全てだと思ってるからアホやで 最近はReact優勢らしいけど個人での小規模開発でもVueオワコンなの？
転職用のポートフォリオの為にGoとVueでウェブアプリケーション作ってるんだけど今からでも変えた方がいいのかしら >>97
優勢というかほぼ決着はついた
Reactにしとけ
vueは未来がない Vueは結局一回も触らんでオワコンなった
我ながら良い選択をしたね
今後メンテナンスしなきゃならん人はご愁傷様 https://zenn.dev/ytr0903/articles/d0a91f6180d34e
↑
reactばっか使ってるわしはこれ読んで良さようやんって思ってんけどな
vueは具体的に何がオワコンなんだい アジア圏でしか使われてない
Angularとずっとシェアがトントン >>101
現在のvueのベストプラクティスと言われてる書き方を見てみな？
ほぼReactでしょ
つまりそういうこと >>101
そもそもbetter angularというコンセプトの元
人気が出たvueだがその記述方法がオワコン化するに従って
Reactの機能を取り入れ始めた
そして全てがReactになる 別にvueでもいいと思うぞ
ここでオワコン言ってるやつは、そいつがそうなってほしいだけ
まあ、時間がそのうち決めるだろうさ これからはSvelteが流行るって聞いて勉強してるんだがそろそろReactもオワコン扱いしていかないか？ Svelteが殺してしまうのは多分ReactじゃなくてVueなんだろうな…… >>108
多分そうなると思う
結局Reactの素晴らしさはコンポーネントとHooksとJSXの連携なのだから
そこを避けようとするフレームワークはどこまでいってもReactになれない laravelとVueは中国語のドキュメントが充実している 日本は特殊で、YouTube で有名な、雑食系エンジニア・KENTA のサロンでも、
未経験者の転職用にはReactよりも、Vue.js を使うように指示している
誰か、Vue.jsがオワコンかどうか、KENTAに聞いてみてくれ
PHP, Scala は、KENTAがオワコン認定したから、もう新規プロジェクトは無い。
ZOZO はLaravel だけど、創業者の前澤が、会社の株を孫正義に2千億円で売って逃げた ケンタはフロントが絶望的にできないからお呼びではない これからはvue3 x Nuxt 3だよ
Reactなんて外国にカブれてる奴が使ってるだけだろ KENTA・勝又健太は、YouTube のRuby on Rails 初心者向け有料サロンの主。
月千円で、日本6位の3千人が入っている。
1位は、キングコング西野の数万人
Vue.js 日本ユーザー会も3千人で、1つのRailsサロンと同じ人数
KENTAは、日本にプログラミング教育革命を起こした。
1年ぐらいの勉強で、10年以上のプログラマーよりも上
最も短時間の勉強で、給料を上げる方法を見つけた人。
それが、Rails のバックエンドエンジニアになる事
KENTAの普及により、今じゃ未経験者でも、
Bootstrap, Heroku, Docker, CircleCI が当たり前
今や、AWS Fargate, GitHub Actions, Terraform,
TypeScript, React, Vue.js 出来ないと差別化できない
今の未経験者は、それぐらいハイレベルな領域で戦っている。
10年以上の化石プログラマーは、太刀打ちできない。
使っている道具が違うから
ツルハシで掘っている土方と、巨大なメカで、トンネルを掘っているのとの違い。
それに初めて気付いて、教育革命を起こした いつもKENTAの宣伝しにくる人のレベルを見るとKENTAのレベルの低さが如実にわかる svelteはvueの正当進化系
vue3の中身がsvelteでもおかしくないはずだった じゃあvue君次はsvelteにすり寄ればええやんけ vueって仮想DOM使ってないんだったっけ？
マイナーだからよく知らんが フロントは各自が好きなもの使えばいい
そのためにバックエンドと切り離したんだからね
明日オワコンなってもすぐに乗り換えられる安心感 KENTA の天敵・モローは消えた
モダンな自社開発系Ruby on Rails のKENTA vs
旧態依然のJava 土方を集める、SES のモロー
みずほ銀行の2千億円・統合プロジェクトも終わって、Java土方の仕事が無くなった。
それで、みずほ銀行はバグってばかり
可読性も悪いし、巨大すぎて直せない サーバーサイドはPHPが一番分かりやすい
Rubyなんて論外ｗ遅いし見にくいｗ わかりやすい≒使いやすい、ではないと思う。それはそれとしてPHPもすごく進化して昔とは別物らしいな。使ってないから知らんけど。 Rubyは遅いし世界的に廃れているしな
イキってた残りカスがそこら中でケンタと一緒に宣伝してるがそもそも言語として論外 いつものRubyガイジがやたらとKENTAに言及してるのなんでだろう？と思ってたんだが
そのKENTAとやらがRubyを推してるっていう理由だけなのか
この板についてはRubyもKENTAもNGWordに突っ込んでおけば万事解決だな フック船長はなんでもありな感じ
Reactの純粋さにとって都合が悪いものをまとめて隠蔽するヤバい奴 当方、svelteでwebアプリのフロントエンドを学んでいるが
javascriptの型無し && スレッド意識せず && 引数の参照渡し && エラーマネジメント皆無
で、すぐ迷宮になりそう。
こんな言語仕様でよくチームで組めますね…怖い TSにすること
入力を常に信用しないこと(型が付いてても)
出力も信用しすぎないこと
OSSライブラリは間違っている前提でラップする事
関数を盲信せず普通にオブジェクト指向すること
typeフィールドで望まないダックタイピングを抑制すること
これがフロントエンド開発のコツやね >>133
大丈夫、JavaScript怖くないよ！
> javascriptの型無し
TypeScriptとバリデーションで解消
> スレッド意識せず
WebWorker使わなきゃスレッド関係ない。非同期の話なら他の言語でも使われてるから慣れた方がいいかと。
> 引数の参照渡し
なんか問題ある？
> エラーマネジメント皆無
TypeScript使ってれば殆どの実行時エラーは潰せるので、あとはサーバとの通信時くらいになる。そのへんはPromiseなのでcacheメソッドで処理する（RustのResultみたいに） ReactとMaterialUIを昨日から始めたんだけど
既に挫折しそう…
https://i.imgur.com/x7ii8B0.png
ボタンの色を変えたいだけなんだけど
色んなページを見ながらやっていて
これで色は変わったんですが
ボタンを押したら指定した色ではなく
白色にボタンが変化してしまいます
なんか設定が間違ってるんでしょうか？ ちなみにvariant="contained"を消した場合
ボタンを押したらボタンが消滅します
リロードすればまた緑色のボタンとして復活します 結構色んなサイトを見て
やり方とかimportする内容が違ったりするんですが
色々なパターン試してみた結果
色を変える事が出来るんですが
やっぱりボタンを押すと色がトンチンカンな色になります
sxプロパティで赤色に変えた時は
クリック後に青色になります
もう意味が分からない… これ消えてるわけじゃないのか
materialUIってもしかして背景が黒の場合が
全く想定されていないUIなのか… 個人的な意見だけど見た目をカスタマイズしたい要件があるときはサードパーティコンポーネントは使わずにゼロから作る方が楽だと思う
便利な機能を持ったサードパーティコンポーネントが使えなくなるのは残念だ
だけど見た目の変更の仕方がわからなくなって何時間もハマるのはもっといやだ
サードパーティコンポーネントでやると決めたら拘りは捨ててコンポーネントを並べるだけで最後まで突っ走る
この見た目の定義がコンポーネントに隠蔽されてるのでカスタマイズしにくい問題をreactの達人はどうやって解決してるんだろう？ >>141
ほんとそうかもしれない…
普通のやり方でやれば5分で終わる作業なのに
何時間もかけるのはアホらしい… Reactの達人では無いけど、
俺はわりとプレーンなコンポーネントを使うし、デザイン面は愚直に書けるTailwindCSSだより。
複雑なコンポーネントはデザイン用のインターフェイスだいたいある気がする 下に記述してるstyleの宣言を上のSenderより上で宣言しないといけないんじゃないの？ >>141
特にB2Bな案件だと自前で作るしかないねえ
ライブラリの罠に嵌まりたくもないし
メンテされなくなった時のリスクもでかい いきなりreactとUIライブラリの学習はキッツイだろ
reactに慣れてきてからUIライブラリ使いなよ ちょっとmaterial UIは諦めます
reactを覚えるだけでも大作業だわ…
親から子コンポーネントに
関数を渡すのに1時間30分かけて進展がない…
もう全部捨ててjQueryでやろうかしら…
Action Script、C/C++、Swift、SwiftUI、
processing、openFrameworks、
AVR(c)、とやってきたけど
初歩的なところでこんなつまづいたの初めてかもしれん…
やってられん…
Facebookが作るものはやっぱりFacebookクオリティか… >>147
マテリアルUIは使ったこと無いから知らないけど、親から子に関数渡す超初歩的なことならドキュメントに書いてあると思うよ Reduxほんとに使うこと無くなったね
もう2度と関わりたくないよ ゆうてまあここはReactについて答えられないやつばっかだしな
口だけなのよみんな React使えば凄いもの作れるかといったらそうでもないし
そもそもそんな凄いインターフェースなんか求められていない
インターフェースなんかHTMLとCSSで作ればいいんだよね
HTMLとCSSは随分と高機能になったから
そこにちょっとjQueryで動きをつければ十分なことが多い
イラストレータやCADソフトみたいなものはReactみたいなものが
便利だと思うけど、普通の管理画面インターフェースとかだとjQueryで十分 >>136
ボタンを押したら白くなる……がちょっと意味わからんけど
&:hover {
}
を用意すればいいって話だったりするのかな >>153
上の方見ると詳しい人もいるし、単に余計な捨て台詞吐くから反感買ったんだと思う。
>>154
jQuery使うくらいならバニラの方が楽だな。 jQueryはバニラと混ぜて使えます。
バニラよりも簡単にかけるところだけ
jQueryを使えばいいのでバニラが簡単というのは
理論的にありえません。 >>155
> &:hover {
> }
>
> を用意すればいいって話だったりするのかな
ありそうな話だな。CSSが苦手なくせに
CSSを勉強しないから、無駄なJavScriptコードを書く人が多い
そういうやつに限ってCSSをけなして
使えない自分を擁護している フロントエンジニアなのにcss設計ができないならReact使う意味ない >>162
わかる。fetch待ってあっちの状態を拾いつつこっちに同期して副作用見ながらElement差し替えて……とか考えずにサクッと組めてほんと楽 漏れは、CSS は分からない。
Ruby on Rails で、SASS・Bootstrap しか知らない
>>136
Railsでは、React, Bootstrap, Bulma, Tailwind が多い
Material-UI, ElementUI は、あまり聞かない 最近のシングルページアプリケーション大嫌いだから早く廃れてほしいわ いちユーザとしての嗜好をここに書かれてもなぁ。
SPAなんて15年位前からあるわけだし、スレタイのライブラリやフレームワークはSPA以外も作れるし。 SPAがいいというか最初のロードで終わるから便利なのであって
今時ページ毎に読み込みとかダサいでしょｗ ページごとに読み込んでくれた方がリセットされる安心感がある
あと遷移前のページとは基本的に切り離して考えて操作すればいいのねということがよくわかるからマルチページのほうが良いと思う
マルチページのほうがハイパーリンクやRPAとの相性もいい
これはあくまでユーザー目線になった時にどっち使いたいか？って考えたときにそう思うってだけね
開発者の目線だとSPAの方がアーキテクチャが綺麗に階層化されててメンテしやすく実装が簡単なのでいいと思う >>168
ダサいとかいうお前の主観で判断するなや >>169
マルチページだと、それそれが担当する範囲が分離されていて
複数の人が並行で開発しやすくなる
大規模システムに向いてる ユーザー目線になった時SPAは「マルチページであるかのように見せる」
ということを徹底しなければいけない
本末転倒ｗ >>170
草生やしてるけど安心感ってめちゃくちゃ重要だと思うんだが？
特にエンドユーザーはITのことなんてよく知らんから安心感が何より大事
「あっ、これはよくある普通の素朴なホームページだ、これなら簡単に使えそうだ。ホッとするね」って思ってもらえたら勝ちよ
逆に「な、なんだこれは。ブラウザなのにまるで業務用のデスクトップツールみたいに複雑だぞ。ひえ～、動かし方が想像できない。う～ん、こりゃ困ったぞ」って思われたら負け spaを何だと思ってるんだ？
twitterが複雑で使いづらいとか聞いたことないが ひょっとしてSPAだとルーティング出来ないと思ってるのでは？ >>175
一例だけで全体を押し測るのはどうかと思う
>>176
従来のページ遷移に見せかけてるだけであって別の概念
やっぱり全てリセットほどの安心感はないね >>177
俺はまだおじいちゃんじゃないけど、世の中おじいちゃんおばあちゃん、おじさんおばさんがどんどん増えてるんだから、彼らに最適化したシステムを作るべきなんだよな >>174
それは見た目(デザイン)の問題であって
シングル/マルチとは関係なさそう >>178
概念が違っても見かけが同じなら気づかなくね？
例えば、ユーザーはTwitterのタイムラインとツイート単独画面を別のページだと思ってるでしょ >>180
デザインの違いじゃなくてあの遷移するときのいったんリセットしてロードし直してる感が良いんだよ
あれがあるとすごく安心するんだ >>181
Chrome、EDGE、時々Safari使ってる >>182
気付いてはいるだろう
あれリロードされないぞって それ、ただの遅いサイトでは……。
じゃあロード画面でも表示しますか 現代の大半の人間はYouTubeやTwitterとかLINEやTikTokとかのアプリを長い時間使ってるし、それらのアプリはSPAの動きするから現代の人間にとってはSPAの方が慣れていると思うぞ
ゆえにページ移動の度に画面が一瞬真っ白になるのって「なんやこれ？」ってなる >>186
ロード画面はいいかもね
あとは上から徐々にレンダリングされていくあの感覚
あそこまで再現できれば安心感を演出できるかも >>187
ないない
そんなのごく一部の例外だって
世の中のほとんどはまだSPAになってないし今後もならないだろう
ユーザーはよく使うマルチページのほうが親しみがある あとね
SPAに慣れるってことは基本的にないんだ
SPAで作った特定のアプリに慣れることはある
だけどそれに慣れたとしても別のアプリには慣れない
だってSPAのアプリは個性的でそれぞれ違う動きをするから
これとは対照的にマルチページアプリはどれもウェブの作法を守ってるので異なるアプリでも共通点が多い
なのでマルチページアプリに慣れるってのは大いにあり得る 慣れるも慣れないも時代によって使われる技術は変わるだろ
頭カッチコチの老人かよ >>189
スマホ持ってないの？
お年寄り用とか子ども用のスマホなら持ってる？
それならYouTubeとかTwitter使えないかもしれないけども
言うてもネイティブアプリってSPAになってるやつしか見たことないな >>192
変わるものもあれば変わらないものもある
HTML、HTTPはず～～～っと昔からあってあまり変わってない
SPAの方が異端なんだよ明らかに >>195
HTMLもHTTPも時代に合わせて変わってるけど？
変わってないのはお前の頭だけな >>196
流石にモバイルはとっくにスマホだよ
三輪車と自動車ぐらい差がつく物なら流石に自動車を選ぶ
それは当然の選択だろう
でもSPAとマルチページアプリってそこまで差がないと思うなー
普通の自転車とロードバイクぐらいの差かなー？
つうか差がないどころか使い勝手はマルチページアプリの方が良いとすら思ってるよ
自転車の例えで言うと「あのー速いのはわかったんですけど、ロードバイクのハンドル持ちにくいんでね。普通のハンドルにしてくれませんか？」みたいな感じ >>175
> twitterが複雑で使いづらいとか聞いたことないが
え？スクロールした後、進むとか戻るで
スクロール位置がリセットされて使いづらいって聞いたこと無いの？ >>197
いや開発者の立場だったらreactおじさんだよw
ユーザー目線の使いやすさはともかく開発するだけならSPA途轍もなく簡単だからね
開発者なら楽な方を選ぶのが正解だ Googleの検索なら、ページがあるから
10件単位ぐらいで位置を覚えてくれるから便利 不便でもそれに慣れてしまうと、不便だって気づかない良い例だな >>198
①アナリティクスとかアドセンス使ってればユーザーがアクセスしているデバイスが分かるけど、多くのWebサイトやWebアプリはスマホユーザーがめっちゃ多い
②スマホユーザーってのはYouTubeとかTwitterとかのLINEとかのネイティブアプリを長い時間かけて使っていると考えられる
③ネイティブアプリってのはほぼSPAな動きをするから、ネイティブアプリを長い時間使ってるユーザー＝SPAの挙動に慣れてる、と推測できる
よってWebサイトにせよWebアプリせよSPAの方が、スマホユーザーにとっては体験がいいんじゃないの、ってことよ
ただ、②のスマホユーザーが「ネイティブアプリ触ってる時間は1日の内わずかです、割合で言うとWebサイトを閲覧してる時間の方が多いです」ってなったら上の理論は成り立たないよ >>206
SPAに慣れちゃったらそうなるのかなー？ >>207
さっきも言ったけどSPAに慣れるってことはないんだよ
共通の作法がないからアプリごとに固有の見た目と動きがある
なのでネイティブのアプリに慣れたとしてもそれでSPAに慣れたということにはならない
SPAの個々のアプリについてそれぞれ練習が必要で習熟には時間がかかる >>207
続き
君が言ってることはつまりこういうこと
「YouTubeやLINEのネイティブのアプリに慣れたらVSCodeにも慣れたことになるよね」
そうはならんやろ？ SPAでMPAの動作を苦労して作る
なら最初からMPAを使えば？ >>211
苦労したくないからSPAで作る
ユーザーには御免なさいだけど使いにくいものを使ってもらう
仕事だからね
信念とは違うこともやらんといかんのよ 頭が固かったり、自分だけの意見を曲げられなくなってて意固地になったり、
長文だったり、連投したり、例えをしだしたり、
典型的な前時代のおっさんじゃんw
ずっとブラウザリロードしてろよw SPA大嫌いジジイを見てると、日本が何で発展しないかよく分かるわ
既存のやり方に固執して、変化する世界には目を背けて「今までこれでうまくやってきたからいいんだよ！」と開き直る
日本の中枢にいるやつらってこんなんばっかりだもんな なんか最近やたらNuxtからNextに移行しましたみたいな人増えたけど、これただreact使いたいだけだよねえ >>214
日本は世界でも有数の先進国だが？
国内にいると世界が見えないとよく言うがまさにそれだね
良いものは良いものとして長く使う
本当に良いものは取り入れて改良する
日本は今も昔もそうやって世界をリードしてきたんだよ
SPAだと開発が簡単なところは評価している
なのでうちもSPAを開発に取り入れている
発展はしているのだ
それがユーザーの利便性に繋がるかはまた別の話
全てはコスト・パフォーマンス >>213
MPAはリンクをクリックした時にページが自動的にロードされる
わざわざブラウザをリロードなんかしない
そんなことも知らないのか？ >>220
ん？ID:qAyrcykqと同じ人？
MPAがどうだなんて絡んだつもりないぞw
IEでjqueryおじがブラウザリロードしてそうだからw 4〜5年前からSPA前提の案件しかやならくなったけどなー
てかMPAで済むような案件安くて割りに合わなくない？
Nuxt使って開発中の機能プレビュー出来るようにしたら
客が気に入っちゃって毎回Nuxt指定で発注くるわw 単価は分からんけどちょっとそこはなんとも言えない気もする
大規模ECのPC版サイトはいわゆるMPAが多い気もしていてそこが安いとも思えない
あと古い業務システム（の保守とか）はまだ多くて、人こないから高くなってそう
後者の会社の人にSPAバリバリのページ見せると目が輝くw導入はまた別の話だけどもw またこいつ暴れてるのかよ
まあ好きにしろ
それでジョーカーを防げるなら安いものだ >>225
Reactがしっくりくるならreactでいいんじゃない
初学者が独学でフロントエンド学ぶってならユーザーフレンドリー強調してドキュメントとかに力入れてるvueでいいと思うけど 表題のフレームワーク・ライブラリは全部ドキュメント充実してると思う。良い時代だ >>224
レガシーに縛られてるしかなりの石頭な上に自分から動くことももうできないみたいだから、化石とか？ angularでプログレスバーの進捗率を操作してやってる良いサンプルコード無いですかね？ ReduxやRecoilはコンポーネントの凝集度を上げ、疎結合とすることに意味があるのに
すぐバケツリレーの是非の話に置き換えて議論してるのを見かける
本質はそこじゃないだろって毎回思う
バケツリレーが辛いとか辛くないとかどうでもいいんよ コンポートがreduxやらrecoilといったインフラストラクチャに依存してたら嫌だな
疎結合を謳うならコンポートは純粋にして全ての副作用をpropsで渡すのが正解 Hooksが当たり前になってから状態管理ライブラリそのものが必要なくなってきたけどね パフォーマンスに取り組もうとするとuseCallback地獄になってコードの見通しが最悪
依存性指定は間違えやすいのに間違えるとデバッグしにくいバグになって現れる
困ったものだ 普通のカスタムフックに見えるけど
うちのにもuseが大量に転がってるぞ
カスタムフックだらけだ >>240
関数が関数を帰す事をやってない人からみたら
目新しく見えるだけ >>241
いや、高階関数には親しんでるけど、カスタムhookには詳しくなくてね。
勉強になりました。ありがとう ロジックと外観が密結合していてなんかもやもやするがこれが正解なのか？ >>243
笑
フック入門としては分かりやすくて良いけど renderは分けたほうがいいよ
const useChecks = (labels: string[]) => {
const [checkList, setCheckList] = useState(labels.map(x=>false));
const handleCheck = useCallback((index: number) => {
setCheckList((checks) => checks.map((c, i) => (i === index ? !c : c))) }, []);
return {
labels, checkList, onCheck: handleCheck,
isAllChecked: checkList.every(x=>x) }
const App = () => {
const checks = useChecks(["a", "b", "c"]);
return <div>
<Checks {...checks} />
<button disabled={!checks.isAllChecked}>next</button>
</div>
} >>244
理解できるかどうかでなく良し悪しの問題な
フックは元々コンポートから状態・副作用を抽出するためのものなのにrender hookパターンじゃあ取り除けてないどころかさらに強固に結び付いてるじゃないか？
俺が書いたごく普通のフックなら完全に見た目と振る舞いが分離してるので再利用性が抜群に高く、デフォルトの動作を提供するのも簡単だろ >>245
どちらかというと俺もそんな感じに書くな
選択肢や選択状態というデータと
チェックボックスという見栄えは
分離させておきたいかもってことで >>136
useStyleってv5ではあんま使わなくなった印象 >>136
お前そもそもBootstrapすら使った事ないだろ >>235
useContex使うよりはrecoil使う方が楽だと思うけどなあ SuspenseってFlatListでどうやって使えばいいんだ？ Flatlistに組み込まれないと無理なんじゃねーかな >>253
やっぱそうか
Microsoftが.netにasync awaitを導入した時みたいにライブラリ側も一気に対応してくれんと困るよね
そのあとサードパーティのライブラリも対応時間かかりそうだし
しばらくは混乱が続くのかなー ReactからSvelteに移行する人は元からReactでやる必要のない事をReactでやってた人だろうな
自称Reactヘビーユーザーとか言ってたのとかまさにそれ reactは場面場面で最適な書き方がガラッと違ってて統一感なくなるのがしっくりこない
非同期読み取り専用ならSuspense
入力系なら別の書き方、FlatListなら読み取りだけでもまた別の書き方、複合的な画面はカオス、みたいな それは何使っても一緒では？
さまざまなライブラリを組み合わせる都合上仕方ないことかと Reactのコードって
ゴミゴミしいんだよなーー
可読性に難がある Reactはデータ構造がスッキリするから全体としては見通しが良くなる 大規模サービスを構築するならReactの方が良いけど
ちょっとした画面表示くらいならVueのほうが書きやすいんよね結局
だから日本企業に合ってるのはVueなんよ svelteのREPL SZVg viewBox animationのHTML部
{#each Array(4) as row, row}
がある。
javascriptでは解釈されるのに、typescriptではrow,rowの重複が問題になると警告が出る。
この回避方法って分かります？ >>262
ちょっとした画面だと思ってたものが壮大な画面になるのは日本企業あるある
yahooのトップページをみろ
いまだにあの古臭いデザインだぞ 担当のお客さま複雑だと使ってもらえないって自分で言っときながら要件はめちゃくちゃ複雑なの出してくるんで呆れた
reactだと簡単に実装できちゃうから要件のんでそのまま作るけどMVCでシンプルな設計にした方がエンドユーザーは喜んだだろうな ReactだろうがMVCだろうがエンドユーザーにはシンプルに使えるようにするのがお前の仕事だろ そりゃ無理だね
複雑に使いにくく作るのがユーザー要件だから そこでサードライブラリを入れないで使えるAngularですよ
誰がやってもフレームワークの書き方 何も考えたくないならangularだね
Googleで使われてるし少なくとも数年後に捨てることはまずないし
捨てたとしても移行ツールは用意されるはず >>263
このスレは、荒らしが立てたスレです。
まともな人は、移動してください！
>>9-10
を参照 そのスレお前すら使ってないじゃん
先にお前が移動しろよ このスレになってから明らかに内容が良くなったし、あっち行く理由がない >>233
使い回さないページ固有のコンポーネントにContainerやカスタムフックで分離して注入する
あと、propsですべてを渡すのは変更や修正に弱い
影響範囲なんて狭いに越したことはないだろ？
>>237
だから結局は小規模でもRedux(RTK)やRecoil使って上位で疎結合にしたら良い
下位は使い回すこと前提だから純粋な状態を保つようにする 上位に副作用を集約して下位に流し込んでくだけ
特に変更に弱かった事例にもあたったことないな
これが変更に弱かったらreact以外の関数型も全部変更に弱いってことになる 簡易で軽いサイトほど低機能や低レベルなライブラリ、プラグイン等で事足りてるってことは普通じゃないか WebはMVCでいいじゃん
VSCodeのような複雑なブラウザアプリケーションを作るときだけSPAを使えばいい
SPAを使うこと自体が目的になってちゃダメだ ちょっと複雑なフォーム作ることになった時点でもうReact使った方が楽 すまんが当社ではうちのフレームワークで作ってもらう規則なんだわ
物ができればいいってだけの10画面程度の小規模じゃないんだし好きにやってもらっちゃ困るよ >>283
うちのって言ってるあたり独自で不便で何なら遅いやつなんだろうな…… なんかesbuild使うのがこれからの常識になるのかな
まだプラグイン周りが充実してないから
足りない部分自作しなきゃいけないのが辛い このご時世にjQueryで金になる仕事なんてほとんど無いでしょ エコシステム変わりすぎ多すぎ問題ははやく解決してほしいんだが
JS系のコミュニティって俺が俺がって感じで協調性ないから永遠に無理なんだろうな かと言って某言語みたく15年位ずっと同じフレームワークが第一線なのもそれはそれでちょっと…… 15年使われなくてメンテされてないのと
15年使われて磨かれてるのは全く別なのだがまあいいや それはそうだな。そういうニュアンスではなかったんだけど、すまんかった。 これ使っときゃテッパンっしょってのも楽っちゃ楽だよね
springとかmojoliciousとかlaravelとか
phpは必ずしもそうではないかもだが エンジニアリングをエンターテイメントとして捉えてるかどうかの違いかな
陽キャエンジニアにとってはそれを使って自分達がエキサイトできるかどうかが最も大事なこと モチベーションは開発における無視できない大きな要素って意味なら同意 >>291
それを楽しめないと無理
最近だとまたviteというwebpackを置き換えるものが現れた
しかも作者はevan you
まさかのwebpackがオワコンになる可能性が 日本でReact使ったまともなWebシステムがゼロなんだよなあ
海外はたくさんあるが 大きなシステムになるともう共通部品とかは他で作ったものがあるからそれ使うべきってなるし、
大きなシステムは外からの個人事業主とかの派遣さんにも来てもらうことになるけど
個人とかのいわゆる派遣さんに求められるのは皆と同じものを作ることであるという事実からReactなんか求めないからなぁ >>299
好きだよね。海外はー、海外はーっていうのｗ Reactのコンポーネントって並べるだけなら楽なんだけどデザイン変更したり動作をカスタマイズしようとすると途端に難しくなる
オブジェクト指向でプライベート変数にアクセスしたくなったときに似てる 逆じゃね？
並べるのは手間だけどカスタマイズや連携は楽 >>301
比較が海外しかないじゃん
好きとかの問題じゃない
>>300
他ってなんだ
オレオレフレームワーク？
>>302
日本のプログラマーはアホしかいないから難しいらしいよな
俺には難しい理由がわからん >>304
他っていうのは他の業務でだよ
何百画面もあるようなデカい仕事受けるような会社だけじゃなく
しょっぱいシステム屋とかでもたぶん流用がデフォやで
例えば文字を数値に変えて変えれないなら0を返すToIntegerとか
そういう共通関数群が大量にあるからそれ使ってもらうってのはそれなりの大きさの業務では基本やで >>305
そんな共通ユーティリティみたいなことは言ってない
フレームワークレベルでコレ使えってなってるのか？
デカい仕事ってバックエンドがゴミ部屋のようにめちゃくちゃな管理してフロントはショボいっていう仕事だよな >>304
海外ってどこですかー？
北朝鮮も海外ですが？
具体的なことを知らんから
海外ってひとくくりにする >>306
例えば得意先コード入力したら得意先名が右のラベルに表示されるようなものとか
ReactやVueで作ってあってもどうせフロントの人らは仕様書みて部品はっつけて終わりやで >>309
ルックアップコンポーネントみたいな奴だな
で、このスレと何の関係があるんだ？ ん？日本でReact使ったまともなWebシステムがゼロなんだよなあ
からの流れだよ
結局のところ全体のフレームワークとしてバックエンドにまで絡めて既存の資産を捨てるほど大きなプロジェクトでReact使うことでの価値は無いってだけで
小規模のホームページとかそういうのならぜんぜん使ってもいいんじゃないっていう話だよ まぁクソデカSSRシステムに組み込めとか言われたらそうなるかもしれん。でも今後は変わるんじゃね？ いやほんとまともにReactとかで規模の大きめのシステム作れるやつがまったくいない
日本のプログラマーがゴミクソばかりで世界一のIT後進国だからな webじゃないがSikiっていう専ブラはreactだったはず ここの連中集めればReact技能者は集まりそうだけど技術選定と設計ですげー揉めそうw 好きなフレームワークで1人1ページ担当してがっちゃんこしよーぜ！ じゃあおれバックエンドをVBScriptでやるわ
おまえらフロントすきにしていいぞ >>317
ごちゃごちゃと障がい者みたいにつぶやいてないで
一回自分でやれ じゃぼく「それjQueryで良くない？」って言う係 技術選定だとReact、Nextjsを選んだ以上にCSSどうするかはかなり悩んだな。
結局CSS Modulesが最良と判断したが。 個人的にはUtility Firstなやつが楽かな
クラス名考えるの面倒だし React/Next.js系がデファクトスタンダードだよな wasmでdomが扱えるようになったらrustで書けるフロントエンドが流行るはず
たぶんrustで書けるreactがそのまま出てくるから結局react覇権になりそうだが
rustはtypescriptの利便性保ちつつより堅牢で高速だから欠点無い マイナスが0になったら
流行るはずって思ってるやつ多いよな
LinuxでWindowsアプリが動いたら
流行るはずとかさ rust版reactとjs版reactの機能が同等になったら
新規プロジェクトでみんなrust版を選ぶようになるはずから
そうなったときがjs/tsの将来性が無くなる瞬間かもしれない
reactがrust版を出すんだったらvueとかsvelteもrust版出すはずで
結局今とフロントエンドライブラリの選定は変わらないのかな rustの方が冗長なんだから、
そんなことにはならないって言ってるんだがｗ wasmからjsをバインディングしてdom操作すんの？
馬鹿じゃね？ Rustは素晴らしく洗練された言語だけど、それはそれとしてフロントを書きたいかと言われると、パフォーマンス上の問題が出ない限りそうは思わない。ライフタイムとhookを並行して思考したりしてると著しく生産性落ちそう >>326
もうあるよ
dioxusのweb版
まんまreact
これはパラダイムシフトは確実な気がする
フロントエンドは面白くなるぞー >>333
これか
https://dioxuslabs.com/reference/web/
なんだこれは？
rustでフロントエンドしちゃってるよ
ヤバタニエン過ぎる
もしもだがdenoランタイムでこれができるようになったらマジでやべーぞ >>334
別に（JSの立場は）ヤバくはないと思うけど、確かに面白いなこれ よく分からんけどフロントをRustで書くメリットってなんかあるの？ >>336
今の所はなさそう
ただ数年後となるとわからない Rustってjsとかphpとかより低級言語よね
したらもうコード書けませんってエンジニア溢れそうだね >>335
denoランタイムとの接続がキーポイントになると思う
denoから使えればtsと相互変換が可能になり
さらにdenoのv8 bindingを使って様々なメタプログラミングが可能になる
とんでもないことになるぞ なんでウェブでわざわざゲーム作ろうとするの？
作っても別にいいけど、
rustとかでゲーム以外作るわけ無いだろ wasmには期待してるけど
wasmが完成した時に覇権を握るのがrustかどうかは別の話 ちょっとした部分をrustで書くのはよくても本格的なやつはrustで書きたくないな
rust難しすぎる >>341
設計としてReactに寄せてるし、C♯ランタイムまで入るBlazorとは明確に違うでしょ。
>>343
ゲーム要素ゼロじゃん。
Reactの3倍位の容量にはなるみたいだし、JSの立場を脅かす事は無いだろうけど、選択肢が増えるのは歓迎かな。
Rustたしかに難しいけど、TSで型パズルするのと難易度的には同じくらいに感じる。 >>345
俺も最初そう思ってたけどオライリーのプログラミングrust第2版読んだらそんなに難しくなかったよ
これまで日本人作者の書いた本読んでいまいち理解できなかったけど
単に説明が下手すぎただけだったよう rust難しいって言ってる人って単にCSを理解してないだけな気がする
rustの仕様ってゼロコスト抽象化なのだからCSを理解してない状態で使えるわけないんだよね 難しいかどうかと使いたいかどうかはまた別問題じゃないかな rustはlodashのようなライブラリはあるのかな？ rustは実行時型情報はあるのか？
C++やTypeScriptみたいにコンパイル時と違う形のデータが入ってくるようなら使い物にならんが？ 静的かつ強い型付けなので実行時にはないしキャストもない
ていうかwasmはRustではないしRustがブラウザで実行される訳でもないので開発環境はTypeScriptでも他の言語でも全然構わない TypeScriptで型が化けるのはバリーションできてない時だけ。
Rustで型が化けるのは余程変なコード書いた時だけ。 Rustは未履修だが意図的に破壊しなければ型エラーが出ないと言う話だったら間違いなく今後はRustに置き換えが進むだろうね
Blazorがその地位に来るかと思ったがRustにしてやられたか
いやいやまだわからんか
速度と安全性を重視するときはRust
実行時型情報による高い安全性と開発コスパを重視するときはBlazor
老害懐古厨はJsTsって感じで棲み分けが進むかもしれん Blazorおじさんまだ生きてたのか……。老害って言われて悔しかったんだね。強く生きてね。 老害？それはJsTs厨のほうだろ
何十年前のポンコツ仕様でいつまで使い続けてるんだって話
JsTsはクソ仕様のオンパレードだから排除できるなら速やかにそうすべき Rust勉強して良かったなと思うことの一つは、Promiseのcatchメソッドの有用性に気づけた事。fetchのResponseのjsonメソッドがPromiseなのもすげえ腑に落ちた。 rustできないと落ちこぼれる時代
フロントエンドも大変なことになってきたな
死ぬ気で勉強しないとな SNSフォローしてるハイレベルなフロントエンジニアもrustはオプションでなく必須になりつつあるって考えて学習始めてたな
まあそれも結構前の出来事だけど
乗り遅れんようにせんとあかんね
JsTsにしがみついてたらこの先どうなることやら コンポーネントは再利用性やテスタビリティにこだわらん方が実務レベルだと上手く行くようだ
純粋関数は理想ではあるがバケツリレーで脳のスタックを食い潰すのでよくないな
ライブラリ化する時が来たらじっくり考えよう rust使うメリットを薄っすら考えてたけどやはりあった
rust使えばフロントとバックエンドで真のisomorphicができるんだよな
このメリットはあまりにもでかいよ
サーバーサイドのエンジニアからしたらむしろrustがいいし フロントエンドの重たい処理をRustをWasmにして代替するってのはいいけどReactみたいなのを代替するとは思えない 言語とライブラリは分けて考えたほうがいいのでは？
既存の言語は大きく仕様が変わることがないので言語同士の優位性が逆転することは滅多にない
しかしライブラリは急に現れて優位性を塗り替えていく可能性がある
RustにReact.js以上のライブラリが現れる可能性は十分にあるが(ALT)JavaScriptがRustに勝つ可能性はゼロに近い
将来を見据えればどちらに学習リソースを支払うべきかは自明だと考えるが如何かな >>367
この人そう言うの分かんないんだよ
wasmがjsを代替するものだと勘違いしてるっぽい
wasmでのdom操作は遅いっての普通に考えたら理解できるはずなんだけど 普通に考えたらDOM操作も今後高速化するとわかりそうなものだが…？
なぜwasmでのDOM操作が将来にわたってずっと遅いままだと確信してるのか逆に聞きたいぐらいだ C#おじさんにRustが使いこなせるとは到底思えん "ポンコツ"の大部分はDOM APIやブラウザAPIに由来するものであってwasmだから逃げれるものじゃない
他言語での使い勝手を良くしようとすると結局ランタイムデカくなってパフォーマンスに影響するし 一般ピーポーはjsでさえヒーヒー言ってんのにrustなんてキモオタ以外できるわけないだろ wasmでdom操作が高速になればreactをwasmで実行するようになるだけじゃない
そうなればJS/TSで書いてwasmに書き出すだけでしょ
馬鹿じゃないのかなこの人 >>373
DOMもブラウザAPIもクソなのはそうだが、それ以上にJS言語もクソ
なので、言語だけでも別の選択肢が生まれるのは素晴らしいこと
主要な言語のランタイムは同梱、キャッシュ、トリミング、対策の余地は十分にある
>>376
速度問題が解決したら、欠陥だらけのJSを積極的に使う理由がない
TSはJSよりマシってだけだから、これも使う理由なくなる
既存のライブラリはその通り、WASMをハブにして全ての言語から使えるようになる
JSの方が優位になるシチュエーションがあったとしても、そこだけJSで実装して別言語からインポートするって形になる なんだ、RubyやろうがこんどはRustにいったのか？w 自分はRust使えないのにRust叩き棒にして自分が使えないフロント技術スレで妄想垂れ流して暴れるおじいさん。可愛そうな人 意見をぶつけあうのは結構なことだが人格攻撃をしたらその場で最底辺に落ちるので自分からはしないように心がけてる >>377
速度問題が解決したrust
vs
最初から速度問題がないjs
rust使う意味ねーだろｗ とは言え屁理屈捏ね続ける人をまともに相手するのは面倒くさすぎる。
無視が一番だな！ >>384
速度が同じか負けてるなら他に優位性ないJSを使う理由がない
JSは"仕方なく使うもの" 反論ができず人格攻撃も封じられたら確かに無視するしか選択肢がないのかも >>386
JavaScriptはウェブ技術に適した言語 自分が仕方なく使ってる、いや使えないのかｗからって
他の人も仕方なく使ってるって思い込むのは何なんだろうねｗ
rustなら、rustならって言ってるだけなんだよ >>389
それはブラウザベンダーが他言語を排除し続けてきた結果
それを撤廃したらどうなるかは容易に想像がつくだろう
JavaScriptでLinux実装できるか？
アップデートしていこうぜ！ >>390
たしかにその通りだな
好きで使ってる人も中には居るだろう ウェブ屋がそれ言っちゃ終わりでしょ
今以上に混沌とした戦国時代に戻るだけ rustに置き換えるよりも
JavaScriptを改良したほうが早いんだよなぁ フロントエンドエンジニア達の"焦り"は感じるね
rustもしくはGo書けるのがイケてるフロントエンドエンジニアの条件みたいになってるし
最近もvercelの人がtscをGoに移植したというブログ書いてた
もはやtsとreact書けるだけでイケてる扱いされる時代は終わったし
hooksの登場でコモディティ化が進んでその辺の素人でもreact書けるようになってしまった
そりゃ焦るよ dioxusも別にJSや既存Webを置き換えようってものじゃないしねぇ > rustもしくはGo書けるのがイケてるフロントエンドエンジニアの条件みたいになってるし
この間までCoffeeScriptだったぞ
そうイケてるというのは
イケてる雰囲気しかないのさね 一方でもう一つのイケてる条件のフロントエンドdevopsだけど
こっちはこっちでk8sやdocker、ネットワークや分散処理のデザインパターンの知識などさらに幅広いインフラ力が求められる
もちろんフロントの人がこの領域をできるわけもない >>397
それ流行ったの5年以上前でしょ
下回りのツールに高速性が求められた結果rustとGoが必要になったのよ
フロントエンドdevopsという領域よ
時代は進化する すげー間違ってるじゃん。フロントdevツールの快適さの為のGoやRustであってフロントそのものの為じゃないんですけども jQueryとかRustとか忙しないおじさんだな
そもそもここSPAスレだぞ spaフレームワークに挫折したじじいが恨みつらみを垂れるスレだから Rustに興味はあるが本腰入れるとしたら、
まずCとかC++のシェア食いだして、それらに匹敵する位になってからかなぁ。 Rustのspaフレームワークスレたててやってろ
せめてスレタイのフレームワークと同じくらいのシェアになったらまた来ればいいよw ここまで書いといて本人がrustを触っても無いのがお笑いポイント しかも、話の発端のdioxusはReactの影響受けまくったライブラリで、Web屋がRust方面にも進みやすくなったって要素もあるのに、ソース読めないから（読んでないから）それに気づかないという 皆がrustを使用してweb開発をするなんて世界は来るとは思えんけど・・・
wasmが主流になったとしたらrustよりもassemblyscriptが流行る気がする その辺は例えばwasmのGCが実装されるか頓挫するかでも大きく変わってくる
今からrust覇権とか.net覇権とか言われても将来の夢語ってるのと同じレベル あんな奴のせいでRustのイメージが悪くなるのが辛い いつまでもJavaScriptにしがみついて知識をアップデートするの拒んでちゃ仕事なくなるかもしれん
土日はrust勉強しよっと >>411
すげーな
プロトタイプの段階で10倍～25倍も高速でメモリ消費もガクッと減るんだ
これはもう既に勝負見えたんじゃない？
チャリンコでレースしてるところにモーターカーが参戦するようなものだよね？ いうほどwasmの方が速度出るシーンはない
JavaScriptだと速度が出ない場所を書き換えるだけ せめてシェア取ってからRustがどうの言ってくれ
スレタイ関係ないやろ、勝手にスレ立てて自分で普及して 「社長！rust使えます！」
「rustってなに？それより早くリリースしろ」
「」 ・wasmの高速化が進み適用範囲を問わずJavaScriptと同等かそれ以上になる☜時間の問題
・wasmを前提とした他言語のビルド最適化が進む☜時間の問題
・wasmを前提とした他言語のライブラリ、フレームワークの開発が進む☜時間の問題
rustは有力な候補だがrustになるかどうかはわからん
でも他の言語が台頭してくるのはもう避けようがない未来に思えるが？
いつまでもJavaScriptとReactの天下が続くと思ってる連中はちょっと楽観視しすぎじゃないですかねー？
正常性バイアスかかってないかじっくり考えてみるといいんじゃないかな 絵空事語ってないで実際に案件が増えてきてから書き込めよ 議論したいならコテハン付けてくれ。ID変わり過ぎなんよ そうですね時間の問題ですね
なので時間になってからまた来てどうぞ rsxっていうJSXみたいにかけるマクロがあるのか
こりゃ凄い
しかもJSXみたいなトランスパイルせずにマクロでやってる
オシャレだ マクロもトランスパイルみたいなもんだけどな。いや、JSXがマクロと言うべきか rustのマクロはASTインジェクションだから型の支援も得られるからだいぶ安全だよ ASTインジェクションはBabelにもあるし、JSXも型情報扱えるよ rustを倒して追っておいで
フロントエンドエンジニアとして生きるなら
JSの手はいらん
必要なのはwasmのみ！ >>433
ワッチョイスレは既にあるから再利用かな
【ﾜｯﾁｮｲ有】Vue vs React vs Angular Part.5.5
https://mevius.5ch.net/test/read.cgi/tech/1596110361/ 意味あるぞ。
お前〇〇だろ！荒らすな！が
お前○○だな！荒らすな！に変わる
荒らしている相手を文面を読まなくても、ある程度的中させられる 今のフロントエンド界隈は
react vs vueから、typescript vs rustの対立軸に変わってきたな
こういう賑わいは久しぶりじゃないか 企業からすればwasm化すれば解析されづらくなるし
逆コンパイルすることを利用規約で禁止できるようになるのかな
だから企業は全部wasm化するのが当たり前になりそうじゃない？ wasmはバイナリだけど分類はプログラミング言語だぞ
さらに言えばwasmdecのようなc言語に変換するツールもあるしそんな簡単にはいかない rust難しいという人に向けてrustのコツを教えるよ
社内の勉強会のネタなんだけどね
まずrustではほとんどのデータがスタック領域におかれる
スタック領域は関数を呼び出した時に確保される
ローカル変数の値もこのスタック領域に確保される
変数の代入はこのスタック領域の変数の場所へ値を書き込むことでデータのやり取りをすることになる
関数から戻る時スタック領域のデータは全て消え失せる
ローカル変数の領域も解放されるからGCが必要ない
まずこの理解が大前提
この動きは変数をクロージャなどでキャプチャしてしまえば永遠に生きるJSとは真逆なのだ
スタック領域のデータは何があっても関数が終わると消滅する
まずこの前提が違うことを意識しよう(続く) 難所として上げられる所有権だがこれはプリミティブ型だとスタック上のローカル変数の領域に値がコピーされるだけ
これはJSと同じ
プリミティブ型以外のデータ(StringやVecなど)は代入元の変数が使えなくなるだけ
これが所有権の正体
なんのことはないデータ自体は何も移動してないのよ
データはただスタック領域に佇んでいる
そういう絵を思い浮かべることが大事
rustではデータは常に1人ぼっちなのだ
これをムーブセマンティクスと呼ぶがデータは何も移動していない
この名前をつけたやつ(C++の人たち)は反省しろ(続く) >>447
とりあえず初心者はヒープとか使わなくていいと思うね
リファレンスだけ覚えりゃOK
ヒープが登場するとRcだとかRefCellの概念が出てきて
絶対に挫折するから
それよりもまず基本的なrustの機能を勉強すべき
基本的にヒープは使わずにやる、というのがrustの設計思想としても正しいと思う
とりあえずヒープは忘れる Rust厨うぜぇな。スレチにいい加減に気付け。
ここはJavascriptのフレームワークの長所・短所を話し合うスレだ。 wasmはフレームワークを動かすための基盤になると考えれば話題の範疇だろう
純粋にフレームワークの話をしたいならそもそもJavaScriptの話題も禁止にすべきだ
でも実際はそうなってない
ならwasmの話題も可とすべきでは？ 気持ちはわかるけどtsの型パズルの馬鹿馬鹿しさにそろそろ人類が気がつくころなんじゃないかと思ってる
そんなことに時間を使うくらいならrustで書いた方が遥かにストレスフリー
ちなみにtsはあくまでjsを余すことなく型付けできるようにしているからあのような型システムになっているわけで
理想的なものではないのよ
そういう意味ではassemblyscriptのほうが遥かに筋が良い ただassemblyscriptはあまりにもプリミティブなんだよな
これならrustで書いた方がよくね？という感じでしょう
だから流行らない
まあこれはwasmがローレイヤー過ぎるのも原因
wasmがもう少し発展してコンパイラインフラストラクチャー的なツール群が増えれば状況は変わるのだろうけどね
どちらにしてもここ数年目まぐるしく流行は変わると思うからフロントエンドは面白いよ ん？Javascriptを動かすフレームワークのスレというのなら
ASP.netMVCのフレームワーク語っていいのか？ さてここまでのまとめ
rustの変数はスタック領域に確保される
スタック領域は関数が呼び出されたタイミングで確保され
関数から戻るときに開放される
ローカル変数はスタック領域に確保される
つまりローカル変数は関数から戻るときに全て開放される
（GCがいらない理由）
ヒープ領域とは関数に関係なく確保されるメモリ領域のこと
データをヒープに確保することもできるが初心者には不必要なので
スタック領域のみ使うように意識する
CS勉強したことがある人は当たり前過ぎてなにを今更？と思うかもしれないが
この辺はちゃんとした大学のCS学科でないと習わないし
コンピュータアーキテクチャの教科書に全部載ってるけど
いまどきこの分野を独学する人も少なくなってきた（続く） あんたStringもVecも使わないでRust書くわけ？ 所有権とは変数に代入したときの代入元の変数が無効になるということ
これを所有権の移動という
変数が無効になるだけで別にデータ自体は何も変わっていないし
移動もしていないのだがこれをムーブセマンティクスと呼ぶ
ちなみに関数呼び出しのときに変数を渡すとその変数の所有権が移動する
これがなぜかわからない人が多いが
関数呼び出しは呼び元の関数のローカル変数を呼び出された関数の
ローカル変数の領域にコピーするという処理が走る(これをCSでは値渡しと呼ぶ）
アーキテクチャによって渡し方は様々だが概念的には変数のコピー処理を行うのだ
このコピーが代入なので所有権が移動する
なので呼び出し元の変数が使えなくなる（続く） >>456
君のその発言を見る限り理解していないようだ
VecそのものとVecが保持しているデータを区別して考えよう
Vecそのものはスタックに確保され
Vecが保持しているデータはヒープに確保される なぜお前はそんなにスタックやらヒープやら所有権にこだわるのか？という人がいると思うが
この概念をきちんと理解していないと絶対にrustを書けるようにはならないから というかさ、Rustなんかじゃなく、
Cという全ての言語の長の正統後継者であるC#こそが正しいといえるんじゃないか
Rustみたいなサンピンのことは知らんけど、
どうせポインタすら使えない程度の言語なんしょ 30分調べればわかるような表面的な知識と曖昧なCS知識がキメラ合体したような酷い感想文だな どうやらVecやStringがヒープに確保されると思っている人がいるようだ
確かにそう思いがちなのは理解できる
C/C++を書いたことがないとこの理解は難しいのだが
先取りになるが簡単に説明しておく
Vecの実態はstruct Vec<T>という構造体なのだ
https://doc.rust-lang.org/std/vec/struct.Vec.html#guarantees
Vec<T>はptr、len、capacityから構成される
ptrの先に実際のデータがallocateされこれはまさしくヒープに確保される
しかしptr、len、capacityはスタックに確保されるのだ
ptrのデータはrust側がよしなにやってくれるのでユーザーが気にする必要はない
理解できただろうか？
この構造体という入れモノとその中身を区別するという概念は非常に重要なのだ ちなみにGoも同じようなものだが、スタックで確保された構造体の参照を
関数から返すと自動的にその領域をヒープに確保してくれるという機能がある
これがとんでもなく便利なのだ
GoがJSチックに書ける理由はこれ
VercelがなぜtscをrustではなくGoで移植したかなんとなく理解できたのではないか C++のmoveコンストラクタがデフォルトみたいな感じなんだ？
安全かつ高効率なわけだね >>465
rustのソース見たわけじゃないがほぼその理解でいいと思う
構造体のガワだけがコピーされて中身のデータはコピーしない
その代わり代入元の変数を使えなくすることで安全性を担保する
理想的なC++というべきか 本スレで構ってもらえないからってここに来んなよ
ほんま陰キャってゴミだわ 俺の思いはフロントエンドエンジニアたちにrustを理解してもらうこと
そして日本のレベルを上げること
rustの人たちって翻訳のゴタゴタみればわかるけど
人間性に問題ある人が多いし完全に村になってて
勉強会に参加とかしにくいのよ オンライン勉強会のある時代に参加しにくいとかww
Rust界隈でも鼻つまみ者なんですね。わかります。 少なくとも今のrust界隈がフロントエンジニアに歩み寄ることはないし
webにも興味がないだろう
掲示板で俺をいじめたいだけならいじめてもらっても結構だが
日本のレベルを上げることには必死だから Rust界隈やフロント界隈が興味がある人なんているのか？
そもそも"界隈"が興味を持つって日本語としておかしいんだが >>470
とりあえずお前のプレゼン全く面白そうに聞こえないからそこから見つめ直す必要があると思うよ
次世代言語スレ一時期は結構賑わってたんだからそこを再燃させれればいいだけだと思うがな
話題のゾーニングができないのってプログラマとしてどうかと思うしRustのプログラマとしてスレ違いの話題を延々と語るとか所有権システム全く分かってないようなもんじゃね？ それはそうとMaterial UI Ver.4から5に上げたら随分使いやすくなってるね
Styleの付け方もしやすくなったしBootstrapみたいにerror,'info,success,warningのカラー使えるようになったし
わりと嬉しい改善が多い 俺が気に食わないなら透明あぼーんしてくれ
ルーパチしたり小賢しいことはしないから
もしくはrustをこのスレだけNGにしてくれ このスレだけngとか出来ないからコテハンつけてくれ 人間性に問題があるってのは議論を放棄して人格攻撃し始めるとかそう言う手合いのことだと思うな
Rustさんはそんな風じゃないんで大丈夫だと思うよ
2chではその手の輩が多くて毒されそうになるけど自分はそうならないように気を付けよう ここはvue,react,angular,svelteスレでしょ
みんながやめてって言ってんのに延々とrustでスレ荒らししてんだからどう考えても問題性あり カラーは自作で誤魔化せない事ないし標準でオサレなTextFieldあったりDrawer使えたりしたから
デザイン苦手な自分からしたらその辺捨ててでもMaterial UI採用する価値はあったと思ってたよ >>482
そこは解釈の違いじゃないか？
reactの話題から派生してreactライクなフレームワークの話題に繋がることはあるだろう
そこから言語の話題に広がることだってまあたまにはあるさ デザインとかホームページ屋じゃないから正直どうでもいい そこまで言うならやめるよ
正直すまんかった
ただこれだけは言わせてくれ
君らはrustを習得する唯一の機会を逃した
こんな大盤振る舞いは今後一切ないと >>488
俺は勉強始めるよ
SNSの有名なフロント技術者も避けては通れないって言ってたし多分そうなるんだろう >>488
ためになる話だと思います。
もっとRustのことが知りたいです。 >>488
Rustの勉強は他所でやってるからモウマンタイ
TPOを弁えられないヤツはどこへ行っても厄介払いされる >>488
お前みたいな無能に代表者面されてもRusterさんたちもいい迷惑だろ 外野は放っておいて、もっとRustについて教えて欲しいです。 >>488
ジャップランドがソフトウエア後進国なのは伊達じゃないんだぞ イタチの最後っ屁だ
まずリファレンスについて
所有権の概念で変数に代入すると元の変数が使えなくなると言ったが
単に関数内で値を読みたいだけの場合でも所有権が移動したら不便極まりない
そこで使うのがリファレンス
aのリファレンスは&a
変数名に&をつけて渡すとその変数のアドレスを渡す
元の変数の値を読み取る場合はアドレスに対して*をつける
let b = &a; // aのアドレスを渡す
*b; // aを得る
こうすればaの所有権は移動せずともaを参照できる
これがリファレンスだ
型でリファレスを表すときは型の前に&をつける
&StringでString型へのリファレンスとなる
rustのコツとしては基本的には所有権を渡して行くことでプログラミングする
値の参照が必要な部分はリファレンスを取る
これでかなり安全なプログラムが書ける
実際単純なコマンドラインのようなプログラムなら上記の戦略で実装可能でしょう
それでは本当にこれが最後だ
さよオナラ
ブッ！！！ rustスレが揚げ足取りであれててこっちに逃げてきたんやろw
居場所はこっちにもないのにw このおっさんTSスレでも暴れてたゾ。他にすることは無いんですか？ 伸びてると思ったら必ずスレチで伸びるねこのスレ
たまに参考にしてるから荒らすのやめてほしいわ Rustはまだまだ仕様変わるから、趣味でやるのでもなければ触る必要無いよ。 javascriptが更に最適化されPCも早くなるし
別にわざわざwasmみたいな頭の悪そうな仕様にする必要無くね 結局wasmがjsよりも高速で動作するってエビデンスあんまないよね なぜ速いのに普及しないんだろう？と考えるんじゃなくて
なぜ遅いのに普及したんだろう？と考えたほうがいい とりあえずプライムビデオ並のコンテンツ作ってから言えって話なのよな
オーバーエンジニアリングの典型 JSTSの機能が悪くない上に速度も遅くない。
そりゃVBAみたいだったら何が何でも他言語に行きたいけど、欠点は数あれど普通の用途では他に行く方がデメリット多いなと感じる程度には優秀な言語なのよね。
だからWasm使わねばならない用途が極端に効率を要する用途と他言語で動いてるソフトをそのまんま持ってくる用途ぐらいになってる。
それはそれとして他言語の勉強もする。面白いから。 Rails vs JavaScript: Which one should you use for your SaaS?
https://www.youtube.com/watch?v=A1ICndiLCGY
2021/11、外人の13分の動画
Railsが巨大で遅くても、使う理由がある。
JS で8週間掛かったものが、Railsで1週間でできた
他にも、GitLab は、GitHub クローンで時価総額2兆円だけど、
Railsを使い続ける宣言をしているとか、
米国年収では、Node.js は900万円だけど、Railsは1,300万円とか rubyとか初心者言語いつまでも使ってたらみっともないぞ 支障が無いなら好きなもの使えばいいんだよ。みっともないのは、押し売りするやつ Rust使いたくなる気持ちは速度というより、エラー回避の面が大きいな
Elmの将来性がある版と言っても過言では無い ReactとTSのおかげでcatchできない実行時エラーを殆ど見なくなりました reactはエラーは少ないけどその分デバッグが大変
いっそのことエラーになって落ちて情報吐き出してくれた方がマシかもしれない
とくにdeps配列のミスで発生するバグはデバッグしにくい
depsを手動設定にしたのは痛恨の失敗設計だったと思う
こんなのはJSXトランスパイラに組み込んで自動化すべきことだ 情況がわからないけど、そのへんは書いた通りに動いてるだけなんだからエラー要らなくね？ 書いた通りに動くのは当たり前の話であって、
間違って書きにくかったり、間違って書いた時に気付きやすくなってるかどうかが優れた開発者体験に繋がる eslintのexhaustive-deps入れれば大抵なんとかなるよな
それで無限ループするときはuseMemoとかuseRefとか使えば大抵どうにかなる >>523
そこを具体的に書いてほしかったんだ。>>524の意味なら気付きやすいし、あんまり引っかかった事無かったもんだから。 約5年くらい前にReactと Vueで2,3本アプリ作ってもう見たくもねえってなったんだけど別物くらいに便利になった？
何が嫌って入れ子になったコンポーネントに値渡すのに中間のコンポーネントにも値持たせてバケツリレーで渡さなあかんのが気持ち悪すぎてマジで無理だった わかる
めんどくさいよな
で末端に状態や副作用を持たせると純粋とは？みたいな別の気持ち悪さが割り込んでくる Reactとかみるとプログラミングって欠陥発明だよなって思うわ 気持ち悪いのは最初だけ、そのうち依存関係がスッキリ見通せて気持ちいぃ♡ってなってくるのさ 今のところ解決方法は存在しない
いや今のところというのはおかしくて論理的に考えて解決方法はおそらく存在しないのだろうな
脳筋バケツリレーか関数の純粋さを捨てて状態や副作用に頼るしかない
純粋関数型プログラミングなんてのは夢物語だったわけだな
銀の弾丸はないいつだってそうだったこれからもそうなる UIなんてのは放っておけば副作用とデータのやり取りがぐちゃぐちゃになるものなので、特に意識しなくても素直に書けば引数バケツリレー程度に収まるReactはやっぱり楽だよ。
100の複雑さが0になればそりゃバンザイだけど、20に減るだけでも相当にありがたい Rustおじさんって呼び方は止めてくれ。Rustのイメージダウン過ぎる……。
つかあのおじさん、Rustスレでも自演しまくってるなぁ Reactみたいな気持ち悪いものをよく生み出したよな
なかなか思いつかない
尊敬するわ 状態管理ライブラリ揃ってるのになんでバケツリレーを選ぶんだよ… reactって本当に流行っているのか疑問な気がする
みんなが分かってるならいいけど、日本だとそういうのよっぽど恵まれた会社だけという気がする
そういう意味では日本のエンジニアってトータルで見るとレベルが相当低いんだなと思う
何でコイツが開発やってるの？みたいなの結構いるしフリーランスにもいるからなぁｗ Reactはうちでもやったけど、結局使わなくなったよ
たぶん他の企業でも結構一回使ってみてあーこれ別にいらんわってなったとこ多いはず ロートルおじさん具体的なこと言わずに煽るだけだからすぐわかる。しかも短気だし。 Rustおじだけどこんな中身のないスレなら俺のrust演説再開してもいい？
前までは不快な書き方しちゃって反省してる
今回はちゃんと書き溜めようかと思ってる だから何でここでやるんだよ
他所の砂場を荒らす前に関連スレを盛り上げろよ ここでやっていいわけ無いだろ。自分の言ったことぐらい守れ >>542
副作用が気持ち悪い
純粋関数で書けるって聞いてワクワクして始めたreactなのにこれじゃあねぇ？ >>547
個人的には面白いからいいけど
ここはreactのスレだから完全なスレ違はよくないみたいだね
だからreactと比較した場合は…といったふうにreactの話題を織り交ぜればいいと思うな Reactで数千人が使う業務システム開発したが業務システムにはかなりいいぞ
Reactじゃないとここまでの規模と複雑なシステムは作れなかった よりによってなんでこのスレが狙われたんだろな
気持ち悪い 逆にweb業務システムでのフロントエンドって、スレタイ以外で何使うん
素のjs、html、jquery以外もうほとんどなくね？
wasmとかはマイナーな部類になるやろ SSRを含めてよければ色々あるだろうけど、多分そういう意味じゃ無いよね Rustネタは>>461の次世代スレでやれよ
そっちもとりあえず巡回はしてるからさ 自演おじさんをあぶり出すべく次スレはワッチョイ必須ですね それで結局のところ課題>>534に対する解決策って存在しないの？
ここまでのところ人格攻撃レスしか返ってきてないんだけど レス周辺に書いてあるのに見えないのか。いや、理解が足りないからわからんのか >>564
どれ？
副作用を持ち込んでバケツリレーを解消するといった類のレスは幾つかあるが>>534はバケツリレーも副作用も気持ち悪いって主張だからそれでは全く解決策にはなってないぞ？ >>565
そういう意味なら、状態を完全に消せる銀の弾丸は無いよ。そこは反論する必要がないから反論がないだけでしょ。 >>566
え？では「レス周辺に書いてある」ってどういうことなの？ >>568
バケツリレーの件でしょ。揚げ足取りおじさん。 なんで核心に触れないようにしてんの？w
結局よく知らんのでしょ？ >>569
つまり俺のレス読めてないのに見当違いなレス返した挙句に人格攻撃までした奴がこのスレに居るってことなの？ 女の娘が一人で始めた食べチョクは、Ruby on Rails, React。
コロナで、漁業農産物などの取引量が30倍になったらしい
YouTube で有名な、雑食系エンジニア・KENTA のサロンでは、
Rails初心者用コースに、Docker, Heroku, CircleCI, Github Actions,
Reactではなく、Vue.js が入っているけど、
米国では、こんなにすごいポートフォリオを誰も作っていないと言ってる。
日本人の初心者は、10年以上のプロよりも上
それでも、Railsの年収は最高峰の1,300万円。
Node.js は900万円
ただし、米国はサラリーマンも全員がフリーランスで、いつでも解雇できる。
一方、日本は解雇できないから、滅多に雇わないので、
事前にすごいポートフォリオを作る必要がある でもKENTAってJavaScriptオフにするだけで突破されるような
セキュリティのセの字も知らんレベルの人間じゃん ケンタって人本当に元GREEなの？
知り合いに聞いてみようかな おじさんは議論じゃなくてレスバトルしてるだけだからなぁ ケンタはバックエンドで日本一の凄腕エンジニアだからな
フロントみたいなゴミは一切やらないと明言している
だからフロントのセキュリティなどケンタのスキルには関係ない 色々勘違いしてるみたいだけど、
ケンタってただの派遣だぞ ケンタは時給2万円以上
いまは会員数が多くて今年年収1億目指すといっていたからおそらく5000万はすでに稼いでいる
いま業界で活躍しているのはほとんどケンタのサロン卒だよ rustスレが完全に壊れたので助けてくれ
やはりここに逃げるしか俺の生きる道はないか >>578
中身のない話してないのに肩書きだけで判断か？ >>586
中身の話はサロンで話している
日本でケンタを超える技術を持っているのはおそらく3名ほどしかいないぞ
そもそも時給3万を超えるようなエンジニアが日本にはほぼ存在しないからな KENTA のサロンは、初心者から時給1万円を目指す人の話。
だからキャリアパスも、Ruby on Rails → Go のみ
米国年収が高いのは、Rails, AWS Solution Architect の1,300万円
Rust, Elixir も、普及のキャズムを越えなかった。
バックエンド言語で唯一越えたのが、Rails, Go だけ。
他のフレームワークは、シェアが少ない
KENTAが終わらせた言語が、PHP, Scala。
KENTAがオワコン認定したから、新規プロジェクトが無くなった 今や大企業もケンタの動画を参考にIT投資を決めるようになってきているからな
すごい影響力だぞ おいおいKENTAキッズがおじさんからIDコロコロをラーニングしちまったぞ エンジニアに数学力が必要かってトピックでなんか言ってるけど
そうじゃないだろ感 KENTAの動画みたことあるけど、
ほっぺに汚いシミのある作文読んでるだけおじさんって印象しかないわ ケンタが常々言ってるのはフロントみたいなどうでもいいことにエンジニア人生を掛けるなと言うこと
フロントはWebデザイナーと何も変わらない
エンジニアの中で最も底辺で能力がない奴がやることで金にはならない
時給1万を超えるにはバックエンドでRubyをやるべき
ケンタのサロンに入れば駆け出しエンジニアでも3ヶ月で60万はすぐに行くし80万へも最短の道で習得できる じゃあバックエンドでrubyやればいいじゃん
スレタイとなんの関係も無いよね 無駄にクソ複雑と言われたり、クソ簡単と言われたりする、いまいち実態を把握されてない感のあるフロントエンドの世界。
理解する気のない外野がグダグダ言ってるだけなのかな。ピンキリ激しいのは事実だと思うけど。 フロントエンドの皆さんはjavascriptのクラス設計はどうしてるの？
typescriptが2012年、ECMAScript6が2015年なので比較的新しい技術のはず。
このスレで「状態管理」という言葉が出てきて、あれ？と疑問が沸いたので… SPAだと状態管理というかある程度全体的に使えるデータが使えたらいいなと思うけど
結局画面ごとにAPI呼んでデータ取ってくるしそこまで巨大なアプリじゃなければ
状態管理するほどのデータは無さそうな気がするんだけどね
画面遷移でデータ渡せるし、グローバル的な管理って何か時代と逆行してるというか
トークンみたいなのぐらいしか使ってなかったわ >>599
このスレで状態管理と出てきたらほぼReactHookの事でクラスは関係無いと思って良いかと。
クラスについては、そこそこ便利なオブジェクトリテラルが有るからあんまり使い道がない。状態を持つオブジェクトを（何回も）生成する時と、組み込み型を継承して拡張するときくらいじゃなかろか。 複雑なデータを表現する時はやっぱクラス便利よ
reactには直接関係ないけど たかがJavascriptごときがクラス扱うとか
正直なまいきだよな Reactの関数コンポーネントはどこで値を保持してるの？
グローバル変数？ >>601
私はjavascriptのオブジェクトリテラルは、任意の関数で弄れてしまうので構造体に過ぎないと感じるが…
連想配列でswtich文を代替できたので、構造体と等価ではないけど。
いつ、何が状態を変化させたのか追跡するのが面倒なので、規定のインターフェース(プロパティ・メソッド)で内部変数を操作し
内部変数の状態に応じて処理を変えたい時にインスタンス内で問い合わる…これがクラスの使い方の王道と解釈している。
交換する変数の型を明記したインターフェースを事前に規定するので、確実に状態が管理される。
クラス設計=状態管理 じゃないかな、と。 >>607
> 任意の関数で弄れてしまうので構造体に過ぎない
その理屈で言うと、クラスで作ったオブジェクトもほぼ構造体です。 >>605
コンポーネント内のプロパティに覚えてる >>607
コンテキストによって状態管理が表すものって変わるでしょ
あなたが言ってるのはクラスでの状態管理だしこのスレで言ってるのはアプリ内での状態管理
全く別の話 >>607
このスレでOOPなんて語っても、誰もOOPなんてやってないから意味ないと思うぞ >>608
それは違う。
内部変数へアクセスする文字ラベルがインターフェースにリスト化・共有化されるので、
どのインスタンスがいつ内部変数を操作したのか追跡できる。
構造体はインターフェースを持たない。
>>610
別になる理由が分からない。
状態管理とは、どのレジスタにどんな数値が格納されているかを追跡できるかどうかじゃないの？
それはインスタンスの連携で構成されるアプリなので、不変だと思うが…
コンテキストの意味が不明瞭なので、状態も不明瞭なんじゃないかなと感じてます。 >>613
内部変数というのはプロパティの事？
（C等の）構造体は実装やメモリ的にはpaddingで表現できるとしても、コード的には文字ラベルがあなたの言うところのインターフェースだと思うけど。
何れにせよクラスで生成したオブジェクトも、オブジェクトリテラルで生成したオブジェクトも、JSにおいてはほぼ等価です。
あるいは、ひょっとしてプライベート変数の話です？ Rustおじさんは全部主観で決めてかかってくるから分かりやすい >>618
なるほど…よく読まんとわからんね
しかしよく理解できるな Reactのソースコード読まなくてもPreactなら簡単に実装されてるから簡単に読める ほう
そもそもリアクティブってどうやって実現してるんだか アクティブっていうぐらいだから
ActiveXを使ってるんだろ 最近web系やってみようとフロントは何にしようかと思ってたけどいっぱいあるし
もうさくっといけそうなvueでいいや
フレームワーク的なところは使わんし 何かイベント起こるとrenderに食わせた関数が呼ばれ仮想DOMツリーを作る、古い仮想DOMツリーとの差分のDOMを更新する。一つの変更が仮想DOM更新中に全部に波及してリアクティブな操作になる（ちょうてきとうな説明） >>626
なるほど
しかし仮想DOMツリーって複雑で膨大なのに速度的に問題なさそうですごいな
どこか階層の一部だけ更新されるとjsオブジェクトとしては全体を更新してるのかねえ
どうやって階層の一部だけ更新してるのかさっぱりわからんわ >>617
render時に対象のVNodeに保存されてるComponentオブジェクトを取り出し、useStateが呼び出された時はそのComponentのプロパティであるhooksという配列に値を設定される
配列なんだから呼び出された順番でインクリメントされる
これがHooks >>627
仮想DOMツリーが巨大かどうかは組み方に寄るし、（仮想DOM操作のような）実DOMに触れないJSで完結する処理はかなり高速。遅い処理はuseMemoとか使おう。 kami.map((a, i) => (
<Kaminoke {...a} onNukege={() => handleNukege(i)} />
)
コンポーネントの再計算のたびにラムダが生成されてDOMの更新がかかってる？
回避方法がわからない 単体要素向けに作ったフックを配列向けに組み直すテクニックはありますか？
const foo = useSuperComplexFooManager()
↓
const foos = []
for (let i = 0; i < n; i++) foos.push(useSuperComplexFooManager()) // opps!!
useSuperComplexFooManagerは前任者が作ったものですがあまりにも難しくメンテナンスできません
この中身には手を入れずそのまま再利用して配列向けにしたいです 俺だったら難しいこと考えずフックをコンポーネントでラップしループの中でコンポーネントを生成する それだと親から各hookのメンバにアクセスしたい時に困りますね const foos = [1...n].map(i => useSuperComplexFooManager())
でいけんじゃね？
useRefでこんなコード書いてるけど >>638
hooksは関数のトップレベルでないと正常な実行が保証されない https://reactjs.org/docs/hooks-rules.html
Don’t call Hooks inside loops, conditions, or nested functions.
ってことかと 正直俺のレベルだとこんなくらいしか思いつかない
コンポーネント作ってpropsにタイムスタンプ用意して
変更されたらメソッド呼び出しみたいな……
type Props = {
timestamp: number;
}
const TempComponent: React.FC<Props> = (props) => {
const foo = useSuperComplexFooManager();
const { timestamp } = props;
useEffect(() => {
if (timestamp === 0) return;
foo.hoge();
}, [foo, timestamp]);
return null;
}
export default TempComponent; React.createRefならループ中に使ってもok?
だとしたらforwardRefでどうにかいけるかも
const TempComponent = forwardRef((props, ref) => {
const { hoge } = useSuperComplexFooManager();
useImperativeHandle(ref, () => ({
hoge,
}));
return null;
}); サンガツ
なるほどuseRefを使うとサブコンポーネント内部状態を参照できるのか
こりゃ便利だ 親子の参照はtree構造では良く使うのにいちいちrefを経由しないと使えないのめんどくさいね
この辺りは他のフレームワークでよくある継承でコンポーネントを拡張する&親子の参照はただのインスタンス参照って方式のほうが直感的でわかりやすいかな 普通だと親が子のデータを管理するからここまで手間は増えないよ
親のuseStateとContextで賄える 普通ならそうなんだけどフックのトップレベル制約の都合で状態やプレゼンテーションロジックを子コンポーネントに預けないといけなくて辛いねという話の流れではなくて？ ロジックもレンダリングもサーバーサイドで完結できないかなって思った
ブラウザは機能不足、WebViewは遅い、なのでネイティブがいい
でもネイティブの酷い開発者体験はどうにかして回避したい、というワガママ フロントエンド改修するのにReactかVue3で迷ってる
世の流れ的にいくならReactにしない理由はないと思うんだけどなんか好きになれんのよな
Vueはテンプレートの構文がわかりやすくて好きなんだけど、結局typescriptとの親和性の観点でtsxで書く流れになってきてるから、tsx使うならReactでよくねとも思う
Reactだと依存配列書き忘れとかも以外とやりがちで、Vueはcomputedがその辺全部いい感じにやってくれるから自分的な差はそこくらいかなあ
なんかここで選べみたいなのあります？ XML文字列をパースしてReactNodeを生成したい
EVALで出来ないかな vueはとっかかりはホント楽だよなあ
でも流れとしてはReactのがよさげっての悩みどころ Reactは状態管理のライブラリが～みたいなややこしそうな話題が飛び交い、触ってみると実際ややこしく感じるけど、最初が混乱すること多いだけであとはわりとぬるい。
ペットボトルみたく入り口だけキツイ。という個人の感想です。 reactは選択の幅が広いからそれを楽と捉えるか苦と捉えるかの違いだろな
使ってみて合わなければ他の選択肢が沢山あるってのはやっぱ魅力よ reactは従来のコーディング習慣と違いすぎるのが嫌い
JSXリテラルはキモいけどまあシンタックスシュガーと考えればギリギリ許容範囲
しかしフックはIF分やループ中で使っちゃダメってのが非常識すぎて耐えられない >>658
気持ちはわかる
確かにハマりどころは多い Svelteこそ易しいと思うんだけど、そうでもないんです？ 情報が少ないとか？ なんだかんだでMVVMの方が好きだな
UIの振る舞いを記述するならオブジェクト指向の方がメンタルモデルとも一致するし実装上の変な罠も少ないから簡単でメンテナンス性も高い
レンダリングは確かに関数の方が簡単だけどね 俺は関数畑なのでReactがしっくり来たけど、そのへんは人に寄るよね >>663
どのmvvmの事？
angular？
knockout？ アトミックデザインってSPAに合わなくない？
カタログは綺麗になるだろうけどディレクトリがごちゃごちゃになる
普通に機能目的別にコンポーネント分けた方がスッキリする >>662
情報が少ないってのはかなりネックだね
それだけでもゼロベースから導入するのにそこそこ高い能力が必要になるからな タスクランナーとか周辺ライブラリ選定して、設定とか全部書いてた頃に比べたらだいぶ良くなった 多様性とか要らねえんだわ
tscを集中的に強化して他のエコシステムをはやく駆逐してよ >>667
>>671
なるほどね～。まだまだこれからって感じか Vueでspaログイン認証作ってるんだけどjwtの知見って必須なの？ フロントでログイン認証とかそんな恐ろしいことできねえわ jwtなんかべつにいらんよ
ログインなんか普通になんもせずにPOSTしてるのがほとんどだよ JWT使うなら有効期限短くしてちゃんと使い捨ててくれよ！
データ抜かれても良いならまぁわりと雑でも良いと思うけど、パスワードとか個人情報みたいなデリケートなもの出てきたらさじ投げてAuthサービスとか信用できるライブラリ使うなぁ。生兵法危ないし。 reactの野良OSS、品質どうにかならんもんかねぇ
公式がもう少ししっかり整備してくれんとダメだな つうかね
野良の分際でreact-*だとかreact-native-*って名前はダメでしょ
企業か個人の制作ですってわかるようなワード入れようよ
ウェッブの連中は何もかもが無責任で適当すぎて頭にくるぜ 名前なんかつけたもんがちだからな
名前で管理すること自体が間違い OSSなんだから信用出来るものを選定したりちゃんと機能するように環境を整えるのも技術者の腕の見せどころ。
それにRustだろうがGoだろうがPythonだろうがJavaだろうがライブラリやフレームワークの命名規則なんてけっこうガバガバだゾ それが当たり前と考えてる時点でもうダメなんだろうな
エコシステムが洗練されなくなる
多くの開発者が興味とは全く異なる部分で苦しむことになる >>651
React は海外に多い。JSX も便利
一方、Vue.js は、下のスレに書いたように、
YouTube で有名な、雑食系エンジニア・KENTA のRuby on Rails サロンで、
初心者の転職用に、React よりも、Vue.js を勧めている
日本では、Vue.js の方が、転職に有利
スレ立てるまでもない質問はここで 159匹目
https://mevius.5ch.net/test/read.cgi/tech/1644673480/73 >>685
ケンタそれは悪手だぞ
いまからReactに変えろ >>682
名前が早い者勝ちになる問題は解決策がないんよな そこでangularですよ
何も考えなくて良かろう >>673
これ言葉足りずだった。
railsとvueでspa作成しててそのログイン認証と状態保持にjwtをcookieに保管する方法してるんだけど、この形ってspa開発ではスタンダード？ なんでjwtを採用してるのかをちゃんと説明できるならいいんじゃない >>689
angularってもうGoogleの社員しか使ってるの見たことねえ angularの良い点を教えてくれよ
なんかもう終わったものとして扱われてるけど オリジナルの開発者が逃げた時に
もう終わってたでしょ >>696
良く言えば破壊的変更が少なく安定してる
学習曲線が、、と言われるがちゃんと調べれば最適解がありほぼ悩まない安心感
ただもちろん世間じゃreact優勢だし無理に薦めない Better angularを目指したのがvue
だったはずなんだけどだけどなんでこうなった reactはJSの動作をそのまま使ってるのがすごい reactはシンプルなんですよ
jsそのまんまって感じ 全然シンプルじゃない
hookの制約とか非常識すぎる >>689
Angularはいざ使おうとなったらマスターでも居ない限り調べる事やら覚える事が大杉だろ
その点Reactがjavascriptさえわかればなんとでもなる >>702
自分もあんま好きじゃないhookですけど
覚えること少ないし
機能自体はシンプルなんで
Vueより習得早いと思いますね
自分もあんま好きじゃないですけど
それとhookはガチで使わなくても
appの直下ぐらいで
viewの定義体を全部プロパティ経由で流しこめば
行けるんじゃないでしょうかね？
嫌いなひとは >>703
早いんですよねreactは習得が
未経験でもTodoぐらいの機能だと
初日でできちゃいますね みんなバリデータは何使ってる？
Ajvはクライアントで使うにはややファットだ >>704
それやると今度はバケツリレーきついんだよね
気持ち悪いhookを使うかバケツリレーで疲弊するかどっちか ほらね簡単でしょ？って言ってる製品ってチュートリアルにそって手を動かしてるだけの場合も多いんで、あんましあてにならん
そこそこの規模の業務レベルのシステムを組んで初めてツラミが見えてくる >>707
で、次にuseContextを導入して
調整すればいい感じになりませんか？ MVVMは良かった
ごく普通のオブジェクト指向を知ってれば誰でもVMが書けた
あとはViewとバインドするだけ
ソースコードに無粋なXMLもスタイルも登場しない
ソースコードには振る舞いだけを書けばいいのだ
素晴らしい疎結合の世界
これなら研修を終えただけの新卒でもできる
オブジェクト指向は人間のメンタルモデルにフィットするこれが大事なことだ
ただViewを実装したフレームワークが残念だった
Microsoftはこの点について猛省しなければならない
reactは新卒には無理だ
関数型なんて初心者には理解できない
高階関数？美味しいんですか？
ループのなかで使ってはいけない？なんでですか？
ぼくが欲しいのはStateの配列であって配列のStateじゃないんですよ
memo？callback？いったいなんでこんなものを書かないといけないんです？
依存配列のせいでコードがめちゃくちゃ見にくいです
コールバックを修正したら間違いなく依存配列も直さないとダメだって？めんどくさすぎませんかね >>710
それは気持ちの悪いhookを深い階層のコンポーネントに導入することに他ならない
コンポーネントの純粋さは失われて気持ち悪いこんになる ライブラリが目先のシンプルさに囚われると逆に複雑な構築を強いられる事はままあるけど、その点、Reactは上手い構成だと思って使ってる。
合わないなら使わなければいいし、仕事なら慣れるしかない。
って、この人例のおじさんっぽいな reactおじさん達は私にreactを売り込む時に純粋関数でUIがチョー簡単に書ける夢のような世界だと言いました
それがどうです？
現場のプログラマは副作用だらけのコンポーネントに疲弊してるじゃないですか？
そして副作用から逃げたら悪夢のような階層のバケツリレーですよ
コンテキスト？それは副作用だろ！
現実の世界は関数じゃないんですよオブジェクトなんです
そこをよくご理解いただきたい 関数型パラダイムとかReactについて行けない人が居るのはわかるし仕方のないことだと思うけど、こんなとこで愚痴られてもなぁ 理解力のないメンバーに認識させるには
どうすれば良いでしょうか？
一番確実なのは
コードを対比させて見比べさせる事でしょうかね？ そういうとこだよ
「ついていけない」という表現が自然と出てくるってことは内心では無意識に難しくて使いにくいフレームワークだって思ってんだろうな この人の指してるmvvmって
angularとかのイケてるのじゃ無い方のですからね >>690
面倒くさがりな香具師のために、
誰かがRuby on Rails 用の各種プロジェクト generator を作っている
Boring Generators
https://github.com/abhaynikam/boring_generators
ログインは皆、Devise を使う。
Omniauth で、Facebook, GitHub, Google, Twitter など あれもダメこれもダメなら自分で作れよ
ワガママな乞食だな 批判内容がふわっとしてるというか上の方で見た意見そのままなので、おじさんはReactエアプっぽい >>707
バケツリレーはコールバック地獄と似た様な構造で全世界的に問題になってるだろうしその内それに関するasync/awaitみたいな解決策は出てくるだろうね JSに暗黙的引数渡しみたいな機能があれば良いのだけどね JSフレームワーク初心者だけど、vueが格段に分かりやすかった
というかvueが昔のhtmlファイルの構成を想像しやすいんだよな
Reactは単純なファイル構成にならない、というかページじゃなくシステムを作ってる感覚 流石に違うんちゃう？
こういう疑心暗鬼、嫌だなぁ。次スレはワッチョイあったほうが良いよマジで >>731
それはコントロール分割の程度の話で
reactもvueも変わらんのじゃないの？ まあそりゃ元々がjQueryやってた感覚からするとvueが分かりやすくとっつきやすいって言い分は分かる
ただそれは使えてるってだけで使いこなしてる段階ではないと思う vueは3になってグダグダになった
今はReact一択 海外で圧倒的な差がある以上それに逆らうと損するだけ。
どんどん優位性が広がるだけだから、どこかで折れる事になる。
なら早いほうが良い。 でもコンポーネントライブラリVueのほうが良さげなの多いんだよね 野良ライブラリが多すぎる
公式はろくに仕事せず無報酬の素人任せ
最終コミットが平気で数年前とかある
責任感なんてあったもんじゃない 海外の比較してるところだとvueがこれから流行るって予想してる人も多いんだよな Vueは周りのライブラリの動向みて良さげなところ取り入れて安定させたものリリースするスタイルだからね
成熟してきた今Vueの安定性は魅力的 >>739
お金払わずにお客様目線とは、開発者の風上にも置けないな 最終コミットが数年前で不安ならフォークして自分でデバッグして引き継げや >>742
金払うからオールインワンの高品質なフレームワーク作って欲しいわ
野良ライブラリを駆逐してほしい
>>741
へー、ブーはそういう方針なんだ？
だったらウサギと亀のレースじゃないけど、最終的にブーのほうが優れたフレームワークになりそうだね React以外ゴミって結論出てるのに今更vueで荒らすのは無理がある vueが躍起になってあたらしいものを模索せんで今あるものを洗練させていくならそれが正解だよ Vue2→3で破壊的変更多かったから
規模の大きいライブラリは移行に手間取ってるんだよ
時間が解決するだろうけど今現在はVueを選びにくいな そもそもおじさんって開発業務した事ないよね
知識が無さすぎる 反論ができなくなると人格攻撃し始めるの人ってウェブ系ではよくあるタイプなのかな？ おじさんはIDコロコロと屁理屈と論点ずらしでレスバトルしてるだけで、議論にならないし…… >>753
したことはあると思うよ
でも派遣切りにあったか使えないからクビになったとかでしょ
もしくは鬱になってやめたとか
上っつらの評論家的なことはできるからそのタイプだと思う 人を煽るのに自分が煽られたら被害者面という人間を受け入れるコミュニティは無い 普通に議論してんのに反論がなくなると人格攻撃する人達のコミュニティとかちょっとした地獄だよね
2ちゃんとはそういうものなのかもしれんがもう少し穏やかになれないものだろうか おじさんがやってるのはレスバトルであって議論とは言わない 反論ができなくなると悔しくて議論と認めたくない気持ちはわかるけどもね IDコロコロしたり無駄に挑発ばかりするから議論扱いされないのにねぇ 中身に反論ができないから関係ない外面の気に入らない点をつこうとする気持ちわかるよ ラスおじはともかく技術ないやつほどreactマンセーしてるのはなんでなの？
To do アプリでも作って、自分はvueよりもreact合ってる！とかほざく奴多いんだけど、どうせ使いこなせないんだから素直にvue使っとけ 外面ってのはこの文脈ではipが変わるとか議論の本質と全く関係ない部分のことね >>771
ipがどうのこうのと議論と関係ないことを書いてる人達が無視してること npmでreact、vue、nextjs、nuxtjsのダウンロード数を見るとvueやる気にならんが、
気にしない人も多いんかな。 スレと関係ない事延々と語るおじさんに問題があるとしか思えないけど >>773
全く気にしないことはないが指標の１つ程度だね
普通はそうだろう
>>774
俺もちゃんと議論してくれる相手ならそうしたいんだけどね
議論から外れて盤外のレスバ仕掛けてくる人達が湧いてくるんで対処してるだけ
彼らが静かになればこちらも無駄なレスしなくて済むんで助かるんだが… Blazor最高！って
あちこちのスレ嵐してた奴の事？ 仕事で開発してるよ
仕事でもなければ開発なんて絶対にやりたくない Blazor最高は間違いなく無いけど、
金だせる企業ならASP.netMVC最高はあるな >>773
へ～と思って見てみたら驚いた。今5倍も違うのか。 結局後方互換切るのは悪手なんだな
angularもそれで斜陽になったし
vueは巻き返せるだろうかね プライベートでは絶対開発したくないと言う人が、わざわざプライベートな時間を割いて嫌いな技術のスレに来る？
やはり目的は議論じゃないよね…… Reactが最強とか言語のシェアでイキってるのはなんなんw
シェアが全くの0じゃないならVueでもAngularでも仕事上捨てきれなくね？
それともReactの開発者とか関係者なん？
Reactないと詰むの？w 大事なのはシェアよりも公式による主要ライブラリのカバー率、公式の抱える熱意だと思うな
シェアが多ければある程度は熱意に反映されるかもしれんが人間の感情はそれだけじゃないだろう JSXがあるから実質的にDSLと捉えることもできなくはないのかもしれんね メタはオワコンなりそうな気配感じてるけどreactは大丈夫なんかね？ MITライセンスのオープンソースだしそこはあまり問題ないかと
一人の開発者に依存してるVueに比べたら全然 もし仮にmetaが潰れたとしても、みんなReactのイニシアティブは握りたいだろうから開発チームごと何処かが引き取るだろうね。
Oracleみたいな会社が引き取ると悲惨だけど どうせならMicrosoftに引き取ってもらいたい denoがよほど跳ねない限りはnodeも安泰な気がするなぁ wasmが発展すればnodejsにこだわる意味はなくなるのでシェアは縮小する
しかし無理して乗り換える必要性もないので選択肢の１つとしては残り続ける それはユーザー数を指標にして見るとNodeは減らずWasm分が単純に増える感じになりそう。
なおnpmはGitHub傘下だから実質MS Adobe製品インストールすると、ロカールにnode.jsのサーバ立てまくるからな。
便利なんだろうけどちょっと怖いｗ Ruby on Rails 6 では、
webpack で変更ファイルをwatch してコンパイルするために、webpack-dev-server を使う
Rails 7 では、脱webpackで、esbuild になるけど webpackが終わるなんて数年前は考えられなかったな
フロントエンドの環境構築はほんと安定しないね
いいツールが生み出されるのはいいことなのだが
webpackのconfigは初心者殺しすぎたし wasmのGC TypesがJVMの再実装になってるのは気になる
ここまで来たらガッツリJSというかTSに寄せて欲しいのだが JVM言語に寄せすぎるとオラクルの影響力が強くなるから嫌やぁ
偏り無いのが理想だけど偏るならMSの方が全然いい こういう疑心暗鬼嫌だからワッチョイあるスレに早く移行したいよ >>798
denoはkoaと同じ道を辿りそうだよなぁ denoとkoaを同列に語ってるの意味がわからんのだが 本人の意図と合ってるかは分からんけど
「コンセプトは悪くないが流行らなかった」とかそんな感じじゃない？ ヒットしたソフトの作者自身による改良版という意味で。
思いがけずヒットしたソフトのバージョン2が意欲的すぎてこける現象ってなにか名前がついてなかったかな。 >>803
Ruby on Rails 6 では、webpack の薄いラッパー・Webpacker を使うので、
設定ファイルも、webpacker.yml を使う
webpack.config.js を直接使わない
webpacker.yml で、全環境共通の設定をしてから、
development など、各環境の設定で上書きする
Railsがデフォルトの設定や、使うモジュールを選んでいるから、あまり考える事がない >>817
ちょっと気になるんだけどそのラッパーはwebpackをうまく抽象化、隠蔽してるのかね？
この手のツールって中で使ってるツールに関する知識も要求されることが多くて負担が余計に増えるだけなんだよね SPAに限らないけどフロントエンドは設定ファイル多すぎなんだよね
自由な反面煩雑すぎる
これっていう開発環境欲しいわ wasmが完成すれば多少楽になるのでは？
多数の外部ライブラリとローカルプロジェクトで構成されるソリューションを単一のバイナリにアウトプットする
こんなのは他のコンパイルタイプの言語なら当たり前にできる基本的な能力の１つ
基本的な能力ゆえに他の言語ではサードパーティのビルダーに頼らないし設定もほとんど要らない
複雑な環境構築から解放されるだけでもJSを捨てる価値があると思うんでwasm開発チームには頑張ってもらいたい >>820
フロントに限らずモダンな開発環境はだいたい設定ファイル多いように思うな。ORMにUIのxml、プロジェクト設定ファイルにlintにエディタ用、充実した色んなライブラリやフレームワークの力を借りてる以上、仕方ないんじゃないかな。 formatとかもgolangみたいに、「お前らこれでやれ」ってしてほしい >>820
そういう発想のヤツにはこの業界向いてないからバックエンドとかアプリとか違う分野に言った方がいいんじゃない？ 付加価値造って喜ばれるし、知能労働で工夫しがいはあるし、毎日わりと楽しいです >>823
「不要」じゃなくて「辛いのでやめてください」の間違いでは？ >>820
わかる
重複した設定多いよね
TypeScript使うと更に重複する TSの案件に参加してお勉強を始めた初日にtsconfigとbabelとwebpackとjestに似たようなPath Aliasをずらずらと書かされた時点で既に俺はTSに見切りをつけて仕事を辞めたくなっていた >>831
パスはほんと面倒だよね
微妙に書き方違ったりするし
あとlint系
もうちょっとなんとかならんのかな TSなんてメンドクサイだけやんｗ
javascriptのままでいいよ
わざわざAPIの戻り値とかパラメータをクラスにしてたりするのか？ｗ
過去にC#とかでそういう設計の見て頭痛くなってきたよｗ class以外に型（データ構造）の表現方法があるからclassの出番は少ないぜ 規模が小さいならtypeでもなんでもいいけど
お仕事で扱うようなのだとclassにした方がいいと思うけどね(当然だけどimmutableね)
どんな時でも通じる正解はなくて損益分岐点次第 immutableオブジェクトにclass使う意味無くね？ >>835
いまだにこういう人がいるってのがフロントエンドっぽい >>841
まさか全部クラス化してるの？ｗ
ありえねーｗ
そこまでして何か得でもあるの？ｗ JSは人によってスタイルがめちゃくちゃ変わるのが面白い
俺は関数型スタイルが好きだがクラススタイルを否定はしない tsでgeter、seter使って
世代管理機能付きの値クラスとかね 最近はTailwindCSSかstyled-components+styled-systemでcssを記述するのが好みなんだけど、皆はどうしてる？
facebookもstylexを発表したし、ＭicrosoftもGriffelを公開したしまたcss、css-in-js周りはちょっと流れが変わりそうな気がする 何も考えずに使えて容量も小さくそれなりな見た目になるからTailwindCSSばかり使ってる…… >>846
react(next.js)だとcss modules、素でゴリゴリカスタマイズする用
vue(2ベース、nuxt.js)だとvuetify、さらっと作ってしまいたい用 reactのhookはすぐに受け入れられたのにVueのcomposition apiはなかなか受け入れられない謎 後発だからすでにhookのツラミを知ってるというのもあるだろうね hook以降にReactに入門したけどhook無しのReact世界なんてイメージできないくらい馴染んでると思う。いや、クラスコンポーネントのソースも見たことあるし、読めはするけども ReactをUIを記述するための一種のDSLと考えるならhookはあれでいいと思う
ただ一般的なプログラミングの習慣から考えるとhookは異質すぎる
関数トップレベルでしか使えない、依存関係配列地獄なんかは何故これでリリースしちゃったのか理解に苦しむレベル クラスコンポーネントはコンストラクタの問題とか
stateを生で触れるとかいろいろ問題があった
それ自体言語機能の問題的な部分も大きいのだがね
それはさておきHooksはコード量の削減と副作用の明示的な排除という目的が達成されるから明らかに良い
問題はJSの言語機能の限界ゆえあの様な形になったのをお忘れなく いや副作用排除は全然できてない
ここに副作用があります、ってマーカーにはなってるけど reactは副作用の分離をjsで楽にに実現出来る環境を整えただけでどう分離するかは完全に開発者の領分
自分の知識の足りなさを他者のせいにするのはみっともないからやめた方が良いよ >>861
それが関数型言語ですがw
副作用が起きる部分を外出しして
値をラップした型としてデザインするというのが関数型言語のアイデア
ラップした型から値を取り出したり設定する時に副作用が起きるがそこは目を瞑る
これがHooksによってできているのはお分かりだろう >>862
楽にできてないんだなぁ
>>859で指摘したようにかなり異質だからねhookって
普通にライブラリ作るときにこんな制約持ち込んだらレビューでボコボコにされる
>>863
副作用が起きる場所をラップ(抽象化というが)して外に出すのは関数型でなくプログラミング一般的なプラクティスな
オブジェクト指向でもDIとかあるだろ？
hookがポンコツなのはせっかく抽象化したuseうんたらってのを関数内で直呼びしちゃうこと
このせいで副作用と関数の結合度が高まって扱いにくくなってる
関数のパラメータとして副作用を渡すなりOOPだったらDIするなりもう少しやりようがあった筈なんだがねぇ おじさんの考えるフックの理想的な実装ってどんなの？
jsで良いから例を出してみて >>864
基本はそうだよ
あとはラップした値が違う型を連鎖呼び出しできるようにするbindという操作があればモナド >>866
hookじゃどうやっても理想にならん
本当に必要なものは副作用をコンポーネントに注入するための自然な経路
それは一般的なプログラミング習慣では関数のパラメータだったりOPPでいうDIだったりする
関数の中で副作用であるhookを直で呼んでる時点でダメダメだ hooksをawaitできる仕様ができたらいいんだけどな いやフックじゃ無くて良いからこうすれば良いって言うコードだしてみて >>871
既に答え出してるが？
関数の引数やOOPでいうDIって >>869
>>872
同じ事繰り返し言ってるだけでなんも解決できてなくてワロタ >>873
そりゃ最初から一貫して答えを言ってるんだからずっと同じことになるだろ >>868
JavaScriptで唯一信用できる型は何か？というとそれは関数だけ
つまり値を関数でラップすれば副作用は外出しできる
単純明快なこの発想をReactのランタイムに実装したものがHooksとなる
Reactチームの頭の良さには脱帽する 次スレではワッチョイ入れて荒らしはNGしましょうね～ >JavaScriptで唯一信用できる型は何か？というとそれは関数だけ
その場合の信用できるできないの判断基準ってなんなんだろう >>875
細かいことはわからんが柔軟なJSの関数なら型の制限も高階関数の埋め込みもメモ化も思いのままだもんね。 >>878
コンストラクタを持っていること
JSではこれ以外で型を識別することはできない instanceofの話か。でもそれは『型』の意味する範囲が狭すぎないか DIライブラリ使えば済む話を延々文句言い続けるおじさんって一体 あ、今急になんとなくわかったかも
俺がreactに求めてるのはvdomとvの接続だけだったのかもしれん
状態をどう管理するかだとか、vdomをどうやって構築するかなんてのは、正直おせっかいでしかない
別にvdomをmvvm(この場合はmvvdommになるのか？呼び方がわからんが)で管理したっていいはずなんだよな
なんなら古のformsスタイルだって行けたはずだ
vdomをどうやってvと接続するか、vdomをどう構築・変更していくか、は本来なら直交してる概念の筈なのに、全部セットでreactというパッケージで提供してしまったところがダメなんだ
この抱き合わせはライブラリ的でなく、お節介なフレームワーク的なやり方と言わざるを得ない >>886
その発想は悪くないしアイデアがあるなら実装すれば？
評論家みたいに言うだけじゃ何も評価されない
Reactは仮想Domのライブラリの一つでしかない
数年前はオレオレ仮想Domライブラリは結構あった
全部死んだけど
もし君のアイデアが優れたものなら他の人が流用したり
盗んだりするだろう >>886
そういう用途なら違うの使えばいいだけじゃん 自分で作れとか違うの使えってのはアマチュアプログラマならそれでいいんだけど
仕事でやるとなるとどうしてもシェアが支配的なフレームワークを使わざるを得ない大人の事情も察してくれたら助かる >>891
また盤外のレスバを始める気ですか？
そういうのはよそでどうぞ ちなみにReactは仮想Dom部分はちゃんとライブラリになってるから
単独で使うこと可能だよ
イベントとかもDomと同じものが実装されてるからReactの仮想Domの上にオレオレフレームワークを作ることは不可能ではないと思う フレームワークが決まってるならそれに合わせた設計をするだけじゃん >>894
数年前ちょっと流行ったな
状態管理をreactに依存しないパターン
reactはjsxのレンダリングだけを受け持つ
結局消えてなくなったけど >>886
わからない状態で書き込んでる癖にイキるな
次からは投稿文をママに見てもらってからにしな Reactのテストにはみんな何使ってる？
やっぱJest？ >>901
俺はjest
だけど使ってるっていえるほどテストしてないやｗ テストなんかめんどくせえし手動でいっかいきりにきまってんだろ >>902
なるほど、ありがとう。Jestで使ってるjsdomはスクレイピングで使ったことあったけど、ブラウザ動作のエミュレーションもこんなに出来るんだって感心したわ。
>>903
いやいや、アップデート毎に手動で検証するの面倒くさいやん。手動検証するよりテスト書いてる方が楽しいし。 >>901
storybookのplay関数を使って目視で確認しながらやるのもいいよ
jestでそのstoryを丸ごと流用できるからテストの工数も増えないし、何より目でしっかり確認しながらテストできるのがかなりでかい >>905
ありがとう。
なるほど良さそうだ。目に見えるのはありがたいね。 公式ではないけどTSのReact Docgenがクソ重いのでそれをやめる
なのでstorybookのmain.jsにreact-docgenを使うようにする。
module.exports = {
typescript: { reactDocgen: 'react-docgen' }
}
あとstorybookは全部ビルドしようとするので必要なものだけビルドするようにするとか
const stories = () => {
return process.argv[4] === '-stories'
? [`../${process.argv[5]}`]
: [
'../src/components/**/*.stories.tsx'
];
};
module.exports = {
typescript: {reactDocgen: 'react-docgen'},
stories: () => stories(),
} >>910
storybookはあんま深入りしてないので
指摘は直ぐには解らんけど、
後で見てみます！ jsでも沢山ストーリーがあったり重いプラグイン使ってたりすると遅いかと
その場合は二つ目に書いた必要なコンポーネントだけビルドするようにしたら良い
自分の環境だと20秒ぐらいかかってたのが2秒ぐらいになった コンポーネントからレンダリングに関係ないロジックを分離しろ、という習慣は間違いだったことに気付いた。
コンポーネントに関わるもの全てを密結合し神クラス(関数だが)にしたほうが、ずっと楽で再利用しやすかった。
どうせフロントの寿命は短い。カジュアルでよかったんだ。 ほとんどの場合Vueのほうが書きやすいと思うんだよなあ
depsとかバグの温床だし、jsxも使えるし画面単位のコンポーネントはjsxよりもtemplateの方がメンテしやすい
割と変化激しいからVueの時代来る気がしている
俺の予想はよく外れる >>918
Vue2と3の断絶が悔やまれるね
Vue3.2なら悪くないどころかむしろ覇権取ってもおかしくないと思った veuはデルミネータ書き換えできるけどv-～や@～も別の識別子にかえられると嬉しいのだけど
他のフレーワークに組み込むときちょっと面倒 よわよわエンジニア=Vueって認識ができちゃったのが痛い
まぁ実際そうなんだけども よわよわでもできるということは優れたフレームワークということ 難しいツールを使える優越感みたいなものを刺激するんだろうな
だからマウント大好きプログラマ達に変な人気がある
冷静に考えると道具としては最悪の性質なんだがねぇ…
まあどのツールとは言わんけどね
頭の中に浮かんだものが答え なんだ？ おじさんか？
次スレはワッチョイ入れましょうね。 よわよわエンジニアの俺はvueとreact両方試してreactの方がシンプルで正統派でかつ勉強してて楽しいと思ったけど、結局vue選んだ
簡単なアプリを実装するってなったらreactだとちょっと大げさに感じた
SNS見てるとフロントエンド以外のかけだしやバックエンドはその手間を嫌ってvueから始める人が多いし、vueがまた形成逆転する可能性は全然あると思う hookがトップレベルでしか呼べない、条件分岐もループもNG
こんな冗談みたいな制約さえなければなぁ
あと依存関係配列とかいう河原に石積むような不毛な作業もなんとかならんもんかね 大元がfacebookっていうのがなんか嫌
angular... やっぱりおじさんじゃないかぁ。今日はID変えなくていいの？ >>932
IDとか別に気にしとらんよ
通信容量などの都合で切り替えてるだけだから >>929
純粋なSPA以外にReactを使おうとしてる人が多いんじゃないかな？
プログラマーが全部支配できない要素が入ってくるとReactは破綻するよ Reactでガチャガチャしてるところに横からDOM操作されたらそりゃ無茶苦茶になるけど、それはReactに限った問題じゃないような…… Reactは純粋なプログラミング力が問われる。だから力があるプログラマーが揃えば良いものができあがるんだろう。
だけど大半は技術ないのがほとんどだし、React使いこなせるやつが少ない、結果人が足りなくて比較的使いやすいvueを採用する。
今までweb制作でjquey振り回してたやつはvue選びがちだ。
ただ最近のトレンド見てるとvueからreactに移行しましたって人が多いけど、reactのツラミがまだわからないだけで、そういうのが2、3年後表面に出てきた時にどうなるかだと思う。
Reactにしましたがvueに戻しました、みたいな流れになってもおかしくない おじさんが意図的にせよそうでないにせよIDコロコロ変わるので、ワッチョイは必須 おれはラスおじじゃないよ？
というかvueとreactの話してんのに何言ってんの？
ラスおじに取り憑かれてんじゃない？
頭大丈夫？ やっぱり建設的な会話もできないゴミしかいないようだしこのスレはもう落としていいよ
いつ見ても役に立たない Vue3やります
デザイナーやディレクターがテンプレートじゃないと運営無理って言われました
コンポネントとstyled_jsxは無理だとさ フロントエンドなんかやってる程度のやつに力のあるプログラマーなんかおらんよ
DirectXとかフロントやってる程度のプログラマーじゃろくに作品ひとつ作れんやろ reactはなぜ機能単位で関数やコンポーネントを分割するかが飲み込めていないと面倒臭く感じるかもね・・・
俺も最初「すげえ面倒くさいな」と思ってたけど、reactが関数型プログラミングの考え方に基づいていて、それがテストのし易さやコードの可読性の向上に繋がっていることが理解できてからはreactを使うのがすごく楽しくなったな でもcompostion apiで同じことできるようになったし >>946
歯科と麻酔科を比べるようなこと言われてもな Ruby on Rails では、BDD/TDD のRSpec・自動システム(ブラウザ)テストが、CI/CD に含まれている。
pull req, CircleCI, Github Action でOK なら、Heroku で起動される
ただし、すべての本で、テスト部分は省かれている。
テスト部分で、初心者の脱落率が高いから
YouTube で有名な、雑食系エンジニア・KENTA のサロンでは、
未経験者の転職用に、必須の工程だけど Vue3マジでわかりやすいなこれw
何一つ頭を使わずに書ける Jestでモジュールまるごとモック化して（該当モジュール内の）import処理をスルーする事ってできないのかな fkutterもいつかは仲間に入れそうですか？
いまはゴミでも 結局、普通に回帰してて笑
https://zenn.dev/shimpeiws/articles/afcc43990d13c0
Before: PageやScreenといった最上位のコンポーネントをContainerとしてデータの取得を集約、下位のPresentational Componentsに渡す
After: 表示のためのデータ取得と描画をできるかぎり近くによせて管理する、必要に応じてStoreの場所を上位に移動したり、ContextやGlobalなStoreに移動する Reactに限らずウェブ系ってずっとそうだよ
トレードオフの関係にあって銀の弾丸がない問題に対して
1)目先の不便さを解消する革新的(に見える)ライブラリが登場
2)スケールするにつれて目を背けていた別の不便さが無視できなくなる
3) 1に戻る
これをずっと繰り返してる
まるでシーソーで遊ぶ子供達みたいにね
なのでもしかしたらjQuery(あるいは類似の新ライブラリ)に回帰する日が来るかもね それってウェブ系に限らないよね。
みんな（色んな意味で）大好きOOPは、無関係な設計論や実装をごった煮にして、上記3つを壮大にやらかしちゃったわけで。
とはいえ何も残らないわけじゃないから、無駄にはならない。 同じところを周ってるんじゃなくてらせん状に昇ってるのよ というか思想の違いによるみたいなもんだろ、そういうのって >>959
あぁ、なるほど、上手いこと言うなぁ。そういう感じだわ jQueryとかいう世のフロントエンド初学者に悪影響しか与えないゴミ
だいたいのことはjQueryなしでできるし、jQueryの機能をjsの標準機能だと思い込んでしまってる奴もいる始末 jQuery誕生以降にWeb作成に入った層は可哀想だとは思う。 とはいえES5までの混沌とした環境での開発には大いに貢献したよ
今でも使ってる人はどうかと思うけど おれはprototype.js信者だったよ
今思えばクソコードなのだが
当時こいつのコードを最初に見た時の衝撃は忘れられない
こんな書き方できるのか？って思ったな jQueryでWebフロントエンド入門します！とかいうツイート見て今がほんとに2022年なのか確信が持てなくなる事があるw
初心者はまぁ知らないんだから仕方ないし、別に使ってもいいと思うけど、教える側はちゃんと今後役立つと責任持てんのかと 謎にjQuery用語記事とかが出てきてしまうのがまた フロントエンドに振り回せれすぎな感じがする
あくまでも最終的な成果物はhtml、javascript(es)、cssだって事を忘れないで欲しい
基本は大事だよね
特にcssは進歩が著しいから生のcssを扱うメリットは充分あると思う
jQueryやOOPを下げずんでいる人がいるけど、その時の時代背景や必然性があったんだと思うよ 初心者がまず覚えるべきなのはなにはともあれバニラだよね。OOPも重要だよ、一時期持て囃された程じゃないってだけで。 えっ、これ標準ライブラリじゃないの？ってコンポーネントが個人のOSSに頼りっきり
しかも別の開発者も似たようなの作ってて、選定の手間が無駄にかかる
ウェブ系ってDIY大好きすぎねーか？
ホビーばらそれでいいんだけどさ
ビジネスで使うものはDRYの精神を尊重してさ、オフィシャルが全部完璧に整備しといてほしいもんだ やっぱ次スレはワッチョイ必須だわ。おじさんNGするために そんなん使ってんだ…… ぷッ
って言われないフレームワークを教えて下さい！ >>422
同感です
WASMと併用の時代になりつつあるのを感じています
WASMを記述する言語はGCランタイムを持たない言語でないと無駄が多すぎるため
現状ではRust一択の状況だと認識しています Rustのfrontend frameworkは盛んすぎて数が多いため見極めが必要 >>986
決して得られない返信を自演してるんやろなぁ。哀しいなぁ ようやくここまで読み終わりました
おじさんと呼ばれる人が各方面に5人いるのですね
203: reactおじさん
219: jQueryおじさん
356: Blazorおじさん
372: C#おじさん
538: Rustおじさん 下3つは多分同一人物。口調、論法、出没時間帯が近い。まぁ、次スレからワッチョイ付けば関係ないけど 次スレ見てたらワッチョイ導入がおじさんにクリティカルヒットしててワロタ このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 55日 18時間 4分 59秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
