フロントエンドJavaScriptフレームワーク総合
■ このスレッドは過去ログ倉庫に格納されています
2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net https://medaka.5ch.net/test/read.cgi/prog/1485008061/ あれから三年後、jQueryのシェアは75.5%にまで成長 >>3 そっちはVue vs React vs Angular限定 ここはフロントエンドで使われるJavaScript全般 つまりサーバーサイドで使われるもの以外 ブラウザで動くものは全て対象 Backboneとかあったよなぁ どうしてどれも長続きしないんだろうね >>9 開発者がメンテナンスにあきてしまう 他のフレームワークが人気になるとそうなる 大手IT企業が関与してないVueとかはそうなるかもね >>5 >ここはフロントエンドで使われるJavaScript全般 スレタイ読めないのか >>14 4年ぐらい前から同じようなことを聞いてる bootstrap5がjqueryはゴミでしたって結論づけました フロントエンド開発ツールとブラウザサポートの進歩により、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が入っていれば便利メソッドが使える >>15 いやいや依存ライブラリから除外したのは今回のリリースが初やろ Ruby on Rails 6, Bootstrap 4 では、 yarn add bootstrap jquery popper.js Jquery に依存しなくなっても、Popper.js への依存は、どうなる? >>18 公式ではそうだけど思想としてはBootstrap for Native JavaScriptってのは大分前からあったな >>19 Popperは依存というよりほぼIEをサポートするためのもんだろ まぁそもそもjQueryが流行りだした頃ってHTML4.01時代で素のJavaScriptがメチャクチャ貧弱だったけど HTML5世代になってから相当APIとか充実したからネイティブのJavaScriptに置き換えたとしてもそこまでコードが肥大するってわけでもないしな 次はwordpressだ!これがデフォルトでフロントエンドにjquery差し込むもんだからjqueryのシェアがイマイチ下がらない諸悪の根源 >>23 Webサイトはそれでいいだろ フレームワークが必要になるのはWebシステムなんだから まぁWordPressよりもWixの方がいいだろ感はあるけど >>10 それは「飽きる」とは言わない。 「撤退する」だ。 >>26 創始者のプロジェクトからの離脱の前に その前段階として飽きとか情熱が落ちるというのがあるのよ >>27 アイデアからして全然違うフレームワークの方が圧倒的人気を持った場合、 自分のフレームワークのプロジェクトを閉じるのは当然で、情熱がなくなるのも 当然。 人気を出すためには、人気の有るフレームワークに近づける必要が有るわけで、 自分の路線でそのまま行っても人気が出る可能性は薄い。 また、本人も最大人気のフレームワークに比べて何らかの点で劣っている事が 分かっているはずで、自分のフレームワークを成長させていってもジリ貧である ことがわかっているから、情熱を失う。 別のフレームワークじゃなくJavaScriptの最新の傾向なんだけどね それをいち早く取り入れたかどうかの違いで >>29 Vue, React, Angular, Razorの違いって、そういうことじゃなくて、設計指針やアイデアの違い。 そして、結果的にVueが最も人気が有る。 新しいことを取り入れたかどうかではない。 >>30 いや、上で言われてるのはVue.jsがReactに寄ったって話だろ 確認だけど、最大人気は Vue が持っているんだよね。 後は、廃れている可能性が高くて。 VueはWebサイトでも使われてる事例が多いから相対的にシェアは大きいかもな いや確かVueが一番人気なのは中国と日本とあともうひとつ変な国だけだったはず >>34 vueは、githubの全プロジェクトの中で、ドキュメント(説明文のみ)部門を除いては一位の人気を誇る。 最新のstateofjs フロントエンドフレームワークの項 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/init@0.2.2 バックエンドフレームワークでフロントのビルド環境が整ってるやつ使えばイチイチ気にする必要もないけどな 自分はLaravel使ってるがRoRでもv6から対応してるんだとか >>39 anyenvとかの、本質的な管理(npm)の間に何層も便利レイヤーが入ってて、うまく動くときにツールがすごいだけなのに分かった気になって自分がすごいと調子に乗ってるからそうなる 結局そのプラットフォームで手広く使われてる管理方法をちゃんと理解しておかないと、 トラブったときに何が原因なのか切り分けられないから、 パッケージのバージョン違いのトラブル程度が「酷い目」に感じられるんだよ Rails: webpack(er)に乗り換える25の理由(翻訳) https://techracho.bpsinc.jp/hachi8833/2020_04_10/90859 Rails 5 から、webpack を使えたけど、 標準になったのは、Rails 6 から LaravelだとLaravelMixというwebpackの設定が簡単に書けるものがあるから vueも割と簡単に導入できるな >>46 既にPython がwasm で動いてる。 データサイエンス部門はPython only になりそうだな。 当然Javascript の機能も使える。 Vueのプロジェクト新しく始めるときにVue-Cliって使ったほうがいいのかねえ なんか裏側で何が起こってるのかよく分からなくなるから、個人的にはwebpackの設定ゴリゴリ書きたいんだけど、主流がvue-cliみたいだから無理やり使ってる laravel mixとかもそうだけどwebpackをブラックボックスにしたツールあんま好きになれない 前スレ >>986 書いたのぼくなんだけど、 いや決してblazor最高!って言ってるわけではない。 次に使う技術を選考するにあたって、 他のWebフレームワークでもおなじようなことができるのか純粋に聞きたかっただけ… とにかくフロントとバックで言語を合わせたらできるということがわかった。ありがとう。 バックエンドをtsとc#のどっちがいいかは、両方使ったことがある人にしか判断つかなさそうね。 で、なかなかそういう人はいなさそう。 たぶんMS推しまくってる人もそうだと思う… >>50 単純に言語としての良し悪しならC#とTSは甲乙付けがたい。カッチリしたC#か、より柔軟なTSか。どちらも優れた言語だ。 バックエンドのエコシステムとして見たら……いろんな視点があるからなんとも >>50 backendははっきりしてる。C#のがts(node)よりいい 実行速度がレベルが違う backendは生産性考えたら静的言語以外は使いたくないわ C#のように言語が強力だと何をやるにも楽だわ 普通のweb appでサーバーの実行速度がボトルネックになることはほぼねーよ。 いやふつうに速度落ちるし どんだけ過疎サイト作ってるのさ 落ちなきゃいいとかいう低レベルなのでいいわけ? サクサクにしないとリピーター増えないわけよ >>55 54もtsと比較してるしC#だけじゃない JSありきで思考停止していてはだめ それは宗教 >>54 いやあなためちゃくちゃjs,tsディスってるけど、 経験はあるの? そういう頭ごなしに否定する意見はあまり信用できない。 >>61 そりゃあるよ C#に比べたら動的言語は全部ゴミ 動的言語は生産性低いわ遅いわで最悪 AndroidもiOSも開発は静的言語だろ? 個人的な感想じゃなくて事実なの JS, TSをディスってるのではない 動的言語、スクリプト全般がダメという話 MS, Google, Appleの一押し言語は全部、静的だろう JSだけ取り残された化石なんだよ ぶっちゃけVSとc#はマジで最強 これは否定できない しかしWebシステムではまったく使われていない どうしようもないほどゴミクズな存在 普及しそうな気配もない Web開発はjsから入る。 そこからtsに行くことはあっても c#に行くことはないわな ・老害は自説を曲げない ・老害は沸点が低い・怒りっぽい ・自分の価値観を押し付けてくる ・老害は話が長い、くどい 見事に老害の枠に収まってて草 https://docoic.com/9265 >>67 js, tsしかやらないっていうのは 静的言語わからないエンジニアのままでいるってことだな C#やらなければwindows appもasp.netも使えない。 静的言語の理解がないのでAndroid , iOS appも開発できない エンジニアとしてはかなり格下 GCのある言語なんて軟弱、CやRustやれ。 コンパイル言語なんて軟弱、アセンブリやれ。 とかいくらでも言いようはあるわけで。C#の殻に籠もってればいいのに >>66 Wappalyzerに検知されるバックグランドテクノロジーってサーバーの構成に問題あると思う たまにPHP5.4とかMySQLとかが検知されてるの見た事あるけど 実際JS,TSしかできません、やりませんって人も多いんだろうね でもプログラミング言語ってそんなもんだよね 日本語で生きていけるのに、英語学べ!って言われてもはあ…ってかんじだよ いろんな言語を貪欲に習得する人はすげーなとおもう >>66 日本は2%じゃん つまり42%✕2%でたったの0.8%なのになんでこいつ嘘ついてんの? >>69 実際のwebから収集されてるデータだぞ 信頼性が高い >>74 tsやっててtsしかできん人は流石におらんのやない? >>75 全世界のデータが意味ないとでも? 掛け算して意味不明な値だしてるし頭悪すぎて草 %の使い方すらわからないことに驚き webpackのビルド設定かなんかで専用のdevtoolには検知されてもWappalyzerでは検知されない事多々あるんだよな TSやってる人は他の言語の経験それなりにあって、 Electronベースの結構複雑なソフト(それこそvscodeとか)を作ってるからTSを使ってる印象あるけどな 今風のイケてるプログラマーだと思うけど てかそもそも言語は大事じゃないでしょ。職業プログラマーだったら色々な言語書くことになるでしょ。 >>80 寧ろ職業プログラマは仕事で使う言語しか覚えないからJavaしかできないってヤツとか相当多い >>80 frontendはJSしかできない奴多いよ 受託開発ならいろんな言語やらされるだろうが そういう企業ばかりではないし web appなら言語変わるのはbackendだろう。 next.js10の最適化凄いな。こういう変化の速さはさすがだわ >>78 オメーがバカなんだろ aspのシェアが42%でasp全体で日本は2ぱーなんだからフレームワーク全体だと掛け算だろが 小学生以下のアホがバカを晒して自慢すんな >>84 IT後進国の日本だけのシェアなどまったく意味がないし そもそもそのそのデータの国別、言語別の統計はあてにならない ということに気付かない時点で無能だわ ほかのframeworkでもアメリカが50%超えてる時点で気付けないんだな アメリカはコスパいいレンタルサーバー、データセンター、クラウドサービスが 多いからアメリカがシェアが高くなっているだけの話だ それはIPアドレスで判定してるだけ アメリカのデータ値はアメリカ人がアメリカ国内で使っていることを表しているわけではない >>85 じゃあwappalyzerのザル統計なんか晒すなボケ 選好バイアスというやつだね。 自分に都合のよい結果を出す情報源をより信頼してしまう。 >>88 そう思うならほかの統計データ出してくれ 信頼できそうなやつな 一般の法人ならASP.NET系使うのはごくふつうのこと サポート期限が長いしMSの技術と品質が信頼されてる >>82 だからそういう人は絶対tsには手を出さないしwebpackビルドなんてしないだろ 少なくともLaravel-MixでビルドしたものはWappalyzerに検知されないしAmazonで部分的に使われてるReactもWappalyzerには検知されてないからな ★jQuery, Ruby, C#, Blazorキチガイが書き込んでも無視してください thread.context.langs // => ["js", "ts", "html", "css", "rust"] >>90 さっぱり意味が分からない ASP.net CoreはLinuxでも動くの知らない人? あとクラウド=Linuxだと思ってるの? ★jQuery, Ruby, C#, Blazorキチガイが書き込んでも無視してください LinuxでわざわざASPを使いたがるヤツなんて明らかに異端だろ 猫も杓子も、AWS Amazon Linux, Aurora の時代に、 ASP, Windows Server, Azure とか、使う理由がない もう新規で使われることはない。保守だけ >>96 コピペ荒らしうざい >>97 偏見そのもの 知識がふるいんだよ ASP.NET CoreはLinux対応だしライセンスフリーだしLinuxで使ってる人多い >>99 こいつもASP.net CoreがLinuxで動くこと知らない フロントエンジニアは無知ばっかりだな Azureで業績好調だし >>99 AzureはAWSについでシェア2位だよ Windowsの比率はわからんけど選ばないということはない 少なくとも業務アプリ系では新規でも使われている。 ここにいる人たちってスレタイの技術使ってどんな規模のWebアプリ作ってるのかな。 それによっても使うクラウドサービスとか変わるんだろうね。 例えばFirestoreは複雑且つ大量データを扱う業務アプリ系では無理と感じた。 >>100 逆、逆 ASPを使ってる人の中でLinuxを使ってる人が多いかどうかじゃなく Linuxを使ってる人の中でASPを使ってる人が多いかどうかの話だよ >>103 おまえの思考が逆 Web appはまず開発ツールのスタックを選んでから、OSは決める server sideに関してはWindowsでしか動かないものよりも Linuxでしか動かないものが多いからLinuxを選ぶケースが増える >Linuxを使ってる人の中でASPを使ってる人が多いかどうか 自分で優れている開発ツールを選び使うだけ いくら多くの他人が動的言語のゴミ使おうが関係ない PHPもRubyも遅いし生産性が低いし選ぶ価値がない >>102 Firestoreは大量のデータを素早く裁くのはむしろ向いてると思うよ。複雑さの意味合いにもよるけど、向き不向きははっきりしてるよね。 IoTと組み合わせたWebでのリアルタイム監視的なものとか色々作ってるよ。Reactはまだ使い始めたとこだけど作りやすくて良いよね。用途によってクラウドも物理サーバも使い分けるよ。 >>103 おまえらが知らないだけで ライセンス無料になったからASP.NET Core始めた人がたくさんいるわけ >>105 RDB脳なんでいまいち想像できないんだけど Firestoreってログデータみたいな構造化されてないデータには向いてるとおもうけど、 商品マスタと10年間の売上データを結合して、商品マスタのなんちゃら区分ごとに集計するって言い出したら用途合わないよね…? Amazon Linux, Aurora なら、数倍速くなる。 Lambda もある GCP には、Tensorflow, Firebase がある Azure には、セールスポイントが無い Windows Server が落ち目だろ。 新規で、Windows Server を選ぶ香具師は、いない。保守だけ NoSQL は、銀行などの正確なものには向かない。 重複更新されたりするだろ 間違っても、問題がないような用途だけ RDB みたいな表分割も出来ない 転職サイトでBlazor案件検索してみたが全然ヒットしないぞ >>108 コレクションの組み方次第で可能。 でも可能だというだけで、そういうのは正直向いてないね。素直にRDB使いたい。 >>111 BlazorはASP.NETの中のひとつでしかないから 求人とかはASP.NET(Core)として扱われるだろう まだ件数としてはBlazorより前のASP.NET MVCとかの方がはるかに多い >>109 数倍とかいいかげんすぎる オンプレミスで開発、運用するスキルがないから性能に大きな差が出る Firestore高すぎだろう 月間アクティブ100万ユーザーで月額30万円近くかかる。 年間360万円 いいカモになってるな >>113 いやキーワード検索なら普通にフレームワーク名は出るぞ >>115 妥当な気がするけど 他のが全然安くすむもん? 安さなら、AWS Lambda などのサーバーレス >>116 求人ならふつうは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とか使えばいい 時代はクラウドみたいな宣伝に洗脳されてカモになるのが 流行ってるのが理解できない 月間100万アクティブユーザをタダ同然しかコストかけないオンプレミスは怖くない? Firebaseから乗り換えるにしても、高可用性なVPSか、しっかりコストかけて鯖組むよ >>119 Redux、Webpackってキーワードですら普通にヒットするのに本当に使われてるなら出ないわけないだろ >>123 Blazor単体ではシェア少ないと書いただろ あとBlazor Serverの社内システムとかは外部の統計にでてこない 他人ばかりきになるなら クソみたいなPHPとかRubyやってりゃいいじゃん みんなと同じことやって安心したいんでしょ MSがWebFormの移行先にBlazorを挙げている。 何年か経ったらSIerが使い出すんじゃない? 業務系はクラサバ時代に作られためちゃくちゃ複雑な画面があったりするから、簡単にSPAが作れるならBlazorは歓迎されると思う。 >>122 ハードのコストはトラフィックやデータ量に依存するから書いてないだけで サーバーは当然、用意するよ Cloudに比べたらタダ同然ってこと VPSとかしょぼすぎて無理 せっかくオンプレミスでやるのにサーバー借りるとかバカらしい 乗り換えるならそもそも独自仕様のFirebaseなんか使わないほうがいい トラフィック増えたらひたすらカモられるのがクラウド >>125 日本はUIの注文が細かいからな WPFもCore対応したようだから法人はWPFもありかもしれない 開発スピードはBlazorより速いしUXも良いはずだ ★jQuery, Ruby, C#, Blazorキチガイが書き込んでも無視してください。 ここはJSのスレです。 前にASP.net MVCの案件したけど、使いやすかったね PHPはLaravelがデファクトスタンダードになってるけど、あれASP.net MVCを真似て作ってる Winows Server+SQL Serverな環境だとVS上で完結して開発できるのもメリット大きいと思った マイクロソフトのサイトちょっと前はNuxt使ってた記憶あるけどな >>127 いや要件上Webアプリにしたいのに開発スピードが早いからと言ってWPFするのは違う… ただ、業務アプリとなると複雑度の違いはあれど画面数が100超えたりするので生産性はとても大事。 簡単な画面はサクサク作れても、複雑な画面になると一気にややこしくなるようなフレームワークだとつらい。 Reactとかってこういう大規模な業務アプリにはどうなんかね。 メンテナンス性も含めて気になる。ころころフレームワークがバージョンアップすると維持も大変だし。 >>133 .NET CoreのWPFでMac, Linuxも対応してクロスプラットフォームに なったから、そもそもWeb appにする必要がないケースも多いんじゃないかってことだよ Mobileから使う社員にはwin tabletやPCから使わせればいいわけで。 開発コストの増大、UXの低下とかのWeb appのデメリットが無視されすぎてる >>133 後半、Reactの代替こそBlazorでしょ 開発のコストも時間もReactより大幅に抑えられる Blazorならバージョンアップのコストも小さい WPFのMac/Linux版とかBlazorみたいな新しい茨の道進むよりははるかに情報も技術者も豊富なReactでWebにした方がずっと素直では…… >>136 そんな考えだから日本は生産性が低くなるんだろう。 Blazorでどれだけ楽になるか、コスト下がるかわかったら Reactなんてあほらしくて使ってられないと思うが 日本人はまわりに合わせると言われてるからどうしようもないな、いつも遅い 実際はReact続ける方がコスト的にいばらの道だ そうやってフレームワーク争いしていればいいんじゃね?w 世界は相変わらずjQueryを使っている 無駄に複雑化してまでレガシーに拘ってる人が生産性を語るのか…… スレタイ見えないのか? アメリカに行って「中国語はいいですよ!」って布教してこいよ >>134 ネイティブアプリは必ず配布の問題が出てくる。 数十人ならともかく、千人規模になると運用つらいよ。 トレードオフの話で、生産性が少々落ちたとしても配布の手間をなくすためにWebアプリにする。 あとReactってそんなに生産性悪いのか? じゃあなんで全世界でこんなに使われてるの? 世界各国に行って「日本はいい国ですよ!」って言ったら 反対するのは特定の地域だけだろうな > あとReactってそんなに生産性悪いのか? > じゃあなんで全世界でこんなに使われてるの? そもそも使われてないでしょ? あと「この道具は世界で一番使われてる。だから生産性が高いに違いない」 なんて言ったら笑われるよ 使われるかどうかなんてマーケティング能力の問題だからね >>140 複雑化ってなんのことだ? UIをドロップして最速で作れるのはWPFとかだろ >>134 WPFはクロスプラットフォーム対応してねーだろあほ >>142 またその話か インフラ側の知識が足りない。 アプリなんてグループポリシーで一括インストールできるし 他のシステム管理ツールでも管理できる まともな企業なら無断で禁止アプリ使われないようなんらかの ツールで管理してる .NET CoreのWPFは単一のexeになるしdeployはコピーするだけだからさらに簡単になる。 single exeは.NET5だったからかもしれないがいづれにしもdeployはまったく問題ない そのお着せのUIで事足りるならね・・・ 実際にはある程度のカスタマイズが必要で いろんなことができる割にやり方が複雑だったりする 結果フレームワークの使い方に振り回されることになる >>146 .NET CoreのWPFはクロスプラットフォーム対応だ Linux、Mac対応 >>142 後半 ブラウザ内で使える言語がJSだけだったからだ。過去形 Blazor wasmなどのWeb Assemblyが実用化してJS縛りがなくなった。 生産性の低いJSを使う必要性がなくなった。 未だにIEが要件に挙がるジャップランドでwasmなんて使えるの? 正直wasmで作るアプリは 「ブラウザで動かす必要はない」 >>147 え、じゃあ企業内で使うアプリは全てネイティブでやれってこと? 大抵の企業ってまずグループウェアがあってそこからシングルサインオンで各業務Webアプリに遷移するのが一般的だとおもうんだけど… WPF、いいフレームワークだしOSS化したのは知ってるけど、それこそあまり使われてない印象。 多数の人に使われている技術は、知見が沢山あるのと、技術者を集めやすいメリットがある。 WPFは俺の会社の範囲内では100%使われてる だから世界でも使われてるはずだ とかいうやつやろw デスクトップアプリは実績豊富なElectronでいいじゃん 正直ぽとペタで作れるのは見た目だけで 処理ではないので、あまり意義を感じられんのだよな >>151 環境を限定できる業務アプリでIE縛りなんてないだろ、ナンセンス あとなかなかIEやめないやつ対策で IE開こうとするとEdgeが開くようにMSが変更するらしい そこまでMSがやってるんだから開発者もIEを使わせないように努力するべき >>157 新規開発ばかりだと思ってんのか? アホだな 環境を限定できるから、何年も前にIE縛りにして IE縛りのアプリが残ってるから変更できないんだよ しかたないからまたIE縛りでアプリを作る >>153 全てなんて言ってないだろう SPから使う必要があるならWPFは選択肢から外さざるを得ない WPFがベストなシステムでも必要もなくWeb appにしてる企業が多すぎるということ 外部企業に作らせていてその会社がWeb appしか作れないんだろう >>153-154 WPFはdesktop appでナンバーワン。 実績がなければ.NET Core対応したりしない >>155 Electron、生産性が低い >>156 Web appで時間かかってるのUIだろう。WPFはそこのコスト大幅に削れる > 実績がなければ.NET Core対応したりしない 実績がなくても.NET Core対応とかするやろ DelphiとかCOBOLLとか >>160 しかたないからまたIE縛りでアプリを作る? それただの馬鹿な企業だろw 依頼するほうも要件丸のみして開発するほうも両方バカ IEはセキュリティ低いしもう終わるのでやめましょうと言えないのは無能 そのうち消えるIEに合わせて作ったらIE終了時で大問題になる >>165 客がそれを望んでるのだからしょうがない IE終了なら、その時は作り直しですねーって金を取るからいい それを渋るなら、その会社はいつまでも古いものを使うってだけだ 未だにフロッピーディスクを使っている会社とかよくある話 >>166 カネさえ貰えればクライアントがどうなろうといったこっちゃないってことか 意識低い系 >>167 プロである以上。ただで仕事はしないんでね IE前提の開発を続けることの危険性を クライアントに伝えられないならプロではない 意識低い系 レベル低い >>171 WPFのプラットフォームは撤回する。調べたらフェイク情報だった .NET MAUIでiOS, Andoroid対応するからそれに期待する その方面での人気はReactに大きく水を開けられてますね。 GitHub stars React-native 91k MAUI 4.9k ちなみに元になったXamarinも似たような数字なので、新しいから星が少ないわけでは無い模様。 それはまぁそうだ。でもなんの根拠もない主観帯な意見よりは役に立つ GitHub Starは1000超えてるかどうか2値くらいの価値しかない >>162 オメーんのこと大好きなMSがVSCodeをElectronで作ってるんですけど? なんなら React Native for Windows もMSが開発してる >>179 俺は信者じゃないしMySQLとかをよく使う C#, ASP.NETは良いものだから使っているだけ Electronのアドバンテージなんかあるか?低速だろ React Nativeも下火だぞ >>115 >月間アクティブ100万ユーザーで、月額30万円近くかかる YouTube で月千円の会員なら、月10億円になる。 月30万円って、一人0.3円か? >>120 >オンプレミスでMySQL, Postgreとか使えば、維持費はタダ同然 OS, ミドルウェアのバージョンアップとか、AWS が保証するから安全 月間アクティブ100万人って規模なら たった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. 彼の言うことは間違っているか主観的で偏見に満ちているという事か https://ja.wikipedia.org/wiki/.NET_Core 「.NET Core 3.0では、Windows版に限りWindows FormsおよびWPFのサポートが 提供されるようになった」 どこの板行ってもみんなに迷惑かけて嫌われてるな、ドザはwww ソフトウェア開発の場合はMacやLinuxを使うユーザーも大量にいるけど、一般的なビジネスソフトの場合は無視できるレベル 実際MacはまだしもLinux向けのビジネスソフトなんかほとんどないわけだし まぁね。俺はデスクトップLinuxユーザだけど、それは俺が開発者でしかもLinuxが好きだからだ。 Electron、マルチウィンドウとか高度なUIだとネイティブのGUIには敵わないなという印象 VSと比べると、VSCodeはタブウィンドウの動作が不自然でマルチモニター環境だと使い勝手が大きく劣る 単純に重いというのもあるし ★jQuery, Ruby, C#, Blazorキチガイが書き込んでも無視してください 「クロスプラットフォームできる!」 ↓ できませんでしたww ↓ 「クロスプラットフォームなど不要!ウィンドウズだけで十分!」 自分ができないことを必要ないと強弁するのがRubyコミュニティとソックリwww 生産性の違いをまじで知りたいんだけど… 彼以外に両方やってる人はいない…? BlazorよりReactのほうが生産性高いわい!という声がない。 >>193 いやたぶんC#側にバカにされたRuby野郎の成れの果てやろ。普通にC#触ってるならWPFがクロスプラットフォーム対応してないことなんて常識… C#もReactも使えるけどBlazor使った事無いし。彼みたいに使っても無い物を根拠も例もなしにこき下ろすような事できないし >>194 生産性なんて結局の所慣れてるかどうかでしかない UI部分の話でしかないから、ほしいコンポーネントがあるかどうか それもシンプルなUIにすれば、複雑なものなんかいらない >>194 エチオピアと日本どっちのが住心地いいですか?って聞かれたらなんて答える? >>194 静的言語の経験ないのか? 生産性はC#最強すぎて勝負にならないぞ >>195 最近WPF触ってない React には、周辺のエコシステムがある Ruby on Rails, Bootstrap, React の組み合わせも多い。 React で、styled-components だろ Redux, TypeScript もある TypeScriptが動的型言語と静的型言語の良いとこ取りを達成しちゃったからなぁ。Union型とかLiteral型とかIntersection型とか、その他もろもろ。 >>194 生産性でいえば静的c#とVSが圧倒的 これだけは他を突き放してる ちなみにMSはTypeScript+VScodeをc#+VS並の生産性にしたいらしい BlogやVScodeのアップデート履歴にそれらが記載されていてアイデアくれってユーザーに呼びかけている >193 desktopとしてLinux, Mac使ってる人ほぼゼロだし web appである必要ない場合多いって事実だろ なんでもweb appにしてしまう風潮おかしい 3DCGもApple非対応のソフトが増えてるらしいからな Macはもうクリエイターからも見放されている >>197 俺の言ってるBlazorの生産性ってUI限定の話じゃないぞ ASP coreだとbackend含めて大幅に生産性があがる 同じ人が同じ言語で同じC#ライブラリ使ってかけるから 生産性が桁違いにあがる >>205 スマホとかタブレットとかエンドユーザとかご存知無い? >>206 TypeScriptでバックエンドもフロントエンドも書けるよ? >>207 TS、JSは低速だしbackendで使わないほうがいい しょぼいアクセスのサイトならいいけど SPはMAUIでるまで対応しないから上の議論では外していただけで ちゃんと考慮はしている SP対応させたいならBlazorを使えばいい >>204 がほんとなら ts + VSCodeはc#+VSに生産性負けてるじゃん 仕事で普段はVSとC#で開発してるんだが、一度話題のVSCodeを使ってみようとC#で簡単なコンソールアプリ作ろうとしたことがある。 しかし、とにかくVSと比較して支援が少なくてすぐ投げてしまった… もしかしてtsでもこの程度なんだろうかという疑念がある。 >>198 そりゃあ…エチオピアじゃないかな… >>209 VS codeよりVSのがいいのはわかる。 tsはASPもWPFも対応してないし当分はC#がMSの主役言語でしょ >>208 普通はDBの方が速度に対する影響大きいでしょ。それにJSはかなり最適化入っててそこそこ速い。もしそんなJSの速度で不満ならGoなりRustなり使うよ。 MAUIなんて待たなくてもその前身であるXamarin使えば良い。と思ったけどそれだと移植が必要だからのMAUI待ちか。どちらにせよWPFそのままってわけにはいかないよね >>212 わざわざ遅い言語でbackend作る意味がない nodeもrailsもC#に比べると激遅いぞ 未だに、Webサイトの最高速度は、Ruby on Rails。 瞬間で表示される。 他のフレームワークじゃ無理 表示速度が“異常な”Webサイト「dev.to」とか https://dev.to/ 元乃木坂46 の川後陽菜のWebサイト、SKIYAKI とか https://kawagopro.com/ >>213 シンプルなコードだから参考記録だけど、まぁ一応JSはC#より2倍遅い程度で、劇遅いとまでは言いにくい。JSで遅ければ(ボトルネック部分を)C#より速い言語にするよ。 https://qiita.com/yosgspec/items/4b2c1059f9a49fb06c5c そもそもパフォーマンスチューニングで最も重要なのは計測だよ。ボトルネック見つけて、それからその部分を最適化すべきだ。 >>215 なーんだ、C#ってエラそうなこと言ってもネイティブ言語には全然敵わないんだなwww >>214 Railsは論外に遅い ASP.net Coreの1/10から1/20の速度になってることがある。 >>216 C#はILを使うんだからC++に勝てるわけないだろ しかし生産性とのバランス考えると最強になる web appでC++とか使ってられない 使いやすいframeworkがないとだめ ベンチだけ速いマイナー言語は使えない 静的型のメリットも享受できそこそこ早いTypeScriptで使いやすいフレームワークを使った上で遅い部分をCなりWasmなりで最適化する、と ★jQuery, Ruby, C#, Blazorキチガイが書き込んでも無視してください なんとなく自分の中で結論が出たよ。 生産性についてはASP.NET+C#に軍配が上がるけど、 React,Vue+TypeScriptのほうが人気。開発者も集めやすいし、情報が多い。 どちらもバランスが取れた言語、フレームワーク。 わざわざ今tsやってる人がC#を習得しなくてもいいし、逆もまた然り。 ってかんじかな… ★jQuery, Ruby, C#, Blazorキチガイが書き込んでも無視してください >>222 BlazorはC#+ASP.NETの知識ある人にとっては 覚えることがほとんどないんだよ Razor syntaxという以前からのASP.NET同じような書き方をする 情報も英語できる人なら新しいBlazorでさえ情報十分 C#の中級者以上ならASP.NETもBlazorも短期間で習得できるから 人の集めやすさも問題ない。 あと分かったこと。 ts+VSCodeのイケてるWebプログラマ達は、実はSIerが扱うC#+VSより生産性の低いやり方でやっているという… でもMSもここに金を注ぎ込んでいるし、そのうち改善されるんでしょう。 生産性の低いやり方でやってるはずなのに なぜか生産量は多い とか言う話かね? >>226 いけてると思い込んでる、だな webエンジニアはMS系の技術の知識がない人多い ASPにシェアがあると言ったりWeb屋はMS系の知識無いと言ったり矛盾してませんかねぇ >>230 矛盾してない web系企業というジャンルがあるんだよ web エンジニアがweb系の企業にだけいるわけじゃない つまりASPやってるのは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万円とか、プログラマーより上になってる そういうこと 所属企業のジャンルとか、ほかに手掛けてる技術とかで変わる 自社開発で不特定多数向けのweb serviceを作ってる企業を web系企業といったり、そこにいるひとをweb(系)エンジニアといったりする。 日本だとヤフーみたいなところだ 受託開発でやってる企業のC#エンジニアはweb appだけやってることは稀。 WPFとかほかのC#にも携わってることが多い上にweb系企業所属でもないから webエンジニアと言われることは少ない YouTube で有名な、くろかわこうへいは、 来年から、AWS の有料講座を始めるので、 1万円あげるから、モニター受講者5人を探していたけど、応募者が殺到 時代はKENTA から、くろかわへ移った! 職を欲しい香具師が、AWSへ殺到 YouTube の、KENTA・くろかわこうへいが、 web バックエンドの歴史・道筋を作った! 時代が変わった瞬間 YouTube からは、こういう時代の寵児が出てくる。 必ず、誰かがやる >>233 おまえコピペばっかりだな C#とJavaやらないとかいってるKENTAはレベル低い やらないというよりできない、が正しい サーバーサイドのスキルがないからクラウド前提になる >>236 へぼいYouTuberに洗脳されすぎ バックエンドで速度でてメジャーなのといったらC#とJava そこができないKENTAはレベル高くはない >>233 に書いたような旧技術よりも、AWS などの価値が大きくなった。 GAFA, Microsoft の5社の時価総額が、東証一部と同じ、500兆円 今後は、Amazon 1社で、500兆円になるかも Ruby on Rails のポートフォリオも、マコなりの所のメルカリクローンばかりになって、 ついにKENTA も、面接で学校へ通っていたことを言わないでくださいって言ってたw 学校のポートフォリオを、そのまま提出する香具師が多いから、 企業からは、学校へ通っていた香具師は採用しないとか Railsのコピペ・チート技術がまん延した結果、 誰でもメルカリが作れるようになってしまったw jQueryおじさん、Youtuberおじさん、C#おじさん三つ巴の戦いが今、始まる。 蠱毒かな? 関係ないやつらが関係ないはずのJavaScriptスレで延々と必死に我田引水の宣伝合戦を繰り広げるということは、逆説的にいかにJavaScriptの人気が高いかということを示してしまっているねwww 使える技術一覧にDHCPなんて書く奴全く信用できないけどな KENTA の千円のサロンは、1,200人で、技術系としては異例の多さ! 勝又健太さんが運営する雑食系エンジニアサロンの口コミと評判! 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# もある >>250 サロンの収入増やすためにKENTAはハローワールド いじった程度の言語まで書いて経歴粉飾してるんだろう C#やってたらWindows要らないなんて言うわけない 最速でdesktop app作れるのC#だし >>214 もだまされて有料サロン入ってるのか? >>246 みたらGitHubがスカスカじゃないか >>250 Bootstrap無くてもレスポンシブ対応はCSSでできるやん。かなり特殊な条件でもResizeObserberで行けるだろうし >>250 むしろBootstrap使っただけのサイトをレスポンシブなんて言わないだろ CSS自力で書けないのにレスポンシブWebが作れますって宣言するレベルもケンタ?レベルだろ そんなに難しくないぞ、HTML/CSS つーかそもそもワナビーぐらいしかWebエンジニア系YouTuberなんか見ないだろ だって情報ありふれてて態々動画で見る意味がないもん 組み込みとかゲームだったらまだ面白い気がするけど、Webって一番エンジニア数も多くて底も浅いじゃん 有名フレームワーク作ってるとかWebサーバー作ってるとかなら話は別だが、動画で見たいか? どっちかっていうとドキュメント読みたいだろ YouTubeチャンネルの人気度で測ってること自体、正直レベル低すぎでしょ。その動画を面白いと思う人がいることと業界で金になるとか技術力が高いってことは全然別だもの。 なんでYouTubeで初心者、子供の人気が集まる人が優秀ってことになるのかさっぱり理解できない。 ケンタがまともなUI作れるわけがない というかケンタだけじゃなくお前らの大半がゴミのようなUIしか作れないんだから終わってんだろ >>254 英語音声のYouTubeのプログラミング関連はクオリティ高いのあるから割と見てる。 公式ドキュメントでカバーされてない話題とかTipsがあったりする。 ドキュメントより動画のがわかりやすいものもある。 開発チームのトップが解説してる動画もいい >>257 Linuxカーネルの開発なんかは組み込みに近いところがあるし、 ドライバ〜ハードウェア抽象化層〜OSまでのコード生成が仕様書から自動で行われなくなるようにならない限り 組み込み的な開発はずっと必要だよ。 遺物だと思うのは何十にも抽象化されたようなアプリレイヤーしか触ってないからでしょ。 まあ、jsスレだしそう思うフロントしかわからない人が居ても不自然ではないが。 >>256 自分もそういう動画は見ることがあって、 もちろん、全ての動画解説を否定しているつもりはなく、 開発技術ジャンルを、チャンネル登録者数の多いYouTuberが一押ししてるから今はこのジャンルが強い、みたいに評価することに何の意味があるのって意見を言いたかっただけ。 チャンネル登録者数が多いってことは多くの場合は初心者にとってキャッチーで簡単なだけで、 それ以上の商業的、技術的意味はない訳だろう。 割とコアに活動してる技術者達が、今はこれが熱い(将来性を感じる)と言っているならわかるけど、 いくら人気だろうがYouTuberに特化したエンジニア崩れが何言ってようが初心者が初心者になんか言ってるだけで、 小学生の間でどの漫画が流行ってるぐらいの意味しかないだろう。 日本でも海外でも専門分野の話はユーチューブ以外で 実績ないと信用したらダメだろ >>258 だからなんでお前ここにいて組み込み吠えてんだよ? 組み込みとかハードに近いコード書いてるやつらはリスペクトしてる。 他所から見ると変化の無さそうに見えるけど、けっこう激しく変化してる世界だし、構造体を見事に組み合わせてメモリ効率良く美しいロジック組んでるの見るとホレボレする。 逆に組み込み屋から見ると、こちらはこちらでレイヤーが多いし異様に高度に抽象化してるように見えるらしく、スゲースゲー言われる。 基礎は共有してても専門性が高い部分はお互いわからない。見下したりせず、お互いリスペクトしあうのか望ましい >>259 日本人YouTuberはプログラミングの解説動画はあまり作らずに サロンに勧誘するための動画ばっかり作ってる印象。 サロンビジネス、ぼったくり情報商材屋多め KENTA は、マナブの12万円のWordPress 教材を、情弱狙いだと批判してる WordPressは低価格の請負だから、初心者がやるのは危険。 時間給じゃないから、どれだけ時間が掛かっても、5万円とか WordPressぐらいなら、KENTAの千円のサロンで、誰かに聞けば十分。 最近は、高額の情弱ビジネスが横行しているから、まず、KENTAに聞くべき! >>265 KENTAも情弱ビジネス 情弱相手のサロンビジネス屋 ネットで調べればわかるしサロンに入る必要がないのに サロンにはいれば解決するかのように宣伝してるのは詐欺 初心者ばかり集まってるサロンで聞いてもろくな回答つかないだろw スキルあるやつはそんなサロン入らないだから WordPressは単価悪いからやらん方がいいってところに関しては確かに同意だな ちょっと聞きたいんだけど、 Gatsbyと(ヘッドレス)CMSを組み合わせた場合、静的なページが出力されるの? つまりCMS上で更新した内容はGatsbyでビルドしないと反映されないのかどうかという事なんだけど。 >>269 まったく別物 クラスをちゃんと理解するにはC#とかの静的言語で オブジェクト指向プログラミングを学ばないとだめ 動的言語だけやってると型の概念が身につかない まずは静的言語の学習を >>270 静的言語のクラスはわかる その上で違いを教えて >>271 数行で説明できる概念じゃない オブジェクト指向は自分でプログラミングしないと見につかない Java , C#の初級プログラマーが最初につまづくところだ 動的言語だけやってると初級から抜け出せない 静的言語を勉強しろってのが適切なアドバイスなわけ >>272 いや、わかってない 静的言語でちゃんとコード書けないでしょ クラスわかってたらそんな頓珍漢な質問は出てこない クロージャを知らない人がクラスだけ勉強したところでその違いがわかるわけないわな。 >>273 理解が曖昧だから 教えられないのでは? >>269 雑に言うと クロージャは関数が外側の変数の参照を(外側の部分の実行が終わった後も含め)持ち続ける現象、かな。参照を持ってるから変数がGCされることも無い。 クラスとの違いは(比較対象では無いけど)……プライベート変数と機能は多少重複してるけど、出来た経緯が全然違うもの、かなぁ。 クロージャってPerlとかクラスがないというかまともなOOPの仕組みない言語がOOPするために使われてただけなんじゃない 今の時代クロージャーがないほうがOOP言語として未熟扱いだけどね クロージャはLisp由来関数畑育ちで、OOPの出来損ないみたいなものじゃない。 まぁ、クロージャ何でもできるからそういう使われ方してて(Ecma3時代にプライベートメンバ作るとか)、そう思われても仕方ないとこあるけど…… OOPが出来損ないでは? 関数型になれなかった言語 ほらね。レスするくせに反論しなかったw ここがこいつの限界というわけ >>282 その気持ちはわかるww でもその言い方は「これだから関数型信者は」って虐められるから止めてよw 俺はOOPも好きだし やっぱり知らなかったww wikipedia得意気に貼って恥ずかしい奴www クロージャなんて言語によって違いすぎるから 誰も数行で説明できない 存在しない言語もあるわけでね やはり静的言語勉強しろっていうアドバイスが的確過ぎた いやいや、違い過ぎるものを同じ言葉では呼ばないでしょ。よりにもよってWikipediaのURLなんてダサすぎる。 なんならあんたの好きなC#で説明すれば良かったのに >>290 回答してくれてありがとう。 所謂JAMstackについて調べてたらmicroCMSとGatsbyの組み合わせについて書いてあったから、ちょっと混乱しちゃって。 >>278 クラスもメソッド(≒クロージャの関数)がプライベートプロパティ(≒外側の変数)を参照できるからそこはクロージャと変わらんよね? jsはprototypeとはいえクラス使えるからクロージャはもういらないってこと? それとも今でもjsはクロージャを駆使するのが当たり前なのかな? >>292 クラスがあればクロージャはいらないってのは間違ってないんだけど、 ちょっとしたコールバック関数を書くのにそれ用のクラス書いてるとクラスだらけになってめんどくさいよ。 逆に適当にクロージャを書いて変数のスコープの見通しが悪くなるときにはクラスにするし、 どっちにも無理やり使おうとすると使いづらい場合がある。 究極を言えばチューリング完全なら出来ること同じなんだし、 言語の機能はよくあるパターンを人間が書きやすく、そしてルールを覚えやすく作ってあるだけということになる >>292 ある程度はその通りで、プライベートプロパティが使える現代の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 クラスとクロージャーは全くの別物だよ。 同じことを処理として実現できるから同じ技術というのはおかしいよ。 https://qiita.com/pebblip/items/2ed30f59cd5981513908 ↑これを読むと理解できるかも お前ら技術力が無いと見下してきたおじさんズが全然技術力無いことを露呈した流れは正直面白かった >>297 どれの話?そうやってありもしないことを言って満足してるの? 「バナナが欲しかったが、バナナを持ったゴリラを手に入れた」 ゴリラ=クラス 元ネタはErlang作者であるJoe Armstrongの、 「オブジェクト指向言語の問題は、オブジェクト指向言語が持ち歩く暗黙の環境をすべて持っていることです。あなたはバナナが欲しかったのですが、あなたが手に入れたのはバナナを持ったゴリラが生活しているジャングル全体でした」 クラスがあるからクロージャは不要というのは、 バナナを簡単に食べられるという話に ジャングルでも同じことができるから不要と言ってるに過ぎない >>299 たとえがアホすぎだね ジャングル全体があるからバナナが収穫できる バナナしかなければ食べたらおしまい 静的言語のが実行速度も速いし生産性も高い 大規模開発もできる つまり上位互換 バナナを食べるだけなのにジャングルの整備・バナナの収穫までその場で考えなければならない。 ゴリラの飼育、お嫁さんどうするかも考えないとw 何故この文脈で静的言語云々が出てくるのか。 静的言語って言いたいだけか JSに限らず動的言語は必要な機能が揃ってないからだ クロージャの話にどうして静的言語云々が出てるんですかねぇ 初期のJavaは酷かった。 イベントハンドラ登録するだけなのにイベントリスナーのクラス作らないといけなかった。 「む、無名クラスでインラインでも書けるから!」とか。アホかと。 今ではみんなラムダ関数使ってまーすw だーれもクラス使ってないでーすwww >>307 JavaとJavaScriptの区別もつかない無能 確かに以前のJavaはクロージャどころか関数ポインタ(的なもの)すら無くて辛い言語だったなぁ。 個人的にはJS|TSでクラス使う場面って、 ・状態を持つオブジェクトを扱う時 ・継承を使う時(WebComponents等) くらいだと思ってる。 >>307 まああのシンプルさが勉強には良かったけどね。 仕事で使いたくはないけど。 なぜクロージャーが便利なのかということも身を持って知れるし。 Javaに失望したらC#にいけばいいのに なぜさらに不便なJSなのか webの開発では圧倒的にクロージャーを使うことが多いよ。 あるリストがあって、その中の一つの要素をクリック時に削除するなどの処理を書く場合は自然とクロージャー使うしね elm.AddEventListener(function() { ・・・}) を使うな function handler() { ・・・} elm.AddEventListener(handler) を使え派は どこ行ったんだろうねw 前者はクロージャーだから循環参照を引き起こして メモリリークのバグになる可能性があるから 後者を使えっていうのが昔は多かったんだが もっともjQueryは後者の書き方をしても循環参照にならない 仕組みなので問題なかったんだが (要素に直接イベントハンドラ関数を割り当てるのではなくjQueryの内部的な イベントハンドラを管理するオブジェクト経由で間接的に参照するので 循環参照にならない仕組みでブラウザのメモリ管理のバグを回避していた) クロージャ使い倒してるけど循環参照してメモリリークなんて一度もなった事無いから、普段全く意識してないなぁ。 TS使ってて他に劣ってるとは全然思わない。あ、ジェネリック周りが複雑過ぎるとは時々思うw next.jsって本がないのが辛い。Gatsbyですらあるのに。どこ見て勉強するとええんやろ。公式をGoogle翻訳? 英語できない人がそんなマイナーフレームワーク使ってはいけない 翻訳なんてつかうからいつまでたっても英語が上達しない 本は情報が常に古い 英語のドキュメントとソースコードでしょ あとはYouTubeの英語 >>313 俺は世代的にこの問題を意識したことないけど、eventをちゃんとremoveすれば良いって話だよね? >>317 ブラウザバックや進む、リロード時に eventをremoveするように作らないといかんわけや とうぜんブラウザバック時にイベントなんて起きないでw そう言えば、jQuery では、DOM の削除時にも、イベントも削除してくれるのだっけ? リロードしてもリソース開放されんってそんな時代あったんか…… Chromeだとリロードボタンの右クリックにキャッシュを飛ばしてリロードするかどうかの選択あるけどね >>319 削除される。もちろんjQueryの命令を使って削除しないといけないけど >>322 キャッシュの話wwwww で?w リスナーの登録は?www 自作ソフトをWeb Componentsで作り直そうかと思ってるが 特にメリットがないし、二の足を踏んでいる。 web components は spaとかを作るには向いてないけどある程度静的なものを作るなら向いてると思うで。 templateとかにlit htmlとか使うの前提だけどね lit-html知らなかったわ。面白いなこれ。 ガチンコなアプリでは物足りない感じだけど、既存のものにもさくっと差し込めそう 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 のマーケットシェアが1位って記事があったから載せてみるね ネット上のマーケットシェアのサイトってソース載ってないのも どうやって調べてるかわからないものも多いよね 上の方で、ページリロードでリスナーが解放されるかって話 バカにせずに真面目に考えてみます 基本的に、ページリロードで 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より数十倍も遅いため使い物になっていない フロントエンド改修するのにReactかVue3で迷ってる 世の流れ的にいくならReactにしない理由はないと思うんだけどなんか好きになれんのよな Vueはテンプレートの構文がわかりやすくて好きなんだけど、結局typescriptとの親和性の観点でtsxで書く流れになってきてるから、tsx使うならReactでよくねとも思う Reactだと依存配列書き忘れとかも以外とやりがちで、Vueはcomputedがその辺全部いい感じにやってくれるから自分的な差はそこくらいかなあ なんかここで選べみたいなのあります? は?一生懸命書いたのに、くっそ昔のスレじゃん 泣きたい Reactを使いたけど、jsの言語仕様が変態すぎて辛い jsはチュートリアルさらりと読んだら、理解が曖昧でも そのままフレームワークの使い方を覚える段階に進んだ方がいいのかな? 言語仕様がぐちゃぐちゃでベストプラクティスを想像できない >>338 webprog、web制作あたりと合体したらいいかも さらに Rect へSvelte とvue をまぶしたようなSolid.jsなるものまであるな https://www.solidjs.com/ ベンダーじゃなくて発注側なんやけど、Javaができて便利なことある? 例えばベンダー側で実際Javaのプログラム書いたり開発した経験が無くても、発注側で極簡単な改修なら自前でできたり、改修や開発の設計書を読めるようになるぐらいならできるもん? >>344 Javaとスレタイは違うものなのでスレ違い 色々変な仕様くっつきすぎてとっつきにくくなり、素のJSに戻ることになるでしょう フロントエンドをスレタイに入れなければもっと伸びたはず ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる