◎正当な理由による書き込みの削除について： 生島英之とみられる方へ:
Vue vs React vs Angular vs Svelte Part.10 YouTube動画>1本 ->画像>1枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/tech/1646747836/
ヒント：5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。
!extend:on:vvvvv:1000:512
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/ Vue vs React vs Angular vs Svelte Part.9
http://2chb.net/r/tech/1642316774/ ★ここではjQuery, Ruby, C#, Blazorの話題は禁止です
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
Next, Nuxt, Sapper, Gatsby, VuePress, RedWoodなどはおｋ。
VIPQ2_EXTDAT: default:vvvvv:1000:512:: EXT was configured
vsはいらんな
フロントエンド総合スレで良い気がする
>>6 画面遷移の度にリソースをリロードしてないか？
>>7 >>8 frontend framework performanceで堂々の最下位
まだstage0で入るかどうかすら不明だ。それにenumとか余計なものは無くなるけどほぼTSそのもの。TS終了なんかじゃないよ
というか、ブラウザがts直接読み込めて動作できれば良いだけでは？
>>4 ほんとそれな
てか、propsでコンポーネントを渡す場合に
<Parent child={<Child />} />はなんかパフォーマンス悪そうだから
<Parent child={Child} />で渡せるようにした方が良いって記事があって驚いた
これ実際は真逆で、後者はParentが再レンダリングされる度にChildがJSXを生成することになるんよな
前者はjsx、後者はjsxを出力する関数を渡しているわけだからね
フロントもC++で書けるようにして統一したらすっきるするとおもうよ
まあしょぼいプログラマーが軒並み死ぬだろうけどC++はなによりも強いからしゃーない
>>21 ナビゲーション系は多いよね
メモ化が効くからかなりパフォーマンス上がる
知らんけどC++をwasmにコンパイルすればいいやん。知らんけど
結局tsって人を幸せにしたのかな
jsの負債化に苦しめられた時間のほうが長かった気が
TSで書き始めると二度とJSに戻りたくなくなるけどね
ただ要求は年々高まるのにJS、HTML、CSSの進歩が遅すぎるんだよ
TSもそうだがその溝をフロントのフレームワークが力技で埋めてくれてるのが現実
ウェブ標準は標準でウェブコンポーネントとかなかなか凄い進歩だぜ！
https://developer.mozilla.org/ja/docs/Web/Web_Components まぁ、多くの人が求めてたものとは違うみたいで滅多に話題に上がらないけど。
と思ってたけど、調べてみるとlitとかではライブラリ内で使ってるようだし、ReactもPreactもWebComponentsのサポートがそこそこ充実してる。
気が付かないうちに使ってるやつだった。
React学習始めたけどCSSの読み込みだけで7種類もあるの吹いた
こういうので乱立するのやめて欲しい…
そんなもん手動で一回やったらそれっきりやらん
それが一番はやい
Jestと、ReactのテストライブラリかPuppeteerの組み合わせ
Ruby on Rails では、BDD/TDD はRSpec で、
UI・システムテストは、Capybara
Rails 7 で、脱Node.js, Webpack, Babel。
IE の死滅により、ES5 へ変換しなくても、ブラウザはES6 のままで動く
WebSocket を使う、Hotwire で、
React に奪われたシェアを回復すべく、SPA のgame changer を目指す、Railsの野望！
IEが死んで下限はSafariになる。そうなるとtargetはes2020くらいになるかな？
サイの表紙の3冊のサイ本で、
Flanagan の第7版を、チラッと見たら「初めてのJavaScript 第3版」と、ほぼ内容が同じw
ここ数年で、何も進化が無かったw
JavaScript 第6版、2012、David Flanagan
初めてのJavaScript 第3版 ――ES2015以降の最新ウェブ開発、オライリー、2017
JavaScript 第7版、2021/12, David Flanagan
litは小さいのが売りで、cssも埋め込みやすく、しかもShadowDOMで面白そう。
たまたまフィットした案件が転がり込んできたので喜び勇んで使おうと実際コード書いてみたのだけど、Preactで同じことしたのとほぼ容量同じだった。
それならPreact使うよ……
useReducerとuseMemoとかuseCallbackって使ってるかね
わしはuseCallbackはちょくちょく使うんやが、reducerとmemoはいまいち使いどころが分からんくてね
reducerの活用例みると複数のinput要素を1つのステートにまとめるときに有用みたいな書かれかたしてる気するけど、オブジェクト型のステートでもええやんとも思うのよね
memoは重い処理結果のメモ化に役立つとか見るけど、クライアント側でやる重い処理って思いつかんくてな
memoの例でforでものすごい回数ループさせたやつとか見るけど、そんな処理なくねとも思うし
記事の一覧取得とかやったらNext.jsの話なってまうけどstaticpropsで一覧取得するし
>>45 useStateの実体はuseReducerだぞ
何をやってるか考えたら当然だと思うが
おじさんがreactおじさんに変わる瞬間かな？
ヤメてくれ...
esbuid使って設定の簡単さとビルドの速さに驚いた。そこでViteも手を出してみたけど……なんかメリットよくわからんなこいつ
>>39 に書いたけど、
Ruby on Rails 7 で、脱Node.js, Webpack, Babel で、esbuild になった
WebSocket を使う、Hotwire で、
規約だけのイベント登録・Stimulus も使う
Rubyだけで、SPA になったから、React, Vue.js は今後どうなるのか？
Railsが、SPA のシェアを奪えるか
あまりに変更点が多すぎて、Rails 6 から勉強を始める
最近Reactの勉強始めたんだけどJavascriptの言語仕様で無理やりHTML/CSSを扱ってみましたって感じで凄く気持ち悪いわ
今までPythonで書いてきたってのもあるけど本当にこんなのが今後も流行っていくの？
proosに変数渡すときに<func foo=hoge bar=fuga>ってなるのも気持ち悪いし今後やっていけるか自信がない
あー来たよいちいち仕様に文句つける他言語野郎が
別に嫌ならやめてこっち来んなってことだ
JSも決して完璧だとは思わないけど、正直Pythonよりはマシだと思う……
でも正直微妙な時期だとは思う
Angularは嫌じゃってことでもっと手軽に始められるのが流行ったけど
あれも欲しいこれも欲しいと要望を吸収していった結果、継ぎ接ぎ感がかなりある
10年以上Python使ってるけどそんな風に感じないけどな
ただreactに不慣れなだけでしょ
>>60 最初滅茶苦茶だと思ってたけどなんか便利
ただ凝った輩が無理やり面倒な文を使って論議しているのはうざい
自分もReact入門してる
たしかに触る前に気持ち悪いなぁとは思ってたけどさ
触ってみたらプログラムよりで面白いなーと思ったわ
ERB(Embedded Ruby)では、PHP みたいに、
HTML 内に、<% 〜 %>, <%= 〜 %> で、Rubyの式・コード片を埋め込む。
<% 〜 %> は出力されないが、<%= 〜 %> は出力される
<% writers = ['あ', 'い', 'う'] %>
<p>
<% writers.each do |writer| %>
<%= writer %>さん
<% end %>
</p>
これよりも、JSX の方が可読性が高い
Reactの1番良い点は覚えることがめちゃくちゃ少ないこと
Vanilla jsからすぐ移行できるのがありがたい
Vue3もちょっとやったけど覚えることが多すぎて無理だった
>>57 <func foo=hoge bar=fuga>←これじゃビルド通らないぞ
そんなガバガバなヤツにはjsx書けんよ
>>57 JSXはオプションなので別に使わなくてもおk
気に入らないなら(気持ちはわかる)普通の関数のように呼び出せばよろしい
>>69 htmlテンプレートでの開発から移行するには楽なんだろうね
vue独自の構文とか覚えたくもないけど
>>73 ReactはHooks覚えるだけだからな
多少癖はあるが拡張性はあるし
副作用隠蔽できるし良いこと尽くめ
ASP classicがそんな感じだったような。。うろ覚え
lazyload実装したら、viewContainerRefがundefinedになるんだけど、なんで？
教えてエロい人
ひぇぇw怖い怖い
> オープンソースのnpmパッケージ「node-ipc」にロシア在住の開発者を標的にした悪意のあるコードがメンテナーによって追加される
https://gigazine.net/news/20220322-sabotage-code-to-node-ipc/ React Hook Form便利だなと思って使ってたんだけど、実は全然要らんかったことに気づいてしまった……
>>78 あれ検証ライブラリのラッパーだもんね
ささっと作るには良いけど仕組み理解してれば無い方が楽よね
>>78 覚えることが多いライブラリはReact向きじゃないね
>>80 そう、仕組み理解してれば（複雑になるにつれ）使わないほうがシンプルに書けると感じた。今はブラウザの機能も充実してるし。
>>81 watch周りとかバリデーション周りとか変に複雑だった。ドシンプルなフォーム作るなら（覚えること少なくて）悪くないと思うけどね……
Jest + React testing libraryやってる人いる？
React testing libraryつかってるとテスト環境だけ動かないことがしょっちゅうですぐ壊れるし、辛すぎる
現状フロントのコンポーネントのユニットテストは費用対効果が悪すぎると思う
もしテスト作るなら必要なテストを見極めるスキル必須だわ
わからんでもない。Puppeteerでテストしてる
https://github.com/redwoodjs/redwood/releases/tag/v1.0.0-rc.final.1 React、GraphQL、Prismaのフルスタックフレームワークとして作られているRedwoodJSがリリース間際らしいけど
わざわざ事前に組み合わせる必要あるのかな？
そういうのもういらん
どうせすぐに廃れてメンテすらされなくなる
そうか？
むしろJSでフルスタックみたいなやつは廃れるどころかこれから伸びると思うけどな
そこまで求めるなら他の言語選ぶかな
jsで完結したい人には良いんだろうけど
>>86 これ
作りっぱなしのプロダクトが多すぎる
もうAngularに帰ればいんじゃね
学習コスト高いって言うけどどうせ他のも必要な機能揃えたら同じくらいの勉強量になるんだし
ならんよ
React一択
とにかく学習コストが低い
Vue3の本が最近出たから立ち読みしたけど
なんじゃこれって感じ
相変わらずthis使いまくりでバグりそうだし
>>91 いや、これはフロントとバックエンドの統合ライブラリだからバックエンドは別の言語でやりたいなって意味
BlazorはC♯で全部やりたいって人以外にはメリット無くね……
Reactを使うのかVueを使うのかについて個人的なモチベーションを整理したかった
https://zenn.dev/marokanatani/articles/compare_vue_and_react > VueはEasy、ReactはSimple
わかる
vueはフレームワーク独自のルールが多かったり業務でちゃんと使うにはVSCode等のエディタの拡張機能が無かったら辛かったりで、慣れすぎてしまうと悪い意味でvue以外が使えなくなってしまう感じがする
たしかにいまvue(nuxt)で開発してるけど
わりとめんどくさいとこあるね
typescriptを使わなければそうでもないのかもだけど
vueは確かに使ってると楽なんだよね
ただ、何でもフレームワークがやってくれるから根本のプログラミングに対する考え方が深まらずにvueをどんだけ長く使っても「ただvueに慣れた」で終わってしまうことになると思う
reactはちゃんと使おうと思ったら
・javascriptの文法
・関数型プログラミングとは何か
・副作用とは何か
みたいに、深いとこまで突き詰める必要があるからreactを使いたくない人はこういうのを嫌がる
その代わりreactに習熟すると他のjavascriptフレームワークや他の言語にも活かせるような考え方が身につくと個人的には思ってる
よくReactは関数型プログラミングって言われてるけどあんまり分かってないわ
そもそも関数型言語に対する理解が足りないんだろうけど今まで書いてた手続き型言語(C++/Python)とそこまで書き方に違いがあるかって言われると謎だし
移行して違和感あったのは
if (is_hoge === true && do_hoge()){}
みたいなのだけどこれは関数型関係ないだろうしなぁ
>>106 ぶっちゃけ関数型言語的なのはクロージャくらいだよ
型があると話が変わってくるけど素のJSならそれくらい
hooksで良いなと思った部分は副作用とマークアップ部分が綺麗に分離できるようになったことだな
それによってコンポーネント内の副作用の影響等が把握しやすくなったり、カスタムフックで自分好みに複数のフックをまとめて抽象化出来たりするからコードの可読性も上がったように思う
createRootとrender分けろって警告で出したね。
シンプルじゃないなぁ
>>97 いや、抜本的に変わったのは3.2とかだったろ
スマホアプリのデータをWebでも編集できるようにしたくて
色々調べてく中でここにたどり着いたんだけど
なんかWebフレームワークは乱立した感じになってるのね…
調べてもどれを使うべきなのかよく分からない
githubの星くらいしか参考データもなく
でも
>>101さんのリンク先記事が参考になった
別にそんなにライブラリは使わないし、規模の小さい個人開発はVue.jsで良さげなのかなと
webアプリ初心者が両方ちょこちょこ触ってみてvue使ってるよ
なんかpinia好きだわ
コード打ち込みはreactが楽しいね
正直たいしたものつくらないから優位性はよくわからん
> 次世代のReact？ Solid.jsについて
https://zenn.dev/nicky/articles/754f0ca74c887a もうReactの天下も終わりかぁ早かったなぁ
100歩譲ってReactの終わりの始まりだとして、それ、React系の流れを汲んだ技術じゃん。今はとりあえずReact使っといて（本当に流行ってから移行しても）問題ないように見える
Solidは仮想DOMを使わないため高速
さらにReactでの無駄なレンダリングも抑えている
Reactを採用するモチベーションがない
仮想DOM使ってないから速いってのは木を見て森を見ずでは？
reactやvuejsでアプリケーションを構築しててパフォーマンスが問題だと感じる場面に遭遇したことはあるが、大量のデータをフェッチしていたり自分のコードの書き方が悪かったりで、reactやvuejs自体が問題に感じるようなことは無かったなあ
なんでReactは仮想DOMつかってるの？
メリットはなんですかい？
jQuery みたいに実DOM を扱わない。
仮想DOM変更時には、自動的にDOM木の差分を計算し、差分部分だけを実DOMに反映させる
ただし、メモリは実DOM・仮想DOMの2つを持つので、2倍使う
>>125 それ言われてハッとしたわ
今や差分検出と書き換えをやるメリットってほぼない気がする
本当に必要なのはJSXとHooksであって仮想DOM入らんかも
Webフロント門外漢は知らないかもしれないけど実DOMの変更はレンダリング処理とか入ってそこそこコスト重いんだよ。
最近はtemplateのslotとかあって必要なとこだけ更新しやすくなったけど、それでも。
仕事中なのでこっそりドキュメント読んだだけだけどかなりよくできてそう
Solid.js普及するといいね👍
個人的にRNよく使うからそっち方面もサポートしてくれれば最高です(仮想DOMないと流石に厳しいか？)
その重いっていうのを数字で見せてくれる人がいないのよね
正直10年前の比べてマシンスペックも上がったし
大した差はないんじゃないの？
むしろ差分検出なんてことをやることのほうが重い可能性
これreactじゃなくてsvelteが死ぬんだろな
差分検出は軽いでしょ？
各ノードに、変更の有無のフラグを持つだけじゃないの？
もう速度くらいでシェアは変わらんよ
重要なのは開発体験の方だ
パフォーマンスばっかり言及されてるけどこれのスゴイ所はhooksのトップレベル制約、明示的なキャッシュ処理、依存関係の記述から開放されることだろう
reactを踏襲しつつ弱点を見事に解消してる完全な進化系だからもうreactを選ぶ理由がない(レガシーのメンテ以外では)
これが流行るかは別だけどreactが文句のつけようのないものってわけではないよね
競合相手のvueがそれ以上に迷走してるだけで
>>139 そこから開放されても、（広い意味での）状態の取り扱いは残るし、あんまり魅力的とは思わないな。
どうしてもReactを過去のものにしたいようだけど。どっちも使えば良いだけなわけで。
たまには Angular のことも思い出してあげてください
誰も答えられないの？
なんでReactは仮想DOMつかってるんすか
仮想DOMを使うのは現状一番速度とコードの少なさでバランスが取れてるから
あとReactは自由にレンダラーをすげ替えられるから、もっといい方法があるなら
仮想DOMを使わないReactレンダラーを作って実装してそれを使えばいい
だからReactを離れる必要はない
マルチプラットフォーム対応とかかな？
Solid.jsは仮想DOMを捨てたからモバイル移植が難しいと予想
>>146 仮想DOMは使えば有利というものではないからそれは難しいところですね
>>147 仮想DOMとマルチプラットフォーム対応は無関係ですね
仮想DOMという抽象化レイヤでプラットフォーム間の差分を大部分吸収できるのでマルチプラットフォーム対応しやすくなるのでは？
>>145 上で書いてるだろw
DOM全体を書き換えるとブラウザの描画パフォーマンスが落ちるのよ
jQueryおじさんがinnerHTMLに丸ごとぶち込むようなコードだよ
一方JSXはユーザーからはinnerHTMLに全部突っ込むコードを毎回生成しているように書いてるけど
中では差分だけ見てるというトリック
これこそが仮想DOMのメリット
>>150 そのメリットは仮想DOMを使わずとも可能なので仮想DOMのメリットではなく差分書き換えのメリットですね
そして差分書き換えのみと比較すると仮想DOMを用いる分だけデメリットですね
>>151 1番大きいのはユーザー体験だよ
該当箇所のDOMを丸ごと毎回生成する処理を書くだけでいいのだから
以前はDOMの状態をみて書き換える箇所を自分で判断してた
それこそがjQueryなコードをスパゲッティにした原因なのよ
パフォーマンス速くしたいからDOMの差分を自分で見る→コードがスパゲッティ
差分見るとスパゲッティになるからDOMを毎回丸ごと生成したい→innerHTMLに突っ込むしかなくてパフォーマンス劣化
この悪循環の無限ループ
これを両方同時に解決したのが仮想DOMでありReact
俺が信者になったのはこれを意識した時だな
マジで神だと思ったね
ここにいるのに仮想DOMメリットを言語化できるやついなかったのな
上のような事実というか歴史的経緯があるんだよ
しっかりと理解してくれ
別に仮想dom使わなくても良いんだよ
あくまでレンダリング高速化の手段の一つ
reactが差分管理として仮想domを採用しただけの話であって他に良いのが出て来ればそれに変わられていくだけ
ただdomと密接に結合するようなレンダラーと差分管理を分離しないアプローチは流行らない
webにしか使えなくなる
>>150 Solid.jsとsvelt.jsはDOM全体を書き換えてるの？
>>156 流石にそれはない
ソース読まないとわからんが別な方法で管理してるのだと思う
>>155 まあ仮想DOMはメモリをバカ食いするデメリットはありからね
他の方法で差分管理できなら問題ない
Reactの次が見えてきた
>>156 コンポーネント(DOM)を生成するのは最初の1回だけで
生成した後はObserverパターンで必要なところだけ更新するようだよ
ソースまだ読んでないからハッキリしたことは言えんが多分そんな感じ
仮想DOMツリーを使わずに差分管理する場合、変化する部分に状態管理機構（solid.jsで言えばsignal、webcomponentsで言えばslot）を打ち込む形になる。
差分管理する要素が少なく、DOMツリーをダイナミックに動かさないのであればsolid.jsのようなやり方に速度的なメリットがあり、そうでなければReactに速度や構造的なシンプルさのメリットがある。そんな感じじゃないかな。
よく知らんけど
>>157 いやおまえが仮想DOM使わないと全書き換えって言ったから聞いたんじゃん
>>161 それはミスだ
そこまで深く調べてなかった
多少コード読んだら状態管理とか変更履歴で管理してるっぽくて想像以上にガチな作りだった
こうやって素直にミスを認めて謝れる人めっちゃ好感持てる
でも俺の疑問はまったく解決してない
・なぜReactは仮想DOMを使っているのか？
・仮想DOMを使わなくても一部のレンダリング更新だけで済むってのか？
・そうであればブラウザのエンジン自体が部分レンダリングに対応しているのか？
・じゃあReactの仮想DOMのメリットってなんなの
>>166 仮想DOM自体にはメリットは全く無くむしろオーバヘッドというデメリットがある
DOMの差分更新は非常に重要で全体更新よりも圧倒的にパフォーマンスが高い
DOMの差分更新はSvelteでもSolidでも各種Vanillaでも当然行われているが仮想DOMは用いられていない
それらと比較してベンチマークなどでReactが遅い原因の一つとして仮想DOM使用によるオーバヘッドが考えられうる
Reactでいう仮想DOMというのは本来は単なるフレームワークの実装の都合ってわけじゃなく、
テンプレートがレンダリング結果としてDOMオブジェクトを返しているように見えるけど実際にはそうじゃないから仮想DOMなんだよ。
Vueみたいに単なる実装の都合で内部的に仮想DOM使ってるのと比較されるからそのへん混同されがち。
その意味だとSolid.jsはどうなんだろうね。まだ触ったことないからわからないけど、テンプレートは直接DOMオブジェクトを生成するの？
仮想DOMってただのjavascriptオブジェクトの階層構造だよね
部分レンダリング更新ってのは、この全体の階層構造のうちの一部の階層のオブジェクトが更新されて、その階層に該当するDOMだけが再レンダリングされるってことかね
その階層ってのはShadowRoot単位なのかな？
想像だけど
>>170 まず仮想DOMは全く関係ないので忘れて横に置いとくといいよ
実DOMを生成する時に全体を生成するのではなく現状の一部を利用して最小限のパーシャルツリーを作って入れ替えるのが部分レンダリング更新
ブラウザによる画面レンダリングも最小限となりメリットがある
今どきのフレームワークならたいてい採用されている
この実現のために仮想DOMは必要としない
一方で仮想DOMは一部のフレームワークが採用している単なる内部のデータ管理方式の一つ
仮想DOMが他の方式と比べて何か有利な点は特にない
実行時に差分検出となるなど不利な点はある
「高速」の比較対象はpostして全部更新だったりする？
>>171 なるほど
つまり
ReactやVueはデータ管理を仮想DOMで管理してる
Solid.jsやSvelt.jsはデータ管理を実DOMで管理してる
この認識であってる？
なぜデータ管理を実DOMで管理してるんだ？って思うけど、仮想DOM使ってないなら実DOMしかないよねってこと
>>173 それは正しくない
どのフレームワークもデータ変更に対応して最終的に実DOM操作をして反映させる点では全て同じ
データ変更がどういう時にどこで起きるかはプログラム作成時にわかっているので
SvelteやSolidはそれらの情報を利用してある種のコンパイラとなり実DOM操作のJavaScriptコードを事前に生成してしまう
つまりSvelteやSolidは実行時にはその生成されたJavaScriptコードが動くだけ
一方でVueやReactはデータ変更に対して仮想DOMに反映させて前後の差分検出をしてその差分を反映させるために実DOM操作をする
>>173 たぶん誤解してる。仮想DOMの使用有無にかかわらず、実際のビューの状態を持っているのは常に実DOMだ。
仮想DOMが登場するのはビューの状態を更新するときで、仮想DOMの場合は論理的には(実際には更新不要な部分は使い回すような最適化はある)モデルの状態に基づいて毎回新しい仮想DOMツリー全体を作り直し、
その仮想DOMツリーをあるべき姿として実DOMを更新する。
一方で仮想DOMを使わない場合は、仮想DOMツリーの作り直しを省いて直接実DOMを更新する。
>>174 SolidやSveltのその操作用のjavascriptのコード生成ってどんな感じ？
いまいち想像が足りないからわからん
コードってなに？
具体例がほしいかな
>>175 React ： データ更新 → 仮想DOM更新 → 実DOM更新
Solid ：データ更新 → 実DOM更新
こういうこと？
このSolidの直にDOM更新ってどうやってツリー全体のうちの差分を算出してるんだろ？
差分とか関係なくjqueryみたいに要素を特定して更新してるのかな？
SolidはデータバインディングしてるだけだからDOM上のどこを更新すればいいか最初からわかってる
となると負荷がかかるだけの大げさなツリー差分計算は不要かと
reactがツリー差分を計算するのは何処が変わるのかreactが把握してないから
Solidはreactに似てるけど根本的なアーキテクチャは違う
>>176 普通にフレームワークを使わずに書けばわかるけど
差分算出なんて全く必要のない行為
必要となるのは変更されたデータを反映するDOM操作のJavaScriptコードのみ
メモ化しなかったら子コンポーネントの要素を再度全てレンダリングしちゃうのでは？
それぞれそのへんはムダを省くよう仕掛け対応があるね
フレームワークとして最低限それはやらないと
結局みんなはっきりは理解していない感じらしいね
まあ自分もなんだけど
solid.js作者による解説記事見つけたよ
正直震えてる
アーキテクチャがやば過ぎ
オワコンと言われた
Reactive Programmingが復活した
https://indepth.dev/posts/1289/solidjs-reactivity-to-rendering この記事でDOMの更新原理が全部解説されてる
ただ理解が追いついてない
何処でReactiveプログラミングが終わって、何処で復活したんだよ。
パラダイムの話と実装の話をごっちゃにしとらんかね。
createElememtしたオブジェクトをクロージャで保持してるのか
確かに生DOMだ
記事はいいけど
>正直震えてる
>アーキテクチャがやば過ぎ
こういうの傍から見て寒すぎ
DOMそのまま掴んでるってことはReact Nativeは絶望的か…ちと残念だ
>>192 フィボナッチ数の計算がべらぼうに重いだけだよ
>>191 RN的な使い方は無理だろね
メモリとんでも無い事になりそう
シンプルなWEBページ特化
メモリは心配してないというか仮想DOMが無いから確実に減る
でも仮想DOMが無いせいでDOMと結合度が高くなってるからマルチプラットフォームは難しいだろう
React.jsやVueってマルチプラットフォームだっけ？
>>196 それは違うんじゃないか
こういうフレームワークを作る時に内部はもう一段抽象的なデータを持つ
その抽象データからDOMが対象ならばDOM操作コードとそのオブジェクトを生成といった具合
だから生成されたものだけを見てDOMと結合しすぎていると判断するのはおかしい
例えばReactの仮想DOMもその内部の抽象データなのだから同じ土俵で比べて判断したはうがいい
仮想DOMがメモリ食いまくってるかというと別にそうでもない
>>196 なんで仮想domが無いからメモリ減ることになるんだよ
仮想domの代わりにコード生成するっていうのに
>>185 これ要約してくれ
お前らの好きなキータやゼンに上げてもいいから
>>200 仮想DOMは変化のない部分もツリーの生成が必要
リアクティブプログラミングなら変化が無いとわかってる部分は省略できるはず
>>200 SvelteやSolidがコード生成するのは実行時ではなくコンパイル時点
そして生成されるコードはVanillaで書いたときと同様な感じでわずかなDOM操作コード
仮想DOMのように余分なメモリを使用したりその管理のためのコードが必要になったりはしていない
>>203 実行時に読み込んでメモリ消費するじゃん
アホかよ
まさかとは思うけど何もしないのと比較して増えてるからメモリが減ってないじゃないかって意味で噛み付いてきてるのかな？
仮想DOMと比較してメモリが減るって文脈が読めないのかしら
極僅かな例外も存在するかもしれんがそれをケースバイケースというのは言葉遊びにしか感じないな
>>204 Reactにも仮想DOMを操作するコードがあるし
さらに仮想DOMで差分算出するコードもあるし
さらにその差分に対して実DOMを操作するコードがあるんだよ
SolidやSvelteはそのうち最後の実DOMを操作するコードだけになるよね
さらに仮想DOMを保持するメモリも必要ないよね
何を根拠に仮想DOMがメモリ食うと言ってるのかは気になるところ。仮想DOMツリーなんてブラウザのタブを担当するプロセスの消費してるメモリの一部でしか無いのに
Excelみたいな巨大アプリでどのくらい消費しているのか知りたいね
知らないか？
計測せずに性能を語っても妄想お披露目会にしかならんだろ
>>207 言葉遊びはお前だよ
仮想domだからメモリ使う前提で話してるけど根拠は？
ほぼあんたの思い込みでしかない
>>213 仮想DOMの生成にメモリを使うのは当たり前では？
なぜ誰も計測してないかを紐解くと、Reactで（他のライブラリやバニラより）メモリ食いすぎて困った、という事例が無いからでは？
>>202 >リアクティブプログラミングなら変化が無いとわかってる部分は省略できるはず
そんな単純な話かなぁ。差分を求めずに「変化が無い」ことを判断する方法は自明じゃないように思うが。
Reactでも速度面で困ってるわけじゃないからな
Solid.jsが小さいのは魅力
Solid.jsのdoc見てみたけど、まず多言語対応されててすごい
精力的なのはいいね
Vue2で作ったアプリが10個以上ある
それらのアプリはVue2で使い続けたい
新しいアプリはVue3で作りたい
こういう場合どうするのがいいと思う？
Webpack使ってます
npmの環境もう1つ作っちゃうのが楽な気がするんだけど
Vueの事はよく知らんけどディレクトリ分けてnpx使えばよくない？
React18にverupして、パフォーマンスが体感できるぐらい上がって満足
でもtypesも18に上げた途端3rd partyからエラーでtsignoreに逃げた…
>>220 なんでグローバルにインストールしてるの？
>>224 わかる
recoilのtypesがアップデートされるまで様子見してる
react学習中は「jsのFWやろ」って思ってると痛い目見るな。
全くではないがreact言語と言っても良いぐらい独特やね
>>230 自分もJSライブラリというよりはJSによく似たDSLという認識で勉強したらうまくいった
>>230 Reactiveにするための面白い仕組みが色々ある。という点以外は素直なJSだし、わりと素直なDOM発展形だと感じたなぁ個人的には
reactは見た目が気持ち悪すぎる
Vueは違和感ないのだが
でもvueは覚えることが多すぎる上
過去のバージョン含めてプロジェクトごとにスタイルが違いすぎて無理ゲー
vueもreactも覚える量は大差なくね
バージョンやプロジェクトごとに違いが多すぎるは非常に同意
プロジェクト毎に…はreact.jsも大差ない
フロントエンドは変化早いから諦めろん
VueとReactの両刀使いだったけどReactに集約しまーす
フロントエンドでいちいちあれこれ考えたくないし楽だよなあ
React使ってる方はスタイルどうしてますか？
僕はあれこれコンポーネントライブラリ試してみて、最終的にTailwind CSSに落ち着きました
Tailwindなんか良く使ってるな・・・
冗長過ぎだろｗ
気持ち悪いとか冗長だとか、感覚的な事ばかり言われてもですね
フロントエンドエンジニアなのにまともにcssを使えないゴミが99％だからな
cssはデザイナーの仕事と勘違いしてるアホしかいない
そんなんおめー、会社の規模と分業スタイルに依るでしょ。ってか大抵はCSSもそれなりに書ける。
フロントエンドエンジニアの99%とか主語デカすぎ
tailwind-cssは最近擬似要素もサポートしたから表現の幅が広がって使いやすくなったけどね
ぶっちゃけ何でcssを書こうがあんまり変わらないから好きなのを使えばいいと思う
css使えないからTailwind使うだと馬鹿一直線
modules、emotion、chakraと使ってきたけど今はtailwind一択やわ
TailwindCSSはクラスがほぼCSSのパラメータと一対一だからCSSわからんとむしろ使えなくない？ エアプかな？
tailwindcssはvscodeの拡張機能を使うとtailwind.config.jsで設定した自分のカスタムスタイルまでコード補完で表示してくれるのが好き
bootstrapでいいじゃん
カスタマイズもできるしダメな理由ないよな
ダサいのはカスタマイズできない無能の言い訳
そういう奴はどのcssフレームワーク使ったとしてもダサくしかならない
>>251 ギョームで使うなら無難だけど
面白味が皆無だから使いたがらない
デザインが関わる部分はデザイナーが作るからどんなの使ってても良いけどね
管理画面とかそういうのはbootstrapで簡単にそれらしい見栄えにしている
管理画面すらデザイナーがモック作ってくれる場合もあるけどね
何せ面倒くさいのは最初にhtml考えた奴のせい(´；ω；｀)
動的に効率よく文書を処理しようとしたらどうしても複雑になるよ
その上スタイルも入ってくるししょうがないかと
>>257 >>259 お前らが無能だからhtmlのせいにしてるだけだろ
自覚しろよ
UIって何をどうしてもツリー構造じゃね？
どうしてもHTMLみたいなインターフェースには成らざるを得ないと思うけど
xhtmlは論理的にツリー構造を表現しているけどhtml5はそうじゃないんだよな。
W3Cへの反発があったからといってもちょっとどうにかしてほしかった。
>>264 行き過ぎたセマンティックって印象よね
むしろ要素を減らすべきだった
HTMLはそこまでクソじゃない気がするけど
XMLはクソｗ
フロントエンジニアを名乗ってるくせにまともにhtmlとcssを扱えない
その上それはデザイナーの仕事だとバカにする
ゴミクソフロントエンジニア
仕事っていうのは役割分担をきっちりした方が効率よくなるんやで
ゴミフロントエンジニアの言い訳
つまりjsxとstyleComponentをデザイナーがやるってことだろ
うちはデザイナさんがお絵描きツールでコンポーネントの各状態ごとの見た目やアニメーションを定義して
それをバックエンドエンジニアが兼任でReactに落とし込む体制でやってる
フロント専任ってのは今は居ない
役割分担は大事だけど分けすぎると調整コスト増なのでほどほどに
仮にフロントエンドのデザインを担うならhtmlとcssで何が出来るのかぐらいは理解しとかないとダメなんじゃないの？
組めとまでは言わないけど組める前提の知識は必須じゃないかと
じゃなかったらレスポンシブなデザインとかムリじゃない？
デザインしましたって言ってイラレで出してくるデザイナーなら要らんわな
デザイナーがお絵描きされてそれをエンジニアがhtmlとcssで再現できるのか？ってこと
当然ながら以下をフロントエンジニアがやるわけだ
どのcssフレームワークを使うか
Atomicデザインの粒度によるコンポーネント細分化
コンポーネントの再利用設計
cssフレームワークのカスタマイズ設定
css変数定義
スタイルガイドラインの策定をcssフレームワークに当てはめる方法
それらのコンポーネント化
css詳細度による優先順位設定
コンポーネントを構築した場合の各コンポーネント親子関係の配置方法
配置によるz-indexの優先順位の影響
インタラクション設計
インタラクション実行処理
デザイナー指定のデザインによるcanvasによる描画開発
>>275 つまりあなたの言うフロントエンドのデザイナーって言うのは絵だけ作る人っていう意味？
そんな人需要ある？
食っていけないと思うけど
紙媒体のデザイナさんだって印刷技術のこと物凄く勉強してるよ？
html化までしてくれるなら後の事はなんとでもするけど
デザインしましたとか言って絵渡してくるヤツはマジ論外
月給5万くらいでいいならお絵描きするだけでもいいけど
>>276 おれは一度もデザイナーのことなんか言ってない
フロントエンドエンジニアはデザイナーなんかにhtmlとcssをやらせるなってこと
フロントにとってhtmlはコンポーネント設計〜jsx、イベント、インタラクションまでやるのにそれをなんでデザイナーにやらせるんだよって言ってるわけ
cssも同じ
>>279 いや、素のhtmlとcssを受け取ってフロントエンジニアjsxにリマッピングって工程で別にいいだろ
>>280 いや絶対にうまくいかない
ゴミフロント
→ htmlとcssがわからないからコンポーネントの作り方がわからない
→ cssがわからないからデザイナーから受け取っても配置方法によって崩れる
→ レスポンシブに対応できない
→ インタラクションが何かすら理解していない
→ 表示されるべきものが簡単に崩れたり消えたりする
→ canvasすら使えない
デザイナー
→ コンポーネント設計できない
→ jsx化されてから問題起きて聞かれてもわからない
→ そもそも動的インタラクションがjsの振る舞いによって変化することがわからない
→ 作りたいものがhtmlとcssでできるのかcanvasでできるのかわからない
>>281 いや、そもそもそんなゴミフロントに仕事なんてさせるなよ
そんなのに仕事させる方が大問題だよ
>>282 そもそもっていうか、フロントエンドエンジニアの募集してるんだがそういう奴らしかいないんだよな
だからフロントエンジニアはバックエンドエンジニアにバカにされるんだよ
>>283 そんなのいるか？
にわかに信じがたいんだけど
>>283 どこで募集してんの？
使ってる求人サイトがよくないんじゃないか？
そんなのいたとして何で採用する段階で分からないんだよwコーディング試験でもやれば一発で分かるだろうに
そんなのを採用する奴等が悪いだろ
このフロントエンドエンジニアに対する異様な嫌悪。これ、いつもの人でしょ。
>>284 >>285 エージェント使ってるからかなりの数のサイトで募集かけてる
ほんと使えない奴らしかいない
そしてエージェント側もフロントは少ない上に能力酷いといってる
>>286 まだ採用していないがな
>>287 バックエンドからみたら酷いのしかいないからしゃーないわ
まあバックエンドも酷いがそれより遥かに低レベル
本当にいるとしたらそんなの採用してる会社の問題だろ
まぁ嘘なんだろうけど
>>288 G〇enとかみたいな職務経歴概要を元にスカウト掛けれるとこで求人した方が絶対いいぞ
エージェントはホント使えんから
スキルのある奴が行きたいと思う会社じゃないってだけだろ
自分は有能だと思うなら転職すりゃいいじゃん
何かキモいのが湧いてるのかｗ
プログラマがデザイナーの作業をやれるほどデザインに優れている訳無いやろｗ
それならデザインの専門家なんて要らんやろｗ
落ち着けよw
お前らがhtml（笑）とcss（笑）すらまともに扱えないって言ってるだけだからな
デザイナーがデザインしてもそれをhtmlとcssで再現できないほどの能力しかないのにフロントエンドエンジニアを名乗るなって言いたいだけだ
また話すり替える
お宅の会社の問題をエンジニアのせいにするなよ
自分が描いた絵のCSSコーディングするならまだしも他人の描いた絵をなんでイチイチCSSコーディングしてやらなあかんのやって話
そんなんなら最初から頼まんわ
ここってWeb系の人しかいないの？
うちはSIerだからかフロントはデザイナーに丸投げするからそんなに凝らないけどね
>>294 世の中の自称フロントエンドエンジニアに言ってる
>>295 自分ができないのを他人のせいにするなよ
>>296 デザイナーにReactやVueやらせてんの？
お宅の会社の下請けすごいね
htmlとcssすらまともに使えない自称フロントエンドエンジニアが図星突かれて誰も反論できなかったな
まあ少しは学習しろよ
マジで恥ずかしいわ
人の話聞かずに一人で勝利宣言する、いつもの人だった
最近話題になってたストローマン論法か
流行を追いかけてんね
たぶん20年ぐらい前から知識のアップデートが止まってて
デザインと1ピクセルのズレも許せないみたいな前時代的な世界で生きてる人なんだろ
今時htmlやcssはバックもフロントもデザイナも関係なく程度の差はあれ必要な共通言語なのにその辺もちょっと理解できてなさそうだし
今更すぎるがデザインとロジックを厳密に分離する事はほぼ不可能
双方の歩み寄りと努力が大事やね
>>305 だよね
まぁ昔に比べたらウェブデザイナに求められるスキルが増えたよね
それは他の人もそうなんだけどそれに取り残された人がネットで発狂してるんだろね
デザイン絵だけがデザイナの仕事って人も現実的に知ってるし
常日頃のキャッチアップ大事ね
>>304 おまえみたいなアホの分析が見当違いすぎて哀れみを感じるわ
一生htmlごときで苦しんでろ
この手のおじさんはおだてられるか煽られるかで上手いこと使われてあわよくば使い潰してバイバイされるんだと思う多分。
多人数チームで上手く立ち回れなさそうだからこなせる仕事の規模が頭打ちなんじゃないかな
おじさんとかチームとかどうでもいいんだよ
チームうんたら関係ない話をして反らすな
お前らフロントエンドエンジニアを名乗っていながらhtmlとcssをバカにする割には使いこなせていないのが問題なわけだ
それを俺のせいにしたところでお前らの酷い低品質のhtmlは改善しない
デザイナーガーとなぜかデザイナーに押し付ける
デザイナーはせいぜい軽くデザインするだけでいい
イラレで十分
そこから製品としてのフロントの設計をするのがお前らの仕事なのに無能すぎてhtmlすらまともにつかえない
そこにcssが入るともうお手上げ
生まれつき視神経が腐ってるのか脳みそが退化してるのか知らんけどデザイナーが指定したUIをまったく再現できない
レスポンシブもわかってないからブラウザサイズ変えると崩れる
もう才能ないからフロントやめろよw
どんだけゴミしか掴めないんだよ
一人だけ別世界で草
イラレでどうやってフレキシブルなデザインすんだよw
どこの世界線よ
>>254 寧ろ業務以外ならJS F/Wホントに使うべきなのかちゃんと再考した方がいいんじゃないかとね
要員通し仲良くやってもらわないと全体の進捗上がらないじゃん。
どんなにデキるやつでもその能力で全体の進捗を上げられないなら現場では退場仕方なし
NextとかGatsbyが使われたサービスでpagespeed insightsとかLighthouseのスコアがいいサービス知ってる？
故人ブログとかポートフォリオサイトレベルならだいたいスコアめっちゃいいけど、showcaseに載ってるサービスとかのスコア見ると70点以下ばっかりなのよね
>>316 GatsbyのメルカリとかNextのクックパッドはクソ低いな
んでどっちも「不要なJS削除して」みたいな内容のメッセージ出てる
これはフレームワーク使う以上どうにもならんもんだな
IEのサポートのためにJSが肥大化してるから、IEのサポートが切れた今後は改善されるとは思う
そいやnodejs18への対応てそれぞれどうなん？
npmとかサックリあげられるん？
今週vueを触ってみた感触…なんでコンポーネント間のデータ受け渡しだけでこんな面倒くさいのよ
>>321 個別コンポーネントの上位スコープの変数が欲しいなら
グローバル変数でも使えば？
>>321 コンポーネントに必要なデータ渡せばいいだけやん
v-modelで双方向バインディングが必要なデータを渡し
単にパラメータを渡すならそのまま渡せばいいだけだし
何が面倒なのかが分からんわｗ
あるコントロールの構成が
5階層ぐらいのツリー構造の外部コントロール群から構成されるなんてザラだから、
確かにバケツリレーな実装は面倒だ
>>323 おおありがとーvuexいれたら楽になった気がする
ただバージョンによってお作法結構ちがうのね
vuex前提はしんどくね？
コンポーネントは上位から貰う事を鉄則としているわ
まあプロジェクトによるよね
参照するObject次第だし
直近の親コンポーネントから渡したいだけならprop的な方がいいし、
同じ階層の親も子も複数とかならvuexが便利やろね
バケツがデータの変化を追うのにいいとは思ってるけどjwtのトークンや認証したユーザー情報やら共通的なデータをコンポーネントを遷移させる都度引き渡しするのに面倒だなとというのと親に値を返すときのイベント駆動がいまいち慣れないってのがあって愚痴ってたのよ
まだはじめて数日なんで上手い方法を知らないってのが問題なんだけどね
vueのコンポーネント間の連携は普通にクソだと思う
認証情報とかってAjax発行したりするVuexのactionsの中でだけ使うようにすればバケツとかイベントで悩む必要なくない？
まあ、そうだわね
個人的にvueは、vuex、router、vuetifyあたりはデフォで取り込んどいてくれればありがたいのにな、とは思う
てかvuetifyのvue3完全対応はよ
Reactコンポーネントのdynamic importがこんなに簡単だと思わなかった。きっちりLazyで、初めて表示されるまでロードされないし
Reactを触りはじめた
reduxだけで全ての状態管理を行おうとして一度詰まったわ
ケースバイケースでcontextの状態管理を使うようにしたらあっさり設計が改善された
しばらくこれで開発を進められそう
reduxめんどすぎる
contextで何が悪いとひらきなおる
ContextでviewModelを共有して快適になった
>>336 Recoil使え今どきReduxとかレクチャーしてる所は時代遅れ甚だしい
RecoilはFlutterのProviderみたいに使えそうだから個人的に気になってはいるんだけど
まだ破壊的な変更がありそうで怖い
ちょっとRecoilを触ったらいきなりフレームワーク特有のバグを踏んだ・・・
まだ早いなこれ
recoilはbooleanのステートを管理するのが苦手なのかな
いまbooleanのステータスを外部関数で変更しようとして詰まってる
Recoil扱えないレベルならjQueryにしとけ
おれのばあいatomとuseRecoilState(Value)でだいたい事足りるから
recoilでよほど難しいことしてるのかなって感想をもった
便利にするつもりなんだろうけどどんどん面倒くさいことになってるなあ
それぞれの思想やらお作法やらあって純粋にうわもののAP作るより手が掛かる
Recoil結構ずっと使ってるけどRecoil固有のバグに遭った事はないな
RecoilでダメだったものはReduxでもダメでそもそも別のReactコンポーネントの配置構成の問題ならあったけど
色々UIライブラリ使ったけどメンテまで考えると使わないのが一番楽な気がする
Reactだとない物は自分で作ったほうが早いし色んな意味で安全
流石に週間時刻予定表とかは作りたくないんだけど、そういうのも？
具体的にはreact-big-calendar
そういうんじゃなくてmaterialとかBoostrapとかのことね
>355
俺だったら自作する代表例
機能が多くて具体的なライブラリほど満たせない要求が出やすくかつ出た時に困る
Vue3.2使い勝手がよくなったって聞いたけど3.2対応のドキュメントって全然充実してないね
2でも説明足りなかったけど3になったらコード追わないと分からない部分増えたよね
そこで見限ったから現状は分からないけど
reactに比べたら桁違いにユーザー数少ないししょうがないよね
>>360 Vueはユーザー数多いとは一体なんだったんだろうな…
Cakeが2から3になった時に誰も使わなくなったみたいな感じになるのかな
Vue一本でやってきた奴が乗り換える先がないからそこまで極端にはならんかもしれんが
vue3はvue3で使えるよ
まあドキュメント少ないていうか、
webだと2も3も混在しててググラビリティ低いのは実感する
この板でvueをやたら下に見る人がいるのは変わらんわね
>>363 3.2で劇的に生産性が上がったみたいな例はみたんだけどそれ以外の体系的なところ探そうとしたら
公式みても古い書式だしどうすんだよこれって感じ
検索すると中国語ばかりで色々と先が思いやられたな
Vueの良さってのも分かるんだけど「合わない」ってのが率直な印象
俺の知り合いVue2ずっと使ってるわ
新サービスにも2を使ってる
早くもレガシーになってる
だからReactにしとけってあれだけ言ったのにアホたちがVueを押しまくるからこんなことになったんだよ
トップダウン設計が苦手なジャップにはReactよりVueの方が馴染みやすかったんだろうね
Vue.js 超入門 v3.2対応: 最初に手にしてよかった本 (技術書) 5/6
タイミング良すぎでワロタ
>>371 こんなPDFアップロードしただけっぽい同人の本みたいなもんよく見つけられたな
Vueはまじでどこに向かってんだろうな
Angularの良いとこ取りで始まったはずなのに今はReactの後追いやってるし
シンプルなまま、今のSvelteポジを狙っていればまだ将来性はあったんだろうなー
海外はむしろreactからsvelte,vueに向かってるのに日本人って英語の情報取りに行けないから遅いよね。
Reactのつらみわからん奴らがvueよりもreactの方がわかりやすいとか言ってるの見てほんと笑える
Vueオワコン言ってる奴はrailsオワコン言ってるのと同レベルの現実見れないアホ
>>374 中華ライブラリ特有の全部盛りに向かってる気がする
めちゃくちゃ楽にやりたいだけならsvelteでいいわな
vanilla.jsの延長として書きやすい
>>381 同感
Reactのような無駄なことをしない分
軽いよね
ロシアのせいでOSS依存へのリスクが無視できなくなりつつある
依存レスかつオールインワンなフレームワークが欲しい
だれか作ってくれ
ちなみに、Vueのモチベーションは
「Angularの本当に好きだった部分を抽出して、余分な概念なしに本当に軽いものを作る」
>>372 入れ替わりの激しいものはAmazonで日付順検索が鉄板だからね
>>375 Svelteはどこまで行ってもサイト向けだしどっちかというとjQueryとシェアの取り合いだろ
ReactからSvelteに移るヤツは初めからReactに向いてないものをReactで作ってただけ
俺は普通のサイト=svelte
ゴリゴリのSPA=React
こういう使い分けをしてる
割といい感じだよ
svelteは既存のサイトに追加するのも楽ちん
Vueって最初は確かに軽いAngularって感じでいいなと思うんだけど
だんだん公式の散らかり具合のほうが気になってきて逆にAngularのほうが楽じゃね？って気がしてくるんだよな
>>390 わかる
同じレベルの学習コスト払うなら今やangularの方が良い
＞Svelteはどこまで行ってもサイト向けだしどっちかというとjQueryとシェアの取り合いだろ
えー
というかSPAで作るもの自体普通のサイトレベルだとおもってんだけど
ものすごいのSPAで作ったことあんの？
個人的にはvueで取りあえず間に合ってるし新規開発者にも教えやすいし
少人数のプロジェクトで少し手伝って貰うみたいなケースでは
今まで出来ないから直ぐにクビみたいなのは無かったな
まぁ、外れの技術者が来れば出来ないのだろうけどｗ
reactにしたら多分こううまくは行ってない気がする
>>393 wappalyzerでサイトとかサービス見てみたらいい
大手のサービスとかサイトとスタートアップのサービスはかなり使ってる
>>384 それはOSS特有の怖さではないよね。それにOSSならフォークも可能だからむしろリスクは低い。ある意味ではプロプライエタリのほうが怖い
>>398 そだね
外部依存のリスクと言ったほうが正確だ
なのでフレームワーク自体が外部依存しておらず、フレームワーク以外の外部依存に頼らなくても快適に開発できる
そんなオールインワンのフレームワークが信頼のおける組織から出てほしい
Webの場合そうはないけどソースコード非公開の個人製作のヤツが一番ヤバイけどね
Pythonみたいによく使われるモジュールが言語に標準装備されてれば良いんだろね
node界隈の混沌とした状況が原因じゃねーかな
JavaScriptのようにPythonコードをHTML内に記述して実行できる「PyScript」 Anacondaがオープンソースで公開
https://www.itmedia.co.jp/news/spv/2205/09/news161.html もうJavascriptは要らなくなるのかもな
WebAssembly上でPythonインタプリタを動かしてそのガベージコレクションもしてそれらと各モジュールを読み込んで重くて遅くてデメリットだらけだからでしょう
今後もほとんどはこれまで通りJavaScript＋WebAssembly (by RustなどGCなし事前コンパイル言語) のままでしょう
Wasmの話になると必ずGC遅いマンが現れるけどJavaScripにはGC無いんか？
Wasmだと言語のランタイムごと実行バイナリに収める必要があって、GCがある等でランタイムが大きな言語はバイナリサイズが大きくなるし効率も悪い。JSの場合はブラウザがランタタイムを持ってて高効率だしサイズも小さくて済む。
Wasm自体が将来GCを持つという話もあるけど、各種言語のGCとは仕様が異なるのでランタイムは作り直しになるようだ。
それはそれとしてPythonが優れてるのはライブラリ周りであって言語としてはJS以下だから使いたくない（個人の感想です）
まあブラウザでpython使うメリットは何もねーわな
Pythonインタプリタ言語の癖して型変換書かなきゃいけない辺り不毛
>>409 ニッチ過ぎてちょっと使い所が分からないよね
想像力が足りないのかも知れないけど
pythonなんてマジで書きたくないわｗ
こんなのでサーバーサイド書くぐらいならRubyで十分だろｗ
どっちも使いませんがｗ
機械学習のデモとかでは結構使えそう(わざわざJSで書き直す必要がないから)だなって思ったけどここだとあんまり望まれてないのかな
結局のところ自分の仕事範囲でピトンが抱え込んでる高度なライブラリを使いたいか否かで意見が分かれる
そもそもインタプリタをemscripten通してコンパイルしてる時点で論外でしょ
どんだけランタイムでかいんだよ
>>415 科学計算とか機械学習の計算をクライアントで実行する案件ってのが思い浮かばないんだよね
wolframalphaとかの計算サイトとかnotebookのような実行環境とかそんなんしか思い浮かばない
フリーランスに立ちはだかる「常駐」の壁。慣例を打ち壊し、
“テレワーク”案件3割→8割へと成長を遂げた「クラウドテック」の軌跡
リモートワーク求人専門サイト「プロリモート」がリニューアルオープン、
業務委託契約の求職者と企業をマッチング
1/3以上が採用につながる高マッチング率、リモートワーク×エンジニア・デザイナー専門の
人材紹介サービス「ReworkerAgent」正式リリース場所からも時間からも自由な働き方を実現！
『ReWorks（リワークス）』リモートワーク特化型転職サイトとして 3月5日 リニューアル
副業・兼業マッチングサービス「クラウドリンクス」登録者数2万人突破
中小企業で進む副業人材の採用、96％が継続採用を希望
茨城県日立市、県外からの「テレワーク移住者」に最大151万円の助成金
長野市、市内に移転・事業所設置し、移住することで最大550万円の支援金を支給
フリーランスが活用できる「最大1,000〜3,000万円・補助率50%〜75%」の
『ものづくり・商業・サービス補助金』とは？概要や条件を解説
>>415 その用途だとTensorFlow.jsあるし、機械学習系のC++やCUDAで書かれたライブラリは流石に動かないだろうからね……
もうjavascriptはオワコンだろ…
フロントエンドはPythonフレームワークのPeactとかPueに置き換わる日も近い
PyScript面白そうではあるけど…まぁひっそりと消えそう
なんかあとひと押し足りないって気がする
なんなんやろ
ぶっちゃけパフォーマンスだけが課題
これが解決すれば後は好みの問題になるから
pythonってshやbatみたいに仕方なく使う言語だと思ってたけど、好きで使ってる人いるんだ。
>>423 Python製のクライアントフレームワークが無いからじゃ無いかな
比較対象が無いので評価出来ない
>>425 ウチだとバリバリ使ってる
っていうか現実的な選択肢がPythonしか無いっていう分野
もちろんバックエンドのみだけど
>っていうか現実的な選択肢がPythonしか無いっていう分野
そういう状況を言ったつもりだけど
大体のところCライクじゃない言語は一般には流行らない
言語変えた程度で何が変わるの？ってのが正直な感想
まさかDOMが生まれ変わる訳でもないし
非同期が同期になるわけでもないし
英語でミーティングするか日本語でミーティングするか
箸でプリンを食べるかスプーンでプリンを食べるか
その程度の違いはあるかもね
jsもpythonもクソ！って思ってる奴は割といそうだけど
jsはクソ！python最高！って奴はあんまりいなさそうな気がするんだよな
完全にイメージだけで言ってるけど
JS（及びTS）はそんなに（罠は多いけど）悪い言語じゃないんだよね。
積極的に乗り換える必要がない程度には
pythonの方が普通の人は使いやすいよ
当たり前だが
YouTube で有名な、雑食系エンジニア・KENTA のRuby on Rails 初心者用サロンでは、
キャリアパスは、Rails → Go だけ
Python は、プログラミングの技術で転職できないから、絶対に教えない。
サロンに転職できない香具師ばかりが残って、サロンが崩壊するから
文系で、プログラミング・Linux, Docker, AWS だけで食っていけるのは、Rails, Go だけ。
PHP, Scala は、KENTAがオワコン認定して滅んだ
Pythonは理系で、大学院数学科・AWS 機械学習 Specialtyの、2つの資格で決まる。
だから、KENTAが文系プログラマーに教えない。
教えても転職できないし、そもそもプログラマーを求めていない
typescriptを触りはじめたばかりだけど
nullとundifineの違いがマジで気持ち悪くて困る
初期化の段階では気にならないけど、
返り値の型指定で、voidとnullを分けなければいけないのは草もはえない
javascriptに戻せばこの気持ち悪さから目を背けられるんだろうか
undifineとか書いてる時点で誰も聞く耳持たんよ
まあ気持ちはわかるよ
tsって静的型付けのために動作上は不要なコードを付け加える作業だからな
書き心地が良いはずもない
TSは推論あるしわりとラクだけど、例外処理に関しては全然役に立たない哀しみ
もう新たな言語つくってくれ
なんで誰も作らないのだ
それはGoogleがDartで通って失敗した道だし、完璧な言語なんてものは存在しないから何度も作り続けることになる。
それにJSは言うほど悪い言語ではない
TSのターゲットがwasmになればJSへの配慮が不要になってもっと色々面白い事ができるはず
乱立してたのはconstもなかった時代だろ
今はそこまで悪くはない
AltJSは今TS一強だし、そのTSも以前とは異なって型付け以外はJSそのものだゾ
>>440 それはTSに限らん話かな。
そもそも例外機構自体が静的型付けと相性が悪い。
>>448 なるほど。
エラー出うるとこはすぐ拾ってT | ErrorとかEitherにするのが無難か
オレオレエラー処理ルールは止めたほうがいい
例外はほんと弱いからランタイム型情報ほしいね
今日初めてTSで例外処理を書いた
anyで型チェックした例外の、あるかも分からないcodeプロパティで例外の種類を
判別するという気色悪いコードを書いちまった
一応、hasOwnPropertyで、error.codeがあるか否かチェックはしてるんだけど
こんな感じで正解なのかすごく不安
てか、TSを入れて型チェックしても、こんな汚い例外処理を書かされるなら
何の役にも立たねーな・・・。JSに戻そうかな
>>451 例外の型にclassを使ってinstanceof
はい！終了...
オプソライブラリに例外に関するドキュメントが無い時に困る
ソース解析とデバッグで調べてるけれど信用できる仕様書が無いと無断で変更されそうで不安
例外の型なんて精々リトライ可能かどうかの判断とデバッグくらいにしか使わないんだから、そんなに厳密に扱う必要ないんだよ
多くの人に使われるようなオプソライブラリを作るレベルの人はそのへんの匙加減をよく理解していて、
いちいち例外を全部場合分けして個別に作り込みをしてるようなドカタレベルの開発者とはだいぶギャップがある
>>456 俺も昔はそう考えてたけどUXを考えるとそうも言ってられん
プログラミングはエラー処理が大半ってよく言われるけど本当にそのとおりだった
面白くない部分だけど品質を上げるためにやらないと
そもそもTypeScriptもそう長く続かない
こんな所詮トランスパイルするだけのものが永遠に使われる訳が無いし
ネイティブはjavascriptで変わらないのだから
そうだね
ブラウザが静的型付け言語を直接実行できるようになったらあっという間に廃れるね
jsより先にポイ捨てされるならtsってなんだったんだろうな
苦労しながら型書いてたのは保守性のためだったはずなのに
>>457 品質を上げるために例外の型を細かく区別することが必須というわけでもあるまい。
そのアプローチでやろうとしたのがJavaの検査例外なわけだけど、結局それを
きっちりやるのは困難なことがわかってきたんで最近は例外の型に依存する
設計自体が避けられる傾向じにあるんじゃゃないかな。
>>462 問題は実行時型情報の欠落とドキュメント不足で静的検査の有無ではない
>>448 本質的問題はそこだね
だから最近のプログラミング言語であるGoやRustは例外機構try/throw/catchを廃止した
>>449 GoやRustはその方式だね
Goはすべてタプルで返し
Eitherに相当するのがRustだとResult<T, Error>型であとは有無を示すOption<T>型
Rustの「?」オペレータが絶妙でエラー時に即時に関数を抜けてくれて例外のようにエラー処理を上位関数に集められる
>>462 別に例外すべてを細かく切り刻めとは言わないけど
ログイン処理実装などのように、例外を細かく刻まないといけない部分はどうしても出てくる
fetchがPromise生成してくれてResponseのメソッドもPromise生成でcatchでサクッと例外処理できるのはほんとに良く出来てると思う
>>466 こんなもんなのよ。
の世の中の問題って！
>>463 何か勘違いしてないかね。
たしかにTSはJSに対して型情報を埋め込んだりするようなオーバーヘッドは生じさせないと言っているが
それは実行時に型を判断できないという意味じゃあない。
nominal subtypingな言語だとコンパイルで型名が失われたら型が判断できなくなるから、あえて
「実行時型情報」として保持させてやる必要があるわけだが。
>>469 いやTSもJSも実行時に型は判断できないよ
オブジェクトが特定の条件をみたしているか判断してるだけ
これは酷く脆いやりかたでだから>455のような事故が起きる
例外に対処するためのcatchブロックで間違えやすい設計になっているのはちと問題だね
そもそもID:Iqge52I10はTSに何を期待して採用しようとしたのか気になる
まったく見当違いの期待をしといてTSはダメだ！役に立たん！と言ってるように見えるが
>>470 >オブジェクトが特定の条件をみたしているか判断してるだけ
それがstructual subtyping的あるいはduck typing的な型なわけだが。
>>455はinstanceofにnominal subtyping的な型の保証を期待したらそうじゃなかったというだけだろ。
実際にはプロトタイプチェーンしか見てないわけだし。
JSに型なんて期待し過ぎ
そもそもが型とは正反対の言語だ
このポンコツ言語をなんとかして実用に耐えるように矯正してるだけにすぎない
本来ならTSスレで話すべき内容なんだろうけど、ワッチョイ無くてあっち機能してないからなぁ
思ったよりマイナー言語なのかね
TSスレは過疎化がひどい
型付けは便利だし手放せないけど変に意識高い系の人が入ってくると面倒なことになりがち
TSは型チェックやトランスパイルの速度がこれからすごい早くなるから
開発環境はさらによくなってオススメされるのでユーザー数は増える
TSもJS互換だし仕様がカオスすぎてワイは頭抱えながら格闘してる…
ESLintって必須プラグインになってきたのは良いが、あれダメこれダメが多すぎる
リテラルと...だけは本当に便利なのであらゆる言語が模倣すべき
頭のいい人がなんやかんやと新しい思想いれたりお作法作ったりしてくれてはいるけど
その度実装してるみんなは右往左往して余計な稼働くって世の中発展を妨げるのは実は頭のいい人達の優越感のせいなんじゃねと愚痴りたくなるほどゴロゴロ仕様がかわるのは完璧して
jsの話ですらないけど初見演算子のなんてググればいいかわからない問題ってどうしてる？
「言語名 演算子」で地道にググるか公式ドキュメントの演算子のページを探す
>>482 EslintはAirbnbとか使わないで最小でやるのが良いんじゃ無いかと
そもそもスケールするかどうか分からんプロジェクトをガッチガチに固める理由がない
TSがどうこうというより、動的型付けの型チェックぐらいもっと手軽にやりたい
googleの賢い人たちに期待してる
型は複雑なものだしTSはMSのレジェンドが生み出した言語だゾ。
マジレスするとSuperstructとか使えば？
>>491 TSには現在進行形でお世話になるよ。これがないとJSはnullが怖い
あとSuperstructを教えてくれてありがとう
調べてみるぜい
勉強中の身なのですがtsを使う理由ってこんな感じでしょうか
理解や用語が誤っていたらご指摘ください。
tsを使う理由（サーバーサイド）
tsは型を厳密に定義することができるのでサーバーサイドでの利用、特にドメイン層でのビジネスロジックの記述に適している。
tsを使う理由（View）
サーバーも同じ言語を使うことで、サーバーで定義したモデル（レスポンスモデル等）をViewでも定義するという二度手間がなくなる。
ただしView側でtsでビジネスロジックを記述すると、利口な UI アンチパターンになってしまうので注意。
>>493 TypeScript検定でも受験すんの？
かと言ってPHPやPythonはアレだし、JavaやC#はアホみたいにメモリ食うし、Node.jsで（fastifyとかで出入り口をガチガチに固めれば）良いじゃんってなることは結構ある。比較的簡単にスケールするし、クラウドでも大体使えるし。
まあサーバがJSTSであるメリットは、
フロントと言語が共通しやすくなることでの総合的な学習コストの抑制がメインやろからね
仕事なら各予算とかパフォーマンスとか、要件に合わせてちゃんと多角的に評価すべきだとおもうよ
共通っていうほど移植性ないでしょTS
逆に混乱するから別言語のほうがいいと思うよ
移植性は関係ないんじゃね。単に環境や知識が一本で済むというだけ。
論点はほかにもあるだろうけどそのへんは要件に照らして個別に判断する話であって、
そういう前提なしに
>鯖でtsはないかな
なんて断言できるもんでもないだろう。
>>502 動くもの動かないものが意外と違うんで一本で済むと思って始めると辛い
stringに生えてるメソッドですら環境依存
そもそもフロントとバックって書き方もアーキも勘どころも依存先も違うんで言語だけ合わせてもって感じ
>>500 ほんまかと思って数年ぶりにjava書いたけど普通にNodeの倍以上メモリ食ってた。
AtCorderはたくさんVM立てるから（forkとかかな？）なんか設定が違うんじゃないかな。
とはいえ思ったより食わなかったので、バカ食いは訂正します。
バックもフロントもコード補完と型安全性、型情報によるドキュメントの補完を目的としてるな
バックでts使った事ないけどapiのスキーマの定義はopenapi使ってれば他の言語使ってても生成できるので二度手間にはならないよ
あくまで学習コストが低いくらいや、とワイも思う
まあドキュメントとかも少しは節約できるかもくらいかな
社内にJSTSのコミュニティがあるとかなら十分検討に値するんじゃね
会社なんて千差万別なんや
継続的に開発するならなんでもいいけど
リリース後は放置するようなものだと、問題が出たときに久々に見てもなんだっけこれ？にならない楽さはある
フロントからJSが駆逐されたらそれも通じなくなるだろうけど
いまどきの学習コストは言語自体よりライブラリやらフレームワークの占める領域がな・・・
言語を揃えてもコスト削減効果は限定的な気はする
でもバックエンドが.netとかjava系でフロントreactよりnextのほうが学習コストは低いやろ
さあ？
それを比較できる根拠は何ももってないから肯定も否定もできないな
皆さんご意見ありがとうございます。
大体の認識はあってそう…？
ガチガチの業務システムになるので、サーバー側は堅牢な言語にしたいところですが…
>>505を読む限り、言語が別でも二度手間感はないのでしょうか
サーバーサイドに定義したレスポンスモデルを変更したら、自動的にフロントサイドも書き変わるのが理想ですね。
しかし意見が結構別れますね
フロントサイド、もしくはサーバーサイドしかやってない人は言語なんてバラバラでもいい
どっちもやってる人は一緒の方がいいってなるのかな
フロントエンド出身の人は同じ言語でいいじゃんってなりやすいし
バックエンド出身の人は鯖でJSTSとか氏ねよって人多いだろうし
JSはまあ論外としてTSしかできないならTS
そうでないなら別の言語でいいんじゃないの
TSのカジュアルさは場合によりメリットになりうる
がしかしJSから継承した多数の変な罠、変化の速い依存関係、低品質な標準・非標準ライブラリを持ち込むデメリットのほうが大きいと思うね
程度問題だな。
pythonやrubyのバックエンドなんてのも平気で存在しているわけだし。
>>511 そもそもこのスレでサーバサイドについて質問する時点で
回答にある種のバイアスがかかるであろうことは想定しないと
サーバサイドについて公正な意見が欲しいならそれに適したスレに行くことを勧めるよ
言語単体でどれがとはいいにくいかな
今時は何らかのフレームワークにのっけることになるけどフレームワークも複雑化しているから使い慣れたものを選択するケースが多い
でそこにマッチした言語を多用することになる
でこれまた使い慣れた言語以外は使いにくいなあと思うように…
>>501 やはりCとRustが圧倒的に効率的なんだな
ブラウザサイドはJavaScript＋Rust(Wasm)のハイブリッドが最も効率良いし
サーバーサイドはRustがクラウド等コスト最小にできるから
今後はJS(/TS)＋Rustの両者だけで最も効率良く行けるね
とりあえず要求要件まとめるのが最初じゃね
会社の得意言語が決まってるとかじゃなけりゃさ
ガチガチの業務システムのコア部分が何がしかのフレームワークで果たしていいのか、とかもあるやろ
ぶっちゃけ余程マイナー言語じゃなきゃなんでも書けるし、要件や現状にあったものを選ぶだけ。早まった最適化は無駄どころか後々の負債になりかねないからね
サーバーサイドはpython1択だろ
新規ならこれで間違いないよ
現時点でnextだのnuxtだの自前で運用するものではないぞ
どんだけコストかかるか
使ってないけど最近サーバーサイドでGoは流行り始めてるってのは何回か聞いた
フロントはVue.js 3、サーバーサイドはPHP
日本においてはこれが最適解だよ
なんで日本に住んでるのにReactとかいうどこの企業も使ってないライブラリ使いたがるのか理解できん
>>522 Vue2の時は悪くなかったけどVue3の日本語ドキュメント全然充実してないやん
弊社、退職済みの自称イケイケエンジニアがnodejsで業務システム作ったおかげで
負の遺産となってる
>>515 でもこの板って特定の技術のスレはあれど
アーキテクチャをテーマにしたスレがないんですよ
あっても過疎ってるんですよ
ちょうどこのスレでtsの話題があったので投稿した次第です
しかしサーバー、フロントどっちもやってる人はすくなそうですね。
うちは規模が小さいのでどっちもやる羽目になりそうなのですよ。
>>522 メルカリ、LINE、Yahoo、マネーフォワード、SmartHR、DeNAとreact(nextjsも含めて)をプロダクトに使用してる企業は枚挙に暇がないんだが・・・
>>511 両方やってるけどバックとフロントは言語ちがうね
フロントは使う技術そんなに変わらないけどバックエンドはプロジェクト毎に要件かなり違うから幅が広くなっちゃう
最初からnodeでやりましょうって決め打ちはしないかな
websocketをガッツリ使うならsocket.ioのあるtsがサーバーサイドでも一番！とか思ってるんだけどこの認識もしかして古い？
Pythonのswampdragonとかスケールしないって記事を見たことがあって
>>529 swamp dragonというかdjango自体があまり使われてない印象
今はfastspi一色かも
>>527 Node (JavaScript) がゴミだと言い張るあなたは何の言語を使っているの？
>>525 >でもこの板って特定の技術のスレはあれど
>アーキテクチャをテーマにしたスレがないんですよ
じゃあこの板自体がその手の情報収集に適してないということ
技術ブログとか漁ってみればある程度まとまった情報も手に入るかもよ
>しかしサーバー、フロントどっちもやってる人はすくなそうですね。
少ないかどうかはわからんけど、自分が少し前にやったのはVue+SpringBootで
選定と実装はひとりでやったよ
>>529 そんなもんJavaにでもC#にでもなんにでもある
あとWebSocketと従来のソケット通信は若干送信内容が違う
>>529 websocketだけならnodeでもいいけど
それ以外の処理はどうすんのよ
データベースやキャッシュなどのWebの根幹をなす処理をさ
nodeの不得意分野
最初に用件をある程度固めて、
それを実現できるフレームワークやライブラリを調べて、
言語は最後にベストなものを選択する
開発にかかるコストの全体の中で、言語の取得なんてかなり小さい
遅いしメモリ食うPythonをバックエンドなんかに選ぶ理由はないわな
>>511 >>サーバーサイドに定義したレスポンスモデルを変更したら、自動的にフロントサイドも書き変わるのが理想ですね。
かってに変わられたら困るですけど(´ω｀)
堅牢とか言ってる割にはなんか根底が矛盾してんですけど
>>539 開発中の話ね
項目名が変わったり、減ったりしたときに困らない？
i/f変わればいずれにしろその項目に対して適切な処理が必要というか作り込みになるから勝手にはこまるのでは
idlぽいものを双方合意で共有するのが現実的では
OpenAPIの定義で握ってるような開発ってどのくらい普及してんのかな。
うちは単にドキュメントとしてしか使ってないけど、あれデータ定義がjsonschemaだから冗長で大変なんだよな。
古くはWSDLとかSOAPとかあったけど、お手軽シンプルなRESTに滅ぼされたのよな
今でもSORPやCORBAが負の遺産で残ってるとこ多いね
Restに駆逐されて良いわ
Swaggerって実質的にWSDLの再発明みたいなもんでしょう
WSDLを安易に滅ぼさずに最適化し洗練させていけば
技術間の断絶が起きず移行コストを抑えつつ今と同じような形態に落ち着いたのではと思う
まあいまさら何を言っても過去は変わらんのだけど
>>541 自分は勝手に変わって、コンパイルエラーになる方が嬉しいわ
変わってることに気付かないのが怖い
リクエストやレスポンスに載せる要素を勝手に追加して送っても受け取る側がさわらなけりゃエラーにもならずそのまま漏れるケースがでてくるよ
ぼっち開発ならいいけど複数人でやるならコミュはとらんと
>>547 それで困るシーンがいまいちイメージしづらいな。
受け取る側で必要ないデータを勝手に追加しても使われないから別に問題ないんでは？
>>539が何をもって堅牢と矛盾してると言ってるのかようわからん
>>514 Rubyは一時期ゴリ押されてたからまあまあ多いだろうな
>>547 いやそりゃレスポンスモデル変わったことは通知するよ
でも人間がやることだから必ず対応漏れが出る
大幅な変更で対応漏れがあったらもうどうしようもないけど
ちょっとスペルミスがありました程度で対応漏れで値が表示されなくなるのはつらい
型安全な言語だと当たり前の感覚だけどスクリプトをやってる人にはピンとこないのかも
>>552 言語というか
フロントのみしかやらない人は、IFの変更があったときはバックエンドから通知が来るのが当然で、
通知が来なくて不具合が出たとしてもそれは通知しない方に責任があるというような考え方ではなかろうか
システムの形態によってはスマホアプリもあるだろうし、その場合はフロントとバックの言語が違うなんてのは当たり前なんだろうけど、
ブラウザのみの場合は極力フロントとバックの言語を合わせた方がメリットが多いと思う
メリットがあるのは理解するけどバックエンドの選定って運用とかにも大きく絡むから
開発の都合だけを押し通すわけにもいかなくない？
要件的制約的にどれを選んでも大差ないってときにじゃあ同じ言語にしとくかってのは否定しないけども
というかバックエンドは負荷が集中する箇所だから
小さい規模ならまだしも本来ならば
バックもjavascriptで書くなんてあほなマネは極力避けるべきだろ
だからフレームワークも運用も枯れまくってるRuby Python PHP Javaのどれかがベスト
バックエンド側を勉強する機会がない
クラウドファンクションの実装で済ませる機会が多くて…
>>555 一般的なRESTサーバーで負荷の集中が予測される場合、クラウドでも自前サーバでも一番気にしなくてはならないのはDBがスケールするか否かじゃね？
言語合ってくれるとバックエンドはフロントのこと分かりやすいだろうな、とは思うけど
合わせてくれとまでは思わない
それよりも優先すべきことが多い
てかまあスレタイとはズレていくな
それは逆だな
一般にバックエンドのほうが技術的に幅広く理解している人が多いから、言語が違ってようがバックエンド担当がフロントを読めないってことはまず無い
当たり前のことだし煽るつもりもないが、フロントの人の方がJSに拘る傾向は遥かに強い
バックエンドでも一つの言語や一つのフレームワークしかわかりませんみたいな人いるけどなぁ。本人次第過ぎる
なんかズレてんな
まあどこの会社のバックエンドが優れてる優れてないってのは様々やしな
今のフロントを理解できるバックエンドってのもなかなか貴重な気はしてる
だよな。実際、人材探してもフロント(SPA)できる人のほうが希少だったわ。
SPAやフロントなんてシステム全体からみたらデザイナーの仕事だからどうでもいいんだよ
フロントもバックもそれぞれ人材はいるけどspaするなら結局前後でデータ整合や認証関連、フロー制御の連携するために間に立って全体をみる役割の人材が少ない印象
>>566 結局フルスタック出来るか、それとも一部しか出来ないか、だよね
言語をどれにするかは独立した別の問題
システム的に許容範囲ならば全てをJavaScriptでも問題ない
逆にサーバーリソースコストが重要ならばスクリプト言語を使っていてはダメだし、
ブラウザ側も重い処理が入るならばJavaScriptだけではダメでWasm必須など
ここサーバーサイドjsは劣ってるって決めつけてる人いない？
表現力もライブラリも実用レベルだと思うが
速さの性能面に限っても、
V8のおかげでスクリプト言語の中でもJavaScriptは断トツに速いから、
他のスクリプト言語を使っていても大丈夫なサーバーサイドならばJavaScriptでも大丈夫
漏れは、NRI ネットコムのAWS Solution Architect Associate(SAA)の教科書で勉強しているけど、
データベースの基本は、マルチAZ
マスター・スタンバイ + read replica(参照のみ)。
Ruby on Rails 6 から、複数DB(read replica)にも対応している
YouTube で有名な、雑食系エンジニア・KENTA の初心者向けRailsサロンでは、
キャリアパスは、Ruby → Go だけ
PHP, Scala は、KENTAがオワコン認定したから、
Laravel を使っているZOZO も、もうダメ。
日本ではKENTAがダメと言うと、誰もその会社へ転職しなくなる。それで滅ぶ
Python, Django も、無理だと言ってる。
大学院数学科とか、AWS 機械学習 Specialty を持っていないと無理。
この分野はプログラミングに関係ない
文系がプログラミング技術だけで食っていけるのが、Rails, Goと、AWS SAA
KENTAだったか誰かは忘れたけど、
フルスタックエンジニアを名乗る香具師は、信用するなと言ってたけど、
KENTAは転職用に、Rails + Vue.js を推奨しているw
こういう書き込みをしてKENTAとかいうやつの評判を下げてる人です
バックエンドではTypeScriptは意図的に避けてる
エコシステムの変化が激しすぎるのと標準ライブラリの貧弱さが使用に耐えない
OSS文化は悪くないけど基本的な機能すらコミュニティ依存っていう無責任な方針はよくない
今後数年から数十年に渡って自分達のプロダクトと共存していくことになるパートナーとして信用できない
逆に言うとフロントと同じぐらい小さくて寿命が短い使い捨てのバックエンドなら別にTypeScriptでも良いと思う
うちはそういうの扱ってないんで選択肢に挙がらないけど
何するにも非同期とかnodeというかJSは終わってる
それはフロントエンドの発想
サーバーサイドは全部同期的に動くのがベスト
同期で動いていかに早くレスポンスを返すかを設計するもの
何やるにもコールバックかPromise連打しなきゃいけなくて地獄
サーバーサイドで非同期は余計なのよ
この感覚を理解できない人はサーバーサイドを理解してない
KENTA
未経験からのエンジニア転職の必須教養【技術知識編】
https
奇をてらって、Laravel, Django を選ぶな。
転職先が多い、Ruby on Rails が有利
AWS EC2 はオワコンだから、Fargate を使えとか、
CircleCI, Github Actions, Terraform,
Nuxt.js, Type Script
>>575 えぇ……サーバサイドでも非同期役立つやん……。仕組みからしてシンプルにスケールさせやすいし、DBの返答待つ間にできる処理回すとかもお手の物。
Promiseやawaitある現代JSでは非同期は簡単に扱えるし、Rustのactix-webとかも非同期だよ？
>>575 それは真逆
サーバーサイドは同期的にならない
様々なマイクロサーバー待ち、データベースサーバー待ち、ローカルファイルシステム待ち、など、これらを一つ一つ同期的に待つのは無駄だから非同期で並行処理させる
>>575 TPモニタですら非同期のAPI提供してきたのに…
>>580 だからそれがダメなんだって
そもそもそんな重い処理をしてる時点で論外
同時接続数が100なのか万単位なのかで全然話が違う
この手の話は具体的なケースを想定するなりして前提を合わせないと話が噛み合わなくて時間の無駄
>>583 >>580に対して「重い処理」なんて単語が出てくるようじゃ会話が噛み合わないわな。
本当にサーバーやってたのかすら疑わしい。
並列処理せずに素直に待ってろって事だろ
DBが遅いのは他の人が使っているからでその間に他の仕事をすると他の人がさらに遅くなりトータルでは悪影響しかない
あのーJsの非同期はrustのそれとは別もんです
まずそれを理解しましょうね
あとスレッド生成しないなら結局クソ重い処理をした時点で固まるんですよ
それが論外
スレッドにしてもスレッド生成のコストもバカ高い
データベース引くより遥かに重いことをやるメリットはなに？
Webサーバーの処理の中でやるとクソ重くなるというのはこういう意味ね
理解できたかな？
俺はプラグラミングモデルの話をしているんじゃない
速いか遅いかの話をしているんだよ
nodeが本当に速いならclusterモジュールなんかいらないのではないか？
>>588 用語の使い方からおかしい
まずは並列(parallel)と並行(concurrent)の違いを勉強しよう
ワーカーを持ち出さない限りJavaScriptのコード並行処理
そして並行処理であってもした方が速くなる
>>590 例えば重い(遅い)サーバー2か所からデータを引っ張って来ないと自分のリクエスト元に返せない重い状況であっても
同期的に直列に処理するよりも並行処理した方が明白に速くなる
同期処理は悪
>>590 データベースが行っている事はCPUバウンドな処理だけじゃないんだよ。
それにCPUのマルチコアやネットワーク、ストレージを並行に使えば速くなるじゃないか。スループットにもレイテンシにも利くぞ。
>>591 clusterモジュールがやってるのはマルチプロセス化だ。スケールアウトの要だし、速かろうが遅かろうが必要なものだ。
元が糞遅いものがマシになるって話してる並行派と、
そんな糞重いものをそもそも書くんじゃねぇよっていう直列派の醜い争いってことでいいの？
流石にIOバウンドでの非同期の必要性は理解できてるようだが
CPUバウンドの非同期については理解が足りてない
完全にCPUバウンドの処理AとBがあるとする
Aは終了までに100秒かかる
Bは1ミリ秒でおわる
多数のクライアントがABBBBBBB...とリクエストしたときを頭の中でシミュレーションしてみればはっきりわかる
シングルスレッドかつ完全に非同期だと全てのクライアントがAのせいで100秒待たされる
しかしここでAのアルゴリズムを変更しループ処理を分解して1秒に1回程度の頻度でawaitを挟むとする
するとAは1秒後にCPUを開けわたすのでCPUはAをいったん止めてBの処理を先に進めることができる
Bを実行したクライアントは1秒程度でレスポンスを得ることができるようになる
>>594 前提条件がズレてるから噛み合ってないんだと思う
まずクライアントに即座に結果を返す必要があるWebの処理では重い処理はしてはいけないのはその通り
重い処理はバッチ系に回すべきだし
そのバッチが並行処理というのなら並行処理は必要
分散環境での並行処理とプログラミング内での並行処理でもまた違ってくる
そういう意味でそれほどズレてはいない気がする
またフロントエンドはシングルスレッドでブロックする処理は厳禁
そういう環境で生まれたJavaScriptのPromiseとそれを元にしたrustのPromiseはAPIは似てるが実装は違ったりする
なかなか面白いテーマだ
この流れみるだけでnodeサーバーはやめとこってなるよな
>>595 あえて極端な例を出してるんだと思うけど、そこまででかい処理ならスレッドなり生成してOSにスケジューリングを任せるかな。
というか皆別々の単位で重い処理ってのを考えてそうな感じする。俺はms単位で考えてた。
>>599 まぁ一般的にはCPUバウンドが高価な処理は他のサーバーに振るよね
フロントではそのタスクの終了が通知されるのを待つだけの話
で、この重い処理をクライアントで賄えたら、ってみんな考えるけどこれはこれでなっかなか難しいんだよね
>>597 むしろNode.jsは好ましいものの一つと分かったはず
>>600 2箇所のデータ返すサーバーからデータを得てまとめてクライアントに返すといった普通の軽い処理の話だよ
Node.jsなどの非同期が楽に扱える言語で実装すれば並列に2箇所を待てるから軽くて速い
ID:UTxfnI1i0の主張がとっちらかっててようわからん
同期非同期、ウェブサーバでの重い処理云々の話から
>速いか遅いかの話をしているんだよ
はイマイチ繋がりが読めない
いずれのケースでもサーバーサイドはローカルファイルシステム待ちや他のサーバー待ちがほぼ確実に入るのだから
それらを順次処理しかすることが出来ない同期プログラミングは不利
並行処理することが出来る非同期プログラミングは有利
>>602 だね
node最高って言いたいだけなんだろうけど
>サーバーサイドはpython1択だろ
こんなこと言ってた奴がNode.js否定するんだから笑える。
ワッチョイあるから曲がりなりにもスレが機能するなぁ
nodeは完璧ではないだろうけどnodeが頭ごなしに否定される要件って生き残る言語がほぼない気が
なるほど、あのアンチ非同期の人はC10K問題を理解してないんじゃなくて、そもそも知らなかった可能性があるのか
そいやしらんけどangularにもNextみたいなのあるん？
例えば、画像のサムネイルを作るような、CPU セントリックな処理は、
直接、App・Web サーバーで処理しない。
他のサーバーへ回す
AWS Lambda では、
1. 画像をS3 へアップロードする
2. それをトリガーに、Lambdaが起動
3. 画像のサムネイルを作成
4. そのサムネイルを別のS3バケットへ追加する
これを、Ruby on Rails のActive Storage では、Image Magick, libvips を使う。
Appサーバーを経由しない、ダイレクトアップロードもできる
>>610 angular自体がnextみたいなものじゃないの？
>>608 俺の留守の間に好き勝手やってくれたようだな
仕事に忙殺されて見る時間がなかったわ
知ってないわけないだろ
むしろお前が今調べたんだろ
しかもそれだいぶ前だぞw
あと接続数の問題と「処理を捌ける」とは別物
全てが幻想の話なんだよ
後そもそもクラウド全盛時代に1台の性能や接続数を語ってもナンセンス
nodeが生まれた時代はクラウド全盛期前
アーキテクチャが古くても仕方ない
現に最近はC10K問題とか誰も言ってないだろ
nodeにやって解決されたわけじゃないぞ
ちなみにdenoでは非同期の利点などもはや一歳言っていない
むしろセキュリティとサーバーサイドをフロント側のWeb標準に合わせるという点を強調している
あと勘違いしてるようだが俺はnodeの非同期がクソと言ってるだけで
一般的な非同期や分散環境を否定してるわけではなく
むしろそっちはやるべき派
それは上の俺の書き込みを見てくれればわかるだろう
俺の書き込みに対して真正面から打ち返せない奴が何を言っても無駄だ
C10K問題を今更出してきたということはもしかして
nodeの非同期を知らなかったということか？
恥ずかしい
流石にそれ恥ずかしい
議論の舞台にすら上がってなかったのかよ
>>616 > 一般的な非同期や分散環境を否定してるわけではなくむしろそっちはやるべき派
> それは上の俺の書き込みを見てくれればわかるだろう
>>575 > サーバーサイドは全部同期的に動くのがベスト
> 同期で動いていかに早くレスポンスを返すかを設計するもの
嘘じゃんww
nodeの非同期が他とどう違って、それがどうして「サーバーサイドは全部同期的に動くのがベスト」に繋がるのかな？
結局顔真っ赤にしちゃって連続カキコでクソクソ吠えてるワンちゃんやんw
具体的に「こういうコードや設計や非同期がこうだめ」って言えないんだろw
最初からC10K問題が念頭にあったならあんなに「重い処理」にこだわったりしないと思うがな。
>>613 >あと接続数の問題と「処理を捌ける」とは別物
>全てが幻想の話なんだよ
？
ちゃんと意味の通る日本語で頼むよ
誰かが青天井でお金を払ってくれるならいいけどそうじゃないなら1台で捌ける数がどうでもよくはないよなあ
setupだとかreturnとか面倒くせえ
普及しないわけだ
新たに始めて覚えるあいだに古いやつで何本もアプリつくれるだろ
そうこうしてるとまた仕様をかえてくるループ
仕様は動かさないで下さい
こういった頻繁な変更がエンタープライズアプリケーションで使いづらくするのです
recoilを使うと非同期でステータス更新する時のステータス管理が楽だな
contextを呼び出す書き方は、どのメソッドをオーバーライドするか覚えておくのが面倒だわ
TSって意味ないだろ
型つけても速くなるわけじゃないし非生産的過ぎる
コード長くなって作るの遅くなるだけ
型推論あるから型をつけるのは（関数の引数やJSON等）データの出入り口くらいでそんなにコード伸びない。
生産性が落ちる要素は型エラーを消すべく型パズルに頭悩ませたり、バリデーションに気を使ったり、ビルドを組み上げたりする部分。
逆にインテリセンスや、厳格なコメントとしての型など、生産性が伸びる要素も多い。特に後から改修するときに凄く役立つ。
生産性は規模によるけど、悪くてもトントンで、むしろ上がる。
実行時エラーをほぼ消せるので枕を高くして眠れる価値はプライスレスw
あと地味にJSよりTSのコードの方が熟達者が書いてるケースが多く、玉石混交なネット上のソースを見るときに役に立つ。
トランスパイル環境作りめんどいからあえてjsのネットのソース使ってるわ
JSとTSだったらTSのがいいよ
あまり強力ではないけどいちおう型安全でインテリセンスも効く
>>628 作るサイトが大したことしないんなら要らないんじゃない？
TSに対応したよ！（TS版のドキュメントを作ったとは言ってない）
これがなければなあ
型のもたらす恩恵が分からないというのはある意味幸せなこと
フロントおじさんは別名consoleおじさんだから
20年前コンパイルできたのに不用品扱いだったのがJScript .net
どう見てもその矮小化版のTypeScriptなんてゴミに決まってんだけどな、今の若い子にはキラキラ見えてんだろうな。
>>636 ググってみたけど明らかにTypeScriptとは別物じゃん。JSを.NET向けに強引に矯正した醜悪な代物じゃん。当時のMSはこういうの多かったな
当時はなんでも～.netってのが出るのかと思ってた
何をもって「どう見ても矮小化版」と判断してるんだろうね
TSは型の足し算、引き算がUI開発にめちゃくちゃ良い
20年以上プログラミングやってるやつがこんな発言したのかと思うと、いっそ切なくなるな
昔から型書くの大変だから動的型付けにして書く量減らそうって流れだったのに逆行してるじゃん
型書いても結局周辺のコード見たり動作テストするんだから一緒だよ
型付けして動作が速くなるならまだしもそれすらないなら自己満感だけのオナニーコードだよ
賢者は歴史に学び愚者は経験に学ぶ
本当に賢い奴はJSを選択する
わざわざ余計なコードを書く必要はない。型付けはシステムに自動でやらせるべき。シンプルisベストだろ
動的型付けを否定するという事は自動化を否定するという事であり
システム自体を否定する事である
プログラム自体を否定するのと同じだ
型付け最高！はいつまでもオートマを否定しマニュアル最高！と言ってるようなもん
正直どっちでもいい
動的だろうが静的だろうが業務系システムで複数言語で動的静的両方で組んでるけどエラーなんて起こしたことない
型あり型無し好きなもん使えば良いよ。
ただ、型あり言語が自動化されてないってのは間違い。
型という情報をコンパイラやエディタに与えることで、自動でエラーを発見してくれたり、型演算で何が指定できるかを教えてくれたり、推論でそもそも書く必要が無かったり。少しの情報で色々自動化される。
一人で作る難易度の低い、使い捨てのツールならいいんじゃない？
逆に、ビジネスルールが複雑、複数人で開発する、寿命が長いシステムは型がないとしんどいだろ
ビジネスロジックが複雑なシステムは一般にバックエンドの比重が大きいから、フロントエンドの型の有無は実はあまり関係なかったりするね
バックエンドはTypeScriptだけどフロントはBabelなんてのも見たことある
しかしバックエンドとフロントで微妙に似て非なる言語を使うのは非効率なだけだしビルドパイプラインも無駄に複雑になる
現実にはフロントでのTypeScriptはBabelの代替として型緩めで運用されてるケースが多いんじゃないかな
型ありがいいです
ある程度のエディタなら静的解析効くってくらいのがいいです＼(^o^)／
実行するまでエラーわからないのはイヤです
型最高！とか言ってる奴は自分の書いたコードしか見てないだろ
自画自賛してるだけ
フロントの大規模開発でTSちゃんと書ける奴大量に集めるなんてそうそう出来ない
ってかフロントの大規模開発なんてそうそうないだろ
だいたい書く人は1人から3人程度で相当大規模でも対応出来る
>>656 つまり、TS使えるやつ3人集めれば十分って事？
>>656 型がわからないエンジニアばかりの空間って存在するのか？
型は大規模開発の必須要件だと思うの
TSスラスラ書ける奴3人なら結構色々出来るはずだけどな
そもそも狭い範囲を多人数でやり過ぎるのもやり難いからモノレポなりにして担当範囲分けた方が良いし
ますますTSの必要はなくなる
SvelteKitを345に上げたらstatic下のシンボリックリンクを読まなくなったので元のバージョンに戻した
バックエンドPHPでフロントがJS系なんて腐る程あるだろ
GOとPHPじゃ生産性全く違うし動的型付け選択なんて十分有り得る
TSは良いと思うけどビルドの蛸足配線だけはどうにかして欲しい
C#から多くを学んだようにdotnetからも学ぶべき
フロントの大規模開発ってページ数が多いだけだろ
ページがどんだけ増えようがデータとHTMLをマッピングするだけの単純作業なら複雑さは変わらん
もちろんSlackみたいなのを作ってるなら別だけどね
フロントの大規模ってDB管理ツールだとかVSCodeのようなイメージ
＞データとHTMLをマッピングするだけの単純作業なら複雑さは変わらん
悲しいなあ、もうちょい楽しい案件やればいいのに
せっかくこういうスレにいるのに
座標とか使うようなSPAの利点を最大限活かした案件もあるよ
実装が面倒臭いけど
大規模案件やってるが基幹システム作ってる
ページというよりコンポーネント設計だな
DBがかなり複雑でそれに合わせて画面開発
コンポーネント同士が連動しているからSPAは開発しやすい
バックエンドはJava
上の方でもチラッと出てたけどやっぱSolid書きやすそう
特にグローバルステートが簡単に管理できるのがいいね
> React大好き侍が、「もうSolidJSでいいじゃん...//」ってなったワケ。
https://qiita.com/shadowTanaka/items/b6d00863a8d6bff37de6 ＞//第２引数はありません。SolidJSが勝手に依存している状態を感知してくれます。
うーん
hookがトップレベルにしか書けないのと依存関係を明示的に書かなければならないのは大きな問題だなと思ってたのでそれがなくなるなら移行も有り
ただ不安なのはコミュニティの体力かな
hookがトップレベルで書けないのが問題って言う人定期的に出てくるけど、どうもピンと来ない。
全部入りコンポーネント作ったりとか大量の副作用とか使ってるん？
コンポーネント外で使いたいならRecoil使えばよくね？
reactのhooksは不安定な動作をする可能性のある副作用を制約をかけてトップレベルでしか書けなくすることによって、副作用の位置を明確にして問題が起こったときに検証がしやすくなることとリファクタリングをしやすくすることを意図してるんじゃないかと思ってた
色んな場所にhooksを書けるのは実装者からすると余計な事を考えなくて有り難い反面、バグが起こった時の検証が難しくなりそうだな
SvelteはVercel所属？だからコミュニティの心配はいらないかな
>>671 グローバルはjs側の機能の範疇で
Reactが提供する機能の範疇ではないのでは？
グローバルで事足りる要件なら
関数コンポーネント内から直接参照すれば良いだけの事
自分の案件でも普通にやってる
・オーバレイのz-infex管理など...
>>674 テストを書いたことがなかったり、チュートリアル規模しか作ったことがない人なんじゃね
Vueだけどメソッドいくつくらいからコンポーネント切り分けること考える？
マウスのホイールで往復してると、あ、やばいなと思い始めるわ
可読性だけが理由ならクソデカifelseが生まれたら範囲の把握が辛いから分けるかな
結構センス問われてる気がするのよね、ここら辺の話って
ルールがチームとかで決まってればええんやろけど
ちょうどいい規模のサンプルプロダクトとかあるんやろか
3箇所以上似たような処理が登場しはじめたら切り出すかな
atomic designに則って分割してるけど、手段が目的になってしまってる感が否めない…
atomicデザインの考え方に沿ってコンポーネントを分割すると、いつもtemplatesが上手く使えない・・
ヘッダーとフッターを組み合わせた奴くらいしか思いつかず、それ以外はtemplatesをすっ飛ばしてpagesで作ってしまう
アトミックデザインは何がなんでも同じ構造にしなければということもないと思うけどね
考え方は尊重して規模や複雑さに応じてアレンジする方が無理がないかと
今@vue/cli 4.5.17でVue2作ると
vscodeでブレイクポイントがずれまくりになるんだけど分かる人いない？
前にできてたときのsourceMapPathOverridesを
"webpack:///./src/*": "${workspaceFolder}/src/*"だと
ブラウザからみてみると違うソースになってるからそりゃダメだなーと
こうなるとよく分かんないよ
バージョンによらずズレたりズレなかったりそもそもブレークポイント張れなかったりでいまだにベストプラクティスにたどり着けない
上手く行かないときは諦めてブラウザ側でブレークポイント張ればいいやってなってる
pinia良いね
Recoilといい、脱Fluxの流れかな
普通のHTMLのページならVueやReactにするメリットがあまり感じられないんだけど
ユーザ体験も変らないしLaravel辺りで作った方が早くてメリットあるように見えるんだが
今フリーで単価70くらいなんだけど最近の相場ってどれくらいなの？
何年も同じ単価でやってるから最近の動向を知りたい
スキルは最近はフロントばかりだけどバックエンドも出来る
普通のHTMLページの定義にもよるけど、Next.js(React)でSSGとかISRするのもなかなか生産性良いよ。表示も速いし、柔軟性も高い。
SSGってイマイチメリット感じたことない
一過使ってみればわかるんかな
単価70って単位はなに？1人月70万円かなぁ？まさか1ステップ70円じゃあないだろうが。
うちは3年目くらいの若手の派遣に投げる仕事が月70万くらいだったな
技術あるならそれこそ100万150万取れそう
>>699 フロントでフリーなら月100万くらいが最近の相場って事？
>>700 エンジニアが受け取るのが70万であって企業側はもっと出してると思う
多分90万は出してる
そうすると1人月○万という表現ではないかも
フリー歴は7年くらいでバックエンド、フロントやらサーバーやらはだいたい出来る
>>701 フリーだとクソクライアントにはどう対処してるの？
最悪、損害賠償請求されるリスクもあるし
>>702 エージェントかましてるからクソには当たらないな
エージェントかまさないと金払い悪かったり色々面倒だよ
>>703 エージェントそこまで対応してくれるのか
>>704 エージェントによると思うけど良いエージェントならそもそも良くないクライアントは紹介して来ないと思う
自分のところで何かあると悪評が立って使って貰えなくなるからね
BtoBの相場でフリーランスがそのまま貰える訳ないやんｗ
100万とか言っても結局エージェントなり間に何か入るのだからそれで70万とかになる訳でｗ
直契約でも出来れば高単価になるかもなーｗ（ハナホジｗ
フロントのフリーの人あんまりいないのかね
最近人手不足が酷いと聞いてたから単価上がってるのかなと思ったんだが
>>707 単価と製品知識は連動しない。単に知識があるやつはむしろやばい。
solidjs覗いてみたんだけどどうせgetterに変えたんだからhooksに寄せた
const [state, setState] = createSignal(0);
じゃなくてsvelteっぽく
const state = createSignal(0);
参照 state()
更新 state.set(1)
にしてくれてたらさっぱりして良かったのに残念
いやそれはなんかJS的に気持ち悪い（個人の感想です）
ReactとTSの組み合わせはエンジニア殺しな気がする
出来ない事はないが無駄にしんどい
これで現場変えてる人結構いそう。Vueの方が採用されるケースは今後も多いだろうな
tsは規約みたいにルール作ってるようなもんだからなあ
慣れないと窮屈に感じるかもね
>>712 普通のところは型付けも問題ないけど
ReduxとかContextAPIとか外部モジュールとかの型付けとかかな
頑張れば出来るけどこれ意味あるの？感が凄い
>>713 ReduxとかContextAPIとか型付けして意味あるの？と感じるんだが
JSなら無い苦労してまで得られるリターンに見合わなく感じる
なんとなくVueよりReactの方がTSとの親和性がいいって認識だったんだけどそうでもないんかね
reactの方がTSへの対応が早かったぐらいの話じゃないの？
型なんてフロントエンドで別にいらんしTSなんか俺は一切使ってないけどなｗ
>>718 AngularがTypeScriptだから、Google社もマイクロソフト社もTSなら、TSが主流になるのはあたりまえ。
多分大きなプログラム組んで保守したこと無いんでしょ
TSはサーバーサイドなら主流になる可能性はあるな
フロントではならないと思う
Next.jsはVercel依存が大きいな
Reactも含めて将来怪しい気がする
>>720 何事もそうだけど困ってない人に有用性を説くのは難しいよね
>>715 一回作って終わりの人かな？
リファクタリングん時どうすんの？あ！しないの人か
プログラミング言語のスレッドだと勘違いしているおっさんが続出
>>725 リファクタリングでもJSで問題無いだろ
どうせソース見るし
ネットだとts絶対許さないマンよく見るけど現実だとお目にかからないよね
絶対許さないとまでは言わんけど無駄やんｗ
フロントエンドで何でそんなもの使わなきゃいかんのやｗ
CoffeeScript何かを有難がってた奴らが使ってそうだしｗ
どうせTS何か10年後には終わってるよ
CoffeeScriptがあっという間に廃れたのはJS自身が（CoffeeScriptの機能も吸収して）進化したことと、より良いTSが幅を効かせたことが大きい。TSが死ぬとすれば、それを成すのはより進化したJSか、TSの上位互換言語の台頭だ。
つまり進化は地続きで、TSを学んだり使うことは無駄にならない。もっと言えばTS使い的には歓迎すべきことですらある。
まぁでもMSが力入れてるし採用率もかなり高いし、10年そこらでは死ななさそう。
フロントエンドでは要らないって言ってる人はバックエンドでは使ってるんだろうか
MSが提案してるTypes as Commentsはどうなったの
jsdocとeslintがあれば十分だと個人的には思ってる
圧倒的にJS採用の方が多いだろ
TSはこのままずっと低空飛行だよ
確かにガッツリjsdoc書いてあればまぁいいかなと思うけど、むしろTSより面倒くさい上に表現力足らなくない？
>>735 古典的な静的ウェブサイトも含めりゃそうだろうけど、スレタイのライブラリ使うようなウェブアプリ界隈では低空飛行とは言えないと思う
MS自身がTypeScriptを嫌になったんだろうな
VSCodeでの解析も完全にはできない
トランスパイルが重くなる
そもそもTypeScriptは時代に合わなくなってきた
>MS自身がTypeScriptを嫌になったんだろうな
なんか唐突だけどTypes as Commentsの話？
反TSの人ソースもなしに主観的な事しか言わねぇな。しかも対話もできない。
TSはクソだから代わりのものが普及したら乗り換える←わかる
TSはクソだからJSを使う←ちょっとわかんないですね
>>738 TypeScriptって書いてるのに読めないの？
「嫌になったんだろうな」って話に脈絡がないからこれがどこから出てきたのかってことだよ。
MSがTSを嫌になったと思わせるような話がなにか出てきたっけ？
>>743 そっかすまんね
TypeScriptに関するVSCodeのアップデートみてると「これ以上解析するの苦しいから助けて」っていうメッセージが頻繁にあったんだよね
最近はしらんけど
まあオープンソースだし当たり前なんだが
そもそもTypeScriptもVScodeもMSが開発してるのに別の提案をしてきてるってことはTypeScriptがダメって自ら認めているようなもんじゃね？
アロー関数とかasyncとかモダンなJavaScriptの構文ってだいたいMS主導の提案だろ？
そもそもTypeScriptはJavaScriptを改善していくためのPoCの役割を担っている言語で、TypeScriptが必要なくなるのはMSにとっても望ましいことなんだよ
>>741 それ分からないって頭弱くね？ｗ
そもそもjsのライブラリなのにjsで書けないってｗ
あ、書けないじゃなくて書かないって言いたいんだろうけど
お前みたいなのは書けないと同義なんだよなｗ
>>744 なんかぼんやりした話だな。tsserver事態のメンテはvscodeチームとは関係ないだろうし何の話だろう。
仮にそれが事実だとしても嫌になったのはvscodeチームがであってMS自身がってことじゃじゃないよな。
「別の提案」ってのがまた話の脈絡がわからないが、こっちはTypes as Commentsの話？
支離滅裂な文章でも文末にｗ付けりゃ人を煽れると思ってるんだろうか…
Types as Comments なんてまさにTSの発展形なわけで、TS学んで有利になりこそすれ、損は無いよなぁ。
TSは言語仕様を見れば必要以上に便利な演算やマクロ化は避けてあるから、ある程度で解析打ち切りってのは異常でもなんでも無いように感じる。
>>745 モダンにアロー関数使って変数の値が極力変わらないスクリプト書いてもIEさんが挙動おかしくなってましたね…
自分もフロントで型を使って何をするか分かってない
ビジネスロジックは書いたらだめだよね
>>751 べつにプレゼンテーションロジックでも役に立つんじゃね？
フロントにビジネスロジック置いたらダメなんて法もないし。
プレゼンテーション層で型エラー出して遷移が発生しなかったり変なデータ表示したらユーザが誤解して結果的に間違った操作するから、どっちも大事だよね。
つかビジネスロジック一切触れなかったら何も操作できないじょん
>>753 ビジネスロジックがフロント側やいろんなところにあるのは悪手だと思うけどな…
でもたしかに日本国憲法には書いてないから言い返せないわ
どこまでがビジネスロジックにあたるか分からんのでなんとも
ソシャゲガチャの確率をフロントで捌くことは無いってのは分かるが
悪手ってのは管理的な意味でかねぇ？
同じロジックのコードが分散したりしなければべつに困らんと思うが。
>>757 レイヤードアーキテクチャの考えだと、
ビジネスロジックはドメイン層に書きましょうでしょ
でも、この話ってそもそも何のシステム作るかで左右されるよな
いつの間にかフロントにビジネスロジックを書くかどうかの議論になってるけど
ビジネスロジックを書くなら型必要、そうでないなら不要って合意がされたんだろうか
そうでないならそこを議論しても意味ない気がするけど
>>758 その境界をクライアント-サーバー間に引かなきゃならん理由はないだろ。SPAとかなら特に。
フロントだけでアプリ作れるよ系のサービスは存在そのものが悪になるの？
フロントだけでアプリが作れるように見えるFirebase/Firestoreも実はセキュリティルールとかあるし、本気で活用するならFunctionsとの連携が必要とかもあって、フロントだけでもない
そんなこといったらデスクトップアプリはフロントだけじゃん
単にコンパイルされて中間ソースがあるだけでツールで簡単に逆アセできてしまう
そのために高い難読化サービスがあるわけで
>>760 フロントにドメイン層があるの？
サーバーはインフラストラクチャ層だけか
>>759 そりゃ必要でしょう
ビジネスロジックって足し算引き算だけじゃないよ
>>765 ちゃんと読んでレスしてくれよ
ビジネスロジックを書くとき型は必要か？なんて質問をしたわけじゃない
>>766 ビジネスロジックなしでも型は必要でしょってことね
プレゼンテーションロジックでも型が必要なのは納得しました
単に型があればVisualStudioCodeなどでインテリセンスが働いて楽とかそんなもんで
そもそもフロントエンドなら大抵はサーバー側とjsonでやり取りするだろうけど
それを表示するだけのフロントで全てのAPIのjsonをクラス化するのかよｗって所がねｗ
ツール使えば自動で吐き出されるとか言うのかも知れんがｗ
C#(Unity)とかだとクラス化した方がコードは書きやすいけど
クラスというよりはインタフェースを定義するって感じかな
ただそれだと結局型安全じゃないキャストをすることになるから
io-tsとかライブラリを使ってAPIがそれを満たしてるかを動的検証できる型情報を定義してる
>そもそもフロントエンドなら大抵はサーバー側とjsonでやり取りするだろうけど
>それを表示するだけのフロントで全てのAPIのjsonをクラス化するのかよｗって所がねｗ
なんか、「フロント」の認識に大きな隔たりがあるのを感じた。
クラス≒型って認識の人は大体クラスベースオブジェクト指向しか知らない人
ECサイト構成するのとメモ帳なり実用アプリ作るのを同列に語ろうとしても無理だよね
>>771 そういう認識の人は数値や文字列にも型があることの恩恵には気づけないのかもね
>>771 狭い特定なパターンの型とクラスを持つプログラミング言語だけしか知らないとそこに陥りやすいかもね
例えばWebに身近なところだとWebAssemblyを書くのに最も使われている言語Rustあたりを理解すると何もかも新鮮で一気に視野が広がるかな
Rustはクラスも継承もない
それなのにメジャーな各言語よりも強力で便利で速い静的な型安全を実現している
C/C++と同じ速さで動くのに即時自動メモリ解放なのでミスは起きず安全でガベージコレクションが必要なく高速な初のプログラミング言語
実行前にメモリ安全性からデータ競合の無さそして全ての型安全まで全てをコンパイラが静的に保証してしまう言語がRust
フロントエンドでJS/TSメインで補助的にWasmを使う従来のスタイルから
フロントエンド全てをRustで記述してWasmで動く新たなスタイルまで登場してきているので
今後のフロントエンドの進化でも注目点
>>777 そう言っとかないと炎上して面倒だからでしょ
世間で実際に置き換わるかどうかと置き換えとして使用できるかどうかは別問題で、
少なくとも後者についてはwasmの公式及び信奉者達は実現するつもりだろうな
名前がダサいし読みにくいから流行らんのだろ
かっちょええ名前にすりゃいいのに
>>778 公式の言うことを全く信じないとか、陰謀論者みたいなこと言いますね……
訂正、信じなくてもいいとは思うけど、公式の言ってることを頭から否定するのはちょっとどうかと思うね
なんでも斜に構えるのが格好いいと思ってるお年頃なんだろう
そうなって欲しいという気持ちはわかるけど
現状ワナビが夢語ってるのと変わらん
wasmおじさんまだいるのかよ
wasmスレでやりなよ
TS型パズルのせいで終業遅れて趣味の時間が削られまくったわ
地味にイライラする
Nextjsは細かくサーバー処理とクライアント処理分けられるけどここまでやる必要あるのかね
無駄に突き詰めすぎな気がする
せいぜいLaravelとVue程度で良いだろ
>>777 その通りでWasmはJavaScriptの機能を代替しない
例えばDOM操作をWasmから直接することはできない
そのため各種プログラミング言語で書かれたWasmのプログラムいずれにも補助となるJavaScriptのプログラムが付随している
したがってWasmからは間接的にDOM操作を含めて任意のことができる状況となっている
例えばC#だけでSPA含めたフロントエンドを記述できるフレームワークBlazorや
同様にRustだけで記述できるフレームワークYewなど
様々な各言語だけで記述できるフロントエンドのフレームワークがJavaScriptのフレームワークの競合となりつつある
特にRustで書かれたものはガベージコレクションや重い(or大きい)実行ランタイムを必要としないため
ダウンロードサイズの点でも実行速度の点でも従来のJavaScriptと比べてほぼ同等となっている
>>788 WasmからJSを呼び出すオーバーヘッドやGCの無いRustで書いてすらJSで書いた場合よりダウンロードサイズが増えることを意図的に無視してない？
まして所有権に気をつけながらRustで書くのと平坦にJSで書いたものが等速では意味がない。つまりWasmを使うべき場面はそこじゃない。
「その通りで」と言いながら元の文章の意味を都合よく無視した持論を展開するのは詭弁だよ。
Wasm開発側がJSの代用にはならんって言ってるしな、既存のライブラリが使えるとか得もあるけど
案件でReactとVueどっちも触ることがあるんだけど、Reactなんか好きになれないなあ
なんかref使ってDOMを意識しなきゃいけないこと多くない？
案件の性質の違いでたまたまそうなんかなあ
depsとかもバグの温床だし書き方冗長だし
それが好きな人もいるんだろうけど
あとVueのtemplateはいいよね。HTMLそのままだし
tsと相性良ければなあ
>>793 refよりはstateの方が使う
ref使わなくてもいい場面で多分ref使ってる
canvasとか埋め込みプレーヤーとかwysiwygのエディターとか操作するときはref使う
depsはhooksのlintのパッケージがあってそれ使えばバグは余裕で回避できる
ずーっと業務でGoとかのバックエンドやってて最近Vue始めたんだけど書き方多すぎないかこれ...？
まずOptionsAPI、CompositionAPI、script setupと3つある時点で意味わからん。ネットで検索してもコードが読めん。慣れてないだけ？
script setupはComposition API書くためのシンタックスシュガーで、新規コードは全部script setupでいいと思うよ
歴史的経緯があるから書き方が増えるのは仕方ないにしてもドキュメントの整備が追いついてないのが困る
３つの書き方の名前を認識できるまで調べてるなら経緯も分かりそうなもんだけどね
あとネットの記事漁るときは日付ぐらいチェックした方が
ref使わなくていいとこで使っちゃう人はvue使っても同じことになりそう
>>801 この記事の主が表層的にしかReact理解してないから、コメントで突っ込まれまくってるな。しかも後半は技術じゃなくてMetaが嫌いって話してるし。
まぁでも、こういうやんちゃな奴がいる界隈は活気があって良いですよ。石頭でさえなければね。
フェイスブックが嫌いってのはかなり多いだろうな実際
>>803 しかも匿名ならわかるけど会社名出してるのが凄いな
普段Vueディスってんのにreactディスられたとたん発狂する奴多くない？
記事にツッコミどころが多いだけでしょ
VueはReactに比べるとコンセプトがstraightforwardなので、良くも悪くも「そういう設計を選んだんだからそうなるよね」で議論が済んでしまう
だからこの記事みたいな設計思想に対するディスはあまり見かけない印象
仮想DOMにオーバーヘッドがあるの事実だしな
だからsvelteやsolidが生まれた
普段からパフォーマンスにうるさいフロントエンドエンジニアが
そこには目を瞑るのはおかしいだろうのは痛いところ突っ込まれた感じ
仮想DOMとuseMemoでパフォーマンス的に困ることほぼ無いんよ。使ったことない人にはわかんないかもだけど『早すぎる最適化は諸悪の根源』だよ
そもそものReactの当初の発想は
「クライアント側でのPHP」を目指してたんだぞ
今の人は知らんだろうけど
本質的な面で効率が良くなるわけはないんだよ
XHPというPHPのライブラリが元になった部分があるだけで「クライアント側のPHP」を目指したなんて事実は無いぞ。
仮に「クライアント側のPHP」という機能を目指したとして、実装としてのパフォーマンスに何の関係があるんだ？
自分の言いたいことのために都合の良い過去を作り出した上に変なこじつけをするな。完全に詭弁じゃないか。
>>812 PHPみたいにというのはつまりカスタムタグ使って
ページを毎回再レンダリングしているように作りたいってことだよ
サーバーサイドがそうしているようにね
その副産物として仮想DOMやJSXが生まれた
まずPHPといってるがfacebookの人がPHPと言ってるからそう言ってるがサーバーサイドと言い換えるべきものだよ(ご存じの通りfacebookはPHPのヘビーユーザー)
クライアントからリクエストを受けたらサーバーサイドは
HTMLを全て「生成し直して」レスポンスを返す
前回の状態など意識せず全て情報を取り直してHTMLを生成する
当たり前だが前回の状態との差分を取って部分的にHTMLを返すなどということはしない
常に丸ごと返す
このモデル(HTTPだが)の良いところはHTML生成といううコンテキストにおいては前回の状態と言ったものは意識しないで済むこと
最新の状態を取ってそれをもとにHTMLを生成すればよろしい
当時のフロントエンドはDOMに状態を持たせてajaxはその状態を更新して対応するDOMを更新するというアプリが大多数だった
フロントエンドもサーバーサイドのように状態を意識せずに関連するDOMを毎回全部生成できないか？という発想が生まれる
React誕生の瞬間である
renderとstateを使って状態が更新されたらどの部分を更新するか一切意識することなく常に一枚岩のDOMを返すようにかける
見事サーバーサイドをクライアントに持ち込めた
ただしこの動きを実現するためには差分を内部的に検出する仕組みが必要不可欠
本当に毎回DOMを全部生成してたらパフォーマンスが終わる
ユーザーはDOMを意識せずに全部返すように書くが
裏で差分を検出してこっそり部分的にDOMを書き換えるようにしよう
仮想DOMの爆誕である
そうなるとJSXみたいなものが必要だよねとなってJSX爆誕
これがReactの歴史である
知らんけど
パフォーマンスが実用に差し障るほど悪いという話には繋がらないわけだ
そりゃ、前提条件を決めなきゃそんな話はできないからな。
用途や規模によっちゃWeb自体「実用に差し障る」し。
仮想DOMのオーバーヘッドを許容しても
丸ごと全部DOMを返すようにかけるメリットがあまりにも大きい
お前らも大規模アプリにおいてはこの書き方がいかに素晴らしいかわかってるよな？
facebookクラスになると何千という状態があるだろうし
それを宣言的にかけるメリットの方が遥かに優先される
仮想DOMがゴミと言ってるやつはデメリットだけを見過ぎ
上に書いたようなメリットがデメリットを上回るのよ
ギャーギャー騒いでる奴らはしょぼい管理画面とかしか実装してないだろうからデメリットばかり見えるんだろう
Facebookを作るわけじゃないならゴミってこと？
結局仮想DOMのパフォーマンスに文句言ってんのがReact書いたこと無さそうな人ばかりなのよね。こういうシステム書くと何秒かかってユーザー体験が悪い、みたいな具体的な話が無い。
上に書いた歴史を踏まえればなぜReactは毎回コンポーネントをレンダリングしようとするの？とか
仮想DOMのオーバーヘッドが無駄じゃね？と思ってる人は
その理由が全部理解できたと思う
おれは業務基幹システムのフロントをReactで作ってる
業務では全国の数百人が一日中ガシガシ操作するのだがReactで作ってよかったと思ってる
数百のコンポーネントを俺一人で作り上げた
画面の中には多数の分割されたコンポーネントやモーダルウィンドウが表示され、格コンポーネントがリアクティブに反映され、さらにcssやcanvasで視覚的に描画もしてる
これを俺一人でAtomicデザインからコンポーネント、ビジネスロジックまですべて設計して開発した
>>825 すまん身バレするから詳細までは言えん
開発初期にはsveltもsolid.jsもなかった（あったのかもしれないが知らなかった）から候補にはならなかった
>>828 簡単に言うと業務に関するフロー図のようなグラフィカルな表示をするためにhtmlとcssとcanvasを使っている
React Native、Flutter、Vueを触ってきて最近Svelteでサクッとアプリ作ったけどSvelte一番好きだわ
Vue3のComposition APIをさらに簡潔にした感じでマジでわかりやすいReactのJSXやFlutterのWidgetが大嫌いだから余計にそう感じる
ただ一番マイナーでエコシステムが弱いんだよな特にコンポーネントライブラリでデザインが良いのがSvelteUIくらいしかないんだがまだ始まったばかりでぜんぜん実用に耐えない
むしろサクッと作る場合こそReactがベスト
関数作ってuseStateで状態作ってJSXをreturnすれば終わり
フォームもcreateRefとか使えば深く考える必要もない
何も考えなくて良い
>>831 SvelteKitが1.0に到達したらもっとエコシステム等が充実すると思う。
>>832 その文面だけではどうしてReactがベストなのか理解できないわ
もうちょっと具体的に比較を頼む
ちょっとしたフォームを考えてみる。大項目A中項目B小項目Cがある。項目リストはRESTで取得する。
Aが選択されたときBのdisabledが外れoptionがセットされる。BとCの関係性も同様。Bが変更されたとき、Cのselectedはキャンセルされ、optionは再度セットさせる。ではCが選択された後にAを変更するとどうなるか。BとCのoptionが再セットされCはdisabledになる。A～Cは他の項目にも影響を与える。今後Cの下に項目Dが追加されるかもしれない。
見た目は簡単なフォームだが既に面倒くさい。こんなのグローバルな状態を使って管理したくない。俺はReact(Preact)を使って楽をする。
SvelteのTemplate Syntaxとバインドでも簡単に作れるんだが
俺Reactしか知らないけどイキリ散らかすわとしか読めない
あぁごめん。他のライブラリでも全然良いよ。React程は詳しくないから書かなかっただけで。
何も無しよりはずっと楽だからライブラリ使っちゃうよね、ぐらいに思ってくれ。
間違ってたら指摘してほしいんだけどReactで開発してて一番嫌なのが状態管理をMeta(Fb)が実装しないでコミュニティに丸投げしてるところなんだよね
なによりReduxってどこがいいのかまったくわからない
冗長なボイラープレート満載かつどこをロジックの場所にするかプログラマーによって解釈が異なるし
結局Viewでhook使いまくりになって疎結合とは？になる
>>839 Reactはバカチョン機能を提供しない
いやそんなミドルウエア的なの
押し付けられても困るの!!(;´Д`)
>>838 >>836ってどの話からつながってるの？
>>839 いまだにそこに文句を言ってるのが凄い
状態管理に銀の弾丸はないのよ
「Hooksを用意したからお前らで適切なものを作れ」
これがMetaが行き着いた結論であるし
実際これはすごく良く機能してる
とりあえず生useStateでサクッと作る
→複雑になってきたからカスタムフックをつくる
→コンポーネント化出来そうだからコンポーネントに切り出す
この開発サイクルがどのフレームワークより優れているのよ
実際ここまで拡張しやすいのはHooksとコンポーネントとJSXの親和性良さ故なのだが
>>839 MetaがRecoilってやつ出してるよ
結構浸透してる
>>840 Recoilがあるんだが？知ったかおバカさん？
>>842 そもそもViewが状態を持たないから依存関係がなく疎結合でReactすごい！って信者の常套句だったのだが？
結局Reduxのストアという状態管理の煩雑さ・スコープの問題からContext APIでよくね？ってウェブあるあるの先祖返り起こす一派もいるけどそっちはそっちでやっぱり問題あって
そして出てきたRecoilはHooks API使ってコンポーネント単位で小さく状態管理するからViewががっつり状態持ってて疎結合とは？になる
しかもRecoilってまだ実験段階の代物でウェブ特有のいつツールチェインが移り変わるか頭を悩まされるのが嫌だからOSSにしてもメーカーが主導すべきなのに遅すぎる
状態管理に関してはそうやって好みが色々あるから、自由に使え、何なら使わなくても良いよってやってんじゃん？
まぁ結局のところViewModelというストアが複数あるMVVMの双方向バインディングを否定した片方向のFluxアーキテクチャもHooks APIでContext APIをAtomsという複数の状態を操作するというMVVMと同じことやっちゃってるわけですよ
アプローチは違って遠回りしたけど結果は似たようなものになっちゃったってことなわけ
これもまぁ好みなんだろけど個人的にMVVMのVueとSvelteが好き
atomはビュー固有ではなくてコンポーネント間で共有されるモデルを置く場所だから全然違うぞ
MVVMでいうならVMではなくMに相当する
いやそれはMVVMを理解してない
MVVMのModelの責務は状態管理やデータ保持のストアじゃなくデータモデルである型定義やビジネスロジックなんだが？
AtomsはReduxでいうところのストアでありストアとの違いはAtomの名前の通りAtoms一つで状態を保持してるところ
複数のAtomsを管理するためのSelectorsがまさにViewModelそのもの
>>848 MにUIの状態を持たせちゃいけないというのはよくある勘違いだよ
VMはバインディングのために使用する射影以上のものではなくて、その責務に専念している限りにおいてはVMの状態管理が複雑になるみたいな問題は本来発生しない
でもMVVMはその構造上、ビューの状態管理の責務を負わせるという誤用をされやすくて、
その結果VMが複数の責務を負うこととなり複雑化に繋がる
>>849 それは貴方の解釈でMVVMの一般的な概念じゃない
その主張はMVVM界隈から100%反論されてレスバになる
しかも貴方の主張って具体的な言葉や説明が一切なくてふわふわし過ぎてて議論になってないですよ
C#おじさんって話題が古いよね
MVVMって一昔前のJSフレームワークがやたら叫んでたアーキテクチャだぞw
理詰めで論破されて顔真っ赤でうんこ！って喚いてるのと等価だから実質敗北宣言なのに本人は気付いてないの草
この人がC#おじさんかどうかはともかく、前スレとかで暴れまわってたC#おじさんは議論ができない人だからラベリングして隔離したくはなる。
エラー処理を蔑ろにすると痛い目を見るからね。
Reactの方がコンポーネントを抽象化し難い気がする
双方向バインドがないからhooks使うと固有のコンポーネントになってしまう
プログラム作っていく上で抽象化、共通化は基本なのでこの流れに反して違和感を感じるね
>>858 それは
>>848に近い誤解に陥ってるんじゃないかな
複雑な状態管理はそれこそ抽象化してモデルにすればいいんだよ
>>859 > 複雑な状態管理はそれこそ抽象化してモデルにすればいいんだよ
コイツのレスってまったく反論になってないんだよね具体的なことが一切含まれず内容が一切ない
これもうレス乞食のために故意にレスバ仕掛けてる荒らしだよ
コイツの場合レスが抽象化されててコピペになってるじゃん
Reactも最近下火になってきてると聞いたが抽象化に反してるし無駄な学習コスト高が原因かもね
まだTS順応やSSR等の有利な点もあるから早めに解決した方が良い
少なくとも双方向バインドはあった方が良いと思う
>>860 具体的どころか中身0な事言って煽ってるの君じょん……
>>861 下火になってきてるというソースくれ。
個人的には、双方向バインド無い方がデータ構造がシンプルになって（シンプルさを担保できて）良いと思う。
>>858 >>hooks使うと固有のコンポーネントになってしまう
コレ何なん？
双方向バインドがあればなあ・・・みたいな場面に遭遇したことがない
いずれにせよコンポーネントが状態を持たない片方向バインディングがReactやFluxのウリで双方向バインディング否定してたのにuseState、useReducer、Hooksが当たり前になってそんなことなかったことになってるのReact界隈が大嘘吐きだってバレちゃったんだよね
だってコンポーネントが状態持ってる方が圧倒的に便利だしグローバルにストアにアクセス出来ないと面倒臭すぎるんだからそりゃそうなる
結局SSRに回帰してるしウェブ界隈って詐欺師の妄言を信用しすぎだね
最終的にフロントとバックの垣根が消滅してajaxが悪だったってところに着地したら笑う
>>865 SSRに回帰してないゾ。SSGとSSRをごっちゃにしてないか？
>>866 垣根がなくなったら内部的にはもっと所謂ajaxを使うことになるゾ。つかajaxなんて言葉、もはや当たり前すぎて死語になりつつある気がする
なりつつあるいうか普通に死語
どっかのAPIに名残が残ってる程度
キーワードとして使うことはないけど死語とは違くない？
無意識にTCPを使ってるからTCPは死語みたいな話でしょ？
>>839 Recoil使えよFacebookが作ってるヤツだからさ
>>844 多分古い書籍とかで入ったタイプだと思う
てかFBってMetaになったんだったな
>>844 Reduxとか何年まえの話をしているのか
エアプ丸出し
>eg+2
この文字列でレス抽出したらReactおじさんでクソワロタ
状態管理もVueの方がわかりやすいしバグが少ないな
ReactはuseMemoとかcallbackで更新を細かく制御出来るがその割に速度はVueに劣るなら細かい設定の意味も薄れるな
ただ面倒なだけになる
>>876 細かく制御できてそのぶん速度が遅いなら正当なトレードオフじゃん。
Vueのほうバグが少ないというソースを出してみ？
c#おじさんは
歳いってて古臭いし
なにより頭わるいで
放置で！よろ
今はVueメインだけど、Vuetifyが3対応してくれればなあ、ってずっと引っかかってる
いつ完成するんだろう
3.0でても全部入ってないよね・・・
>>878 >tdwJでレス抽出したらReactおじさんの自演で草
vueは2で十分だしなぁ
3にする必要が今の所ないので2のまま開発してる
Reactおじさんが必死になってReactおじさん否定して火消ししてて草
C#おじさんはC#おじさんって言われたの、そんなに嫌だったんだね
ReactおじさんはReactおじさんって言われたの、そんなに嫌だったんだね
実際どうなだろ？
なんだかんだで中核層って３０～４０代なんじゃね？
おじさんと言われたおじさんだろ
>>883 vueはOptions APIしか存在価値ないからね
サクッと作れるのは魅力
Composition API使うぐらいならReact使うしさ
>>890 それはそう。
2010年くらいからず～っとしつこくWebやってるおじさんだよ。Twitterとか見てもそういう年齢層がWebのフロントを牽引してる気がする。
最近はスマホアプリ全盛でWEB自体がオワコンだよ
スマホアプリでもWEB使えない事はないけどあくまでオマケみたいなもんだし
今の20代は円周率が3だから。
分数がわからないと言ってます。
つい最近までBlazorおじさんでもあったc#おじさん
>>883 わかる
nuxt+vuetifyでvue2使ってるけど
正直ちょっとした業務アプリなら
これでいいやって感じしてるｗ
>>896 でもTypeScriptの恩恵受けられなかったり、vscodeでvolar使えなかったりしてストレスたまらない？
>>897 tsの恩恵が型チェックを指してるなら
ほぼ恩恵受けられてるとおもう
まあpropsはお察しだけどたいしたことはないかな
volarはもともと使ってない(vetur)
veturはリファクタリング機能……せめてリネームくらい
さくっとできればいいのにってストレスはある
Nuxt3安定版リリース予定日がコロコロ変わるけど、夏のうちにリリース頑張ってくれ
Vueって完全にPythonと同じ構図て2派3派分裂に陥ってるな
3をメインにするにはまだ周辺が出揃ってない一時的な状況であって分裂とは違うと思うけどね
しかしangularは話題に上らないな
俺は好きだけど
>>902 angularjsはもう古いし（少し勉強したのが6年ほど前の話）
angular2が出たけど流行る気配も無く、記憶から消えていった感じがｗ
でvueとかreactが出てきてあっという間に過去にされた感じがするなぁ
Nuxtで公式のライブラリ同士が競合したりするともうAngularでよくね？って思うことはある
次スレはvsとAngular消すって事？
SvelteとSolidだとどっちが言及多かったのかな
stackoverflowの2022アンケートだと好きなフレームワークランキングangularだいぶ上位だったぞ
別に消さなくてもいいけど日本だと使っている話を全く聞かないなぁ
世界レベルは分からないけど、好きな人は好きって事なのでは？
消さなくてもいいけど残しても話題になることはおそらくないよね
そもそもこのスレ自体がReactおじさんとReact嫌いおじさんが喧嘩するだけの場所になってるけど
vsだけ消す感じかな。ワッチョイは継続だな。前スレと快適さが違いすぎる
vsvsって何だと思ったら、そういや対決スレみたいな感じだったなw
vsはワイもなくていいよ
angulerはどっちでもいい。行き場なくなって困るいるかもやし。。。？
ワッチョイはぜひ継続で
reactもレンダリングを極小に抑えればvanillaとほぼ変わらん速度が出るし、速度が同じならそこに残るのはコンポーネント思考で疎結合なソース、高可用、最高の可読性、拡張性。solidの出番あるかな？
>>914 複雑な構成だとガチで難しい...
マジ地獄
優劣の話をしたいなら謳い文句みたいなのだけじゃなくて根拠も示そうよ
今月のweb+dbのReact特集はためになるな～
>>917 立ち読みしたが基本的なことばっかじゃん
このくらいも知らないようじゃreactを全然理解していない
Reactビギナーな人がいてもええやんけ。
玄人でも役に立つことがよく読むと書いてあるパターンかも知らんけど
>>918 わかる
あれが巻頭記事になるって今のWEBDBの質やばいな
最近質が落ちすぎなんだよ
https://gihyo.jp/magazine/wdpress/archive/2022/vol129 特集1
Reactの深層
最新バージョンから読み解く！ 変わる常識と変わらない思想
本特集はReact 18のリリースを受け，これまでのReactについて復習するとともに，React 18の新機能を紹介します。新機能を使いこなすにあたり，前半ではこれまでのReactの使い方やAPIに込められた思想を確認し，後半ではReactユーザーが対応を迫られる新しい常識を解説します。将来にわたってReactらしいコーディングをするための考察です。
これに対して知ってる知らないの話にもってく
>>918は的外れだと思うが
Reactユーザーはまた新しい常識とやらに対応を迫られてるの？
ご苦労なことだな
Reactのメジャーバージョンってあんまり使う側にプログラマにはそこまで影響なくて
Reactというライブラリの中身のロジックががらりと変わるけど使い勝手はそのままみたいなパターンなんだよな
CQでもトラ枝でも界面でも技評でもなんでもそうだが
長年通年読み切り雑誌造ってるとマンネリ化して
毎月同じ頃に同じネタ繰り返したり
新規読者開拓の方が優先されて初心者向け記事ばかり出すようになる
ReactはJSから逸脱しすぎ
そのうちVueに負けるんじゃない
言うほど逸脱感あるかなぁ。それに負けるとしてもVue相手では無さそう
npm trends見ればReact一強よな
vueはnextと同じぐらいだったよたしか
国内だとスキルレベルの影響か、VueがReactに切迫してきてるとは思う
グローバルに見ればReactやろなあ
jQueryはガラバゴスなので移行しやすい先は無いじゃなかろうか
むしろとっくにjavascriptに実装されたからjqueryなんていらんわ
>>936 JSXとHTMLテンプレートだけを比べて語るのは乱暴がすぎる
そもそも
>>933の逸脱が具体的に何を指してるのか分からなくて
それにどう反論してるのかもわからない
next使い始めて初めて自分でAPIを書いたんやが、セキュリティ的にやらないけんことまとめてある記事紹介してくれないか
セキュリティ気にせんかったらAPI叩かれ放題になるやん？
それは嫌や
APIの仕様はログイン不要でサイト内からなら誰でも叩けてバッファを返すAPIや
とりあえず誰でもAPI叩けないようにと思って以下は実装してん
・呼び出し元ががサイトURLと同じか
・許可されたhttpメソッドか
他にこれやらな危ないで！ってのあったら教えておくれ
sec-ch-ua-platformとかユーザーエージェントも使って、人間か否か、みたいな判定に使えるかなと思ったんやが、ブラウザによってあったり無かったりで使われへんね
react久しぶりにいじること繰り返してるけど毎回useEffectの実行タイミング忘れる
それ以外は割と覚えてるんだけど
まずは導入してもらって徐々に移行してほしいって気持ち
資産捨てたくないをやったものってバージョンアップの度に置き換え地獄になりがちだから不安
>>950 早く次スレ立てろ
ちゃんとAngular抜かして立てろよ
あとスレタイは最初にReactを書け
React vs Svelte vs Solid.js (vs Vue) Part.11
でいいんじゃないか
>>948 あーあ投資家の圧力に負けたか
Denoのコンセプトであるパッケージ管理をしないかつ
Web標準をサーバーサイドに持ち込むというコンセプトじゃ
現実の問題を解くのは無理だったか
もうJavaScriptフロントエンドフレームワーク総合とかでええやん
何を入れる入れないだの順番だのあほらしい
なるほど、フレームワークは削っといた
JavaScriptフロントエンド総合 Part.11
http://2chb.net/r/tech/1660898820/ これでjQueryジジイが来るようになったな
スレタイを変えたアホのせいだ
テンプレ残ってるからまだマシだけど
jQuery排除するには弱いし名分が立たない
まさに今jQuery案件に放り込まれて絶望してる
触るの8年ぶりくらいかな・・・
可哀想に……。
IEが死んだ今jQuery使うってことはレガシーの機能追加？ それなら表面以外は生DOMで茶を濁せんもんかね
一応新規開発なんだけどね
古い会社がデスクトップアプリの需要減で何もわからないままWebに参入してきちゃったんだ
こうやってスレタイに入ってなくても隙あらばjQueryの話してくるヤツは居るから変わらんな
>>972 デスクトップアプリ案件とか
保守案件以外は殆ど無いだろうね
>>962 死ねカス
誰かReact専用スレ立ててくれ
>>962 マジでこいつ無能
スレ落とせよゴミクズ
なんでもいいけどドサクサに紛れてワッチョイ無しスレとか立てるなよ
誰かこのスレタイで立てて
おれは立てられなかった
React vs Veu vs Svelte vs Solid Part.11
このスレタイにAnguler入れるとスレタイ長すぎで弾かれるから注意
ドサクサに紛れてReactを先頭にもってこようとか浅ましいことを考えるからそうなる
React最初にって言われたからそうしたんだが
そもそもReactのほうがメジャーだろ
浅ましくないわ
メジャー度合いとスレタイの並び順に何か関係があるんで？
こまけーことはいい
Vue先にしてもいいからスレ立てしてくれ
次スレ
判断付かんので現状維持
スレタイ変えるなら丁寧に進めてくれ
Vue vs React vs Angular vs Svelte Part.11
http://2chb.net/r/tech/1660969032/ フロントエンド総合でいいよ
わかりやすい
ごちゃごちゃ言ってる奴は無視で良い
対立煽りや宗教論争ふっかけたい連中はこっちで住み分けってことで
>>994 あるよ
ちな昨日いった本屋はReactとかよりもVueの本が圧倒的に多かった
たまたまかもやけど
>>993 んじゃReact先頭にした浅ましいスレ立てれば？
Angularは必ず復活する。
Reactはmetaと共に滅亡する
>>993 ネットの情報ばかり鵜呑みにしてないで働け
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 168日 0時間 28分 58秒
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/ ▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
lud20250225171705caこのスレへの固定リンク： http://5chb.net/r/tech/1646747836/
ヒント：5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。
TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像
↓「Vue vs React vs Angular vs Svelte Part.10 YouTube動画>1本 ->画像>1枚 」を見た人も見ています：
・locally noetherian regular flat surfaces over a Dedekind scheme
・mlb one league no division all play all and many games vs neighbors proposition
・Aqours クラブ活動 LIVE & FAN MEETING 〜 Landing action Yeah！！ 〜 イベント総合スレ85日目
・Aqours クラブ活動 LIVE & FAN MEETING 〜 Landing action Yeah！！ 〜 イベント総合スレ99日目
・Aqours クラブ活動 LIVE & FAN MEETING 〜 Landing action Yeah！！ 〜 イベント総合スレ89日目
・Aqours クラブ活動 LIVE & FAN MEETING 〜 Landing action Yeah！！ 〜 イベント総合スレ115日目
・Aqours クラブ活動 LIVE & FAN MEETING 〜 Landing action Yeah！！ 〜 イベント総合スレ118日目
・Aqours クラブ活動 LIVE & FAN MEETING 〜 Landing action Yeah！！ 〜 イベント総合スレ112日目
・一人で行くHello！ Project 2020 Summer COVERS 〜The Ballad〜 part17ヴァー 【7/11(土)〜8/30(日)】
・BBC「blackface actor sparks anger」
・【Netflix】アンブレイカブル・キミー・シュミット: キミーVS教祖 / Kimmy vs. The Reverend | Interactive Special【インタラクティブ】
・【DOA5LR】DEAD OR ALIVE 5 Last Round 晒しスレ 16 [無断転載禁止]©2ch.net [無断転載禁止]
・【ビチビチのうん地】導きの地総合 Lv-63 "The Diarrhea Shit Lands"【LEVEL DOWNち…】
・Seagull's Love Songって同人誌 [無断転載禁止]
・【SOP】Liverpool vs AC Milan【ICC】
・卍 Razer 卍 【blade/stealth】 #3
・【ブラサス】Black Rose Suspects ブラックローズ サスペクツ part16【貞本】
・【Plan A】VICTON【 Voice To New World】
・Tom Clancy's Rainbow Six Siege Round104
・Tom Clancy's Rainbow Six Siege Round182
・Tom Clancy's Rainbow Six Siege Round181
・Tom Clancy's Rainbow Six Siege Round133
・Tom Clancy's Rainbow Six Siege Round150
・Tom Clancy's Rainbow Six Siege Round192
・Tom Clancy's Rainbow Six Siege 愚痴スレ Round1
・【R6S】Tom Clancy's Rainbow Six Siege Round232
・JAPAN RUGBY LEAGUE ONE （リーグワン） Part.22
・ginkiha vs kamome sano
・XCode VS Visual Studio for Mac
・FEARゲー】アルシャード vs GURPS【ｽﾃｨｰﾌﾞｼﾞｬｸｿﾝ】
・A Question for our Japanese readers
・【FPS】Paladins: Champions of the Realm Part2
・【ブレソル】BLEACH Brave Souls 破道の二百七十八
・【xflag】ファイトリーグ-Fight League Part.3
・【FPS】Paladins: Champions of the Realm Part4 [無断転載禁止]
・【LoL】League of Legends : Wild Rift Part18【ワイルドリフト】
・【詐欺運営】BLEACH Brave Souls 初心者質問スレ2【ブレソル】 [無断転載禁止]
・【LoL】League of Legends : Wild Rift Part10【ワイルドリフト】
・【LoL】League of Legends : Wild Rift Part29【ワイルドリフト】
・【LoL】League of Legends : Wild Rift Part32【ワイルドリフト】
・【xflag】ファイトリーグ-Fight League Part.5 [無断転載禁止]
・NEMOPHILA vs BAND-MAID
・Talk with Japanese language
・ﾃﾞｨｵHEAVEN & HELL/BLACK SABBATH11ﾏｰﾃｨﾝ
・【ディーン】DEAN GUITAR Part5【ギター】
・BanG Dream！（バンドリ！）総合 48thLive
・クリーン・アーキテクチャ Clean Architecture
・◆◇El Blanco Real Madrid 1198◇◆
・【LoL】League of Legends 1630LP【ipあり】
・◆◇El Blanco Real Madrid 1219◇◆
・◆◇El Blanco Real Madrid 1063◇◆
・◆◇El Blanco Real Madrid 1005◇◆
・【LoL】League of Legends その1412【lPなし】
・【LoL】League of Legends 初心者スレ Part194
・【LoL】League of Legends 1549LP【ipあり】
・【LoL】League of Legends 質問スレ Part67
・【LoL】League of Legends その996【総合】
・◆◇El Blanco Real Madrid 1082◇◆
・◆◇El Blanco Real Madrid 1059◇◆
・◆◇El Blanco Real Madrid 988◇◆
・◆◇El Blanco Real Madrid 1084◇◆
・【LoL】League of Legends 初心者スレ Part284
・Soundgarden, Chris Cornell, Audioslave Part3
・【LoL】League of Legends 1527LP【ipあり】
・【LoL】League of Legends 1485LP【lPあり】
02:42:26 up 57 days, 2:45, 0 users, load average: 7.29, 10.54, 9.22
in 0.082525014877319 sec
@0.082525014877319@0b7 on 031115
|
ブックマークへ