Vue vs React vs Svelte Part.6
レス数が1000を超えています。これ以上書き込みはできません。
実際どうなん？
※Angularは残念ながら全く話題にならなかったのでSvelteに差し替えました
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Svelte
https://svelte.dev/
※前スレ
Vue vs React vs Angular Part.5
https://mevius.5ch.net/test/read.cgi/tech/1596029929/
★ここではjQuery, Ruby, C#, Blazorの話題は禁止です
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
Angular, Next, Nuxt, Sapper, Gatsby, VuePress, RedWoodなどはおｋ。 Q. jQueryはどのバージョンを使えばいいのですか？
A. IE9以上であれば、jQuery 3.0以上を使用してください。
IE8以下にも対応するならば、jQuery 1.12を使用してください。
補足
jQuery 1.9 までは一系統しかなく、古いブラウザも含めて全て対応していました。
その後、古いブラウザを切り捨てるためにバージョンを分岐させました。
古いブラウザにも対応した1系（1.10、1.11、12）と
古いブラウザを切り捨てた2系（2.0, 2.1, 2.2）です。
1系と2系は対応ブラウザの違いだけで機能は全く一緒です。
機能が同じなのにメジャーバージョンが違っているのが分かりにくい
ということでバージョン番号の付け方を変えることになり、
新たに古いブラウザを切り捨てたjQuery 3.0、そして古いブラウザにも対応した
jQuery Compat 3.0がリリースされる予定でした。
しかしマイクロソフトが古いIEのサポートポリシーを変更し
サポート中であるOSで動く、最新のIEしかサポートしなくなったために、
2016年1月でVista上のIE8のサポートが終了しました。
そのため予定されていたjQuery Compat 3.0がなくなり、
jQueryは3.0に一本化されました。 jQuery 3.0正式版がついにリリース。通常版のほかに、Ajax機能を省略したスリムビルド版も提供
http://www.publickey1.jp/blog/16/jquery_30ajax.html
2006年1月にjQueryが初めて世の中に登場してから10周年となる今年。jQuery 3.0の正式版が登場しました。
jQuery 3.0 Final Released! | Official jQuery Blog
これまでjQueryは、、モダンブラウザのみをサポートすることで軽量化と安定化をはかった
「jQuery 2.x」系と、Internet Explorer 8以前を含む古いバージョンのブラウザまで
サポートする互換性重視の「jQuery 1.x」系の2系統が存在しました。
また、フル機能のjQuery 3.0のほかに、Ajaxの機能を省略して軽量化したスリムビルド版のjQuery 3.0の提供が行われます。
Along with the regular version of jQuery that includes the ajax and effects modules, we’re releasing a “slim” version that excludes these modules.
通常バージョンとしてAjaxやエフェクトモジュールなどを含んだjQueryと同時に、これらを外した“スリム”バージョンも提供する。
最近のWebアプリケーションではjQueryのAjaxを使うことは少なくなったと思われますので、スリム版のjQueryで十分だという開発者も多いでしょう。
圧縮後のサイズは通常版が30kbなのに対し、スリム版は23.6kb。 jQueryはオワコン？いやいや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%） >>1 書き忘れた
★推奨NGワード
jQuery
Ruby
C#
Blazor
全くスレタイと関係ないものばかりなので、連鎖あぼーん有効で問題ないでしょう。透明あぼーんもオンにしときましょう。 シェアを根拠にｊQueryを自慢してるやつは
マクドナルドのハンバーガーを自慢するのと同じだってことに気づけ マクドナルドのハンバーガーの何が間違っているか言えるか？
あれは、「一番普及してる＝美味しい」としてしまったこと
美味しいが間違いなのであって「一番普及している＝総合的に優れている」という
結論であれば間違いじゃないんだよ
「美味しい」というのは優れている要素の1つでしかない、
「一番普及している＝安い」ということだってできる。もちろん一番安いわけでもないだろう
いろんな要素があって、それらを総合的に見た時優れている。
「マクドナルドのハンバーガーは総合的に一番優れている」という言い方ならおかしくもなんともなかった
あの話は「美味しい」にしたところが間違いなだけ。
一番普及しているという事実には、そこに優位な理由が存在していることを意味している
jQueryもそうだわな。Windowsだってそうだ。
すべての面で他より勝ってることなんてありえない
しかし一番普及しているものは総合的に優れているということなら正しい ウェンディーズのハンバーグが一番旨かったと思うが
ウェンディーズは死んでしまった
良いものが残るとは限らない × 良いものが残るとは限らない
○ 美味しいものが残るとは限らない
旨かった＝良いものではない。そこが間違っている
戦略的に"優れているもの"が生き残る
生き残っているものは結局の所、（重要な点が）優れているものなんだよ >>11
そう。あのコミック自体が言葉遊びだったんだよ。
あれ読んで、一番普及しているものに優れたところはない と
解釈してしまった読者はアホ 「一番売れているのは、一番美味しいからだ」と言ったどこかのモブに対して
イヤイヤイヤイヤ「一番売れているのは、販売戦略が一番優れていたからだろ」と
ツッコミを入れなければいけない所
別の所が一番なんだよと指摘すると、実はこの話は成り立たなくなる jQueryを熱く語ってるの滑稽なんだけど自覚ある？ フレームワークは腐る、乱立する
大体同じ内容をメソッド名とか引数パターンだけ
覚え直しという無駄な学習コストの三重苦
ネイティブコードこそ至高 jQueryが普及してるとか
jQuery使ってれば良いって主張してるけど
jQueryが糞ってことは否定してないしな >>16
すごい判る
大抵は覚えることが増えるだけで
思ったほどメリット出ない WebのUIの複雑さに対処するように進化してきてるから
ちょっとしたサイトを作るくらいではメリットを感じられないんだろう >>17
今までjQueryがクソという話が出てないんだから
否定がないのは当たり前だろｗ
お前がこのスレではじめて言ったが明確に否定するよ
jQueryはクソではない >>16
覚え直しという無駄な学習コストの三重苦
Reactは将来移行しなければいけないほどの作業がありますんで
覚悟しておいてください。大丈夫！移行の問題を緩和する仕組みも作りました。
2つのバージョンを共存できるんです！同時に2つのバージョンを使えばいいんです！
React 17では、将来のReactバージョンへの移行の問題を緩和
https://www.infoq.com/jp/news/2020/10/react17-easy-future-migration/
> Reactチームは、React 16の2年後にReact 17（最初のリリース候補版）を最近リリースした。
> React 17は、2つの同時バージョンが共存できるようにすることで、
> Reactの将来のメジャーバージョン間の移行が簡単になるよう努めている。
他にも沢山変更したいことはあるのですが、移行は大変なので
React 17の後に延期しましたよ。えっへん！
> 特に、React 17は「足がかり」のリリースであり、あるバージョンのReactで管理されているツリーを、
> 別のバージョンのReactで管理されているツリー内に安全に埋め込むことができる。
> […]他の変更はReact 17の後に延期しました。 jQueryの凄さにAPIの互換性が高いという点がある。
最新版のjQueryは2020年4月にリリースされた3.5だが
おそらく1.10あたりでもほぼ同じように使える
1.10がリリースしたのは2013年だ それはあるね
JSのフレームワークに限らないけど、ライブラリーがバージョンアップの度に破壊的な変更を繰り返して、ライブラリーの更新に合わせて本体を修正するより本体を新規に作り直した方がマシというのはよくある
それで廃れたのがRailsだと思う 確かにrailsは特に酷い。
railsはrubyと、大量のgemに依存してるだろ？
うっかりrubyのバージョン上げようものならマイナーバージョンアップでも動かなくなるgemが大量に出てくる。
それぞれのgem作者がrubyの破壊的仕様変更に対応しないと今まで使えてたgemが使えない。
これで昔は一世を風靡してた今は使えないgemがかなりある。
だんだんこんなのやってられるか、ってgem作者がrubyワールドから離れてくから。 Rubyっつうかウェブ系オープンソース文化はみんなそうだろうな
だからマイクロソフトの.NETがいいんだよね
C#だとほぼ公式のパッケージだけで一通り揃ってて快適に開発できる
互換性の問題もゼロにはならないがほとんど考えなくていい 「フレームワークの使い方覚えた、成長したぞ」
その機能は非推奨になりました。これからはこっち使ってね。もっと簡単だよ！
「せっかく成長したのに、なかったことにされた。しかも前より簡単って苦労して覚えた努力は一体・・・」
Angularはそうなったね
Reactもそうなるみたいだね
そのうちVueもそうなるんだろうな
使い方を覚えるのが成長とか思ってるからそうなる ヘッダーとかフッターとか
ナビゲーションメニューとか
ハンバーガーメニューみたいなの考えた奴死ねよ
めっちゃ開発しにくいだろ >>29
この発言からして本当にjQueryの時点で成長が止まったままの
おじさんらしいなｗ
フレームワークで使われてるイディオムみたいなものは
ネイティブで自前実装するときにも活きてきたりする
実力の底上げになるんだよ
デザインパターン覚えたりしたときみたいにね
お前はそこが限界だったんだなｗかわいそうにｗ バージョンアップごときの変化についていけないのはエンジニアとして終わってるよｗ 初めて触るフレームワークだったとしても
普通に1つの仕事やる間に基本＋ちょっとした応用くらいのことは身につけられるし
「学習する労力」というほどのことじゃない
jQueryバカは本当に学習能力が低すぎて辛いのかもしれないがｗ BlazorってクライアントサイドEFCoreってできんのかね？
Queryableをシリアライズして飛ばすだけだからできそうなもんだが クライアントEFCoreが実現したらGraphQLが要らなくなりそうだ >>37
へーもうあるんだ
今までRESTだのGraphQLだのgRPCだのと色々と疲弊してたのって何だったんだろうな >>30
ハンバーガーは最悪
開発する方だけじゃなくて
ユーザー側も使いにくいわ >>30
お前が無能なだけだろ
こんなチンケなものすら作れねえのかよ React使って生産性とか管理しやすさとか
幻想だからよ。
そもそも「管理しやすさ」っていう漠然としたものがなんなのか
と言うのが人によって認識が違う訳よ
オブジェクト思考がなんなのかって事延々と考えるのと同じよ
SQL HTML CSS JavaScriptだけでも覚えること大量にあるのに
それを覚えたばかりの人間がそんなこと理解出来るわけがない
GUIなんて千差万別あるのにReact使ったくらいで
簡単に共通化や再利用などできるわけが無い
そんなくだらない幻想のために一度覚えたHTMLやJavaScript
をまた文法変えて覚え直しさせれられる苦痛が分かるか？
そんなもんに学習コストかけるくらいなら
ネイティブのDOMのコーディングスピードとセンスあげて
毎回ゼロベースで作った方がシンプルで余程生産性が高いに決まってる
共有化さまくってるパーツを使うストレス、
共有化パーツに頼りまくってる画面を解析して改修するストレスがどんなものかぐらい想像つくだろ
コードを使い捨てることが出来る安心感
ネイティブであることの信頼感。これぞ至高 >>42
何が言いたいのかまったくわからん
React使ったらhtmlは文法変えてんの？
変えてねーだろアホかこいつ いやいや共通化はしとけよ
ReactだろうがjQだろうがバニラだろうがそこは同じだ >>43
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください >>44
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください シングルページってアイデア、結局要らなかったな
URL変わったらloadし直してくれたほうがシンプルで良い ふつうクライアントサイドルーティングで変えるけどな。エアプ乙。 ページの初期化は
ブラウザ駆動で
location.reload()でいつでも状態消去出来る
それより、保持し続けたかった画面状態が
画面遷移で消滅してしまう方が問題
保持してるものを破棄するのは簡単だが
無いものを引き継がせたり復元したりするのは大変
ならばセッションに保持しようとすると
今度はそれが残り続けて不具合の要因になる
セッションは意識して破棄するのは面倒
そう考えるとSPAで画面遷移減らすのが最適解 ★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください SPAが叩かれるのはSPAを前提としたビューを切り替えたりする
ビューの下らないテクニックが嫌われるだけであって
SPAの考え方自体が悪いわけではないと思う
SPAは基本的にAjaxをバンバン飛ばすから
Ajaxが叩くURLというのは分離されている
画面と関係の無いURLを気軽に定義出来るようになり
「画面」と「画面遷移」だけを減少させることが出来る
URLは減少しない、むしろ更にきめ細かくできる シングルページにこだわる必要はないと思う
2個でも3個でも構わないが
とにかく無駄な画面遷移を減らす事が重要 ブラウザに無駄に大量の履歴が残るのを防止出来るし
終わったsessionに対して変に履歴から横入りも防止出来るしメリット多い 単純にさ、メンテナンスしやすいように小さく分けろってことなんだよね
どうしても密結合しなきゃならないっていうなら話は別だけど
そうでないなら結合度は低く保つのはシステム開発の常識なんだし 小さく分けるなら別のページにしたほうがわかりやすいんだよね
開発者もユーザーも 単にケチつけたいから理由を無理やりひねくりだしてるように見える
パヨ野党と同じ 単純明快にページを分ける、というやり方をやめて、わざわざ処理を追加して無理矢理ページ内で遷移したように見せかけるという、複雑で愚かな選択
これによりTwitterのサムネがおかしくなったり様々な問題を招き入れてしまった ここでグダってないでツイッター社に説教して来いよもう ツイッターは一例でしょ。しょぼい会社じゃなくて
ツイッターレベルであっても対応に苦労しているという話だ SPA基本のルーターすらしらんやつが
わめいてるけど無視した方が無難かな。 >>70
今そんな話してないよ
グローバルに保持してる状態の話をしてる >>67
匿名掲示板だと反論できなくなった人ってすぐ悪口言うよねｗ >>66
だからその無理やりページ遷移したように見せかける
っていう部分だけが愚策なんだって
ページ自体が複数も要らないんだよ
見かけ上のページも複数要らない 表面上SPAの癖に
時々別のURLに飛ばす造りって
単にSEO対策なんだろ
SEO稼ぐにはURL多い方が良い
SPAの使い易さとSEOは無関係 別のURLに飛ばしてOKなものなら、飛ばしたほうがいいじゃん
状態を引き継ぐよりもステートレスの方がいいんだから アプリケーションは内部状態を持つのが当たり前だが、その状態をサーバー側に持つか
クライアント側で持つかの違いだけじゃね？
どっちかというとサーバー側とそのAPIがステートレスになってくれた方が嬉しいと思うが。 ステートフル”すぎる”な
表示してない物の状態まで持つな
ページを切り替えるなら状態をクリアしろ
切り替えたように見せかけて裏で状態を維持するとか最悪だぞ >>80
おめー無知すぎんだろ
SPAフレームワークをページ遷移だけで見てるからそれしか言えねえんだよ ”すぎる”と”すぎない”の境界がわからんなぁ。
気持ち悪く感じるのは主観だろうからどうしようもないが。 >>81
俺はMVC+Vue.jsのような軽い使い方までは否定してない
SPA的な全部JSでやっちゃえって考え方が駄目だ webサイト画面構成のビューの作法というか
テンプレみたいなのを誰かが勝手に定義するから
害悪になるんだって
Webサイトにはヘッダー フッターやサイドバーや
ナビメニュー、バーガーメニューがあるべきとか
パンくず付けるべきだとか
SPAのサイトは見かけ上のURLで画面を切り替えるように
すべきとか、こういうの一体誰がなんの権限があって
決めてんの？
実装がどれだけ面倒になるかも考えずにさ
ビューの構造考えてる奴らに「シンプルにしろよ、馬鹿が」
って言ってやりたいわ 馬鹿たちかい。
サーバーサイドでステート維持するのは
実装大変だし、バカ高いコストになりますよ。
スケールの設計とかした事あんですかね？ ステートサーバー用意するだけだな
簡単にスケールする
SPAにすると最初はフロントにステートがあったんだけど
SEOとか諸々の事情でやっぱSSRにしなきゃってなって
サーバーサイドにめちゃくちゃステートを持つことになる
ステートをスケールしたいだけなのにフロントもスケールもしなきゃならなくなって最悪 SSRにしたらサーバーにめちゃめちゃステート？笑
エアプここに極まるｗｗｗ >>88
なにわろてんねん
>>89
お前がエアプ SvelteはNY Timesのほかに
Square Enix
Apple
Spotify
Google Arts
Alaska Airlines
などが使い出したようだ
超頑張れ もういい加減クソみたいなアプリ開発するのも
メンテするのもウンザリだ jsからいかにして逃げるか、が今後のwebエコシステム成功の鍵になるだろうね
jsの上にフレームワークを乗せる方式にはも限界が来てる
svelteやblazorがその礎になるだろう エアプ乙。
svelteはjs。
reactやvueなんかよりもjsらしいjs。
mskk真面目に仕事しろ。 Svelteの利点はコンパイラ言語というとこ
つまりその気になれば別の言語でも同じことができるということだ
JavaやC#に置き換えるといったことも可能だろうね もうこれでいいんじゃね？
Google Web Toolkit (GWT) は、Javaを使ってウェブ用Ajaxアプリケーションを開発できるオープンソースのJavaソフトウェア開発フレームワークである。Apache License 2.0でライセンスされている
https://ja.wikipedia.org/wiki/Google_Web_Toolkit Google Web Toolkit：現実的な開発に即したAJAX
https://codezine.jp/article/detail/531
JavaをJavaScriptとHTMLに変換する開発フレームワークの利用
AJAXアプリケーションの開発は簡単なものではありません。というのも、
AJAX（Asynchronous JavaScript and XML）の開発言語であるJavaScriptの
全貌を把握している開発者はほとんどいないからです。さらに悪いことに、
JavaScriptの実装はブラウザによって違いがあるため、互換性という厄介な問題もあります
（「補足記事1 以前のWeb UIおよびAJAXのJavaScriptの弱点」を参照）。
GmailとGoogle MapsによってAJAXの名を知らしめたGoogleが、
この問題を解決するために世に送り出したのがGoogle Web Toolkit（GWT）です。 考え方としては同じことだね
昔から求められ研究されていたものが周辺技術の進歩により実用的な段階になりつつある
AIも昔からあるけど実用化したのはごく最近だった
WEBの世界でもまた同じようにイノベーションが起こる
JSは世界に不要です そして次は勝つ
時代の節目ってのはいつもそうだった 「次は勝つ」と言ってるやつは、たいてい期限を付けない
いつまでに勝てるという見通しがないからだ
負けたら「次は」更に負けても「次は」と言い続ける JSすらまともに使いこなせない
不十分な負け犬の遠吠えにしか
聞こえないけど。 使いこなした上でより良い道具を模索するのがプロ
jsにしがみつく人は駄目だ PHPの機能ではなくHTMLの機能で他HTMLのインクルードがないのは不便
これが出来ればかなり可能性広がる JavaScriptなんか使いこなせるようになってもなあ >>115
HTML部品を細かく外部部品にできる
cssとかJavaScriptとか画像付きで
サーバサイドのクソインクルードと違ってdevtoolsから
呼び出し関係を把握出来る バージョンアップですぐに知識が陳腐化するのが問題だよな
Reactが一番メジャーと言っても、他にもたくさんあるし、React自身もバージョンアップで変わるし、Reactの周辺技術も変わるし >>116
ReactやVuejsのコンポネント
あるいは純粋なWeb Componentsではダメという事？ ソースと画面上のdevtool解析に差異があるから不便 それだけならejsとかのテンプレートエンジンでいいのでは jsを嫌ったところでweb開発では結局npmライブラリ使うんだからjs/tsからは逃れられんと思うけどね JSは嫌いじゃない。むしろ肯定する
嫌いなのはサーバサイドのビューの生成支援技術
特にDBやモデル層と密結合してるものは最悪
とりあえず純粋なデータの形でJSON化して文字化け防止
エンコしてJavaScript側に埋め込んどけば
JavaScriptで復元して、いかようにでもビュー構築
できるのに
そういう事を知らない奴がサーバサイドフレワの
ゴミみたいなビュー機能使いやがる パッケージ問題はwasmにビルドして相互運用って形なるので気にしなくていい
JSが消え去るのも時間の問題だ >>124
サーバーサイドならModelが型を持ってるからメタデータを処理してCRUDを生成するなんてことが実用的な水準でできるけどJSONじゃ無理でしょ？ サーバーサイドで完結するなら遅延評価とかでDBへの負担を最小にできるけど、一旦JSONにするとN+1とかリクエスト連発とか高負荷になるもんな
それでGraphQLとか流行り始めてるけど domain modelからview modelへの変換も実装量としては無視できない
これをスクリプトでやるなんて正気じゃないよ GWTってまだ生きてたんか
SWTと同じくらい長生きだな https://dev.to/linkuriousdev/to-wasm-or-not-to-wasm-3803
wasmって今のところjsよりそんなに極端に速いわけではなさそうだけど
普通のwebアプリをwasmにしても大して恩恵は受けられないんじゃ >>130
ゲームとかのグラフィックス用途だけだよ。 鯖の負荷を減らすにはクライアントサイドの
ブラウザに仕事させるのが最善
ネットワークアクセスが頻繁になるけかもしれんが
キープアライブとかあるし大した問題ではない
同時接続数はローバラ噛ませてスケールアウト
擦るのが定石で それだけ利益産むだけの接続数が
来てるんだから必要経費
サーバサイドはレンダリング支援は要らん
バリデーションはフロントサイドとDBの制約で十分
ハッキングしてくる奴に律儀にエラーメッセージ
返してやったりエラーハンドリングしてやる必要ないからな
関連はJOIN覚えろ
ORMとかクエリビルダとかクソなんだよ
最悪複数回SQL飛ばせば外部テーブルのレコード取ってきたり
SQL飛ばさずに連想配列の配列からデータ漁るメソッド
作っとけば工夫すればコーディング爆速になるのに
ちまちまとバリデーションとかリレーションとか
定義するフレームワークは馬鹿
つまりwebアプリは全部糞なんだよ！
ネイティブJavaScriptが至高
ネイティブSQLが至高
expressのみが至高
オブジェクト指向は死ね！
RailsもララベルもReactもAnglarも死ね！ クライアントでやれと言いつつ
結合はサーバーでやれと？ どっちがサーバでどっちがクライアントかも分かってないぞそいつ
お茶碗持つほうが鯖とかそんなレベル jQueryバカがボコボコに論破するたび過激になって帰ってきて草 >>120
debugビルドでsourcemap吐き出させると
devtool上でも手書きのソースが表示されるよ スレタイAngular外されたか
個人的には好きなんだけど使う奴が少ないんだよなあ
Angular+nest+typeormの組み合わせが快適で重宝してる 普通にDOM操作してる分にはJSで十分速いんだよなぁ。
最近WasmでFFmpegをブラウザに移植、とかあったし、TensorflowでWasm利用したりしてる。
そういう従来PCやサーバのOS上で直に動いていた物がそのままWebに移植されて予想もしてなかった新しい組み合わせを生む、みたいな方向性に期待してる。 十分速いもなにも、現状DOM APIはJS用しかない。WASMにもないのでJS経由でないといじれない。
偉そうに宣伝してくる他言語のフレームワークも最終的にJSのAPI呼んでる。 >>143
Domを使う場合JSがネイティブだね。
Wasmの場合canvasに直接描画するのが本流。ゆえにDom上のUI資産は一切使えない。 wasmでUInt8Array作ってcanvasに流し込む形かな。ゲームとかならそれで良さそう。
いやでもゲームなら高速描画を求めてWebGLやcanvasのAPI使うからwasmで完結はしないかも。
ゲーム以外だとUI周り全部wasmで描くとランタイム大きくなるし。 ゲームとかだったらいいんだけどねぇ。
複合UIをCanvasベースで作り直しとかｗ
CSSのレスポンシブ関連機能相当のものやイベントシステムも再実装か？ｗ id変えて3連投
内容もトンチンカンだし
何がしたいんだ canvasで描画されたサイトはスクレイピングできなそうだけどどうなの >>144
>Wasmの場合canvasに直接描画するのが本流。ゆえにDom上のUI資産は一切使えない。
別に「一切使えない」という訳ではない。
Edit要素やチェックボックスなんかをHTMLのFormで書きたい人はWasmからでも
書ける。
例えば、EmscriptenならC++ソース内でEM_ASMの中にJSコードが書けるので
そこでなんでもHTMLコードは書ける。 >>152
基本その通りで、AI技術などを使わない限りはページを解析できなくなる。
だから文書中のキーワードから自動的に検索エンジンに登録される事ができなく
なってしまう。
その意味で検索エンジンに登録して欲しい内要はcanvasで書かずに
HTMLのtextareaやpやdiv要素などの中に書いた方が良い。
そしてWasmを使ってもそのようにすることは可能。 >>152
Wasmに求められてる事のは、
ブラウザー内でネイティブアプリを動作させることでは？ >>155
JS使えないのがWebが主流になったからって
慌ててWasmに逃げようかと考えるから
そんな疑問になる。 >>156
例えば、Win32のEditControl相当のものは、canvasで作ることも出来るが
pre要素で作ろうと思えば作れる。
例えばqiitaのプログラムコードの表示はpreタグで作られているから
それと同じことをWasmでやればよい。 Wasmでsilverlightの土台整ったんで
是非復活してください。 googleのクローラーさんがwasm読めるように頑張ってくれれば良いだけだよね
あとは任せた いくらGoogleのクローラでもCanvasに独自実装されたUI全てに対応するのはちと辛かろう（リソース食う量が段違いだし）。有名フレームワークがあるならそれに対応するのはあるかも。
フレームワークがSEOに弱いとわかりつつwasmに行くのが先か、
wasmフレームワークが流行る可能性があるとGoogleがクローラを進化させるのが先か。
等面俺は普通にDOM使うかな〜 クローラーがcanvasの文字列に対応するには、(OCRみたいな)画像からの文字認識が必要。 ややこしいのは、HTMLだとテキストを全部、HTML要素の中に書いておいて
見えない領域は必要に応じてスクロールするようになっているが、
nativeとのマルチプラットフォームライブラリのWasmの場合だと独自に
スクロールして必要な部分しか画面には出さないので、文字認識しても
クローラーは見えない部分には対応しにくい。 SEOとかLanding Pageだけ対応しとけばあとは割とどうでもいいんじゃないの？ なんでSEOせにゃならん要件でWasm使うのかい？
もしかして某板の基地外？ いや俺はSEO対策には詳しくないが、海外のサイトでWasmでcanvasで文字を
描画した場合に問題になることが議論されていたから、それに影響された。
もし、問題にならないと思うんなら別にそれでいい。 > なんでSEOせにゃならん要件でWasm使うのかい？
これを読んで、SEOに悪影響はないという主張だと理解したわけ？
外国の方ですか？ｗ >>167 は >>165
へのコメントのつもりだった。 これすごくない？
ブラウザ上で動画生成や変換ができるWebAssembly版FFmpeg「ffmpeg.wasm」レビュー
https://gigazine.net/news/20201109-ffmpeg-wasm/ reactでhooksが主流の今、reduxを学習する意味は大きいだろうか？ Vueって本当に簡単なんですか？
言うことを聞いてくれなくて時間の浪費が半端ないです。
これを乗り越えた先にパラダイスはあるのか ないよ
今、JavaScriptやjQueryで苦労してる人 が
使うものであって、苦労していなければ Vue を使っても
使いづらくなるだけ
使う目的が違ってる。Vue に適したことじゃないと
Vue を使うのはデメリットしかない ReactやVueは最初が辛いですが、一度覚えてしまえば一生使える技術ですので。 >>176
一応真面目に答えると天地の差でパラダイスになるけど、、
言う事を聞かないってのが何を指してるのか分からんとなんとも >>181
どんなときにパラダイスになりましたか？
具体例を聞かせてください 何がどう難しいのかさっぱりわからん
フレームワークって単にその仕様を覚えるかマニュアルみて調べるだけじゃん
もしマニュアルみてもわからないならお前の能力がゴミなだけ マニュアルに、こういう場合はこうするって
全てのパターンが網羅されてるなら、そのとおりだろうね（笑）
難しいところがない＝考えることがなにもないってことだから馬鹿でもできるね ややこしいルール増えるだけでほんま役に立つんかと思いながらReact始めたけど、途中から目に見えて楽になったのを感じたし、それ以来リアクティブじゃないのは辛いなと思うようになるぐらいは変わった。
Reactが生き残るかどうかはわからないけど、Webの最新技術に触れようと思うと当然のようにReact要素が出てくるので、ある種の基盤になってるのかなと思う。 ソースコード解析できないならフレームワークは使わないほうがいい >>182
答えたいんだけど範囲が広すぎるよ
まず何を作ろうとしてるのか。何の期待してvue使おうと考えたのか。今困っている事(言う事を聞かない？)を具体的に。
この3つが分かるといいんだけどな。
もしかしてvue単独で既存のwebに組み込んで使おうとしてる？ Reactに近い考え方でもっと薄いライブラリねーかな
分厚いフレームワークあるあるの変な挙動に1日悩まされて結局バグだったみたいなことを避けたい フレームワーク単体じゃなくてVSCodeとかwebStormとかのIDE、hotReload、cliでプロジェクト始めてビルドからdeployまで一貫させるとかgitとかtypescriptとかnpmとか諸々全部含めた上でのフレームワークだし。 Angularだけは本当に誰も話題にしないな。
Angular 11リリースされたのに…
信者もアンチも居ない。
ただ誰も興味がない… 海外だとAngularも人気あると思う
Reactが一番人気なのは間違いないけど
Vueは日本ではなぜか人気あると感じる 後ろ盾の差でもう勝負ついてる
WebAssemblyが成熟するまでは間違いなくReactの一強 シルバーライトは時代を先取りしすぎてたな
そろそろ世間が追いついてくるかもしれん Blazor and ASP.NET Core Get Faster in .NET 5 -- Visual Studio Magazine
https://visualstudiomagazine.com/articles/2020/11/12/blazor-speed.aspx Angular はリリースのペースが早すぎてなぁ
一年に一回で三年ぐらいメンテならまだわかるけど
半年に一回メジャーはなぁ Svelte側の意見なので、そらそういう話になるよね。
でも確かに普通のサイトをSSGするならReactはオーバースペックだなぁ >>204
歴代このスレでそう言うヤツが何回も暴れてたぞ >>204
脱jQueryとか言ってた奴らは多かったよ
なんのために脱jQueryするのか理由がなかった
脱jQueryが目的となってた
そして生産性を落とした >>203
> でも確かに普通のサイトをSSGするならReactはオーバースペックだなぁ
オーバースペックと言うか用途にあっていない
沢山人を運ぶのに、バスじゃなくてトレーラーを使うようなもの
運べる人数の数なら、トレーラのほうが多いから
オーバースペックに見えるかもしれんが、そうじゃない
快適さが重要 ちょっと待て
>202 はReactが不要という話じゃなくてjQueryも含めた何でもできるライブラリは（場合によって）要らんという話でしょ。
Svelteは必要十分な機能で2kBのフットプリントと覚える事が少ないってのが売り。使った事ないから良く知らんけど 何でもできるのは別にいいんじゃないの？
駄目なのは使ってないコードまで転送してしまうこと
Wasmならビルド時に不要なコードを除外できる 「wasmなら」は関係なかったな
「ビルドプロセスを挟めば」だ ビルドプロセスでTree Sharking 使っても大きいライブラリはやっぱりフットプリント大きいよ。
それと覚える事の大きさ、も考えると小さい方が良いってニュアンスみたい。
大は小を兼ねる、一個覚えて全部やるって発想ももちろんありだとは思うけどね。 >>210
いやwasmなら、であってる
スクリプトじゃビルドしても効率的にコード削除できない >>208
ReactユーザーからするとSvelteがコンポーネント化する作りには到底向いてるようには思えない >>212
wasmバイナリ自分で書いたことある？
いくらでも非効率にできるよ。
ビルドツールの問題。 既存の関数をwatのSIMDで書いた事あるけど、あれは面白かったな。慣れてないから速度は倍まで行かなかったし、無駄にメモリ食うようになっちゃったから止めたけど。
>>213
なるほど。そういうもんか わざわざCSSで動的なUIパーツ組む奴が理解できない
「CSSでも動的な動きができる」
は？出来るから何？
変数もifもforも関数も定義できない
console.logで出力してデバッグもできない
欠陥言語じゃん
マジで頼むからCSSで余計なことすんな
aタグとかいうゴミみたいなタグを安易に使うな
擬似クラスとかいうゴミに頼るな
buttonやspanにイベントリスナ仕掛ければ事足りること
イベントリスナも知らないくせにフロントエンド弄るな
JavaScriptで親タグの中身抹消したり
DOM要素を動的に作れる事も
DOM操作で丸々入れ替えられる事も
画面幅や座標の制御をできることも知らない癖に
DOM要素を隠したり詳しくもないくせに
displayやpositionやz-indexを安易に
いじるようなゴミみたいなCSSを書くな >>216
もはや宗教的な理由でJavaScript使えないのかなって思う 宗教的な理由というか、jsっていまいちな言語だとおもうよ
極力触りたくない。
tsが出てやっとこさまともに使える代物になったんじゃないのかな。
みんなそれぞれ習得した言語があると思うけど
jsしか習得してない人とそうでない人でこの辺意見分かれるところなんだろうね。 宗教上の理由でjs使えないヤツってパターンビルド済みのoutputのjsも含まれるから当然tsも含まれるだろ jsは特別優れた言語じゃないけど悪くもない
ブラウザ間の互換性のなさが最悪だっただけ
今でもあの時の印象を引きずって苦手意識を持ってる人が多い >>219
JavaScriptがイマイチなのは同感だけどCSSと比べたらどうよって事じゃないの？
CSSで複雑な事するよりはJavaScriptの方がデバッグ含め扱いやすいよねっていう 何と比べてってのにもよるが。
php,python,rubyあたりと比べてってんなら鼻で笑うわｗ 環境構築がめんどくさい
パッチワークみたい組合わさってて、常に何かがDeprecatedになって破壊的変更のアップデートされてるので、止まったら死ぬみたいな現実がある テレビ東京で、Amazon Killer のShopify を、取り上げていた
Amazonでは、売上の7〜15%取られるけど、
Shopifyなら無料だから、日本でもブレイクする
益子の陶器市では、数千万円掛かるシステム構築運用費用が、
Shopifyで、月2万円ほどで出来たとか
JavaScript のクソみたいなフレームワークで時間を取られている間に、
また、Ruby on Rails から巨大企業が誕生するぞ！ Shopify、確かに流行ってるね
SEOとか集客考えるとスクラッチで作るとかデメリット多すぎる
またjQueryの時代になるかもね だからjQueryが使われていた分野では
jQueryが一番適しているって言ってるだろう ただ、ShopifyがAmazonキラーかというとちょっと違うと思う
Amazonとか楽天よりも、BaseとかStorejpだね強豪は
この辺は根こそぎ持っていかれる気がする >>226
ShopifyはフロントエンドでJS用Shopify API読んで構築するんじゃん。バックエンド構築必要なし。
捨てられた数千万円掛かるシステム構築とやらがRailsだろｗｗｗ アマゾンは欲しいものリストが優秀で積み本の管理できるし
Kindle書籍も大分買ったしな aタグはゴミだよ
JavaScriptのイベントリスナで捕捉できない
隠れ画面イベントがこいつのせいで発生してしまう
spanにイベントリスナ仕掛けてれば
追加の処理を割り込ませることができるが
aタグでbefore afterとか使われるとJavaScriptを割込ませるのが
難しくなる ？？？
いっこも難しくないが…
具体的に何が難しいの？
いくらなんでもザコ過ぎでは？ｗｗ >>232
aタグは単に他の要素とリンクしてると言うだけでしかない
aタグを使わないでどうやって他の要素とリンクしているという状態を
静的に定義するというのだ？ HTMLの基礎を勉強したほうがいい >>234
idか自作属性を両方に振るだけなんだよなぁ > aタグでbefore afterとか使われるとJavaScriptを割込ませるのが難しくなる
なるほど言いたいことはわかった
でも結論が a タグはゴミになるのが全く理解できない SPAでaタグ使う話？
ちょっと話の前提が欲しいな >>235
> idか自作属性を両方に振るだけなんだよなぁ
意味不明。 今言ってるのは静的な情報の話だぞ
文書があって、この文書はどこそこへリンクしている
という静的な情報をどうやって作るんだ？
静的の意味がわかってないのか？ >>239
全く意味がわからん
静的な情報とはなんだ >>240
定義されて変わらないってことだ
状態が変わらなければ、テストする必要がなくなる
constといえばわかるか？
関数型を勉強したほうがいいぞ それは不変では？
英語わからないおじさん？
static
dynamic
variable
constant
それぞれ英語に訳してみよう！(1 x 4 点) JavaScriptにconst以外で静的なものってあるの？ >>244
class構文にstaticってあるけど、
staticって、英語なんて訳す？
constはconstantの略だけど
constantってなんて訳す？
はい、レスして！
コピペ用↓
static→
constant→ >>244
constに近いもの(immutable)なら
Object.freeze()
Object.create() の第2引数による指定
文字列
等がある
でも静的と言えばstaticかな
jsのstaticは実態がprototype付いてないだけのメンバだから言うほどstaticか？ みたいな気持ちになるけど constだって言うほどconstantじゃないからおあいこ その点TSのas constってすげぇよな、最後までreadonlyたっぷりだもん AppleのM1にはJavaScript専用命令が搭載されているらしい Safariが遅いっていうよりも他のブラウザがめっちゃ高速化を励んでる中Safariだけ着いて行けなかったって感じじゃね？ Web見ないやつなんていないから。
用途が約束されてるのでメーカーにとって投資する価値がある。
googleなんかV8にいくらの金と時間かけたと思ってるんだ。
これら投資あってのスクリプト言語最速の地位よ。 最近はそんなに聞かんけど
一時期MozilaもGoogleも新バージョンでJavaScriptの実行速度が2倍にとかよく言ってたもんな ふむ。ならばそのGoogleが作ったものを
利用すれば低コストで最高のものが手に入るな（笑） WebKitの時代はそうだったけどなんで喧嘩別れしたんだっけ？ 人類規模で投資の仕方間違ったよな
スクリプトの高速化なんてやってないで、wasmに早期から取り組むべきだった wasmのブートストラップコードはjsなんだからjsが遅かったらwasmまで遅くなるじゃんバカなの バカには理解するのが難しいかもしれ
投資してればその無駄なブートストラップのJSが消えるだけ wasmが影も形も無かった頃、静的型付けでコンパイル言語でバイナリが実行ファイルで、サーバからクライアント、あらゆるマシンやブラウザ上で動く、しかもITの巨人たちがこぞって投資した。そんな凄い言語があったんです。
そんな言語でもJavaScriptの牙城は崩せませんでした >>261
まだ投資が足りなかった
普及してれば人類のステージはもう何歩か先に進んでたのに惜しいことをしたな
この遅れが後々の宇宙人との戦争に響いてくる 投資とかじゃなくてwasmが重かっただけの話
当時のブラウザじゃろくに動かない
ソフトウェアの世界は重いものより軽量のものが好まれる そもそも、jsの置き換え用途として
wasmが用意された訳ではない。 docker作ったやつが「wasmを知ってたらdocker作らんでも良かった」って言ってwasmのことを褒めてた記事を前見た
言ってる意味はよくわからなかったけど将来性あるんだろうなあって感じた webエンジニア全員でAppleボイコットすべきだろ
縮尺違うデバイス乱発しやがるし
safariとかいうゴミブラウザはまともに動作出来ないしよ Safariは糞なんだけどなんだかんだ全盛期のIEよりはマシ。でもMacやiOS以外でテストできないのはホントやめて欲しい >>267
wasmのサーバーサイド向けのまともな処理系があれば確かにdockerいらないんだけどな
いかんせんwasmは仕様が貧弱すぎて >>267
K8Sでwasm動かすオプション、マイクロソフトが作ってた気がする
外部コマンドとかに依存してないピュアなプログラムなら、wasmに乗せればどこでも動くからDocker要らん サンドボックスから出れませんよ。
デスクトップネイティブの変わりにはなりません。 >>271
その「どこでも」にサーバーサイドは含まれていますか？ >>273
当たり前だろ…今誰がクライアントサイドの話をしてるんだよ…
クライアント側技術のwasmが、docker代わりにサーバで使えるかもね、どうだろうね、とそういう話だろうに。 >>266
え？
もともと、EmscriptenがC/C++をasm.jsに変換していたのが、asm.jsがWasmに
進化したのだと思っていたが。 何の反駁にもなってない。jsの置き換え用途として
asm.jsが用意された訳ではない。 wasmは
C++等の色んな言語の資産を活かせる。
JavaVMほどの起動時の遅さやフットプリントは必要ない。
GCが無い。
純粋なwasmではIOができない（データの永続化ができない）
のでJavaVMとは色々異なってて、サーバサイドではどちらかというとDockerぽいと感じるかな いずれにせよJSは近いうちに終わる
COBOLやJavaみたいなレガシーの扱いになる 近いうちと言っても少なくともまだ5年ぐらいは無さそう。完全に置き換わるまでには10年くらい。全然置き変わらない可能性もある。
ま、無くなったって新しいの覚えるだけだ。言語が変わっても思想的に地続きなフレームワークが出るだろうし、何も無駄にはならないな 何れにしてもポストJSを考えるには時期尚早感が強い。言語ベンダーとかフレームワーク屋ならともかく >>281
> COBOLやJavaみたいなレガシーの扱いになる
それは終わるとは言わないｗ
お前はいちばん重要なことを忘れてるな
JavaScriptが一番少ない記述量・作業量で目的を達成できるのだから
wasmに取って代わることはない 選挙でもそうだが政局なんてそう簡単にはひっくり返らんよ 世の中で本当に終わったといえる言語には特徴がある
1. 1ベンダーによる開発
2. その開発会社が終息を宣言、もしくはそれ相当の自体になった
これにギリギリ当てはまるのは
VB6とDelphiぐらいだろ
JavaScriptは多数の実装があるのでどうあっても終わらない D言語やPerl5/6なんかもあったな
PHPも開発会社が終息を宣言すれば終わる可能性もある
Rubyは幾つか実装があるみたいだが
やっぱり本家が終われば終わる可能性もある
GoもGoogleだけかな
で、JavaScriptはこれらとは程遠い Delphiとエンバカデロってどうにかなったのか？ >>281
JSからネイティブコードが
呼び出せるようになるだろ。 jsは終わらないけど
jsを使ったフレームワークやAltJSの類はどんどん移り変わるから大変だなあとは思う
バージョンアップしたときとかみんな着いていけてるのか？ フレームワーク作る側も変化が激しくて習得が負担になりうる事を意識してか、ルールが独特過ぎたり複雑過ぎるのは最新減ってきたように思う Pythonの高速ライブラリはCで書かれたネイティブモジュールだけどPythonはなくなりましたか。
え？なくなってない？じゃあなんでwasmでjsがなくなるのｗｗｗ
Pythonよりさらに状況悪くて、クライアントサイドではwasmはjs経由でしかロードもできないのにｗｗｗｗ 何言ってんだこいつ
pythonのライブラリがCで書かれてるからと言ってクライアントまでCにする理由はない
なぜならCよりもpythonのほうが簡単だから
これはpythonと「pythonより速いが難しい言語」との比較だ
JSとwasmの関係はpythonとCの関係とは全く状況が異なる
wasmは今のところC#が有力だが将来的には言語を選ばなくなるはず
ということはJSと「JSより簡単で安全で高速な他の言語」との対立という構図になる
結末は目に見えているね > C#が有力
どこが？ｗｗｗ
wasmはGCサポートしてないから.net中間コード逐次実行するランタイムをwasmでロードするという、クソみてーなことしてるGCクソ言語じゃんｗｗｗｗ
RustやCみたいにwasm用にAoTコンパイルできるようになってからほざけカスｗｗｗｗ
やーいインタプリタ言語ｗｗｗｗｗｗ >>296
嘘だろと思って調べてみたらマジで草
オーバーヘッド半端ないな >>296
blazor wasmがガッカリ低速なのもこれが主原因なんだよね。
ランタイムDLのオーバーヘッド、
中間言語からの実行時(JIT)コンパイルのオーバーヘッド…
他のザコアイテムの改善を行ってはいるが、本丸のAoT対応はできてないw >>299
Blazorは純粋なwasmじゃないですよ。
Domの処理はガッツりjsです。だから遅い。 >>296
そんなものは時間が解決するに決まってるだろ
少しは考えてからレスしたほうがいいよ wasmにGCが乗り、さらに予定すらされていないDOMを直接触る機能が付き、それが全てのブラウザに搭載され、仕様が安定し、それにC#が対応し、フレームワークが完成し、そのフレームワークが流行り……いつになったらJSはレガシーになるんですか？ >>300
そんなのはRustもCも一緒です。
DOM APIはJS用しか存在しないんだから。
言い訳にもならない。 >>291
alert("hoge")
alertの先はネイティブコード
昔からJavaScriptはネイティブコードを呼び出している .net vmのcdnを予めダウンロードしとくみたいなことできんの？ >>303
昔からDOM APIはJavaScript専用じゃない
呼び出そうと思えば、どんな言語からでも呼び出せる
VB6（VBScriptじゃなくて）とかDelphiにIEコンポーネントを埋め込んで
VB6やDelphiからDOM APIを呼び出すなんてのは昔からできた
DOM APIの先はネイティブコードなのでJavaScriptから呼び出しても
wasmから呼び出してもパフォーマンスは変わらない
DOM APIの機能が強化されるたびに、JavaScriptのパフォーマンスは上がってきた
JavaScriptからwasmに変換することもできるということを考えると
話は昔かあるインタプリタ vs コンパイラでしかなくなる
事前コンパイルした方が確かに速いが、インタプリタは事前に
コンパイルする必要がなく気軽に開発できるという点で広く使われている
これが覆ることなんて今後も考えられないだろ
Javascriptのメリットはインタプリタからコンパイラへの変更がシームレスであるということ
開発の初期段階はブラウザで直接動くから素早く開発でき
そして速度が重要な部分だけwasmで変換すれば良くなる
パフォーマンスと開発効率のバランスが優れてるいいとこ取りの言語なんだよ DOM APIはJavaScript専用です。
wasmからJS経由せずにDOMを触る方法はありません。
これはCだろうがRustだろうがC#だろうが変わりません。
DOMの実装はC++ですが、上記の状況とはまったく関係のない話です。
C++だろうがwasmからJS経由せずにDOMは触れません。
嘘を千回繰り返しても本当にはなりません。 Mozillaのwasmのリファレンスに、「wasmから直でDOMいじれるようにする計画もあるよ！」みたいなことが書いてあったような記憶がある >>311
Mozillaにはね...Mozillaだから >>309
じゃあDOMの実装をJSにしたら良いのでは？ >>302
数年以内だろうな
C#に限らず各言語で出揃う >>313
じゃあ、とは？
C++で実装されたネイティブDOM API (JS専用。wasmからはC++だろうがJS経由しないと呼び出せない)が整備されてるのになぜその必要が？
誤魔化してるつもりかな？ｗ
C++で実装されたネイティブDOMの、WASMネイティブのインターフェースを作ってもらいなよ。お前らが。GCクソ言語なんちゃってコンパイル言語中間言語逐次wasm翻訳実質インタプリタクソ言語爆遅ハッタリ嘘つきクソ言語のC#ユーザーがｗｗｗｗ >>315
君が足踏みしてる間に世界では誰かがより良い世界を作ろうとしてる
もちろんwasmもすぐに良くなる やっぱりウソ吐いて誤魔化そうとしてたね。
あいも変わらず卑怯な奴らだよ。
そんなだから信用されないんだ。
呆れた。 この二人の論争はなんというか宗教、政党、プロ野球みたいな感じ
どっちも一長一短、適材適所があるでしょうに。
興奮しすぎだわ。 wasmのスレ立てれば？
デバック面倒くさすぎて
使う気にはなれんけど。 単なる事実対妄想だが。
クソ言語C#バカが妄想な。
blazer開発者ですらJSに速度では勝てない勝とうとしてない狙いは別のところにあると言ってるのに速度でも勝てると勝手に妄想、嘘んこをスレ違いに喚き散らして宣伝して回るクソゴミカスどもだからお灸を据えてやったほうがいい。 速度で勝てないのは現時点での話
当然将来的には最適化が容易なwasmが勝つ
当たり前のことなんだけど理解できないのはかわいそうに そりゃwasmは速いよ。でも今のC#そのままブラウザに持ってきただけのblazerが早いわけじゃない >>323
当たり前に予想できることを妄想とは言わない
コーラを飲んだらゲップが出るのと同じように確実なこと >>324
まだ慌てる時間じゃない
ゆったりと高みの見物を決め込んでればいつの間にか逆転してるだろう とにかくとっととAoTコンパイル対応してRustやCと同じ土俵乗ってから偉そうにほざけカスって感じ Googleとマイクロソフトがこんな誰でも分かるようなあからさまボトルネックを延々と放置するわけねえじゃんって幼稚園児でもわかりそうなもんだがねえ
いったい何を根拠にしたら黎明期の遅いままでずっと推移するなどという荒唐無稽な妄想を信じられるのだろう AOTサポートにより（JSに勝つことはないにせよ）性能向上が期待され、また宣伝し、信者も大いに期待していたが…
AOT support in Blazor WASM will be postponed and not show up in .NET 5.
Blazor WASMでのAOTサポートは延期され、.NET 5には含まれません。
https://twitter.com/christianweyer/status/1270602821688328192?s=20
延期されたｗｗｗｗ
一時ソースはGitHubのAoT compilation issueへのDaniel Rothの6/6のコメントとみられる。
他の改善アイテムで頑張るってよｗ
https://twitter.com/5chan_nel (5ch newer account) >>322
現実を教えてあげよう
誰も実行速度で困ってないんだ
そしてみんなが持ってるコンピューターは
年々実行速度が速くなっていってるんだ
買い替えによってね ID:owcTZSsV
こいつ口は悪いけどたしかに嘘や希望的観測は言わないな ソフトウェアの発展というのは
実行速度が技術に置き換えられてきたといっても
過言じゃないだろう
昔の話をするならアセンブラからC言語へ
C言語からC++へ、C++からJavaへ
ネイティブアプリからブラウザアプリへ
実行速度はどんどん遅くなってるんだよ
それが成り立ってるのはハードウェアがそれをカバーしてるからで
そうする理由は開発速度を上げるため
wasmの目的は実行速度ではない
既存のものをブラウザ上に移植するのを容易にするためだ
その必要がないならネイティブアプリにしたほうが実行速度は速いだろう >>290
俺が愛用してるエディタはDelphi製だけどな C#バカの汚いやり口はいつも同じ。
最初は速いと嘘を吐き騙そうとし、
ウソがバレたら今度は速度なんて重要じゃないという。
前にも言ったが、blazer開発者は最初から速度でJSには勝てないと言ってるんだが？
最後に開き直るなら、最初から飾らねばよい。 >>336
最初は勝てないのは妥当な判断だ
最適化なんてほとんどしてない黎明期だからな
逆に言うと改善の余地が有り余ってる blazorさんはスレ違だから
退散した方がいいよ。
そもそもwasmも同じくスレ違だから。
無かったら別スレ立てて移動してね。 勝てないとわかったら追い出し作戦か
ワンパターンだねー エッ！一年前から遅い遅い指摘されてたのに、まだAoT実現できてないの？
このプロジェクト大丈夫？？
https://www.reddit.com/r/csharp/comments/c7qtwy/is_blazorwasm_faster_than_js_today/
> No. Blazor is currently interpreted. That makes it very slow compared to JS.
> It will at some point be AOT, which should yield a massive performance boost,
> but we're not there yet.
いいえ。Blazorは現在インタプリタ動作です。
そのためJSに比べて非常に遅くなります。ある時点でAOTになり、
パフォーマンスが大幅に向上するはずですが、
まだ実現していません。
↑これが一年前。さーてそろそろAoT実現してるかな〜
AOT support in Blazor WASM will be postponed and not show up in .NET 5.
Blazor WASMでのAOTサポートは延期され、.NET 5には含まれません。
＿＿＿＿＿
ゝ／ ＼ /
/ ＿＿＿＿＿＿＿ヽ
| | : : : : : :＼_人ノ: : :| ／
| | : : / ⌒ ヽ: :/ ⌒ ヽ
/＾v─ i | |
（（ |:ｄ: :♯| ((・|・)) ! 「延期！」
ヽ: : /＾ヽ､ ＿ ノっ ＿ ﾉ−､
|: :| ＼_／＾＼／＾＼_:ノ
|: :| ＼
/⌒＼ヽ （⌒ヽ⌒） ））
| ＼＼_／＾＼_／ﾉ ＿＿＿＿＿
| ＼─┬─ ´ | |_
|. ＼. ＼ | ＼ | 延期 （＿）
| ＼ ＼.／￣￣） （＿)
＼ / ￣) | >>338
現在が見えてないC#おじさんの妄想より、現状と開発者の言葉を信じるけどね。普通は C#おじさんのせいでC#が巻き添え食って嫌われるのは心外 C#は良い言語だったと思うよ2000年代中盤から2010年代前半くらいまではね なんだよこの流れ……jQueryが入る余地ねぇじゃん…… >>347
呼んだかい？ｗ
結局の所wasmは使われず、JavaScriptを使う
そしてDOMと相性がいいのはjQueryって話なんだが typescriptの生産性を越えない限り、他の言語に出番なんて来ない jQueryはDOM操作ライブラリだけど
本来ウェブサイトにおいてDOMはガシガシと操作するもんじゃないんだわ
これはjQueryに限った話じゃなくてJavaScript一般の話
jQuery（JavaScript）でやるのは要素の属性の変更
主にclassを変更する。そしてCSSによって見た目を変える
DOMを変更して見た目を変えるんじゃなくて
DOMはそのままでCSSで見た目を変える
これでやりたいことの8割は実現できる
できないのはグリッドテーブルの行数を増やすとかそういうもの程度
そうやって見た目をCSSで変えるだけにすると
JavaScriptの処理は少なくなって、CSSによる宣言的な記述で実装できるようになる。
これはバグが減ってCSSはブラウザによってネイティブで処理されるからもっとも高速になる
あとはこれをJavaScriptでやるからjQueryでやるかだが
jQueryを使うとJavaScriptのコードも宣言的に書けるようになる
正しいウェブサイトプログラミング手法を知ってると
JavaScriptでやる処理が減るから、JavaScriptが遅いことがデメリットにならないんだよ
多少遅くなってもボトルネックにはならないから、そのぶんjQueryを使って楽にやりましょうと
もとより大したことはしないのに、それをwasmに置き換えてなにかメリットあると思う？
ウェブサイトにwasmが入る余地はないんだよ。wasmはデスクトップアプリの移植用 もちろんこの手法にも問題はあってJavaScriptは
シンプルになるが、代わりにHTMLとCSSが複雑になる
この問題はCSSに関してはSASS（SCSS）で解決できる
ウェブプログラマはCSSとその周辺技術に詳しくならないといけないんだが
なぜかCSSわかりません。みたいなことを恥ずかしげもなく言ってしまう
ポインタわかりませんみたいなレベルだからなこれ
HTMLが複雑化する問題は将来的にはWebComponentで解決するだろうし
今現在はテンプレートエンジンを使えば、簡単な記述で生成できる 随分スレチな流れだが、wasmは置いといてそこでjQuery推すのはやめてくれ。さらにスレチが加速して収集つかなくなる。jQueryが優秀なのは知ってるから。 >>348
Next.jsとGatsbyどっちがオススメ？ >>249
Armv8.3のFJCVTZS命令が件のJS専用命令で、JS特有の整数変換を高速化できるとのこと。
https://qiita.com/mod_poppo/items/66663d9a05790579b5e4
M1のみならずArmCPUなら高速化するってわけだ。x86も追従するかもね。 別にサイト作成にjQuery使うことは否定してないからさっさと成仏してくれ マシン語(アセンブリ言語)があらゆる言語を動かし得るのと同様、Wasm(WebAssembly)
もあらゆる言語を動かし得るのだから、Wasm自体に限界は余り無い。
限界があるのは、
・ローカルファイルシステムへ自由な読み書きが出来ないこと。
・グラフィックが遅いこと。特にせっかくOpenGL相当のWebGLがあるのに
同じマシンのnativeのOpenGLの数十倍遅いことが多いのが残念。 >>351
アホ？
jQueryは命令的、Reactとかが宣言的っていうんだよ
命令的だから当然複雑になると手に負えなくなる >>331
その話は一理あるが、ダウンロード時間に関しては果たしてどうか。
意外と通信費は安くならないし。
それと速度が関係ないというならデスクトップもC#で十分なはずなのに
C++も依然としてかなり人気があるし、新しい言語ならC#より速度が速い
とされるRustも一番人気とも言われている。
人気に関しては色々と議論の余地があるが。 >>359
補足するとPCの速度は、シングルスレッド性能は余り上がらないがコア数はどんどん
増えているので、マルチスレッド化できるような処理の場合にはその時点での
速度の遅さは余り問題にならないかも知れない。
ところが通信に関しては安く済まそうと思うと、とたんに事情が違ってくる。 一戸建ての固定回線の場合、光ファイバーにするには月々4,500円くらいが最低価格。
一戸建ての三年以後の価格で、光ファイバーでそれ以上安いプランは存在し無い事が
多いから。それだと年間、5万4,000円かかる。
それより安くしようと思うとADSLになるが、ADSLは基地局から遠いと極端に遅く
なり、光ファイバーの100〜1000分の1位しかでない事が少なくない。
その場合、Blazor Wasmの初回起動はダウンロードに一分以上待たされる。
また、さっきネットで、ダウンロード後の起動にも15秒程度かかる場合があるというテスト
結果をちらっと見た。 >>358
> jQueryは命令的、Reactとかが宣言的っていうんだよ
それはお前がjQueryを命令的に使ってるだけの話
Reactのどこが宣言的だというのか
宣言文相当のものを見せてみろって
jQueryの場合は
$('.link').css({color: 'red'}') こうな
.link { color: 'red' }
これは同じく宣言的であるCSSの書き方と似ている Netflix で測ると、今は都会の光ファイバーなら、速い時で、150MB / 秒ぐらい出る！ スマホで速度制限中かもしれないし、データ量が少ないに越したこた無いんだな 速度制限中の速度は500Kbps、つまり62.5KB/秒
jQueryのサイズはgzip圧縮時で30KB
0.5秒
画像1枚の方が大きかろう >>369
いやマジでお前恥晒しだから無能アホjQueryゴミ命令カオススパゲティ野郎はお呼びじゃないからあっちいけ
スレのレベルが下がる ちょっと聞いていい？
Reactはbabel必須って理解は間違ってない?
Reactの環境構築の最小構成みたいな記事でbabelを入れてなかったからなんか他にやり方あるんかと思いまして 宣言的か宣言的じゃないか、jQuery使うか使わないかなんて、同じチームの人間が言うことでなければどちらでも良い。
それを押し付けてさえ来なければ勝手にどうぞ、となる。 >>371
webpackとts-lorder使ったときはインストールしなかった。裏で依存関係で拾ってきてるかもしれないけど >>364
大阪梅田の5階建ての会社のビル
NTT だと言ってた。
でも混雑時には、かなり遅くなるだろうが Ruby on Rails 6 ではデフォルトで、Webpack。
node_modules フォルダ内に、何千というファイルが入っているw
プロジェクトの設定ファイルは、
package.json, babel.config.js, .browserslistrc, postcss.config.js
yarn.lock は、7,500行あるw
その中を、babel で検索したら、440 個
React プロジェクトを作るには、
rails new に、--webpack=react を付ける >>374
webpackもts-loaderも、「jsxをトランスパイルする」モジュールではないよね？
裏でなんかやってんのか これか？
でも、React プロジェクトを作ったら、依存で勝手に入るかも
https://github.com/jsx/JSX
npm install -g jsx 最新版で学ぶwebpack 5入門
Babel 7でES2020環境の構築
(React, Vue, Three.js, jQueryのサンプル付き)
https://ics.media/entry/16028/#webpack-babel-react
webpack+Babel+Reactの構成を作成しよう
@babel/react を記述するのがポイントです。
これによって、JSX が解釈できるようになります >>371
昔はcdnでも使えたらしいな
今はほぼ100%webpackだろうけど >>376
革新的だと思ってるかも知れんがLaravelの後追いやね TypeScriptはJSXをトランスパイルできる
https://www.typescriptlang.org/docs/handbook/jsx.html
＞TypeScript supports embedding, type checking, and compiling JSX directly to JavaScript.
だからTypeScript+Reactでやる場合はBabelはいらないと思う Ruby on Rails は、ずっと昔から、Webpack プロジェクトを作れた
それが、Rails 6 ではデフォルトになっただけ >>382
なるほどー！そういうことか
納得行きました、ありがとう >>382
なるほど、tsconfigにjsx(tsx)関連の設定あるのはlint用だけじゃなかったわけだ LaravelといえばASP.NET MVCのパクリだよな
BladeとかRazorから由来してる SSRエンジンってその先にもう一個何かないとDB書き込みとかできないんじゃなかったっけ？
違ったか？ Rails、JS界隈はフレームワークの移り変わりが速くて大変そうだね
やっぱり安心して長期運用できるのはマイクロソフト、jQueryですわ >>386
ASP.NET MVCはRubyOnRailsのパクリだとおもう >>389
MS製のフレームワーク、Win32, MFC, WinForms, WPF, UWP,
Silverlight, Xamarin, Blazor, MAUI, WinUI, WinRT, ...
長期安定的に非推奨のものが積み重なっていくね。 IE6が出てからIE7が出るまで5年もアップデートが無かった。今からすると考えられない暗黒時代 .NET
.NET Standard
.NET Framework
.NET Core
Mono
...
もうどれがどれだか分からん。 ASP.NET, Azure, MS Cloud とBlazor Server/Wasm, MAUI, XAMLなどの
関係性が複雑すぎて理解が難しい。
Xamarin.Form, Xamarin.Android と XAML, WinForms の関係性とか、
「便利」とは何か、選択肢が多いことは便利なのか。 MVVMだのMVCだの。MFCのDocument/Viewアーキテクチャと名前は似ているが、
なんか違う。
BlazorもXAMLと似ているが違うようだし、HTMLとも関連しているが全く同じでは
無いような感じで、学んでも果たして将来の役に立つのだろうか。 >>394
ライバルブラウザが存在しないとそういうことになるんだよな
ネットスケープ（Mozilla）はライバルになり得なかった
Chromeの登場がすべてを変えた
オープンソースというか無料のソフトウェアというのは
MicrosoftやGoogleの広告ビジネスのように
他のビジネスで金を稼いでいないと持続できないのだ すでにマイクロソフトが
オープンソースの推進役みたいになっとる。
言語は別に他社製でもよいかんじだ。
そのうちC#からもフェードアウトするかもよ。 プラットフォーム持ってるとこに取ってはオープンソースはメリット多いよね。
コミュニティは活性化して利用者増えやすくなるし、利用者から直接修正パッチ飛んでくるし、新しい使い方を見つけてくれるし、なんならライバルも軍門に下る（EDGE） Chrome では、ページ全体が翻訳されるものでも、
Edge では、翻訳されない部分が残ることがある >>399
MSクラウドが他のクラウドと差別化できるのは、PaaSだけだと思うが、
PaaSと言語は切っても切り離せないのではないか。
ならばMSがクラウドで儲けるためには、言語を他社製で良いという訳に
行かない気がするが。
なぜならそうすると、社運がかかっているクラウドが、その言語会社に牛耳られる恐れがある。
また、オープンソースの言語にした場合は、MSクラウドでなくても良いことになるので、
クラウド事業で失敗する可能性が高まる。
もう1つの可能性は、言語が全て無料化されることだ。
しかしAWSもMS製のVisualStudioを使うことが出来る。
そのVSが無料化した場合、敵であるところのAWSに塩を与えてしまうことになる気がする。 クラウドは何でも受け入れる事が一番重要なんじゃないかな。何が流行るかわからないし。
それと同時に、差別化・囲い込みが必要だってのもわかる。
MS♡Linuxとか言ってんのは前者で、後者は.NET、そしてその中間にTSとVSCode。みたいな。
固執はしないだろうけど、捨てもしないだろう もうosすらLinuxとの双生児になりつつあるからね。 >>402
無料のMS製品を使わせて、そのMS製品と一番相性がいいのがMS製品だから
生産性を考えると全部MS製品に揃えるのが良いという流れに
持っていってるだけ。GoogleもAppleも同じことをやってる
そしてこの数年の間にLinuxも
MS製品の一つとなってることに気づいたかね？ >>407
しかし、その戦略はMS製品でなくても良くなってくる危険もはらんでおり、
LinuxではWineの完成度も上がってきているからLinuxに移行が進んで
Windowsが売れなくなる状態になるのを加速する。
Windowsが売れなくなれば、MS Officeでなくても良いと思われる様になり、
ならば MS クラウドでなくても良いということが連鎖的におきかねない。
殿様商売の経験が長かったせいでそれに気づけてないのかも知れない。 デスクトップLinuxは20年経ってもまったく普及してない Linuxデスクトップを10年以上使ってきたけど、開発者以外に流行る徴候は一度も無かった。スマホの展開には驚いたけど。
MSもPC方面は警戒してはいないし、デスクトップが戦場になる時代でもないと感じる >>408
時系列が逆だねぇ
Linuxの完成度が良くなってきたから、MSはそれに対応するように戦略に変えたの
その結果が、AzureだったりWSLだったりするわけ
知らんの？いつからLinuxが使われてきたのか
MSの戦略の結果、MS製品でなくても良くなったんじゃなくて
MS製品でなくても良くなりつつあったから、戦略を変えたの
たとえWindowsが売れなったとしても、MS全体のビジネスに
影響がないようにビジネスの柱を複数用意したの
大企業なのにこの柔軟性はすごいよ MS Officeでなくても良いというが、
少し前までOpenOfficeやLibreOfficeがライバルだったのは知ってるだろう
だが今は見る影もない。なぜならどちらもクラウドの時代に対応できなかったからだ
今じゃLinuxでもクラウドでMS Officeを使えるようになってる
このようにMSはクラウドに対応してきた 後乗りはオープンソースが推奨してることだから
それをMSがやっても、とがめられることじゃないんだよ
Edgeも後乗り、Chromeの技術をMSが利用する
でもChromeそうやってできてることで非難できない
最後に全部MSが合法的にかっさらっていく
それを見て「後乗りだー！」「後乗りだー！」と騒いでも
後の祭り GitHub
Windows
Office
VisualStudio
VSCode
.NET
Java
TypeScript
npm
python
Azure
Asp.Net
Blazor
マイクロソフトさんまじ無敵じゃないですか
おそらく次に囲い込むのはDockerだろうな マイクロソフト嫌う人って何が嫌いなんだろ
煽りとかじゃなくて純粋に理由が聞きたい
金儲けに走り過ぎてるとことか？ Dockerは単なるスタンドアロンなOSSなので、MSが買ったところでGoogleやAmazon等に対して差別化できるか微妙だからどうだろうね
そうでなくてもDockerは既にMSやAmazonの下請状態なわけで、あえて買収するメリットはないのでは 嫌いっていうかVisual Studioあんま使いたくないな
開発環境はエディタとターミナルだけで完結したい >>420
ウィンドウズで動く画像ソフトを作って販売
↓
マイクロソフトがOSに取り込む
↓
画像ソフト死亡（怒）
オープンソースの作成者「なんでウィンドウズのソースが見れない？オープンソースを勝手に使うな（怒）」 実際にはオープンソースが商用ソフトを殺してるんだけどな
オープンソースの作者がソースコード非公開にしていいと言ってるから
非公開にしてるわけで、それに文句を言ってる作者なんかいない いやAWS思いっきり非難されてあわててOSSにスポンサードし出したが。 オープンソースがプロプライエタリを殺すとか敵対するとか、何年前から来たんですか？ それはソースコード非公開の話と関係ないし
そもそも問題となってるのはクラウドであって
Windows自体はクラウドではないので現に非難されてない >>427
事実だよ。オープンソースに殺されてないのは
マイクロソフトなどの体力があるところだけ
オープンソースがある分野で
競合ソフトがどれだけあるというんだ？
中小企業が参入する余地はない .netの開発はVSで全部完結するとこがいいわ
IlSとかSQLServerとか、デプロイからDB管理まで全部VSだけで済む
OSS系の開発はいろんなツールをパッチワークみたいに使い分けないといけない
で、何かのソフトがバージョンアップして動かなくなるから古いバージョンに戻すと今度は別のソフトが動かなくなるクソ >>420
今は別に嫌いでもないけど、
昔はIEバンドルしてネスケ締め出したり
オフィス抱き合わせして一太郎ロータス潰したり
.netバンドルしてJava潰したり
独禁法で訴えられてなかったらグーグルも潰されてたと言われてる。
やりたい放題やって嫌われないわけがない たらればとかどうでもいい
今は開発者に好印象
それがMSの強いところ MS凄い=MS支持してる俺凄いって発想の奴がいるな >>433
たった今、そういう発想が思い浮かんだのは、「お前」ですよね？ｗ ブラウザもEdgeが覇権とりそうだね
Chromeの機能性にマイクロソフトのカスタマイズが入れば無敵
VSCodeとの連携も可能 メイン火狐だしサブはchromeもどきなら何でも良かった >>430
今のVSは、AndroidSDKやclangとも連携しているから、開発環境の
バージョン管理が複雑になり、不安定になってきている。
オープンソースを誰かが流行らした結果、そのようなものしか作れなくなって
しまい、プログラマは不幸になった。 >>429
オープンソースを使い出すとサイズが巨大化する傾向がある。
AndroidSDKも、clangも最初からサイズがでかい。
対応プラットフォームなどによるが、clangはコンパイラの1つの実行ファイル
が89MB以上で、clang.exe, clang++.exe, clang-cpp.exe, clang-cl.exe
など複数のファイルが同様のサイズなので、これだけでも89*4=約360MBに
なり、lld-link.exeが61MBあったり、全部合わせると物凄いバイト数になる。
Windowsのファイルシステムイがシンボリックリンクに対応していないから、
clang.exe の亜種がサイズが大きくなっている可能性もあるが、それは
Windowsが悪いのではなく、デファクトスタンダードであるWindowsで
使えないUnixの機能を勝手に使って済まそうとしたことや、移植した人の責任。 >>426
「OSSにスポンサード」と言っているが、目立つ人や団体に金を出しただけで
その裏で貧乏生活を強いられ、搾取されているプログラマは泣いている。 VisualStudio容量もりもり食うのに使った事ない人なのかな？ 米国の平均年収では、
Ruby on Rails が、125,000 ドルでトップ！
Node.js が、90,000ドルで最下位
遂に、AWS のソリューション・アーキテクトが、
1,500万円と、Rails をも超えたらしい！
不況の株高で、Amazon の株価は、160兆円。
数年以内に、500兆円ぐらいまで行きそう
YouTube に動画を上げてる、AWS 認定のクラスメソッドは、すごい。
会社全体で、AWSの800資格を取って、
全12資格を取った、マスターが7人もいる！
AWS は、CentOS 系のAmazon Linux と、MySQL 系のAurora の組み合わせで、
数倍速いように作っているとか やっぱMVCのほうが稼げるね
SPAは需要が少なすぎる もう、AWS だけでは食えません。
Ruby on Rails とセットでないと食えません、とか言われていたのに、
AWS のソリューション・アーキテクトの値段が、1,500万円まで暴騰してる！ 今のjsフレームワークはSSRはもちろんSSGもできるんですが ふーんでって感じ
MVCの需要を超えてから出直してこい なーんでこの人たちはRailsやC#やjQueryを押し付けてくるの？ 自分の頭で考えた結果だろ
何も考えずに流されてるほうがダメ 有名な誰それが言ってたから俺もやるんだーっていう何も考えてないやつが多い
そういうやつを見抜くのは簡単、そういうやつは手段が目的になっている
例えば「脱jQuery」 スレタイのフレームワーク・ライブラリの使用経験がある人の中で、jQueryに戻りたいっていう人は存在するんだろうか >>455
ウェブサイトのちょっとしたJavaScriptにも
フレームワークを導入したいって人がいるかって？
いないやろｗ 押し付けてくる理由は無いとなるとただの荒らしかな？ Static Site Generator
最近はISR(Incremental Static Regeneration)が流行りらしいなどういうのか知らんが >>455
Webアプリ作るんだったらjQueryはダルいなぁ。Reactの快適さを知ってしまった いいね。ウェブアプリかどうかって話が認識されてきた
ウェブサイトにはjQueryがぴったりってことだ ネイティブのJavaScriptとReactとtypescript使ってる
奴の人口足してもjquery人口には勝てんやろな
所詮、これが現実よな Ruby on Rails では、
bin/rails webpacker:install:react
で簡単に、React プロジェクトを作れるけど、
ほとんどの人は、よく知らずに、コピペだけして作っているw Angularの皮肉なことはアップデートの遅いAngularJSの方が人気でシェア逆転したこと
草しか生えない >>471
砂糖+アブラ+アゲ
>>472
珍しい(中国の)ス国の粉菓子 マイクロソフトが責任持って面倒見てくれるBlazorに絞ったほうが良さそうだな >>474
いいね！
フレームワークがというよりこの記事がいい。
では私からも…
https://www.wix.engineering/post/is-stencil-a-better-react
こっちはパフォーマンスにフォーカスしてるみたいだ。
>>474 みたいなほうが読んでて面白い。 フレームワークは使う側じゃなくて作る側になるのが楽しい
自分の好きなように変更できる
使うだけじゃ最先端になれない おいおい、マイクロソフトには
knockout.js
があるのを忘れたのですか！ >>480
マイクロソフトは従業員が個人的に開発したものを
奪うようなことはしない >>482
かなりいけてたFWだけどね。
一時期ASP.NETのテンプレートに
組み込まれてた時があったよ。 VueとかReactとかAngularも組み込まれるだろうな
すでに組み込まれてるか？ ASP.NET Coreには今標準でReact,React+Redux,Angularがあったはず >>479
API設計面白いよね。
何処まで隠して何処まで出すかとか、使い勝手と一貫性をいかに両立するかとか。最終的にプログラミングに対する思想が出てきたりとか。 フロントがtsでサーバーが.net系の言語ってつらくね？
それならサーバーもtsでいいんじゃんってなる
しかしおっさんなおれは、なんでサーバーサイドをJavascriptにしなければならないんだ…と考えてしまう
Blazorはまだ成熟してないから却下
嗚呼 今時サーバーサイドなんかJSON返すだけだろ。
何でもいいと思うが。
GoとかRustが速くていいんでない？
gRPCとか凝りだすなら知らん。 サーバサイドは気がつくとschemeばっかり書いてる……。その辺がなんとかなるならGoとか書きます >>492
作るシステムにもよるんだろけど
こちとらRDBから大量のデータとってごちゃごちゃ処理したり
百近くあるテーブルそれぞれのメンテナンスや照会をするわけですよ
フロントはリッチにしたい
サーバーサイドはかっちりやりたい
そして言語はフロントとサーバーで合わせたい… バックエンドはどうしても型安全、速度が求めらられる
もちろん速さのためにメンテナンス性、生産性を犠牲にもできない
C#はそのあたりのバランスが素晴らしいんだよな レス番飛んでるがC#、blazor、.NETあたりはNG放り込んどくと捗るぞ。 スレタイから目を反らしてる荒らしが何か言ってらｗ
ムカつくから.netC#blazeraspスレまとめてうんこコピペ爆撃で埋め立て荒らしして仕返しするはｗｗｗｗｗｗ REST API 向けのフレームワークってお勧めある？ フロントエンドやっててJavascriptが得意な人はサーバー側をJavascript系言語にしたい
バックエンドをやってたひとはフロント側を同じ言語にしたい（あえて具体的な言語は書かない）
そしてこの両者が相容れることはない！
絶対にだ！ サーバー・クライアント共に同じ言語で書ければ楽なのは事実
ゆえにnode.jsとか流行ったけどでもやっぱりねぇ・・・ 言語一つしか遣えないというのは、
エンジニア的にいけてない。
view層と
model以下層とでは
使いやすい言語特性が異なると思う。 >>505
いけてるいけてないの問題ではない
型の共有ができないほうがつらいだろう
HelloWorldだすだけならいいけどさ >>508
この手の技術は初心者さん…
え、この考えっておかしい？
フロントでもサーバーでもTypescriptが使えると嬉しいですよね♪
とかブログやQiitaに書いてる連中はなんなの
みんな初心者なの？ jsフロントしかやったことないと型の共有といってもピンとこないのかもしれない。 GraphQL使ってるから言語は違ってもいいかな
同じロジック使いたくなることはあるけど クライアントの接続先のほとんどはREST APIになっちゃったからね。
今の案件も接続先４ベンターとも全てREST API。
もちろん仕様書はOpen API準拠。
サーバーの開発とかそんな感覚はもう無くなってて、
ネットワーク上の複数のサービスに必要に応じて接続して要件こなす感じ。 >>511
ありがとう。
軽く調べてみたけどすごいリッチだな〜。サクッとAPI作れるしGraphQLにもできるし >>514
リッチなのはもともとオープンソース版のcontentfulみたいなものを目指してたからかな。
しかしプラグインの拡張性がヤバイｗ >>513
サーバーサイドの開発の感覚がない
じゃなくて、きみがサーバーサイドを開発する機会がなかっただけなんじゃないの？
誰かがサーバーサイドの開発はしてるわけでしょ？
サーバーサイドもフロントサイドもバリバリこなしたうえで
型の共有なんて要らないと結論づけて
俺のこと初心者呼ばわりしてるんだと思ったら違うんかいな。 スクリプト言語は規模がでかくなるとテストが遅くてたまったもんじゃない >>517
なるほど。
それが「ちゃんとしたプログラム」でスクリプト言語が使われにくい一つの理由か。 気に入らん意見はたとえ正しくても全部自演に見えるんだな
なんか哀れだな Ruby on Rails には、JSON を返す、API モードがある。
Postman でテストしてみましょうとか
GraphQL の動画もある ろうそくに火を着けるのに戦車でホウゲキスルみたいな話ｗ >>525
ここにいる人たちはローソクに火をつける程度のことしかしてないとでも？ JSONを返すAPIの話でしょ？ｗ
ローソクに火を着ける程度の話じゃんｗ
Pythonで言うならfastapi一発で片が付く程度の要件ｗ >>515
Auth周りも充実してるやん！
マジでリッチだなStrapi RSSってCORSが面倒くさそうだ。
まず鯖側のロジック組んだら？ ネイティブからVueに来たけど、React始める理由が見つからないのだよなぁ。やる気になる理由教えてほしい。 なんか無理やり問題作り出してるね。
そんな人生歩んできたの？
Vueやってりゃいいじゃん。
目移りしてないで添い遂げなよ。 >>534
海外でフロントの基盤になりつつあるから、覚えてると次の技術に手を出しやすい、と思う。
あと、設計が洗練されてるから、勉強してて面白い。
そんなに気合入れなくても1,2週間くらいでわりと使えるようになるよ 逆じゃね？徐々にnative離れしていってるだろ今 Vueってアプリ向けサイト向けのどっち付かずな位置付けだよな VueやってReactもやったら
Reactの方がシンプルで簡単に感じた。
両方Typescriptで。
VueはTypescriptで苦労多かったけど、
Reactは何もトラブらなかったのは感動した。
Vueも今は違うのかな？ 誰が悪いと言った
被害妄想か？
使えばいいだろ好きに ありがとうございます。
エンジニアがメンテする方は時間みつけてReact版も作ってみようかな。Reactがいいって言う人もいるものね。
オペレータがメンテするほうはまだVueかなぁ。JS/TS入れると途端に手を出さなくなるっぽいから。 VueからSvelteってのはわりとアリだと思うけどReactからSvelteはないんじゃないかな？なんとなく どんなに素晴らしいSPAフレームワーク使ってもお前らが作るゴミのようにダサい画面はどうにかならんの？ モダンなデザインライブラリ使えば、よほど滅茶苦茶やらん限りデザインマシにならない？ ならない
なぜなら生まれつき目ん玉腐ってるからどうやっても無理 >>232
なるほど、言葉が足りなさすぎて四方八方とケンカするタイプだな >>545
React以外生き残れないのでは？と思うわ
そのReactも10年先は闇 >>554
Blazorはマイクロソフトが面倒みるだろう
切り捨てるにしても今のマイクロソフトなら移行先はしっかり示してくれはず >>554
ネイティブDOMが流行ってたjQueryの機能の一部を取り込んだように、Reactの一部がネイティブDOMに取り込まれる時も来るのかな Reactの一部というか仮想DOM相当が実装されて
直接DOM操作をしても速いってことにはなりそう
そうなるとReactを使うメリットが無くなるかな
jQueryの方がいいや 仮想DOMはともかく、可及的速やかにTypeScriptをネイティブサポートして欲しい 意味不明。コンパイル時に型チェックして用が済んだ型情報捨てたらJSになるだろ。
ネイティブサポートとやらで何が出来るようになると勘違いしてんの？ ネイティブサポートっていうのはすべてのブラウザで
TypeScriptをそのまま実行できるように
標準化してくれって意味だろ？ えっ…型チェックはいつやるの？
実行時にやったら意味ないじゃんｗｗ tscの遅さからして、ジェネリクスとか型推論する事はコンパイルの遅さに繋がるから、ブラウザに乗ることは無いと思うな…… >>566
静的言語として実装すればマシになりそう 今ビルド時に行っていることを実行時にクライアント側で行わせるんだったら何のメリットもないな。 >>567
よくわからないな。そりゃCみたいにすればコンパイル速くなるけど >>570
それだと型推論なしの別言語が必要になる てかWebpackでまとめてやってるけどtsだけの賞味の処理時間ってどんなもんなのかね？ 処理速度がどうこうというより、TSのコンパイル要らなくなればエコシステムの複雑さが多少緩和されて嬉しいというのが>>559の意図だった ブラウザ毎のTS対応の差異を吸収するために結局トランスパイルが必要になるというオチ ビルド時に静的にチェックできるのが嬉しいのにそれを実行時に持っていったら本末転倒 >>577
これだよなぁ
これわかってない奴がいそうなあたりフロント屋の限界を見た感じ 動的型付け言語しか経験のない人が静型付け言語をtsで初めて触ったんだろうな。
インタプリタで静的型付け言語を動かしたい意味が分からない。 実行速度がすべてじゃない
開発速度が上がる
実行速度が悪いのかと思ったら意外に良い >>578
それはいくらなんでもフロント屋を舐め過ぎ。単に経験不足なだけでしょ。 VSCodeとか使ってるとコンパイルする前に割とチェックしてくれるから
これならコンパイルいらないんじゃね？と感じたんじゃない？ コンパイル済みの静的な言語の方が実行時も速くなるのでは？ >>584
それはコンパイル時間が全体のどれだけを占めるかによる
殆どのサイトではソースコードの量なんてたかだか数MB程度なんや
そんなもん一瞬で終わるだろ？ >>584
コンパイルするとファイルデカくなるからネットサーフィンに向かなくなるけどな 結局はJS(TS)と一部Wasmの組み合わせがWebではベストでベターって事かな。ECMAとかの連中はホントよく考えてんな そういう面倒な事は全部フレームワークが吸収するのが今のweb開発環境だろう
下手に深入りせず感謝だけしてればいいさ SSRが必要な要件のサイトにフレームワーク使うかのが本当に正しいか？っていう命題 最近フロンエンドの若手がnext.jsやnuxt.js使って俺たちサーバーサイドもいけるっしょ？感出しててきつい
サーバーサイドのこと何も理解して無さすぎる
お前らはrustもかけないしサーバーサイドも理解してない
フレームワーク以前にやることがあるだろう シニアなサーバサイド屋がこんなとこに出張して来てグチってるのも大概キツいと思います 俺は最新技術おっかけてるイケてる若手だぜオーラ出してる後輩が簡単なアルゴリズムとデータ構造も知らなかったのには驚いた
結局のところ便利な開発ツールを使うだけのユーザーなんだよなああいう連中って
ツールを作るエンジニア側にはなかなか回れない
ハリボテの実力をアピールするのに必死だから基礎がなってない とりあえずフロントエンドの思想をサーバーサイドに持ち込まないで欲しい
ただでさえこちらは複雑なのにサーバーサイドコンポーネントとか多少のパフォーマンスアップのために余計な世話を任せるのをやめて欲しいね
静的サイトジェネレーターとして利用するのは大歓迎です おじさん良かったね。SSG流行ってるから静的ファイルとJsonだけ吐いてれば良いよ。そのうちグチを履く場所も無くなるよ >>598
危機感はある
日本のIT業界の未来的な意味で >>600
君の狭い社会だけで決めつけるのは早計じゃないか？
日本中の若手エンジニア接したわけでもないのになぜ危機感を覚えられる？ そもそも若手だろ？
若手ごときにムキになるなって。
そりゃ20年も30年も経験が長い分、お前のほうが実力も知識もあるって。比べるまでもねえよ。
もっと自信もちなよ。 >>601
他社の若手とも交流があるし今はネットで見知らぬ他人とも話せる時代だ ベテランがいちゃもん付けて若者の生産性を落とす事のほうがよっぽど日本の将来に害を成すかもよ？ 今の若者って器が小さいけど派手に盛り付けるのが得意だから一見すると若いうちから凄い優秀な人材に見える
でも器が小さいから盛れる量が頭打ちになるのも早い
そうじゃなくて若いうちに地味な研鑽を積んで器を大きくしてほしいんだよね
器が大きければ盛るのに時間はかかってもそのうち器小さい奴を追い越せる
器ってのは基礎訓練で身につくもの
スクールに通って効率よく教わってキラキラした便利なサービスやツールを使えば盛るだけなら誰でも盛れる
でそれじゃ肝心の器がなかなか大きくならない >>605
彼は現実ではいちゃもんつけてないぞ。多分。 >>606
スクール上がりが糞なのはまぁ……その……確かに。
キラキラツール系は嗅覚が良いなって素直に認める。
ITが好きで自己研鑽できるタイプじゃないと、結局は自分から脱落してくでしょ。
>>607
そういう感じはするなw >>599
SSRよりSSGが流行ってる理由分かってないみたいだね SPA
SSR
SSG
ISR
SPA以外正直よく分かってない ISRだけ分からん
ちなみにDSLRとは「Digital Single Lens Reflex camera」の略で『デジタル一眼レフカメラ』の事 Incremental Static Regeneration だってさ。
SSRとSSGの合わせ技か。
SSGのデメリット消すためとはいえSSRの何分の一かのサーバリソースは必要になる、と。 相変わらずこの分野は迷走してんなぁ
もうそろそろMVC回帰のトレンドがくるよ
クラウドからオンプレに回帰
ミクロサービスがモノリスに回帰
トレンドってだいたい一周回って帰ってくるんだ 技術の進歩は螺旋である
あとjavascript系技術ってフロントがjavascriptでしか動かないから仕方なしにjavascriptでやってるんであって
そうでなければ選ぶような技術ではないと思う… 仕方ないと思うかどうかは人それぞれだな。俺は言語としてjs/tsが好きだけど。
個人的にはpythonの方が「仕方なく使ってる感」が強い。 JSはVBAのようなもので、お金を頂いて開発するようなかっちりした製品には向いていないんじゃないですかね。 >>621
vbaとてもわかる…
jsみてるとvbaを思い出す…
チームでやりだすと途端に破綻する
しかしTypeScriptは素晴らしい。
みんな大好きマイ⭐︎クロソフトでした。 かっちりしたとか、チーム開発となればTS(strict)の出現は大きな進化だった。
Pythonの型ヒントと違って、各種ライブラリにしっかり型があってstrictが現実的に使える C#を使える層はVBAを使える層を含んでいるが、名前にCが付いているから
C使いの一員になったと勘違いした挙句、C++を好んで使っている人をC#を
使えない老人呼ばわりするのがウザイ。
C#なんてC使えるやつなら誰でも使えるわ。 意外と使えん奴もいるから人それぞれ
Cなんて初心者の入門用言語だし C#はいい言語だよ。
C#使いもまともな人多いよ。
でもここにやってくるC#おじさんは使えない老害だよ
>>625
VB.NETとVBAをごっちゃにするのはちょっと…… C#使える層も大概おっさん扱いされてますが…
TypeScriptはよくできてると思うが、流石にサーバーで動かすのはやりすぎだった。
お手軽システム限定。 スクリプト言語でサーバーやるの全般がダメって言いたいのかな DBを利用したRESTサーバでJSがボトルネックになる状況とかよほど酷いロジックでは？ DBとAPIがほぼ直のチュートリアルみたいなステムならNodeでもRubyでも何でもいいよ
業務でそんなシステムはなかなか珍しいけど たぶん、ちゃんと測定したわけでもなくふわっとした印象で語っているだけだろう スクリプトっていうか、動的型付け言語をサーバーサイドで使いたくない気持ちは分かる。
でも速度面を理由にするのは、よく分からない。
例えば負荷テストの結果が良くない等、具体的数字に基づいて言ってるのかな？ >>639
ベンチマークで遅いことはわかってるから候補から外れる
作ってからなんか遅かったですじゃ手遅れだからね RubyやJSは起動が速いが、JavaやC#はどうなの?
クラスローダーやDLLのロードのためか、起動が遅い印象がある。 >>642
サーバーの起動なんてリリースやメンテナンスのタイミングしか無いけど気になるか？ >>642
比較的遅いがバックエンドなら気にすることじゃない >>644
もしかして、起動したら基本的に終了せずに、イベントが発生するまで
待機してイベントを裁くような方法を使うの？ 突然空気読まずにMVCとか言い出したと思ったらやっぱりC#おじさんか……。
スレ違いの話はやめようね rubyが早いとか何言ってんだろw
なぜtwitterがscalaで書き直したか知らないの？ >>640
性能要求を満たすかどうかは案件ごとに違うだろうに。
スクリプトだから、ベンチマークが遅いから、って一律で切るのはそもそもそういう検討をしていないんだろうね。 ベンチマークで遅いのと、実用になるかならんのかは全然別だと思うが。
コンビニに行くのにフルチューンのF1では行きたくないだろ。 スクリプト言語でサーバーサイドやる利点を是非知りたい。
パフォーマンス？生産性？流行りだから？ >>650
に書かれてた。やはりお手軽システム限定ってことか。 >>651
ネット黎明期のころ、CGIはPerlで書かれたものが多かった。
Perlは文字列とASCIIコードの相互変換が混乱し易く、かつ、
関数呼び出しの参照渡しに問題が有ったのでRubyに置き換わった。
PerlとRubyは言語が違うだけでどちらもスクリプト言語で似た動作原理
を持っていたので移行しやすかった。
その後、SunがJavaをサーバーサイドを主目的として作った、と聞いた。 >>651
雑に言うと
JavaでサーバーサイドやったらJVMの起動に時間がかかってパフォーマンス悪すぎ
TypeScriptでサーバーサイドやったらイベントループのおかげでパフォーマンス良すぎ。Javaのように書けて移行もしやすい
っていう記事を読んだ >>652
お手軽システムと言うが、お手軽の定義が10年前とは違うぞ。
今の「お手軽ではない」って用途は、現代のCPUですらC++でゴリッゴリにチューンしたロジックをぶんまわさないと走らないと実用にならんシステムであって、ほとんどの物はここに入らん。
少なくとも、JITで瞬時にコンパイルされてる時点で過去のインタプリタ言語とは相当違う。
今の軽自動車であれば日本一周ぐらい余裕みたいな議論になる。 開発言語を選択する理由なんて様々だと思うが、逆に、サーバーに限定して
スクリプトとそれ以外に線を引いてスクリプトは向いてないと主張する理由が知りたい。 日本人がGoでサーバーサイドやるという記事を読んだ
TypeScriptでやるというのは外人の記事
GoとTypeScriptのどっちがいいかの評価記事を読みたい 起動速度が重要になる場面はあるよね。Lambdaとかご存知無さそうだけど >>657
物によるけど、俺はGoの方が好き。
デプロイが圧倒的に楽だから。 >>649
うーんいや
スクリプトにして生産性がぐんと上がるんならパフォーマンスをしっかり検討して許容範囲に収まるなら使ってみようって流れになる可能性はある
でもスクリプトにして生産性がそんなに上がるかっていうと上がらないし下手すると下がるからね
メリットないのにベンチマークで遅いとわかってる言語を選ぶ理由はないでしょう >>650
それはF1カーの運用までが大変だからだろ
比喩表現としてまったく不適切だよ
C#はスクリプトに比べてパフォーマンス以外も楽だからね
楽で速いのだから答えは決まりだ >>660
だから、言語を選ぶ条件なんて様々だろうに。言語自体の機能、開発しやすさ、環境、あるいは開発者を
集めやすいとか過去の資産の継承とか。
それらを踏まえたうえで要求を満たせる言語ならスクリプトとかそうじゃないとかこだわる必要はないと思うが。
>メリットないのにベンチマークで遅いとわかってる言語を選ぶ理由はないでしょう
そこでベンチマークという指標だけを特別視する理由があるのかということと、そもそもそのベンチマークの
成績がどれだけあればいいのかとか、そういう基準をもって選択しているのかと。 C#はJSの2倍程度しか早くないですよ。
Cなら一桁違う事もあるけど >>654
JavaはポストCOBOLのポジションだからもう生産性やパフォーマンスを期待してはいけない
ちなみにC#は非同期処理が得意な言語の筆頭だよ
非同期処理を実用レベルの高生産性まで最初にもっていった言語はC#
JSやその他の言語がイベントドリブンのコールバック連鎖で気持ち悪い非同期処理をシコシコ書いてた時代にC#では真っ先にReactiveExtensionやAsync/Awaitを実装した
C#はライブラリの非同期対応も最も充実している言語の1つだ
JSやその他の言語では未だに非同期ライブラリがコールバックしかサポートしていないといったことも珍しくない >>662
言ってることは間違ってないけどどの要素をとってもC#が最強なのでな 最初から「俺はC#が好きだ」って言ってればそこで終わってた話。
足りない頭でもっともらしい理屈をつけようとするからおかしなな話になる。 >>661
C#とJavaを引き合いに出したいのなら、ハマーぐらいかな。
確かに頑丈だしそれなりに走るけど、それが要るかと聞かれれば疑問符。
俺もC#はよく使うが、楽さは全然違うぞ。
Goとかと比べると、遥かにC#はめんどくさいし、そもそもC#は.net coreでAOTかけてても起動遅い。 >>667
Goも楽で速いがC#とは方向性が違うので共存できる いずれにせよバックエンドでスクリプトを使うメリットは
ない ジャッジが居ないから結論が出ないんだよね。
・>>1が進行役のMCやる。
・MCがジャッジを三名指名する。
・棄権も許容して、ドローになる場合クラウドにゆだねる。
・MCは、クルーが大技を繰り出してきたとき、Yeah! や WoW! HoHo! など適切に合の手を入れる。
・7 to smoke ルールで、7勝した奴が勝ち。 おまえらphpもスクリプトだってこと忘れて議論してるな
メリットなかったら普及しないだろ C#おじさんは狭い知識から屁理屈捏ねて勝利宣言繰り返すだけの人だから。お手本通りの老害 >>671
当時は高級言語の選択肢が少なかっただけだ Windowsで使えた、レンタルサーバで使えた。
需要にこたえていた。
我わ正義なり我に従えってRubyより流行ったのは当たり前だった。 >>669
使いこなせません、と言うことだな。
それはC#が好きなんではなくて、C#しかできないんだろ。
C#に謝れ。 Blazorスレと似たような展開だが、あっちはスクリプト系クソ
こっちはC#,Javaクソ
理由はどちらもパフォーマンスや生産性が〜
これはもう宗教だな >>675
使うメリットがないと言ってる
日本語わかる？ Javaはライブラリの勝利じゃないだろか。
企業で使う場合、認証が一番厄介な部分だと思うけど、Javaはそこがしっかりしてた。
GlassFishを試用してみたけど、軽くは無かったな。 C#は別にクソじゃないよ。一人で狂信者やってるC#おじさんがクソなだけ。
使ってる用語や説明の仕方に癖があるからわかりやすい >>678
メリットを知らない、と言うことだなって言ってるの。
逆に言えばC#のメリットも、本当に両方で作った上でメリットを感じた事があるかどうかすら怪しいもんだ。
知らない物は、無いに等しいわなって単純な話で、おっさんが哀れなだけだよ。
だからC#に謝れって言ってるんだが。
日本語わかる？
俺もC#好きで、それこそFW2.0の時に「良くも切り捨てやがったな…」とか恨んだレベルで年季入ってるけど、他の言語のメリットもちゃんとプロダクト出すレベルで使って判断できるつもりだぞ。 >>682
メリットがないといってんだ
無いもんを知ってるわけ無いだろ
ないんだから >>684
可哀想な人だな。
C#のデメリット言ってみ。
無いと言うならもう言う事は無い。 1万円のBluetoothより300円の有線のほうが音良いからね。 C#おじさんBlazorスレでも鼻つまみ者じゃん…… 安くてもシャープはシャープ（腐っても鯛みたいな感じで）だけど、安いソニーはアイワだからね。 C#のメリットデメリット
script系のメリットデメリット
向き不向きを知った上で正しい技術選択をすべきだな
Blazorは出来たてほやほやなので、フロントをやるとしたらjs系言語一択になるだろう。
サーバーもjs系言語にした方が技術者も集めやすいというのが一番のメリットだとおもう。
ただ、重ためのバッチ処理が入るような企業向けシステムには向かない。
エクセル管理してたものをWebシステム化する程度のものに向いている。
どうだ！ 685がわざわざ明確な評価基準出してくれてるのに無視してて草
>>690
> エクセル管理してたものをWebシステム化する程度のものに向いている。
それって個人の感想ですよね？
クックパッドがNext.js採用したそうですよ そういえばvueの人気が低下してきてせっかく抜いたangularに逆転されそうってマジですか？ >>693
個人の感想だよ
間違ってたら訂正してくれ。
クックパッドのサイトは条件に合うデータとってきて表示するくらいの要件だよね
あと個人が一件一件データを出し入れするだけの要件なら向いてる
裏で大量データの計算したり、帳票生成したりするのに向いてないのではなかろうか。
（個人の感想です） >>695
帳票作成、最近うちはnodeベースのpuppeteerでPDF書き出すものを試験的に作ったけど、めっちゃ良いよ。
言うほど重くない上に、そこそこのクオリティの帳票が描ける。
というかクオリティに対する重さが極小なのと、帳票作成のしんどさが相当軽減されてる。
iTextSharpとか使ってたのが地獄だったかのような感じ。
ただどうやっても背景が透明ではなく、白い板になってるのがなんとかならんかなって思ってる。 >>695
でもクックパッドは凄いアクセス数を捌いてるよ？
> あと個人が一件一件データを出し入れするだけの要件なら向いてる
クックパッドのページ見てから語ろうね
というか貴方はC#のデメリットをちゃんと答えてあげなよ。Blazorが時期尚早なんて濁した回答してないでさ >>696
puppeteerにそういう使い方あるのか。
スクレイピングと自動化にしか使ってなかったわ。
良いこと聞いた JavaやC#はaws lambdaやgcp functionsのwarm startが遅い。ランタイム重いからね。
nodeはちょっぱや。
goは速くてしかもシングルバイナリだからgoというのは分かるがJavaやC#はダメダメだね。 立ち上げっぱなしだとaws lambdaやgcp functionsの意味ないからね >>698
そうそう。特に単票はWeb版と同じAPIでHTML出して、帳票向けのcss当てて出力するだけだから、劇的に楽。
page.pdf()で完結。
悩むとしたら集計系とか、連続帳票のヘッダとフッタぐらいかな。
そのへんは小細工してcss書くのは諦めて、素直に複数ページ描画した。
手書きで心を込めた罫線の描画命令を書く必要もないし、クリレポ職人も要らないし、もちろんライセンスも要らない。 >>701
新しくAPI切ったりしなくて良いのは楽だなぁ。
前社で楽に帳票作るためにC#でxslxのテンプレートにデータ焼き込んでた怠惰な俺向きだわ >>697
いやおれは要件が合えばscript系に移行することもかんがえてるC#erなんだよ
ていうかここのスレの意見聞いてたら弱点なんか全くないじゃないか >>702
xlsxも綺麗に刷ろうと思うとCOMになるから、プロセスが落ちなかったりすると面倒だし、非UIのサーバアプリではやるなってのがMSの公式見解だしで、どうにかしようと行き着いたのがHTML帳票だった。
>>703
自分が知ってるC#の弱点は？
俺は色々思い浮かぶけど。 >>704
そもそもBlazorは未完成なのでSPAが作れないという感想
他は…
VisualStudioが重たい
.NETのサポートが短くなった
技術者を集めにくい
MSがフレームワークを作るだけつくって非推奨とか言い出す
言語というか、環境まわりだな
代わりにスクリプト系言語の弱点教えて >>705
C#の弱点を聞いてて、Blazorの弱点を聞いてるんじゃない。
その全てはだいたいnodeと今時のJSのフレームワークで解決出来るんじゃないかな。
スクリプト系言語の弱点は、デプロイがちょっと面倒な事と、ランタイムが必要な事だと思う。
その辺はコンテナとか周辺技術で解決かな。
まあ、.net coreのSCDで解決しようとして未だに燻ってる所だよ。 >>706
C#の弱点はぱっと思いつかないな…
いろんな言語のいいところをパクって尚且つ非破壊だから
言語としてはひどい目にあったことはない
ADO.NETとかWebFormにはひどいめにあった
パフォーマンスや生産性がC#&ASP.NETと同等、それ以上なら前言を撤回する
以前どこかのスレに金融系のガチガチシステム、計算処理やエンドユーザー向けに大量の帳票吐く要件がある何十人ものメンバーでつくるようなシステムでスクリプト系言語使えるか聞いたらやめた方がいいって言われたことがある fastlyのcompute@edgeやcloudflareのworkersなどのエッジコンピューティングプラットフォームにC#でデプロイしてみなよ >>708
いくらでも思いつくぞ。
GCがイケてない。
古いAPIが残りすぎ。
スレッドプールの使い方が下手。
最近ValueTaskが出てさらに無茶苦茶になった。
新機能がとことんシンタックスシュガーで、awaitするだけで暗黙のメンバ変数が生まれて寿命が長くなる。
いっぱいある。
それ以上だよ。少なくとも生産性に関しては。
既存資産という意味では。
規模が増えてきたら静的型付き言語でやりたくなるのはわかるけど、別に動的型付け言語でも普通にできる。
言われた事があるだけで、やってみて駄目だった訳じゃない時点でお察しだぞ。
まずは一人で、次はチームで、次はプロダクトでやって見ればいいじゃん？ >>710
ここに来てやっと有用な情報が出てきた…
どっちもやったことのある人の意見を聞きたかった。
スクリプト系総じてくそ！で終わらせる奴もいるし。
会社でそういう技術を試すにも理由がいるんでな。
充分選択の余地ありだな
ありがとう。 >>711
なんでこんなに試し試されるような会話をしないといかんか考えてよ。
みんなわかってて、批判してるんよ。
ちゃんと聞こうよ。 またそのうちC#おじさん湧いてくるだろうけど、マジで不毛なんだよね。全く懲りない反省しない AWS Lambda には、Ruby も採用されている
マネージドサービスを使っていれば、環境構築運用など何も考える必要ない。
バッチ、Lambda、SQS・キュー、SNS・通知を、一杯つなげるだけ 新規案件でSPA作りたかったらサーバーサイドもフロントサイドもC#選ぶ理由なんてないってことだ >>708
VitualStudio使わなきゃいけないってのはサーバーサイドやるには結構面倒 C#おじさん全くスレと関係ないことを書き散らかして
自演改行しまくるから本当に迷惑 >>620
tsはまぁ分かるがjsはちょっと
pythonは古い言語だから記述のもどかしさは多いね
import周りは迷走しすぎ es3の頃のバッドノウハウを一旦リセットしてes2017とかやるとだいぶ違うよ。
同じ動的型付け言語でもpythonなんかより言語として洗練されている。 pythonも型書けるからねえ
tsはなんか型パズルしちゃう人が多くてよくわからん
表現力が強すぎるのも考えもの >>710
>GCがイケてない。
JSを含む多くの言語がGCを持っている
それらのGC実装比較して具体的にどうイケてないと感じた？
>古いAPIが残りすぎ。
後方互換性は明らかなメリット
JSを含む他の言語ではそんなに簡単に後方互換性が失われて破壊的変更が頻繁に行われるの？
>スレッドプールの使い方が下手。
.NETのスレッド(を含む非同期処理全般)はうまく出来ていて最小限の労力で各環境毎に高い効果を見込めるようにできている
具体的にどういうところが下手だと感じた？
>最近ValueTaskが出てさらに無茶苦茶になった。
基本的にValueTaskを選んでおけばOKになったのでむしろスッキリした
どういうところが無茶苦茶になったと感じた？
>新機能がとことんシンタックスシュガー
シンタックスシュガーにすることによりランタイムのバージョンアップを回避して高い後方互換性を維持することができた
このメリットに対して変数のスコープが少し伸びた事によって具体的にどのようなデメリットが発生した？ なんだ
具体的に答えられないということは
やっぱり適当にそれっぽく言ってみただけか まともに回答しても屁理屈で答えるか図星を突かれたら無視するような奴に、色々教えて介護してやる気は無いよ >>728
そういうのはまともに回答できるようになってから言いなさい wasm自体はGCサポートしてないからGC言語のGoやC#は辛いぞ。
少なくともGCをランタイムに積まないといけない。
そんなわけでwasmにはRustやC/C++ばっか使われるのだ。
C#なんかGCどころかコードをwasmネイティブにすることもできずにwasmでﾄﾞﾄﾈﾄの中間言語インタプリタ動かしてるだけだからなｗ >>723
世代を超える時の扱いが雑。Goは敢えて世代管理しないという方向で行ってるが、ほぼパーフェクト。
そのせいでstackallocとか作っててワロスって感じ。
古いAPIを残してる分には良いだろう。
Obsoleteもついてないってどう言うことよ。
なんでhttpアクセスすんのにあんなに方法あんのよ。HttpClientは罠実装だし。
うまくできてない。ConfigureAwaitメソッドなんか要らない、と言えるようになってから言え。
ValueTaskを選んでおけばという発想がおかしい。
stackallocと同じ方向性の解決法。
選択肢は解決ではない。ちゃんとコンパイラがやれ。
ランタイムのバージョンアップを回避する必要性がわからん。必要ならしろよ。
それは後方互換性とは言わんでしょ。
個人的にはその寿命が伸びる件で踏み抜いたので割と嫌い。 wasmにGC載せる計画はあるみたいだけど、そのGCはおそらくJSのGCと同一だろう。ChromeではwasmがTurboFan上で動くのと同様に。
これが移植上ネックになることもあるのかな、と上のを見ながら思った あと、C#の話する時はC#って書いてくれ。NGするから 一時期ﾜｯﾁｮｲｽﾚもあったけどなんか毛嫌いするヤツが多かったんだよな >>736
>世代を超える時の扱いが雑
どういうふうに雑だと感じた？
Goは世代管理をしないと言うがJSやその他の言語はどんな実装になってる？
>Obsoleteもついてないってどう言うことよ
高い互換性おかげで問題なく動作するから無理して修正する必要がないからではないかな
次期バージョンで消える可能性すらない安定したAPIになぜお節介にもObsolateを付けた方が良いと考えたの？
>なんでhttpアクセスすんのにあんなに方法あんのよ
複数の方法が共存するのは言語が後方互換性を維持しつつ順調に成長している証拠
君の考えかただと新APIだけ残して古いAPIは削除して後方互換性破壊することになる
唯一のAPIを残して他を削除すべきと考えたのはなんで？
>ConfigureAwaitメソッドなんか要らない
ConfigureAwaitはプログラム文脈から機械的に判断できないコンテキストの切り替えをコントロールするためのメソッドだ
これがないとプログラマはコンテキストの切り替えをコントロールできなくなってしまう
なぜコンテキストの切り替えをコントロールできないほうが良いと思った？
>ValueTaskを選んでおけばという発想がおかしい。
なぜ発想がおかしいと考えた？
>ランタイムのバージョンアップを回避する必要性がわからん
古いプログラムをそのまま動作保証するのに最も確実で安全で低コストな方法がランタイムをそのまま維持することだからだよ
なぜ破壊的変更が紛れ込む可能性があるのに変えなくてもいいところまでわざわざ変えたほうがいいと考えた？ TypeScriptも互換性維持のために同じ運命を辿るのだろうか
同じ作者だし
いまイケてる言語、フレームワークもいつかはレガシーに
ナウなヤングは気付いたらおじさんに そのへんはある程度はしゃーない。
そうなったらいかにナウなヤングの邪魔をしないようにするか、いかに限られたリソースでキャッチアップするか考えるさ。
それまでに沢山経験積んどかなきゃ…… >>746
みたいなバイタリティある人はいいけど
大半の人間は潰しが効かなくなるだろうね
フロントサイドしかやってない人とか特に… Cordovaは、iOS, Andoid, macOS でJSで書いたプログラムをWebViewを
使ってAppStoreやGooglePlayに登録できるアプリとして作製できるが、
iOS 11 以上だと、Wasmも実行できるらしい。Androidでは当然出来る。
そして端末の独自機能にJSやWasmからアクセスできる。
ファイルアクセスなども可能。
仕組みはJSと端末との間で通信するブリッジを用意している。
つまり、Wasmとして出力したプログラムは、Cordovaを使えば
モバイルOSで、ファイルシステムや端末の独自機能をフルアクセス
できるようになるらしい。
HttpServerなどを使ってJSとnative APIとの間が仲立ちされているので
JSからnative APIが全て使用できるだろう。 >>748
nativeアプリの仕組みはこうだ：
1. 時間や乱数を利用してパスワードの様なセキュリティートークンを作る。
2. Posix Socketを使ってLocal Http Serverを作る。ポート番号を5000とする。
3. WKWebViewなどのWebViewを使ってHtml+JSのプログラムを起動する。
4. 2 や 3 を起動するとき 1 のトークンを2と3の両方に渡す。
5. JSが端末の独自機能を使いたい場合、fetchやXmlHttpRequestを使って
http://localhost:5000/機能名?トークン&パラメータ
の様なURLでLocal Http Serverにアクセスする。
6. Local Http Serverは、トークンが正しい場合にのみ動作するようにする。
機能名とパラメータに応じてファイルの読み書きや端末の独自機能のAPIを呼び出す。
7. APIの結果は、Http プロトコルの response で JS 側に返す。
8. JSは結果を受け取る。 wasmってブラウザだけじゃなくK8SでもIoTデバイスでも動くわけだし
モバイルでも動かしたいって欲求も当然出てくるだろうな
そうなるとストアアプリの実装言語も将来的に何でもありになるのかもね >>743
nodeなんかはインクリメンタルではなかったっけ。
Javaはアプリの仕様に合わせて好きに選べる。
awaitで寿命が伸びる件と相性が悪いけど、あまりにも世代1に行き過ぎ。
ライブラリ関数ではゼロアロケーション意識しないといかんレベル(ライブラリ関数でgcが起きるとgen0がライブラリ関数で尽きるので呼び出し元がgen1にあっさり追い出される)
.net coreでやっとある程度柔軟にはなったものの。
無理して修正する必要はない。
逆だろ。処理系のバージョンアップ側にメンテナンスコストかかり続けるじゃん。
それ言い続けて、限界を迎えたら.net core？
アホかな。
後方互換性を維持しつつ順調に成長してるならば、関数が変わるよな。
実のところ、本館、新館、別館と建て増した温泉旅館だよ。
古いAPIは2世代ぐらいで殺すべきだろ。
なんで.NET FWがあんなに亀レベルでしか成長できなかったと思ってんの。
コントロールできない方が良いんではない。
コントロールする必要があるのがアホかなって言ってる。
UIスレッドだけ特別扱いしてるところからわかるだろ。
中途半端。
発想がおかしい理由がわからんならもう黙れよ。
古いプログラムをそのまま動作保証するために必要なのは、互換性ではなく、そのバージョンをLTSにしてちゃんとパッチ出してく事だよ。
で、SideBySideできるようにするか、コンテナにするかどっちかだろ。
バージョンアップするけど(だいたい)互換性はありまぁすとか言ってるから、2020年なのに.NET FW 4以上に上げられん基幹系みたいな負の遺産を残すんじゃないか。
お前が言ってることはC#というか.NETを何度もだめな言語にしてきた老害の発想だからな。
C#が好きならちゃんと考えろよ。 ホントに他の言語やれと。
俺ずっとVue+JavaScript派だったけど、最近何周か遅れてReact+TypeScriptやってて、これはこれで確かにいいなと思ったりしてるぞ。
いろんな設計思想があるのは良いじゃん。最強で至高なんかねえよ。
めっちゃ叩いたけど、そのすぐ裏側はC#の良いところなのもわかってるからな。 >>751
>Javaはアプリの仕様に合わせて好きに選べる。
結局のところアプリのメモリ使用特性に合わせて選択するのが賢いのであって特定の実装が良い悪いという絶対的な指針はないのだろうね
ではなぜ君は.NETのGCが絶対的に悪いような言い方をしたのかな？
>awaitで寿命が伸びる件と相性が悪いけど、あまりにも世代1に行き過ぎ。
awaitシンタックスシュガーで変数の寿命が伸びていたのは昔の話
少なくとも7年前には非同期を跨がない変数はキャプチャされなくなった
なお非同期をまたぐ変数の寿命が伸びるのは非同期処理の宿命でありawaitシンタックスシュガーは関係ない
なぜ君はawaitシンタックスシュガーが変数の寿命を伸ばすことを問題視したの？
>ライブラリ関数ではゼロアロケーション意識しないといかんレベル
C#のメモリ管理サポートは.NET Coreで急激に進歩している
他の多くの高級言語ではゼロアロケーションを意識しても難しいがC#ではそれほどでもない
これはパフォーマンス意識する上で非常に大きい
アロケーションを減らせるならGCの負荷も小さくなる
JSなど他の言語では機械的な最適化以外にメモリ確保そのものを大幅に減らす工夫はあるのかな？ >処理系のバージョンアップ側にメンテナンスコストかかり続けるじゃん
いやいや処理系のメンテナスコストは低いよ
だって仕様が変わってないんだから
シンタックスシュガーのバージョンアップで変化するのはコンパイラのほうね
>それ言い続けて、限界を迎えたら.net core？
Coreへの移行はメンテナンスが累積して限界を迎えたから行ったわけではないよ
主な理由はマルチプラットフォームへの対応を迫られたから
>実のところ、本館、新館、別館と建て増した温泉旅館だよ。
>古いAPIは2世代ぐらいで殺すべきだろ。
その本館も新館も別館も安定稼働してお金を稼ぎ続けている
なのになぜむりやりお金をかけてまで閉じる必要があるのかな？
>なんで.NET FWがあんなに亀レベルでしか成長できなかったと思ってんの。
.NET FWというかC#の成長は速かったよ
いくつもの先進的な機能たとえばLinqだとかReactiveExtensionだとかAsync/Awaitだとかを生み出して
他の言語はC#を追いかけるように機能を模倣してきた
>コントロールする必要があるのがアホかなって言ってる。
コントロールする必要がなければデフォルトでいいよね
コントロールしたいときにできないのは大きな問題だとは思わないかい？
>UIスレッドだけ特別扱いしてるところからわかるだろ。
これは言語の問題ではなくOSアーキテクチャの成約ね
他の言語だってUIスレッドは特別なもの
もしコンテキスト切り替えをコントロールできない言語だと特別なスレッドのために他の関係ないスレッドがパフォーマンス上の不利益を被る >発想がおかしい理由がわからんならもう黙れよ。
わからないから説明をしてほしいのだけど？
根拠も理由もなく発想がおかしいというだけではまったく意見になってないよ
>古いプログラムをそのまま動作保証するために必要なのは、互換性ではなく、そのバージョンをLTSにしてちゃんとパッチ出してく事だよ。
.NET FWはそのあたり手厚いね
未だにWinアップデートで3.5のセキュリティパッチとか落ちてくるでしょ？
>で、SideBySideできるようにするか、コンテナにするかどっちかだろ。
.NETはSBSもサポートしているね
コンテナ化することをそのまま動作保証とは普通は言わない
>バージョンアップするけど(だいたい)互換性はありまぁすとか言ってるから、2020年なのに.NET FW 4以上に上げられん基幹系みたいな負の遺産を残すんじゃないか。
負の遺産ではなく未だに安定して利益を生み出す正の遺産だよ
負の遺産っていうのは言語のAPIが急にサポート切れになって大幅な改修を入れなければならなくなり開発コストで大損したみたいな場合ね
>お前が言ってることはC#というか.NETを何度もだめな言語にしてきた老害の発想だからな。
C#が駄目な言語になったことなんてないよ
VBという悲しい過去があるので.NET全体を称賛するわけにもいかないが
C#は常に成功してきたしこれからも成功する言語だと確信している >>754
絶対的に悪い部分はあるだろ。
「挙動の変更不可」。
「GCの挙動が気に食わん」の解決法が「別のGCを選べる」というのは、GCの設計として正しい。
「気に食わんけど耐えるしかない or ワークアラウンドで対応」
これはなんの解決でもない。
非同期を跨ぐときに伸びるから問題なんだよ。
ずいぶん質問が多いが、なぜ、問題視しなくて良い、と言い切れるの？
難しくないから、人間がやれば良い？
アホか？
じゃあGoみたく、ベンチツールにデフォでアロケーションカウンタついてるのか？
そうでもないだろ。
他の言語を引き合いに出す前に「できるだから気合で解決」をまず減らせよ。 >>755
高いよ。
お前あんまりミッションクリティカル系でC#使ってないだろ。
違うよ。マルチプラットフォームへの対応だけであればPCL、.NET Standard、あのあたり何だったことになる？
特にPCL。あれで現に破綻しただろ。
安定稼働してお金を稼ぎ続けてるなら、3棟それぞれメンテしろ。
お金をかけてまで維持するのとお金をかけてまで閉じるのは同じ話だ。
>>755
言語仕様は早かったな。
で、2016年まではawaitでキャプチャしてたとか、歪な形になってたわけだ。
その頃のアセンブリはもちろんその頃のまま。パフォーマンスもお察し。
さらに今のコンパイラでコンパイルしたものとILは異なるよな。
そのあたりで踏み抜くものが多すぎるんだよ。
コントロールしたいときに出来ないとかそんな事を言う時点で「スレッドプールとは」って話なんだよ。
UIスレッドだけ特別視するのが悪いと言ってるんじゃない。
「UIスレッドはちゃんと勝手にConfigureAwaitできてるじゃん。お前らなんで他のコードでも同じように勝手に処理されるように、メソッドの属性とかそういうもので解決しなかったの？」という話なんだよ。
手動設定信仰過ぎるだろ。 >>757
>「挙動の変更不可」。
.NETもパラメータである程度の調整はできるようだが…
アルゴリズムを手軽に差し替えるような解決策が用意されている言語はどれほどあるのだろうか？
非同期を跨ぐときに伸びるから問題なんだよ。
ずいぶん質問が多いが、なぜ、問題視しなくて良い、と言い切れるの？
難しくないから、人間がやれば良い？
アホか？
じゃあGoみたく、ベンチツールにデフォでアロケーションカウンタついてるのか？
そうでもないだろ。
他の言語を引き合いに出す前に「できるだから気合で解決」をまず減らせよ。 >>756
ほう、4.0と同時に入れられる4.xがあるなら手厚いと言えるだろうな。
コンテナ化する事を動作保証と言うぞ。
というか、完璧に構成管理してやっと動作保証できるものであって、コンテナ化に関しては理想型だろ。
安定して利益を生み出す、で履き違えるな。
負の遺産と言うのは、現状利益を生み出しているかとは全く関係のない尺度だ。
言語のAPIが急にサポート切れ、な。
いつ誰がやらかしたかな？ >>759
焦って途中でレスすんなよみっともない。
ほかのすべての言語はできるがC#だけは出来ない、と言ってるんではない。
C#が得意な事とそうではない事があることは認識しろ、と言ってる。
他の言語を選択するメリットは無い、と言い切ったのが破綻してることはもう充分理解できただろ。
C#なら、C#でも、ってのは、そりゃ原理上可能だろ。可能じゃなかったらチューリング完全でない。
ただ、向いてるかって聞くと、それぞれもっと向いているものを知ってる人間は居るってことなんだよ。
ちょっと冷静に考えろ。
C#は好きだが、議論の道具として叩いてて、反対側にはメリットもあるのはわかってんよ。 >>757
>「気に食わんけど耐えるしかない or ワークアラウンドで対応」
>これはなんの解決でもない。
GCの差し替えができないならそうするしかない
C#は他の言語と違って安全なメモリ管理サポートが充実しているので「耐えるしかない」ということはない
>非同期を跨ぐときに伸びるから問題なんだよ。
ずいぶん質問が多いが、なぜ、問題視しなくて良い、と言い切れるの
非同期を跨いで利用される変数のスコープが伸びることは必然だから問題じゃない
もし問題だというならそれはシンタックスシュガーのせいではなく非同期アルゴリズムの設計に問題がある
言語のせいではなく設計ミス
>他の言語を引き合いに出す前に「できるだから気合で解決」をまず減らせよ。
そうじゃない「他の言語でできないor難しいことが簡単に出来る」と言ってる
たとえばC#のref構造体やspanのように安全に低頻度のアロケーションをサポートするスクリプトが幾つあるだろう >高いよ。
>お前あんまりミッションクリティカル系でC#使ってないだろ。
処理系のメンテコストの話がミッションクリティカルでのC#利用経験の話になるのはなぜ？
>違うよ。マルチプラットフォームへの対応だけであればPCL、.NET Standard、あのあたり何だったことになる？
>特にPCL。あれで現に破綻しただろ。
PCLは確かにあまりうまく行っていなかった
うまく行っていなかったからこそだ
本格的なマルチプラットフォーム対応のためのCoreでありStandard
>安定稼働してお金を稼ぎ続けてるなら、3棟それぞれメンテしろ。
>お金をかけてまで維持するのとお金をかけてまで閉じるのは同じ話だ。
もちろんメンテナンスは続けてるだろ
古いコード新しいコード両方が安定して稼働するからこそ安価にメンテナスが可能となる
APIが急になくなったらちょっとしたメンテナンスでも大騒ぎだ
>そのあたりで踏み抜くものが多すぎるんだよ。
多すぎるというからには何かしら数字が出てるのだと思うけど示せる？
>コントロールしたいときに出来ないとかそんな事を言う時点で「スレッドプールとは」って話なんだよ。
すまん
正直意味不明なので説明を求む
>なんで他のコードでも同じように勝手に処理されるように、メソッドの属性とかそういうもので解決しなかったの？」という話なんだよ。
その属性をつけるのは結局手動だろう？
自動化信仰も結構だが世の中全てを自動化できるわけではない
手動で解決してる理由は機械的、自動的に決定できないからだよ
機械的、自動的に決定できないものに対して取れる最もマシな方法は昔から決まってて
事故が起こりにくい方をデフォルトにする
どちらも安全なら統計を撮って利用頻度で決める >>760
>コンテナ化する事を動作保証と言うぞ。
いや言わない
基本的に今まで動作していた環境で同じように動作することを動作保証という
新しくコンテナに載せ替えるかどうかは動作保証とはまったく別のベクトルの話であって関係がない
>安定して利益を生み出す、で履き違えるな。
>負の遺産と言うのは、現状利益を生み出しているかとは全く関係のない尺度だ。
技術的負債のことを言いたいのだろうけど
古いAPIが全て負の遺産であるような認識は典型的な間違いだぞ
たとえ古いAPIを使っていてもテストが整備されていて設計が美しく開発環境の準備が難しくないならそれは借金でもなんでもない
>言語のAPIが急にサポート切れ、な。
>いつ誰がやらかしたかな？
.NETでは幸いなことにまだぶち当たったことがない なげーなー
C#はSPAには特化してない
歴史的な経緯があるからそのせいで扱いにくいこともある
SPA作るなら特化しているReact+ts使った方が幸せになれる
ってこと？ >>761
>焦って途中でレスすんなよみっともない。
うるせえな寒くて手が滑ったんだよ
暖房つけたからもう大丈夫
>C#が得意な事とそうではない事があることは認識しろ、と言ってる
C#より上手く特定の分野を実装できる言語はあると思う
しかしC#は各分野で最高とまでいかなくとも何でも得意で
C#が特別に苦手なことというのはない
そういう成績オール5 or 4的なところが気に入ってる
>他の言語を選択するメリットは無い、と言い切ったのが破綻してることはもう充分理解できただろ。
C#を使えるなら他を使う「積極的」なメリットは無い
他の言語が特別に得意な分野がどうしても必要なときに仕方なくその言語を使う程度の塩梅でおｋ >>765
>C#はSPAには特化してない
SPAについてはまだまだ黎明期
>歴史的な経緯があるからそのせいで扱いにくいこともある
新規に開発する分には扱いやすい
レガシーがモダンと比較して扱いにくいことがあるがそれはレガシーなので仕方がないこと
レガシーが安定して動作するよう後方互換性とセキュリティパッチが充実しているので
レガシーのメンテナンスを最小化することができる
>SPA作るなら特化しているReact+ts使った方が幸せになれる
人による
現時点ではReact+TSのほうが支持者が多い >>766
全部言い訳だわ。
GC(メモリ管理サポート)に文句つけて、GCがあるから問題ないとか寝言言ってるのか？
IDisposableなクラスでawaitで暗黙のメンバ変数になったらいつまで寿命伸びると思う？
ケース知らなすぎるだろ。
他の事も色々間違ってるがもうそもそもおかしい。
C#は別になんでも得意じゃねえぞ。
オール3だよ。
C#でこれは4だなって思うのはLinqぐらいだ。それももう追いつかれた。
他の言語を知らんから、本当の5を知らんのだろ。
積極的なメリットは無い。知らないからそりゃそうだろうな。
それでC#が好きだとほざくな。 >>769
人とニーズによるだろうけど、Goの並行処理とか、
Erlangのメッセージパッシングとか、
F#の測定単位とか、
Lispのマクロとかかな。
JavaScriptも、あれはあれでとても良いと思う。 >>768
>GC(メモリ管理サポート)に文句つけて、GCがあるから問題ないとか寝言言ってるのか？
大抵のことはGCで問題ない
クリティカルなところでのC#なら安全に比較的細やかにメモリ管理ができるので問題ない
>IDisposableなクラスでawaitで暗黙のメンバ変数になったらいつまで寿命伸びると思う？
当たり前だがDisposeするまでだろ
非同期挟もうが挟むまいが不要になった時点で速やかに破棄される
awaitを使ったからと言って必要もないのに無駄に変数の寿命が伸びることはないよ
伸びるのは非同期処理を実装するのに本当に必要な変数だけだ
>本当の5を知らんのだろ。
例えば？ >>769
5=GOなんだろ
ダジャレだよダジャレ
エスプリの効いたギャグをかましてくれたんだよ >>770
これ特化してるところじゃん
あらゆる分野において平均以上かどうかなんじゃないの
ジェネラリストかスペシャリストか >>770
果たしてそれがメインの開発言語を乗り換えるほどの価値があるかどうかだよね
自分はとてもではないがそうは思えない
もし本当にどうしても避けられずそれが必要になったら局所的にその言語で実装してメイン言語から呼び出すって形にするだろうな
まあGoぐらいなら別にメインにしてもいいかなぁ…とは思うがね(実際にはしないだろうけど) C#は素敵な言語だけどさすがにオール5は言い過ぎたねって話だね >>773
5ってのは、そういう事だと思うぞ。
4で、それが書きやすい、程度。
>>774
ニーズ次第じゃないかな。 オール5の言語なんてLispしかないよ！DSLで何にでも特化できるから！神はLispで世界を作ったんだぜ！（ぐるぐる目）
冗談はさておき、昔のJSはLispの匂いがして好きだった。今は（TSは）Lispの匂いほぼなくなって、万人ウケしやすい言語になったと思う。 >>778
ほんとにそれよね。JSはC構文のLispっぽくて好きだったけど、TSでどんどん静的な言語になってしまってる。 高階関数で関数型プログラミングの匂いはするがLispの匂いはしない
Lispって全部がリストになってるから >>780
applyと分割代入あたりが、おおむね対応するんではなかろうか。 全部がListだったらそれはもう匂いがするどころではなくLispそのものだと思う。
Lisp脳だったのでTS始めた時は型演算そのものを(Lispみたいに)JSで書かせてくれと思ったよw Lispの匂いといえばMozillaのlet式が没ったのは返す返すも残念だった。今はdo式に期待してる >>778
Lispのどこがいいんだ？
全てにおいて不便なだけな気がするのだが Lispのデータとソースコードは全てListである。
Lispは主にListを操作してプログラムする。
Lispには文は無く、式だけがある。
LispのマクロはListであるLispソースコードの操作をLispで行う。
Lispのマクロはありとあらゆる式をList操作で作り出せるのでDSLが簡単にできる。あらゆるコードを抽象化できる。
スレ違いだからあとは調べてね。
これは個人的な所感だけど、
ありとあらゆる式文が作れる（抽象化できる）ってことはつまり俺ルールがまかり通って分断を招く言語って事だから、そりゃ一般向けじゃないやね >>787
そのせいでクオートとか関数クオートみたいな邪悪な存在が生まれたのは無視かな？ >>787
長々と書いてるがメリットってこれだけだろ？
> Lispのマクロはありとあらゆる式をList操作で作り出せるのでDSLが簡単にできる。
DSLを作りたいやつがどれだけいるか知らんが
DSLというのはただの関数に過ぎない
だからどの言語でも関数を作ることで簡単にDSLを作れるぞ 細かい反論はあるけど概ねご批判の通りだよ。
だから流行らない。俺は好きだけどね https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E7%89%B9%E5%8C%96%E8%A8%80%E8%AA%9E/
> DSLは、大きく内部DSLと外部DSLに分類することができます。
>
> 内部DSL: 内部DSLは、汎用のプログラミング言語の書き方を工夫して、
> 見かけ上の構文を自然言語に近づけた言語です。
書き方を工夫するだけだからどの言語でも出来る
> 外部DSL： 外部DSLは、汎用のプログラミング言語とはまったく別の構文を持ったDSLです。
こっちはlispでも作りづらい 内部DSLの場合、言語によって自然言語に近づけるといっても限界がある場合がある
えばC言語なら、 This("is", "a", "pen"); が限界だろう
これがRubyだと This "is" "a" "pen" となる
is とか a とか を定義すれば、This is a "pen" と書けるかもしれないな
だがシェルスクリプトであれば This 関数を作るだけで
This is a pen と書くことが出来る。
ダブルクォートでくくらなくても文字列として扱われるからだ
内部DSLを作るのに一番適した言語はシェルスクリプトだと思うが
それはそれとして、DSLを簡単に作れる言語の条件はリスト操作をしてるとかではなく
引数を () でくくらなくても良いとか最後にセミコロンがいらないとか
そういう言語ではないだろうか？自然言語は () でくくらないからな 引数の区切りにカンマが不要ってのもDSLに適した言語の条件かな >>789
kotlinぐらいじゃないかな。
無茶めな構文が変わるレベルのDSLが作れるの。
S式として成り立ってればどんな構文すら作れるから、関数を作ることで作れるとか言ってるレベルじゃないぞ。
それが良いことかはおいといて。 どんな構文でも作りたいわけじゃない
「自然言語」に近い構文を「簡単に」作れるというのが条件
自然言語というのはシンプルで、単語を並べるだけなのだ
仮にkotlinでC言語の構文に対応できたとして
それはDSLとしてはふさわしくない構文 >>789
JuliaとRustはそこそこ無茶なこともできるしな
ASTレベルでの操作だし
Lispプログラム=実質的なASTと考えると何も変わらん
そこの優位性ももはやない >>796
だからプログラム言語を作りたいんじゃなくて
DSL（自然言語風）を作りたいんだってばｗ あと「簡単に」ってのも重要
作れるけど大変っていうのは簡単ではない Lispは自然言語風ではないだろ
あの括弧なんとかしろよ DSLって別に自然言語に寄ってなくても良いんじゃないか？
ドメイン記述に便利な表記であればそれで良いかと。
昔ウィジェットツリーをそのまま書いたらマクロで展開されるとかそういうの書いたことあるけど、自然言語寄りではなかったな。
最近で言うとkotlinのankoみたいなやつ。 > DSLって別に自然言語に寄ってなくても良いんじゃないか？
それは正しいが「自然言語と異なる別のプログラム言語」を
覚え直さなければいけないのはナンセンスだろ （なぜか「当分お断りしております。」が出たので分割して書き込み）
独自のDSLを作る場合、新たな言語を覚えなおさなくていいように
誰もが知ってる自然言語に近い構文にするのが普通 ぎゃくにこーどがわかりづらくなる
DSLの特徴である「ドメイン固有の処理を簡単に表現できる」に反してしまう （なんで「ぎゃくにこーどが」を漢字とカタカナにしたら書き込めないんだ？） こうやって言語機能そのものみたいな基本部分の重箱つついて、何かあるとすぐちゃぶ台返しして応用や発展的な話題出ないの最高に5chのプログラム板って感じ >>807
そういうことじゃなくて「色々出来る言語」を過大評価しすぎってこと
簡単に目的を達成できる方が重要なのに
色々出来るんやでだからすごいっていう考えが古臭い >>810
どうやらブラウザ（ユーザーエージェント？）も関係あるっぽい
Chromeでは書き込めず、Firefoxなら書き込めた
その他の情報も見てる可能性があるな
IPアドレスは変えてもクッキー消しても意味はなかった スレ違いなネタでろくに知識もないのに平気で一人で盛り上がってる感じ、またC#おじさんかよ。NGすとこ >>812
９月２日から１０月１０日までレスが３つしか付かなかった過疎スレだったんだよね
テーマに沿って話して過疎るか雑談でスレを伸ばすかのどっちかで雑談でもいいと思う
でないと話すことなくて過疎る
雑談が嫌なら来なければいい なんでjs前提のスレで他言語について話してんだ○イジかよと思ったけど。もともと過疎スレだったのか。
フロントエンドFrameworkはすでに別にスレがあるから、雑談スレでもいいかもね。 みんなどうやったら良いSPAが作れるか議論したいんじゃないの
今更だけどスレタイで技術を限定するのは世界を狭めていると思う
C#おじさんはうざいかもしれないがまがいなりにもSPAを作る技術があるわけで C#おじさんの自演ここまでくると怖い
本当に年内に病院に行くべき >>813
C#おじさんいっつも最後にはそれ言い出すな。荒らしが荒らして伸びるより過疎スレの方がどう考えたって健全じゃん。
スレが伸びることが何の免罪符になると思ってんだか まあアホみたいにC#に反論して悪かった。
そりゃそうでそもそもスレチだわな。
React今更やり直してんだけど、スタイルってどうやってる？
Vueみたいにコンポーネントごとに書いといたらcssが一本ドーンとできるみたいな仕組みが欲しいんだが、見た感じなさそう。
css in jsでインラインスタイルみたいな感じで当てまくるのが王道なの？ react というかNext.jsってpagesの中でscssをimport する時って
各エレメントにclassName={hoge.kage} って手動でクラス名を紐付けないと駄目なの？
比較して申し訳ないけど、vueだとcss側に*{color:red}とか.main{border:1px;}、html側に<div class="main">と書くだけで
コンポーネント単位でdata-v-xxxx ってスコープ切って紐付けてくれるんだが、そういうのは無し？
前の人と多分同じネタかなこれ >>822
同じネタだと思う。
かつ、俺less使ってて、共通色とか基本サイズ数とかの定数値を、importしてるんだけど、これをきれいに解決する方法がわからん。 横からだけど自分もそれ気になるなあ。
コンポーネントごとcssを別出しするとか色々あるみたいだけど、やり方が複数あって迷うなぁ。
Tailwind使ってるからスタイル自体そんなに充てないけども >>823
うーむ、Next.jsのgetServerSidePropsに惹かれて試してみたけど、こっちはVueと比べてCSSの考える事は多い感じかな
適当に書くけど、.main > * {color:red}とかやって、子コンポーネントに突き抜けたりしないだろうか・・・。 >>820
他人に過疎を味あわせたいというのは異常だし
おまえがこのスレに来なくて過疎を味わい他人がこのスレで雑談して楽しむのはwin-win
スレのテーマを話したい人がいるときに雑談で邪魔しないというマナーはある >>822
Reactだと、上記と同じことをするのはstyled-componentsかな。
エディタの補完が追いつくのかは気になるけど
https://qiita.com/taneba/items/4547830b461d11a69a20 >>826
とにかくお前はC#スレに籠ってろ
他の勢いがあるスレに関係ないことを書き込みに来てるのはわかってるんだ 「過疎スレだから」がスレ違い宣伝荒らしの言い訳ならprologスレとforthスレを盛り上げてこい。これは命令だ。 Next.jsってアップデートされたけどVercel使わないとまともに使えん的になってきてそこそこの規模でも有料だし
少し大きくなったら年間数万ドルもかかるとかやばくねえっすか？ ちょっと調べたけどnextって今そんなことになってたんだ。面白ー。
まぁまだゆとり向けフレームワークのnuxtちゃんがいますし... 画像最適化やISR等の一部機能がVercel依存なだけじゃないの？
Vercelも自分とこのプラットフォームを使ってほしいだろうけど、客寄せになるNext.jsの人気は必要だから無茶はできないし ReactのNext.jsのgetServerSideProps() に相当する機能ってVueのNuxt.js には無い？
DBアクセスとか、必ずサーバー側で実行して欲しい処理を書きたい ある
が基本的すぎてドキュメント読んでないのがバレるぞ asyncDataやfetchだとrouter-link、nuxt-linkでページ遷移するとクライアント側で実行されちゃう認識だけど
それ以外にも必ずサーバサイドで実行される(ロジックの中でfs.readFileSyncが使える)方法あるの？ getServerSidePropsの意味するところを俺が誤認してたみたい失礼。
asyncDataをサーバ側に限定する方法はない
ServerMiddlewareを使えばサーバ側で動くAPIを作れるから、それをクライアント側から呼ぶ形が一般的 やっぱりページごとにAPI作るのがNuxtの流儀か
管理サイト的なものを作っていて、9割のページがDBのデータを表示してるから
1ページごとにAPIを個別に作るのはしんどいんだよね
それか、router-link禁止で全部<a>タグでのみページ遷移するルールにするかって感じか >>822
普通にscssで書いてる
一般的なサイトと書き方変わらん >>838
コンポーネントにではなくて、サイト全体に書いてる感じ？
グローバルに効いちゃうって事？ >>839
index.jsでsassをimportしてるからそんな感じ
といってもscssファイルはページ用とか変数用とかに分けてる >>840
なるほど。ありがとう。
となると、ちょっと設計方針変えないといかんな。 >>841
あとビルドするときにscssをcssとして出力（package.jsonに記載）したほうがChromeのDeveloperで開発しやすいんでないかな
俺はそうした
jsにスタイル書くのって俺的には無理だったしscssの変数とかmixinどうすんのって感じだったから使ってない せっかくコンポーネントごとに分けてるのにグローバルな巨大cssを作るのもちょっとなぁ
scssだと入れ子が出来るだろうから素のcssよりゃマシだろうけど >>842
package.jsonに記載って何を記載するんですか？ いいからガタガタ抜かさずemotion使ってみろってｗ emotion は絶対にない。
linaria は許容できるけど SPAで特定のページにnoindex付けたいんですがどうやるのが正解ですか？
今考えてるのは特定のページに入ったらjqueryでheadにnoindexをぶち込む方法です >>843
そうなんだけどさ、styled-componentの無理やり感が無理なのとjsがスタイルの記述ばかりになって見通し悪くなるし
あと使ったことないけどstyled-componentだとChromeのDeveloperToolでどうやって調整するんだろ
開発がWebアプリ系なら全体的にほとんど同じスタイルだからそれほど増えなくないかな
>>844
開発用パッケージにcss-loaderとsass-loaderとstyle-loaderをインストール
だったかな css in js だと goober が軽くてええな styled component と emotion は全く同じ位置付けなんだけど。
styled componentが無理矢理でemotionが無理矢理じゃないのが理解できない。
dev toolpの問題は結構前に解消されてるでしょ。
css in js を使用する人は何を実現したくて使用するのか聞きたい emotionはstyled component形式でも書けるけどメインはcss prop形式だよ。
css prop形式使わないならstyled component使えばいい。
わざわざemotion使うからにはcss prop形式使うでしょ。
styled component形式は移行のためのサポートと思っとけばいい。 https://emotion.sh/docs/styled
インターフェイスは styled componentと変わらないと思うけど ちゃんと読まないでレスしてた
css prop形式だと余計に css in js 使う意味ないでしょ。
それだと classNameをconditionで操作してるのと変わらないでしょ あのねえ、styled componentより後発でたったそれだけのことで人気追い抜くわけないでしょ…
知らないならドキュメント読んで使ってみなさいよ tailwindかtacyonsどっちか迷ってる俺に推しの一言をどうぞ https://i.imgur.com/vOB4XJi.jpg
もはや比較の必要あるか？というレベルで大差付けてるけども
最近の人気で言うとTailwindCSSかChakra UIかという感じやな、chakraはreact専用だけども。 tailwindとchakra uiはスコープだいぶ違うと思うが。
前者はCSSフレームワーク、後者はreact用uiツールキットでしょ >>858
立ち位置は完全には同じでないけど、被ってる部分は結構あってサイト内にも比較ページがあるくらい意識されてるよ。
https://chakra-ui.com/docs/comparison
背景も使い所も全く別物なら公式がわざわざ用意しないからね うんそれoverview読むだけでまったく別物だって分かるね 全く別物ではないな中身見てないだろ
もちろん範囲外のものもカバーしてるけども 例えば
Tailwindなら
<div className="w-full mx-4 my-2"></div>
Chakraなら
<Box w="full" mx={4} my={2}></Box>
で同じ結果になる。
colorもレスポンシブも同様にあるしな。
まぁ全く同じもので厳密に比較しないと死ぬ病気だったらすまんな、忘れてくれ。 あほくさ。
上は単なるcssクラス
下はreactコンポーネントじゃん。
下はJSXで書いてるから似て見えるだけ。
実態はJS関数じゃん。
いったいどこが同じなのかｗ
cssなんて基本要素も甚だしいんだからそれで似てる言ってたらWeb用のありとあらゆるライブラリが似てるｗ 知らんけど使用感のことを言ってるんでしょ？
内部構造が別だからってギャーギャーつっかかってもしゃあないやん... このフレームワーク流行ってるのか
使ってみようかな
趣味プロダクトのデザインマジで面倒だ まあ>>859が正しいわな
どちらを使うかで迷う人が多いから、わざわざ比較ページでピンポイント比較しているわけで
ただChakraは、使うのを止めるってなった時に地獄を見そうだな
react-bootstrapで地獄を見た私はそう思うぜ https://i.imgur.com/2YClP8H.png
そーす
https://2020.stateofcss.com/ja-JP/
これ見るとまだオワコンではないと思う、他が大きく下げたものが多いから順位は上げてる。
TailwindCSSが断トツではあるけどね。 でもお前らのゴミみたいなセンスじゃ何使ってもどうにもならないじゃん？ >>869
ゴミみたいなセンスだから優秀なライブラリを使うんだろうが
OSSタダ乗りおじさん舐めんな AWSのことかな？ｗ
批判にあわてて援助し出したんだっけ？ｗ jqueryUIたいなライブラリー
なにか知りませんか？
Reactで使いますが、
React用じゃなくても良いですので。 BootstrapとかMaterial-UIの事言ってる？ bootstrapよりどちらかというとvelocityとかじゃね JQuery UIの主にインタラクションのような機能です。
Draggable
Droppable
Resizable
Selectable
Sortable
自前のコントロールを作ろうとすると必ずこの壁にぶち当たります。 React に、そういう機能のコンポーネントは無いの？ ないと思う
俺もjQueryUIのコンポーネント使いまくってるやつは移行が不可能
全部作らないといけないし
新規でやるときは使うんだが いや少なくともReact DnDでuseDragとuseDropはあるけど…？
そういうことじゃなく？？ ReactでjQueryUIを使う場合、
なのか問題とかあるのかな？ 仮想DOM のReact と、実DOMを更新するjQuery の更新タイミングを、
React のタイミングに合わせる必要がある
合っていないと、jQueryで更新しても、
その後、Reactでは更新していないと思われて、元の状態に戻ってしまう >>886
それはなんとか大丈夫かな？
それよりもjqueryUIのベストなロードの方法はなんだろうか？ いやだからjQueryUI互換のReactのコンポーネントライブラリが欲しいんだよ
なんやかんやいってjQueryUIの出来はめちゃくちゃいい なんでUIライブラリ二重に使おうとするわけ？
野球帽の上にシルクハット被っても問題ないかな？と言ってるに等しいのでは？
これは問題あるともないとも言える。
可能不可能で言えば問題ないとも言えるが、バカに見えるという点では問題あると言える。 >>889
バカはお前だろ
jQueryUIはコンポーネントライブラリだぞ 俺はangular使ってるがmaterialUIがまんまそれに相当する
React にもあるはず。ちゃんと探そう あちこちで言われてるんだからいい加減理解してほしいもんだけど
ReactとかはjQueryの代替にはならないの
ウェブサイト全体をウェブアプリに作り変える場合に使うもので
インターフェースはほぼ全部作り変えでUIを自分で作るためのものなの
jQueryだけじゃなくてブラウザ標準のDOM APIとも相性が悪い
全てをReactのやり方に置き換えるレベルじゃないと単に開発しづらくなるだけ
jQueryのシェアは去年一年で3%増えました。主に今までなにも使ってないところが
採用するのがjQueryです。まだ増え続けています。
その他のフレームワークは0.1%増えるか増えないかだよ
https://w3techs.com/technologies/history_overview/javascript_library/all/y
殆どのところは開発効率が上がらないか逆に下がってしまって却下されてるんだろう Webサイトは改修しやすくないといけないからな
Reactでガチガチに作っても運用の人たちが困る Webサイト → バニラ or jQuery
Webアプリ → Reactとか
これで結論出てる Ruby on Rails では、Bootstrap を使うから、
その依存関係で、jQuery も自動的に入る
React は、コンポーネントとして使う 意味も分からないバカが大量に沸いて出た。
あるいは、また自演坊の出現か？ JQuery UIをぐぐってみた感じ、完全な代替品はreactには無いんじゃないの？
自分がスクラッチしたUIに後からjsの振る舞いを付けてくれるライブラリ群って事だよね。
react、vueの場合、uiとjsの振る舞いをセットでコンポーネント化してあるものがメジャーだから、それらを採用してcssハックで見た目をカスタマイズするしかないと思う。
(コンポーネントによってはslotとかで後から自由にuiを付けられるものもあるので、ぜひドキュメントを見てもらえれば) あの、いまvueで実装してみたくてテストしていたんですが、
https://i.imgur.com/tRZJ97x.jpg
イメージとしては{{message}}のところにデフォで表示される1というメッセージがコンポーネントで作ったボタンを押したらqqqqしたいんです
で、画像のように書いたところalertは表示されるんですが、内容が変わりません
これはおそらくコンポーネントの中に{{message}}とdataも入れてあげれば変わるようにはなるとおもうのですが、
やりたいことはコンポーネントで作ったカスタムボタンを押したらそのコンポーネント外に書いてある{{message}}に値をセットさせたいのです
これってどのように実装すればいいんでしょうか？ const element = <div id="A" />;
：
element.props.id = "B"; //--- TypeError: Cannot assign to read only property 'props' of object '#<Object>'
上記でエラーになるんですが、一度設定したプロパティを変更する事は可能？
もしかして出来なかったのだろうか... Emitを使えばいける。
vueのドキュメントのemitかstoreパターンの項を一度読んだ方が効率がいいと思う。
もしくはハンズオンの書籍で体系的に学ぶか。
またエディタはvscodeとか使った方が時短になります。 プロパティは親からしか、変更できない。
dataとコンポーネントを紐付けている場合は、プロパティをwatchして変更を検知し、dataに反映する必要あり。 vue3、vue-cliのデフォルト設定だとローカルサーバーでtsファイルに定義したtypeの再コンパイルが走らなくてきっつー。
解決してる人いたら設定教えてくださいっす。 >>906
serveでってことだよね。何もせずとも普通にやってくれるが？ jotaiっていうReact用の状態管理ライブラリめちゃくちゃ良いじゃない
なんでこれ話題になってないの？ いいのはたくさんある。
だが結局は多くの人が使っているものが普及する >>909
前スレでとっくに既出。
449 デフォルトの名無しさん 2020/08/31 02:31:14
Reactのrecoilいいな
useContextの欠点を補完してる
もうReduxなんか必要ねえは
460 デフォルトの名無しさん 2020/09/11 22:12:09
>>449
これも面白そう
Jotai, a New Granular State Management Library for React
https://www.infoq.com/news/2020/09/jotai-react-state-management/
たぶん日本語の「状態」からｗ >>911
おー出てたか
recoilよりはかなり使いやすい
とりあえず趣味プロダクトで使ってみる またみずちが変なこと言ってんなｗ
jQueryを求めてないって考えが間違いなんだってば
2021年1月時点のシェア 77.2%
https://w3techs.com/technologies/history_overview/javascript_library/all/y
2020年の1月から一年で +3.0%
今日の時点でシェア + 0.1%
需要は未だにjQueryが一番あるというのに
それを理解できないおじさん すなわち jQuery はウェブ制作板って事だろ。 jQueryはDOMラッパーとしてしか使ってないわ ここはム板だからjQueryはあまり流行らない。
しかし世界は依然としてjQueryで出来てるのだろう。
そもそも論としてウェブサイトはアプリじゃないので。 いい加減ウェブアプリではjQueryは適さないって言えばいいのに
なぜかjQueryを目の敵にしてるｗ
自分が使わないからって、みんなも使わないと思うんじゃねーよ 正直jQueryの話をされても、EVの話をしてる時に馬車の話を始められるような気分 なんでこのスレタイ見て単なるウェブサイトの話題だと思うのか jQuery使ってる連中って、そもそもSPA用の開発環境構築出来るだけのスキルがないだろ
npmコマンド叩けるかも怪しい SPA用の開発環境構築するのが目的となってるなｗ
必要ならやるだけだろ SPA開発が流行らない理由は明白で、保守出来るやつが少なすぎるのよな
開発環境構築するのが目的のエンジニアがいると思うやつとか、
世間は頭が悪いやつが多すぎるのよ jQueryが使われてるというよりリプレイスできないから
シェアがそのままなんだろう
巨大サービスを作り直すとかGAFA以外無理だろう javaパーシステム屋と業務システム開発してるんだが俺のSPAフロントにビビっててこいつらいつの時代の連中なんだって感じ
誰一人理解してない 一時期jQuery+handlebars+railsで無双してたな
フルスタックのフリーランスだったからマジで稼げた
最近は要素技術が多くなり過ぎて
全部1人でやるのが難しくなってきた QiitaとかDev.toとか見てるとNext.jsが破竹の勢いに見える 少なくとも日本でreactやvueを採用するって10%も無い気がする
それくらい何というか使える人も案外少ないし概念もややこしいのかなと
誰かが構築している上で構築した人の説明があって単にプログラム書くだけなら
案外簡単とは思うけど、一から構築するとなるとある程度知らないと出来ないだろうし
世界ではこの辺の技術の最先端が前に行き過ぎという感じがするなぁ
かといって今更jQueryで書く気はしないけど現実は中々そうは行かないという感じか 一番需要があるからといって、一番最高な技術なわけじゃない
一番需要があるのは、一番バランスがいい技術なんだ
何が一番なんなのか、そこを間違えてはいけない react圧倒的だな
https://trends.google.co.jp/trends/explore?cat=13&;date=today%205-y,today%205-y,today%205-y,today%205-y&geo=,,,&q=%2Fm%2F012l1vxv,%2Fm%2F0j45p7w,%2Fg%2F11c0vmgx5d,Svelte#TIMESERIES >>933
調べなきゃ使い方がわからないとも言えるんだよな Reactそんなに難しいかな？
DOMとJSさえ把握してれば、わりとすぐ使えようになる気がするけど >>930
Wappalyzer入れながら自分の知ってるサービス見てみたら？
知らんつもりで使ってるかもしれんよ。
ユーザ企業だけど、割とベンダーはReactかVue使ってくるし、
俺が作ってるのはVue使ってる。 DOM扱いは明らかにreactのがjqueryより楽だけど、非同期処理に関してはjqueryのが楽だわ。 ついてねーよカス。そのコードをどこに置くかって話だよ。 JQueryとVue.jsのどちらを勉強しようか悩んでいたけど、>>915を見ると、
JQueryの方が良さそうだね。 新規にやるならReactの方がいいだろ
なぜVueに飛びつこうとするのか 実質的にNextが使えないこの先はNuxtにすべきか悩み中 ぶっちゃけReactって覚えること少ないから初心者向けだと思うけどね
その分全部自分で書かなきゃならんし
hooksみたいなとっつきにくいものを身につけなきゃならない
Vueは覚えると楽だけど覚えるまでがすごく大変 jQueryなんて勉強するものじゃないぞ。
あーめんどくせーってなったときjQuery つーかおってちょろっと書くもの。
jQueryすらお勉強しなきゃ使えないってんならプログラム全般致命的に向いてない。 同じことがreactにも言える。
プログラミングを簡単にするものだから楽になってるはずのもの
通常よりも楽になってるはずなのに、それを使うのに苦労してるようじゃ駄目
勉強してようやくreact使えるようじゃプログラム全般に向いてない >>949
実質的にnextが使えないってどういうこと？ Vercel向けに最適化されてるってアレでしょ。OSSだしそんなに影響ないと思うけど。 jQueryとvue.jsは並用出来るのでしょうか？ jqueryのカラム話題はこっち↓でやってくださいね
守らないと荒らしとみなされますよ
Vue vs React vs Angular vs jQuery Part.3
https://mevius.5ch.net/test/read.cgi/tech/1560333177/ vercel向けに最適化されてるのはわかるけど、そんな問題じゃないと思うけどね これから先もエッジケースでvercel贔屓の開発は進むかもしれないけど、それが問題になるケースはなさそうだけどね DOM APIとvue.jsは並用できるのかな？
という話題はここでOK？ >>959
なんで併用したいの？
そもそもreactやvueを使うと生のdomを触る機会は基本的にないはずだよ。 >>960
jQueryに依存しないDOM APIだけで実装されているライブラリを使いたいからです。
例えばLuminousとかです。 なるほど
それでいうと使える。
https://ja.reactjs.org/docs/refs-and-the-dom.html
ただ使う場合はrefを使用してdomにアクセスする様にしてね。上のリンクのいつrefを使うかにも書いてあるけど 俺が貼ったdocにはcreateRefが使われてるけど、今はuseRefがあるから、それを使えばいいと思う。 >>965
それができるならjQueryでも同じ方法でできますね。
jQueryはただのDOM操作ライブラリですから。
こういう聞き方をするのが良さそうです。 >>967
うん。jqueryも使えるよ。
ただ、reactやvueを使っててjqueryを導入したいと思うケースを俺は思いつかない。 最近知ったけど
reactjsexample.com
ってサイトいいね。いい感じの部品が結構色々ある 仮想DOM使いたくないならsvelteとか使えばいいじゃん
フレームワーク上でjqueryを使う理由ってなによ ajaxって今思うとすげー恥ずかしいメソッド名だよな >>970
jQueryを使うのではなくて、
jQueryを使って作った多くの資産、ライブラリを使うんだよ
導入検討のためのサンプルとかPoCとか使い捨てプログラムとか
寿命が短いものばかり作ってんの？ jqueryで書かれたプログラムは一般的に技術的負債になりやすいから、jqueryで書かれたプログラムの方が寿命短いよ。
jqueryで書かれたアプリケーションをみんな頑張ってreactやvueなどのフレームワークで書き換えてるよ。 資産っていうけど、大抵はreactとかで書き直されてるor代替のライブラリがあるよね。 >>975
根拠を全く書いてないし、jQueryの現在のシェアを見れば
それが間違いだってわかる
もう少し説得力が有る回答をしてくれ >>976
その代替のライブラリに置き換えるだけで
既存のコードが動くんか？ そう思うならそうしてれば良いよ。我々は違う方法を取る。 jqueryのシェアの高さを支えてるのはbootstrapだと思うけど、bootstrapも依存ライブラリとしてjqueryを削除しようとしてるよ。
https://www.infoq.com/news/2020/08/bootsrap-5-drops-jquery/
君こそreactがjqueryに優っているという根拠を示してくれる？ >>977
jqueryプラグインなんてもはや更新すらされていないゴミばかり
バージョン管理もできない
そもそもjqueryオブジェクトとかいう神オブジェクトにすべて突っ込んでるから激重 > 君こそreactがjqueryに優っているという根拠を示してくれる？
ウェブサイトにはjQueryが適してるとしか言ってないんだがな
まあいいや。jQueryは短いコードで目的を達成できる。
例えばリンクをクリックしたら文字を赤くするのはこれだけ
$(document).click(function() { $(this).css({color: red})});
reactで同じことをするコードを書いて欲しい
俺が書いたんだから、次はお前が書くのを要求しても良いはずだよな >>977
使い始めるハードルが低い方が技術負債になりやすいと思うがな。VBAみたいに。 > 使い始めるハードルが低い方が
JavaScriptの話でもしてんの？ >>974
jquery1,2系は公式に廃止されているわけだが、それに依存した過去の資産を使い続けるメリットを教えてくれよ
脆弱性にも対応してしないし設計も古くて副作用があるけど、それを上回るメリットがあるんだろ？ 前提としてタイプ量の短さで判断しようとしてるのが愚か
一生フレームワークを比較する時にクリックした要素を赤くして遊んどけばいい >>982
お前は一生jQuery書いてりゃいいよ エディタがコード補完するのが当たり前のこのご時勢にコード量を言語優劣の根拠にされても困るよな 正直Vueとかで書いた後でもjQueryの方がいいとか言っている奴は完全に向いてないｗ だからreactでもvueでも同等のコードを書いてから
これがどういう点で優れてるかを説明すりゃいいのにｗ >>950
Reactの場合バージョンアップして何かが変わったとしてもJavaScriptがベースにある限りそんなに困る事はないと思うがVueはそうはいかないからな >>992
もうね、お話にならないんだよゴミ
一生jquery使ってろゴミ ReactやVueの欠点はnode_modulesが巨大すぎることだけ
それ以外のすべてでjqueryより上 jQueryって状態をグローバル変数で管理するしかなくて
相当辛い
その例みたいにCSSをちょこっと変えるとかならjQueryじゃなくてもほぼ同じコードでいけるし
IEが死んだ今その用途ですら使う意味はない >>997
> jQueryって状態をグローバル変数で管理するしかなくて
jQueryのせいにするなよ
お前の実力不足じゃんか DOM（ドキュメント"オブジェクト"モデル）なんだからDOM要素を
オブジェクトとして考えればいい。状態はオブジェクト、つまりDOM要素自身が持つ
DOM要素の属性として持たせてもいいし、data属性を使ってもいいし、
jQueryのdataメソッドを使ってDOM要素に結びつけても良い
グローバル変数で管理するしかないのは、単にお前の技術力不足ってだけ このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 82日 12時間 16分 58秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
