.NET MAUIが不人気な原因なんなの？

**デフォルトの名無しさん** · 2025/02/14(金) 16:10:51.62

プログラミング業界に激震、Flutter macrosが開発断念
ReactNativeと.NET MAUIがまさかの復権か
https://hayabusa9.5ch.net/test/read.cgi/news/1739513015/

**デフォルトの名無しさん** · 2025/02/14(金) 18:50:48.14

>>477
完全に react expoのターンだろ

生成AI「bolt」にスマホアプリ生成が追加🤖
https://hayabusa9.5ch.net/test/read.cgi/news/1739515512/

**デフォルトの名無しさん** · 2025/03/05(水) 20:20:18.98

いい加減ASPとXAMLを統合してくれや
RazorとXAMLのViewの構文の違いだけならMS開発環境古参のワイは余裕でやから文句言わへんのやが
フロントエンドのライフサイクルや実装がまったくことなるからMAUIで無理矢理ひとまとめにしても意味ないっちゅーねん
なんでReactがマルチプラットフォームで覇権なんかゆーたらWebモバイルデスクトップで多少の手直しは必要にしても実装に一貫性があるからやんけ
ええ加減RazorかXAMLどっちかに絞って余ったんを捨てろや

**デフォルトの名無しさん** · 2025/03/12(水) 09:10:52.04

A 10x Faster TypeScript
https://devblogs.microsoft.com/typescript/typescript-native-port/

C#を作ったアンダース・ヘルスバーグですらもうC#を選ばないとか終わってるな

**デフォルトの名無しさん** · 2025/03/12(水) 10:01:18.74

もうC#を使うメリットがWindowsデスクトップアプリを作るなら一番簡単だからって理由しかないからな
TypeScriptをJSやなくてGoのラッパー？にしたら10倍速でネイティブに限りなく近いパフォーマンスが発揮できるらしい
MAUI含めてMSの開発環境のメイン言語もC++やC#やなくてTypeScriptにさっさと切り替えてほしいわ
ワイはJSもTSも余裕のフルスタックエンジニアやからなwww

**デフォルトの名無しさん** · 2025/03/15(土) 11:25:36.86

これか

マイクロソフト、TypeScriptのコンパイラなどをGo言語に移植することで10倍の処理速度に
https://www.publickey1.jp/blog/25/typescriptgo10.html

Golangはクロスプラットフォームなネイティブを書くのであれば最適解なのかな
WasmまわりではGC関連の事情もあってバイナリサイズの増加に苦慮しているみたいだけど、GUIでなければ基本的にGoを使っとけば問題ないのね

C#も.NET Coreでクロスプラットフォームを強化してるけどGoより安定してないと見られたか

**デフォルトの名無しさん** · 2025/03/15(土) 11:34:23.06

一番の理由はC#が単純に遅いってこと
今はTSのトランスパイラがJSで書かれててnode.jsで動いとるtscで
それをGoに移植してtsgoにしたらすべての処理が約10倍になったってわけ
VScodeなんかもこれで実装されとるからtsgoになったらRustで実装されとるZedにも負けへんくらい速くなりそうでめっちゃええやん

**デフォルトの名無しさん** · 2025/03/17(月) 08:30:35.74

golang本スレの錆れ様は何だったのか

**デフォルトの名無しさん** · 2025/03/17(月) 16:28:10.88

5chはジジイが多いって事を本気で自覚した方がいいってことだろ
Qiitaなんかgoの記事すごい多いいぞ

**デフォルトの名無しさん** · 2025/03/17(月) 16:46:00.68

Qiita()
自分は違うと勘違いしてるジジイがブームが去ったものを今流行ってると思ってるの草
今はZennの時代なんだよジジイwww

**デフォルトの名無しさん** · 2025/03/18(火) 14:10:14.93

TSがGoに移植されることやしフロントエンドもXAML捨ててモバイルウェブデスクトップをHTML+TSに一本化しようや

**デフォルトの名無しさん** · 2025/03/18(火) 21:32:27.68

https://x.com/ahejlsberg/status/1899624685396181031
C# was a top contender for the port, as was Rust. But both would have been a rewrite more than a port. We picked Go because it was the path of least resistance to 10x for *this* particular code base. It's a win for OSS. We couldn't have done this in the past!

**デフォルトの名無しさん** · 2025/03/18(火) 21:37:29.28

https://github.com/microsoft/typescript-go/discussions/411#discussioncomment-12476218

The TypeScript compiler's move to Go was influenced by specific technical requirements, such as the need for structural compatibility with the existing JavaScript-based codebase, ease of memory management, and the ability to handle complex graph processing efficiently. After evaluating numerous languages and making multiple prototypes — including in C# — Go emerged as the optimal choice, providing excellent ergonomics for tree traversal, ease of memory allocation, and a code structure that closely mirrors the existing compiler, enabling easier maintenance and compatibility.

In a green field, this would have been a totally different conversation. But this was not a green field - it's a port of an existing codebase with 100 man-years of investment. Yes, we could have redesigned the compiler in C# from scratch, and it would have worked. In fact, C#'s own compiler, Roslyn, is written in C# and bootstraps itself. But this wasn't a compiler redesign, and the TypeScript to Go move was far more automatable and more one-to-one in its mapping. Our existing codebase is all functions and data structures - no classes. Idiomatic Go looked just like our existing codebase so the port was greatly simplified.

**デフォルトの名無しさん** · 2025/03/18(火) 21:47:34.88

tsコンパイラとgoのコードって1対1で対応付けられるくらい相性良かったのか
この知見を発展させてTypeScriptで書いたコードをJSじゃなくてGoにトランスパイルしてそのままバイナリコンパイルもできるようになって欲しい

**デフォルトの名無しさん** · 2025/03/19(水) 00:48:24.72

もうさGoをJavascriptにトランスパイルさせてよ
Goは書きやすくて便利だからさ

**デフォルトの名無しさん** · 2025/03/19(水) 21:51:32.78

A 10x Faster TypeScript (2025/3/11) | TypeScript - The official blog of the TypeScript team
ps://devblogs.microsoft.com/typescript/typescript-native-port/

**デフォルトの名無しさん** · 2025/03/26(水) 09:55:01.75

このスレの住民的にはクロスプラットフォーム開発はやはりQtがオススメ？

**デフォルトの名無しさん** · 2025/03/26(水) 10:21:45.29

凝った作りにしなきゃいいだけ

**デフォルトの名無しさん** · 2025/03/29(土) 18:57:22.25

成果物が軽く10MB、けっこう作りこむとあっという間に100MBを超えてもいいならElectronが一番いいんじゃね？

**デフォルトの名無しさん** · 2025/04/04(金) 11:37:33.92

.NET frameworksのアプリを.NET MAUIに移植できないかと聞かれソースにIPC使ってるのを
見て速攻で無理っすって回答した過去を思い出し。

**デフォルトの名無しさん** · 2025/04/04(金) 19:35:10.01

すべてが.NET Frameworkのサブセットやと理解しとらん低脳チンパンのアホが多すぎるんよ
まぁここでもMSの縦割り組織かつ部門同志の派閥争いで大迷走の戦略が大爆死しただけとゆー至極真っ当な結果なんやけどな
WinRTがそもそもの大失敗やったんやがそこからUWP、PCLと更に大迷走
その後にPCLを再定義しただけの.NET Standardも結局サブセットやっちゅー根本原理は変わらず
プラットフォーム固有の機能が一切使えない代わりにロジック共有できますみたいな一体なんのメリットがあるのかMS自身も説明でけへんそびえたつうんこで見向きもされず大爆死
WinRTで激減したデスクトップアプリの開発者が軒並みiOSなんかのモバイルに流出してしまってそれ以降一向にWinアプリが開発されずMS Storeも死亡
まぁゲイツが大学の同級生かつ親友のバルマーをCEOにしてしまったっちゅーお友達人事が全ての原因なんやがな
バルマーやなくてナデラがCEOならWindows Phoneが第三勢力として生き残っててC#/.NETがもっと有効活用されてた世界線があったかもしれんけどたらればよな

**デフォルトの名無しさん** · 2025/04/04(金) 21:03:27.10

いまは.NET Coreから分岐するのが.NET Frameworkと違うん？

**デフォルトの名無しさん** · 2025/04/04(金) 21:18:41.07

>>495
もう100MBとか気にしないしElectronでおｋ

**デフォルトの名無しさん** · 2025/04/05(土) 02:01:59.89

ガイジジイこのスレにも出没するのか
キッツ

**デフォルトの名無しさん** · 2025/11/21(金) 16:58:18.60

マイクロソフトはついに、Windows 11の主要コア機能のほぼすべてが壊れていることを認めた。

このテクノロジー大手は本日、最新のパッチチューズデーがゲームのパフォーマンス低下を引き起こしているとNVIDIAから非難された。NVIDIAは、これらの問題を解決するための緊急ホットフィックスドライバーをリリースした。

これは、今週初めに発表されたエージェントOSへのオペレーティングシステムの進化により、同社のWindows責任者が最近直面した激しい反発の直後に起こった。

しかし明るい面としては、こうした反発を受けて、MicrosoftはWindowsに問題があることを認め、まるで合図を送るかのように、新たなサポート記事でWindows 11のほぼすべての主要なコア機能に問題があることを認めました。問題はXAMLに関連しており、スタートメニュー、タスクバー、エクスプローラー、Windows設定など、すべてのシェルコンポーネントに影響を与えています。

**デフォルトの名無しさん** · 2025/11/21(金) 16:59:40.41

MSついにWin11がどんなハイスペPCでも常にもっさりしたりプチフリするほどパフォーマンスが酷い原因がXAMLだと認めるwww

**デフォルトの名無しさん** · 2025/11/29(土) 00:27:31.04

何言ってんだこいつ

**デフォルトの名無しさん** · 2025/11/30(日) 06:01:09.90

Windows 11でファイルエクスプローラーをプリロードするとRAM使用量が2倍になり、速度向上は最小限に抑えられる

Windows Latest のテストにより、プリロードが部分的に機能し、ファイルエクスプローラーの読み込みが高速化されることが確認されましたが、十分な速度ではありません。Dev チャネルと Beta チャネルで利用可能な最新の Windows 11 Insider Preview Build 26220.7271 (KB5070307) を実行している仮想マシンでは、通常のファイルエクスプローラーの起動で 35 MB の RAM が使用されます。ただし、プリロードされたバージョンでは、バックグラウンドプロセスにより、そのほぼ 2 倍の 67.4 MB の RAM が使用されます。エンドユーザーにはほとんど変化が感じられず、ファイルエクスプローラーは依然として動作が遅いように感じられます。

以前のWindows 10のファイルエクスプローラーはWin32 UI要素を使用していたため、パフォーマンスの向上は必要ありませんでした。しかし、Windows 11では、このレガシーコアに最新のWinUI/XAMLがオーバーレイされています。そのため、追加されたUI要素によって、アプリケーション全体の速度が低下しています。

WinUI/XAMLがWin11のパフォーマンス低下の根本的な原因だと判明www

**デフォルトの名無しさん** · 2025/11/30(日) 08:19:40.69

流石にWin11エクスプローラについてはそれ以前の問題だと思うぜ
VisualStudioなんかも早くからWPFだしWindows TerminalもWinUIだけどあそこまで悲惨なことにはなってねえし

**デフォルトの名無しさん** · 2025/11/30(日) 22:38:19.44

Win11のはKB5062553導入でXAMLパーサーのロードが遅れて、起動中に読み込まれたエレメントが
間に合わずに壊れてたってのが原因だからねえ。

**デフォルトの名無しさん** · 2025/12/01(月) 00:06:09.16

マルチタブ切り替えたりすると、固まるんじゃないかって不安になるくらい重いね11のエクスプローラー・・・
皆他のファイラー使ってたりするの？

**デフォルトの名無しさん** · 2025/12/01(月) 00:09:22.00

MSはなんでもかんでもプリロードする病を治せよ
要は起動を速く見せかけるためにデスクトップをアプデ後の後処理より早く読み込んでたのが原因だろう
これに限らずあらゆるアプリが自分を速く見せるために競ってプリロードしまくってただでさえ重い起動直後のCPUとディスクを奪い合って全体として遅くなってる
やらかした後だというのに更にエクスプローラのプリロードを増やす計画とかさあ…

**デフォルトの名無しさん** · 2025/12/01(月) 00:10:17.35

そもそもWinRTやUWPが失敗したのもWPFから無理矢理XAMLを引っ張ってきたのが根本的な原因なのだがwww
開発も大変ならパフォーマンスも悪くてマルチプラットフォーム化も問題だらけのXAMLを捨てきれず今でも固執し続けてるのがそもそも大失敗でMSの開発環境における失われた15年なのは確定的に明らか

**デフォルトの名無しさん** · 2025/12/01(月) 16:56:49.63

Windows updateで何度問題起こしても懲りないからな
原因報告受けても認めず被害を長期化させてバカ丸出しなんだよ
有償OSでやっていい事じゃないだろ
本当におかしな会社だよ

**デフォルトの名無しさん** · 2025/12/01(月) 17:08:18.62

まぁ未だにデスクトップでWindowsが86%程度のシェア保ててる理由がゲームのお陰だからな
それもValveがProtonとSteamOSとハードウェアに注力してるお陰で遂に大手メーカーがLinuxのゲーム環境で最大の障害であるカーネルモードで動作するアンチチートをLinuxとArmに対応し始めたからな
これで大手のビッグタイトル’すべてがLinuxに公式対応したらゲームでもずっとパフォーマンス低下問題を改善できないままのWindowsの牙城が崩れるのは確定的に明らか
これでやっとWindowsをみんなが捨てられてユーザーもデベロッパーもウィンウィンになるぞ

**デフォルトの名無しさん** · 2025/12/02(火) 04:13:41.07

同社は最近、特定のエンタープライズシステムのタスクバーやエクスプローラーなどの主要な OS 機能を含むWindows Shell 全体に多くの重大な問題があることを認めました。これらの問題は、UWP、WPF、WinUI 上に構築された Windows UI 要素の大部分を構成する XAML に何らかの形で関連しています。

**デフォルトの名無しさん** · 2025/12/03(水) 05:35:45.14

XAMLが悪かったとして
だから何なの。。

**デフォルトの名無しさん** · 2025/12/03(水) 17:58:28.22

マイクロソフトは、一部のPCで24H2だけでなくWindows 11 25H2の主要なUI機能も壊れていることを認めた
先月11月後半、NeowinはMicrosoftがWindowsの最も重要なUIとUXコンポーネントの一部に不具合があることを説明するサポート記事を掲載したことを知りました。もしこのニュースを見逃していた方のためにお伝えすると、このテクノロジー界の巨人は、エクスプローラー、スタートメニュー、タスクバーなどを含むWindows 11のシェル要素が、一部のエンタープライズおよびオフィスシステムでバグを起こしていることを認めています。
このサポート記事は、IT管理者とシステム管理者がこうした問題に対処するためのガイダンスとして公開されました。主な問題はXAMLに関連しており、本日Microsoftはこの問題に関する詳細情報を追加しました。

**デフォルトの名無しさん** · 2025/12/03(水) 19:48:37.07

TortoiseGit入れると高確率でフリーズするし
PCも古かったのでマシン入れ替えたけど全く解決しなかった
OS自体がイかれてるならそうなるわね

**デフォルトの名無しさん** · 2025/12/03(水) 20:29:47.00

>>513
MAUIはWinUIがベースだから関係大有りなのだが?www

>>515
WPFから始まったそびえたつうんこの産廃XAMLを維持で強要し続けてシェア減らし続けてるのもうスパイ以外のナニモノでもないだろwww
そしてMSはXAMLを使わずアプリをほぼすべてReactで開発してるの一体どんな喜劇なんだよwww

**デフォルトの名無しさん** · 2025/12/03(水) 21:15:35.43

はやく全部TypeScriptにしてくれ
低レベルはもう全部C++でいい
どうせAIが書くから

**デフォルトの名無しさん** · 2025/12/03(水) 22:29:29.06

実質shellのexoplorerに要らん機能盛り込み過ぎ

**デフォルトの名無しさん** · 2025/12/04(木) 00:40:49.97

>>515
WaylandをサポートしたLinux+Electron40でも今同じようなことが起きてる。
Electron40 Linux版が特に肥大しすぎてRAM 4Gくらいしか積んでないと平気で落ちるしdaemon登録してると
メニュー中途半端にぶっこわれて表示したりAppimage版で起動がめっさ遅かったり。

もう何だろね、PCは最低でもRAM 32Gは積めってことなのか。

**デフォルトの名無しさん** · 2025/12/04(木) 00:58:32.52

Windowsが親の仇になってる人がいるな
シャドーボクシング頑張って

**デフォルトの名無しさん** · 2025/12/04(木) 04:15:32.83

そもそも未だに2バイトフォントのレンダリングが汚くて醜いのって現存するOSだと既にWindowsだけなのもクソすぎる
macOSだけでなく既にLinuxですらフォントが美しくてモバイル含めて派生OSがすべてLinuxのフォークだから今フォントが汚いOSなんてWindows以外存在しないから尚更MSの無能さが際立つ
きっと10年後も日本語含めた2バイトフォントが今と同じく汚いままでMacTypeやFaithTypeを使ってるんだろうな
個人的これ以上Windowsで開発どころか利用もしたくないから早くゲームがLinuxに移行してWindowsがシェア奪われてほしい
すべての環境がLinuxになれば誰もWindowsとMSに苦しまなくて済む

**デフォルトの名無しさん** · 2025/12/04(木) 05:49:44.59

Linuxが落ちるのは勝手にプロセス殺す仕様だからじゃないの
Windows11の問題とは別の問題をLinuxは孕んでる

**デフォルトの名無しさん** · 2025/12/04(木) 07:04:17.62

>>521
馬鹿
↓
2バイトフォント

**デフォルトの名無しさん** · 2025/12/06(土) 08:28:07.40

>>521
それ、過去の遺産のMSゴシック／明朝系を使ってるからやねん。あんなのさっさと撲滅させれば
Windowsでも比較的きれいな描画になる。そもそもMSなんちゃらはWindows3.1時代のレターフェイス
もデタラメで同じサイズの英語フォントと並べたらガタガタ表示になるやつだしな。

**デフォルトの名無しさん** · 2025/12/06(土) 09:53:35.43

やっぱ悪者はMSじゃなくて日本MSなんだよなぁ

**デフォルトの名無しさん** · 2025/12/06(土) 10:31:11.75

>>524
全く同じ英語フォントをMacとWindowsで比べてみ？見え方違うぞ

**デフォルトの名無しさん** · 2025/12/06(土) 10:38:22.80

ベジエのアルゴリズムが違うんか

**デフォルトの名無しさん** · 2025/12/06(土) 10:53:04.12

TeX最強ですねわかります

**デフォルトの名無しさん** · 2025/12/07(日) 00:44:55.17

実際組み込みの等幅フォントで見やすくて見栄えが良いやつないよね
游ゴシックはサイズ大きいうえに薄いから場所取るのに読み辛い
MeiryoUIの等幅版出せ

**デフォルトの名無しさん** · 2025/12/07(日) 00:49:48.43

いやだからそもそもフォントの問題じゃないっつってんだよ
macOSと同じモリサワのヒラギノのOTFがWindowsだとどうやっても綺麗に表示できないのはWindowsのフォントレンダラーがゴミすぎるんだよ
デスクトップモバイルどころかNASやラズパイの組み込み向けOSですらLinuxだからフォント綺麗なのにWindowsだけがフォント醜くて汚いのMSが無能すぎるんだよ

**デフォルトの名無しさん** · 2025/12/07(日) 02:24:38.40

>>529
MeiryoKeGothicおすすめ
等倍
もう10年以上前から使ってる

**デフォルトの名無しさん** · 2025/12/07(日) 16:23:07.83

MacはMacで、全角と半角を識別しにくくて困るし半濁点を合成文字(例えば「ぷ」を「ふ」＋「゜」)
使ったりして、これまた見た目で全然判別出来ないため検索に引っかからなくて苛つくことはある。

**デフォルトの名無しさん** · 2025/12/07(日) 20:33:49.85

macOSやiOSだけでなくLinuxやAndroidですらフォントが綺麗になって10年以上経つのに未だにWindowsのフォントだけが汚いのUIの統一性のなさや未だにダークモードに完全対応できないことを考えてもMSがあまりに無能すぎるだけなの明らかだろ
ガチでさっさとValveのSteamOSがシェア奪ってWindowsはこの世から消えてほしいわ

**デフォルトの名無しさん** · 2025/12/07(日) 21:49:37.11

まだ騒いでんのかこのガイジ

**デフォルトの名無しさん** · 2025/12/07(日) 22:15:54.05

>>534
スレチの話題に乗ってる時点で同じ穴の狢なんだよなあ、俺もだけども

**デフォルトの名無しさん** · 2025/12/08(月) 06:39:24.46

>>346
日本では C# ばかり言われるが、アメリカでは C++ も愛されている。

**デフォルトの名無しさん** · 2025/12/08(月) 11:37:48.78

UIのことならスレチじゃない気がするが

**デフォルトの名無しさん** · 2025/12/09(火) 00:45:52.49

.NETのUIでフォントが汚くてアンチエイリアスしたいならフォントを0.5度くらい
傾けりゃいいだけかと。.NET Framework3の頃はよく使われてた小技。

**デフォルトの名無しさん** · 2025/12/09(火) 02:08:36.13

いやそれ以前にWin32のころはGDI+のDrawStringですべての文字列を画像化してアンチエイリアスかけられるからアプリデフォでMacTypeと遜色ない綺麗なフォント表示にできたんだが知らんのか?www
斜めにするとか意味不明すぎるんだが画像うpしてみろよ評価してやるからさ
DrawStringのアンチエイリアスの美しいフォント見たらWindowsでもフォントにアンチエイリアスかけられるんじゃんって発見したときびっくりしたわ
15年以上昔の話だがもちろんめっちゃ重くなるけど今のPCならまったく問題ないレベル

**デフォルトの名無しさん** · 2025/12/09(火) 02:34:05.33

ひとつのアプリの特定箇所だけ綺麗にしたところで、同じフォントなのに場所によって見え方が違うのは全体として汚い印象になるんだぜ