.NET MAUIが不人気な原因なんなの?
ライブラリがなさすぎてMAUIで作るよりiOSとAndroidを別々に2個開発した方が早い PCとタブレットとスマホを一本のコードで書くとか無理に決まってるだろ カメラ撮影もできないからテキストとボタンを表示するくらいしかできない iOSアプリ開発にはMac必須なのにVisual Studio for Mac廃止なのが致命傷だった AndroidとiOSのふたつですら最小公倍数でできないことだらけなのに
そこにMacCatalystとWindowsを混ぜるとか企画したやつ頭キチガイすぎ Xamarinの出始めの頃の
基本的にiPhoneとAndroidで別々にアプリを作るが
OSに依存しないビジネスロジック部分だけ共通ライブラリ化する
というのが一番理にかなっていた Xamarin.formsの時点で道を間違えていたんだよ vscodeのc#拡張が産業廃棄物級のゴミなのが大きい 複数のプラットフォームに対応して出来ないことだらけとかAdobe Flashが通った道じゃん。 Silverlightでも経験しているのに何で同じ過ちを繰り返したのか。 ジョブズも死ぬ直前にそんなこと言ってたな
iPhone OSの新機能をアプリ開発に利用できるかどうか、いつ利用できるかがサードパーティーによって決定されてしまうと同氏は主張している。
特にクロスプラットフォームツールでは各種プラットフォームの「最小公分母」の機能しか提供されず、「開発者がAppleの最新技術を利用できない状況は受け入れられない」という。
https://www.itmedia.co.jp/news/articles/1004/30/news029.html 片方で使えない機能があると両方で使えないことになる ぶっちゃけこの分野はFlutterで良いんだよね
プラットフォーム固有の処理はRustやGoで書いて呼べば良いし
唯一の難点というか嫌いなのはDart
ここだけせめてJSとかTSにしてくれりゃいいのに Androidのユーザーは金払いが悪いから、そもそもiOS向けのアプリだけ出しておけば十分だったんだよ >>11
AndroidはJavaだから問題ないけどObj-CのSDKをC#で書くとかただの苦行だし
別々に書くので良いよ
どうしても共通化したい場合はC++で書く方が良い SwiftUIのシンプルさと雲泥の差なのが敗因だろ
ReactiveCommandなんかを使ってもグチャグチャになるし ぶっちゃけ教科書どおりにObservableなんか使って書いたらメンテナンス性は最悪すぎてやばいだろ 失敗作の糞なのに頑なにプッシュして生産性落とそうとしてくるのが時間のムダ過ぎる そもそもTeamsのアプリとかだってReactで刷新したわけじゃん
まず自分達の製品で使ってみろって言いたい 正直、iOSとAndroid別々に似たようなアプリを作った方が早い あとXAMLは百歩譲ってもMVVMはゴミクソウンコだろ >>33
これ
今や典型的なUIを使ったアプリなんてChatGPTで生成して貰えば良いのだからたいしたこともない
ゲームはUnityとか使えば良い >>28
引数のラベルの仕様が全く違うので論外だよ >>36
SwiftとC#なんてテキスト置換で相互変換できるだろ。
Xamarin.Macで古いCarbon叩く場合はIntPtrだらけになるけどiOSとCocoaだとそんなことないし。
むしろヤバイのJavaだよ。
AndroidのJavaはイベント処理に匿名クラス使いまくりだからC#に変換するのがクソ面倒。 >>37
触ったことないんだろうけどUIKitというかObj-Cは関数のシグネイチャが
aFunc:arg1:arg2と言うような形なの
つまり関数名と引数のラベルが統一的に扱われる
これはC#でまともに書けないので
ただの引数にしてメソッドの名前をシンプルに変えてる
例:UIKitのメソッドシグネイチャ
tableView:didSelectRowAtIndexPath:
Xamarinのメソッドシグネイチャ
void RowSelected (UIKit.UITableView tableView, Foundation.NSIndexPath indexPath)
トホホ
名前がラベルじゃなくなってる上に個別のただの引数になっておる
これを見た時おれはxamarinというかC#を捨てた >>38
c#もラベルあるじゃん。
RowSelected (tableView:tableView, indexPath:indexPath)
みたいに書けばいいだけでは?
swiftで言えば全部の引数に_付いてる程度のもんだろ。
その程度の違いは一握りのキチガイしか気にしないだろ みなみにswiftではこの辺が少し変わっていて
aFunc(label1 arg1:Type, label2 arg2:Type)となっている
呼び出す時は
aFunc(label1: "foo", label2:"bar")
ラベルがめんどくえって時は_をラベルの前につける
aFunc(_ label1 arg1:Type, _ label2 arg2:Type)
こうするとaFunc("foo","bar")で呼び出せる
ちなみにswiftも昔はObj-Cに寄せて
第一引数のラベルは無視されて生指定して
第二引数以降はラベルをつけるみたいな仕様だったが改善された >>39
ラベルがメソッド名の一部だって言ってるだろ
そこを省略されたらなんもわからんのよ これは単にxamarinのせいではなくただのC#の言語仕様の限界
pythonやrubyのように位置引数とキーワード引数がわけられる言語なら容易に対応できたのに メソッド名が素直に一対一対応しないフレームワークなど使うか?
これが答えだ
いちいちこの対応関係を調べていかなきゃならん
こんなことやってられか?
いまならChatGPTがあるから多少マシではあるがこんなヤク狩りしたくねーのよ >>41
qiitaなどの世に溢れてるswiftコードのほとんどがobjc風ではなくC#風の記法だらけになってるのに、
そんなバカみたいなことに拘ってるのは一握りのキチガイだけだぞ。 xamarinがなぜこんな仕様にしたのかは謎ではある
Javaに寄せるためにこうしたのか
キーワード引数は昔からあった気がするが仕様的に対応できないようなものがあったのか >>44
当たり前だがswiftは上に書いたようにSDKと同じように書ける
両方上手く書けるようにしてるんだよ
というか書けないとおかしいのだが
ランタイムはObj-Cのものを使ってるのだから
xamarinのせいなのかmonoのせいなのかは知らんがswiftと同じようにすることはできたはずなのに このようにxamarinはゴミという評価をして捨てていった
俺も一度はチャレンジしたのだよ
その結果がこれ
ちゃんとメソッドの仕様を合わせられていれば事情は変わっていたかもしれない ちなswiftでのSDKのメソッドシグネイチャは第一引数のラベルにのみ_がついている
こうすることで完全な一対一対応かつ普通の言語のラベル付きメソッド呼び出しも位置引数呼び出しもできるようになっている
素晴らしい👍 C#でキーワード引数と位置引数の混合ができなかったのか
今もできないのかは知らないが少なくとも当時のmonoの環境では無理だったということなのか?
C#は詳しくないのでよくわからないが この引数の仕様は間違いなくswiftが1番美しい
全言語の中で最強だろう >>46
Objective-cなんて誰もがクソだと感じていたけど
iOSアプリ開発ではそれしか使えなかったから
みんな仕方なく使ってただけだろ
SwiftやXamarinが登場してObjective-cが激減したのが答えだよ
テキストひとつ連結にするのに馬鹿みたいに長いメソッドなんて誰も使いたくない
あんな黒歴史のような過去にしがみつくのは愚かの極み Objective-Cとは、
C言語のメモリ安全性と、
Smalltalkの高速性を合わせたプログラミング言語である。 objc,swift,c#を並べて比較したとき、c#を選ぶ理由はガベージコレクションが唯一リファレンスカウント方式ではないという点だよ。
カメラでの動画撮影などの高負荷かつ長時間使うアプリだと安定性に雲泥の差が出る。 話がだいぶそれたがMAUIが流行ってないのは「xamarinで嫌気がさした人たちが戻ってこないから」です 言い忘れた
AndroidはJavaだからSDKがほぼ一対一対応するからと書いたがAndroid SDKの仕様的に匿名のインナークラスをすげー使うのよ
これをC#でやるのがすげー泥臭くてその部分もクソだった
つまり結局そのまま移植するということが実質不可能であり
こんなことなら別々に書いた方がマシとなった まとめるとxamarinがクソ過ぎたせいで
どうせMAUIもクソだろうと思った人たちが相当数いて
MSの技術に不信感を持っているので使わない
現にMAUIのMacはgithubみてもほぼ開発は停止してる 実際俺は仕事でiOSとAndroidのネイティブ開発をやってて
両対応面倒だからxamarin使えないかと本気で移行を考えていたし実際移植作業を開始していた
だからこれくらい詳細に語れる
MAUIを流行らせたい場合はまずは失った信頼を取り戻すことをしないと無理だろう
あとSwiftUIやFlutterが出てきている昨今
今更XAMLとかも時代遅れなのはいうまでもない >MSの技術に不信感を持っている
8のタイル以降これ
8に関わった奴の罪は重い >>56
Xamarin.Androidは↓みたいなJavaのIListener系をActionに変換するクラスを必要に応じて深く考えずに脳死で作りまくれば捗るぞ。
class FuckListener : Java.Lang.Object, IFuckListener {
public Action<object>? OnFuckAction;
public void OnFuck(object you) {
OnFuckAction?.Invoke(me);
}
} >>60
ぶっちゃけ思うんだけどセキュリティとかそういうのだけ更新してくれてたらWindows95で良いんだよね >>62
流石に95は無理
NTをそのまま64ビット化してくれればよかった
おれは昔NTでずっと開発しててめちゃくちゃ安定してた
当時のマシンリソースなんてカスみたいなもんだったのに >>2
Flutterとかでもそういうところあるよね XAMLが嫌?
そんなあなたにMAUI Blazorをどうぞ >>63
3.1に比べれば95は神
NT? 重すぎでしょ >>68
95なんて落ちまくりだっただろw
セキュリティもやべーし >>69
だからセキュリティだけは更新してと>>62で言っただろ
文盲かよ馬鹿かよ無能かよw OSのセキュリティだけ更新して製品の安全性を保てるとか思ってるやつ
プログラミングやってないんやろな、とは思う >>72
何言ってんだお前?
今のOSは全部そんな感じだぞ >>70
落ちるのは単なるバグだぞ
あとOS的にセキュリティは一切考慮されてない仕組みだから無理 >>68
今のwindowsは全部NTベースだぞ
windows10はNT10.0だ >>75
95は32ビットフラットメモリモデルのプログラムがかけたんだぞ
3.1のセグメントモデルを知っていれば神としか言いようがない
3.1のファイル操作はDOSを使うからガックガクだったが95のプリエンプティブなマルチタスクは神
NTは確かにすでにあったけど起動するだけで眠くなるアプリ無いし
visual studio codeのc#とmauiの拡張機能が絶望的な品質だからだろ
iosアプリ開発はmac必須なのにvisual studio codeが使い物にならないせいでどうにもならない >>76
3.1触ったことあるってマジで何歳よ?
ジジイの俺ですら検証用のマシーンでチラッと見たことがある程度で触ったことはないぞ MAUIはmacOSはもうずっとCatalystでお茶を濁すつもりなの?前に触った時Windowサイズすら変えられないと知って絶望した
C#はもう観念して、せめてデスクトップに集中してほしいんだが >>79
Windows3.1は1990年代の前半だから40代の元パソコン少年とかなら触ったことあると思うぞ
自分は45歳のオッサンだが高校に上がって少し経つ頃にはPCはWindows3.1一色になってた >>82
俺もどっちかというとパソコン少年だったがMSXの後はwindows95まではコンシューマゲーム機しか触ってない
3.1触ってるやつは相当レアだと思うよ 今思えばWindowsは国民機を潰すのが目的の1つにあったろう
技術立国日本の零落の始まりだ
日本が誇れる企業はトヨタしかなくなった
AI自動運転とかで同じことが車で起きたら終わりだ XAMLを削除して新しいモダンな描画システムを作るべきだよ
FlutterとかSwiftUIみたいに書けるやり方でさ SwiftUIはよかった
まだ作りかけって感じは否めないけど(テーブルが10列までしか作れないとか) 最近のフレームワークは最初からUI書くために設計されてるからなー
ツリー構造をいかに手数少なく その辺のフレームワークの設計はMSの専売特許だったはずなのだけどね
どこでおかしくなったのか >>80
ビルドにMac必須だろ
とくにライブラリを作るなら実機が手元にないとまったく開発が捗らないし >>81
ウインドウサイズは変えられるようになった
フォーカスの移動はできない シミュレータなしだと都度実機へ転送でつらないか
いまはリモートシミュレータがクラウド化されてる? ipaに署名できない
つまりリリースビルドができない 現状ではUIKitやらAVFoundationやらSensorKitやらを叩いてゴリゴリと自前でライブラリを作らないと使い物にならない。
そのライブラリの実装テストの試行錯誤はMac実機とiPhone実機の2つがないとまったく捗らない。 まあ、実際使い物にならないから流行ってないんだけどね
廃止予定のVisual Studio for MacをVisual Studio Codeがまともになるまで延命するでもしないとMAUIまるごと完全消滅しそうではある >>81
mac catalystはswiftで開発してもゴミだからな。
AVFoundationもまともに動かないからバーコードも扱えないし業務アプリには致命的すぎる Java拡張の方が評価も更新頻度も高いというね
MSくん何がしたいんやC#もういらんのか? C#はVisual Studioで使うものだからどうしてもCodeの方はおろそかになるよねって話
Codeの拡張機能JSだし開発者もかぶってない 正直mauiはバグ多すぎてデバッグつらいからmaui blazorでui作るほうが早くできる >>101-103
Xamarin開発者の99%はmonoからの流れでLinuxとMacだからな。
そこをスパッと切り捨ててWindowsでVisual Studio使ってる人だけをターゲットにした結果がMAUIの現状だろう。
しかもその層はスマホアプリ開発の経験ほとんどなし。
Windows Phone時代にチョロっと触っただけだというね。 まあC#一派って.NETにこだわりあるんだろうし
暗黒期を支えたプライドでこだわってるんだろうけど
時代は変わってることに気がついて欲しい
C#は望まれてない
windows phone時代のアーキテクチャは早すぎた
今こそ復活の時 VisualStudioでしてきたことを今更VSCodeでやってられんということでしょう
いい加減.NETの遺産は滅ぼして良いと思う 2022年のピークからコミット数相当落ちてるね
https://github.com/dotnet/maui/graphs/contributors
バグ放置すんな人増やせって炎上してたのにコミッタ増えてないし改善する気無いね >>111
UWPとiOSとAndroidで「共通でできる機能」だけを集めたもの。
逆を言えばこの三者のうちひとつでも実装できない昨日はバッサリ切り捨てられている。
つまり何も良くなっていない。 >>112
ええええ
これ以外開発するものないだろ
それとももうBlazorに全移行せよってこと? AvaloniaUIにスター数負けてるのにオープンissue3倍
終わってる 星の数ほどディスれるけど要点をまとめると
・XAMLがHMLT5+JS(TS)と比較してすべての面で劣る。
慣れてるXAMLerですら新規プロジェクトで一から実装してると萎えるくらい面倒くさい。
逆にC#や.NETは神、Tauri+Rustで実装してるとRustの標準ライブラリやサードパーティーライブラリがまったく充実してくて面倒くさすぎて萎える。
・人気がないからコミュニティが過疎りまくってて限界集落状態でコントールもライブラリもなにもない、エコシステムが崩壊している。
特に認証周りのライブラリまでOSSに依存していて話にならない。
これがReact、Flutter、Electronなんかと比較してMSの開発環境が終わってる一番の理由。
MSのないならお前らプログラマーが作るんだよぉ!?はストイックすぎる、誰もこんな開発環境使わねーよ。
・破壊的変更が多すぎて過去のノウハウやナレッジがリセットされて使い物にならず何も残らない荒野になり再度開拓する気力もなくなりみんな逃げ出す。
WinUI2→WinUI3だけでもかなりの破壊的変更だらけでこんな環境誰も怖くてさわれない、ましてや自社どころか顧客のプロジェクトでは採用不可能。
WPFでXAML触ってたからいけるんちゃう?とWinUIに手を出すと内部実装がまったく違っていて手も足も出ない、また一からキャッチアップのはじまり。 まぁ、MSが割り当ててる開発者が少ないから
WinUI3もそうだが普通にクソ品質なんだよな
これが最大の問題
MSが力入れてないんだからそもそも流行るわけがない そもそもMSがOfficeもTeamsもSkeypeもOutlookもどれもこれもぜーんぶReactとReact Nativeで作ってんのどゆこと!?ってなるわ
マジで俺等のこと馬鹿にしすぎだろ MSの黒歴史
windowsアプリ作れるようにしたで
Visual Studio+Win32で作ってやw
→イベントハンドラやウインドウ関連のAPIがゴミ過ぎるためにまともなUIが作れない
MFC作ったで
C++でオブジェクト指向やでw
→結局ただのラッパーなのでCDocumnetやCViewの本質的複雑さは変わらず誰も使わない
しょうがないからVBで画面作ってやw
→結局画面はこれで作るのが標準になる
ただし、業務ロジックは裏のC++プロセスへ投げることになるのでたかが画面一枚作るのに死ぬほど手間がかかることに MSの黒歴史2
.NET Frameworkっていうの作ったでw
Javaより使いやすいC#いう言語も作ったでw
今回はGUIも作りやすうしといた
みんなつこーてや
→フォームアプリのゴミさ加減は相変わらずなので大規模になるとまともにUIが作れない
WPFいうの作ったでw
流行りのXMLで全部書けるんや!!
これが最強やろ!!
→XAMLがゴミ過ぎて誰もついて行けず
そしてWeb全盛時代へ突入
しかしMSはこの分野での武器はゼロ
IE6というレガシーで足を引っ張ることだけが仕事になる MSの黒歴史3
やがてスマートフォン全盛時代へ突入
Windows phone作ったでw
iPhoneやAndroidより使いやすいで
あと今回はみんな大好きJavaScriptでアプリをつくれるようにしといたでw
UWP言うねん凄いやろ
これに合わせてWinRTいうのも作ったで
裏側はwindowsのランタイムや!!
これからは全部これでええんやで
これで今度こそ勝ちや
→windows phoneは空前絶後の大失敗
WinRTは結局XAMLに囚われる上に
.NETの機能を使うにはめちゃくちゃ面倒で誰も使わず MSの黒歴史4
IE6の死によりブラウザのフロントエンド開発が加速する
その中でReactやVueが流行り始める
仮想DOMを装備して状態を意識せずに書けるスタイルが人気となり爆発的普及を見せる
Blazor作ったやでw
WebアプリをJavaScriptやなくてC#で作れるんやでw
これが顧客が本当に求めたものやろw
→そもそもC#は誰も求めていないので誰も使わず msの出すフレームワークよりelectronで作ったほうがいいってみんな気づいちゃった いやそんなの本職のフロントエンドプログラマーなら10年以上前から気づいてたから
XAML使う理由がC#と.NET使いたいためだけに我慢してXAMLとMVVM学習してただけの話
.NETだけはとてつもない下位互換性を堅持してるのにフロントエンドフレームワークが常に破壊的変更されちゃただでさえXAML書けるやつもノウハウもナレッジも少ないのに誰が使うねんて話
個人的にC#と.NETでのアプリ・ビジネスロジック実装は今でも神レベルに使いやすいし便利だからC#/.NETからReactやViteやSvelte使えるようにしてくれりゃ全部解決なんよな
まぁ昔からずっと主張してる俺の持論でMSは社内のフロントエンド開発部門の毎年の予算作るためだけにまったく役に立たないゴミみたいなフロントエンドの仕事を用意してやってるだけやで絶対に MSはどうにかしてC#を使わせようと頑張ってるんだね
利権かなんか知らんけどさ 別にWPFでもいいからXAMLを放棄してhtml5にしてくれたらそれでよかったんだけど、Xamarin
買収しちゃってXAMLがさらにカオス化というのがな。 WebView2のMac版とLinux版出してくれればそれでいいよ
スマホはもうC#でやりたいやつ誰もいないだろ、、、 一番期待してたBlazor Hybridも既存のRazor構文とMAUI抽象化レイヤーというゴミ実装でオワコン
なぜTauriのtarui::commandのようなnvoke Commandsの美しくも簡単で便利な実装にできなかったのか
まぁそもそもほんまにMS本社レドモンドで作ったのかも怪しいくらいゴミやから外注に作らせた説もぜんぜんあるわな
ほんまTauriでRustじゃなくてC#使えたら最強やのになぁ Tauriの美しさは素晴らしい
デスクトップに限らずそのうちモバイル業界のガワアプリハイブリッドアプリのプラットフォームをTauriが統一すると思う Tauriで開発されてるアプリでいくつか注目してるのあるけど2~3年立っても一向に開発終わらなってないのがちょっと不安だな
やっぱりElectronに比べると開発速度は出せないのか >>130-131
Tauriはロジックの実装がRustなのが最大の魅力なんやがそれが足枷にもなってるんよ
例えば俺が個人利用のためにC#+WinFormsで作った圧縮・展開アーカイブアプリをTauri+Rustにポーティングしたんやが
RustにはC#のsharpcompressのような統合圧縮・展開ライブラリが存在しない
それどころかC++のlibzipやunrarみたいなのもなくてRustでヘッダー読んでとかめちゃくちゃ大変やった
ここがC#どころかC++にすら劣る部分やねまぁRustの使用領域を考えるとトップエンジニアが触るんやからそうなるんやろうけど俺ら下々のプログラマーにはちと荷が重い そもそもrustの速度必要とする一般アプリなんてそうそう作る機会ないだろ
SNSアプリなんてWebAPI叩いてデータベースいじってUI表示とか
CPUインテンシブなアプリなんてなぁ・・
画像処理系のアプリとかで
例に出た圧縮も自前で実装するならいざしらず
結局外部ライブラリ呼ぶだけだしな つか、libarchiveはもうwindowsに同梱されてるよな Windows限定ならCOMで少々面倒だが7z.dllで全部完結するんだけどWinFormsをTauriにリプレイスするってことはマルチプラットフォームもある程度考えてるだろうしそうはいかんか
>>134
Tauriの利点はどっちかと言うとバイナリサイズの方だと思ってる
VSCodeやDiscord辺りが先陣切ってTauri化してくれたら神なんだがまあ無理な話か tauri久しぶりに見に行ったけど2.0まだなんだなぁ tauriはなーelectronに比べてpreloadもいらないしフロントエンド側はめちゃくちゃスマートに書けるんだけど
Rust側で何かやろうとするとガッチガチ言語すぎてギャップがすごい
C++とかやってた人は楽チンなんだろうけど >>138
tauriでrustを使う理由って「rustで書きたいから」以外の理由がない
全部JSで書いた方が速いし楽
しかし男には全てをrustで書くという夢がある そんなに心配しないでもそのうちGPTがUIをHtml+JSで出してくれるようになるよ
現状でもGPT-4oがすごいらしいじゃん
プログラマはロジックを書くのに集中すればいいってわけよ 俺はさっさとAIでER図やExcelのテーブルからDBとAPIをジェネレートしてほしいんだがな
一番AIに向いてるに内容だと思うんだが一向に出てこないからAIもぜんぜんたいしたことねーよな
個人的にインフラだけでなくDBやIFやバックエンドは自動生成してフロントエンドに集中したいわ
これ日本のデベロッパーが一番ズレてると思うのがプロダクトで一番重要なのってロジックじゃなくてUI/UXのフロントエンドだからな
日本人はデザインセンスやそういう発想がなさすぎるからソフトウェアがゴミなんだよ
今まで仕事しててこの分野で中国人に30年差をつけられてるのも納得って感じ >>142
嫌だからその程度生成してるって
テーブル定義貼り付けてみろ
全部生成してくれる WinUIは3にもなって未だにXAMLでウィンドウのサイズプロパティがなくXAMLでサイズ指定ができない
Githubでも散々叩かれててウィンドウサイズを変更する機能のないUIフレームワーク(笑)って投稿にいいね!めっちゃついててクソワロタ
なんでウィンドウのサイズ変更するためだけにコードビハインドかつP/Invokeで3行もコードを書かんとあかんねん
MSのフロントエンドアーキテクトってどいつもこいつもセンスゼロでほんま無能すぎるやろ 普通にWinFormsがバリバリ現役やからな
難点はWinFormsやとWin 11のFluent Designがまったく使えんことやな
そもそもmacOSやLinuxと違ってOSのGUIでMicaやAcrylicをネイティブサポートしてない時点でWinUIもMAUIも糞もないんやけどな
DevExpressが販売してるFluent FormsならWinFormsでMicaやAcrylicのカスタムコントローラーが使えるんやけど年間サブスクで$999からやから使えるわけない
なんでこんなMSが標準で用意せんとあかん機能をサードパーティーがビジネスにしてメシ食ってんねんおかしいやろ
まぁ流行る要素皆無よ >>146
フォームは画面遷移があまりにもゴミ過ぎるからねえ
あんなの標準でやれってめちゃくちゃ >Fluent Design
それ意識高い系が好きなやつやん fluentやるにしてもelectronかtauriで十分 そうそうFluent DesignでDesktopアプリ作るのもReact NativeやElectronやTauriの方がパッケージ充実しててめっちゃ楽なんがイミフすぎるんよな
MSはもうフロントエンドを他からパクってきてロジックだけC#で使えるようにしてくれ余計なことせんでええ
SwiftUIが最強だぞ
なぜパクらないのか 技術力がないからだろう
JVMパクった時のように得意の同じアーキテクチャで丸パクリでいいのにそれすらできなくなった >>149
Office 365で使われてるからもうネイティブ版は息してないな
Windowsネイティブアプリしゅーりょー C#以外禁止ならBlazorでいいけどそうじゃなければReactで書きたい フロントエンドはReactでもVueでもViteでもSvelteでもなんでもええんや
ロジックだけC#使いたいんやなんで誰もが求めてることをやらんのやMSアホすぎる あとXAMLと双璧をなすめんどくさアーキテクチャのMVVMもオワコンすぎる
まぁそもそもC#の設計思想がC++からの移行を想定してて面倒な記述や手続きを求められるんやが
あまりにめんどいからWinUI3でもMVVM使わずがっつりコードビハインドやハードコーディングで書いてるからな
それにしてもXAMLもMVVMもとにかく手間がかかるJSやPythonが好まれる時代にまったくマッチしてないのアーキテクトやエンジニアのセンスゼロと言わざるを得ない C#で書いたコードをNativeAOTしてそれをRustでラップしてやればTauriでロジックをほぼC#で書けるんじゃね?そんなことやる気ないから知らんけど Tauriはもうブームさっただろ
時代はwailsだろ Tauriはモバイルアプリ分野で普及しそうで期待してる
ガワアプリハイブリッドアプリを手軽に作れて、ReactNativeやCapacitor(Ionic)に対抗できるポテンシャルはあると思う >>158
すまんが現場じゃJSとpythonって嫌われ者だぞ IT業界
jsとpythonが人気に“見える”のは高校大学とかの教育現場までカウントされてるからだぞ
pythonだって機械学習ぐらいしか使わない
jsだって小規模開発ぐらい
規模が大きくなるにつれてpythonなんて能力不足だしjsはバグの温床になりやすいから極力排除する フロントエンドのフレームワークのスレでそんなん言われてもね Blazorは違う、フロントエンドをC#で書きたいなんてもう誰も思ってない
WailsやTauriのC#バージョンが求められてる 「誰も」とか「ゼロ」とか「極力」とか、
そういう極端な言葉使ってるやつは視野が狭そうに見える ReactでもVueでもBlazorでもComposeでもFlutterでもなんでも好みのものを使えばおけ
Reactが学習コストも資産も充実してるってだけで、どのフロントのフレームワークを使っても動くものを作れる >>168
求められてないけど
Wails使えばGolangで書けるのにいまさらC#にしがみつく必要なし WebView2がクロスプラットフォームになれば事実上そうなるんだけどな
ガワはMAUIでもAvaloniaUIでもUNOでもなんでも良い
https://learn.microsoft.com/ja-jp/microsoft-edge/webview2/roadmap
一応ロードマップにはMacOSやLinuxはあるんだけど、音沙汰無いからやる気なさそうだけど。 goも不遇だよね
Dart開発しました
go開発しました
でもGoogleではTypeScriptが標準です! >>162
そりゃお前の頭ん中な
今やその2つ+Rust/Go以外はやる価値なしと判断されてる それ言ったらRustはもっと将来性あるというか確約されてるし人気あるだろ
まぁ俺もGo触ったことないんであれだが比較すべきはRustでそのRustと比較してどんなメリットあんの?
Rustは名前と人気だけ先行してみんなイメージだけで語ってるやつ多いがぶっちゃけ開発環境としてはなんもなくてほぼフルスクラッチになるからC++よりもきつい
そのRustよりも明確なメリットってなんかあんのか >>178
そりゃお前の頭ん中な
あなたのお気持ちとか知りませんやんw 今のRustの用途ってCやC++の既存の機能を置き換える実装がほとんどなんじゃねーの
自分でなんでも書けるからRustなんてよゆーってプログラマーなんてそんな多くねーだろ >>183
そのお前の頭の中の「勝敗」
誰得やねん? JavaでAndroidアプリ作るよりC#のほうが解りやすくてMAUI使ってる俺は変態なのか?
まあ、主に自分で使用するものをVBAやC#で作った経験しかないからな。
ちなみにGoglePlayでツール系のアプリ公開してるけど2200回ダウンロードされてアクティブなデバイスは300程、Firebaseのデータやプログラムを定期的にアップデートしてる。 わざわざJavaで書く意味がわからんKotlinで書くだろ…
しっかしたまにC#やJava触るとセミコロンだったり型が前置だったりが古臭く感じるなあ ウィンドウをサイズやポジションを設定するプロパティも機能もない
サイズ設定
IntPtr hWnd = WinRT.Interop.WindowNative.GetWindowHandle(this);
WindowId myWndId = Microsoft.UI.Win32Interop.GetWindowIdFromWindow(hWnd);
AppWindow appWindow = AppWindow.GetFromWindowId(myWndId);
appWindow.Resize(new SizeInt32(500, 200)); ポジション設定
m_window = new MainWindow();
var hWnd = WinRT.Interop.WindowNative.GetWindowHandle(m_window);
Microsoft.UI.WindowId windowId = Microsoft.UI.Win32Interop.GetWindowIdFromWindow(hWnd);
Microsoft.UI.Windowing.AppWindow appWindow = Microsoft.UI.Windowing.AppWindow.GetFromWindowId(windowId);
if (appWindow is not null)
{
Microsoft.UI.Windowing.DisplayArea displayArea = Microsoft.UI.Windowing.DisplayArea.GetFromWindowId(windowId, Microsoft.UI.Windowing.DisplayAreaFallback.Nearest);
if (displayArea is not null)
{
var CenteredPosition = appWindow.Position;
CenteredPosition.X = ((displayArea.WorkArea.Width - appWindow.Size.Width) / 2);
CenteredPosition.Y = ((displayArea.WorkArea.Height - appWindow.Size.Height) / 2);
appWindow.Move(CenteredPosition);
}
}
m_window.Activate(); これが2024年の最新のマルチプラットフォームフロントエンドフレームワークとかあまりにもひどすぎてクソワロタ
そしてMS自身はOffice365もOfficeもEdgeもReact、VScodeはElectronで実装しててクソワロタ GoogleもMetaもTwitterも社内で使っててものすごく便利で素晴らしいからフレームワークをOSS化して人気でたのに
それがMSの場合自社ですら使わないゴミをOSS化してるから当然だれからも見向きもされないままオワコン化
いまだかつてこれほど酷かったフロントエンドフレームワークは初めてだわ そらまああんなでかい会社で一枚岩なんてありえんけどな
逆に開発者が環境を強制されない自由な社風とも言える
自分に都合のいい一面だけ見ても理解できんよ