どうぞ
jQueryでいいんじゃね？
このスレと何が違うの？
Vue vs React vs Angular Part.4
http://2chb.net/r/tech/1591796945/
Vue vs React vs Angular Part.4
http://2chb.net/r/tech/1591796945/
2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
http://2chb.net/r/prog/1485008061/
あれから三年後、jQueryのシェアは75.5%にまで成長
http://2chb.net/r/prog/1485008061/
あれから三年後、jQueryのシェアは75.5%にまで成長
>>3
そっちはVue vs React vs Angular限定
ここはフロントエンドで使われるJavaScript全般
つまりサーバーサイドで使われるもの以外
ブラウザで動くものは全て対象
そっちはVue vs React vs Angular限定
ここはフロントエンドで使われるJavaScript全般
つまりサーバーサイドで使われるもの以外
ブラウザで動くものは全て対象
つまりスレタイが気に入らなかったってことだな。
JSよりWasmが主体だったらどうなるの。
AureliaとSvelteとEmberのスレか
Backboneとかあったよなぁ
どうしてどれも長続きしないんだろうね
どうしてどれも長続きしないんだろうね
>>9
開発者がメンテナンスにあきてしまう
他のフレームワークが人気になるとそうなる
大手IT企業が関与してないVueとかはそうなるかもね
開発者がメンテナンスにあきてしまう
他のフレームワークが人気になるとそうなる
大手IT企業が関与してないVueとかはそうなるかもね
UI/UXのフレームワークの話も含めたいね
Bootstrap5のαリリース来たぞー
https://v5.getbootstrap.com/
https://v5.getbootstrap.com/
さよならjQuery
bootstrap5がjqueryはゴミでしたって結論づけました
フロントエンド開発ツールとブラウザサポートの進歩により、jQueryを依存関係として削除できるようになりましたが、他の方法では気付かないでしょう。
これは、フレームワークに対する数年で最大の変更点の1つであり、Bootstrap 5で構築されたプロジェクトは、ファイルサイズとページの負荷が大幅に軽減されることを意味します。
フロントエンド開発ツールとブラウザサポートの進歩により、jQueryを依存関係として削除できるようになりましたが、他の方法では気付かないでしょう。
これは、フレームワークに対する数年で最大の変更点の1つであり、Bootstrap 5で構築されたプロジェクトは、ファイルサイズとページの負荷が大幅に軽減されることを意味します。
Still want to use jQuery? It’s possible!
jQueryを使いたいですか？可能です。
https://v5.getbootstrap.com/docs/5.0/getting-started/javascript/#still-want-to-use-jquery-its-possible
Bootstrap5はちゃんとjQueryにも対応しとるで
> jQuery’s plugin system; this means you’ll be able to do $('[data-toggle="tooltip"]').tooltip() to enable tooltips.
jQueryが入っていれば便利メソッドが使える
jQueryを使いたいですか？可能です。
https://v5.getbootstrap.com/docs/5.0/getting-started/javascript/#still-want-to-use-jquery-its-possible
Bootstrap5はちゃんとjQueryにも対応しとるで
> jQuery’s plugin system; this means you’ll be able to do $('[data-toggle="tooltip"]').tooltip() to enable tooltips.
jQueryが入っていれば便利メソッドが使える
Ruby on Rails 6, Bootstrap 4 では、
yarn add bootstrap jquery popper.js
Jquery に依存しなくなっても、Popper.js への依存は、どうなる？
yarn add bootstrap jquery popper.js
Jquery に依存しなくなっても、Popper.js への依存は、どうなる？
まぁそもそもjQueryが流行りだした頃ってHTML4.01時代で素のJavaScriptがメチャクチャ貧弱だったけど
HTML5世代になってから相当APIとか充実したからネイティブのJavaScriptに置き換えたとしてもそこまでコードが肥大するってわけでもないしな
HTML5世代になってから相当APIとか充実したからネイティブのJavaScriptに置き換えたとしてもそこまでコードが肥大するってわけでもないしな
次はwordpressだ！これがデフォルトでフロントエンドにjquery差し込むもんだからjqueryのシェアがイマイチ下がらない諸悪の根源
>>23
Webサイトはそれでいいだろ
フレームワークが必要になるのはWebシステムなんだから
まぁWordPressよりもWixの方がいいだろ感はあるけど
Webサイトはそれでいいだろ
フレームワークが必要になるのはWebシステムなんだから
まぁWordPressよりもWixの方がいいだろ感はあるけど
よくこんな地獄みたいなスレ立てたな
>>26
創始者のプロジェクトからの離脱の前に
その前段階として飽きとか情熱が落ちるというのがあるのよ
創始者のプロジェクトからの離脱の前に
その前段階として飽きとか情熱が落ちるというのがあるのよ
>>27
アイデアからして全然違うフレームワークの方が圧倒的人気を持った場合、
自分のフレームワークのプロジェクトを閉じるのは当然で、情熱がなくなるのも
当然。
人気を出すためには、人気の有るフレームワークに近づける必要が有るわけで、
自分の路線でそのまま行っても人気が出る可能性は薄い。
また、本人も最大人気のフレームワークに比べて何らかの点で劣っている事が
分かっているはずで、自分のフレームワークを成長させていってもジリ貧である
ことがわかっているから、情熱を失う。
アイデアからして全然違うフレームワークの方が圧倒的人気を持った場合、
自分のフレームワークのプロジェクトを閉じるのは当然で、情熱がなくなるのも
当然。
人気を出すためには、人気の有るフレームワークに近づける必要が有るわけで、
自分の路線でそのまま行っても人気が出る可能性は薄い。
また、本人も最大人気のフレームワークに比べて何らかの点で劣っている事が
分かっているはずで、自分のフレームワークを成長させていってもジリ貧である
ことがわかっているから、情熱を失う。
別のフレームワークじゃなくJavaScriptの最新の傾向なんだけどね
それをいち早く取り入れたかどうかの違いで
それをいち早く取り入れたかどうかの違いで
>>29
Vue, React, Angular, Razorの違いって、そういうことじゃなくて、設計指針やアイデアの違い。
そして、結果的にVueが最も人気が有る。
新しいことを取り入れたかどうかではない。
Vue, React, Angular, Razorの違いって、そういうことじゃなくて、設計指針やアイデアの違い。
そして、結果的にVueが最も人気が有る。
新しいことを取り入れたかどうかではない。
確認だけど、最大人気は Vue が持っているんだよね。
後は、廃れている可能性が高くて。
後は、廃れている可能性が高くて。
VueはWebサイトでも使われてる事例が多いから相対的にシェアは大きいかもな
いや確かVueが一番人気なのは中国と日本とあともうひとつ変な国だけだったはず
>>34
vueは、githubの全プロジェクトの中で、ドキュメント(説明文のみ)部門を除いては一位の人気を誇る。
vueは、githubの全プロジェクトの中で、ドキュメント(説明文のみ)部門を除いては一位の人気を誇る。
そりゃ中国のプロジェクトだからなぁ
最新のstateofjs フロントエンドフレームワークの項
https://2019.stateofjs.com/front-end-frameworks/
ま、ガッカリすんなよ。ガラパゴスジャパンと中国父さんで人気なんだからいいじゃねぇか。
https://2019.stateofjs.com/front-end-frameworks/
ま、ガッカリすんなよ。ガラパゴスジャパンと中国父さんで人気なんだからいいじゃねぇか。
2020/4/26
webpack 4 の入門メモ
https://qiita.com/rubytomato@github/items/687b1987c7ee233443aa
webpack.config.js を自動作成するため、
npx webpack-cli init
と入力すると、@webpack-cli/init をインストールするか聞かれるので、インストールすると、
npm install -g @webpack-cli/init
で、バージョン・0.3 が入り、エラーが出て、ひどい目にあった！
そこで、アンインストールして、
npm uninstall -g @webpack-cli/init
代わりに、バージョン・0.2.2 をインストールした
npm install -g @webpack-cli/[email protected]
webpack 4 の入門メモ
https://qiita.com/rubytomato@github/items/687b1987c7ee233443aa
webpack.config.js を自動作成するため、
npx webpack-cli init
と入力すると、@webpack-cli/init をインストールするか聞かれるので、インストールすると、
npm install -g @webpack-cli/init
で、バージョン・0.3 が入り、エラーが出て、ひどい目にあった！
そこで、アンインストールして、
npm uninstall -g @webpack-cli/init
代わりに、バージョン・0.2.2 をインストールした
npm install -g @webpack-cli/[email protected]
バックエンドフレームワークでフロントのビルド環境が整ってるやつ使えばイチイチ気にする必要もないけどな
自分はLaravel使ってるがRoRでもv6から対応してるんだとか
>>39
anyenvとかの、本質的な管理(npm)の間に何層も便利レイヤーが入ってて、うまく動くときにツールがすごいだけなのに分かった気になって自分がすごいと調子に乗ってるからそうなる
結局そのプラットフォームで手広く使われてる管理方法をちゃんと理解しておかないと、
トラブったときに何が原因なのか切り分けられないから、
パッケージのバージョン違いのトラブル程度が「酷い目」に感じられるんだよ
anyenvとかの、本質的な管理(npm)の間に何層も便利レイヤーが入ってて、うまく動くときにツールがすごいだけなのに分かった気になって自分がすごいと調子に乗ってるからそうなる
結局そのプラットフォームで手広く使われてる管理方法をちゃんと理解しておかないと、
トラブったときに何が原因なのか切り分けられないから、
パッケージのバージョン違いのトラブル程度が「酷い目」に感じられるんだよ
Rails: webpack(er)に乗り換える25の理由（翻訳）
https://techracho.bpsinc.jp/hachi8833/2020_04_10/90859
Rails 5 から、webpack を使えたけど、
標準になったのは、Rails 6 から
https://techracho.bpsinc.jp/hachi8833/2020_04_10/90859
Rails 5 から、webpack を使えたけど、
標準になったのは、Rails 6 から
LaravelだとLaravelMixというwebpackの設定が簡単に書けるものがあるから
vueも割と簡単に導入できるな
vueも割と簡単に導入できるな
複雑な処理はwasm になるだろう
>>46 既にPython がwasm で動いてる。 データサイエンス部門はPython only になりそうだな。
当然Javascript の機能も使える。
当然Javascript の機能も使える。
Vueのプロジェクト新しく始めるときにVue-Cliって使ったほうがいいのかねえ
なんか裏側で何が起こってるのかよく分からなくなるから、個人的にはwebpackの設定ゴリゴリ書きたいんだけど、主流がvue-cliみたいだから無理やり使ってる
laravel mixとかもそうだけどwebpackをブラックボックスにしたツールあんま好きになれない
なんか裏側で何が起こってるのかよく分からなくなるから、個人的にはwebpackの設定ゴリゴリ書きたいんだけど、主流がvue-cliみたいだから無理やり使ってる
laravel mixとかもそうだけどwebpackをブラックボックスにしたツールあんま好きになれない
後継スレage
前スレ
>>986
書いたのぼくなんだけど、
いや決してblazor最高！って言ってるわけではない。
次に使う技術を選考するにあたって、
他のWebフレームワークでもおなじようなことができるのか純粋に聞きたかっただけ…
とにかくフロントとバックで言語を合わせたらできるということがわかった。ありがとう。
バックエンドをtsとc#のどっちがいいかは、両方使ったことがある人にしか判断つかなさそうね。
で、なかなかそういう人はいなさそう。
たぶんMS推しまくってる人もそうだと思う…
>>986
書いたのぼくなんだけど、
いや決してblazor最高！って言ってるわけではない。
次に使う技術を選考するにあたって、
他のWebフレームワークでもおなじようなことができるのか純粋に聞きたかっただけ…
とにかくフロントとバックで言語を合わせたらできるということがわかった。ありがとう。
バックエンドをtsとc#のどっちがいいかは、両方使ったことがある人にしか判断つかなさそうね。
で、なかなかそういう人はいなさそう。
たぶんMS推しまくってる人もそうだと思う…
>>50
単純に言語としての良し悪しならC#とTSは甲乙付けがたい。カッチリしたC#か、より柔軟なTSか。どちらも優れた言語だ。
バックエンドのエコシステムとして見たら……いろんな視点があるからなんとも
単純に言語としての良し悪しならC#とTSは甲乙付けがたい。カッチリしたC#か、より柔軟なTSか。どちらも優れた言語だ。
バックエンドのエコシステムとして見たら……いろんな視点があるからなんとも
ここはJSのすれなので...
ここは総合スレなので周辺の話題はOK
>>50
backendははっきりしてる。C#のがts(node)よりいい
実行速度がレベルが違う
backendは生産性考えたら静的言語以外は使いたくないわ
C#のように言語が強力だと何をやるにも楽だわ
backendははっきりしてる。C#のがts(node)よりいい
実行速度がレベルが違う
backendは生産性考えたら静的言語以外は使いたくないわ
C#のように言語が強力だと何をやるにも楽だわ
流石にC#だけの話はスレ違い
隔離スレ必要かも
普通のweb appでサーバーの実行速度がボトルネックになることはほぼねーよ。
いやふつうに速度落ちるし
どんだけ過疎サイト作ってるのさ
落ちなきゃいいとかいう低レベルなのでいいわけ？
サクサクにしないとリピーター増えないわけよ
どんだけ過疎サイト作ってるのさ
落ちなきゃいいとかいう低レベルなのでいいわけ？
サクサクにしないとリピーター増えないわけよ
C#の話しない奴は思考停止
>>54
いやあなためちゃくちゃjs,tsディスってるけど、
経験はあるの？
そういう頭ごなしに否定する意見はあまり信用できない。
いやあなためちゃくちゃjs,tsディスってるけど、
経験はあるの？
そういう頭ごなしに否定する意見はあまり信用できない。
>>61
そりゃあるよ
C#に比べたら動的言語は全部ゴミ
動的言語は生産性低いわ遅いわで最悪
AndroidもiOSも開発は静的言語だろ？
個人的な感想じゃなくて事実なの
そりゃあるよ
C#に比べたら動的言語は全部ゴミ
動的言語は生産性低いわ遅いわで最悪
AndroidもiOSも開発は静的言語だろ？
個人的な感想じゃなくて事実なの
JS, TSをディスってるのではない
動的言語、スクリプト全般がダメという話
MS, Google, Appleの一押し言語は全部、静的だろう
JSだけ取り残された化石なんだよ
動的言語、スクリプト全般がダメという話
MS, Google, Appleの一押し言語は全部、静的だろう
JSだけ取り残された化石なんだよ
じゃあこのスレはあなたの趣向に合わないねバイバイ
ぶっちゃけVSとc#はマジで最強
これは否定できない
しかしWebシステムではまったく使われていない
どうしようもないほどゴミクズな存在
普及しそうな気配もない
これは否定できない
しかしWebシステムではまったく使われていない
どうしようもないほどゴミクズな存在
普及しそうな気配もない
>>65
嘘をついてはいけない
Microsoft ASP.NET はシェア42%でトップ
https://www.wappalyzer.com/technologies/web-frameworks/
嘘をついてはいけない
Microsoft ASP.NET はシェア42%でトップ
https://www.wappalyzer.com/technologies/web-frameworks/
Web開発はjsから入る。
そこからtsに行くことはあっても
c#に行くことはないわな
そこからtsに行くことはあっても
c#に行くことはないわな
・老害は自説を曲げない
・老害は沸点が低い・怒りっぽい
・自分の価値観を押し付けてくる
・老害は話が長い、くどい
見事に老害の枠に収まってて草
https://docoic.com/9265
・老害は沸点が低い・怒りっぽい
・自分の価値観を押し付けてくる
・老害は話が長い、くどい
見事に老害の枠に収まってて草
https://docoic.com/9265
>>67
js, tsしかやらないっていうのは
静的言語わからないエンジニアのままでいるってことだな
C#やらなければwindows appもasp.netも使えない。
静的言語の理解がないのでAndroid , iOS appも開発できない
エンジニアとしてはかなり格下
js, tsしかやらないっていうのは
静的言語わからないエンジニアのままでいるってことだな
C#やらなければwindows appもasp.netも使えない。
静的言語の理解がないのでAndroid , iOS appも開発できない
エンジニアとしてはかなり格下
GCのある言語なんて軟弱、CやRustやれ。
コンパイル言語なんて軟弱、アセンブリやれ。
とかいくらでも言いようはあるわけで。C#の殻に籠もってればいいのに
コンパイル言語なんて軟弱、アセンブリやれ。
とかいくらでも言いようはあるわけで。C#の殻に籠もってればいいのに
餌を与えないで下さい
>>66
Wappalyzerに検知されるバックグランドテクノロジーってサーバーの構成に問題あると思う
たまにPHP5.4とかMySQLとかが検知されてるの見た事あるけど
Wappalyzerに検知されるバックグランドテクノロジーってサーバーの構成に問題あると思う
たまにPHP5.4とかMySQLとかが検知されてるの見た事あるけど
実際JS,TSしかできません、やりませんって人も多いんだろうね
でもプログラミング言語ってそんなもんだよね
日本語で生きていけるのに、英語学べ！って言われてもはあ…ってかんじだよ
いろんな言語を貪欲に習得する人はすげーなとおもう
でもプログラミング言語ってそんなもんだよね
日本語で生きていけるのに、英語学べ！って言われてもはあ…ってかんじだよ
いろんな言語を貪欲に習得する人はすげーなとおもう
>>75
全世界のデータが意味ないとでも？
掛け算して意味不明な値だしてるし頭悪すぎて草
％の使い方すらわからないことに驚き
全世界のデータが意味ないとでも？
掛け算して意味不明な値だしてるし頭悪すぎて草
％の使い方すらわからないことに驚き
webpackのビルド設定かなんかで専用のdevtoolには検知されてもWappalyzerでは検知されない事多々あるんだよな
TSやってる人は他の言語の経験それなりにあって、
Electronベースの結構複雑なソフト(それこそvscodeとか)を作ってるからTSを使ってる印象あるけどな
今風のイケてるプログラマーだと思うけど
てかそもそも言語は大事じゃないでしょ。職業プログラマーだったら色々な言語書くことになるでしょ。
Electronベースの結構複雑なソフト(それこそvscodeとか)を作ってるからTSを使ってる印象あるけどな
今風のイケてるプログラマーだと思うけど
てかそもそも言語は大事じゃないでしょ。職業プログラマーだったら色々な言語書くことになるでしょ。
>>80
寧ろ職業プログラマは仕事で使う言語しか覚えないからJavaしかできないってヤツとか相当多い
寧ろ職業プログラマは仕事で使う言語しか覚えないからJavaしかできないってヤツとか相当多い
>>80
frontendはJSしかできない奴多いよ
受託開発ならいろんな言語やらされるだろうが
そういう企業ばかりではないし
web appなら言語変わるのはbackendだろう。
frontendはJSしかできない奴多いよ
受託開発ならいろんな言語やらされるだろうが
そういう企業ばかりではないし
web appなら言語変わるのはbackendだろう。
next.js10の最適化凄いな。こういう変化の速さはさすがだわ
>>78
オメーがバカなんだろ
aspのシェアが42％でasp全体で日本は2ぱーなんだからフレームワーク全体だと掛け算だろが
小学生以下のアホがバカを晒して自慢すんな
オメーがバカなんだろ
aspのシェアが42％でasp全体で日本は2ぱーなんだからフレームワーク全体だと掛け算だろが
小学生以下のアホがバカを晒して自慢すんな
>>84
IT後進国の日本だけのシェアなどまったく意味がないし
そもそもそのそのデータの国別、言語別の統計はあてにならない
ということに気付かない時点で無能だわ
ほかのframeworkでもアメリカが50%超えてる時点で気付けないんだな
アメリカはコスパいいレンタルサーバー、データセンター、クラウドサービスが
多いからアメリカがシェアが高くなっているだけの話だ
それはIPアドレスで判定してるだけ
アメリカのデータ値はアメリカ人がアメリカ国内で使っていることを表しているわけではない
IT後進国の日本だけのシェアなどまったく意味がないし
そもそもそのそのデータの国別、言語別の統計はあてにならない
ということに気付かない時点で無能だわ
ほかのframeworkでもアメリカが50%超えてる時点で気付けないんだな
アメリカはコスパいいレンタルサーバー、データセンター、クラウドサービスが
多いからアメリカがシェアが高くなっているだけの話だ
それはIPアドレスで判定してるだけ
アメリカのデータ値はアメリカ人がアメリカ国内で使っていることを表しているわけではない
wappalyzerが最も信頼できる
選好バイアスというやつだね。
自分に都合のよい結果を出す情報源をより信頼してしまう。
自分に都合のよい結果を出す情報源をより信頼してしまう。
>>88
そう思うならほかの統計データ出してくれ
信頼できそうなやつな
一般の法人ならASP.NET系使うのはごくふつうのこと
サポート期限が長いしMSの技術と品質が信頼されてる
そう思うならほかの統計データ出してくれ
信頼できそうなやつな
一般の法人ならASP.NET系使うのはごくふつうのこと
サポート期限が長いしMSの技術と品質が信頼されてる
普通にLinuxかクラウドでしょ
少なくともLaravel-MixでビルドしたものはWappalyzerに検知されないしAmazonで部分的に使われてるReactもWappalyzerには検知されてないからな
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
thread.context.langs
// => ["js", "ts", "html", "css", "rust"]
// => ["js", "ts", "html", "css", "rust"]
>>90
さっぱり意味が分からない
ASP.net CoreはLinuxでも動くの知らない人？
あとクラウド＝Linuxだと思ってるの？
さっぱり意味が分からない
ASP.net CoreはLinuxでも動くの知らない人？
あとクラウド＝Linuxだと思ってるの？
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
LinuxでわざわざASPを使いたがるヤツなんて明らかに異端だろ
使いたがるやつが、明らかに居たんだよ
猫も杓子も、AWS
Amazon Linux, Aurora の時代に、
ASP, Windows Server, Azure とか、使う理由がない
もう新規で使われることはない。保守だけ
Amazon Linux, Aurora の時代に、
ASP, Windows Server, Azure とか、使う理由がない
もう新規で使われることはない。保守だけ
>>99
こいつもASP.net CoreがLinuxで動くこと知らない
フロントエンジニアは無知ばっかりだな
Azureで業績好調だし
こいつもASP.net CoreがLinuxで動くこと知らない
フロントエンジニアは無知ばっかりだな
Azureで業績好調だし
>>99
AzureはAWSについでシェア2位だよ
Windowsの比率はわからんけど選ばないということはない
少なくとも業務アプリ系では新規でも使われている。
ここにいる人たちってスレタイの技術使ってどんな規模のWebアプリ作ってるのかな。
それによっても使うクラウドサービスとか変わるんだろうね。
例えばFirestoreは複雑且つ大量データを扱う業務アプリ系では無理と感じた。
AzureはAWSについでシェア2位だよ
Windowsの比率はわからんけど選ばないということはない
少なくとも業務アプリ系では新規でも使われている。
ここにいる人たちってスレタイの技術使ってどんな規模のWebアプリ作ってるのかな。
それによっても使うクラウドサービスとか変わるんだろうね。
例えばFirestoreは複雑且つ大量データを扱う業務アプリ系では無理と感じた。
>>100
逆、逆
ASPを使ってる人の中でLinuxを使ってる人が多いかどうかじゃなく
Linuxを使ってる人の中でASPを使ってる人が多いかどうかの話だよ
逆、逆
ASPを使ってる人の中でLinuxを使ってる人が多いかどうかじゃなく
Linuxを使ってる人の中でASPを使ってる人が多いかどうかの話だよ
>>103
おまえの思考が逆
Web appはまず開発ツールのスタックを選んでから、OSは決める
server sideに関してはWindowsでしか動かないものよりも
Linuxでしか動かないものが多いからLinuxを選ぶケースが増える
＞Linuxを使ってる人の中でASPを使ってる人が多いかどうか
自分で優れている開発ツールを選び使うだけ
いくら多くの他人が動的言語のゴミ使おうが関係ない
PHPもRubyも遅いし生産性が低いし選ぶ価値がない
おまえの思考が逆
Web appはまず開発ツールのスタックを選んでから、OSは決める
server sideに関してはWindowsでしか動かないものよりも
Linuxでしか動かないものが多いからLinuxを選ぶケースが増える
＞Linuxを使ってる人の中でASPを使ってる人が多いかどうか
自分で優れている開発ツールを選び使うだけ
いくら多くの他人が動的言語のゴミ使おうが関係ない
PHPもRubyも遅いし生産性が低いし選ぶ価値がない
>>102
Firestoreは大量のデータを素早く裁くのはむしろ向いてると思うよ。複雑さの意味合いにもよるけど、向き不向きははっきりしてるよね。
IoTと組み合わせたWebでのリアルタイム監視的なものとか色々作ってるよ。Reactはまだ使い始めたとこだけど作りやすくて良いよね。用途によってクラウドも物理サーバも使い分けるよ。
Firestoreは大量のデータを素早く裁くのはむしろ向いてると思うよ。複雑さの意味合いにもよるけど、向き不向きははっきりしてるよね。
IoTと組み合わせたWebでのリアルタイム監視的なものとか色々作ってるよ。Reactはまだ使い始めたとこだけど作りやすくて良いよね。用途によってクラウドも物理サーバも使い分けるよ。
>>103
おまえらが知らないだけで
ライセンス無料になったからASP.NET Core始めた人がたくさんいるわけ
おまえらが知らないだけで
ライセンス無料になったからASP.NET Core始めた人がたくさんいるわけ
>>105
RDB脳なんでいまいち想像できないんだけど
Firestoreってログデータみたいな構造化されてないデータには向いてるとおもうけど、
商品マスタと10年間の売上データを結合して、商品マスタのなんちゃら区分ごとに集計するって言い出したら用途合わないよね…？
RDB脳なんでいまいち想像できないんだけど
Firestoreってログデータみたいな構造化されてないデータには向いてるとおもうけど、
商品マスタと10年間の売上データを結合して、商品マスタのなんちゃら区分ごとに集計するって言い出したら用途合わないよね…？
Amazon Linux, Aurora なら、数倍速くなる。
Lambda もある
GCP には、Tensorflow, Firebase がある
Azure には、セールスポイントが無い
Windows Server が落ち目だろ。
新規で、Windows Server を選ぶ香具師は、いない。保守だけ
Lambda もある
GCP には、Tensorflow, Firebase がある
Azure には、セールスポイントが無い
Windows Server が落ち目だろ。
新規で、Windows Server を選ぶ香具師は、いない。保守だけ
NoSQL は、銀行などの正確なものには向かない。
重複更新されたりするだろ
間違っても、問題がないような用途だけ
RDB みたいな表分割も出来ない
重複更新されたりするだろ
間違っても、問題がないような用途だけ
RDB みたいな表分割も出来ない
転職サイトでBlazor案件検索してみたが全然ヒットしないぞ
>>108
コレクションの組み方次第で可能。
でも可能だというだけで、そういうのは正直向いてないね。素直にRDB使いたい。
コレクションの組み方次第で可能。
でも可能だというだけで、そういうのは正直向いてないね。素直にRDB使いたい。
>>111
BlazorはASP.NETの中のひとつでしかないから
求人とかはASP.NET(Core)として扱われるだろう
まだ件数としてはBlazorより前のASP.NET MVCとかの方がはるかに多い
BlazorはASP.NETの中のひとつでしかないから
求人とかはASP.NET(Core)として扱われるだろう
まだ件数としてはBlazorより前のASP.NET MVCとかの方がはるかに多い
>>109
数倍とかいいかげんすぎる
オンプレミスで開発、運用するスキルがないから性能に大きな差が出る
数倍とかいいかげんすぎる
オンプレミスで開発、運用するスキルがないから性能に大きな差が出る
Firestore高すぎだろう
月間アクティブ100万ユーザーで月額30万円近くかかる。
年間360万円
いいカモになってるな
月間アクティブ100万ユーザーで月額30万円近くかかる。
年間360万円
いいカモになってるな
安さなら、AWS Lambda などのサーバーレス
>>116
求人ならふつうはC#とASP.NETで募集かけるだろう。
Blazor単体だとシェア0.5%もないし、APIつくるときは従来のASP.NET (Core) MVCを使う。
C#とASP.NETやってきた人にとってBlazorは覚えることはあまりない。
C#やASP.NETで経験つんできた人を採用する方がはるかにいい
求人ならふつうはC#とASP.NETで募集かけるだろう。
Blazor単体だとシェア0.5%もないし、APIつくるときは従来のASP.NET (Core) MVCを使う。
C#とASP.NETやってきた人にとってBlazorは覚えることはあまりない。
C#やASP.NETで経験つんできた人を採用する方がはるかにいい
>>117
高いといったのはFirestoreに限らずCloud DB全般。
オンプレミスでMySQL, Postgreとか使えば維持費はタダ同然だし
document data使いたければMongo DBとか使えばいい
時代はクラウドみたいな宣伝に洗脳されてカモになるのが
流行ってるのが理解できない
高いといったのはFirestoreに限らずCloud DB全般。
オンプレミスでMySQL, Postgreとか使えば維持費はタダ同然だし
document data使いたければMongo DBとか使えばいい
時代はクラウドみたいな宣伝に洗脳されてカモになるのが
流行ってるのが理解できない
規模ごとに値段出してくれてるのは親切だわ
月間100万アクティブユーザをタダ同然しかコストかけないオンプレミスは怖くない？
Firebaseから乗り換えるにしても、高可用性なVPSか、しっかりコストかけて鯖組むよ
Firebaseから乗り換えるにしても、高可用性なVPSか、しっかりコストかけて鯖組むよ
>>119
Redux、Webpackってキーワードですら普通にヒットするのに本当に使われてるなら出ないわけないだろ
Redux、Webpackってキーワードですら普通にヒットするのに本当に使われてるなら出ないわけないだろ
>>123
Blazor単体ではシェア少ないと書いただろ
あとBlazor Serverの社内システムとかは外部の統計にでてこない
他人ばかりきになるなら
クソみたいなPHPとかRubyやってりゃいいじゃん
みんなと同じことやって安心したいんでしょ
Blazor単体ではシェア少ないと書いただろ
あとBlazor Serverの社内システムとかは外部の統計にでてこない
他人ばかりきになるなら
クソみたいなPHPとかRubyやってりゃいいじゃん
みんなと同じことやって安心したいんでしょ
MSがWebFormの移行先にBlazorを挙げている。
何年か経ったらSIerが使い出すんじゃない？
業務系はクラサバ時代に作られためちゃくちゃ複雑な画面があったりするから、簡単にSPAが作れるならBlazorは歓迎されると思う。
何年か経ったらSIerが使い出すんじゃない？
業務系はクラサバ時代に作られためちゃくちゃ複雑な画面があったりするから、簡単にSPAが作れるならBlazorは歓迎されると思う。
>>122
ハードのコストはトラフィックやデータ量に依存するから書いてないだけで
サーバーは当然、用意するよ
Cloudに比べたらタダ同然ってこと
VPSとかしょぼすぎて無理
せっかくオンプレミスでやるのにサーバー借りるとかバカらしい
乗り換えるならそもそも独自仕様のFirebaseなんか使わないほうがいい
トラフィック増えたらひたすらカモられるのがクラウド
ハードのコストはトラフィックやデータ量に依存するから書いてないだけで
サーバーは当然、用意するよ
Cloudに比べたらタダ同然ってこと
VPSとかしょぼすぎて無理
せっかくオンプレミスでやるのにサーバー借りるとかバカらしい
乗り換えるならそもそも独自仕様のFirebaseなんか使わないほうがいい
トラフィック増えたらひたすらカモられるのがクラウド
>>125
日本はUIの注文が細かいからな
WPFもCore対応したようだから法人はWPFもありかもしれない
開発スピードはBlazorより速いしUXも良いはずだ
日本はUIの注文が細かいからな
WPFもCore対応したようだから法人はWPFもありかもしれない
開発スピードはBlazorより速いしUXも良いはずだ
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください。
ここはJSのスレです。
ここはJSのスレです。
前にASP.net MVCの案件したけど、使いやすかったね
PHPはLaravelがデファクトスタンダードになってるけど、あれASP.net MVCを真似て作ってる
PHPはLaravelがデファクトスタンダードになってるけど、あれASP.net MVCを真似て作ってる
Winows Server+SQL Serverな環境だとVS上で完結して開発できるのもメリット大きいと思った
そういうのってフロントエンドJavaScriptフレームワークと組み合わせられるのか、と思ったけどライブラリであるReactは組み合わせられるらしい。
こんな記事を2016年に作ってるんだから、MS的には共存したいようだ。
https://docs.microsoft.com/ja-jp/archive/msdn-magazine/2016/february/asp-net-progressive-enhancement-with-asp-net-and-react
こんな記事を2016年に作ってるんだから、MS的には共存したいようだ。
https://docs.microsoft.com/ja-jp/archive/msdn-magazine/2016/february/asp-net-progressive-enhancement-with-asp-net-and-react
マイクロソフトのサイトちょっと前はNuxt使ってた記憶あるけどな
>>127
いや要件上Webアプリにしたいのに開発スピードが早いからと言ってWPFするのは違う…
ただ、業務アプリとなると複雑度の違いはあれど画面数が100超えたりするので生産性はとても大事。
簡単な画面はサクサク作れても、複雑な画面になると一気にややこしくなるようなフレームワークだとつらい。
Reactとかってこういう大規模な業務アプリにはどうなんかね。
メンテナンス性も含めて気になる。ころころフレームワークがバージョンアップすると維持も大変だし。
いや要件上Webアプリにしたいのに開発スピードが早いからと言ってWPFするのは違う…
ただ、業務アプリとなると複雑度の違いはあれど画面数が100超えたりするので生産性はとても大事。
簡単な画面はサクサク作れても、複雑な画面になると一気にややこしくなるようなフレームワークだとつらい。
Reactとかってこういう大規模な業務アプリにはどうなんかね。
メンテナンス性も含めて気になる。ころころフレームワークがバージョンアップすると維持も大変だし。
>>133
.NET CoreのWPFでMac, Linuxも対応してクロスプラットフォームに
なったから、そもそもWeb appにする必要がないケースも多いんじゃないかってことだよ
Mobileから使う社員にはwin tabletやPCから使わせればいいわけで。
開発コストの増大、UXの低下とかのWeb appのデメリットが無視されすぎてる
.NET CoreのWPFでMac, Linuxも対応してクロスプラットフォームに
なったから、そもそもWeb appにする必要がないケースも多いんじゃないかってことだよ
Mobileから使う社員にはwin tabletやPCから使わせればいいわけで。
開発コストの増大、UXの低下とかのWeb appのデメリットが無視されすぎてる
>>133
後半、Reactの代替こそBlazorでしょ
開発のコストも時間もReactより大幅に抑えられる
Blazorならバージョンアップのコストも小さい
後半、Reactの代替こそBlazorでしょ
開発のコストも時間もReactより大幅に抑えられる
Blazorならバージョンアップのコストも小さい
WPFのMac/Linux版とかBlazorみたいな新しい茨の道進むよりははるかに情報も技術者も豊富なReactでWebにした方がずっと素直では……
>>136
そんな考えだから日本は生産性が低くなるんだろう。
Blazorでどれだけ楽になるか、コスト下がるかわかったら
Reactなんてあほらしくて使ってられないと思うが
日本人はまわりに合わせると言われてるからどうしようもないな、いつも遅い
実際はReact続ける方がコスト的にいばらの道だ
そんな考えだから日本は生産性が低くなるんだろう。
Blazorでどれだけ楽になるか、コスト下がるかわかったら
Reactなんてあほらしくて使ってられないと思うが
日本人はまわりに合わせると言われてるからどうしようもないな、いつも遅い
実際はReact続ける方がコスト的にいばらの道だ
そうやってフレームワーク争いしていればいいんじゃね？ｗ
世界は相変わらずjQueryを使っている
世界は相変わらずjQueryを使っている
Blazor調べたらC#で吐いた
無駄に複雑化してまでレガシーに拘ってる人が生産性を語るのか……
スレタイ見えないのか？
アメリカに行って「中国語はいいですよ！」って布教してこいよ
アメリカに行って「中国語はいいですよ！」って布教してこいよ
>>134
ネイティブアプリは必ず配布の問題が出てくる。
数十人ならともかく、千人規模になると運用つらいよ。
トレードオフの話で、生産性が少々落ちたとしても配布の手間をなくすためにWebアプリにする。
あとReactってそんなに生産性悪いのか？
じゃあなんで全世界でこんなに使われてるの？
ネイティブアプリは必ず配布の問題が出てくる。
数十人ならともかく、千人規模になると運用つらいよ。
トレードオフの話で、生産性が少々落ちたとしても配布の手間をなくすためにWebアプリにする。
あとReactってそんなに生産性悪いのか？
じゃあなんで全世界でこんなに使われてるの？
世界各国に行って「日本はいい国ですよ！」って言ったら
反対するのは特定の地域だけだろうな
反対するのは特定の地域だけだろうな
> あとReactってそんなに生産性悪いのか？
> じゃあなんで全世界でこんなに使われてるの？
そもそも使われてないでしょ？
あと「この道具は世界で一番使われてる。だから生産性が高いに違いない」
なんて言ったら笑われるよ
使われるかどうかなんてマーケティング能力の問題だからね
> じゃあなんで全世界でこんなに使われてるの？
そもそも使われてないでしょ？
あと「この道具は世界で一番使われてる。だから生産性が高いに違いない」
なんて言ったら笑われるよ
使われるかどうかなんてマーケティング能力の問題だからね
>>142
またその話か
インフラ側の知識が足りない。
アプリなんてグループポリシーで一括インストールできるし
他のシステム管理ツールでも管理できる
まともな企業なら無断で禁止アプリ使われないようなんらかの
ツールで管理してる
.NET CoreのWPFは単一のexeになるしdeployはコピーするだけだからさらに簡単になる。
single exeは.NET5だったからかもしれないがいづれにしもdeployはまったく問題ない
またその話か
インフラ側の知識が足りない。
アプリなんてグループポリシーで一括インストールできるし
他のシステム管理ツールでも管理できる
まともな企業なら無断で禁止アプリ使われないようなんらかの
ツールで管理してる
.NET CoreのWPFは単一のexeになるしdeployはコピーするだけだからさらに簡単になる。
single exeは.NET5だったからかもしれないがいづれにしもdeployはまったく問題ない
そのお着せのUIで事足りるならね・・・
実際にはある程度のカスタマイズが必要で
いろんなことができる割にやり方が複雑だったりする
結果フレームワークの使い方に振り回されることになる
実際にはある程度のカスタマイズが必要で
いろんなことができる割にやり方が複雑だったりする
結果フレームワークの使い方に振り回されることになる
>>142
後半
ブラウザ内で使える言語がJSだけだったからだ。過去形
Blazor wasmなどのWeb Assemblyが実用化してJS縛りがなくなった。
生産性の低いJSを使う必要性がなくなった。
後半
ブラウザ内で使える言語がJSだけだったからだ。過去形
Blazor wasmなどのWeb Assemblyが実用化してJS縛りがなくなった。
生産性の低いJSを使う必要性がなくなった。
未だにIEが要件に挙がるジャップランドでwasmなんて使えるの？
正直wasmで作るアプリは
「ブラウザで動かす必要はない」
「ブラウザで動かす必要はない」
>>147
え、じゃあ企業内で使うアプリは全てネイティブでやれってこと？
大抵の企業ってまずグループウェアがあってそこからシングルサインオンで各業務Webアプリに遷移するのが一般的だとおもうんだけど…
WPF、いいフレームワークだしOSS化したのは知ってるけど、それこそあまり使われてない印象。
多数の人に使われている技術は、知見が沢山あるのと、技術者を集めやすいメリットがある。
え、じゃあ企業内で使うアプリは全てネイティブでやれってこと？
大抵の企業ってまずグループウェアがあってそこからシングルサインオンで各業務Webアプリに遷移するのが一般的だとおもうんだけど…
WPF、いいフレームワークだしOSS化したのは知ってるけど、それこそあまり使われてない印象。
多数の人に使われている技術は、知見が沢山あるのと、技術者を集めやすいメリットがある。
WPFは俺の会社の範囲内では100%使われてる
だから世界でも使われてるはずだ
とかいうやつやろｗ
だから世界でも使われてるはずだ
とかいうやつやろｗ
デスクトップアプリは実績豊富なElectronでいいじゃん
正直ぽとペタで作れるのは見た目だけで
処理ではないので、あまり意義を感じられんのだよな
処理ではないので、あまり意義を感じられんのだよな
>>151
環境を限定できる業務アプリでIE縛りなんてないだろ、ナンセンス
あとなかなかIEやめないやつ対策で
IE開こうとするとEdgeが開くようにMSが変更するらしい
そこまでMSがやってるんだから開発者もIEを使わせないように努力するべき
環境を限定できる業務アプリでIE縛りなんてないだろ、ナンセンス
あとなかなかIEやめないやつ対策で
IE開こうとするとEdgeが開くようにMSが変更するらしい
そこまでMSがやってるんだから開発者もIEを使わせないように努力するべき
>>157
新規開発ばかりだと思ってんのか？
アホだな
環境を限定できるから、何年も前にIE縛りにして
IE縛りのアプリが残ってるから変更できないんだよ
しかたないからまたIE縛りでアプリを作る
新規開発ばかりだと思ってんのか？
アホだな
環境を限定できるから、何年も前にIE縛りにして
IE縛りのアプリが残ってるから変更できないんだよ
しかたないからまたIE縛りでアプリを作る
>>153
全てなんて言ってないだろう
SPから使う必要があるならWPFは選択肢から外さざるを得ない
WPFがベストなシステムでも必要もなくWeb appにしてる企業が多すぎるということ
外部企業に作らせていてその会社がWeb appしか作れないんだろう
全てなんて言ってないだろう
SPから使う必要があるならWPFは選択肢から外さざるを得ない
WPFがベストなシステムでも必要もなくWeb appにしてる企業が多すぎるということ
外部企業に作らせていてその会社がWeb appしか作れないんだろう
UIに時間がかかるとか、本末転倒ですねｗ
> 実績がなければ.NET Core対応したりしない
実績がなくても.NET Core対応とかするやろ
DelphiとかCOBOLLとか
実績がなくても.NET Core対応とかするやろ
DelphiとかCOBOLLとか
>>160
しかたないからまたIE縛りでアプリを作る？
それただの馬鹿な企業だろｗ
依頼するほうも要件丸のみして開発するほうも両方バカ
IEはセキュリティ低いしもう終わるのでやめましょうと言えないのは無能
そのうち消えるIEに合わせて作ったらIE終了時で大問題になる
しかたないからまたIE縛りでアプリを作る？
それただの馬鹿な企業だろｗ
依頼するほうも要件丸のみして開発するほうも両方バカ
IEはセキュリティ低いしもう終わるのでやめましょうと言えないのは無能
そのうち消えるIEに合わせて作ったらIE終了時で大問題になる
>>165
客がそれを望んでるのだからしょうがない
IE終了なら、その時は作り直しですねーって金を取るからいい
それを渋るなら、その会社はいつまでも古いものを使うってだけだ
未だにフロッピーディスクを使っている会社とかよくある話
客がそれを望んでるのだからしょうがない
IE終了なら、その時は作り直しですねーって金を取るからいい
それを渋るなら、その会社はいつまでも古いものを使うってだけだ
未だにフロッピーディスクを使っている会社とかよくある話
知ったこっちゃない、の誤字
IE前提の開発を続けることの危険性を
クライアントに伝えられないならプロではない
意識低い系
レベル低い
クライアントに伝えられないならプロではない
意識低い系
レベル低い
>>171
WPFのプラットフォームは撤回する。調べたらフェイク情報だった
.NET MAUIでiOS, Andoroid対応するからそれに期待する
WPFのプラットフォームは撤回する。調べたらフェイク情報だった
.NET MAUIでiOS, Andoroid対応するからそれに期待する
その方面での人気はReactに大きく水を開けられてますね。
GitHub stars
React-native 91k
MAUI 4.9k
ちなみに元になったXamarinも似たような数字なので、新しいから星が少ないわけでは無い模様。
GitHub stars
React-native 91k
MAUI 4.9k
ちなみに元になったXamarinも似たような数字なので、新しいから星が少ないわけでは無い模様。
Githubの星で判断するのは無理があるわ
それはまぁそうだ。でもなんの根拠もない主観帯な意見よりは役に立つ
GitHub Starは1000超えてるかどうか2値くらいの価値しかない
なんなら React Native for Windows もMSが開発してる
>>179
俺は信者じゃないしMySQLとかをよく使う
C#, ASP.NETは良いものだから使っているだけ
Electronのアドバンテージなんかあるか？低速だろ
React Nativeも下火だぞ
俺は信者じゃないしMySQLとかをよく使う
C#, ASP.NETは良いものだから使っているだけ
Electronのアドバンテージなんかあるか？低速だろ
React Nativeも下火だぞ
月間アクティブ100万人って規模なら
たった30万円の維持費を減らす努力よりもっとほかにやることあるよなそりゃ
たった30万円の維持費を減らす努力よりもっとほかにやることあるよなそりゃ
>>149
Q:WPFは、.NET Core3 を使えば、Linux で動作しますか？
A: いいえ、彼らはそれらが明確にWindowsのみに対応していると述べました。
そして、将来も、それらをクロス・プラットフォームにするつもりはないことを
明言しました。なぜなら、その全体の概念がWindows特有の機能からもたらされて
いるからです。
彼らは、クロスプラットフォームアプリケーションについての完全に新しいアイデアに
ういて話し合いましたが、それは簡単ではありません。
[Q] Can WPF applications be run in Linux with .Net Core 3?
2019/06/19
[A]
No, they have clearly stated that these are windows only.
In one of the .NET Core 3.0 discussions, they have also clarified
that they do not intend to make these features cross-platform
in the future since the whole concept is derived from windows specific features.
They talked about thinking of a whole new idea for cross-platform applications,
which is not easy.
Q:WPFは、.NET Core3 を使えば、Linux で動作しますか？
A: いいえ、彼らはそれらが明確にWindowsのみに対応していると述べました。
そして、将来も、それらをクロス・プラットフォームにするつもりはないことを
明言しました。なぜなら、その全体の概念がWindows特有の機能からもたらされて
いるからです。
彼らは、クロスプラットフォームアプリケーションについての完全に新しいアイデアに
ういて話し合いましたが、それは簡単ではありません。
[Q] Can WPF applications be run in Linux with .Net Core 3?
2019/06/19
[A]
No, they have clearly stated that these are windows only.
In one of the .NET Core 3.0 discussions, they have also clarified
that they do not intend to make these features cross-platform
in the future since the whole concept is derived from windows specific features.
They talked about thinking of a whole new idea for cross-platform applications,
which is not easy.
彼の言うことは間違っているか主観的で偏見に満ちているという事か
おまけにスレ違いだ
https://ja.wikipedia.org/wiki/.NET_Core
「.NET Core 3.0では、Windows版に限りWindows FormsおよびWPFのサポートが
提供されるようになった」
「.NET Core 3.0では、Windows版に限りWindows FormsおよびWPFのサポートが
提供されるようになった」
どこの板行ってもみんなに迷惑かけて嫌われてるな、ドザはｗｗｗ
ソフトウェア開発の場合はMacやLinuxを使うユーザーも大量にいるけど、一般的なビジネスソフトの場合は無視できるレベル
実際MacはまだしもLinux向けのビジネスソフトなんかほとんどないわけだし
実際MacはまだしもLinux向けのビジネスソフトなんかほとんどないわけだし
まぁね。俺はデスクトップLinuxユーザだけど、それは俺が開発者でしかもLinuxが好きだからだ。
Electron、マルチウィンドウとか高度なUIだとネイティブのGUIには敵わないなという印象
VSと比べると、VSCodeはタブウィンドウの動作が不自然でマルチモニター環境だと使い勝手が大きく劣る
単純に重いというのもあるし
VSと比べると、VSCodeはタブウィンドウの動作が不自然でマルチモニター環境だと使い勝手が大きく劣る
単純に重いというのもあるし
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
「クロスプラットフォームできる！」
↓
できませんでしたｗｗ
↓
「クロスプラットフォームなど不要！ウィンドウズだけで十分！」
自分ができないことを必要ないと強弁するのがRubyコミュニティとソックリｗｗｗ
↓
できませんでしたｗｗ
↓
「クロスプラットフォームなど不要！ウィンドウズだけで十分！」
自分ができないことを必要ないと強弁するのがRubyコミュニティとソックリｗｗｗ
生産性の違いをまじで知りたいんだけど…
彼以外に両方やってる人はいない…？
BlazorよりReactのほうが生産性高いわい！という声がない。
彼以外に両方やってる人はいない…？
BlazorよりReactのほうが生産性高いわい！という声がない。
>>193
いやたぶんC#側にバカにされたRuby野郎の成れの果てやろ。普通にC#触ってるならWPFがクロスプラットフォーム対応してないことなんて常識…
いやたぶんC#側にバカにされたRuby野郎の成れの果てやろ。普通にC#触ってるならWPFがクロスプラットフォーム対応してないことなんて常識…
C#もReactも使えるけどBlazor使った事無いし。彼みたいに使っても無い物を根拠も例もなしにこき下ろすような事できないし
>>194
生産性なんて結局の所慣れてるかどうかでしかない
UI部分の話でしかないから、ほしいコンポーネントがあるかどうか
それもシンプルなUIにすれば、複雑なものなんかいらない
生産性なんて結局の所慣れてるかどうかでしかない
UI部分の話でしかないから、ほしいコンポーネントがあるかどうか
それもシンプルなUIにすれば、複雑なものなんかいらない
日本に決まってるだろー！
React には、周辺のエコシステムがある
Ruby on Rails, Bootstrap, React の組み合わせも多い。
React で、styled-components だろ
Redux, TypeScript もある
Ruby on Rails, Bootstrap, React の組み合わせも多い。
React で、styled-components だろ
Redux, TypeScript もある
TypeScriptが動的型言語と静的型言語の良いとこ取りを達成しちゃったからなぁ。Union型とかLiteral型とかIntersection型とか、その他もろもろ。
ちなみにMSはTypeScript＋VScodeをc#＋VS並の生産性にしたいらしい
BlogやVScodeのアップデート履歴にそれらが記載されていてアイデアくれってユーザーに呼びかけている
BlogやVScodeのアップデート履歴にそれらが記載されていてアイデアくれってユーザーに呼びかけている
>193
desktopとしてLinux, Mac使ってる人ほぼゼロだし
web appである必要ない場合多いって事実だろ
なんでもweb appにしてしまう風潮おかしい
3DCGもApple非対応のソフトが増えてるらしいからな
Macはもうクリエイターからも見放されている
desktopとしてLinux, Mac使ってる人ほぼゼロだし
web appである必要ない場合多いって事実だろ
なんでもweb appにしてしまう風潮おかしい
3DCGもApple非対応のソフトが増えてるらしいからな
Macはもうクリエイターからも見放されている
>>197
俺の言ってるBlazorの生産性ってUI限定の話じゃないぞ
ASP coreだとbackend含めて大幅に生産性があがる
同じ人が同じ言語で同じC#ライブラリ使ってかけるから
生産性が桁違いにあがる
俺の言ってるBlazorの生産性ってUI限定の話じゃないぞ
ASP coreだとbackend含めて大幅に生産性があがる
同じ人が同じ言語で同じC#ライブラリ使ってかけるから
生産性が桁違いにあがる
>>207
TS、JSは低速だしbackendで使わないほうがいい
しょぼいアクセスのサイトならいいけど
SPはMAUIでるまで対応しないから上の議論では外していただけで
ちゃんと考慮はしている
SP対応させたいならBlazorを使えばいい
TS、JSは低速だしbackendで使わないほうがいい
しょぼいアクセスのサイトならいいけど
SPはMAUIでるまで対応しないから上の議論では外していただけで
ちゃんと考慮はしている
SP対応させたいならBlazorを使えばいい
>>209
VS codeよりVSのがいいのはわかる。
tsはASPもWPFも対応してないし当分はC#がMSの主役言語でしょ
VS codeよりVSのがいいのはわかる。
tsはASPもWPFも対応してないし当分はC#がMSの主役言語でしょ
>>208
普通はDBの方が速度に対する影響大きいでしょ。それにJSはかなり最適化入っててそこそこ速い。もしそんなJSの速度で不満ならGoなりRustなり使うよ。
MAUIなんて待たなくてもその前身であるXamarin使えば良い。と思ったけどそれだと移植が必要だからのMAUI待ちか。どちらにせよWPFそのままってわけにはいかないよね
普通はDBの方が速度に対する影響大きいでしょ。それにJSはかなり最適化入っててそこそこ速い。もしそんなJSの速度で不満ならGoなりRustなり使うよ。
MAUIなんて待たなくてもその前身であるXamarin使えば良い。と思ったけどそれだと移植が必要だからのMAUI待ちか。どちらにせよWPFそのままってわけにはいかないよね
>>212
わざわざ遅い言語でbackend作る意味がない
nodeもrailsもC#に比べると激遅いぞ
わざわざ遅い言語でbackend作る意味がない
nodeもrailsもC#に比べると激遅いぞ
未だに、Webサイトの最高速度は、Ruby on Rails。
瞬間で表示される。
他のフレームワークじゃ無理
表示速度が“異常な”Webサイト「dev.to」とか
https://dev.to/
元乃木坂46 の川後陽菜のWebサイト、SKIYAKI とか
https://kawagopro.com/
瞬間で表示される。
他のフレームワークじゃ無理
表示速度が“異常な”Webサイト「dev.to」とか
https://dev.to/
元乃木坂46 の川後陽菜のWebサイト、SKIYAKI とか
https://kawagopro.com/
>>213
シンプルなコードだから参考記録だけど、まぁ一応JSはC#より2倍遅い程度で、劇遅いとまでは言いにくい。JSで遅ければ（ボトルネック部分を）C#より速い言語にするよ。
https://qiita.com/yosgspec/items/4b2c1059f9a49fb06c5c
そもそもパフォーマンスチューニングで最も重要なのは計測だよ。ボトルネック見つけて、それからその部分を最適化すべきだ。
シンプルなコードだから参考記録だけど、まぁ一応JSはC#より2倍遅い程度で、劇遅いとまでは言いにくい。JSで遅ければ（ボトルネック部分を）C#より速い言語にするよ。
https://qiita.com/yosgspec/items/4b2c1059f9a49fb06c5c
そもそもパフォーマンスチューニングで最も重要なのは計測だよ。ボトルネック見つけて、それからその部分を最適化すべきだ。
>>214
Railsは論外に遅い
ASP.net Coreの1/10から1/20の速度になってることがある。
Railsは論外に遅い
ASP.net Coreの1/10から1/20の速度になってることがある。
>>216
C#はILを使うんだからC++に勝てるわけないだろ
しかし生産性とのバランス考えると最強になる
web appでC++とか使ってられない
使いやすいframeworkがないとだめ
ベンチだけ速いマイナー言語は使えない
C#はILを使うんだからC++に勝てるわけないだろ
しかし生産性とのバランス考えると最強になる
web appでC++とか使ってられない
使いやすいframeworkがないとだめ
ベンチだけ速いマイナー言語は使えない
バランス考えるとJSが最強やろｗ
静的型のメリットも享受できそこそこ早いTypeScriptで使いやすいフレームワークを使った上で遅い部分をCなりWasmなりで最適化する、と
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
なんとなく自分の中で結論が出たよ。
生産性についてはASP.NET+C#に軍配が上がるけど、
React,Vue+TypeScriptのほうが人気。開発者も集めやすいし、情報が多い。
どちらもバランスが取れた言語、フレームワーク。
わざわざ今tsやってる人がC#を習得しなくてもいいし、逆もまた然り。
ってかんじかな…
生産性についてはASP.NET+C#に軍配が上がるけど、
React,Vue+TypeScriptのほうが人気。開発者も集めやすいし、情報が多い。
どちらもバランスが取れた言語、フレームワーク。
わざわざ今tsやってる人がC#を習得しなくてもいいし、逆もまた然り。
ってかんじかな…
2020年、世界で最も使われているWebフレームワークはjQuery
https://insights.stackoverflow.com/survey/2020#technology-web-frameworks-all-respondents2
https://insights.stackoverflow.com/survey/2020#technology-web-frameworks-all-respondents2
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
>>222
BlazorはC#+ASP.NETの知識ある人にとっては
覚えることがほとんどないんだよ
Razor syntaxという以前からのASP.NET同じような書き方をする
情報も英語できる人なら新しいBlazorでさえ情報十分
C#の中級者以上ならASP.NETもBlazorも短期間で習得できるから
人の集めやすさも問題ない。
BlazorはC#+ASP.NETの知識ある人にとっては
覚えることがほとんどないんだよ
Razor syntaxという以前からのASP.NET同じような書き方をする
情報も英語できる人なら新しいBlazorでさえ情報十分
C#の中級者以上ならASP.NETもBlazorも短期間で習得できるから
人の集めやすさも問題ない。
あと分かったこと。
ts+VSCodeのイケてるWebプログラマ達は、実はSIerが扱うC#+VSより生産性の低いやり方でやっているという…
でもMSもここに金を注ぎ込んでいるし、そのうち改善されるんでしょう。
ts+VSCodeのイケてるWebプログラマ達は、実はSIerが扱うC#+VSより生産性の低いやり方でやっているという…
でもMSもここに金を注ぎ込んでいるし、そのうち改善されるんでしょう。
生産性の低いやり方でやってるはずなのに
なぜか生産量は多い
とか言う話かね？
なぜか生産量は多い
とか言う話かね？
ASPにシェアがあると言ったりWeb屋はMS系の知識無いと言ったり矛盾してませんかねぇ
>>230
矛盾してない
web系企業というジャンルがあるんだよ
web エンジニアがweb系の企業にだけいるわけじゃない
矛盾してない
web系企業というジャンルがあるんだよ
web エンジニアがweb系の企業にだけいるわけじゃない
つまりASPやってるのはWebエンジニアじゃないって事？
Webを触るけどWebエンジニアじゃない人々なの？
Webを触るけどWebエンジニアじゃない人々なの？
YouTube で有名な雑食系エンジニア・KENTA は、
初心者が進む道を、サーバー側言語のRuby → Go を王道としてる
この2つ以外は、出てこない
GUI 系は、画面の手直しなどで、工数がかさむ。
C#, dot.net などのWindows 系は、いらない。
Java などの土方系も、いらない。
C/C++ などのポインタ系や、ハードウェアの仕組みなども、いらない。
Elixir, Rust は、普及へのchasm・溝を超えられなかった
言語よりも、Docker, Kubernetes, AWS などの、サーバー構築・新規案件を重視する。
上流工程・新規案件の方が、価格交渉力が強いから。
一方、下流工程・保守案件は低価格しかない
ベンチャー企業では、Ruby on Rails, AWS, CircleCI がデフォルト。
Amazon Linux, Aurora か、Lambda
YouTube で有名な、くろかわこうへいは、
来年から、AWS の有料講座を始めるらしい
もう会社では、AWSが必須で、
年収が500万円とか、プログラマーより上になってる
初心者が進む道を、サーバー側言語のRuby → Go を王道としてる
この2つ以外は、出てこない
GUI 系は、画面の手直しなどで、工数がかさむ。
C#, dot.net などのWindows 系は、いらない。
Java などの土方系も、いらない。
C/C++ などのポインタ系や、ハードウェアの仕組みなども、いらない。
Elixir, Rust は、普及へのchasm・溝を超えられなかった
言語よりも、Docker, Kubernetes, AWS などの、サーバー構築・新規案件を重視する。
上流工程・新規案件の方が、価格交渉力が強いから。
一方、下流工程・保守案件は低価格しかない
ベンチャー企業では、Ruby on Rails, AWS, CircleCI がデフォルト。
Amazon Linux, Aurora か、Lambda
YouTube で有名な、くろかわこうへいは、
来年から、AWS の有料講座を始めるらしい
もう会社では、AWSが必須で、
年収が500万円とか、プログラマーより上になってる
そういうこと
所属企業のジャンルとか、ほかに手掛けてる技術とかで変わる
自社開発で不特定多数向けのweb serviceを作ってる企業を
web系企業といったり、そこにいるひとをweb（系）エンジニアといったりする。
日本だとヤフーみたいなところだ
受託開発でやってる企業のC#エンジニアはweb appだけやってることは稀。
WPFとかほかのC#にも携わってることが多い上にweb系企業所属でもないから
webエンジニアと言われることは少ない
所属企業のジャンルとか、ほかに手掛けてる技術とかで変わる
自社開発で不特定多数向けのweb serviceを作ってる企業を
web系企業といったり、そこにいるひとをweb（系）エンジニアといったりする。
日本だとヤフーみたいなところだ
受託開発でやってる企業のC#エンジニアはweb appだけやってることは稀。
WPFとかほかのC#にも携わってることが多い上にweb系企業所属でもないから
webエンジニアと言われることは少ない
YouTube で有名な、くろかわこうへいは、
来年から、AWS の有料講座を始めるので、
1万円あげるから、モニター受講者5人を探していたけど、応募者が殺到
時代はKENTA から、くろかわへ移った！
職を欲しい香具師が、AWSへ殺到
来年から、AWS の有料講座を始めるので、
1万円あげるから、モニター受講者5人を探していたけど、応募者が殺到
時代はKENTA から、くろかわへ移った！
職を欲しい香具師が、AWSへ殺到
YouTube の、KENTA・くろかわこうへいが、
web バックエンドの歴史・道筋を作った！
時代が変わった瞬間
YouTube からは、こういう時代の寵児が出てくる。
必ず、誰かがやる
web バックエンドの歴史・道筋を作った！
時代が変わった瞬間
YouTube からは、こういう時代の寵児が出てくる。
必ず、誰かがやる
>>233
おまえコピペばっかりだな
C#とJavaやらないとかいってるKENTAはレベル低い
やらないというよりできない、が正しい
サーバーサイドのスキルがないからクラウド前提になる
おまえコピペばっかりだな
C#とJavaやらないとかいってるKENTAはレベル低い
やらないというよりできない、が正しい
サーバーサイドのスキルがないからクラウド前提になる
>>236
へぼいYouTuberに洗脳されすぎ
バックエンドで速度でてメジャーなのといったらC#とJava
そこができないKENTAはレベル高くはない
へぼいYouTuberに洗脳されすぎ
バックエンドで速度でてメジャーなのといったらC#とJava
そこができないKENTAはレベル高くはない
>>233
に書いたような旧技術よりも、AWS などの価値が大きくなった。
GAFA, Microsoft の5社の時価総額が、東証一部と同じ、500兆円
今後は、Amazon 1社で、500兆円になるかも
Ruby on Rails のポートフォリオも、マコなりの所のメルカリクローンばかりになって、
ついにKENTA も、面接で学校へ通っていたことを言わないでくださいって言ってたw
学校のポートフォリオを、そのまま提出する香具師が多いから、
企業からは、学校へ通っていた香具師は採用しないとか
Railsのコピペ・チート技術がまん延した結果、
誰でもメルカリが作れるようになってしまったw
に書いたような旧技術よりも、AWS などの価値が大きくなった。
GAFA, Microsoft の5社の時価総額が、東証一部と同じ、500兆円
今後は、Amazon 1社で、500兆円になるかも
Ruby on Rails のポートフォリオも、マコなりの所のメルカリクローンばかりになって、
ついにKENTA も、面接で学校へ通っていたことを言わないでくださいって言ってたw
学校のポートフォリオを、そのまま提出する香具師が多いから、
企業からは、学校へ通っていた香具師は採用しないとか
Railsのコピペ・チート技術がまん延した結果、
誰でもメルカリが作れるようになってしまったw
KENTA の職歴
https://github.com/kenta-polyglot/cv
100以上の技術をやってる！
https://github.com/kenta-polyglot/cv
100以上の技術をやってる！
jQueryおじさん、Youtuberおじさん、C#おじさん三つ巴の戦いが今、始まる。
蠱毒かな？
蠱毒かな？
共通項は狂人ってことかな
関係ないやつらが関係ないはずのJavaScriptスレで延々と必死に我田引水の宣伝合戦を繰り広げるということは、逆説的にいかにJavaScriptの人気が高いかということを示してしまっているねｗｗｗ
確かにw
使える技術一覧にDHCPなんて書く奴全く信用できないけどな
…
KENTA の千円のサロンは、1,200人で、技術系としては異例の多さ！
勝又健太さんが運営する雑食系エンジニアサロンの口コミと評判！
https://onsalofan.com/creaarhacksalon-kentakatsumata/
勝又健太さんが運営する雑食系エンジニアサロンの口コミと評判！
https://onsalofan.com/creaarhacksalon-kentakatsumata/
雑食系ケンタはフロントはド素人だからな
C#, Javaもやってないからbackendもたいしたことない
KENTA の職歴には、Rails, jQuery, Vue.js はあるけど、
Node.js, React, Bootstrap, Electron, Express, Firebase は無い
Bootstrap を使わずに、レスポンシブ対応をどうやったのか？
Kotlin, Scala, Java, VC++, C# もある
Node.js, React, Bootstrap, Electron, Express, Firebase は無い
Bootstrap を使わずに、レスポンシブ対応をどうやったのか？
Kotlin, Scala, Java, VC++, C# もある
>>250
Bootstrap無くてもレスポンシブ対応はCSSでできるやん。かなり特殊な条件でもResizeObserberで行けるだろうし
Bootstrap無くてもレスポンシブ対応はCSSでできるやん。かなり特殊な条件でもResizeObserberで行けるだろうし
>>250
むしろBootstrap使っただけのサイトをレスポンシブなんて言わないだろ
CSS自力で書けないのにレスポンシブWebが作れますって宣言するレベルもケンタ？レベルだろ
そんなに難しくないぞ、HTML/CSS
むしろBootstrap使っただけのサイトをレスポンシブなんて言わないだろ
CSS自力で書けないのにレスポンシブWebが作れますって宣言するレベルもケンタ？レベルだろ
そんなに難しくないぞ、HTML/CSS
つーかそもそもワナビーぐらいしかWebエンジニア系YouTuberなんか見ないだろ
だって情報ありふれてて態々動画で見る意味がないもん
組み込みとかゲームだったらまだ面白い気がするけど、Webって一番エンジニア数も多くて底も浅いじゃん
有名フレームワーク作ってるとかWebサーバー作ってるとかなら話は別だが、動画で見たいか？
どっちかっていうとドキュメント読みたいだろ
YouTubeチャンネルの人気度で測ってること自体、正直レベル低すぎでしょ。その動画を面白いと思う人がいることと業界で金になるとか技術力が高いってことは全然別だもの。
なんでYouTubeで初心者、子供の人気が集まる人が優秀ってことになるのかさっぱり理解できない。
だって情報ありふれてて態々動画で見る意味がないもん
組み込みとかゲームだったらまだ面白い気がするけど、Webって一番エンジニア数も多くて底も浅いじゃん
有名フレームワーク作ってるとかWebサーバー作ってるとかなら話は別だが、動画で見たいか？
どっちかっていうとドキュメント読みたいだろ
YouTubeチャンネルの人気度で測ってること自体、正直レベル低すぎでしょ。その動画を面白いと思う人がいることと業界で金になるとか技術力が高いってことは全然別だもの。
なんでYouTubeで初心者、子供の人気が集まる人が優秀ってことになるのかさっぱり理解できない。
ケンタがまともなUI作れるわけがない
というかケンタだけじゃなくお前らの大半がゴミのようなUIしか作れないんだから終わってんだろ
というかケンタだけじゃなくお前らの大半がゴミのようなUIしか作れないんだから終わってんだろ
>>254
英語音声のYouTubeのプログラミング関連はクオリティ高いのあるから割と見てる。
公式ドキュメントでカバーされてない話題とかTipsがあったりする。
ドキュメントより動画のがわかりやすいものもある。
開発チームのトップが解説してる動画もいい
英語音声のYouTubeのプログラミング関連はクオリティ高いのあるから割と見てる。
公式ドキュメントでカバーされてない話題とかTipsがあったりする。
ドキュメントより動画のがわかりやすいものもある。
開発チームのトップが解説してる動画もいい
組み込みなんていう遺物をいつまでやってんだか
>>257
Linuxカーネルの開発なんかは組み込みに近いところがあるし、
ドライバ〜ハードウェア抽象化層〜OSまでのコード生成が仕様書から自動で行われなくなるようにならない限り
組み込み的な開発はずっと必要だよ。
遺物だと思うのは何十にも抽象化されたようなアプリレイヤーしか触ってないからでしょ。
まあ、jsスレだしそう思うフロントしかわからない人が居ても不自然ではないが。
Linuxカーネルの開発なんかは組み込みに近いところがあるし、
ドライバ〜ハードウェア抽象化層〜OSまでのコード生成が仕様書から自動で行われなくなるようにならない限り
組み込み的な開発はずっと必要だよ。
遺物だと思うのは何十にも抽象化されたようなアプリレイヤーしか触ってないからでしょ。
まあ、jsスレだしそう思うフロントしかわからない人が居ても不自然ではないが。
>>256
自分もそういう動画は見ることがあって、
もちろん、全ての動画解説を否定しているつもりはなく、
開発技術ジャンルを、チャンネル登録者数の多いYouTuberが一押ししてるから今はこのジャンルが強い、みたいに評価することに何の意味があるのって意見を言いたかっただけ。
チャンネル登録者数が多いってことは多くの場合は初心者にとってキャッチーで簡単なだけで、
それ以上の商業的、技術的意味はない訳だろう。
割とコアに活動してる技術者達が、今はこれが熱い(将来性を感じる)と言っているならわかるけど、
いくら人気だろうがYouTuberに特化したエンジニア崩れが何言ってようが初心者が初心者になんか言ってるだけで、
小学生の間でどの漫画が流行ってるぐらいの意味しかないだろう。
自分もそういう動画は見ることがあって、
もちろん、全ての動画解説を否定しているつもりはなく、
開発技術ジャンルを、チャンネル登録者数の多いYouTuberが一押ししてるから今はこのジャンルが強い、みたいに評価することに何の意味があるのって意見を言いたかっただけ。
チャンネル登録者数が多いってことは多くの場合は初心者にとってキャッチーで簡単なだけで、
それ以上の商業的、技術的意味はない訳だろう。
割とコアに活動してる技術者達が、今はこれが熱い(将来性を感じる)と言っているならわかるけど、
いくら人気だろうがYouTuberに特化したエンジニア崩れが何言ってようが初心者が初心者になんか言ってるだけで、
小学生の間でどの漫画が流行ってるぐらいの意味しかないだろう。
日本でも海外でも専門分野の話はユーチューブ以外で
実績ないと信用したらダメだろ
実績ないと信用したらダメだろ
組み込みとかハードに近いコード書いてるやつらはリスペクトしてる。
他所から見ると変化の無さそうに見えるけど、けっこう激しく変化してる世界だし、構造体を見事に組み合わせてメモリ効率良く美しいロジック組んでるの見るとホレボレする。
他所から見ると変化の無さそうに見えるけど、けっこう激しく変化してる世界だし、構造体を見事に組み合わせてメモリ効率良く美しいロジック組んでるの見るとホレボレする。
逆に組み込み屋から見ると、こちらはこちらでレイヤーが多いし異様に高度に抽象化してるように見えるらしく、スゲースゲー言われる。
基礎は共有してても専門性が高い部分はお互いわからない。見下したりせず、お互いリスペクトしあうのか望ましい
基礎は共有してても専門性が高い部分はお互いわからない。見下したりせず、お互いリスペクトしあうのか望ましい
>>259
日本人YouTuberはプログラミングの解説動画はあまり作らずに
サロンに勧誘するための動画ばっかり作ってる印象。
サロンビジネス、ぼったくり情報商材屋多め
日本人YouTuberはプログラミングの解説動画はあまり作らずに
サロンに勧誘するための動画ばっかり作ってる印象。
サロンビジネス、ぼったくり情報商材屋多め
KENTA は、マナブの12万円のWordPress 教材を、情弱狙いだと批判してる
WordPressは低価格の請負だから、初心者がやるのは危険。
時間給じゃないから、どれだけ時間が掛かっても、5万円とか
WordPressぐらいなら、KENTAの千円のサロンで、誰かに聞けば十分。
最近は、高額の情弱ビジネスが横行しているから、まず、KENTAに聞くべき！
WordPressは低価格の請負だから、初心者がやるのは危険。
時間給じゃないから、どれだけ時間が掛かっても、5万円とか
WordPressぐらいなら、KENTAの千円のサロンで、誰かに聞けば十分。
最近は、高額の情弱ビジネスが横行しているから、まず、KENTAに聞くべき！
>>265
KENTAも情弱ビジネス
情弱相手のサロンビジネス屋
ネットで調べればわかるしサロンに入る必要がないのに
サロンにはいれば解決するかのように宣伝してるのは詐欺
初心者ばかり集まってるサロンで聞いてもろくな回答つかないだろｗ
スキルあるやつはそんなサロン入らないだから
KENTAも情弱ビジネス
情弱相手のサロンビジネス屋
ネットで調べればわかるしサロンに入る必要がないのに
サロンにはいれば解決するかのように宣伝してるのは詐欺
初心者ばかり集まってるサロンで聞いてもろくな回答つかないだろｗ
スキルあるやつはそんなサロン入らないだから
WordPressは単価悪いからやらん方がいいってところに関しては確かに同意だな
ちょっと聞きたいんだけど、
Gatsbyと(ヘッドレス)CMSを組み合わせた場合、静的なページが出力されるの？
つまりCMS上で更新した内容はGatsbyでビルドしないと反映されないのかどうかという事なんだけど。
Gatsbyと(ヘッドレス)CMSを組み合わせた場合、静的なページが出力されるの？
つまりCMS上で更新した内容はGatsbyでビルドしないと反映されないのかどうかという事なんだけど。
すまん教えて
クラスとクロージャってどう違うの？
クラスとクロージャってどう違うの？
>>269
まったく別物
クラスをちゃんと理解するにはC#とかの静的言語で
オブジェクト指向プログラミングを学ばないとだめ
動的言語だけやってると型の概念が身につかない
まずは静的言語の学習を
まったく別物
クラスをちゃんと理解するにはC#とかの静的言語で
オブジェクト指向プログラミングを学ばないとだめ
動的言語だけやってると型の概念が身につかない
まずは静的言語の学習を
>>271
数行で説明できる概念じゃない
オブジェクト指向は自分でプログラミングしないと見につかない
Java , C#の初級プログラマーが最初につまづくところだ
動的言語だけやってると初級から抜け出せない
静的言語を勉強しろってのが適切なアドバイスなわけ
数行で説明できる概念じゃない
オブジェクト指向は自分でプログラミングしないと見につかない
Java , C#の初級プログラマーが最初につまづくところだ
動的言語だけやってると初級から抜け出せない
静的言語を勉強しろってのが適切なアドバイスなわけ
>>272
いや、わかってない
静的言語でちゃんとコード書けないでしょ
クラスわかってたらそんな頓珍漢な質問は出てこない
いや、わかってない
静的言語でちゃんとコード書けないでしょ
クラスわかってたらそんな頓珍漢な質問は出てこない
C#おじさんまさかクロージャ知らんとは……
クロージャを知らない人がクラスだけ勉強したところでその違いがわかるわけないわな。
>>269
雑に言うと
クロージャは関数が外側の変数の参照を（外側の部分の実行が終わった後も含め）持ち続ける現象、かな。参照を持ってるから変数がGCされることも無い。
クラスとの違いは（比較対象では無いけど）……プライベート変数と機能は多少重複してるけど、出来た経緯が全然違うもの、かなぁ。
雑に言うと
クロージャは関数が外側の変数の参照を（外側の部分の実行が終わった後も含め）持ち続ける現象、かな。参照を持ってるから変数がGCされることも無い。
クラスとの違いは（比較対象では無いけど）……プライベート変数と機能は多少重複してるけど、出来た経緯が全然違うもの、かなぁ。
クロージャってPerlとかクラスがないというかまともなOOPの仕組みない言語がOOPするために使われてただけなんじゃない
今の時代クロージャーがないほうがOOP言語として未熟扱いだけどね
クロージャはLisp由来関数畑育ちで、OOPの出来損ないみたいなものじゃない。
まぁ、クロージャ何でもできるからそういう使われ方してて（Ecma3時代にプライベートメンバ作るとか）、そう思われても仕方ないとこあるけど……
まぁ、クロージャ何でもできるからそういう使われ方してて（Ecma3時代にプライベートメンバ作るとか）、そう思われても仕方ないとこあるけど……
OOPが出来損ないでは？
関数型になれなかった言語
関数型になれなかった言語
ほらね。レスするくせに反論しなかったｗ
ここがこいつの限界というわけ
ここがこいつの限界というわけ
>>282
その気持ちはわかるww
でもその言い方は「これだから関数型信者は」って虐められるから止めてよw
俺はOOPも好きだし
その気持ちはわかるww
でもその言い方は「これだから関数型信者は」って虐められるから止めてよw
俺はOOPも好きだし
>>277 >>270
じゃあ3行で説明してあげよう
https://en.wikipedia.org/wiki/Closure_(computer_programming)
じゃあ3行で説明してあげよう
https://en.wikipedia.org/wiki/Closure_(computer_programming)
やっぱり知らなかったｗｗ
wikipedia得意気に貼って恥ずかしい奴ｗｗｗ
wikipedia得意気に貼って恥ずかしい奴ｗｗｗ
クロージャなんて言語によって違いすぎるから
誰も数行で説明できない
存在しない言語もあるわけでね
やはり静的言語勉強しろっていうアドバイスが的確過ぎた
誰も数行で説明できない
存在しない言語もあるわけでね
やはり静的言語勉強しろっていうアドバイスが的確過ぎた
いやいや、違い過ぎるものを同じ言葉では呼ばないでしょ。よりにもよってWikipediaのURLなんてダサすぎる。
なんならあんたの好きなC#で説明すれば良かったのに
なんならあんたの好きなC#で説明すれば良かったのに
>>290
回答してくれてありがとう。
所謂JAMstackについて調べてたらmicroCMSとGatsbyの組み合わせについて書いてあったから、ちょっと混乱しちゃって。
回答してくれてありがとう。
所謂JAMstackについて調べてたらmicroCMSとGatsbyの組み合わせについて書いてあったから、ちょっと混乱しちゃって。
>>278
クラスもメソッド（≒クロージャの関数）がプライベートプロパティ（≒外側の変数）を参照できるからそこはクロージャと変わらんよね？
jsはprototypeとはいえクラス使えるからクロージャはもういらないってこと？
それとも今でもjsはクロージャを駆使するのが当たり前なのかな？
クラスもメソッド（≒クロージャの関数）がプライベートプロパティ（≒外側の変数）を参照できるからそこはクロージャと変わらんよね？
jsはprototypeとはいえクラス使えるからクロージャはもういらないってこと？
それとも今でもjsはクロージャを駆使するのが当たり前なのかな？
>>292
クラスがあればクロージャはいらないってのは間違ってないんだけど、
ちょっとしたコールバック関数を書くのにそれ用のクラス書いてるとクラスだらけになってめんどくさいよ。
逆に適当にクロージャを書いて変数のスコープの見通しが悪くなるときにはクラスにするし、
どっちにも無理やり使おうとすると使いづらい場合がある。
究極を言えばチューリング完全なら出来ること同じなんだし、
言語の機能はよくあるパターンを人間が書きやすく、そしてルールを覚えやすく作ってあるだけということになる
クラスがあればクロージャはいらないってのは間違ってないんだけど、
ちょっとしたコールバック関数を書くのにそれ用のクラス書いてるとクラスだらけになってめんどくさいよ。
逆に適当にクロージャを書いて変数のスコープの見通しが悪くなるときにはクラスにするし、
どっちにも無理やり使おうとすると使いづらい場合がある。
究極を言えばチューリング完全なら出来ること同じなんだし、
言語の機能はよくあるパターンを人間が書きやすく、そしてルールを覚えやすく作ってあるだけということになる
>>292
ある程度はその通りで、プライベートプロパティが使える現代のJS|TSではクロージャの役割は少し減った。
状態を持つならクラス書いたほうが意図が自明な場合があるからね。
でもクロージャ使った方が短く書けたり、意図がわかりやすいパターンもある（メモ化とか高階関数とか）。だからクロージャは今も使われてる。
ある程度はその通りで、プライベートプロパティが使える現代のJS|TSではクロージャの役割は少し減った。
状態を持つならクラス書いたほうが意図が自明な場合があるからね。
でもクロージャ使った方が短く書けたり、意図がわかりやすいパターンもある（メモ化とか高階関数とか）。だからクロージャは今も使われてる。
クロージャは、クラスと同じ。
メソッドf が、fの外のスコープにある、インスタンス変数@num にアクセスできるのと同じ
class A
def initialize ( num )
@num = num
end
def f
puts @num
end
end
a = A.new( 2 )
a.f #=> 2
メソッドf が、fの外のスコープにある、インスタンス変数@num にアクセスできるのと同じ
class A
def initialize ( num )
@num = num
end
def f
puts @num
end
end
a = A.new( 2 )
a.f #=> 2
クラスとクロージャーは全くの別物だよ。
同じことを処理として実現できるから同じ技術というのはおかしいよ。
https://qiita.com/pebblip/items/2ed30f59cd5981513908
↑これを読むと理解できるかも
同じことを処理として実現できるから同じ技術というのはおかしいよ。
https://qiita.com/pebblip/items/2ed30f59cd5981513908
↑これを読むと理解できるかも
お前ら技術力が無いと見下してきたおじさんズが全然技術力無いことを露呈した流れは正直面白かった
「バナナが欲しかったが、バナナを持ったゴリラを手に入れた」
ゴリラ＝クラス
元ネタはErlang作者であるJoe Armstrongの、
「オブジェクト指向言語の問題は、オブジェクト指向言語が持ち歩く暗黙の環境をすべて持っていることです。あなたはバナナが欲しかったのですが、あなたが手に入れたのはバナナを持ったゴリラが生活しているジャングル全体でした」
クラスがあるからクロージャは不要というのは、
バナナを簡単に食べられるという話に
ジャングルでも同じことができるから不要と言ってるに過ぎない
ゴリラ＝クラス
元ネタはErlang作者であるJoe Armstrongの、
「オブジェクト指向言語の問題は、オブジェクト指向言語が持ち歩く暗黙の環境をすべて持っていることです。あなたはバナナが欲しかったのですが、あなたが手に入れたのはバナナを持ったゴリラが生活しているジャングル全体でした」
クラスがあるからクロージャは不要というのは、
バナナを簡単に食べられるという話に
ジャングルでも同じことができるから不要と言ってるに過ぎない
>>299
たとえがアホすぎだね
ジャングル全体があるからバナナが収穫できる
バナナしかなければ食べたらおしまい
静的言語のが実行速度も速いし生産性も高い
大規模開発もできる
つまり上位互換
たとえがアホすぎだね
ジャングル全体があるからバナナが収穫できる
バナナしかなければ食べたらおしまい
静的言語のが実行速度も速いし生産性も高い
大規模開発もできる
つまり上位互換
バナナを食べるだけなのにジャングルの整備・バナナの収穫までその場で考えなければならない。
ゴリラの飼育、お嫁さんどうするかも考えないとｗ
ゴリラの飼育、お嫁さんどうするかも考えないとｗ
ゴリラの花嫁
何故この文脈で静的言語云々が出てくるのか。
静的言語って言いたいだけか
静的言語って言いたいだけか
JSに限らず動的言語は必要な機能が揃ってないからだ
例えばevalすらできない
クロージャの話にどうして静的言語云々が出てるんですかねぇ
初期のJavaは酷かった。
イベントハンドラ登録するだけなのにイベントリスナーのクラス作らないといけなかった。
「む、無名クラスでインラインでも書けるから！」とか。アホかと。
今ではみんなラムダ関数使ってまーすｗ
だーれもクラス使ってないでーすｗｗｗ
イベントハンドラ登録するだけなのにイベントリスナーのクラス作らないといけなかった。
「む、無名クラスでインラインでも書けるから！」とか。アホかと。
今ではみんなラムダ関数使ってまーすｗ
だーれもクラス使ってないでーすｗｗｗ
確かに以前のJavaはクロージャどころか関数ポインタ（的なもの）すら無くて辛い言語だったなぁ。
個人的にはJS|TSでクラス使う場面って、
・状態を持つオブジェクトを扱う時
・継承を使う時（WebComponents等）
くらいだと思ってる。
個人的にはJS|TSでクラス使う場面って、
・状態を持つオブジェクトを扱う時
・継承を使う時（WebComponents等）
くらいだと思ってる。
>>307
まああのシンプルさが勉強には良かったけどね。
仕事で使いたくはないけど。
なぜクロージャーが便利なのかということも身を持って知れるし。
まああのシンプルさが勉強には良かったけどね。
仕事で使いたくはないけど。
なぜクロージャーが便利なのかということも身を持って知れるし。
Javaに失望したらC#にいけばいいのに
なぜさらに不便なJSなのか
なぜさらに不便なJSなのか
webの開発では圧倒的にクロージャーを使うことが多いよ。
あるリストがあって、その中の一つの要素をクリック時に削除するなどの処理を書く場合は自然とクロージャー使うしね
あるリストがあって、その中の一つの要素をクリック時に削除するなどの処理を書く場合は自然とクロージャー使うしね
elm.AddEventListener(function() { ・・・}) を使うな
function handler() { ・・・}
elm.AddEventListener(handler) を使え派は
どこ行ったんだろうねｗ
前者はクロージャーだから循環参照を引き起こして
メモリリークのバグになる可能性があるから
後者を使えっていうのが昔は多かったんだが
もっともjQueryは後者の書き方をしても循環参照にならない
仕組みなので問題なかったんだが
（要素に直接イベントハンドラ関数を割り当てるのではなくjQueryの内部的な
イベントハンドラを管理するオブジェクト経由で間接的に参照するので
循環参照にならない仕組みでブラウザのメモリ管理のバグを回避していた）
function handler() { ・・・}
elm.AddEventListener(handler) を使え派は
どこ行ったんだろうねｗ
前者はクロージャーだから循環参照を引き起こして
メモリリークのバグになる可能性があるから
後者を使えっていうのが昔は多かったんだが
もっともjQueryは後者の書き方をしても循環参照にならない
仕組みなので問題なかったんだが
（要素に直接イベントハンドラ関数を割り当てるのではなくjQueryの内部的な
イベントハンドラを管理するオブジェクト経由で間接的に参照するので
循環参照にならない仕組みでブラウザのメモリ管理のバグを回避していた）
クロージャ使い倒してるけど循環参照してメモリリークなんて一度もなった事無いから、普段全く意識してないなぁ。
TS使ってて他に劣ってるとは全然思わない。あ、ジェネリック周りが複雑過ぎるとは時々思うw
TS使ってて他に劣ってるとは全然思わない。あ、ジェネリック周りが複雑過ぎるとは時々思うw
next.jsって本がないのが辛い。Gatsbyですらあるのに。どこ見て勉強するとええんやろ。公式をGoogle翻訳？
英語できない人がそんなマイナーフレームワーク使ってはいけない
翻訳なんてつかうからいつまでたっても英語が上達しない
本は情報が常に古い
英語のドキュメントとソースコードでしょ
あとはYouTubeの英語
翻訳なんてつかうからいつまでたっても英語が上達しない
本は情報が常に古い
英語のドキュメントとソースコードでしょ
あとはYouTubeの英語
>>313
俺は世代的にこの問題を意識したことないけど、eventをちゃんとremoveすれば良いって話だよね？
俺は世代的にこの問題を意識したことないけど、eventをちゃんとremoveすれば良いって話だよね？
>>317
ブラウザバックや進む、リロード時に
eventをremoveするように作らないといかんわけや
とうぜんブラウザバック時にイベントなんて起きないでｗ
ブラウザバックや進む、リロード時に
eventをremoveするように作らないといかんわけや
とうぜんブラウザバック時にイベントなんて起きないでｗ
そう言えば、jQuery では、DOM の削除時にも、イベントも削除してくれるのだっけ？
リロードしてもリソース開放されんってそんな時代あったんか……
リロードワロタｗｗｗ
お里が知れるなｗｗｗｗ
お里が知れるなｗｗｗｗ
Chromeだとリロードボタンの右クリックにキャッシュを飛ばしてリロードするかどうかの選択あるけどね
web component流行ってくれ
自作ソフトをWeb Componentsで作り直そうかと思ってるが
特にメリットがないし、二の足を踏んでいる。
特にメリットがないし、二の足を踏んでいる。
web components は spaとかを作るには向いてないけどある程度静的なものを作るなら向いてると思うで。
templateとかにlit htmlとか使うの前提だけどね
templateとかにlit htmlとか使うの前提だけどね
lit-html知らなかったわ。面白いなこれ。
ガチンコなアプリでは物足りない感じだけど、既存のものにもさくっと差し込めそう
ガチンコなアプリでは物足りない感じだけど、既存のものにもさくっと差し込めそう
おもろいで
lit elementもおもろいで
lit elementもおもろいで
https://www.statista.com/statistics/1124699/worldwide-developer-survey-most-used-frameworks-web/
https://trends.google.com/trends/explore?geo=US&;q=%2Fm%2F012l1vxv,%2Fm%2F02_qnn,%2Fm%2F06y_qx,%2Fg%2F11c6w0ddw9,%2Fm%2F0dhx5b
上の方に ASP.NET のマーケットシェアが１位って記事があったから載せてみるね
ネット上のマーケットシェアのサイトってソース載ってないのも
どうやって調べてるかわからないものも多いよね
https://trends.google.com/trends/explore?geo=US&;q=%2Fm%2F012l1vxv,%2Fm%2F02_qnn,%2Fm%2F06y_qx,%2Fg%2F11c6w0ddw9,%2Fm%2F0dhx5b
上の方に ASP.NET のマーケットシェアが１位って記事があったから載せてみるね
ネット上のマーケットシェアのサイトってソース載ってないのも
どうやって調べてるかわからないものも多いよね
上の方で、ページリロードでリスナーが解放されるかって話
バカにせずに真面目に考えてみます
基本的に、ページリロードで VM のヒープもスタックも全部リセットされるので
普通に考えればメモリリークなんてものはない
Chrome とかはVMどころかページ毎にプロセスまるごと作り直しみたいな話になるので、
メモリリークの可能性は低い
キャッシュというのは、JS/HTML/CSS のソースコードのキャッシュをメモリ上とか
データベースに保存してるってことよね、メモリ解放の話とは関係ない
JIT コンパイラのコードキャッシュとかに関しては、プロセス間で共有してるのかは知らない
まぁでも、これもリスナーのメモリ解放の話とは関係ない
Ref :
https://stackoverflow.com/questions/28896028/do-javascript-memory-leaks-matter-after-a-page-refresh-why
バカにせずに真面目に考えてみます
基本的に、ページリロードで VM のヒープもスタックも全部リセットされるので
普通に考えればメモリリークなんてものはない
Chrome とかはVMどころかページ毎にプロセスまるごと作り直しみたいな話になるので、
メモリリークの可能性は低い
キャッシュというのは、JS/HTML/CSS のソースコードのキャッシュをメモリ上とか
データベースに保存してるってことよね、メモリ解放の話とは関係ない
JIT コンパイラのコードキャッシュとかに関しては、プロセス間で共有してるのかは知らない
まぁでも、これもリスナーのメモリ解放の話とは関係ない
Ref :
https://stackoverflow.com/questions/28896028/do-javascript-memory-leaks-matter-after-a-page-refresh-why
は？一生懸命書いたのに、くっそ昔のスレじゃん
泣きたい
泣きたい
泣かないで。
きっとこれからこのスレを読む誰かの為になるよ
きっとこれからこのスレを読む誰かの為になるよ
>>47
Pythonは言語仕様に問題が有り過ぎてwasmへの変換は不可能と決着済
仕方ないのでPythonインタプリタをwasmへ変換して動かしてる
結果JavaScriptより数十倍も遅いため使い物になっていない
Pythonは言語仕様に問題が有り過ぎてwasmへの変換は不可能と決着済
仕方ないのでPythonインタプリタをwasmへ変換して動かしてる
結果JavaScriptより数十倍も遅いため使い物になっていない
フロントエンド改修するのにReactかVue3で迷ってる
世の流れ的にいくならReactにしない理由はないと思うんだけどなんか好きになれんのよな
Vueはテンプレートの構文がわかりやすくて好きなんだけど、結局typescriptとの親和性の観点でtsxで書く流れになってきてるから、tsx使うならReactでよくねとも思う
Reactだと依存配列書き忘れとかも以外とやりがちで、Vueはcomputedがその辺全部いい感じにやってくれるから自分的な差はそこくらいかなあ
なんかここで選べみたいなのあります？
世の流れ的にいくならReactにしない理由はないと思うんだけどなんか好きになれんのよな
Vueはテンプレートの構文がわかりやすくて好きなんだけど、結局typescriptとの親和性の観点でtsxで書く流れになってきてるから、tsx使うならReactでよくねとも思う
Reactだと依存配列書き忘れとかも以外とやりがちで、Vueはcomputedがその辺全部いい感じにやってくれるから自分的な差はそこくらいかなあ
なんかここで選べみたいなのあります？
は？一生懸命書いたのに、くっそ昔のスレじゃん
泣きたい
泣きたい
泣いてもええんやで
板がわかれすぎて全然人いないよね
Reactを使いたけど、jsの言語仕様が変態すぎて辛い
jsはチュートリアルさらりと読んだら、理解が曖昧でも
そのままフレームワークの使い方を覚える段階に進んだ方がいいのかな？
言語仕様がぐちゃぐちゃでベストプラクティスを想像できない
jsはチュートリアルさらりと読んだら、理解が曖昧でも
そのままフレームワークの使い方を覚える段階に進んだ方がいいのかな？
言語仕様がぐちゃぐちゃでベストプラクティスを想像できない
さらに Rect へSvelte とvue をまぶしたようなSolid.jsなるものまであるな
https://www.solidjs.com/
https://www.solidjs.com/
ベンダーじゃなくて発注側なんやけど、Javaができて便利なことある？
例えばベンダー側で実際Javaのプログラム書いたり開発した経験が無くても、発注側で極簡単な改修なら自前でできたり、改修や開発の設計書を読めるようになるぐらいならできるもん？
例えばベンダー側で実際Javaのプログラム書いたり開発した経験が無くても、発注側で極簡単な改修なら自前でできたり、改修や開発の設計書を読めるようになるぐらいならできるもん？
色々変な仕様くっつきすぎてとっつきにくくなり、素のJSに戻ることになるでしょう
フロントエンドをスレタイに入れなければもっと伸びたはず
