Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/
Svelte
https://svelte.dev/
※前スレ
Vue vs React vs Svelte Part.7
http://2chb.net/r/tech/1610901677/
Vue vs React vs Angular vs Svelte Part.8
http://2chb.net/r/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 を禁止とか書いている
いつも、この荒らしがスレを立てて、テンプレを変えてくるので、
漏れらは荒らしの立てたスレから、正規のスレへ誘導してきた
ここで良い
向こうのスレは無関係な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だし
普段ネットで見てんの？ >>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
取り調べで「事実無根」と容疑を否認。
卓球所に松岡学(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は結局一回も触らんでオワコンなった
我ながら良い選択をしたね
今後メンテナンスしなきゃならん人はご愁傷様
アジア圏でしか使われてない
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を昨日から始めたんだけど
既に挫折しそう…
ボタンの色を変えたいだけなんだけど
色んなページを見ながらやっていて
これで色は変わったんですが
ボタンを押したら指定した色ではなく
白色にボタンが変化してしまいます
なんか設定が間違ってるんでしょうか？ ちなみに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で使われてるし少なくとも数年後に捨てることはまずないし
捨てたとしても移行ツールは用意されるはず
そのスレお前すら使ってないじゃん
先にお前が移動しろよ
このスレになってから明らかに内容が良くなったし、あっち行く理由がない
>>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
これはパラダイムシフトは確実な気がする
フロントエンドは面白くなるぞー >>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のみ！
意味あるぞ。
お前〇〇だろ！荒らすな！が
お前○○だな！荒らすな！に変わる
荒らしている相手を文面を読まなくても、ある程度的中させられる
今のフロントエンド界隈は
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?
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 
