Flutter vs .NET MAUI vs React Native 2
.NET MAUI=C#←神
React Native=JavaScript←世界的に広がってるが言語仕様がクソなのは言うまでもない
Flutter=Dart←TypeScriptにも負けC#にも負ける生まれながらの敗北者 クソ暇人.NET MAUI HighSchooの宣伝のためだけのクソスレ Dart はマクロを導入するらしいね
C++ で嫌われたメタプログラミングを性懲りもなくw
Java や C# にマクロがない理由はわかってるくせにね
Google は自分が面白いと思う機能はどんどん勝手に作っちゃって、オレ様すげーって思いたいんだろうな
飽きたら捨てるだけだしね (´・ω・`)もう誰もスレタイにあるRNの話してない… >>5
正直海外だとReactNative多いよ
Office系とかそうだし
SharePointはなぜかXamarinだが… https://mevius.5ch.net/test/read.cgi/tech/1661511605/715
715.NET MAUI HighSchool2022/11/26(土) 19:55:08.85ID:xLMoOceS
>>713
わかったもうMaui関連のスレしか行かないようにするわ
Flutterやろうよ!!! 4
https://mevius.5ch.net/test/read.cgi/tech/1648427137/501
501.NET MAUI HighSchool (ワッチョイ df01-1zqz)2022/12/10(土) 16:40:36.14ID:i3sOjwlr0
>>500
デスクトップ作るなら.NET MAUIのほうが良くねぇか?
まぁそれでもWinUIとかのデスクトップフレームワークには劣るけども フラカスさんはFlutterスレより先にXamarin,MAUIスレでFlutterのアップデート情報を公開します まあ、Flutter スレは過疎ってて、存在意義が薄いよね
Flutter の話はここだけで十分なんじゃないの? MAUIの知識も危ういのに、フラカスとかあんまり煽るのもどうかと思うわ。 フラカスもFlutterがどういうふうにできてるかわかってねぇからなw
ネイティブAPIラップして動かしてるのわかってないのマジでウケたwww >>9
なぜおまえの勝手な宣言が他の利用者に影響を与えると思うんだ? 毎日朝から晩まで5chでflutterディスって片手間でアプリ開発ごっこする人生でした。
ポートフォリオ?もちろんバグ取り中です。
5chが優先ですから。 なんでまた変なスレ立ててるの?自分のスレが既にあるでしょ >>13
MAUIの知識が十分あればほかのフレームワークで解決してること、Xamarinで解決してること、Xamarin.formsで解決してたこと、MAUIがやっと解決したことをがわかるでしょ。
UIフレームワークとしては別にflutterを笑えるものでもない。 GoogleもJavaやKotlinでクロスプラットフォームフレームワーク作っとけば馬鹿にされなかっただろうにDart(w)とかいう生まれながらの敗北者言語選んじゃったことが間違ってるよね >>20
KotlinはJVMの他にNativeやJSがあるけどJavaはJVMしかねえだろアホかな
どうやってiOSで動くと思って書き込んだんだろ(w) 毎日朝から晩まで5chでDartディスって片手間でアプリ開発ごっこする人生でした。
ポートフォリオ?もちろんバグ取り中です。
5chが優先ですから。 >>21
java自体をobject-cでラップしてvm起動してその中で動かせばいいんじゃない?(適当) >>21
Dalvik も ART も知らんのだな… >>25
Dart はモノはともかく、存在そのものが悪いのよ
ユーザーのことを考えず、作りたいから作っただけの言語 >>26
JVMで動いてるってことじゃなくてJVMで動く中間コードを生成してるからってこと
JavaのJVMコンパイルで生成してくれる中間コードをネイティブにAOTコンパイルする機構が必要があるってことをいいたい
泥にはそれがOSに組み込まれてる >>27
Dart 1はホントにポンコツで、誰のことも向いてなかった。それはそう。
2.0で相当変わったんよ。型もついたし、Flutterに使うために、constの影響範囲とまで変えたからな。 >>24で言われてるように何かしらの中間コード処理機能をiOSアプリに同梱しちゃえばいいんだけど、まあ、それのデメリットを抱えながらアプリを作る理由がないよね >>30
JavaScriptからネイティブに大幅方針転換したからね
ま、その時点でDart言語は終わった >>31
これはダメなのでは?iOSでは仮想マシンやインタプリタは基本ダメだった気がする。
>>32
俺は逆だけどなぁ。JSはJSがあれば良くなってきた。 >>31
Dart も VMで動いてるでしょ
そのデメリットは Flutter が常に抱えてるものだよ >>23
何も作ってないのがよくわかるスレでワロタ >>25
じゃあなぜTypeScriptとかいうC#以下の後継に負けたの?w
ウケるwww >>40
何が?
C#やDartと同じでネイティブにコンパイルできるようにすればいいだけじゃん?
Dartにこだわる必要がない
むしろゴミ言語なんだからあそこで終わらせとけばよかった >>43
Javaはネイティブにコンパイルできねえって >>44
なぜ?
なぜ?C#やDartはできてJavaはできないの? >>45
Javaは中間コードしか生成できないから
以上 >>30
型ついたら変わると思ってるのってアホだよなwww
言語設計が悪いんだから型どうこうの話じゃない >>47
それコンパイルさせる機構をiOSに入れるシステム作ればいいだけでは?
C#もDartもそうだろ? >>41
勝ち負けの意味がわからん。人気的な意味? >>49
その意見すでに>>24で出てるけどどこかのタイミングで中間コードをJREとリンクさせてネイティブに変換しなきゃいけないよね?それがどんなにコスパ悪いことかわかって言ってるか?
だからお前にバカって言ってるんだよ
ちょっとガチギレ >>50
人気的な意味でも評価が高いって意味でもそう >>45
C#もできるとは言わないぞ。
厳密に言えばAOTもなくはないけど、JIT効かせた方が効率の高い言語だから。
C#もJITでの方が効率が良い。 >>51
だからそれを今C#やDartがやってんだろ? >>51の問題を解決したのがKotlin Nativeとして既に解決してる >>54
外部IDEでコンパイルさせたSwiftなんかのコードをぶち込めばいいだけでは? >>37
なるほど
Flutter ではリフレクションをサポートしないんだね
都合の悪い機能は制限してもいいなら、Java でもKotlinでもGoでも良かったはず なぜC#やDartにはできてJavaにはできないのか全く理解できん
そういう機構作ればいいだけでは? >>58
それじゃSwiftじゃん。
PCでクロスなAOTするなら何でもありだよ。RoboVMとかあったじゃん。 >>60
VMの特性としてJITのプロファイリングが無いとパフォーマンスが出ないのでメリットが無いって言ってるでしょ。
基本的にボクシング回りが遅いのと、バイトコード上ではジェネリクスが型を消す形で実装されてるので走らせないとわからん。 >>61
だから何でもありだっつっただろ
なんでもありの中Dartを選ぶ必要性がない >>64
クロスで全部まるっと挙動まで揃ってるUIフレームワークがあるのと、それをホットリロードしやすい仕組みになってるからな。
スレッドも基本的にシングルスレッドで、UIスレッドときっちり分けられたりとモバイルに向いてる。
都合が良いだけで、ベストじゃない、というのもわからんでもないが、それでも都合がよいよ。 swiftuiはInjectionIIIとか例外はあるものの基本的にホットリロードできないからiosネイティブデベはflutterを使いたがる
androidネイティブは性質上制約なくホットリロードできるからandroidネイティブデベはflutterを使いたがらない 真面目にやりたいのならマ板でやれ
クソコテのためのスレいくつたててんだよ >>75
WinUIは遥か昔からAcrylic対応してたぞ
GoogleやAppleが遅いんだ 俺は何言いたいがわかるが、面倒くさそうそうな展開になりそうだからほっとくのが吉やなw まあUIはそのときの一番流行りの感じにしとけば批判が少ないよね プログラマーとして働いたことない
初心者のC#ガイジさんじゃん >>85
?
構ってほしいのはコテつけてこんなスレ立てしてるガイジでは? 仮に構ってほしいと返ってきたらどうなんだ?
この質問何の意味があるんだ?! KotlinのみでiOSアプリ組めるのすごくね?
Jetpack ComposeはReact並みもしくはそれ以上に使いやすいから好き
https://zenn.dev/yt8492/articles/24d6a01d57e9da Jetpack ComposeってJVMのみじゃなかった? >>90
Linux,Windows,AndroidはKotlin/JVM
macOSはKotlin/JVM or Kotlin/Native
iOSはKotlin/Native
ブラウザはKotlin/JS + WebAssembly
で動いてる Jetpack Compose じゃなくてCompose Multiplatformだな
Compose MultiplatformはAndroid/iOSともに完成度が高い
今年中にはReact, Flutter, Composeの三つ巴になりそうね JetBrains が flutter もどきを作ったのかw
イラネ >>94
そんなこと言わずに使ってみて
むっちゃ使いやすいから >>94
Composeは泥で主流になりつつあるよ
泥カンファレンスで毎年取り上げられまくってる まずDartとかいうゴミ言語を使わなくても良いって時点で使いやすそうだな Composeホットリロードがないけど扱いやすいとは思う Compose がそんなに素晴らしいなら、いずれ Google は flutter を捨てるだろうな
今 flutter を始めるのはやめたほうが良さそうだね
Dart で作ったコードは flutter 以外に使い道がないから、ゴミになってしまう
コードは資産だからね rememberがちょっと気持ち悪いな
useStateの時も思ったけど
宣言的UIのここが嫌い
純粋関数なら最高に気持ちいいんだけど 学者みたいな理想を追いすぎてもしょうがない
何事もほどほどで十分 >>98
@Previewもホットリロードもあるでしょ、おじいちゃん >>99
いやFlutterはGoogleの自社製品だし、、
JetBrainsはGoogleではないよ?
>>100
ものすごくわかる
泥だとViewModelと二重状態管理になったりするから、黒魔術みたいなものと思い込まないと気持ちがよくない Previewは便利そうだ
マルチプラットフォームの完成度、エコシステムの安定性次第だけどReactNativeから乗り換えてもいいかも 普及させたいなら宣伝費使って大々的にやるしかない。
ここで便所の落書き増やしても自己満にしかならないよw >>105
普及させたい、じゃなくて泥で既に普及してる 確かに泥ネイティブからすると、remember とかrememberSaveable はActivity と独立駆動してて黒魔術臭がすごい
上手く使いこなさないとすぐ再Composeするし つか、composeのナビゲーションドローワってどうなってんのあれ..
左右の端のスワイプによるバックナビゲーションとの絡みで、
端からスワイプしなくてもナビゲーションドローワが出てくるようになってんだろうが、メインコンテンツがLazyColumnなどの縦スクロールさせるコンテンツだと
縦スクロールさせようと思ったら横スワイプのドローワが反応したり
ドロワーを出そうとしたら縦スクロールと認識されたり
相当ひどい事になってんだが >>103
自社製品だから捨てるんだよw
Google はシェアを取れないと判断したら捨てるだろ
奴らには開発者の資産を守るという感覚がないからな
面白そうならやってみて、飽きたら捨てるのが Google まぁモバイルアプリはもうあと数年の命って感じだろうな
MRが来たらC#以外のモバイル開発言語は死ぬ >>111
それはしゃーない
C#繁栄への犠牲だな
MAUIはMAUIでWindows,Mac用って割り切ればまぁいいだろ >>110
そんな達観的になっちゃって
もうモバイルアプリ開発は飽きたんですか? ちなみに.NET MAUIでARアプリ開発するためにいろいろ調べてたらEVERGINEっていうゲームエンジンを見つけた
Unityと違って.NET上で動くから3D部分はEVERGINEでUI部分は.NETみたいな形で両立できそう
MR用テンプレートがインストール時点で容易されてあったりToolkitが用意されてあったりMRするならUnityよりこっちが使われるようになるかもしれない
(ゲームは依然Unityだろうけど)
https://evergine.com/ >>113
いやコンシューマー向きのMRデバイスが出るまでは.NET MAUIいじるつもりだよ
.NET MAUIはBlazorWebViewのおかげでWebアプリを高速にモバイルアプリに出来たりかなりすごいと思うわ
この辺はどのクロスプラットフォームでも実現不可能だろうね このまえアイデアクティブっていう日本のMicrosoftやメタが主体のアイデアコンテストにMRコンシューマー機を普及させるアイデア出したからこれが評価されれば一気に広がりそうではある きみの定年までに一台3万くらいでMRが普及するといいね 業務で使うならReactNative一択でもまだまだ難点が多く快適とは言えない
MAUIは簡単で良いと思うがXamarinの負の遺産のせいで説得と実績作りに難儀
FlutterはDartの壁が厚いので多分一生使わない
Composeは期待の新星でReactNativeのツラミ成分を解決してくれるなら乗り換えたい >>117
3万は無理だね
今のハイスぺスマホがだいたい15万~20万程度だからそのくらいで売れればとは思う
今のMicrosoftHoloLens2は1台50万とかするしね。 >>118
MAUI Blazorのポテンシャルの高さマジでやばいよな
このポテンシャルの高さを気づく人が増えたらマジで一気に形勢が逆転する >>107
黒魔術わろた
たしかにそんな感じ
@Previewなんか重たいのが気になってしまう >>110
年中5chで妄想垂れ流して片手間で開発ごっこするしょうもない人生でしたw ちょっと Compose Multiplatform 触ってみた
Compose の remember はたしかに黒魔術臭がするが、riverpod の watch よりずっとマシだわ
もう flutter イラネ compose普及の立ち上がりが何故か遅い気がするんだよな
flutterは1.0あたりから一気にいったような気がするが
>>108もそのうち誰か指摘するだろと思って放置してたが(気にしてるの俺だけかもしれんが)
もう、stableから8ヶ月くらいになるんだっけか
material 3の対応も進んできたが >>121
重たいね
テキストの色を変えるだけなのに、20秒かかったりする
1秒で終わることもあるんだけど >>126
それSwiftで開発させられるんじゃねww >>126
一台30万超えとかどの企業が現場導入するんだ
流石にゴミ 30万ならドローン機体買うわ
ドローン開発もAIをかなり使うから楽しいぞ >>128
すでに1台40万するHoloLensは色んな会社に導入されてるの知らないの? >>108
ナビゲーションドロワーって、泥では最近あんまり使われてない気がする
ボトムナビゲーションバーでルーター管理が覆い Compose を触ってみているが、いいなこれ
Compose Multiplatform がちゃんと動けば Flutter いらないな
Compose と MAUI の2択でいい
riverpod や freezed みたいなクソから人類を解放すべき ComposeいいけどHiltが分かりづらい…MAUIみたいに簡単にして Androidアプリのライフサイクルが面倒くさすぎる
ApplicationにActivity、ViewModelでインスタンスの生存期間が違うのを意識しなきゃあかん
ま、HiltだとApplicationにDIしてシングルトンにするとか、interfaceに@Bindsでリンクさせるとか、ApplicationContextでシングルトンコンテキストを引っ張ってくるくらいしか使わんよ 泥専でxamarin、flutter、ネイティブのfragment view、composeといろんなフロントフレームワークやってきたがどれも一長一短だわ
あとは今年度末までにreactを極めて総合評価を下すぜ >>144
そうか?アレがあるおかげでやりやすいと思うけどな。
Windowsにも似たようなものがあるべきだよなって思うぐらい。 Windowsにはそれがないからスリープ復帰で通信やり直しとか時計見ないとわかんね。 >>151
ないわけ無いだろう…
PowerRegisterSuspendResumeNotification() は違うのか? >>151
確かにonStop、onDestroy系にフックできるはありがたい
Windowsにそれ相応があるのかは知らん >>4
C#にはメタプログラミングの方法が腐るほどあるのだが浅ぱちゃのしったかくんが語ってんじゃねーゾ?www メタプログラミング嫌い
zigのcomptimeくらいわかりやすくしてくれ 来週、 Stadia が終わるらしいね
デベロッパーはかわいそう
Flutter もポイされるかもしれないね
デベロッパーのことなんか気にしない会社だからね FlutterはDartとWidgetがゴミすぎるわJS(TS)にしたReactはやっぱ賢い
MSも毎回やらかしてるが言語という車輪の再発明をしてそれを押し付けるとかマジ余計なんよ大きなお世話
MSもXAML捨ててHTML5+CSS+TS(JS)にすればC#は良い言語だからMAUIやBlazorでワンチャンあったのに大失敗よ
個人的にVueやSvelteが書きやすさやわかりやすさの点で好き >>157
そんなHTML,CSSすきならMAUI Blazorでよくね?
https://youtu.be/2dllz4NZC0I typescript/javascriptでいい
blazorは宗教的にtypescript/javascriptを使いたくない人向け TS言語もReactもいいアイデアだけどやっぱり基盤の不安定さが逃れられない課題になっちゃってるよね
その点では.NETとMSなら安心安全で良いと思うけどね
正直なところ新規アプリを作るならどっち選んでも労力に大きな差はない
だとしたら後々を見据えてさまざまな観点で安定感がある方を選ぶのが賢い お前らウェブサイト製品制作の話をしたいならblazor vs reactでも立ててそこでやれよw 安心安全を求めるならKotlin/Swiftでネイティブに作るだろ
なにいってんだ どうかな?
それはSPAつくるならバニラが安心安全だろと言うようなものだ
間違えやすい面倒な部分は信頼できるベンダーに任せて隠蔽してもらった方が安心できる >>160
宗教というかC#で書いたほうが楽じゃね?
Js系は回りくどい記述が多い >>162
Blazor(WASM)の弱点である初回起動時の糞遅ローディングがMAUI Blazorでは完全に消えるのがMAUIでBlazorを使う利点かなと思ってる ふつうにフロントがreact、バックがwasmでいいわ
フロントまでwasmでやろうとするから遅くなる >>156
ユーザーが少ないのに絶対ポイされないフレームワークなんか無いだろw
ボランティアじゃないんだから。 tauriは知らなかったけどパッと見た感じmauiのblazorハイブリッドのパクリっぽいね 全然違うわっつーかTauriすら知らんにわかがシャシャんなや
俺はReactもFlutterもMAUI(XAML、Blazor)もTauri(Vue or Svelte + Vite + Rust)も全部使った上で批評してんだよ馬鹿どもが何がVueガイジだボケ
お前らアプリ一つ作ったこともない手じゃなくて口だけしか動かさないプログラマとして一番最底辺のゴミどもじゃねーかよ
5chてほんまド素人が何も理解せず浅パチャな上辺でググりがら煽ってレスバしてるだけの無能しかいねーよな草生えるわ
レスバしてる暇あるなら1行でも多くコード書け俺らの世界に口だけ動かしてる馬鹿とか害悪以外のなにものでもねーんだよクソが お前、以前はxamarinスレとNeeViewスレで暴れてたやつだろ
戻ってきたのか? tauriってWebView動かして中身はいつものweb frameworkでやりましょうね、あとrustで書けばだけどネイティブapiも呼べますよって感じだろー?
まんまmaui blazorの劣化版じゃん?
色々と継ぎ接ぎしながら一生懸命作ってる途中のがtauri
C# .NETの上に綺麗にまとめ上げてもう使えるのがmaui blazor >>173
5chでアホ丸出しの長文レスする暇があるならもっとコード書けよボケ >>171
これRustでしょ?
世界にどれだけRustユーザーいるんだよ >>177
C++erなら問題なく使えるっしょ
まわりも俺もそうだった >>178
そうなのか…
C++erならQtという選択肢もあると思うが… >>179
?は?QTってライセンス有料じゃん、wxWidgetsなら商用利用できるからわかるけど
というかなんで一言語プログラミング縛りしようとするんだ? >>180
いやまぁそのタウリが使いやすいなら別に良いけど
Qtって有料なんだね
知らんかったわ >>183
学生の頃、ちょっとしたその場しのぎ電子工作用アプリ作るのにすごく便利だったな Qtは無料版もまだあるよ
ただライセンスが面倒だし
ソースコードは公開義務があって
公開方法を間違えるとQtから直接文句が来たりでめんどくささは最高 qtやwxもモバイルアプリ作れるからスレタイに加えるか? >>181
どこがクソなの?言ってみろよ?wx神を貶すなど許さんぞ まぁ理解出来ないとクソと言うのは条件反射だと言うことで。 >>186
イベントしかりレイアウトしかりコードが冗長すぎる
以上 >>187
ただ長すぎるとスレ立てれなかったりするんだよなぁ Blazor が既にあるのに
他のクソなフレームワーク使う
意味がわからない UnityってGitでソース管理出来るようになった? React-NativeのIgniteっていうboiler templateなかなか良いな。
generatorってのを使ってcomponentとかscreenとか作るから、画面遷移とかの問題が起きにくい気がする。 tauriがどうこうというより
そもそも、もうそんなハイパフォーマンスが求められるアプリ作る機会,需要が少ないからな.. いや、普通にパフォーマンス悪いアプリは自然と使用者少なくなっていくよ。 【IT悲報】「React Nativeはオワコン これからはFlutter」信じたエンジニアさんむせび泣く [743999204]
https://greta.5ch.net/test/read.cgi/poverty/1691853159/ >>204
ピチャイがCEOになってから邪悪さを隠さないようになった気がする可能性あるかもしれない。 google map platformを利用したflutterアプリを開発してるけど
既存ライブラリを利用すると、画面遷移でマップ画面を呼び出すたびに
有料APIを呼び出すから利用料がすごいことになる 時代はKMPだよ
マルチプラットフォームはKotlin Compose新時代が開幕してる
KMP (Kotlin Multiplatform)の導入検討
https://qiita.com/seiji-matsumura/items/febd0c787e737e6345be KMP画面遷移もできなかった頃に比べたら使えるようにはなってきたな >>211
それな
PrecomposeはAndroidの公式画面遷移ライブラリとそっくりでむっちゃ使いやすい kotlinもjavaもわからんから.net mauiしかない mauiはdotnet8のネイティブaotの対応でようやくマルチプラットフォームコンパイル対応UIライブラリとしてスタートラインに立ったイメージだわ AndroidアプリがKotlin,JavaのJVM系とC他LLVM系ネイティブ、
iOSアプリがSwift他LLVM系ネイティブ
で書かれてる。
やっぱAndroidを含めたマルチプラットフォーム対応を謳うならJVM環境向けコンパイルに対応したものがいいよね、少しでもビルド速度の早いほうがいい。 AndroidはJVM環境じゃなくてART環境かな
まあ大まかな仕組み的には似たようなもんだ MAUIは国内外問わず大失敗としか言いようが無いが……
Xamarin切らずに徐々に移行させれば違っただろうになぁ とはいってもKMPは>>209で貼った記事で全て語り尽くされてるし
ComposeマルチプラットフォームのコツはAndroidのJetpackComposeとほぼ共通でAndroidカレンダーで語り尽くされそうだし
https://qiita.com/advent-calendar/2023/android
KMPあるいはComposeマルチプラットフォームで新しく語ることが特にないんだよねえ
気になるKMP対応ライブラリ評価は>>221のカレンダーでやってくれてるし >>217
ReactNativeはJavaScript/TypeScriptで書けるってだけで使うメリットあるよねえ
FlutterはKMPのComposeのiOS正式サポートが来たらいよいよ立ち位置が厳しそう MAUIはmacOSはもうずっとCatalystでお茶を濁すつもりなの?前に触った時Windowサイズすら変えられないと知って絶望した
C#はもう観念して、せめてデスクトップに集中してほしいんだが Flutterスレ、流れ的にここに吸収されたほうが良さそうだが
性懲りもなく次スレ建てたのか 直近の流れがどうだろうと戦いだけがスレの存在意義じゃない
そもそも他フレームワークとかどうでもいいし Tauri Mobileをちらっと見てみたけどガワネイティブを作る分には便利そうね
将来的にExpo/React Nativeの対抗馬になりそう c#民としてはtauri mobileがdotnetのblazorを搭載できるらしいから期待してる
mauiはクビだ ガワで良ければ今んとこCapacitorが一歩リード
tauriは、バックエンドあんまり触らなくて良いアプリなら、まあ。凝ったことやろうとするとRustがつらい
C#はAvaloniaが良いんでないの?スマホも動くしblazorも一応既に稼働してる