Vue vs React vs Angular Part.4
レス数が950を超えています。1000を超えると書き込みができなくなります。
>>849
SSRゴミカス野郎にリアクティブやらせたらデータと表示が一致させられなくて死ぬ
>>850
ゴミカス自称フロントエンジニアのゴミのようなUI/UXスキルはどうしようもないほど低レベル
コイツらにまともなUIを作れるわけがない
一生かかってもゴミセンスから抜け出せない VueとかNext.js使ってる人は
結局SPAとしては使わずに、SSRで使ってるということか？ >>852
SPA最大の利点はサーバの負担が軽い事だと思う。
フロントのためのロジック丸ごと省略できるから。
主に製作者側の都合なんだけどね。
例えば情報系サービスをスクラッチで作るとして、最初からスマホアプリとブラウザ版を作るならSPAも悪くない。
バックエンドは完全に共通になるしメンテ楽だわ。
ただ現状、WEBを作る場合ほとんどのケースでNextでSSRが最適解になるなあ。 >>854
デベロッパーだけの都合でもないよ
クラウドのランニングコストを支払う運営の都合でもある >>854
SPA vs サーバーでその処理を行うだったらそのとおりだけど
実際にはサーバーで処理を行うとは限らないんだよ
例えばAjaxを使ってJSONだけ読み取ってローカルの
テンプレートエンジンで処理をする。
マルチページで作るんだからこれはSPAではないよ。
JSONだけ読み取るのは現在のページ（URL）での処理だけ
それでもサーバーの負荷はわずかに減ると思うかもしれないけど
ボトルネックは通常データベースアクセスになるので
単にサーバーのCPUの休み時間が増えるだけ
> 例えば情報系サービスをスクラッチで作るとして、最初からスマホアプリとブラウザ版を作るならSPAも悪くない。
> バックエンドは完全に共通になるしメンテ楽だわ。
それもSPAである必要はないね。JavaScript（Ajax）で作ればいいだけ それにしてもURLが異なれば、通常はJavaScriptの処理も
まるっきり変わってしまうのになんでSPAにしようとしてるんだろうね
単にマルチページ+JavaScript（Ajax=テンプレート+JSON）でいいじゃない？ ここでいうSPAフレームワークはリアクティブなんだよ
ajaxで取得したデータは自分で処理書かないといかんだろが
それとコンポーネント化
これらを理解できねーゴミクズたちが必死に浅い知識でSSR自慢しに来ている
わからねえならあっち行けよ まああれだな。新しい技術ができたら、それは銀の弾丸だとばかりに
それが正しい、それでやるべきだ！といういつもの流れ
そこから一方戻って、というブームがあったんだが実際はどうだろうか？
やりすぎだった。それが全てではない。適材適所だな。と気付いて
ようやく一人前の技術になると思うよ。今はまだブームの段階 >>859
リアクティブとSPAは関係ないだろう
マルチページじゃリアクティブできないとでも？ >>859
コンポーネントもSPAに限った話じゃないし
いにしえのJSFやASPNETですらサポートしてる
他のフレームワークもほとんどすべてがサポートしてるだろう >>860
ゴミクズの一味はおめえだよ
中身スカスカのレスいらないから
二度と来るな フレームワークでテストがしやすくなったというのも疑問点が残るよね。
例えばクリックしたら色が変わるってのをどうやってテストをしているのか
書いてみてほしいものだが web e2e test sweet とか
web e2e testing framework とかで検索してみたら？ テストがやりやすいと言う割に
ググらないといけないと言うねｗ >>857
その場合でも各ページの元になるhtmlはサーバが返すだろう？
ルーティングもサーバで処理する。それだとあまり美味しくない。
SPAの利点はWEBサーバのコード不要で静的ファイルを返すだけになり身軽になる事。
クライアントの帯域とコンピューティング予算を利用するスタイルだから、こっちは楽になるのは当然。
APIとDBサーバだけなら開発の負担はぐっと軽くなる。
逆にSPAの限界は、どうやっても肥大するJS。大規模には不向き。
いわゆるマルチページ（初めて聞いたが意味は分かる）が良いならNextでSSRすればいいよ。
どっちが良いという話じゃないし。 >>860
Wappalyzerで国内サイトを
40社程度調べたところだが、React-frameworkで
有名らしいNext.jsもGatsbyほとんど使われてない。
Gatsbyに関してはWappalyzerで集計すらされてない。完全ランク外
ブームといえる状態にも来てないと思う。
名前は有名になってるのに導入があまりされてないのは調べてはみたけども
導入する価値がないと考えたサイトが多い証拠なんじゃないかな >>870
新聞社のサイトで既に動いてるのがあって置き換えると思うか？
大手じゃなく新しいサイトを調べて >>872
劇的にユーザビリティが向上するなら置き換えるのでは？
ようするに大したメリットないってことか ほとんどすべてのサイトでは不要かむしろUXを悪化させるんだからSPAなんてものが流行るわけがない
コンサルさんは飯の種になるから必死に広めようとしてるようだけどな 数学わからないおじさん「数学なんて必要ない！」
英語わからないおじさん「英語なんて必要ない！」
こういう人はいくら必死に必要ない必要ない喚き続けても誰からも尊重されずバカにされてるよｗｗｗ >>876
不安でしょうがないんでしょｗ
精神的安定を得るため叩くしかないｗ
実際に必要ないとしても知れば恐れることなどないものを。
無知とは恐ろしいねｗｗｗ >>872
基幹業務と違ってWebのフロントは短期間でリニューアルする。
大手ほど資金力あるから制限なくStackを選べる。
日経、朝日、読売新聞を見てみたが
web frameworkすら使われてないじゃないかｗ
読売はWordPressだな、CMS
さすがIT後進国
IT先進国はどうか？NY Times見てみたがSvelte が使われてるな
どうやらSvelte採用のトップクラスサイトだったようだ。
Svelte の公式サイトではReactやVueを
traditional frameworksと表現して暗に時代遅れだと言ってるのが気になる
https://svelte.dev/
SpotifyとかYandexも使ってるな
https://www.wappalyzer.com/technologies/javascript-frameworks/svelte >>856
零細サイトを除いたらランニングコストはオンプレミスのが安いし
クラウド要らない派
クラウドはバックエンドの構築、運用ができない企業が使うものだと思ってる お前らが提案するフレームワーク名
毎回変わってて草 >>882
上場企業でもほとんどがバックエンドの構築、運用ができない企業に該当する
開発を外部に丸投げしてるから運用のノウハウもない 本当に良いものは長く使われる
SPAはすぐに次のトレンドに置き換えられるだろう
Svelteなどなどすでにその兆候がある 過去の遺産があれば大規模なリニューアルは難しいだろうよ。
それは否定しない。いろんな事情あるからね。
ただ内部で開発ガッツリしてる系のサービスはおおよそNextなりVue使ってる感じ。
以前みたDMMの記事は面白かったよ。興味があればDMM Insideとか見るといい。 どこそこの大手アプリはうまく行った！
こういうロジックでフレームワークを推奨してくる人には警戒したほうがいい
アプリのスケール感を全く考えてないから
日曜大工ツールセットで作るべき物を巨大重機で作ろうとするようにおかしなことになる フロントフレームワークって基本はSEO切り捨てていい部分のページ向けにまず作ってみるっていうのが大前提だと思う >>886
サイトの規模がトラフィックの事を言ってるならそれは間違いだよ。
単純に作りやすさ保守メンテを考えれば考慮に値する技術が沢山あるという事。 トップページをワッパライザしてSPA使われてねーとかほざいてるゴミ >>888
保守、メンテナンスを考えるとSPA人材の少なさが大きな問題だな
WEB系フレームワーク使う人って、やっぱ、新しいもの好きが多いんだよね
んで、要領良くチャラチャラ生きてきたせいか知らんけど、責任感もない人が多くて、すぐに新しいものに目移りしたり、転職しちゃう
こういう連中に、数年後に、ちょっと前に流行ったあのフレームワークなんだけど、君が作ったやつ、あれメンテナンスしほしいなー、って言うとすげー嫌がるんだわ
ただでさえ少ない人材が、年月を重ねるとまじで皆無になる
で、連中はコピペ人間かよって思うぐらい同じようにこういうんだ、「新しい素晴らしいフレームワークに載せ替えましょう。お見積りはこれぐらいで」
信用ならねぇわ、古くから愛用されて、これから先もずっと生き残ると思われる技術、それを使う技術者こそが信用にたりうる >>889
ゴミはおまえのこと
web エンジニアなら>>859のようにAjaxという言葉を使わない
Ajaxの定義と経緯を調べてこい
おまえが良く使うreactiveについてもはっきりした定義がない https://svelte.dev/blog/write-less-code
SvelteによるReact, Vue批判
コードが冗長すぎてうんこだと批判されてる。
Reactすこし触ったときにアホみたいにevent handler出てきて
なんでこんなめんどくさいことやってんだろうと思ったけど直観は正しかったようだ。
SvelteはcompilerだからJSの特殊さに縛られないらしい
たしかにコードがすごい短い
JS嫌いな人にはあってるかもしれないな テレ朝 react
日テレ vue
フジ nuxt
TBS 使ってない
TBS以外はSPA
TBSもがんばれ まあ正解だけ覚えてりゃいいと思ってる奴はこの仕事は向いてないよ。 >>891
お前がゴミクソじゃねえか
俺はReactHooksが出る前のバージョンでWebアプリは数プロジェクト作ってる
全く問題ないどころかコンポーネント化が完璧にできているからメンテも楽
何が最新好きだよ？最新じゃなくてもSSRじゃ考えられないくらい開発しやすいわ
お前がゴミクソすぎてまったく使えないのはわかった
Ajaxがどうとか今さらそんなもので勝ち誇るなゴミクズ
レベルが低すぎるんだよ
クソみたいなUIしか作れないゴミクズの分際でうるせえわ
さっさとここから消えろ 多分こないだのBlazorくんと同一人物なんだろｗ
聞き齧った話しを言いふらしてちやほやされたいだけ。
おそらく自分では何も作ったことないｗ >>871
マルチページがいやなら、SRP（単一責任の原則）設計といえばいいんじゃね？ｗ
SPAって1ページになにもかも突っ込んでしまってよくない
大きなものを作る時は小さなものの組み合わせにしたほうが良いよね
SPAの方が速くなることがあるのは事実だけど作るのが大変になる ずっとvueやってたけど最近react覚え始めたら難しすぎるわ
vueのcreatedとかmountedとかわかりやすいの名前だったなあって >>878
> 基幹業務と違ってWebのフロントは短期間でリニューアルする。
なるほど（笑）
だからこそさ、フロントの役目はなるべく少なくして
サーバー側でやったほうが良いんじゃないかｗ
フロントとサーバーが同じ言語で出来るのがメリットのように
言ってるけど、分離したほうが良い。そして変化の少ないサーバーサイドと
変化の大きいフロントインドに分けて、フロントエンドのコードはなるべく少なくする
SPAの速いよりも、メンテナンス性の方が大事だろ？
フロントとサーバーが一体化されてるフレームワークだと
フロントを変えようと思った時サーバーまで引きづられてしまう
結局、動的なサーバー処理 と 静的（＋JavaScriptで動き付け）なフロントエンドという
設計のほうが長い製品寿命が得られる ゴミクズ連呼してる基地外は何に切れてるんだろうな
こんな感情的な奴はまわりでも低品質なコードしか書いてない >>894
> コードが冗長すぎてうんこだと批判されてる。
マジそれ。コードが短ければバグも少なくなる。
テストできるようにするのは良いけど、そのために冗長になってテストが大変になってる。
完璧なテストなんかやめて、テストできない部分を意図的に残すが
その部分は最小限のバグのないコードで書けるようにしたほうが良いと思うよ >>899
ﾜｯﾁｮｲ付きならもうちょい分かるのにな >>897
> まあ正解だけ覚えてりゃいいと思ってる奴はこの仕事は向いてないよ。
そこでいう間違いっていうのは、すぐに陳腐化して負債になるコードな
わずか数年後にレガシーコードになってしまうものを覚えてどうする？
そういうコードを書くならちゃんとお前がメンテナンスしなきゃいかんぞ？ >>901
もうライフサイクルメソッドはHooksで置き換えられるからそんなに難しくないぞ Hooks使ってない人は過去に作ったプロジェクトを修正してるの？
それとも工数もらえないから放置？
プロジェクトを再開する時、これはもうレガシーですねとかいって
改修作業するの？ まあもってあと3年だろうな
その後はもう別のオモチャに乗り換えてる フロントは変化しやすいってことを考えると
フロントの処理が多くなりすぎてるんだろうな 大体黎明期に大きく変わって段々落ち着いてくるもんだけどね SvelteもいいけどElmもいいな
とにかくレトロJSと別言語ってのが筋がいい
レトロJSの都合から解放されるだけでなくWASMへの移行にも期待できる
TSも別言語っちゃそうだけどこいつはレトロJSの面影が強く残ってるのが減点 ○○は嫌いなんだ！だからレトロと言おう、レガシーと言おう！
という印象操作。脱jQueryも同じ仲間
レトロとかレガシーとか脱とか言ってるのに
それが現実にならないのは悔しいだろうなぁｗ >>899
おめーはアホだからブレザー野郎と区別すらつかねえんだなゴミクズ なんかQiitaとかでReact始めましたって人が皆classでコンポーネント書いてるのはチュートリアルがHooks対応してないって事なん？ >>913
んーでも実際レトロじゃないか？
ブラウザで動くのがそれしかない&資産（負債）が溜まりすぎて移行できないっていう、言語自体の良さ以外の理由で生き残ってるあたりレトロ臭がキッツい
WASMでそのあたりが変わって行くと素晴らしいことだが、残念ながらまだもう少し時間がかかりそうだ >>908
んなもんどんなフレームワーク使っていても同じだろゴミクズ
バックエンドのフレームワークも数年で変わってるだろゴミクズ
フロントが変化しやすいってなんだゴミクズ
テメーが使えてねえだけだろ >>916
なぜブラウザでしか動かなかったらレトロなんだ？
そのブラウザはどこでも動くんだがｗ > WASMでそのあたりが変わって行くと素晴らしいことだが
そのWASMはどこでも動かない（笑） >>918
ブラウザでしかうごかないからレトロとは言ってない
ブラウザで動くのがそれしかないという理由で生き残ってきたのがレトロ臭キツいって言ってる >>917
重要なのはフロントとサーバーが分離できてるって所
一つでどでかいシステム作るよりも
小さなコンポーネントを組み合わせたほうが良い >>928
今まで他の言語が採用できない理由を考えたほうが良いよ
採用する機会はいままで幾度となくあった
もともとHTMLのscriptタグはJavaScript以外にも
対応できる設計で、実際VBScriptだって使えた。
一時期はRubyとかPythonとかも動かそうという動きがあった
だがそれが実現しなかったのは、JavaScriptほどのメリットがなかったからだよ
JavaScriptは生き残ってきただけじゃない
他の言語が参入できなかったという事実を無視してはいけない >>915
確認したらclassになってるわ
これは公式ドキュメントから読む真面目な層がかわいそう＆公式がんばれ フレームワークを使う時は、あとからフレームワークを
捨てられるように設計することが重要なんだよな よく考えたらもう一年近くクラスコンポーネント書いてないわｗ
全部ファンクションコンポーネント＋フックAPI
createClassはそうでもなかったけどクラスコンポーネントはホンマ嫌いやったわ。
全部単なる関数で書けて最高に幸せ。
そもそもJSにclass構文持ってきた池沼は地獄に落ちろと思う。 wasmに期待してる人は一度使ってみなよ。期待してるようなものと全然違うことがわかるから Ruby on Rails では、ビジネスロジックをサーバー側へ寄せていく。
GUI には、React を使っても、コンポーネントとして使う。
フレームワークとしては使わない
Bootstrap なら、素人でもレスポンシブ対応できる。
規約だけのフレームワーク・Stimulus も使う
Reactive なら、Stimulus Reflex とか
pjax(ajax + historyAPI のpushState)も使える。
HTML のbody だけの入れ替え。
head 部分は送らないから、エコ
他にも、メール送受信、S3 へ保存、画像変換とか
デフォルトで、一式揃っているから、新規起業は、Rails で作るのが多い つまりReact、Vue、Svelte、Blazorの完成形がPHPということでよろしいか？ >>922
メリットがなかったんじゃなく単にセキュリティ担保が難しかっただけだな >>900
デスクトップアプリは全部そういう構造なんだが
設計ちゃんとしてれば詰め込みすぎでヤバいなんてことにならない メニューの階層が深すぎて設定項目がどこか見当たらないのはその為か >>926
マジでそれ。実際に書いて使ってみれば一発でわかるような事がわかってないレスが多い。 Blazor(wasm)を実際に使ってるが期待以上だった
バイナリサイズ、速度は今でも十分悪くないが今後急速に改善されるだろう 速度は今でも十分悪くない>>675-677
今後急速に改善される>>703 >>934
体感的には全く問題ない
そう言ってるだけ >>918 >>920
JSはbrowserで動く唯一の言語という特権が
あるから今の地位がある。
優遇されてるのにweb frameworkではJSは人気がない。
WappalyzerでみてもJS系web framework利用者は少なく
最大シェアでもExpressの7%
1%以上のシェアのものはExpressとNext.jsしかない
ちなみにASP.NETはシェア52% >>922
WebAssemblyならJSの縛りはなくなるし
JSを完全に捨て去ることができる。 しかし現実は圧倒的にjQueryが
シェアナンバーワンなのである JavaScriptって1回死んだよな
それをGoogleがAJAXで復活の呪文させてしまった
あのときJavaScriptでは無理だからちゃんとしたプログラミング言語とUIツールキットを載せようってなってたら違った未来があったのかな >>934-935
Wasmはbrowserで実行されるわけだからユーザーが
体感的に気にならないスピードになればいいだけだ。
C#使える人にとっては開発のスピードはすでに最速になってる。
SoCのスピードは毎年30%近くあがってるから、
ソフトウェア変えなくても今1秒かかってる処理が
まったく気にならないレベルになってしまう。 >>938
jQueryおじさんそれweb frameworkじゃないから
936の統計に入ってない
機能不足 >>941
そりゃjQueryはフレームワークに圧倒的な差で勝ってしまうからなぁ
DOM APIの薄いラッパーなので速度は早い
ライブラリのサイズも小さい
HTML/CSSとの連携で最小限のJavaScriptコードで実現するから jsが駄目ならtsで良いじゃん。c# も使えるけどtsが言語的にc#に劣る部分なんてほとんど無いよ >>936の統計に含まれてないのは
jQueryが圧倒的に勝ってしまうから？ jQueryって云わばフレームワークを使わない場合のPHPみたいなもんだしな >>942 >>944
jQueryおじさんって複数いたのか
すでに書いたように機能が不足しててweb frameworkに分類されない
最低でもrouting機能くらいないとweb frameworkとは呼べない
jQueryはJS Libraryの項目で集計されてる
https://www.wappalyzer.com/technologies/javascript-libraries
>>943
TSはJSに変換する以上、どうしてもJSの機能や速度に制限受ける >>947
JavaScriptでルーティングをすること自体がおかしい
JavaScriptが無効だと動かないサイトになるだろ >>947
機能はc#並みにはあるよ。
jsとwasmの速度の違いはリソースのコンパイルとロードにかかる時間だけだよ >>948
機能も目的も違うしjQueryはweb frameworkと
比べても意味ないんだけどそれわかんないの？
DBとかbackendの開発したことないでしょう？ とりあえずjQueryはスレチだからやめとこうぜ。 レス数が950を超えています。1000を超えると書き込みができなくなります。
