Vue vs React vs Angular Part.5
レス数が1000を超えています。これ以上書き込みはできません。
実際どうなん？
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/
※前スレ
Vue vs React vs Angular Part.4
https://mevius.5ch.net/test/read.cgi/tech/1591869705/
★ここではjQuery, Ruby, C#, Blazorの話題は禁止です
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
Svelte, Next, Nuxt, Gatsby, VuePress, RedWoodなどはおｋ。 1年後の世界へ行こう！
／'⌒`ヽ、 Blazorが世界1のシェア取ってるはず…
ヽ、┗ ノ
`ーｰ' γ⌒ヽ／ﾌﾞﾚｷﾁ＼ ／'⌒⌒ヽ、
,-ｰｰ-､ .||~￣~|/-O-O-ヽ|. （ ┃ ⌒ヽ
/ ┃ ） || 6| . : )'e'( : . |9 ＼ ━┛ ）
.（. ┃ ） || ｀‐-＝-‐ ' ＼＿＿_,ノ
ヽ､＿＿,ノ || ＿(つ¶¶と)＿_
／||'''''| 三 | |'（⌒）
／ '―――――` ￣ ＼
`＝＝＝＝＝＝＝＝＝＝＝＝' ￣￣￣| | ｌｌヽ _| ヽ
| | |l￣| | l Blazorって未来ではどうなってんの？
| | / ´＼ /
| | ヽ､＿ ｀＾イ
二二二 」 ＿ ＿＿ ｌﾆ二二ｌ､ ＿＿＿_
─┴┐ ⊆ﾌ＿)＿_./ ┌ヽ ヽ┐ ／´ ｀＼
二二二二二二ｌ / | | | |. / ヽ
＿l＿＿＿＿_| ／｀ｰ─‐|＿| |_| / ヽ
| ／｀ヽ__, ─ ､ノ |─l ｌ l
|───/ ／lﾆ/ /二ﾆluul. | ! え？そんなゴミないよ
| ___|￣ | | |_|. l /
└─（ ）(ﾆ| ￣|./二ﾆ) ヽ /
￣￣ / ） >━━━━━━ く
｀ー ´ / ヽ ￣￣￣| | ｌｌヽ _| ヽ
| | |l￣| | l Blazorって未来ではどうなってんの？
| | / ´＼ /
| | ヽ､＿ ｀＾イ
二二二 」 ＿ ＿＿ ｌﾆ二二ｌ､ ＿＿＿_
─┴┐ ⊆ﾌ＿)＿_./ ┌ヽ ヽ┐ ／´ ｀＼
二二二二二二ｌ / | | | |. / ヽ
＿l＿＿＿＿_| ／｀ｰ─‐|＿| |_| / ヽ
| ／｀ヽ__, ─ ､ノ |─l ｌ l
|───/ ／lﾆ/ /二ﾆluul. | ! え？そんなゴミないよ
| ___|￣ | | |_|. l /
└─（ ）(ﾆ| ￣|./二ﾆ) ヽ /
￣￣ / ） >━━━━━━ く
｀ー ´ / ヽ >>1
SvelteはVueの５０倍速いって書いてたんだが？ 前スレの>>988がぜんぶ間違ってて草
.NET Coreはcross-platformになって
ASP.NETはLinuxでもMacでも動く時代になってる。
open source
App serverのIIS縛りもなくなっている。
Linuxでも無料で使える。
Dockerもsupportされてる
時代はASP.NET CoreとC#なのだ あと下の987も間違ってる。
Wappalyzerの分類でもWordPressはCMSの分類になる。
Wappalyzerのweb frameworkのシェアランキングの対象外だ
Web appとweb siteの区別、
CMSとweb frameworkの区別がつかないのなら知識はjQueryおじさんと大差ない。
987 名前：デフォルトの名無しさん[sage] 投稿日：2020/07/29(水) 22:56:11.03 ID:z6Fnx3oM [5/5]
WordPressが全ウェブサイトの35%(CMS市場では6割超)のシェアなのにaspが過半数なんておかしいと思ったｗ
https://www.similartech.com/compare/asp-net-vs-php このスレが少しでも有益になるといいなと。
2020年の現状ポストjQueryとしてのフレームワーク/ライブラリ戦争が一段落した時期だと思う。
メジャーなのはスレタイのVue, React, Angular。異論はあるだろうがスレタイに沿う。
ただ微妙に性格が違う。
大きくViewライブラリ、SPA、SSRで分かれるから整理したい。
Viewライブラリ(仮想DOM/リアクティブ)
Vue.js
React.js
SPA
vue.js + vue-router
react.js + react-router
angular(フルスタック)
SSR(フルスタック)
nuxt.js(vue系)
next.js(react系)
angular universal
大事な事だが、どれを使ってもリアクティブであり、CLIでプロジェクトを作ってVSCodeなりで環境つくればHMR(ホットリロード)できる。
現状優勢なのはnext.js。
純粋なフルスタックSPAはangularのみ。angularは他と違い、まずSPAであり、次にuniversal(SSR)もできる感じ。
nuxt、nextはまずSSRであり、SPAもやろうと思えばできる感じ。
vue reactは既存のWEBサイトに追加して利用する事もできる。（script タグを追加する)
jQueryの代用として活用するなら良い。
俺もまだ未熟で間違ってたらすまんが訂正してくれ。 >>1
これテンプレート入れる必要ある
web frameworkのシェア、ランキング
https://www.wappalyzer.com/technologies/web-frameworks
ASP.NETが圧倒的
ASP.NET: 52%(C#)
Laravel: 8% (PHP)
CodeIgniter: 5% (PHP)
Ruby on Rails 9%(Ruby)
Express 7%(JS)
Next.js 2%(JS) >>8
例えそうなっていようが一度根付いてしまったイメージは
払拭されねえよ
MS関連は基本インストーラーのウィザードでないと
インスト出来ないのが一般大衆のイメージ
LinuxとかJavaScript使ってるエンジニアとって
MS社の最近の動向なんて興味も関心も無い
たとえ出来たとしてもわざわざ乗り換える理由なんてない
完全にLinux対応と謳いつつMS特有のエラーが
発生したり、
時間が経った後に金銭要求されたりなど色々と
勘ぐってしまう
あとMSは大文字小文字の使い方が
Linux圏の人間からするとなんかズレてる
そういう細かいところが好まれない ￣￣￣| | ｌｌヽ _| ヽ
| | |l￣| | l jQueryって10年後ではどうなってんの？
| | / ´＼ /
| | ヽ､＿ ｀＾イ
二二二 」 ＿ ＿＿ ｌﾆ二二ｌ､ ＿＿＿_
─┴┐ ⊆ﾌ＿)＿_./ ┌ヽ ヽ┐ ／´ ｀＼
二二二二二二ｌ / | | | |. / ヽ
＿l＿＿＿＿_| ／｀ｰ─‐|＿| |_| / ヽ
| ／｀ヽ__, ─ ､ノ |─l ｌ l
|───/ ／lﾆ/ /二ﾆluul. | ! シェア80%に到達したよ
| ___|￣ | | |_|. l /
└─（ ）(ﾆ| ￣|./二ﾆ) ヽ /
￣￣ / ） >━━━━━━ く
｀ー ´ / ヽ
https://w3techs.com/technologies/history_overview/javascript_library/all/y
2019年1月時点でのシェア 73.6%
2020年1月時点でのシェア 74.2% (+0.6%）
2020年7月時点でのシェア 75.9% (+1.7%）
予測
2021年1月時点でのシェア 76.5%
2022年1月時点でのシェア 77.0%
2023年1月時点でのシェア 77.5%
2024年1月時点でのシェア 78.0%
2025年1月時点でのシェア 78.4%
2026年1月時点でのシェア 78.8%
2027年1月時点でのシェア 79.2%
2028年1月時点でのシェア 79.5%
2029年1月時点でのシェア 79.8%
2030年1月時点でのシェア 80.1% フレームワークにとって脅威なのは
VanillaJS（つまりJavaScriptライブラリを用いないJavaScript）が
強化され続けているという所
つまりフレームワークでこんなこと出来るようにしたました
→VanillaJSで簡単にできるようにしました
→フレームワークいらねぇじゃん
という流れができてしまってる >>14
これが理想的な姿だと思うが
何故フレームワーク開発者目線なのかが分からない
利用者にとってはシェア何パーセントとか
大手が使ってるとか糞みたいにどうでもいいことで
動くもので有れば
なおかつ便利で極力今までと似たようなことをやるための
余計な再学習コストがかからないもので
あれば、情報が多ければなんでもいい
大手が導入して画期的だったとしても
ググってQiitaに安定したサンプルが出てこない
ようなフレームワークは使う価値がない
本来はフレームワークなんか導入せずに
バニラの機能が進化してくれるのが1番いい >>10
SSG
Gridsome(vue系)
Next.js(React系)
Gatsby.js(React系)
Scully(Angular系)
これも追加で
ちなみにNext.js公式はSSG推し gridsomeってのがあるんか…
vueのssgはvuepressが強いのかと思ってた >>11
サーバーOSの8割くらいがUnix系なのに、ASP.NETがそんなシェア有る分けない。
嘘つき。 >>18
大手企業の業務システムはWindowsばっかりだよ >>20
デスクトップはWindowsでも、Webサーバーの8割はUnix系。
MSのクラウドですら75%以上はLinux。 前スレでWappalyzerがソースだとか言ってるレスあったが
寧ろバックエンドテクノロジーがWappalyzerに検知されるのってサーバーセキュリティがザルだって言ってるようなもんなんだが
ちゃんとサーバーチューニングしてたらバックエンドに何使ってるとかは普通はでない >>21
信用が大事なとこはWindows鯖が求められるよ
マイクロソフトの安心感が大事 >>19
残念ながら、jQueryはVanillaのJSと同じことを
簡単にかけるのであったら便利なわけです。
「同じこと」というのが重要な所
フレームワークはやり方を全く変えるので
やり方を覚えなくてはいけませんが、
jQueryはやり方は同じで簡単にかけるだけなので
楽になるという効果が残るわけです。 >>24
・MS環境は、金がかかり、ずっと金をせびられ続ける。
・MS環境は、他のものと組み合わせるのが難しい。 >>24
MSはproprietary（独占）でLinuxはオープンソース Linuxとか野良OSじゃん
Red Hatのサポートがあってギリギリ許される
マイクロソフトなら最初から全てが安心 使うだけじゃなくて自分で開発したいって気持ちがLinuxに向かわせる 新機能を追加したいって思ったときオープンソースなら自分で開発できる >>27
MS環境が金がかかるのはOSが無料じゃないから当たり前だけど
Linuxのクラウドも有料のものしかないから金かかるよ
あとLinux環境って他のもの（WindowsやmacOS）と組み合わせるの簡単だっけ？
他のOSと組み合わせるのが難しいのはどれも変わらないと思うよ というか、レンタルサーバーって、大体 apache を使ってるから、
.htaccess とかでパーミッションの設定方法などがどのレンタルサーバー屋でも
基本的な部分が共通している。
だから、一度覚えれば、もっと安くてよいサーバーに移ったりし易い。
MS製だとそういうわけにはいかない。
どこも全体的に高めだし、選択肢は狭まるし。
Unix系だと、はっきり言えば、Xrea、CoreServer、SAKURA、Lollipopなど安い
ところで済ませられるが、MS製だとそんな安いとこない。
それと、やっとサーバーだけはMSの呪縛から離れられてほっとしている人は多いはず。
そこを敢えてMS製クラウドなんてに行くのなんて、自分で墓穴を掘っているようなもの。 MSはWindows10からスパイウェアのようにMSと通信するようになって企業秘密がMSに全部筒抜けかもしれない >>33
Unixサーバーは、多種多様な掲示板用CGIや、WordPressなども無料でころがっているので
安いし便利だし、情報もあふれている。
対してMSのものは、とにかく金がかかる。
それに、WebサーバーをWindowsやMacと連携する必要も感じない。 apacheとかって、RubyやJava(TomCat)とかとも連携していたりして、
まとめてローカルサーバー環境をパッケージとしてインストールできたりするし、
cygwinなどとも連携し易い。
WSL2とかより、cygwinの方が便利なことも多いし。
MS以外のほぼ全ての開発慣用がapacheやMySQLなどはどこかで配慮しているが、
MSのサーバーは無視されている。 >>36
> Unixサーバーは、多種多様な掲示板用CGIや、WordPressなども無料でころがっているので
> 安いし便利だし、情報もあふれている。
え？それが？ Uinixサーバーが無料で転がってるんじゃなくて
CGIやWordPressが転がってるだけだよね？
それらはWindowsで動くよ >>37
> WSL2とかより、cygwinの方が便利なことも多いし。
矛盾してるよね？
WSL2＝Linux。Linuxよりもcygwinの方が便利って言ってるの？
cygwinなんてsystemdすらないのに >>37
> MS以外のほぼ全ての開発慣用がapacheやMySQLなどはどこかで配慮しているが、
cygwinも配慮されてるってこと？
配慮されてないならWSL2の方が良いってことになるよね。
WSL2はLinuxだからapcheやMySQLなども動くし >>38
Unix用に書かれたcgiを敢えてWindowsで動かすと言う茨の道を歩む必要は無い。
どうして無料で済むものを敢えて、変な環境な上に有料にしてしまうのか。
IEよりも悪い。
>>39
WSL2は、内部でLinuxのカーネルまで動かしてしまうから起動も遅いし、
Windowsとのファイルのやり取りも難しいし、cygwinではなかったさまさまな
厄介を自ら引き込むようなもの。 CGIは、Unix互換OSですらパーミッションやapacheの設定、cgiフォルダの位置や
名前などの僅かな違いでトラブル事が多い。
WindowsOSなどは、トラブルが100倍になりそうだから使わない。
金までかけて、敢えてトラブルに巻き込まれる必要は無い。 >>41
> Unix用に書かれたcgiを敢えてWindowsで動かすと言う茨の道を歩む必要は無い。
cygwinは配慮されてるの？
WSL2はLinuxだから、その茨が解決されたって話なんだよ。
> WSL2は、内部でLinuxのカーネルまで動かしてしまうから起動も遅いし、
内部でLinuxカーネルを動かしてるのにわずか2秒程度って速いって言わないか？
https://www.atmarkit.co.jp/ait/articles/1906/14/news019.html
> 「Hyper-V仮想マシンサービスを使ったLinuxの仮想マシンならば、これまでもあったではないか！」と
> 思われる方もいるかもしれない。だが、この軽量ユーティリティーVMを使ったWSL 2では、
> 仮想マシン環境が起動し、bashがコマンドを受け付けるまで2秒程度という速度で起動できる。
実際使ってみると2秒もかからない。1秒未満？程度などでもっと驚いてるが
Linuxカーネルは起動が速いね！ 設定ファイルがスクリプトってとこに、誰も疑問を感じなかったんだろか。 >>18
すぐ上にASP.NET CoreはLinuxでもMacでも
動くようになってるとかいてるだろ
あと法人は長期サポートされるMSの技術を使うのを好む。
web frameworkは273万件のサイトからデータ収集してる。
おまえがASP.NETの強さを知らないだけ。
Wappalyzer tracks over 2,733,000 websites and 61 technologies in the category Web frameworks. >>25
お前がいつものjqueryキモジジイということだけはわかったゴミクソ メルカリはNext.js使ってるようだ。
国内では数少ないNextサイトのようだが
ほとんどのページでふつうにページ全体を読み込んでるな
SPAにはなってない。
メルカリの使いづらさは異常
PCから使っていてお知らせクリックすると
アプリをインストールしろとポップアップが出てくる。
アプリじゃないとできない処理がたくさんある。 >>43
そんなの信じない。
実際やってみると絶対遅いから。
Visual Studioだってそうだし。
実際に使えるまでに50秒くらいかかる。 SPAはそれで管理するページすべてを
一つのアプリとしてみなす必要があるから
メンテナンスがしづらくなるんだよ
意味的に一つのアプリになってればいいけど
例えばヘルプページみたいに単独で独立して表示する場合
アプリとは分離したほうが良い
っていうようなことまでちゃんと考えないといかんよ？
SPAフレームワークを使うときは >>34
どうせクライアントはWindowsの世界
ならサーバーもWindowsで統一したほうが管理しやすいし、操作ノウハウも一本化できて解りやすい >>48
> 実際やってみると絶対遅いから。
やってないような言い方だなｗ >>48
Linuxカーネルの起動にそんなに時間がかかるわけ無いだろうｗ
かかったとしても数秒だ
だがしかしWSL2はその数秒未満でbashが起動できてる
謎の高度な技術が使われてるようだな >>50
そんなことない。
サーバーは、Windowsが生まれるずっと前からUnixの世界。
その世界を新参者のOSが壊すことは出来ない。 むしろ、Windowsの方がUnixに侵食されてきている。
例えば、cygwinやWSL2。
AndroidモバイルもUnix、MacもUnix。 >>42
実際にはそういうUnix、Linuxならではのトラブルがきれいさっぱりなくなって快適な環境が手に入る
しかも手厚いサポートと保障のおかげで安心して運用できるからしっかりした企業に選ばれる
名だたる大企業は安かろう悪かろうのLinuxを選ぶなんてことはしない >>53
LinuxはWindowsよりもあとに作られたOS
Linuxは新参者である >>54
> むしろ、Windowsの方がUnixに侵食されてきている。
侵食（？）してるのはMS自身では？
MS自身がやってるのだから侵食ではなく取り込みというべきだろう >>55
> 実際にはそういうUnix、Linuxならではのトラブルがきれいさっぱりなくなって快適な環境が手に入る
だからWSL2=Linuxで快適な環境が手に入るわけだね >>45
業務で扱うならやっぱりマイクロソフトだよな
他人の作ったOSSオモチャ弄り遊び半分で仕事してるWEB系中小零細企業はLinuxでもいいのかもしれんが >>57
ミイラ取りがミイラになったでござるの巻き。 >>61
LinuxはMSに勝てる。ソフトウェアが無料でもそれを使ってサービスを運営すればビジネスは可能
って言ってたら、MSがLinuxを使ってサービス運営しちゃいました。ってこと？ LinuxでMSの儲けを奪いに来たら、MSの儲けになってしまったでござるの巻き。 Windows vs Linux Mac 論争は
不毛だからいいかげんやめましょう
最低限webの話であってくれ 逆に、Linux を利用したことで、かえって、Linuxの普及を加速することとなった。
歴史を振り返ってみれば、WSLの導入はMSの終わりの始まりであったとさ。 Githubもマイクロソフトの物になった
Linuxもいずれそうなるだろう >>33
OSが無料だからVPSとか借りる場合月額かなり格安のプランからある >>68
いくらぐらい？
https://www.kagoya.jp/windows/
初期費用無料！1日単位で使える
Windows Server搭載のVPS
日額 38円
月額上限 1,045円 >>70
WebArena Indigo Mem:1GBで349円〜 >>45
たかだか273万件のサイトｗｗｗｗ
さすが詐欺会社の調査はショボいなｗｗｗｗ
こちらは12億6090万9305件のサイトを調べた結果↓
https://news.mynavi.jp/article/20200223-979011/
asp含むms製がトップ取れたのは2016年から3年間足らず。
現在は一位nginx、二位apache、三位有象無象のその他勢、四位ms
現在のシェアは15%にも満たないｗｗｗ
失望されて棄てられたんだねｗｗｗｗ
つまり数年前から「Apacheの代替争い」が始まり、それを商機と捉えたmsも名乗りを上げた。
結果みんな失望してnginxに乗り換え、nginxが「Apacheの代替争い」に勝利した。
一方ms製品は凋落したｗｗｗｗｗ >>73
それはweb frameworkの話ではない。
Windowsのweb serverが動いてるからと言ってASP.NETというわけではない。
バカは黙ってろ >>76
ということはaspのシェアはさらに下と言うことだなｗ
まじゴミｗｗｗｗ >>77
>>8を読めバカ
LinuxでもASP.NETは動く。
だからWeb serverとweb frameworkのシェアに直接の関係ない
アホばっかり >>73
nginxの後ろでWindows asp.netが動いてるんだろ
そこまで調べてから反論しろよ >>72
Windows VPS SMALL 3ドル メモリ:2GB
https://www.hostens.com/vps-hosting/
OSの値段なんて大差ないんですねー Linuxは安いって嘘だったのか
メンテナンスコストまで考えたらWindowsのほうが全然いいな >>78
動いたとしてもお互い選ばんやろ
ASP使うヤツはLinuxサーバー選ばんやろうし
Linux使うヤツはASP選ばんやろ
もし居たとしてもそれは異端中の異端 >>80
そんな海外鯖まで言い出したら無料も普通にあるだろ >>78>>79
linuxかどうかの調査じゃないんだが。バーカｗｗｗ Win鯖 + ASP.net Core + React 組んで良さげだったから
次はDocker上のLinux (Alpine or CentOS)でやってみようと思ってる >>86
そういうデータ持ってくれる？
持ってこれないよね？思い込みで語ってるだけだから
そういう思い込みで語ることこそ「技術者にとって恥ずかしいこと」だから >>82
知識が古い、古すぎる
Linux + ASP.NET Coreはベストの組み合わせ
ライセンスフリーのOS、Linuxと
最高の開発生産性のASP.NET CoreとC#開発 ASP.NET Core MVC & Webapiのほうは冗談ぬきでめちゃくちゃ速いな
このレベルの最適化が出来ればいずれWasmはどうなるかわからんがSSRだったら最速になるんじゃないのこれ 別にいいじゃん、俺もハリウッド映画のｽｰﾊﾟｰﾊｶｰみたく
キーボードだけでCUI OSをコントロールして射精してたもんだよ
そういうのがｶｯｺｲｲ時期は誰にだってあるんだよ、中学時代とか Web開発者が
MS製品好き好んで使うわけねぇだろ
情報が古いとか新しいとかそれMSが
自社で謳ってる文句でしょ？
そんなの信じるかよ
MSとLinuxはファイルシステムの基本的構造から
して違うんだわ
MSはLinux互換なんか気にせずに自社のやり方
貫いてりゃいいだろ。互換対応しても使わんから
逆になんでLinux互換対応なんか作ろうとしてんの？
Winだけで動くソフトだけ作ってりゃええやん >>95
Visual Studio CodeもMS製品なわけですが >>94
ワッチョイなんてつけるなよ
5chは匿名だからいいわけ >>95
TypeScriptがMicrosoftなの知らないアホな人がまた来た。
Visual Studio Code使ってる人たくさんいるのも知らないようだ。
おまえが感情論と古い知識で止まってる間に
Microsoftはオープンソースとcross-platformに力入れる企業に変わってる。 OS最強 Windows マイクロソフト
IDE最強 VS マイクロソフト
エディタ最強 VSCode マイクロソフト
バージョン管理最強 GitHub マイクロソフト
クラウド最強 Azure マイクロソフト
言語最強 C# マイクロソフト
ここまできたらもうわかるだろ
SPAフレームワーク最強 Blazor マイクロソフト
出たばかりだからまだ少し粗があるが時間の問題だ >>102
どれもこれも、優越的地位を利用してシェアをとったものばかりで、
中味は大したことない。 Xamarinはどうなりましたか？
Silverlightはどうなりましたか？ vscodeは遅いだけ。
IDEの補完機能も大したことない。
デバッガはまあ、強力ではあるが、商用のIDEとしては特に目立って優秀と言うわけでもない。
TurboDebuggerやWatcomのIDEなんかも、成長させていけばあのくらいにはなっただろう。
金に任せて大量のプログラマを使って高機能にしてるだけ。
起動速度も処理速度も遅く、サイズがでかいのでダウンロード、インストールに時間が狩る。
C#も、Javaと比べてちょっと優れている程度で、最強と言うほどではない。
C++とは実行形態も速度も違うし、比較は出来ない。
githubは原則的にオープンソース専用で、企業秘密的なものには使いにくい。
ネットにアップロードした段階で暗号かけても、運営の人には見れてしまうし。
Azureは全然最強ではない。
どれもこれも、誇大宣伝ばかり。 しかも、blazorは、最初から将来性が無い。
そのうち、MAUIに主力が移るわけだから。
しかし、そのMAUIも、中途半端で終わるだろう。 Svelteは書き方がVueとほぼ同じ
thisがない(仮想DOMがない)ように作ったらパフォーマンスが良くなるってのが売りなのかな
Vueでいいじゃんって思われてるのか開発が進んでないような気がする でも、制作側の都合としては、動きのあるダイナミックなサイトにしたいわけですやんか。
クライアントにどんだけ大変だったかご説明差し上げられますし。
それに、見る側の立場では、動きのあるダイナミックなサイトなんて願い下げですわな。
動いた瞬間そっ閉じです。
するとどうなります？
誰も見ないんだから、クライアントは対策を発注しますがな。
何とかしてクレメンスと。
ほら、次の仕事につながった。 > でも、制作側の都合としては、動きのあるダイナミックなサイトにしたいわけですやんか。
ああ、顧客が本当に欲しかったものとかでググったほうが良いよｗ >>86
こういう事言っている奴はmacかっこいいとでも言いたいのか？
正直開発はwindowsで何の問題も無い訳で >>113
開発フェーズじゃなくて運用開始後の事考えてんの？ >>109
native appとweb appの区別もつかないアホ
MAUIはnative app用だからweb appは含まれない
>>107
Xamarinは名前が変わって進化する
https://github.com/dotnet/maui >>89
>>45
いや結局法人はWindowsを選ぶんだろ？ >>110
Svelte公式によるとReactよりも高速らしい
Reactはインタープリタがあるから遅いとかいてた
JSXからJSの変換で速度低下するってことだとおもう
コンパイルするからコードが短く、Reactより速いと言ってるけど
ユーザーはまだ少ない感じだな >>115
失敗したから名前変えた民主党や密航朝鮮人みたいなもんか。 >>116
法人といってもいろいろだからな
技術力と予算だろ
技術力はあるがお金は節約したい企業や個人はLinuxでASP.NETを使う
トラブル時にMSの有料サポートに頼りたいならWindowsで使う
あとはDBがLinux版しかない場合があって予算の都合で
同一サーバーで動かしたい場合とかもLinuxになる。 言語やフレームワークワークは後ろ盾の強さがかなり重要だから、Svelteが真に素晴らしかったとしても、流行らずに死ぬかもしれない クライアントがAndroidスマホだから都合が良いんだろうね >>117
webpackでpackingした後ならそれ関係なくね？ TwitterのUXって正直なところあまり良くないと思う
SPAを導入した結果、本来必要ない複雑さが生じて使いにくくなってる
5chぐらいシンプルな作りのほうが使いやすいよ SPAだと気軽に複雑化にできることが問題
いらんとこまで複雑化しちゃうんだよね Twitterいいじゃん
開きっぱなしでも新着とか増えてくのすごくない？ >>130
恥ずかしい云々っていうより
Windowsサーバーでサーバー管理してる日本の大企業が単純に印象悪いってだけだけどな あわしろいくやさんも言ってるけど、Windowsを恥ずかしく思わない時点で、日本のITは終わってるんだよ。 韓国やアメリカで技術者がWindows使ってると言えば笑われる案件ですよ。 そもそも日本以外ってiPhoneのシェアそこまで高くないしプログラミングなるならMacとか言うのは日本くらいやろ >>136
Ubuntuなんてスパイウェアだろ
Linuxのなかで最低 >>128
永遠にスクロールしていくのイライラしないか？
タイムラインをどこまで読んでも終わらない。
新着はタイムリーに表示されるが
過去のtweetの検索性がひどく悪い。
blogのように過去の発言を少しずつ読んでいく、という
ような使い方ができない。
カレンダーとかpaginationとかがないのがつらい
>>129
たしかにハッシュタグ無限にあるのに検索が速すぎて
どうやって実現してるのか気になる >>139
until:2020-07-01 from:accountname Windowsは
クライアントとしてはそこそこ優秀だと思うが
サーバとしては論外
sqi serverとかASP.NETとか
IISみたいなのは申し訳ないがNG >>140
コマンド一覧みたわ、コマンド使えば意外といけそうだな
until, since, from以外にもlang:jaとか
GUIで詳細検索できるようにすればいいのにな
過去のtweetをすぐ表示できないからやらないかもしれないが >>145
-"キーワード"とか-from:user_id
で除外とかもある > nuxt、nextはまずSSRであり、SPAもやろうと思えばできる感じ。
これは間違い。SSRをやろうと思えばできるし、SPAもやろうと思えばできる
ツイッターのハッシュタグ検索なんてただたんにハッシュタグテーブルがあるだけで特殊なことしてないよ
要はDB内で木構造(インデックス)使ってるし、ロジックもシンプルだから早くて当たり前 ReactのSSRってどうやってやるの？
react-dom/serverのrenderToStringでhtmlを書き出せたが
ボタンをクリックしたときのjavascriptを書き出せない
ReactのSSRは中途半端ってことはない？ <button>a1</button>
ボタンをクリックしたときtextContentをa2に書き換えるとする
SSRならどうなる？
１．変更分だけをサーバーで生成
２．HTML全部をサーバーで生成
３．クライアントでtextContentを置き換える >>142
きっとWindowsで嫌な目にあったんでしょう
察してあげなさいよ、かわいそうに >>153
クライアントで書き換えたらサーバーはそのことを知らないままにならない？
他の処理でSSRしたときにa1に戻ってしまわない？ ハァ？他の処理でSSR？
根本的に理解してないだろ魔法じゃねんだぞ フレームワーク乱立はよくねえな
責任感が強いマイクロソフトに集約すべき 責任感ねぇ
「MSさん？互換性と言う言葉をご存知ですか？」 MSにケツの穴まで見せそうだな
反抗心を失ったら人間終わり 後方互換性に1番気を使ってるのはマイクロソフトで間違いない 金のために互換性保ってるだけで、正義のためじゃないだろ。 C
C++
J++
J#
C#
F#
VB
VBA
VBS
VB.NET
JScript
TypeScript
Win32 API
Windows Forms (WinForms)
Windows Presentation Framework (WPF)
Universal Windows Platform (UWP)
Electron
Xamarin
React Native
.Net Framework
.NET Core 3
XAML Islands
一体何で開発したらええんかのぅ？ >>166
MS には他にも、MFC, Razor, Blazor, .NET MAUI, SilverLight がある。 >>166
迷うはずないやつがいくつも混じってるぞ Ubuntu使ってるやつのカラーセンス疑うわ
あ、俺も使ってた… >>168
あ！量販店の店員さんですか？
Vue とReact とAngular
どのメーカーが良いですかねぇ Linuxは野良ツール多すぎて迷うよなー
マイクロソフトを信用してとりあえずコレだけやっとけ的なものがない
どれを選んでも中途半端でトラブルと縁を切れない >>172
自分の能力が低いって自己紹介じゃんそれ >>173
そういう考え方が雑魚っぽい
苦労を自分から背負い込むスタイルとか非合理的でしょ >>175
それソケットの型とか電圧が違うからって警告出ませんか？
サーバーのコンセントにささらないと困ります。 C#ってunsafe、Span、refがあるから低レベルの爆速プログラミングもできるんだな
こんなんwasmに事前ビルドされたらJSが速度で勝てるわけないじゃん wasmはjsエンジンの（一部の）上で動いてるから、コンパイル後のピーク速度は同じなんだけど。ネイティブGCも無いからGC付きクソデカランタイム動かしてたら速度メリットも消えちゃうんだけど
https://qiita.com/karszawa/items/0bd6e7aa0b638a8e9ee2 そのうち逆になるだろ
wasmが一番下のレイヤーになってJSはその上で動く vueユーザーはvue3に備えてこれ読んどきなさい
Vue Composition APIでストアパターンをスマートに使って状態管理をする
https://qiita.com/resessh/items/ab09ec925ca49d02caae >>181
Reactに寄ったとは聞いてたがマジで寄ってるなｗ >>178
C#はネイティブメモリを安全に活用する機能があるのでメモリ効率がすごくいいよ
この機能が追加されたおかげで.NET Coreの全体的なパフォーマンスが急激に上がったのは記憶に新しい
スタックで済むところはスタックで処理できるから従来のC#、Java、JavaScriptのように必要のないところでオブジェクトのためにメモリを確保しなくても済むようになった
これがパフォーマンスにとって大きな影響がある
JSがこれを模倣しようとしても型安全性と構造体がないからそう簡単にはできない
TSがトランスレーターに甘んじてるうちはTSでも同じこと
TSが完全にコンパイラなったとしてもref、Span、構造体に相当する言語機能を導入しなければならないから簡単には行かない >>183
jsの場合jitがその辺はやってるんだよ。型が変わらない変数ぐらいjitは見つけて最適な型で最適なところに割り当ててる、スタックやレジスタレベルでね。refどころか関数のインライン化もやるよ。
c#のjitも凄いけど、それをwasm上でやるのは大変じゃないかな？ ホントは、Wasmの本質は速度向上ではなくて、言語を変えられることだよ。 >>184
その程度じゃ全然最適化が足りないんだよ
機械的な判断じゃどうしたって最適化していいか確定しない部分が沢山でてくる
C#だってデスクトップやサーバーサイドで最適化のノウハウをしこたま溜め込んでる
その蓄積があるのにあえてプログラマの手で高速化するための手段を用意した
マイクロソフトはJITを極めてもそれだけじゃ満足できないとわかってたからね
結果として.NET Coreは凄まじいパフォーマンスを獲得したわけ
Blazorはまだ黎明期だからしかたないけどサーバーサイドのベンチマークはまじで凄いからね >>185
それ。他言語のライブラリとか持ってこれるのが助かる
>>186
そうだね。早く速くなるといいね >>186
お前いつまでここに寄生してその話続けんの？ >>187
他からライブラリを持ってこれる、というようなことだけじゃなく、
JSには、ちゃんとしたclassの概念もなければ、ちゃんとしたstructの概念も無い。
明示的な型指定も出来ない。
また、常にGCがONなので速度的に不安定。
変数は原則的に全てHeapからの確保になってしまうので使い始めが遅い。
動的に型が決まるので、JITでもある程度以上最適化できない。
そういうところがC++では改善できる。 >>191
wat書くとそのへんは痛感するね。流石にcppとかrustには叶いませんわ。 C++はJITが効かないので、最悪Javaの20倍ほど遅い。 >>194
それは、狭い範囲における非常に稀なケースだが、
WasmはJITが効くので、C++も出力をWasmにしてしまえば、原理的には
同じ事が出来るわけだけど。 > C++はJITが効かないので
JITって何かわかってる？
ただのCPUに最適化したコンパイルに過ぎないぞ
C++でもコンパイル時にCPUに最適化すれば同じことだ >>195
JITの方が速くなる可能性があるとすれば
1. たまたま実行した環境では、要素数の多いSIMDが使えるCPUの場合、そのCPUに
合わせて最適化できる。
2. 予め最適化する場合には、実行段階で、CPUの場合分けのためのオーバーヘッド
が少し生じる。
3. 実際に実行してからのプロファイリングを用いて、繰り返し回数の多いループ
を重点的に最適化できる。
これもテスト時にあらかじめ行っておくことも出来るが、何らかの要因で
条件が大幅に変わった場合には、JITでやる場合と差が出てくる可能性がある。 そもそもwebというかブラウザがdomとcssに結局は縛られるから、そっちのが問題だと思うけどなあ。。
そしてdomはとても壊れやすい。それが起因の問題は今でもちょくちょく体験する。ブラウザ互換も未だに完全じゃない。
wasmだc#だと言っても、UIまで包括的に別の仕組みで動作しないと同じだと思うよ。 Vueはreact追いかけて変な方向に行ってしまったな。
従来のVueの手軽さがいい人にはAlpineJSをお薦めするよ。 wasmとかc#とかMSの話してる奴
これもう荒らしだろ。
単語NG安定 >>200
そういうマイナーなframeworkは
バグとかの情報少ないし一番めんどくさいだよ
お手軽っていうのはユーザーが多い
ASP.NETとかRuby on Railsのことなんだ
Rubyはweb以外ではろくに使われてないし
結局、ASP.NETが最強ということになる >>199
QTが動いたって話だしそのうちDOMに依存しないUIフレームワークもでてくるだろうな
それが良いかどうかは未知数だが 【ﾜｯﾁｮｲ有】Vue vs React vs Angular Part.5.5
https://mevius.5ch.net/test/read.cgi/tech/1596110361/
スレチガイジが居ないスレはこっち >>191
スタックメモリを有効活用しようとしたらstruct必須だからJSの言語機能を大幅に改修しないといけないね >>206
c#しか知らないのにそういうネタ出すの止めたら？ >>207
他の言語も知ってるけど？
俺はJSしか知らないフロントエンジニアじゃないよ C#しか知らない業務ソフトおじさん
略してソフトおじさん >>205
C#理解できないレベルの低い人たちだけのスレ立てたのか
わざわざ分裂させて時間を無駄にしたがる人たちは理解できない Ruby は、Vagrant, Chef, ServerSpec, Github とか、サーバー構築テストに強い
Chef では、以下の抽象化構文で、Cent 系のrpm/yum, Debian 系のdeb/apt の、両方に対応できる
package "dstat" do
action :install
end ここでCの話してるやつって外国に忍び込んで蝕んでいく中国人みたいだな JavaScriptに話を戻そう
ReactってそもそもHTML要素が既にある時点で
イベントハンドラとかprops stateとか作りこんんで行く訳だが
そもそもHTML自体をしこたま動的に生成しなきゃならん事
多い。
そういう時ネイティブ JavaScriptの
createElementとappendChild使うのがいちばん便利
なんだわ。
動的に生成したDOM要素にイベントリスナ設定して
ピタゴラスイッチ見たいにUI構築していくのは楽しい。 手動でやりたいならどうぞご自由にとしか。
JSスレ行ってね。
あ、ついでにC#ｶﾞｲｼﾞとRubyｶﾞｲｼﾞも一緒につれてって。頼んだよ。 Document.createDocumentFragment( ) だろ >>204
QTってWEBはWebGLが前提だろうから、どうなんだろうね。
でもWEB版とネイティブアプリ版両方作るなら、一番合理的とも言える。
欠点は読み込みがクソ重くなる事か。。 >>214
まあ仮想DOMってdocument配下にないメモリ上の状態でガチャガチャやるわけだし
実DOM直接操作するよりはオーバーヘッドないんじゃない？ >>218
仮想的なDOMを操作しても
最終的に実DOMに反映しなければいけないのだから
仮想DOMの処理はは100%オーバーヘッドだよ 一番速いのは、仮想DOM操作も実DOM操作もしないこと
当たり前だよね？
つまりHTML/CSSだけで実装するのが一番速いわけ
できないと思うなら「CSSだけで作った」で検索してみりゃ
いくつもCSSだけで動きがあるものを作っているサンプルが見つかる
次に速いのは必要最小限の実DOM操作を行うこと
これも当たり前。これはCSSだけでできないことをJavaScriptで
行うが、必要最小限のクラスなどの属性の変更で行うこと
DOM要素の追加削除は行わなず、CSSを使って表示非表示で対応するのでのでこれも速い
ただしHTMLとCSSを正しく理解していなければいけないので
JavaScriptからウェブに入ったなんちゃってウェブプログラマには荷が重い（笑）
ちなみにjQueryを使ったプログラミングでは、この必要最小限のDOM操作を行うのに適している
仮想DOMっていうのは、このHTML/CSS/JavaScritpのベストプラクティスを無視して
全部JavaScriptでやったら重くなった→どうにかしてマシにしたい
というバッドノウハウとして生まれたものだよ
HTML/CSSまたは、jQueryを使って正しくプログラミングしたものに比べれば
仮想DOMは遅い jQueryがネイティブより速い？ 何言ってんの？ >>221
ネイティブより速いなんてどこにも書いてないよ
速度で言えば速い順に
JavaScriptなし > ネイティブ > jQuery >>>> フレームワーク
なのは当たり前でしょう？ 要はその「必要最小限のDOM操作」が自明じゃないような大規模な画面の変化をさせたい場合には
仮想DOMの効果が出せるということ。 いや実DOMに対するappendを
一回でドンとappendするか
複数回こまごまとappendするか
どっちがオーバーヘッドが大きいかって話じゃない？ vDOMはオートマ
jQueryはマニュアル
jQueryおじさんは軽トラ運ちゃん >>228
C#おじさんID変えまくってるから望み薄だなぁ ｊQueryが嫌いな訳じゃないんだよな。昔は散々世話になった訳だし。
ただスレチ。話も長くなるし。 >>226
> いや実DOMに対するappendを
> 一回でドンとappendするか
一回でappendする場合DOM操作ではなく、innerHTMLの代入とかに
なるわけだがフレームワークはそんなコトしていない
そもそもinnerHTMLだから速いというわけではなく
JavaScriptで追加するか、ブラウザ内部の処理で追加するかの違いでしか無い
ブラウザ内部で処理したら速いように思えるが、innerHTMLでは
HTMLのパース処理が必要になるので無駄な処理をしている
それに昔はJavaScriptが遅かったが、今は速くなっているため
JavaScriptのDOM操作とinnerHTMLによる一回でドンは大差なくなってる。
仮想DOMは純粋なオーバーヘッド。実DOMに反映する処理＋仮想DOMのオーバーヘッド >>227
> vDOMはオートマ
> jQueryはマニュアル
> jQueryおじさんは軽トラ運ちゃん
そして一番重要なのは、どの方法が一番早く目的地につけるか？
って話なんだよねｗ 仮想DOMが遅い理由
Why Virtual DOM is slower
If you think it’s fast, this article might be what you were missing
https://medium.com/@hayavuk/why-virtual-dom-is-slower-2d9b964b4c9e なんちゃってアマチュアレーサーがマニュアルのほうが速いとかでマウント取ってくるのと一緒だな。
ひっきりなしにガチャガチャガチャガチャ動かしたくないんだわ。 >>236
だから動かさなければいいのでは？
HTMLとCSSでできることはJavaScriptを使わない
コードがないのでバグも減るし、速度も早い
JavaScriptからウェブに入ってきた人って
HTMLとCSSの技術力が低すぎる人が多いんだわ
知らないくせに、知らない俺すごい。みたいな考え方してるｗ
どうどうと嫌いです（だから勉強していません）みたいなこと言うからな 例えばCSSだけで作られたアコーディオン
https://webdesignday.jp/inspiration/technique/css/5316/
JavaScriptなしでブラウザ内部だけで実行するから最速
こういうのを作れるとお前ら何JavaScriptフレームワークで
無駄な努力してんの？ってなる え？ innerHTMLでドンと入れるもんなの？
ドンと入れるってのは一個Element作ってその下にたくさんElementぶら下げて最後にappendChildするものだとばかり。さもなくばtemplateタグかと…… >>239
じゃあ、DOM APIで一個Element作ってその下にたくさんElementぶら下げた方が速いですねｗ >>238
アコーディオン
クリックしてから開くまで遅すぎ
JS使ってないのにこの遅さはひどい そもそもアコーディオンなんて使うほうがアホ
アコーディオンあるとスクリーンショットとれない
ユーザビリティ考えてないゴミといっていい >>240
それだと一個足す毎に描画発生するじゃん？ >>241
開閉スピードはCSSのパラメータで変更できる。最小0だよ。
そういう当たり前に想像できることにレスするから
お前の間抜けさが際立つわけ >>243
発生しないが？
まさかお前、DOM APIではできない方法を使って
JavaScriptフレームワークが実装されてるとでも思ってるのか？ｗ
不思議やなぁ。ただのJavaScriptフレームワークなのに
JavaScriptでは使えない方法を使ってると思うんやぁｗ >>241
アコーディオンのデモだからアニメーションを強調して長目にしてるだけじゃん 速度もとめるならwebglだな
3Dはもちろん2Dも速い そういやValkanってブラウザ対応とかするんかな？ >>245
最初からDOMの話してるんだけど。
bodyからのツリーにぶら下げなきゃ描画しないのは知ってるよ？
だからこう書いたのに
> 一個Element作ってその下にたくさんElementぶら下げて最後にappendChildする >>237
アプリ作る目的がこのスレなのにhtmlとcssのみとか頭イカれてんだろゴミ野郎
何ヶ月も同じこと言ってんじゃねえよ バニラでアプリ作れない雑魚のための介護マシン≒React等低速フレームワーク
ということでFA？ UIだけの話しかできないやつなんなの
ここframeworkの話するところ
>>253
開発生産性を考えられないアホは
バニラでやってればいい 自分ではうまくcssだけで実現できたつもりでも
クロスブラウザ対応できてないケースが多い。
ライブラリ使わないとクロスブラウザ対応は事実上不可能
web frameworkも同様
不要だといってるアホは開発生産性を考慮できていない >>247
意外と素のOpenGL ESよりだいぶ遅いのが気になるが。 >>255
クロスブラウザだけならjQueryで充分
生産の効率化がフレームワークの肝じゃないかなぁ いやーもう俺はjQueryだけとか無理だわ。保守が苦行すぎだろ。
ScopedじゃないCSSとか思い出すだけで辛い。
型も無しにApi呼ぶの怖すぎ。リファクタリングに手間かかりすぎ。
スレタイのフレームワークなりライブラリ使うだけで劇的に快適になるよ。
中規模以上ならフレームワーク必須。
今更仮想DOMが遅いとか。。文句の付け所が見当違い甚だしい。 emotionのcss prop便利すぎワロタｗｗｗ
styled component形式も併用できる。けどネスト深くなるから好きじゃなかったんだよね。 >>254
とか言ってるやつが1番開発生産性をわかってない
SPAフレームワークなんて人材調達がめんどくさくて高いからコスパが悪い
MVC+jQueryなら人集めるのが簡単だ
後者は長年の経験の蓄積があるから作業を開始してからもSPAキッズより速い >>260
いや、わかってる。
俺は個人でも仕事でもSPA使ってない。
ASP.NET MVC系 + C#だ
前スレでも結論でたとおもうが大手法人サイトでも
web frameworkとしてはReact , Vueをほとんど使ってない。
ただのUIまわりだけの利用にとどまっていて
SPAとして動かしてない 長年の経験があって安くて簡単に手に入る人材？ 地雷では？ >>252
アプリを作るとは？
実際にはUI作ってるだけやろ >>258
> いやーもう俺はjQueryだけとか無理だわ。保守が苦行すぎだろ。
> ScopedじゃないCSSとか思い出すだけで辛い。
SPAにするんじゃなくてサイト全体をモジュール化しましょう。
それぞれ独立したページだから、ページごとのscopedになっている
sassを使いましょう。CSSファイル一つでも
ページごとのCSSが作れます。
お前HTML/CSSの技術知らんだろ？
無知だから苦行なんだよ >>261
わかってる人だったか
すまんなここは喧嘩売ってくる人が多いから攻撃的になってしまっていた SPAを作るのが楽なのはわかるが、それはSPAじゃなきゃだめなのか？
UIを作るのが楽なのはわかるが、それはそんなに複雑なものなのか？
って話なんだよな
ほんの少し必要なもののために、全体を複雑化してしまってる。
UIなんて要素の表示非表示で殆どのものは作れるんだよ
DOMによる要素の操作（属性変更以外）が必要なのはフォーム項目数が
増減する場合ぐらいしか無いんだが、一体何のために
フレームワークを使わないといけないんだって話なんだよな な？俺が言ってることが正論だから
まともな反論一つできないわけだ >>265
独立したページだからページごとのscoped？ってどんな小規模なサイトなのよ。普通のサイトでも1ページに複数のcss組み合わせてpackするだろ。。それにaltCssは関係ない。単に名前空間の話なんだけど分からない？
気をつければ問題ない、じゃないのよ。保証されてないとダメなの。その保証をフレームワークがしてくれるワケ。
って言っても分からんか。。よく手作業でやるよな。まあ精々頑張ってくれ。 >>269
最後の3行が無知を晒してんだろがボケ
お前みたいなゴミがゴミサイトしか作れないからそれしかわからねえんだろゴミ >>270
名前空間ならクラスを使えばいいだろ
単にネストするだけ
書き方がわからんのなら教えてやるぞ？
.my-namespace {
.module {
.component {
.name {
color: red;
}
}
}
} フレームワークを使うのはホームページビルダーを使うような事だ >>271
理由はないけど最後の3行は無知なんだ！
と言っても誰も賛同しないって（笑） >>272
やっぱり分かってない。そんな事みんな知ってて随分昔に通り過ぎてるんだよ。
それを手作業でやる必要ないだろ。必ず間違えるのが人間なんだから。
君もそんな所にとどまってないで登ってきなよ。歓迎するよ？ >>272
通り過ぎる？
じゃあこれの何が問題か言えるよね？
先に言っておくわ。はい言えなーいｗ >>275
HTMLの基本である文書構造とスタイルの分離を
理解できてないやつがいるからね。
昔はCSSを変更するだけで見た目をガラリと変更できた
早くフレームワークでそういう本来あるべき時代が来るといいねｗ >>237
ごめん、技術力がないんじゃなくて
タグ書くのとか別ファイルにCSS書くのが純粋に
めんどくさいからあえてJavaScriptで書いてるんだわ。
HTMLもCSSも全部JavaScriptで生成してるんだわ
JavaScriptならconsole.logで
途中経過確認できるし
forやif 配列 連想配列
イベントリスナ
location ajax全部自在だから
JavaScript使うんだわ
単なるwebサイト制作屋じゃなくて
プログラマなら誰だってそーする。 ウェブサイトをプログラミングすんなよ。
画面がグニョんとうごく動的でダイナミックでエクセレントなホームページ作ってるやつ。
おまえ地獄に落ちるぞ。
おまえのせいでページを見てるみんなが困ってんだ。
謝れ。
ページがぐにょぐにょ動く必要ない。
おまえの自己満足だ。 >>281
要求仕様にあるからやってんだよ
俺だってやりたかねぇよ 業務ならUbuntuにしとけよ。
おまえのはホビーだ。
ど素人が。 テキストのhtmlつなげてDIV.innerHTMLにぶち込んでいたけど
JQueryが速いって聞いて書き直したら、クッソ遅くなった
ま、昔の話だが まあ3年前ならそうかもしれんけど、いまはフレームワークの時代だからね。
やはりUbuntuだと思うんだわ。 >>283
そのクソくだらないおもちゃを
みんな作りたがってるから
余計な仕事が無くならねんだよ
さっきからそういう話をしてんだよ。、 金のために魂を売ったなら、結局地獄行きじゃねーか。 SvelteのTutorialやろうとして19のうち5で一時挫折
VueもSvelteも覚えることが多すぎる
ほとんど覚えることがないReactは良かった
Reduxは読みやすいReactをものすごく読みにくくして学ぶ気が起きない Webアプリしか作れないやつとWebサイトしか作れないやつじゃ話しは合わんわな Reactはなんで何度も実行して無駄なことしてんのって思ったことがSvelteは解消してんね
コンパイルするから最小限のことしか実行しないようですばらしい vueとsvelteはほぼ同じようなものなんだけど、互いにいい所があって、両方のいいとこ取りしたものを欲しくなるんだよなあ >>290
そうじゃねーんだ。
ユーザーの立場から、ホームページは動かすなと言ってるんだ。 >>280
そういやって静的に作れるファイルを
動的に作るからフレームワークは遅いわけ >>296
あそこ何気にIPv6に対応してるからな >>296
それな。シンプルイズベスト
ただのHTMLとCSSでいいのに
なぜかわざわざ複雑にする >> 293
ホームページみたいなWebサイトしか作れないお前の立場じゃ、Webアプリを作るのに適してるスレタイのフレームワークの良さはわからんよ
とりあえずお前はスレタイのフレームワークを使ってWebアプリを作るといい
あとユーザーの立場で言えば今の多くのユーザーはネイティブアプリに慣れてるから、動きのあるページの方が良いって言うと思う > 動きのあるページ
CSSアニメーションでできることを
JavaScriptつかって再発明してそう（笑） 動くホームページなんて昭和の主婦かよ。
子供だましもいいとこ。 >>300
お前みたいなゴミはせいぜいwebサイトのcss止まりなのはわかった >>289
ReactやるぐらいならElmでよくねえ？ >>277
なるほどなあ。これが所謂JQueryおじさんってやつか。構うんじゃなかったわ。。
分かった。お前はお前のやり方を通してくれ。
でもスレチだから出てってくれんかなぁ。一応フレームワークのスレなんでね。 お客様のなかに 想定い通り にお住まいの方はいらっしゃいますか〜 Vueって昔はcdnから読み込んでHTML属性にv-なんちゃら書けば簡単に使える
nodeやビルドシステム要らずの良いフレームワークだと思ってたんだけど今のVueなにこれ。
Reactの後追いばかりして自分の良さを消しちゃってるよね。
もともとv-なんちゃら属性でHTMLで出来ることを拡張する
コンセプトのフレームワークで全部JSファイルの上でwebコンテンツ作りますのReactとは違うのに無理してTypeScript使い出してて草
そういうのが受け入れられない人こそがVueの本来のターゲットユーザーであったはずなのに >>301
一応日本初のホームページは1992年（平成４年）だから
昭和の主婦には不可能です。
https://ja.m.wikipedia.org/wiki/日本最初のホームページ Vueはreact追いかけて変な方向に行ってしまったな。
従来のVueの手軽さがいい人にはAlpineJSをお薦めするよ。 Hooksが出たいまとなってはReactの方がとっつきやすいだろうしな 野良フレームワークはこういうことがあるから長期運用を視野に入れたときに嫌になる
マイクロソフトが管理してるBlazorだったら安心して長期に渡って利用できる グニョンと動いた時点でアウト。
動くホームページ認定。 フロントの変化が激しいのは昔から。文句行っても始まらんし今後も変わらない。嫌なら他の業種行くしかない。
その前提で例えばVue派とReact派で論争するなら分かるが、なんかスレチで伸びるよな。
少なくとも文句言うだけのjQおじにだけはなるまい。 >>317
俺が変えてやるっつってんだよバカヤロー。
おまえ、そのままでいいのか？
おまえの客は困ってないか？ そもそも、ITは中国のほうが進んでいるという事実を受け入れられないから、いろいろおかしなことを言う。
ハードウェアは韓国、ソフトウェアは中国に学べ。 MSRAで開発されたBlazorは今後の主流になる可能性がある。 MSRもむかしは日本に在ったんだけどね。
なぜこうなった。 やっぱさ、こういうスレで話してても、頭悪いもんな。
中国人のほうが頭いいんだよな。
こういうスレでは、いまこうだからって話よくするんだけど、中国人と話すと、自分たちが10年後を作ってるって感覚があるんだよね。
日本人にはそれが無い。 あのさあ。
Github見たらわかるでしょ。
勢いが違うよ。
スターの総数一位言語は中国語だよ？
いまそういう時代なんだよね。 ただ一つ言っとくけど、没落したとはいえ日本も世界第三位の国だからね。
このままじゃ終わらんよ。
おまえら俺について来い。 MSも中国人も有能なのは確かだけど。虎の威を借る無能についてゆくヤツなんていねぇ >>327
やっぱり中国人は自分たちで作ったものがないのかｗ それならVueとか中国人が作ってるんじゃなかったっけか？
MSの某社員漫画家もやってたろVue 申し訳ない、Reactは公式にも書いてある通り
フレームワークではなくライブラリなんだ・・ こんなスレで議論するよりウィーチャットで中国人に聞けばいいんだよ。
どれが良いですか？って。 中国人は人口が多いからな
んなもんで公開されてるOSSも多い
また同じ中国人が内輪で使うから星も多い いま中国人が一番注目してるのがBlazor。
これで決まりだろう。 それでは数少ないメイドインジャパンのPSSについて語ろう！ さぞかしBlazorのスター多いんやろなと思ったらReactやVueと2桁違って草 読んでる端から文字がぐにょぐにょ動くとか、文書としてあり得んからな。 Reactが滅びて青き清浄なる世界が取り戻せればよい。 中国は今のご時世いつアメリカから取引切られるか分からんから自国製のもんを使うんやない？ 中国はアジア各地に戦争を仕掛けようとしてるからね
侵略行為そのものだし >>343
国政としてはかなり正常な判断だよな
外国ベッタリ依存の我が国と違って自立心がある
ITだけ話ではないがいざというとき自立できる国なら安心して暮らせる 中国はGitHubは規制されてないのか
中国人は人口多いし、英語あまりできないし
GitHubが中国語だらけになるのは自然なことかと。
中国で革新的なOSやBrowserが開発されたとしても
党の方針でスパイウェア入りだから結局、世界で使われない。 そこからか。
中国でウェブブラウザは国産が多く使われていたが、現在では半数がチョロメを使っている。
そういう状況。 GB18030あたりも説明してやらんと理解できないかもしれんな。
俺以外の日本人は素人だから。
中華人民共和国標準化法3章14条を調べてみろ。
チョロメを使うということは、欧米製品を受け入れるということではなく、欧米進出の布石だ。 ITは中国のほうが進んでいる、中国に教えを請えと教えてやってるのに。
未だに、「日本の方が凄いんだもん！」とか言っててワロ。 おまえらH5知ってるか？
お前らのやってるブラゲーはほぼ間違いなく中国産だぞ。
中国の企業が下請けで作ってるって意味じゃないぞ？
中国企業の下請けが各国にあって、ローカライズしてる。 Javascript自体がかなりの糞言語だけどな。 >>315
cocoaでxamarin,azure推そうとして爆死してるの見ると微妙感ある TSなら不満はないけどな。JSがアレすぎたから余計そう思うだけかも。 最初は俺もそう思ってたけど、書いてみたら必須に思えてくる シンプルなコードが書けないから
型とかが必要になるんだよな
まあフレームワーク使うと複雑になるのは
フレームワーク自身に問題があるとも言えるけどさ
全部JavaScriptでやろうとせず、HTMLとCSSをうまく使いなさい ・マークアップおじさん
・Typescript使えないおじさん new! 型があること自体は別にいいんだけどイチイチ些細の変数の型まで定義するのが糞めんどくさくてanyでいいやってなったらもうtsである必要なくね？みたいになる TSの型を書いたらなにこれすげーってなった
TSのすごさはなにこれすげーってなったときに記事を書いたから探せ
最初に経験したときに書くべきだね
二度と経験できないから 英語の記事を読んだらTSのすごさを絶賛する記事があふれてるらしいが本当にそうか？って思った TSですごいとかいってるひとはC#使ったら感動で死んでしまうだろう
C#が最高だからね C#お姉さんが真実を教えてあげよう
https://youtu.be/ctSqiD8BGPM?t=170
ASP.NET coreはnode.jsより7倍速い。
node.jsはオワコン。低速・開発生産性も低い フレームワークはTS対応してるから重要になる
TS対応してないフレームワークはゴミ？ よく知らんがVue3がTS対応して昔のが使えなくなって混乱してるとかしてないとか 難しいことは中国人に聞けよ。
おまえらが考えたってわからんだろ。 中国人はそんな事言わんからお前は日本人か韓国人だな >>373
Vueは昔からTS対応が弱かった。Nuxtも同様。
一昔の中途半端感は酷かったな。今はだいぶマシになったけど不安は残る。
V3で本当にきっちり対応するならそれも良い。
基本的に好きなので生き残って欲しい。
ページ数の少ない静的サイトはNuxtに世話になってるし。 まともにやってる人は、Vue.extendで普通にtypescript扱えてたの知ってるから、
typescriptに弱いとか言うひとはアホだなあと思われるので気をつけるように >>370
asp を使わなくとも、WasmのWASIが速いはず。
ちなみに、node.jsからでもwasiが使える。 グラフのプロットをしていたところ以下のエラーが出ました。対処法を教えてください。
File "C:\Users\NEC-PCuser\AppData\Local\Programs\Python\Python38\lib\site-packages\matplotlib\pyplot.py", line 2823, in plot
return gca().plot(
File "C:\Users\NEC-PCuser\AppData\Local\Programs\Python\Python38\lib\site-packages\matplotlib\axes\_axes.py", line 1743, in plot
lines = [*self._get_lines(*args, data=data, **kwargs)]
File "C:\Users\NEC-PCuser\AppData\Local\Programs\Python\Python38\lib\site-packages\matplotlib\axes\_base.py", line 273, in __call__
yield from self._plot_args(this, kwargs)
File "C:\Users\NEC-PCuser\AppData\Local\Programs\Python\Python38\lib\site-packages\matplotlib\axes\_base.py", line 399, in _plot_args
raise ValueError(f"x and y must have same first dimension, but "
ValueError: x and y must have same first dimension, but have shapes (343,) and (343105,) スレ違い！
Python のスレで、聞いてください！ Vueはreact追いかけて変な方向に行ってしまったな。
従来のVueの手軽さがいい人にはAlpineJSをお薦めするよ。 >>383
ほんとあんまり変な機能はむしろ入れないで欲しいな
気軽さは残さないとreactとの差別化が出来ないしな オープンソースの便利ツールが日本から生まれなくて悲しいですよ。活かしたライブラリを大量に作れるほどCSエンジニアの数が多くないんかやっぱ。 日本のWeb系は外人の作ったフレームワーク使うだけのユーザーの域をまだ出てないからね
日本から発信して世界中で使ってもらうなんてことはまさに奇跡
Rubyは好きじゃないけど実績は本当にすごい 世界中で使ってもらうには英語が欠かせない
中国は英語を学ばせる教育体制が整ってて英語とCSができる人材が出てくるようだ deeplとかいう精度高過ぎる翻訳ツールも出てきたし、10年後には言語の壁はだいぶ取り払われてる気がする >>389
deepL の精度は桁違いにすごいですね…
どうしてこうなった？ vurはマークアップ上がりとしては取っつきやすくていい
Reactと比べるとやっぱスタイリングはvueの書き味が圧勝してる Vueはreact追いかけて変な方向に行ってしまったな。
従来のVueの手軽さがいい人にはAlpineJSをお薦めするよ。 Blazorのデモ
https://isc30.github.io/blazor-lazy-loading/
のlighthouse結果：
https://lighthouse-metrics.com/one-time-tests/5f2b9fddee28bd0008f6ab20
※LighthouseスコアはGoogleスピードアップデートの採用指標です
うちのサイトはGoogle経由でなんかアクセスされたくない！
資本主義反対！！
そんなコミュニストに最適なマイクロソフト最先端フレームワークBlazorをどうぞヨロシク！！！ TypeScriptのサイトはGatsbyになったんだっけ >>396
VM立ち上げてんのかってくらいFetchが遅いな >>404
鋭いね。IRコードのインタプリタwasmモジュール読み込んでんだよ。
それ完全に読んでからじゃないと何一つ実行されない。
しかも実行もIRコードを逐次変換実行だから遅い。
ほんとはAoTコンパイラ導入されてIRコード送るんじゃなく事前にwasmネイティブコード変換済みのものを送る方式にアップデートされる予定だったが、その計画は少なくとも一年延期になったｗ
あと一年は遅いママｗｗ早いパパｗｗｗ 今のままでも体感速度的にはなんの問題もないがwasmネイティブ対応は時間の問題だ
オープンソースだから予定より早く実装される事もよくある
アンチの断末魔が亡者のうめき声に変わるまであと少し 対応してから言って。
お前ははよベータテストに戻れよｗｗ >>405
AOTでnativeに変換されると、最終プログラムのバイト数は増えるだろう。 AOTならアセンブリよりもっと細かい粒度で不要コードをトリミングできるから最終的にはサイズかなり減るだろうね >>410
果たしてそうかな。
通常、中間コードは、(この場合はWasmコードが該当するが)nativeコード
より小さい事が多いものだが。 wasmもネイティブコードではなく中間コードなんだな
そりゃそうか
IntelでもARMでもない仮想アセンブラ（抽象）じゃなきゃ困るもんな ブラウザ上で走らせるという条件が、まず遅い
コマンドの度にパラメータの安全確認など無駄な処理が必ず入る >>412
Gatsbyでただの静的サイトだからASP.NETじゃないやろ >>407
この速度はユーザ逃げ出すよ。ISDNを思い出す遅さ >>417
極一部の糞回線だと僅かながらにストレスを感じるかもしれん
でもほとんどのユーザーは問題ナッシン >>419
わかった。あんたC#とBlazorの巧妙なネガティブキャンペーンをやってたんだな。やっと腑に落ちたよ。
あんたが演じたみたく滅茶苦茶な理論振り回す開発者ばかりだと思い込ませれば、C#になんて近づきたくなくなるもんね。いやあ、大したもんだ。すっかり騙されたよw ここ最近Nextjsが本当に優秀なのでGasbyがお株奪われた感があるな
普通じゃまずない方法でGraphQL使ってたりGasbyは技術的に面白いするから一部の物好きが細々と使っていく感じになるのかね。 Gatsbyは検索機能が付いたスターターがあって好きよ
最近の主流のAlgolia使わんでいいのはでかいさね JVM（Java virtual machine）でよかったよね .NETのC#がJavaよりはるかに出来がいい。
速いしJavaはスクリプトよりはましだけどね 来週中にnuxt.jsもvue3になるらしい。楽しみだな。 Vueはreact追いかけて変な方向に行ってしまったな。
従来のVueの手軽さがいい人にはAlpineJSをお薦めするよ。 今はreactが正義みたいになってるけど
本当にそのスタイルが一番いい方法なの？
まだまだ完成度の高い方法があるような気がするけど svelteがどこまでreactに近づけるかにかかってる
でもsvelteは普及しないだろうな
ファイルの拡張子は3文字以内でないとスマートとは言えない svelteは後ろ盾が弱いからreactには勝てない svelteをreactやvueと比較してる例って元の素材がシンプルなだけで
規模の大きなものをあれでやろうとしたら結構ごちゃごちゃになりそう reactが去年hooks正式導入したみたいに
他のライブラリで新しい優れた手法が出てきても
それすらも取り込んでさらにreactの完成度が高くなっていくんじゃないか そういう無節操に流行りものとにかく取り込んでグチャグチャにするのはvueの専売特許だろ。 vue2でコンパイルしたモジュールを3のランタイムに突っ込んだら動かなかった。
これ、vue3の正式リリース時はある程度(再ビルドなしで)互換は確保してくれるんかな >>447
先週あたり正式リリースされてたぞ
互換性は無いでしょ Reactのrecoilいいな
useContextの欠点を補完してる
もうReduxなんか必要ねえは vuetifyも互換性なかったし観念して新仕様に書き換えるしかないんじゃね？ Nuxt.jsのExpressをバックエンドにも流用していた人いない？
NuxtをバージョンアップしたらExpress消されてしもたんだけど、
バックのAPIどうしてる？ 新しくAPIサーバー立てる？ 既存プロジェクトにフォークしてrecoil入れてみたけどwebpack.configかモジュールか何かがあんまり古いとrecoil-persistが動かないみたいだね
create-react-appで新規に作ったプロジェクトだとスムーズに動いた recoilというかuseRecoilValueすると2回レンダリングするね？
スタックオーバーフローでも話題になってたけど 2回くらい誤差だと思うくらいじゃないとReact疲れ起こすぞ reactの状態管理とディレクトリ構成は早くベストプラクティス決めてくれや reactは単なるライブラリだっていってんだろ
フレームワークのnextやgatsbyはフォルダ構成決まってんじゃん >>449
これも面白そう
Jotai, a New Granular State Management Library for React
https://www.infoq.com/news/2020/09/jotai-react-state-management/
たぶん日本語の「状態」からｗ vue+typescriptでimport xx from "xx.vue"をした時に、xx.vueで定義しているプロパティやメソッドをオートコンプリートで認識する方法ってありますか？
今は↓を指定していて、当然ながらvueの共通のプロパティしか出てこない。
declare module "*.vue" {
import { defineComponent } from "vue";
const Component: ReturnType<typeof defineComponent>;
export default Component;
} Angularは、materialを使う言語。
JavaScriptをつくるスクリプトという印象だった。
SPAとよく言われるが、CORSでつまづくから人気がないんだと思う。
機能一日触っていたけどAngular側の問題ではないという話もあるが。
webapi、いわゆるバックエンドをgolangで実装したが簡単に棲み分けできた。 Reactでログインどうやって作るんすか？
OpenID？というのを使うんですか？ >>463
セッション維持の仕方という意味で聞いているのかな？ >>463
reactあんま関係ないねーー。
ログイン画面の作り方の事なのかい？ どういったapiを作ればいいのか
どうやってreactから使うのか
さっぱりわかりません 俺はめんどくせえからお前ら無料で調べて教えろってなんで素直に言えないんだ >>463 >>466
server-sideの勉強しないと無理
DBとかsecurityの知識が必要
server-sideやるならJSはやめたほうがいい
node.jsが遅いし良いframeworkがない
server-sideの知識がないならなおさらJSはやめたほうがいい
速さ重要ならASP.NET Core
速さはどうでもいいならRuby on Rails
あたりが有名どころ ググったけどどいつもこいつもオレオレ認証ばっかりでどうにも胡散臭い
こんなんでいいのか？
フレームワークが全部面倒みてくれないと不安すぎてリリースできない
お腹痛い
--react--
username, passwordをajax post /api/login
--server (Aspnet, Spring, ...)--
username, passwordをverify
set cookie（ http only, secure, same origin)
--react (post準備)--
CSRF tokenをajax get /api/csrf_token
--server--
認証cookieなかったら401
CSRF tokenをリフレッシュ
--react (post)--
CSRF tokenをheaderに入れてajax post /api/xxx
--server--
認証cookieなかったら401
CSRF tokenが違ったら403
Permissionが無いなら403
なんか処理する おいらクッキーよくわかってないのでいつもlocalstrage使ってる >>470
localstorageはsecurity低いと言われてるけどな
JSで盗めるそうだ
>>469
不安ならMSのasp.net coreのドキュメントみればいい
login実装についても詳しいのがあったはず >>463
認証プロバイダーなら、Facebook, Google, Amazon, OpenID など。
モバイルアプリなら、AWS Cognito
Ruby on Rails なら、Devise
ベンチャー企業では、Rails, AWS, CircleCI がデフォルト
クライアント側の人は、Firebase を使う ぶっちゃけ始めるのにいい言語て何 part3
https://mevius.5ch.net/test/read.cgi/tech/1599110613/170
上に書いたけど、
ベンチャー企業は、AWS, CircleCI, Ruby on Rails ばかり採用するから、
サーバー側は、Railsの1強
Railsをやっていないと、システム構築運用できない。
これを他言語で学ぼうと思うと、大変 Railsは遅い
LinuxでもASP.net Core動くようになってからは
Rails選ぶ理由が見当たらない
C#覚えるほうがほかの用途にも使えるし。 YouTube で有名な雑食系エンジニア・KENTA は、
初心者が進む道を、サーバー側言語のRuby → Go を王道としてる
いらない技術が、
GUI 系は、画面の手直しなどで、工数がかさむ。
C#, dot.net などのWindows 系は、いらない。
Java などの土方系も、いらない。
C/C++ などのポインタ系や、ハードウェアの仕組みなども、いらない。
Elixir, Rust は、普及へのchasm・溝を超えられなかった
今は言語よりも、Docker, Kubernetes, AWS などの、サーバー構築運用技術が重要になった！
つまり、10年やったプログラマーよりも、
Ruby on Rails を1年勉強した未経験者の方が、上になった！
KENTA も言ってたけど、ポートフォリオに、Terraform を使うような怪物も現れてきた
ベンチャー企業は、AWS, CircleCI, Rails ばかり採用するから、
Microsoft は、GitHub を買収し、CircleCI, Heroku, Rails, Ubuntu などを狙っている 未だにRubyイキってる残党
早く駆逐されないかな Linux環境だから今更ASPやるメリットなんもわからんし(C#は好きだけど)、RailsはRubyおじさんがうるさいので、nextかな〜 >>477
KENTAってぼったくり情報商材うってるやつだろｗ
そんなやつの信者なんているんだな
Goなんてちっとも流行ってないしメリットもない
KENTAなんて情報商材屋のクズってすぐわかる
RubyはRuby on Rails専用言語というのが実態。
web以外ではろくに使われてないしwebに使っても低速 >>477
最後の一行も情報商材屋KENTAの予想か？
つっこみどころ満載なんだが KENTA は、マナブの12万円の情報商材について、
WordPress だから意味がないって言ってる
初心者は、Ruby から始めろって
KENTAのサロンは、月千円だろ。
年収も公開してる マナブも情報商材屋だったのかw
もうエンジニア脱落したひとでスキルがない人という事は知ってる
初心者向けCMSのWordPressみたいなので12万円で売るってそうとうなクズやねｗ
10万以上の情報商材うってるやつらは全員クズだとおもってる
KENTAも情報商材屋だろ
IT系のYouTuberなんて金のためにやってるやつらばっかりだし
そいつらは情報商材売るためのポジショントークばっかりだぞ
自分が売りたい商材に合わせてほかの技術がだめだとか言ってるだけ
Railsは初心者が入りやすいからそれで商材つくって儲けようってことなんだろうな 年収で負けてるお前らが何を言っても虚しいだけだぞ
全て結果が示してる KENTA は、サロン経営者。
キングコング西野を目指している。
知らんけど、情報商材屋ではないだろ
KENTA は、スーパー・プログラマー。
経歴書に使用した、100の言語・フレームワーク・ツールなどを書いてる
Elixir で、ポートフォリオも作ってる KENTA は、学校を否定しないけど、
Ruby on Rails で、マコなりの80万円とか、
1週間のイナズマコースの20万円とか、苦々しく思っているはず
どこもかしこも、Rails で稼ぎまくっている
東京フリーランスのとだこうきは、
デイトラで、10万円のRuby on Rails コースを作って、価格破壊を起こした >>485
KENTAは三流
本当に技術があるなら自社サービス、アプリを大ヒットさせて、
IPOまでいって数百億円以上を手にしてるわ
KENTAとか情報商材屋のやってることは
IT業界の経歴ないやつの弱みにつけこんでぼったくり商材を買わせてること。
初心者向け講座なんて書籍やネットで入手できるレベルのことしか書いてない
サロンの会費が月1000円ならたいして稼げない。
YouTubeの再生も安い
収入のメインはぼったくりの情報商材だよ
YouTubeで知名度あげて初心者だましてぼったくり商材うる。それがKENTA
そんなクズの動画みるのやめたほうがいいぞ >>486
10万円、価格破壊でもなんでもない
英語できるやつはYouTubeで良い解説動画をたくさん無料で見れる
英語できないやつでもRailsくらいなら書籍はたくさんある
情報商材に手を出す必要性はゼロ 年収が高いほうが偉いなら
詐欺師は偉いってことだな ずば抜けたスキルあるやつは雇われでも4桁万円稼げるし
自社サービス開発すれば億単位の金をすぐに手に入れる
初心者、業界未経験者をだまして数十万円の情報商材を
売りつけてるようなクズYouTuberはスキルもたいしたことない。
スーパープログラマーとか持ち上げてる信者もいるし、
騙されてる方もきづいてないようだしたちが悪いよな ということで、情報商材買いませんか？
通常価格39万円の所、今なら20万円です！ ずば抜けたスキルがあるなら雇われてないでサロン経営とかしたほうが儲かるんだろーな なにより人にこき使われて成果を吸い上げられる会社構造から脱却できるってのが心の抑圧からの解放につながってよりよい幸福を得られるのかもしれん >>485
ケンタはバックエンドしかできない古いタイプのエンジニアだよ
フロントはド素人
ド素人のサロン入りたいならどうぞ フロントは安い人材がゴロゴロ居るから外注すればいい
本当に価値のある仕事ってほとんどすべてバックエンドだよ 有名で優秀なエンジニアはgithubのプロフィールが輝いてる アピール好きの二流のほうがそうでない一流よりプロフィールが輝かしいなんてことはよくある
アピールの仕方を熱心に研究するようなやつも多い
まあそういうのに時間取られると中身がおろそかになるんだけどね >>494
サロンで稼いでるやつらにあるのは
プログラミングのスキルじゃなくて初心者を騙して稼ぐスキルな KENTAとかいう奴が宣伝に来てたのか
それともネズミ講システムでもあんのか KENTA は、サロン経営者。
知らんけど、情報商材屋ではないだろ
年収も公開していたけど、何千万も無かった
マコなりなんて、80万円のRuby on Rails コースに、生徒が何千人とかだろ。
売上が何十億円とか
東京フリーランスのとだこうきは、
デイトラで、10万円のRailsコースを作って、価格破壊を起こしたけど、
会社の時価総額、10億円を目指すと言ってた
マコなり・マナブは、経営者。
一方、KENTA・とだこうきは、スーパープログラマー そんな事よりスレタイにそった話しようぜ。最近React覚えたんだけどVueは何で日本で流行ってんの？ 色分け世界地図見たことあるけど中国と日本となんだかよく分からん中央アジアの国だけVue人気だったな。 日本は中国の一部みたいなもんだからな
政府からマスコミから企業の役員から中国人だらけ だから流行ってんじゃね？ フロントは安い人材ってのはそっちはWebサイト作成であってWeb開発じゃねえんだよ
Web開発のフロントはむしろ難易度高くて世界的にかなり希少価値が高い
ここをわかってないバカがバックエンドに多い >>506
フロントで無理するんな
顧客はそんなもの求めていない
フロントを難しくして、俺難しいことしてるんだって悦になるなよ
意味がないことをしてることに気づけ フロントはエンジニアじゃなくてフレームワークユーザーでしかないから金は出し渋らざるを得ない >>508
技術力の話なんかしてないぞ
顧客が求めてるものを作れってだけ つーかなんでSPAの方が素晴らしいなんて考えて出てきたんだろうか？
Twitterなんかスクロールして、そこのリンク先見て
もどったらスクロールが消えてて使いづらいし
それ普通のウェブサイトでよくね？ってのが多い >>510
むしろ逆だろ
ウェブアプリ作るならSPAのほうが楽だからそうしてるだけだぞ >>512
ほらなｗ
顧客が求めてるかどうかじゃなくて
自分が作るのが楽だから〜とか言い始めたｗ 顧客が求めるものを楽に提供できるならその方が良いと思うが。 ウェブアプリを作ってる連中は
顧客に何が求めてるかを聞いてない
作ることから始める 顧客が本当に望んでるなら
もっとウェブアプリは普及してるだろうな
結果論だが、顧客から求められていなかった >>496
client-sideとserver-sideどちらかしかできない人なら
server-sideやってきた人のが理解力はあるが
server-sideやってきた人間ならC#要らないとか言わないし
KENTAレベル低そう >>515
Webアプリが求められれば作るし、
Webサイトが求められれば作る
お前は客が何を求めているかも分からず
ボクウェブアプリは作れましぇーんしてるだけなの 高速MVC+部分更新だけお手軽にできるフレームワークが本当に欲しかった物
ASP.NET Core MVCはよくできてる >>519
顧客はアプリを求めないってだけの話
こういうのを作ってください→ああフロントはウェブサイトですね
こういう話
こういうのを作ってください→フロントはウェブサイトで十分だけど、俺はウェブアプリにしたいんだ！
こういうのが未熟者 アプリは、様々なリソースを使う権限を渡すから、嫌がられる
一方、ブラウザなら、自分のPC 内にアクセスされない >>521
いや、さすがに頼まれたものと違うものをゴリ押しすんのはガイジだろ
お前の中ではウェブアプリとウェブサイトは具体的にどんな違いがあるわけ？
SPAならウェブアプリで、そうでなければウェブサイトって言いたいの？ > お前の中ではウェブアプリとウェブサイトは具体的にどんな違いがあるわけ？
ウェブアプリは難易度が高くて開発コストが高いだって>>506が言ってたよｗ 当たり前だがフロントできるってことはバックエンドなどとうの昔に散々開発してきてるわけ
バックエンドしかできない無能はフロントエンジニアはフロントしかできないと勘違いしている
お前らがフロントできないだけの無能な負け組だといつになったら理解するのか > 当たり前だがフロントできるってことはバックエンドなどとうの昔に散々開発してきてるわけ
その根拠は？？？ >>524
うん、それは分かるんだけど、抽象的すぎるよね。じゃあそれって具体的にどう違うのか？ってところを聞いてるんだよ Ruby on Rails では、React, Bootstrap などが多いけど、
Tailwind CSS を使っている人もいた
Tailwind CSS を使っている人は、いる？ 客「こういうのを作ってください」
>>521「フロントはウェブサイトで十分だけど、俺はウェブアプリにしたい」
客「ウェブアプリにするとどう違いますか？」
>>521「開発の難易度が上がって、コストも上がります」
客「？？？」
523「いや、さすがに頼まれたものと違うものをゴリ押しすんのはガイジだろ」
519「Webアプリが求められれば作るし、Webサイトが求められれば作るよ」 >>526
それはないな
フロントエンドはserver side知らないやつばっかり
おまえは職歴ないのがばれてる
server side続けられずにフロント移動なら無能だろう
上流に近いところの仕事から外れたということはそういうことだ >>524
難易度が上がるとかコストが上がるってのは成果物に対する副次的な話で、
具体的にって聞かれたら成果物の話をするだろう普通。
アスペには難しいか。 > 難易度が上がるとかコストが上がるってのは成果物に対する副次的な話で、
成果物関係ないよ。人件費の話。
難易度が上がると高い人件費の人を雇わないといけないでしょ？ｗ
難易度上がっても給料は一緒でいいっていうのなら話は別だが >>533
つまり君の認識によると、
ウェブアプリとウェブサイトの違いは開発手法のみであって、成果物への違いは無いということなのかな？ Ruby on Rails で、Netflix 製のJSON シリアライザー・Fast JSON API を使っている人がいるけど、
これは、GraphQL とREST の中間的な立場になるようだ
REST 以外では、GraphQL と、どちらを使うことが多い？ >>534
うはっ、このビジネスアプリの画面ゲームみたいｗｗｗ
という成果物でも目的は達成できるだろうが顧客は求めてない
結局ありきたりのシンプルなインターフェースが一番
成果物が違っていても、実現できることが同じなら違いはないと言える >>511
twitterのスクロールが糞なのは同意するが
それはSPAの欠点という訳ではなく
単にtwitterの設計が間違ってるだけ
SPAを責めるのは筋違い 使いやすいインターフェースを求めていくと
結局従来の1URL、1ページの構成が最適だって気づく
SPAも結局従来のインターフェースを目指してる
本末転倒ｗ というか個々の人件費が増えてもSPAで早く作った方が安いパターンもあるのでは？ SPAが早く作れるなんてデータでもあんの？
むしろ分業作業がしづらくなるから遅くなるやろ >>511
新しいタブで開けばいいだけではないか？
戻ったりするより無駄な読み込みもなく速い
SPAが素晴らしいなんて風潮にはなってないでしょう
大手web serviceのほぼすべてがSPAになってない
URLが別々じゃないとデメリットの方が大きい >>539
SPAは開発生産性が悪く、開発コスト、工程は大幅に増える
しかも使いにくいサイトになる
ろくでもない
5chではSPA流行ってると嘘ついてるひといるけど
ぜんぜんそんなことはない。騙されてはいけない >>536
君の言っていることが二転三転してよく分からないからまとめるね。
これであってる？違っていたら教えてほしい。
・ウェブアプリは糞でウェブサイトのほうが優れている（開発難易度やコストの都合）
・2者の主な違いは開発手法にある
・2者はインターフェースにも違いがあるがそれは主旨とは外れているので優劣という意味では関係ない
・インターフェースの違いの掘り下げると、それはデザイン的な違いという意味ではなく、SPAかどうかが焦点 ID:y+TJqPrh
こいつ成果物は関係ないとか言ってるのに、思いっきりインターフェースの優劣比べてて面白いな 動的にすればするほど、ユーザーがページの挙動を予測しにくくなる
凝ったデザインにすればするほど装飾とマージンが増えて、価値ある情報の含有率が減る
この事実からひたすら目をそらして、UXだなんだと、耳障りのいい横文字言葉遊びでキャッキャとはしゃぐウェブ系フレームワークユーザー（エンジニアに非ず）がいかに多いことか
やつら遊び半分のウェブ系だから許されてるかもしれんが、ガチの業務系に行ったら無能どころか害悪にすらなりかねん お、求められてるものが違うのはわかってんのね
でも業務系以外の事、もっと勉強しようね UXとかデザインの是非の話は完全にスレチじゃねーか
あのUXはjQueryだと難しいけどreactなら楽に実装できるとか、実装面での話をするならここでも良いが、UXを実装するしないの是非の話は余所でやってくれ >>547
９月２日から１０月１０日までレスが３つしか付かなかった過疎スレだからスレチや余所でやってくれはまったく通用しない！！
おまえがこのスレに来なければいい！！！
過疎ったのにまたレスが付くようになっていいなと思ってる
おまえがスレチ！！ SPAで「ありがち」なUX設計が実はクソだということがわかってよかった
次は実装が楽になるのか？生産性が上がるか？という疑問だが
これも怪しい
ご存知の通りSPAは遅い、初回起動はとくに遅く
アプリの一部だけが更新されたにも関わらず全体を取り直す必要があるたね頻繁に更新されるアプリには不向きだ
またSEOにも弱い
SSRならば、と言う人がいるが、これはサーバーサイド資源の浪費や不安定さという別の問題を呼び込むので、スマートな解決策ではない
そう、SPAは実装する上でもあれこれ問題だらけの困ったちゃんなのだ
SPAの採用実績が少なくMVCフレームワークが持て囃されるのには理由がある
動的ビューの実装を楽にしたいがために、別の様々な問題を呼び込み、全体としては生産性が低下してしまっている
なんてことはない
SPAは実装能力もクソだった
だから選ばれないのだ 定期的にwebsiteの話題する人現れるけど
ここプログラム板だしweb siteではなくweb appが大前提 でも、最新情報をゲットするアプリとか、正直ウェブサイトのほうが良いんだけど。 > ご存知の通りSPAは遅い、初回起動はとくに遅く
Preactとかご存知ない？
20KB以下とかでアプリ作れるよ。起動も一瞬 >>552
それはあるよね。
だからSPAサイトのクロールはリソース食うの我慢してヘッドレスブラウザ使ってるわ >>531
いや、フロントフレームワークでてきたのなんてここ最近だろボケが
それまではSSRやってたんだよ
フロントしかできないアホはフロントじゃなくてただのWebサイトhtmlコーダー
一緒にすんな >>549
WebアプリにSEOなんていらねーだろ
おめーはWebサイトしか作れない安月給底辺コーダーなわけだ >>555
ここ最近っていつのことだ？
おまえが最近知っただけでは？
人の入れ替わり激しいしフロントエンドしか知らないやつたくさんいる
あとSSRの意味を理解してないだろう
>>556
いやECとかはSEO必要なサイトもある
基本知らないしフロントの底辺だな > ご存知の通りSPAは遅い、初回起動はとくに遅く
いや、単純な速さを比べるなら、ページ遷移速度はSPAが圧倒的に軍配あるし、初回起動もSPA側がchunk化してればどっちも遜色なくね？
chunk化はVueでもReactでもできるし、書き方もルーターの書き方をちょっと変えるだけで手間もかからんぞ。
https://ja.reactjs.org/docs/code-splitting.html
https://router.vuejs.org/ja/guide/advanced/lazy-loading.html
一括ロードするべきか分割ロードするべきかはアプリの性質によると思うが、SPAの選択肢が一括ロードしかないと思いこむのは間違いだぞ。 とにかくフロントフレームワークごときが難しいとかそもそも開発できないゴミの意見は不要
バックエンドしかできないゴミも不要 バックエンドはjsonさえ返せればいい
人員さくほどのことではない、なんならサーバーレスでもいい クライアントでレンダリングのためにJavaScriptで
処理をするんだからどうしても遅くなるよ A single-page app is almost always worse than a multi-page app
https://news.ycombinator.com/item?id=18335007
単一ページのアプリは、ほとんどの場合、複数ページのアプリよりも劣ります JavaScriptの処理速度よりネットワークやアクセスの集中したサーバのレイテンシの方が影響大きい場合の方が多くない？ これは良い意見だな
> SPA Webアプリの構築に数年を費やした後、ステートレスHTMLの単純さが本当に欠けています。
> 私の同僚が選んだフロントエンドフレームワークは、ページ間など、
> 状態を持ち運ぶのが本当に好きで、多くの見つけにくいバグを引き起こしました。
> これらのバグは、複数のページにわたって特定の一連のアクションを実行するとトリガーされます。
> そのようなことは不可能なはずです。ページ間のすべての状態をクリアする必要がありますが、
> これを行うためにフレームワークと戦うのは難しいようです。状態を持ち歩くことはそれの基本です。
SPAはステートフル。ページを移動するときに「状態」を引き継ぐ >>566
ネットワークやアクセスが集中した場合、SPAでも遅くなります。
データベースから取ってきたデータ（ここが一番時間がかかる）を
HTML形式に変換して返すか、JSON形式に変換して返すかの違いしかありません。
HTML形式をサーバーサイドレンダリングというのなら、
JSONを返す場合は、サーバーでJSON形式に「レンダリング」してるんですよ ASPおじさんさ、ID変えて逃げないで>>543に答えてくれよ アラフォー大逆転プログラマー たけ
【Rails】（送信時のリロード無し！）Action CableでSlack風チャットアプリを作成
https://www.youtube.com/watch?v=o6PuxDr8Meg
プログラミングを始めて半年で、こういうのを作って発表する怪物もいる
この人は、数学の博士課程まで行ってた人。
地頭さえ良ければ、Ruby on Rails 1年で、他言語の10年ぐらいの実力がつく
スクロールしたら、古いデータを取得して、そこに追加していくだけ。
ページ遷移させない
pjax(ajax + historyAPI のpushState)もある。
HTML のbody だけの入れ替え。
head 部分は送らないから、エコ Railsで半年とか1年って最強にアホって言ってるようなものだぞ
2週間もあればそれなりのもの作れるだろ まあ品質悪くてもいいなら
2週間でも構わないがなｗ そりゃRails では、Scaffold という魔法の呪文を唱えれば、CRUD アプリが15分で作れるw
たけがすごいのは、あちこちのサンプルを調べたら、ページ遷移するものばかりだったから、
ページ遷移しないものを作って発表した所
スクロールしたら、表示されているものより以前のデータを取得して、
jQuery で、要素を追加していく >>570
数学科卒みたいな人ならweb appはどんなのでも作れるだろう
1年でという言い方は嫌いだ
趣味でやる人は1日30分程度だが仕事でやれば10時間にもなる
Chat風ならpage loadしないのは当然だろう
page単位のloadが悪いわけじゃない
用途によって最適なものがあるというだけ 小学生がカメラと物体認識を使ってフィットネス系シューティングゲームを作れる時代に１年もかけてチャットだけじゃインパクト弱いね 大したことないことを大したことのようにアピールする能力が成功の鍵なんだろうな
SPAもその類のライブラリに属してる とても、プログラミング始めて、半年の実力じゃないだろ
発表を見ている人は、皆、びっくりしてるだろ。
すごい拍手で
数学科へ行くような人は、集中力が桁外れだから、1日16時間ぐらい勉強できるのだろう。
脳が若いから 周回遅れのくせに絵に描いたようなRails脳だな
Rails野郎はどいつもイキってて気持ち悪い Rails は中高年でも、人生を大逆転できるという情熱がすごい！
他の言語じゃ、どう考えても無理
他のフレームワークよりも、数年以上突き放した、圧倒的な実力があるからこそ
ずっと、オワコンと言われながらも、最先端を走り続ける実力w 既存資産ならjava, python, nodeが圧倒的なんじゃないの
何かしらやりたいなってググってrubyが出てくることほとんどないけど? [2|5]ちゃんの専ブラをwebアプリで造る場合
SPAにした方が良いと思うよ たいていのベンチャー企業では、Ruby on Rails, AWS, CircleCI の組み合わせ。
Rails 以外のフレームワークでは、リスクが高い
また、大手の自社サービス系もそう。
GitHub, GitLab, Airbnb, Shopify, Netflix, Hulu, Cookpad >>585
何回おなじようなレスするつもりだよ
自社の必要な仕様に合わせてスタックは選ぶもので
ただ真似をすればいいという話じゃない
クラウドは人気サイトになると維持費高いし
オンプレミスでやるサイトもたくさんある。
日本みたいに高速なFTTH普及してるところで最初から
クラウドに頼るのはヘタレだわ >>588
自分が数学得意だったということもあるが
数学科というか数学を評価してる
受験科目でもっとも論理的思考問われるのが数学
数学できるやつで頭悪いヤツはいない
数学科は数学が得意な奴しかいかない
あと低偏差値の大学って数学科はないイメージ Railsって意識高い系がよく使ってるけど実際公開のLinuxサーバー環境に自力でデプロイできるヤツは３割いないんじゃない？
せいぜいローカル環境で動かして喜んでるくらいだろ 俺は古い人間だからLinuxサーバ立ててそこで公開しちゃうけど、今どきは「サーバレス☁で爆速🤯デブロイ✨✨」みたいな時代だから別になんでもいいんじゃないの？
何がサーバレスやねんとか思うけど、手を動かすやつがいつの時代も一番偉いかなって >>589
×受験科目でもっとも論理的思考問われるのが数学
○受験科目でもっとも論理的思考を問われるのが数学
日本語の格助詞を跳ばしてしまうなんて、日本語を操る能力がいささか不足していると思われます
言語能力が劣る人に、その言語能力に基づいた論理的思考の能力を評価できるとは思われませんね
それに、受験数学は数学じゃありませんよ、受験数学はせいぜい「算数」レベルでしょう？大学に入って先生から「受験数学は算数のお遊戯ですね」と罵倒された経験はおありですか？
私は高校時代からそういわれていたし、そういわれつつ受験数学をやっていましたが 前スレもガイジが一生一人でレスバしてたよな
可哀想 >>591
詳しくないけどサーバレスってバックエンドのPHPとかRailsとかサーブレットが要らない構成パターンじゃなかったっけ？ >>592
なんだ、突然、数学できなかった数学コンプのバカがかみついてきた
俺のは脱字だと誰にでもわかるがおまえの文章は明らかにおかしい。
「言語能力が劣る人に、その言語能力に基づいた論理的思考の能力を評価できるとは思われませんね」
まず、「人が」だろう助詞がどうこう文句つけてるがおまえがまともに使えてない。
算数と数学の違いは分野の違いでレベルの違いではない。
と反論するのが論理的な人。
算数でも難関校の問題は難しく、高校で偏差値70以上でも解けない問題ある >>592
数学でかみついてきたからおまえが低学歴なのはすぐ気が付いたけど
先生とかいってる当たりおまえ高卒だろ
大学ならふつうは教授とかだ
「受験数学は算数のお遊戯ですね」の発言はフェイクだろうが
本当にそれを言ったと仮定してもそれは罵倒でもなんでもない。
おまえは罵倒の意味もわかってない >>595
＞＞「言語能力が劣る人に、その言語能力に基づいた論理的思考の能力を評価できるとは思われませんね」
＞まず、「人が」だろう
「人に」でも有効でしょう？「人に」するのが間違っている理由はなんですか？
無論、「人が」として、述部の内容を実施する主語を示すのも問題はないとは私も思いますが、
「人に」として、「評価できる」に対する連用修飾語としても違和感はないですね
もしかして、あなたは日本語を習いはじめて 10 年くらいの人ですか？
＞算数と数学の違いは分野の違いでレベルの違いではない
私に言わせれば算数は数学の中のレベルの低い分野ですね、例えば計算問題とか計算で解かせる問題とか計算さえうまくいけば解ける問題とか、こういうのはみんな算数
唯一「数学」という名前に値する受験数学は「証明問題」でしょうね
それでも、本当は「証明する価値のある」定理や定義を提案してこそ数学といえるのだとはおもいますけれども、まあ、このあたりは妥協してもいいでしょう >>594
プログラム置けば動いてサーバ管理が不要って意味のようだけど、だからといってサーバあるのにサーバレスってネーミングは素人騙す気まんまんじゃない？
ってしょうもないところで引っかかったの >>596
＞大学ならふつうは教授とかだ
教授、というのは学生からはそのすごさはわからないもので、実際には、教わっている人が教授か助教授か選任講師か非常勤講師か助手か技官か全然区別がつかずに皆「先生」と呼んでいました
それが普通でしょう >>597
私に言わせれば？はぁ？
おまえの勝手な定義はどうでもいいんだよ
難しいことで知られる灘中学の試験も「算数」だ 算数は知らんけど
「数学じゃなくて算術だ」
っていうのは聴いたことがある >>597
違和感がない？ほんとアホだな
「人に」だったら「能力があるとは思わない」と続くのが正しい日本語
おまえの文は「評価できる」と続くわけだから
その前に来るのは「人が」が正しい。
評価するのは誰なのか意識していればわかりそうなものだが
まあいいや学歴コンプの低学歴みたいだし丁寧に説明してもわからないだろう >>598
例えばFirebaseとか有名だけどアレほぼReactとかと直で繋がってる感じじゃない？ YouTube で有名な、雑食系エンジニア・KENTA がびっくりした未経験者は、
ポートフォリオに、Ruby on Rails, AWS, CircleCI, Terraform, Packer まで入れていたとか！
こういう怪物もいる
これに、Docker, Kubernetes
Rails は、他のフレームワークよりも、数年以上先にいるから、
たぶん、これを超えるのは、サーバーレス・AWS Lambda だけ
Lambdaは、Ruby でも書ける >>603
PreactとFirebaseで最近アプリ書いたよ。Firestoreのセキュリティ勉強してからやったから爆速デプロイとは行かなかったけどCloud Functions も使わず、クライアントからDB(Firestore)に直接アクセスするのは新鮮だったし、仕組み上セキュリティが確保できるってのも勉強になった。
今どきの開発体験ってこんな感じか、これはアプリに集中できて良いなと思った。
でもなんだかんだ鯖の事は形が変わっただけで意識してるなと個人的には感じた よくわからんのだけど、こららのjsフレームワークって
バックエンド側にアクセスする時、ブラウザから直接APIを叩きにいくの？
railsとかはサーバ側でバックエンドにアクセスして
HTMLを完成させてからユーザに渡すイメージだけど。 Ruby on Rails でも、API モードで、GraphQL なども、やっておいた方がよい Ruby on Rails, React, Bootstrap という組み合わせも多い
Rails では、Vue.js は少ないけど Railsゴミとフロント無能なケンタの話は聞く必要なし 10/13、KENTA / 雑食系エンジニアTV
キャリアの立て直しにWeb系エンジニアという職業が最適である理由
https://www.youtube.com/watch?v=ynMyrvCCP1w
登録者数、5万人超。
月千円のサロン、2千人のスーパープログラマ！ フロントできないくせにスーパープログラマーとかよく言えたものだな KENTA の経歴
https://github.com/kenta-polyglot/cv
すごい！ 100以上の技術を書いてる
Vue.js もやってる しつこくKENTAの話題かいてたの本人だったのか
ぼったくり情報商材屋KENTAに騙されてはいけない https://github.com/kenta-polyglot?tab=repositories&;q=&type=source&language=
こいつサンプルプログラムみたいのしか書いてないじゃん >>617
atcoderとかpaizaに出てくるような問題集の中からそれぞれの言語で1,2問だけ解いた感じか KENTA の経歴には、100以上の技術を書いてる。
たぶん、日本一だろ
さすがに、これを超えるのは無理 >>619
浅く広くの知識ではたいしたことない。うすっぺらい
たくさんの言語であいさつだけでできてもしょうがないのと同じ
優秀な言語を深くしっているエンジニアのが強い >>617
ほとんどの言語はハローワールドレベルってことだな >>606
おおむねブラウザからサーバのWebAPI叩くとJSONが飛んでくる >>622
ということは今までrailsとかと違ってバックエンドにアクセスするのは
ユーザーのブラウザからだから、バックエンドサーバは外部に晒さなくてはいけないんだよね？
認識あってるかな >>624
バックエンドサーバーを外部に晒すだけじゃダメだぞ
バックエンドサーバーに認証と認可機能を実装しなければいけない
つまりMySQLの場合ユーザーごとにMySQLにログインするユーザーを作って
そのユーザーで参照できるテーブルとデータをちゃんと設定する
例えばUsersテーブルに全てのユーザー名とハッシュ化されたパスワードが入っているならば
ブラウザでログインしたユーザーはUsersテーブルの中の
自分のデータしか参照できないように、バックエンドサーバー（MySQL）の定義を作り込む >>624
そうだよ
とりあえずgRPCだけやっとけばいい >>625
意味不明
なんでパスワードハッシュにアクセスさせてんだよｗ
でたらめばっかりだな
>>624
まずはちゃんとした公式のドキュメントをよめって。
とんでもないでたらめおしえてるやついる 俺がFirestoreの例を出したのがいかんかったのか？
ああいうブラウザからDB直接叩く（ように見える）のはどちらかというと例外だよ DB サーバーは普通、AWS 内のプライベートエリアにある。
公開されていない
公開されているのは、AP サーバー。
それか、Nginx とか
Amazon Web Services パターン別構築・運用ガイド 改訂第2版 (Informatics&IDEA)、
NRIネットコム株式会社、2018
YouTube で有名な、くろかわこうへいのお勧め本 ここ数年でReactとかangularとかの要は"クライアントサイドレンダリング"て言うの？
がメジャーになってきてて、Reactとか名前は聞いたことがあるが、サーバ間の構成を良く知らなかったので混乱してる。
今まではサーバサイドレンダリングの構成だと思うので。 >>632
またそのデマか
こんなスレタイのスレなんてあるからそうなる
SPAはぜんぜんメジャーになってない
SPAは特殊な用途にしか向かない
ReactはUIライブラリとして使われているだけでSPAとしてはほぼ使われてない
VueもAngularもシェア1%未満
もうこのスレ廃止でいいだろう
SPAが流行ってるかのような誤解を与えるだけ 5chは流行ってる物のスレ立てる場所じゃないんだが。
forthスレに流行ってると勘違いするからスレ廃止しろとか言ってこいよ糞カスザコプログラマもどき。 SPAの功績はSPAというアーキテクチャじゃなくてコンポーネント作るのが楽ってとこだよな
同じように楽にコンポーネントを作れるなら従来のMVCでいい SPAの良さは開発が楽になる点だぞ
お前らユーザーにとってはどうでも良いことだろ Reactでリスト的なコンポーネントいじってるとリアクティブって管理楽だなーって思う。あと副作用を避ける事を徹底しててコード組みやすい。
初見では直感的でないルール多くてちょっとビビるけど Ruby on Rails では、Bootstrap と、GUI コンポーネントに、React を使う >>636
楽になるわけないだろ
おまえが生産性高いweb framework知らないだけだわ
楽ならもっと普及してる
SPAは時間、コストかかるのにデメリットばかりだからこんなに流行らない >>634
ろくに流行ってないくせに対決スレにするなってことだ
0.1%未満のもの比較するスレタイにしてるから騙される人が多い SPAは簡単だから誰でもできる
簡単なことだから高い技術力もいらないし
給料も高くない レールは続く】 Ruby on Rails Part21 【これからも
https://medaka.5ch.net/test/read.cgi/php/1545146635/118
米国の平均年収では、
Ruby on Rails が、125,000 ドルでトップ！
Node.js が、90,000ドルで最下位
ただし、Railsの求人は、Node.jsの半分しかない。
Railsは、GitHub, Airbnb, Shopify など、巨大企業が多いから、年収が高いのかも 開発が楽なのはMVC
SPAはメリットとともに多くのデメリットも招き入れるのでそう簡単にはMVCには勝てない
SPAの利点であるコンポーネントの作りやすさについても
Asp.net Core MVCなどは非常に簡単にできるように設計されているのであまり差がつかない コンポーネント作りが何がどう非常に簡単なの？他と比べて説明してよ つやのとけんたならけんたのほうがましだな
どっちもくそだけど >>637
副作用を避けてる？
適切なところで副作用起こすべきってReactのサイトに書いてるんだけど 決められたタイミングでの状態遷移の方法は、Redux だろ
Ruby on Rails では、Bootstrap と、
GUI コンポーネントに、React, Redux を使う人もいる Bootstrapは楽だけど細かく調整したい時にどうすればいいかわからなくて困る 結局開発体験が優れてれば何でもいい
Reactが流行ってるのってそこじゃないのか >>637
何も考えずに副作用フック作りまくったらすぐに無限ループするよなw
propsのプロパティ一つでも変えたら他のプロパティも更新かかるのめんどい そりゃ、Bootstrap を使う人は、デザイナーじゃない
サーバー側主体で、CSS を知らないけど、
レスポンシブ対応にしないといけないから、使ってる
コピペしてるだけで、詳しい意味は分からないw フロントエンジニアなのにcssわからんとかゴミ
デザイナーにjsxやらせるのか？
Bootstrapはカスタマイズ前提で作られてるんだから仕様を見ればやり方わかるだろ >>651
フロントなんてのはそれで充分だと思うがね
大きなビジネス価値を持つバックエンドと違って
その時々で流行り廃りやデバイスの進化に影響をうけて移ろいやすい
こんな賞味期限が短いものに学習リソースを割くのはバカみたいだ >>650
あるあるw
そのへんは意図的なデザインかもね
>>646
やむを得ないState以外は副作用無しで書けるようになってると感じたんだけどな
>>653
React作ったのはクソ程儲けてるFacebookなんですが…… Facebookは中身の価値が高いからなぁ
別にUXが人気に繋がったわけじゃない
なのでまた別のUIフレームワークが流行ったり画期的なデバイスが生まれたらFBもすぐにUIを乗せ換えるよ
でもUIを乗せ換えてもFBのビジネスは変わらない
本当に価値があるのは中身だから バックエンドもフロントに比べればゆっくりかもしれないけど日々変化してる。今いる位置に満足してる人が老いて枯れる程度には。
だから突き詰めると普遍の価値があるのはデータだって事になる。
でも誰も触らない死んだデータに価値はない。触りたくなる表面を重要視する事は何もおかしくはない 触りたくなるデータって女子中学生のバストサイズのデータとか？ 「フロントエンドエンジニア」なんてカッコよく言ってるけど、
逆にフロントエンドしか出来ませんって言ってるようなもんだよね バックエンドしかできない奴のほうが圧倒的に多い
フロントエンジニア探してるけどバックエンド95対フロントエンド5くらいの割合しかいないぞ
その5もかなりレベル低い フロントエンドエンジニアにはマークアップエンジニアも紛れ込んでる つまりちゃんと勉強してればフロントはブルーオーシャンなのか >>653
React作ったのはクソ程儲けてるFacebookなんですが・・・ フロントはFacebookとか有名所に持ってかれてる >>664
クソ儲けたのは中身のビジネスが優れていたから
UIは後付けのオマケ >>664
だからどうした？
儲けてるから技術があるわけでもない
過去にはFacebookはPHPみたいなゴミを採用して改造していた
技術のセンスが悪い
Reactにしてもframeworkまで機能を追加できなかった
自社で使えればいいという程度の認識 >>666
Facebookは個人情報を盗んで金儲けしてるだけ アンチフロントエンドの巣やんけ。どうしてこうなったw バックエンドのゴミクズたちがフロントできないから僻んでるんだよ >>653
React作ったのはクソ程儲けてるFacebookなんですが・・… >>671
クソ儲けたのは中身のビジネスが優れていたから
UIは後付けのオマケ 有名企業が作ったからというだけでReact採用するのはアホだね
AngularなんてGoogleすら使ってないと言われてるしなｗ >>659
寧ろフロントエンドフレームワーク使ってるのは元々バックエンドやってたヤツだろ
フロントオンリーのヤツはjQueryの方が素晴らしいって言ってるんじゃないか？ >>673
Facebookとかいう陽キャ専用SNSはぶっちゃけ嫌いだけどReactの設計ポリシーは素晴らしいと思うよ jquery好きなのってマークアップ上がりのエラーあっても気にしないやつだよ 10/15、雑食系エンジニア・KENTA
Web系エンジニアの主要5職種、結局どれが一番得なのか？
https://www.youtube.com/watch?v=hM_k9792d4o
時給1万円などの高単価は、バックエンド・インフラなどの上流工程。
低単価は、フロントエンド・iOS・Android
漏れが補足説明すると、
先に、上流工程でお金を使ってしまうので、
下流工程では残ったお金を分配するだけになるから
会社の重役になる人も、サーバー側言語のRuby ばっかりw Reactが素晴らしいっていうか関数型に寄せたModel View Updateが素晴らしいってだけだよな >>677
コイツはフロントやって挫折した奴
フロントで成功してる奴は散々バックエンドをやってきてるからコイツより圧倒的に有能 先にシステムの構築運用から始まるから、
最初は気が大きいから、そこで予算を使ってしまうので、
フロントは、残りの予算から決まってしまうから不利
フロントは見たらわかるから、誰でも口を出しやすい。
ちょっとした見た目を直せと言われることが多い
ところが、違う人が来ると、また違うように直せと言われる。
違う人が来るたびに、修正しろと言われる
こういうやり取りが多いから、あいつは仕事が遅いとか、
デザインが悪いなどで、時給が下がっていく
相手がデザインを指定してくるから、
他の人には、エンジニアの腕が悪いように見える
最後には上司が来て、デザインが悪いから、エンジニアをクビにしろってなるw
色んな人が、デザインを指示してくるから
船頭多くして、船山に上る >>677
自称有名エンジニアが使ったからというだけでその技術採用するのはアホだね
Rubyなんて雑食エンジニアすら使ってないと言われてるしなｗ >>681
いろんな人から指示されるのはフロントが悪いだろ
意見まとめる人つくって指示系統を一つにしろと言えばいい
デザイン悪いからクビなんてきいたことない、センスも悪すぎだろｗ フロントは遊び半分のウェブ系が作るから「芯」がないんだよ
だから散々クレームくらっては場当たり的な対応を繰り返す
でそのパッチ作業が速いから生産性が高いなどとトンチンカンな自画自賛をしてしまう
最初からしっかり意志のすり合わせを行いクレームをくらわないUIを作るのが最も生産性が高いのだがそれが彼らには理解できない バックエンドのゴミクズたちがフロントできないからって僻んでるんだなｗｗ >>685
サーバーサイドのがフロントより格上だ。業界の常識
フロントは上流をまかされない時点で格下なんだよ
セキュリティやDBやOSやネットワークの知識に乏しい バックエンドでまともにDBすら設計構築できないゴミクズばかりじゃねえか
フロントエンジニアは元々バックエンドをやっていてマスターした奴がフロントやってるわけ
何回言ったら理解するんだこのアホどもは バックエンドでは全く分からないから、客は何も言えない。
言う材料・知識がないから
一方、フロントは見た目だから、誰でも口を出しやすい。
だから、ここを直してとか言いやすい
あまり難しい事をやってるようには見えないから、簡単に直せると思ってしまう。
でも、その手間がうっとおしい KENTAみたいなレスですね
その改行するのはKENTAの喋り方を参考にしているんですか？ KENTAってやつに他スレ荒らすなって言えばいいの？ before
afterみたいな
擬似要素使うのやめろや
あとCSSから外部ファイル読み込むもやめろや
devtoolから検出しにくいんだよ！
CSSでプログラムめいたことするのやめろやカスが
同じ事JSで全部できるから >>694
JSっていうかjQueryだろ
どちらも宣言的に記述できる
宣言的だからバグがへる どちらもっていうのは
CSSとjQueryのことだよ
宣言的っていうのは
クラス名 { 属性: 値 }
みたいに書くから
.class { color: red }
$(.class).css({color: red})
どちらも宣言的 宣言的はキーワードを指定すると何が起こるか
って事の記憶することを強要する
プログラムのように上から論理的に処理を辿ることが出来ない
バグが減らないと言うが現実は
スタイル効かない、効かない、それがやりたかったんじゃない
そんな余計な効果は要らない…クラスが死んでる、重複してる
上書かれてる…こんなんばっか
構造化プログラミングは覚えゲー不要
余計なライブラリに頼らず素のJSで
構造化プログラミングでDOM操作。これぞ至高 正直jQueryの時代は終わったと感じていて、なのにプログラミングスクールの類の宣伝がjQueryばっかで、こいつらいつの時代を生きてんだと思う。
初心者にReactやらせろとまでは言わないけど、せめて潰しの効く素のDOMやらせるとか、jQuery無しじゃ何もできないやつを量産するのやめて欲しい >>699
これが現実。お前が「狭い世界」に生きてるだけの話
https://w3techs.com/technologies/history_overview/javascript_library/all/y
jQuery
2017年 71.9%
2018年 73.1%
2019年 73.6%
2020年 74.2%
2020年2月 74.4%
2020年6月 75.5%
2020年8月15日 76.2%
2020年10月15日 76.5% 「DOMはつぶしが効きますか！」
→React、Vue、AngularでDOMは使いません へ〜、こりゃ失礼。既存ページがカウントに入ってるとはいえシェア減ってないのは凄いな。
Reactでも手が届かない部分はあるしDOMはやった方が良いと思うけど。 減ってないどころか増えてるからね。もちろん年々増えるペースは減ってるが
それでも去年は0.6%だ。しかも今年はなぜか2%以上も増えてるｗ
最近流行りのフレームワークが1年で0.1%増えるか増えないかという状態なのに
> DOMはやった方が良いと思うけど。
jQueryはDOMと共存できるんだから、DOMもやったほうがいいのは当然
jQueryは全てのブラウザで動くように古くからあって共通で使ってる機能しか使ってない
だから最近のブラウザだけで使える機能を使う場合はDOMを直接使う
力があるならjQueryプラグインにすると更に便利にDOMを使えるようになる React使ってるのに内部でjQueryを使ってると地獄
あとフロントライブラリの中で
jQueryを前提としていてjqueryで書かれているものが
かなりあることと、
ライブラリの使用例がブログとかでjqueryが書かれている場合
他人がjqueryで書いててコピペしたい時に
jqueryに依存してしまうケース
新人は素のDOMでもReactでもなくまずjquery
でコードを書こうとするがこれを正そうとするのは
非常に面倒
こういうの加味すると脱jqueryはかなり困難 > React使ってるのに内部でjQueryを使ってると地獄
そりゃそうだな。ReactはDOMと共存できない。
だからReact使ってると内部でDOMを使ってると地獄だ
jQueryだけに限らない 皮肉が通じなさそうだからもう少し説明してやるかｗ
>>704はjQuery側の問題ではない。
React側の問題だ
jQueryがーと書いてあるが
それは全てDOM APIを直接使った場合にも当てはまる
ReactとDOM APIを共存させる方法だってあるーという
話をし始めたら、その方法を使えばjQueryも共存できることになる
jQueryはDOM APIを簡潔に使えるようにしたライブラリに過ぎないのだから 実際なんで増えてるか不思議
技術スタックあるから大手の制作会社はjqueryばっか使ってるってことかね 既存サイトやフレームワークやWordpressみたいなものでページ作ったらjQueryも付いてきたってパターンはありそうだと思った 俺からすればなんでjQueryのシェアが減ると思ってるのかなって感じだがな
jQuery不要とか言ってるやつの言葉を正確に言うと
「jQueryなくても冗長になるだけで頑張ればできる！」
だからな。これはデメリットにはなってもメリットにはなってないんだよ。
jQueryをなくした場合のメリットは一応ある。例えば
「jQueryをなくすとで30KB（gzip圧縮状態）減る！」とか
「DOMを直接使うと実行速度が1%（？）速くなる！」とか
でもこれらを言うことはない。
jQueryをなくすとこにメリットが有ると感じてるなら、それを言えばいいのにそれを言わないのは
jQuery不要と言ってる人が、本当はなくすことにメリットを感じてないからなんだろう
だから「脱jQuery」とか言ってごまかしてる。これは目的ではなく手段
DOM API vs jQueryであれば明らかにjQueryの方がメリットあるわけでjQueryを使い続けるのは当然
仮想DOM使ったフレームワークとjQueryであれば、フレームワークの方がウェブアプリを作るときに
メリットがあるけど、ウェブの大部分はウェブサイトなんだよ
とある会社の"ホームページ"でJavaScriptがバリバリに使われてると思うか？思わんだろ？
普通の会社のホームページに飛んだ時、動き出したらうざく感じるだろ？
それが許されるのはゲーム会社とかアニメーション会社ぐらい
JavaScriptは昔からページの一部に動きをつけるための簡易的な
スクリプトとしての利用が大部分なんだから、その延長上にあって
より簡潔に記述できるjQueryが使われるのは当たり前の話
DOM APIはjQueryの簡潔さに追いついてないし、フレームワークは全くの別路線だ 採用するメリットの少ないSPAフレームワークより
より便利で馴染みのある従来のフレームワークのほうが採用される確率が高い
従来のフレームワークにはたいていjQueryがセットで付いてくる bootstrap jQuery辞めるってよｗｗｗ >>699
Webシステムの開発者にはReactとかの方がいいけどWebサイトのコーダーにはjQueryだろ
もう根本的に用途が違うものと見た方がいい >>706
jQuery側の問題でもReact側の問題でもない
それをやる奴の頭が悪いだけ 世の中圧倒的な数のゴミサイトが量産されてるんだからjqueryを使う意識なくてもWordPressとかが使ってるからな
WordPressなんかWordPress内のjqueryの他にテーマが読み込むjqueryや各プラグインが読み込むjqueryとか1ページに複数のjquery読み込んでいるサイトがけっこう多くてめちゃくちゃカオスだぞ
ReactなどのSPAライブラリはWordPressやjsプラグインみたいに勝手についてこないからな
ゴミが大量にある状態をシェアも人気も圧倒的とかほざくバカはそれはそれで勝手にそう思ってりゃいいから他で騒いでろ lisp系でお薦めの最新言語はなんでしょう？
Erlang?elixir? >>711
bootstrapがjQuery使うをやめたからbootstrapが使われてるから
勝手に入ってるんだという言い訳ができなくなった
そして>>714はWordPressを言い訳にしてる。 >>716
ゴミ住人がゴミの数を自慢してもさぁ
はよ住処に帰れ >>707-708 >>716
前にも書いたがjQueryは依存関係で知らないうちに
入ってる人が多いだけ
アホなjQueryおじさんは事情を知らずにシェア増えてると喜んでる。
jQueryのコード書いてる人が増えてるわけではない。
例えばbootstrapもjQueryを読み込むようになってる
最新bootstrapはjQuery依存を解消したが最新版は旧ブラウザの
サポート切ってるからあえて古いBootstrap使ってる人も多い。 > 前にも書いたがjQueryは依存関係で知らないうちに
> 入ってる人が多いだけ
依存関係で知らないうちに入ってるのを除くというなら
将来BootstrapやWordPressでフレームワークが
使われるようになっても除かないといけない
ということは理解してるかい？ このスレがプログラム板にあるのはWebサイトではなくWebシステムに焦点をあててるからだ
と後付けの理由を主張してみてすつ >>719
jQueryおじ、やっぱり頭悪い
Bootstrapがweb frameworkを使うことはありえない。
WordPressはCMSだからCMSのシェアを見るべき。
そもそもPHPはゴミだから採用の選択肢にあがらない jQueryおじはそもそもweb frameworkの必要性すら
理解してない無能だからどうしようもない
こういうのがいるからフロントはってバカにされわけ >>721
> Bootstrapがweb frameworkを使うことはありえない。
あれ？なんでWordPressはかかないの？
WordPressがweb frameworkを使うことはありえるわけだよねｗ > WordPressはCMSだからCMSのシェアを見るべき。
jQueryはCMSで採用されているのです。 > Bootstrapがweb frameworkを使うことはありえない。
React Bootstrap
https://react-bootstrap.github.io/
Angular powered Bootstrapng-bootstrap.github.io
https://ng-bootstrap.github.io/#/home
BootstrapVue
https://bootstrap-vue.org/
採用する人いなそうｗ 本業じゃない人がちょっとwordpressのどこどこが不便だからコードコピペして修正、ってなると学習コスト低いjqueryくらいしか無理だろうしシェアは減らなそうだ web frameworkって言葉じゃフロントエンドを指してるのかバックエンド指してる曖昧だからキッチリ明示した方がいいんじゃない？
従来なら寧ろバックエンド側を指して使われてた言葉なはず >>725
それ全部触った事はあるけどAngularだけめっちゃ使いにくかったな >>725
アホすぎて>>721がそういう意味じゃないのわからない？
web frameworkがBootstrapを使う（呼び出す）ことはあっても
逆のパターンはあり得ないって言ってんだよ
>>723
CMSはなんらかのweb framework使ってるのが普通だろう
CMSの人気を測る際はCMSのランキングを見る。
CMSとweb framworkのシェアを比べたりするのは意味がないし
そんなことをするのはアホだろう
まったく用途、カテゴリが違うもの比べてどうするつもりだ？ >>727
むしろわかりやすいようにきっちりweb frameworkと書いてる。
web frameworkはserver-sideまで含めた仕事するやつだ
UI側だけの場合は、UI frameworkとかUI libraryと表記されるのが普通 このスレでいつもjQueryのシェア書いてるのは
web framework否定論者のアホってこと >>725
> 採用する人いなそうｗ
jQuery使ってたせいでreactやvueから敬遠されて他のcssフレームワークの隆盛を許してしまったからね。
いまさら脱jQueryしてももう巻き返しは難しいだろうね。 >>704
> React使ってるのに内部でjQueryを使ってると地獄
これ具体的にはどんな地獄があるの？ >733
Reactは仮想DOMといってDOMの情報と同一のものを内部で二重に持っていて
差分ができたら内部のDOM情報を実際のDOMに反映している
だからDOM APIを使って直接実際のDOMを書き変えると
Reactの内部のDOM情報と食い違いが起きて正しく反映できなくなる
何が起きるかはわからない >>734
そういう意味か
なら外部JSの恩恵を享受するためにDomの管理をReact管理から外して利用すれば
問題ないね（この内容はTutorialにもあった） >>729
WebFrameworkって従来はバックエンドを指す言葉なんだけど
フロントならFront-end Frameworkとでも書いたらどうだ？ >>731
そりゃWebサイトおじさんからしたらjQueryは今でも現役だろうから反論したいんだろ
逆にWebシステムの構築を考えた場合Reactが一番妥当だから
中途半端マークアップコーディングやってるVueとかAngularとかは廃れる可能性も結構あると思ってる
Webサイトのコーダーにwebpackでのビルドとかやらすのもナンセンスだと思うから
サイト→jQueryに回帰
システム→React
っていう風になっていくんじゃないかね
ちなここはプログラム板だから議論対象はWebシステム >>737
> 中途半端マークアップコーディングやってるVueとかAngularとかは廃れる可能性も結構あると思ってる
Reactも含め、未完成のWeb Componentsを補うために
複雑なことをしてるから将来確実に廃れるか大幅に仕様が変わるよ
Web Componentsがどのブラウザでも実用的になったら
それをエミュレートしてる今のバージョンは完全にレガシーになって
将来のモダンブラウザのみを対象とした軽量なものが登場する
その時代でもDOMは変わらないだろうから、
そのDOMを簡略化するだけのjQueryは変わらず使えるわけさ >>736
勝手に名前つけても伝わらないだろ
例えばMicrosoftとかはBlazorをUI Frameworkと呼んでいる。
web appに限定されないからfrontend frameworkは不適切 jQueryのセレクタ構文とか、いまじゃバニラのJSでも
document.querySelector('input[type=radio]:checked')
みたいな感じで使えるし簡略化するだけのjQueryはわざわざ読み込むまでも
なくなっていきそうだけどな そりゃセレクタ構文だけだろ
jQueryの特徴は、そのセレクタにマッチする複数（ない場合も含めて）に対して
CSSのスタイルと同じように要素が存在するかをチェックすることなく
宣言的に処理を割り当てることができるのが便利なんだが メソッドチェインできることだけがjQueryのメリット？
ほんのちょっとの便利のために余分なファイルを読み込ませたくないな メソッドチェインの話なんかしてないのに
いきなりなにいってんだろうねｗ
まさかメソッド呼び出しは全部メソッドチェインだとでも思ってんの？ 何言ってるのかわからないけどなにか小粒な利点を主張しているのは分かった
存在チェックすることなしに宣言的に処理をするなんて小粒も小粒 わかった
知能が低くて最新のライブラリなりフレームワークについていけないから
ひがんでるんだな >>745
そんなんだからjQueryがいつまでも増え続けてるのがわからんだよ
jQueryが物理的に行数が減るのは当然として、
その結果、メンテナンスのコストが下がって
バグが減るのが重要なところだろ 素人がちょっとしたWebページにちょっとした動的な要素をつけたいときには
jQuery使うと便利かもね
って程度だよ
jQueryにすがりついてるお前の程度もしれてるｗ 例えば、アロー関数なんて使わなくても
this保存してfunctionつければ同じことができるけど
アロー関数使わなくて良い世界を知ったら元に戻れないだろ？
ほんの数行の違いでもないほうが楽なんだよ まさかjQueryマンセーで愚かな考えを晒すことで周りから袋叩きされる
ということを通してjQueryを貶めるという作戦か そんな願望垂れ流してないで
メリットとデメリットの話をしろよ
jQueryがなくても頑張れるっていうだけで
jQueryをなくすメリットを言わないんだもんなｗ ハァ？jQueryバカはCSSセレクタ丸パクリのクセして自分の手柄にしてんのか。チョンみてーだな(藁 jQueryバカが言ってるメリットはどれも小粒
なくても困らない
なら最初から利用しなければ余計なファイルを削減できる
というのが使わないメリット >>753
もともとJavaScriptでCSSセレクタは使えなかった。
今は単に「セレクタ」というんだが、お前が言ってるように「"CSS"セレクタ」という
言葉があるのは、元々はCSSで使うものだったときの名残ｗ
はるか昔にjQueryがJavaScrpitでCSSセレクタを実装した
その素晴らしい発想を見て、それをあとからDOM APIに
querySelectorとして使えるようにした
パクったのはDOM APIの方。それを知ってて
お前わざと>>753みたいなアホ丸出しのレスしただろ？ｗ
しかしDOM APIがパクったのはセレクタAPIだけで
jQueryオブジェクトはパクらなかったので
DOM APIのループ処理で繰り返すという手続き的なAPIは変わらなかった
宣言的なjQueryの比べれば劣化コピーでしかない 余計なファイルを削減できる？
JavaScript使ってる時点で外部JavaScriptファイルがある
たかだか1ファイル減るだけの話
しかも結合すれば1ファイルですむ jQueryとかメリットなんて微々たるものなのにレガシーブラウザ対応とかで
無駄にサイズがでかいからな
減らす効果はそれなりにあるぞ 余計なファイルを削減できるというメリットは小粒
初回アクセス時に30KB読み込みができるというメリットは小粒
JavaScript処理が僅かに早く終るというメリットは小粒
jQueryをなくしたときのメリットはどれも小粒ではないか
体感上わからない程度の遅延があっても困らない
ならできる限り開発を楽にするほうがいい
というのがメリット >>757
圧縮時30KBはものすごく小さいですが？ 例えばGoogleのシンプルな検索トップページは圧縮状態で65KBでした。 jQueryを利用するメリットがそもそも小粒
ブラウザごとの分岐処理とかが埋め込まれてるから実行時の効率が悪い
ファイルサイズがでかい
つまりいらない jQueryのメリットのうち小粒のものだけを抜き出したら
全部小粒だった
と言ってるのと同じだなｗ >>755
中学校を単に学校というって言ってるみたいなもんだな。バカが。
CSSのセレクタのルールそのままパクっただけの盗人。
盗んだものをもともと自分のだと主張。まさにチョン。 jQueryの価値はjQueryオブジェクトだよ
CSSセレクタなんか、素の使いづらいJavaScriptでもできるじゃんｗ
価値がないところだけを見て価値がないと言っても無意味だよ
もっと広い目でjQueryを見ないとｗｗｗ このjQueryバカは素人レベルのスキルしかなさそう しょぼいWebページをjQueryで作ってご満悦なんだろう いい年こいたおっさんがjQueryにすがりついてるとかダサすぎるんだよ ほらね、もう遠吠えいうことしかできなくなったでしょ？ CSSセレクタパクリがバレたら開き直ったjQueryガイジ。
居直り強盗で駅前一等地を占拠してパチンコで儲けるチョンと同じ。
jQuery関係ないスレで居直り占拠jQueryチョン。 おっと
>>1 に
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
と書いてあったな >>770
なんで無視したの？もう一回同じことを書く羽目になったじゃないか
もともとJavaScriptでCSSセレクタは使えなかった。
今は単に「セレクタ」というんだが、お前が言ってるように「"CSS"セレクタ」という
言葉があるのは、元々はCSSで使うものだったときの名残ｗ
はるか昔にjQueryがJavaScrpitでCSSセレクタを実装した
その素晴らしい発想を見て、それをあとからDOM APIに
querySelectorとして使えるようにした
パクったのはDOM APIの方。それを知ってて
お前わざと>>753みたいなアホ丸出しのレスしただろ？ｗ
しかしDOM APIがパクったのはセレクタAPIだけで
jQueryオブジェクトはパクらなかったので
DOM APIのループ処理で繰り返すという手続き的なAPIは変わらなかった
宣言的なjQueryの比べれば劣化コピーでしかない 言葉で説明されてもメリットわからんな。どうせ議論するならコード書け。 言い出しっぺとして書くけど、これを数文字短くするためにjQuery使うか？
document.querySelectorAll('div.highlighted')
.forEach(ele=> Object.assign(ele.style, {color: 'red', backgroundColor: 'white'})) document.querySelectorAll('div.highlighted').forEach(ele=> Object.assign(ele.style, {color: 'red', backgroundColor: 'white'}))
$('div.highlighted').css({color: 'red', backgroundColor: 'white'});
一行のものはだいたい半分になる。
だがそれよりも重要なのは「宣言的」であるということ
forEachというループが無くなっている 無いとなんかすごいのか？
jQueryが裏で回してるだけじゃん >>776
jQueryが裏で回す（十分テスト済み）＝自分でやらないからバグが減る jQueryとレビューする点を見れば
どちらが大変かなんて明らかなのよ
document
querySelectorAll → $
('div.highlighted') → ('div.highlighted')
forEach(
ele=>
Object
assign(
ele.style, → css
{color: 'red', backgroundColor: 'white'})) → ({color: 'red', backgroundColor: 'white'});
jQueryだと4箇所見るだけですむが、DOM APIだと 9箇所もある コードの意図を隠してまで短くすることか？
その時点で要素があるべきなのか複数なのか何も判らん
エラーが出ない=バグがないってことならいいが >>739
こいつ結局Webサイトの話しかできてねえな
アホだろ
>>750
こいつやはりアホだ
アロー関数がfunctionの代用だと勘違いしてる
その認識でほんの数行変えたらバグるわけ
そもそも仕様がまったく違う >>780
どこにアロー関数がfunctionの代用って書いてある？よく読んでみなよｗ >>779
隠しているのはコードの詳細であって
詳細を隠してるから意図は明確になってる >>739
Web Componentsは流行らんと思うよ正直
こんな移り変わりの激しいWeb技術の世界で3年以上前から話題が上がってるにも関わらず未だに流行りにもなってないっていうのはそういう事だろ
Recoidなんて登場してから殆ど経ってないのにもうReduxを抜きつつある
Web Componentsが本当に良いものならそういう速度感で流行るもんだ
現時点で流行ってないっていうのは結局D言語みたいなものにしかならない WebAssemblyに関してはWebGPUが今後流行ったら多少チャンスはあるかも知れんがそれ以外の用途では望みは薄そうだな Ruby, jQuery は、メソッドチェーンで関数型のように書ける。
a().b().c() みたいに
これを一々、存在チェックしてられない
return if obj = a() == nil
return if obj = obj.b() == nil
obj.c() WebAssemblyはこれからの技術
MS以外がまだまともなframeworkだしてない
JSが好きという人は少ないので必ず流行る
>>786
CPU速くなったらwasmの弱点が消えて長所だけが残るから
wasmはだんだん増えていく > CPU速くなったらwasmの弱点が消えて長所だけが残るから
> wasmはだんだん増えていく
そこに目的がありません
速くなったら使われると思うのはなぜか？
ウェブアプリが作れるようになったら、みんなウェブアプリを作ると思うのはなぜか？
目的がなければ、使うようにも作るようにもならない 劣ってるから使われないって思うのは
技術者のよくある勘違いだよなｗ
そもそも需要がなければ使われないんだよ 不都合な真実、ほとんどの人がwasmを試してすらいない。遅いなんて言ってる人全然いないだろ？ https://classic.minecraft.net/
babylon.js製。
安定して60fpsで動くが、babylon.jsにはWebAssemblyは一切使われていない。 >>789
JSに縛られず開発生産性高い言語を使える
それだけでwasmを使う理由になる × JSに縛られず
○ もとからJS使わない人が使う
だからウェブ系の人は使わないし
JS使わないならネイティブアプリでいいんじゃね？ってなるんだよなｗ >>794
native appだけでいいってのは技術的にはそのとおり
wasmは中途半端な立ち位置だからな
ただApple, Googleで手数料30%取られるだろう？
wasmだとその手数料を回避できるから
そういうビジネスの問題考えたら価値がすごくあるわけ 結局ブラウザから排除されてるJavaAppletやFlashPlayerとWebAssemblyに違いなんとほぼないんだよな >>794
JSについては違う
Blazorのようなのが人気でてくると
JSしかできないフロントエンジニアの存在が不必要になる
C#プログラマーはserver sideとclient sideの両方のコードがかける
JSが必須ではなくなるということは
JSエンジニアが必要なくなる時代ってことだ >>796
まったく違う、わかってない
Sandboxあるからセキュリティが高い
さらにwasmはweb standard Web Components はとても素晴らしいけど、けっこう面倒くさい。でもライブラリとかはバックグラウンドにガリガリ使うようになって間接的に役立つだろうし、なんなら関数でラップしても良い wasmでjsが消えてもDOMは残る。フレームワーク使えば別だけど、DOMから離れようとすれば遅くなり、wasmの速さは失われる wasm＆SPAは業務系の希望になりうると思うが
業務系の複雑なUIはSPAと相性がいい
業務系エンジニアなら誰でも使えるJavaやC#がフロントでも使えたら学習コストが下がる
サーバーとクライアントでロジックを共有すればコストが下がる >>797
> Blazorのようなのが人気でてくると
前提崩れだね。
十年で日本を追い抜く言ってた朝鮮はどうなりましたか？ｗｗｗ
Silverlightｗｗｗｗ なんだよまたjQueryでスレ伸びてるのか。
クライアントがブラウザである以上、jsやcss,domに原則縛られるんだよ。あとは如何に効率よくラップするかの差でしかない。好きなもの選べばいいさ。
ただ未だに生のjsやcssで組んでるやつは流石に時代遅れと自覚して欲しい。 >>803
BrowserはいまだにJSに縛られると思ってるやつは流石に時代遅れと自覚して欲しい
Blazor WebAssembly使い始めたがC#だけで書けるし
Visual Studioで開発できるし最高だわ >>804
期待してるけどツールがまだ追いついてなくて….razorファイルのフォーマットが崩れる問題くらいはさすがに修正してくれないと。
まあ現状はスレチなので。 Blazorはまあまあ悪くないけどソースコード編集してから画面に反映されるまでが遅いのがネックだね >>804
それは違うなだろう。
ラップしてるだけ、意識しないだけで最終的にブラウザが対応してる要素に縛られるのは変わらん。スマホアプリとは全く違う。
フレームワークの進化に対して実行エンジンであるブラウザの進化が遅すぎるんだよな。今でもsafariだけcssの解釈が違うなんてしょっちゅうだし、土台部分の知識が無いと結局対応できん。チグハグで不安定なのがフロントの宿命なんだよ。
だから各フレームワーク、IDEには本当に感謝してる。裏でとんでもない労力かけて俺たちの労力軽減してくれて有り難うだよな。 5GとかiphoneとかRetinaみたいな余計なことして
業界混乱させる前にやるべき事やれや
まずまともなブラウザ提供しろ
さもなくばデフォのブラウザ大人しくchromeにしとけ >>808
自分が読み書きするコードがC#ならそれでいいでしょ
どんな言語も実行前には人間が読めない形になる web componentは流行るかどうかはさておき、必然的に使う場面が出てくると思う。
今後はマイクロサービスと同様にその技術がフロントにも流れてきてマイクロフロントエンドアーキテクチャが主流になると思う。
そうなると、サービス単位で共通なコンポーネントはweb標準であるweb componentで作る必要が出てくる。
どうだろうか jquery別に悪くないけど、今はvanilla jsで十分だし使う場面がない。
モダンフレームワーク（react,vue,etc）vs jqueryという構図をこのスレでは良くみるが意味がわからん。
正しく議論されるべきは
モダンフレーム vs web標準（web componentなど）
だと思う。 オライリーから出てるCSSシークレット著者によるWeb Components評。
ちょっと辛辣。コメント欄で議論盛り上がってるがここChrome翻訳効かないのな…
https://lea.verou.me/2020/09/the-failed-promise-of-web-components/ Web Componentsに対する批判
https://thenewobjective.com/web-development/a-criticism-of-web-components
・CSS疑似セレクターが機能しない
・ネイティブ要素と互換性がない
・Non-trivialな要素はHTMLElementを継承する必要がある
・JavaScriptが必要
・潜在的に指数関数的なフォールバック
・ポリフィルが必要
・Ariaの問題
・SEOの問題
・追加の制限 俺の頭が悪いせいかこの記事の言いたいことがいまいちわからん
plug and playの箇所解説よろ >>815
ｼｨｰｯ! (jqueryバカがよってくるから) >>814
流行らんよ
マイクロサービスはトレードオフ >>817
後で読んでみるけど、
ariaとJavaScript以外は別に問題じゃない気がするけどね web非標準のreactが簡単にssr出来るのにweb標準のweb componentsが事実上無理（初期レンダリングコストはクライアント側で支払うしかない）なのはなんだかなぁ… >>817
templateタグともっと親和性を高めるとかHTMLだけでComponent作れるとやりやすいよなと思う >>825
やろうと思えばできるけどな。shadow domを使わない場合だけど。
でも言いたいことはわかる。そこまでサポートしてから世に放てば良かったのにとは思うけどね。
https://web.dev/declarative-shadow-dom/
↑いま頑張ってやってる途中やで Declarative Shadow DOM か。いいね。
試してみようと思ったらchromeでもまだオリジントライアル中か… やりたいことは理解してるんだけど
英語力がないから何がdeclarativeのニュアンスがわからん。 宣言的だろ？ ようはループを使わないってことだよ
例えばjQueryはループを使わない
$('.selector').css({color: 'red'); このように
これがDOM APIだとループが必要な手続き的になってしまう >>830
絶対に違うわww
宣言的＝ループを使わないが違うということは俺にもわかる 宣言的なweb component
現状のweb componentのどこが非宣言的で、あのリンク先の技術が適用されるとどこが宣言的になるんだろう。イマイチわからん。web componentにおける宣言的ってなんや UI組み立てる系のライブラリは固定乱数でいいから
全てのDOM要素にid振っとけや
色が違うとかアイコンを変えろとかクソみたいな指示飛んでくるんだから 宣言的な書き方に拘っても保守性なんて少しも良くならんわ。 SPAは簡単だったけどCSSがやっぱりわからねえんだわ
SPAで作ってもデザインが古くさくなる デザインなんてとりあえずBootstrapっぽくすればええんやろ？ >>833
乱数のid振ってどうすんだよ？
まさかidで色変えてんのか？
>>835
お前のセンスゼロだしこの先死ぬまでセンスゼロのままだからなあ
>>836
bootstrapっぽくすら不可能じゃん
>>837
センスゼロのやつは死ぬまでセンスゼロ
>>838
Googleが公式にセンスゼロ向けって謳ってるしな
ただしセンスゼロでcssスキルない奴が使うとMaterialUIすらまともに使えない センスゼロでもSPAはできるけど、CSSはそうもいかんからなぁ
センスゼロでも使えるライブラリを使うしかないか
逆に言えばライブラリ使えば、センスゼロでもCSS、SPA両方できるようになるわけだし、こだわり捨てればまあ、いいか
すぐに移り変わる分野だし、気楽にやろう MaterialUIなんて公式のサンプルコピペしてテーマ設定するだけでそんな酷くならんと思うが
これ以上のリッチなもの求めてて自分で勉強できないならデザイナー雇うしかない
色彩センスは今どき色選んでくれるサービスたくさんあるだろ
ttps://yumyumcolor.com/ とか MaterialUIとBootstrapは併用できるの？
混ぜるな危険？ material ui 重い…
軽量でいい感じのが欲しい この手のUIフレームワークは余白が多すぎて、1画面の情報量が少ない
スマホアプリ前提な感じ >>842
やろうと思えばできるが崩れる上にそもそもやるやつはアホでしかない
>>844
余白なんか調整すればいい
キツキツの帳票みたいなUIが好みという日本人が多いが世界中から笑われてんの未だに気づかない連中ばかりだからな 情報をギッシリ詰め込むのは別に構わないと思うが
ダッシュボードとかでよくある
しかしジジイどもは同じ画面で入力もやらせようとするからおかしくなる >>844
Vue もReact もAngular も
全く関係ない話だ スマホ向けのUIとPC向けのUIを同じテーマでやるのは無理ある
サイトリニューアルして昔あった機能や要素を削除して既存ユーザーから大反発食らうのがこのパターン >>850
結局SPAって1つか2つの問題を解決するために他の多くの問題を呼び込んでるんだよな >>850
vue.js で CRUD アプリを造りたいとか
発想そのものがあほやん
https://qiita.com/koduki/items/9ce6ad8787b32caa38ff
CRUD にしたいなら vue.js 使わなければ良いだけの話だろ >>852
だから
（殆どの用途には）vue.js 使わなければ良いだけの話だろ
と最初から言ってるだろｗ https://w3techs.com/technologies/history_overview/javascript_library/all/y
2020年10月15日 76.5%
2020年10月23日 76.6%
2020年10月25日 76.7%
な？だからjQueryが使われてるんだって
少なくとも10日で0.1%以上増えてるからな シンプルなアプリは開発者、利用者の両方の視点でMVCフレームワークの圧勝だろ
複雑なアプリになると開発者としてはSPAのほうが作りやすいが、、、
しかし利用者からすれば複雑なアプリの需要なんてのはほとんど無い等しい
例えばpgadminは複雑なアプリだがぶっちゃけシンプルなadminerのほうが使いやすいのだ
結論
SPAはゴミ 「脱jQuery」を目的にするとたいてい失敗する
なにか問題があって、それを解決するためにVue、React、Angularなどを採用すべきという
当たり前の前の話であって、良い選択肢の１つであるjQueryを廃止して
特定の用途専用のものを導入するのは愚かである
特定の用途専用のものは、特定の用途の場合に使うもので
「○○の用途のために○○を導入しました」という言い方にするべきだ ようするにUX設計ができない人のためのフレームワークがSPA 今までSPAのやり方でスマホアプリとか作ってきた人たちが
今までと同じやり方で作るためのものSPAだろう
ウェブにはウェブのやり方があるんだが
そういう（アプリ作ってひた人たちにとっては）"新しいやり方"を
学ぶ能力がなくて、今までと同じやり方でやりたいっていうのがSPA
これからはSPAだ〜とか言ってるやつは、jQueryどころかCSSも嫌いなはず
なぜならどちらも宣言的だから。SPAは手続き的に作る。
セレクタに対して処理や属性を宣言的に適用するjQueryやCSSは
考え方が根本的に違っていて、頭が凝り固まってる人には理解ができない 良い加減スレチ
くだらん話でスレ埋めるな
よそのスレか板いってくれ jQueryが増えてるってのは事実として
それ以上に増えれば、シェアはjQueryよりも増えるんだよ
結局増えてねーじゃんと jQueryとReactじゃ根本的に作るべき対象が違う うん。だから最初から根本的に作るべき対象が違うので
「脱jQuery」ありきは間違いだって言ってるわけ
作るべき対処がjQuery向きじゃない場合に使えば良いわけで
今までjQueryで問題なくやってきたところが脱jQueryするのは
意味がないどころか、デメリットになってるわけ
作るべき対象がjQuery向きなのに、脱jQueryしてどうするんだと フレームワークなんて概念がなかった時代にjQueryで無理やり作ったシステムとかならフレームワーク置き換えって結構意義はあるけどね
段階的な置き換えか一から再構成かは都度都度によるけど Ruby on Rails では、React, Bootstrap が多い。
Material-UI を使った場合は、レスポンシブ対応になるのかな？
react-bootstrap という、BootstrapをReactコンポーネントとして再構築した、UI フレームワークもある。
jQuery など不要な依存関係がない Rails, React, Bootstrap で、
Bootstrap 4 が、jQuery に依存しているから、使っているだけ
react-bootstrap など、jQueryに依存していない場合は、axios が多い >>854のシェアって公開されてない社内サイト/アプリやログイン必須アプリも含まれてるの？ ブラウザ毎に仕様が違った時代に重宝されたjqueryを未だに崇めてる奴は脳みそがそこで止まっているわけだ 脳みそが若いままプリプリってことだ。物覚えもいい。 >>872
脳が止まってるのはお前やで
未だにjQeryの便利さをブラウザの仕様の違いを
吸収するためのものだって思ってるんだろ？
jQueryすげー、DOM APIが簡潔に書けるーってみんなが思ってる中
ブラウザの違いを〜とか言ってて恥ずかしくないのか？ 未だにDOM直接イジってんのかｗ
おっさん哀れだなぁｗｗｗ そりゃフレームワーク開発者は使うでしょ。
詭弁のガイドラインみたくなってきた。
2.ごくまれな反例をとりあげる
4.主観で決め付ける
11.レッテル貼りをする フレームワーク開発に必須な知識を持ってる
まれな人材ですよね >>874
ミクロな視点でみれば簡潔に書けるのかも知れんが大規模なソースを構造化するのにはあんま向かないよ >>879
関数を使え
構造化するのにフレームワークなんぞいらん >>879
大規模なものを作るならモジュールに分けましょう
jQueryでも同じことです。 こういう基本的なことが出来てない人がSPAに手を染めて出来た気になっちゃうのかな 世界中でjqueryは時代遅れのゴミクソと言われてるのに未だに崇めてるバカは脳みそがjqueryで動いてるらしい その「世界中」の現実です。
https://w3techs.com/technologies/history_overview/javascript_library/all/y
jQuery
2017年 71.9%
2018年 73.1%
2019年 73.6%
2020年 74.2%
2月 74.4%（1ヶ月で+0.2%）
6月 75.5%（4ヶ月で+1.1%）
8月15日 76.2%（2ヶ月で+0.7%）
10月15日 76.5%（2ヶ月で+0.3%）
10月25日 76.7%（0日で+0.2%、10ヶ月で+2.5%）
Vue.js 0.4%（1年で+0.1%）
Angular 0.4%（1年で+0%）
React 0.3%（1年で+0%） 訂正
10月25日 76.7%（10日で+0.2%、10ヶ月で+2.5%） フレームワークはjQueryより"簡単"なんだから
jQuery使えるなら、フレームワークも使えるんでしょう？
それともフレームワークの方が難しんですか？（笑） jQueryおじが住み着いてるようだけど
その時間に新しいframeworkの勉強しようという気にはならないんだな
成長しない、できない人 まず君の理解が足りてないのは
jQueryとSPA系のライブラリは役割も規模も全然ちがう
jQueryじゃ機能が足りてなさすぎて
SPA系のライブラリに張り合うだけの立場にすらない
君の存在自体がスレチ >>888
Backbone.jsを勉強したほうがいいよって
昔言われたことがあるよｗ >>889
続きまだ？ jQueryに足りない機能の話をしてくれるんじゃないの？
もうずっと待ってるんだけど、いつ書くの？ >>887
おめーの時代遅れjqueryで動いている脳みそで判定できるわけねえだろ >>884
これだけはっきり数字で示されてるのに認めない香具師って科学的な思考プロセスができないのかな？
文系さん？ Reactでできるような状態管理、動的なDOM構築がjQueryだとどれだけ泥臭くなるか一回試してみろよ
jQueryだけじゃスケールしないことがわかる
Node.jsの基盤上で開発すると開発言語は例えばTypeScriptにできるし
ブラウザでの確認とかMinifyもコマンド一つだし
古いブラウザへの対応もバージョン指定すればPolyfillが埋め込まれるし
CSSもトランスパイルの過程で一意なクラス名を生成するとかもできる でもそのシェアってニュースサイトとかブログとか自動生成ページとか入ってるんでしょ？ >>895
> Reactでできるような状態管理、動的なDOM構築が
そもそも、そんなもの必要ないんだよね
状態は、グローバルにでっかく持つんじゃなくて
個々の要素に持たせればいいだけ
小さくモジュール化しましょう
動的なDOM構築ではなく、静的なDOMで構成を作って
個々の要素の状態によって、表示を変更するだけにしましょう
例えばアコーディオンようなものは、複雑なDOM構築を行わないと無理だと
思ってるんだろうけど静的なHTMLとCSSだけでもできる
本当に無理なことだけをJavaScript（jQuery）で補完してあげるだけで完成する。
そのやり方を知らないから（CSSを使いこなせないから）もったいないことにCSSの機能を破棄して
全部JavaScriptでやるから、DOM構築大変だー、動的だー、複雑だーってなるんだろ そもそもの出発点が「Reactでできるようなこと」となってるからおかしいんだよ。
出発点は「作りたいもの」であって、それをReactで作ると、状態管理と動的なDOM構築が必要になって
jQueryとCSSを適切に使うと、そんなもの不要でシンプルに作れる
「作りたいものはなにか」を基準に考えろ だから複雑なものを作ろうとしたときにjQueryでは限界があるのを確かめてこい
アコーディオンなんてReact使うまでもない
もしかしてしょぼいアプリしか作ったことない？ 苦し紛れに出した例がしょぼすぎて程度が知れるってもんだわ 複雑な状態を持つものな
アコーディオンなんてOn/Offしかないじゃんｗ Reactを適切に使うと管理する状態が減って楽なんだけどな〜。使った事ないんだろうな アプリケーションと単純なuiを同列に語って、フレームの必要性を述べてるとか大丈夫か？ やっぱり、フロント、JS界隈はレベルが低いな
C#理解してるBlazorスレとレベルが違いすぎる blazorなんてJSもTSすら理解できない老害のための介護フレームワークじゃんｗ
あとsilverlightはどうなりましたか？ｗｗ >>905
例えばC#のどのへんがレベル高いんですか？ >>899
設計が下手くそだから複雑なものになってしまったんだろｗ
まず設計をシンプルに保つんだよ
そうすりゃ複雑なフレームワークは不要になる
こんなん自明の理だろうが 設計が下手くそ ねえｗ
同じ人間が作ってもよりスケールする方法って言ってるのにｗ
頭悪いとしか言いようがないわ そらお前みたいに素人が作るレベルのものでは
jQueryで十分だったんだろうなｗ ここに書き込んでる人間は信用しなくても
SPAライブラリ作ってる人間がお前よりはるかに優れた技術と思想を持ってるのは確かだから
jQueryがあるのになぜそんなライブラリをわざわざ作ったのか
考えれば自明だろ
雑魚が突っかかるな しかしReactやVueはなんだかんだ出てくるのにAngularの話題はさっぱり無いな。スレタイから外して良いのでは？ >>910
jQuery vs SPAにスケールは関係ないぞ
設計が正しければjQueryでもSPAでもスケールする
設計が悪ければどちらだろうとスケールしない
SPAなら自動的にスケールするだとかSPAじゃないとスケールしないと言いたいのならばそれは全く的外れな主張だ jQueryバカもエアプで文句言ってるだけだからな
俺は両方経験してきてるけど >>906
JSはそのうち消えるぞ
>>907-908
C#のがはるかに高機能なのにC#使いが理解できないわけないだろｗ
silverlightなんて古い話はどうでもいい
wasmはweb standardだぞ
note.jsみたいな低速バックエンドつかってる情弱はだまっとれｗ
>>908
あげたらきりがないが、高速な実行スピード、開発スピード。
Type safety
LINQ
Visual Studio
充実したドキュメント
MSによる長期サポート >>917
消えないよ。
例えばC#にしよう！となるとなんでRustじゃダメなんですかGoじゃダメなんですかとなる。
Rustにしよう！となるとなんでC#じゃダメなんですかGoじゃダメなんですかとなる。
JS以外は共通語としてコンセンサスが取れない。
結局いつまで経ってもJSとその他（会社・プロジェクトごとに異なる）という枠組みが残る。
そのうち消えるのは確実にC# >>917
いやいや
C#使ってる人間がする議論のレベルの高さを聞いたんだよ
C#なんて馬鹿でも使えるんだから C#がレベル高いとは思わないが、jsやってる人はなんとなく苦行を強いられてる気がする。
でもそれが技術なんだとおもいこんでるきがする。
tsで型使うとこんな便利なんだ！って書いてるブログ見てそう思った。
え、そんなの当たり前じゃないの…ってことが書いてた。
こんな比較はC#もjsも実務でバリバリ使いこなせてる人じゃないとできない。 そもそもjsしかできないと思ったら大間違いだからな nodejsのパフォーマンスがボトルネックになることってなさそう。
大半のアプリケーションがボトルネックになってる箇所はネットワークの待機時間とかなんじゃないの？ 実践Rustプログラミング入門って本で
JSをRustで書いたwasmに置き換えたらどれだけ速くなるか示します！みたいな章があって、
結局あまり速くなってませんが理由はいろいろ考えられます…みたいなションボリした感じで終わっててワロタｗｗｗ jqueryはWordPressにWordPress専用のjquery、テーマ毎のjquery、プラグイン毎にjqueryがバージョン別に読み込まれてるからコンフリクト起きていても単純に全てjqueryオブジェクトにぶっ込んで見た目は動いているように見えているだけ
しかもjqueryオブジェクトは全メソッドを保持するというゴミ仕様
使わなくても全て実装している
これどうやってテストすんだよ？ゴミクソjquery脳だと >>899
> だから複雑なものを作ろうとしたときに
複雑なものは単純化して作りましょう SPAだったら複雑なものが作れる！
ほら、すごく複雑なUI！！！
馬鹿じゃなかろうかｗ >>924
> プラグイン毎にjqueryがバージョン別に読み込まれてるから
いちいち嘘つくなよ。実例だしてみろよ
アホかｗ >>927
おめーがわかってねえんだろ
WordPressというゴミクソはなんでもアリだからテーマでjquery読み込もうがプラグインで読み込もうが関係なく読み込んでるんだよ
ちなみにWordPressには未だに1系のjqueryが使われている
そしてjqueryオブジェクトには全ての関数が生えている
素のjsでできるのにわざわざjqueryで処理させるために
素のjsでdomを処理したら当たり前だがjqueryオブジェクトには反映されない
この不整合が生まれる
さらにWordPressやテーマに付属のjqueryや他のjqueryプラグインが勝手にdom変えると自分がいじってるはずのjqueryオブジェクトには反映されないからどうなっているのかわけわからんことになる
こんなゴミクズ仕様で開発やテストなんか不可能
バカが簡単と思ってやっていたら本番稼働で動きませんでしたっていうだけ
それに気づかない奴がjqueryを崇めている > 素のjsでdomを処理したら当たり前だがjqueryオブジェクトには反映されない
> この不整合が生まれる
え？何の話？
jQueryを仮想DOMとでも勘違いしてるだろｗｗｗ > さらにWordPressやテーマに付属のjqueryや他のjqueryプラグインが勝手にdom変えると自分がいじってるはずのjqueryオブジェクトには反映されないからどうなっているのかわけわからんことになる
ならんなぁ、どういう使い方してるのか書いてみ あー、いや言葉で説明できないだろうから
再現コード書いてみ >>931
おめーがバカだからんかんねえんだろゴミクズ
jqueryしか使えないアホは理解不能だからソース書いても理解できねえだろ >>898
chromeのdevtoolsみたいなのreactで作ってんだけど、本当にjQueryで出来る？ >>919
C#選ぶという選択をできてる時点で技術的に優れてる
C#使いにframework不要論説いてる無能はいない >>920
JSやってるやつらはそもそもほとんど型の概念理解してない。 >>917
> Type safety
> LINQ
> Visual Studio
> 充実したドキュメント
> MSによる長期サポート
それ全部ある上にWebでネイティブに使えるTypeScript最強説 >>926
お客様「使いにくいからシンプルに戻して」
まあこれだよな >>937
設計者同じだしな。
C#＝ジャギ
TypeScript＝ケンシロウ >>937
やはりアンダースヘルスバーグは天才なんだね Vue 、React、Angular 使えるレベルの人に
はBlazorは不要では？ 今日のOPって
1.1750-60ドル
これだよね >>942
安全堅牢で高速なフロントエンドを作りたいならありかもね
まあ速度はこれからだけど >>944
Blazorはdomをjsで書き換えてるんで
なんだかなぁ？って感じなんで
js一切使わないバージョンが出てからの期待だね。 正直ReactがWasmに対応して他を駆逐する未来もありそうだと思う。Wasm使っても結局DOMは残るわけだし、Reactiveは確かに強力だし >>937 >>939
高速な実行スピード、開発スピード。
この1行抜いたのはなぜだｗ
TypeScriptのデバッグはC#よりかなり劣化するだろ
TSはトランスパイル後はJSでしかない。
JSをマシにする程度の技術でしかない。
JSの弱点の多くは残る
WasmでJS縛りがなくなった以上、同じ開発者のC#を
使うほうがいいだろう >>947
単に入れ忘れた。すまんな。
トランスパイルしてもTypeScriptのエラー箇所は(SourceMap作れば)普通にブラウザが教えてくれるし、ブレークポイントもブラウザで使えるでしょ。
というかその理屈だとWasmに変換したC#の方がデバッグ難しくない？ >>942
Blazorならバックエンドも同じC#で開発できて効率がいい Blazorってクライアントサイドとサーバーサイドでモデルの共有ができる。
これってかなり楽だとおもんだけど、他のフレームワークってこういうのある？
無知ですまん。 >>950
Microsoft以外にはないはず。
MSはfrontend, backendのframeworkの両方を開発してるし
さらにDatabaseまで作ってる。
Modelのclassからtableの作成まで連動できたり生産性がぶっちぎりだからな Googleならクライアントから直にオブジェクトをDBとやりとりできる環境もあるんですよ。Firestoreって言うんですがね。 >>932
再現コードはまだですか？
>>933
chromeのdevtoolsみたいなのとはなんですか？
どの部分ができないと思うんですか？ あるのかないのかどっちなんだ…
例えば、
バックエンド側でデータベースにアクセスしてモデル…c#であればDBのテーブルと同じ構成のpocoに突っ込んで
フロントエンドに返すようなよくある仕組み。
このモデルから項目を一つ削除したとする。
Blazorなら、フロントエンド側で削除した項目を使っている場合は、そんな項目はないですよとIDEがエラーを吐くよね。
こういう仕組みが他のWebフレームワークにあるかを知りたいのですよ。 >>956
従量制でコスト高いクラウドと比べるとかアホじゃないのか
そんなのバックエンドのスキルないやつがつかうものだ >>933
Firefox debuggerはReact採用してるね。
https://madewithreactjs.com/firefox-debugger
Chrome DevToolsはLighthouseタブの中がReact製。
DevToolsも拡張機能で拡張できるがReact使ってるの多い一方jQuery製は見たことない。
恥ずかしくてストアに登録できないんだろうなｗｗｗ UNITY Editorは何で作ってんだろ？
かなり高度な実装なんで気になる。 >>959
ないでしょ
MSの開発ツールと同レベルのデバッグできる開発ツールはない
JSもRubyもType safetyじゃないからできない
JavaとかKotlinとか静的言語ならできる可能性あるけどツールの存在は知らない
kotlinとかはそもそもいいframeworkがないし >>965
ちょっとわるいけど>>957と戦ってもらっていい？ >>966
戦うまでもない
node.jsでできるわけがない、そいつ嘘つき
もしくはバックエンド、DBの知識がゼロ
node.jsはframeworkじゃないし
JSはtype safetyですらない 本当にないの…？
え、じゃあみんなバックエンドのモデルに変更があったよー、フロント側の影響あるところシラミつぶしに探して修正してくれー
なに？修正が漏れて本番環境にリリースされた！？
バッカモーン今度からはトリプルチェックだー！
な事してるってこと？
それって苦行すぎないか…？
Blazorの話がしたいんではなくて
世のWeb系と言われる開発者の皆さんがこの辺どういう風にしてるかを知りたい。 jqueryはお話にならない
ゴミクズjqueryは無駄で不要なメソッドをわざわざすべて生成しているゴミのような仕様
domの構造に依存しているから再利用性ゼロ
テストもできない
アホ専用 そもそもなんでjQueryの話聞かされなきゃならないんだ
本当に迷惑だよな >>962
ひどい後出しジャンケンだな。あるか無いかの例として出しただけなのに。
コスト面で言えばMSのライセンス料すらかからない構成もできるよ。Linuxサーバで、NodeとTypeScript使ってフロントとバックエンドで型を共有して、JSONがほぼそのまま格納できるMongoDBとかも構成可能だよ？ 新スレ乱立してるから立てるなよ
次は下のでいいだろう
理由はAngular誰もつかってないし3つで対決する必要がない。
VueもReactに寄せてきてるっていうしその二つで対決させてもしょうがない。
フロントエンドJavaScriptフレームワーク総合
http://mevius.5ch.net/test/read.cgi/tech/1591848719/ ★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください >>973
TSもframeworkじゃないだろ
>>950の質問読んでも理解できないならいいかげんなレスつけるな
おまえもbackend , DBについてわかってない
>>974
明らかな間違いを訂正してやってるのに荒らし扱いとかアホかと >>974
ロジカルに反論できなくなった負け犬って相手を貶めることしかできなくなるんだよね
つまり先に悪口、罵倒レスを書いたほうが負け
これで決着かな >>975
フレームワーク無しで解決するなら別にそれで十分じゃん。
>>976
誰も勝負なんてしてないよ。何と戦ってるの？ >>977
ts, jsでは解決しないっての
言語だけtype safeならいいって話ではない
言語、framework, IDEとかトータルで対応していないとMS並みの
高度なデバッグ、高い開発生産性は実現できない >>978
IDEはVSCodeがあるよ。君の大好きなMS製で、strictなら型情報に合わせて色々やかましく言ってくれるから実行時の型エラーは事前に消せる。デバッグ環境はブラウザが高機能化しててかなり充実してる。
さて残るはMS制のフレームワークだ。どういう優位性があるのか具体的に示してよ >>979
だから質問者がかいてるだろ
backendやDBの勉強して自分で試せば違いはすぐにわかる。
modelがなんなのかわかってない人たちには説明できない
VS codeもVisual Stuidoに比べるとかなり劣る
ブラウザレベルとか論外
backendやDBの勉強のしなさい >>980
具体例で説明してくれないのか。君なら一生懸命解説してくれると思ったのに。
がっかりだよ clientとserverが同じ言語で書いてるなら、モデルの共有は可能でしょう、普通に考えて。 blazorがモデルの共有が便利！！とか書いてる人は一体どの時代を生きてるんだろうか。
まだ、grpc時代にモデルの共有をフレームワークと一緒に語るのがお門違いですよ。 プログラミング領域ではモデルはいろんな意味を指すよ。
君の言ってるモデルが何を指してるいるのか説明していない時点で議論にならない。 blazorググったけど、モデルの共有なんて意味不明の機能無いし
（これは真面目にblazorやってる人怒るよね( ;∀;)）
最初ORM的な事言ってるのかと思ったけど、
おそらく両層でC#のコード使いまわせるレベルの事言ってると思いますよ。 なんとまぁモデルの意味がわかってないのは彼の方だったか。
彼のせいで無駄にblazorに負のイメージがついてしまった >>981
限度があるだろ
すでに概略は書いてるし。
基本用語、概念を分かってないなら説明できない、
正確に言うと時間がかかりすぎてやってられない。
勉強してっていうのが一番親切、お互いに時間効率いい >>985
C#知らない人の言葉で説明できるかよ
C#、LINQ, Entity Framework, Database,
ASP.NET Core, Blazor, Visual Studio, Web API, SQL,
この辺の知識あればC#でいうところのmodelが何なのかはわかるんだよ そんなモデル共有なんてやってたら不必要な情報までブラウザ側で持つ事にならないか？ >>987
わかってないのはおまえだ
C#でmodelといったら通常はEntity Frameworkを
使うようなclassだ
ASP.NETならModelsフォルダの中とかだ
>>986
modelはもっと別のレイヤーの話だっての
C#とLINQとEntity FrameworkCoreを勉強しなさい ASP.net coreもC#知らんくせに上からのやつばっかりでイライラしてきたわ
C#はmodelのところにちょこちょこ書くだけで
Validationのコードも自動で生成してくれる
JS系でゴリゴリやってる原始人どもにはわからない世界
>>986 >>983
コード共有だけではない
modelへの変更をDBなどに反映させる仕組みもある
デバッグ含めてトータルの生産性を語っている文脈 ３、４年ほど前になるか、仕事でこんな人を相手にしなければならなくなって、
（まじでしゃべる内容が似てる）その時の事をいま思い出した...。 >>984
gRPCのモデルってロジック持てるんだっけ？
ドメインモデルの実装できる？
C# Blazorなら1コードでクラサバ両対応できるけど そろそろ1000
新スレ乱立してるから立てるなよ
次は下のでいいだろう
理由はAngular誰もつかってないし3つで対決する必要がない。
VueもReactに寄せてきてるっていうしその二つで対決させてもしょうがない
フロントエンドJavaScriptフレームワーク総合
http://mevius.5ch.net/test/read.cgi/tech/1591848719/ Web appでgRPCなんてわざわざめんどくさくしてるだけだろ
生産性低すぎ、バカらしい C# Blazorのようにモデルを共有できないアーキテクチャの場合、例えば↓こういう要件ではどうするんだ？
エンティティが単価、税率、個数って属性を持っている
単価、税率はリードオンリーで表示
個数は入力可能
リアルタイムの計算項目として税込み価格(単価*個数*(1+税率))をリードオンリーで表示
この税込み価格の計算は明らかにドメインロジックでありプレゼンテーションロジックではない
1. 税込み価格の計算のためにいちいちサーバーに問い合わせる
2. 簡単なロジックだからプレゼンテーションで計算することで妥協する
もちろん税込み価格なんてのはごくごく簡単なロジックだからどっちでもいいじゃないかと思うかもしれない
しかしそれは簡単な例を出したからにすぎない
現実の世界はもっと複雑でユーザーの要求は予測不可能だ
モデルをクラサバで共有できればこんなくだらないことに悩むこともなくなる
C# Blazorならそれができるのがデフォルト >>994
自分の感覚を世界の常識だと思ってる。よく居る老害だね 現実問題、TypeScript使ってると大量にanyに遭遇するからな
用途によってはそっちの方が適切なこともあるだろうし このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 89日 14時間 7分 22秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
