Microsoft-ui-xaml: Diskusi: WinUI vs ElectronJS dan lintas platform (tingkatkan WinUI untuk menghilangkan alasan menggunakan ElectronJS daripada WinUI)

Hal yang sama berlaku dengan aplikasi Xbox Beta baru. Itu menggunakan 400MB yang baru saja dibuka sebagai Toko yang dimuliakan. Microsoft Store hanya menggunakan 117mb saat aktif.

Sampai Microsoft mengembangkan kerangka kerja UI lintas platform, yang memungkinkan satu UI dan desain kontrol di semua platform, ElectronJS dan sejenisnya, akan terus digunakan.

Contoh kecepatan menakjubkan dari ElectronJS/Teams:
Pertama, sebagai perbandingan, saya menghitung berapa lama waktu yang dibutuhkan untuk membuka Microsoft Outlook dan melihat pesan terbaru di kotak masuk (kotak masuk yang berisi sejumlah besar pesan). Hanya butuh beberapa detik -- sebenarnya itu sangat cepat sehingga saya tidak bisa menghentikan stopwatch cukup cepat untuk mendapatkan pengukuran yang akurat.
Selanjutnya saya menghitung berapa lama waktu yang dibutuhkan untuk membuka Microsoft Teams dan melihat pesan terbaru dalam obrolan dengan rekan kerja: 27 detik! Kali ini bisa lebih atau kurang tergantung berapa banyak pesan dan gambar yang ada di panel chat.

( PEMBARUAN 9-NOV-2019: _Versi baru Teams telah dirilis dan meningkatkan waktu yang dibutuhkan untuk melihat pesan obrolan terbaru. Contoh 27 detik yang disebutkan di atas sekarang menjelaskan versi Teams sebelumnya. Terima kasih kepada staf Microsoft anggota yang mengerjakan perbaikan ini._ )

Minggu lalu, saya mengklik ikon Bantuan di Teams, lalu saya mengklik "Berikan umpan balik" dan mengetik pesan. Itu sangat lambat: Setiap kali saya menekan tombol pada keyboard, butuh beberapa detik untuk setiap karakter muncul! (Namun, ketika saya menguji "Berikan umpan balik" lagi hari ini, tertinggal jauh lebih sedikit daripada minggu lalu, jadi tampaknya sulit untuk mereproduksi masalah khusus ini.)

Jika Teams ditulis menggunakan WinUI, itu tidak akan memiliki masalah kecepatan dan berbagai bug yang tidak biasa lainnya. Misalnya, aplikasi WinUI menggunakan pemformatan tanggal/waktu yang dikonfigurasi di pengaturan Windows, sedangkan Teams selalu menggunakan pemformatan tanggal/waktu AS 12 jam saat Teams diatur ke bahasa Inggris, dan mengabaikan pengaturan Windows -- bukan itu cara Windows aplikasi seharusnya beroperasi. Kemudian saya menguji mengubah bahasa Teams hari ini dan dikatakan _"Ada kesalahan, Teams sedang memulihkan"_. Dan kemudian beberapa gambar dalam pesan di panel obrolan gagal dimuat.

Demikian juga jika Teams ditulis menggunakan WinUI, itu tidak akan membuat 5 proses Teams.

@mdtauk

Sampai Microsoft mengembangkan kerangka kerja UI lintas platform, yang memungkinkan satu UI dan desain kontrol di semua platform, ElectronJS dan sejenisnya, akan terus digunakan.

Meskipun saya secara umum setuju, pasti ada lebih banyak cerita ini daripada itu, karena misalnya Microsoft OneNote tersedia untuk Windows, Android, dan Mac, tetapi tidak menggunakan ElectronJS (AFAIK) dan tidak mengalami kinerja yang buruk seperti tim.

@mdtauk

Sampai Microsoft mengembangkan kerangka kerja UI lintas platform, yang memungkinkan satu UI dan desain kontrol di semua platform, ElectronJS dan sejenisnya, akan terus digunakan.

Meskipun saya secara umum setuju, pasti ada lebih banyak cerita ini daripada itu, karena misalnya Microsoft OneNote tersedia untuk Windows, Android, dan Mac, tetapi tidak menggunakan ElectronJS (AFAIK) dan tidak mengalami kinerja yang buruk seperti tim.

Microsoft memiliki sumber daya untuk membangun aplikasi untuk setiap platform, berbagi kode sebanyak mungkin - tetapi tidak menggunakan UI bersama

Saya akan senang mendengar argumen apa pun yang menentang penggunaan Uno Platform yang menargetkan banyak platform (Windows, iOS, Android, Web) yang menghasilkan paket aplikasi berkinerja tinggi menggunakan UWP API sekarang, WinUI nanti. Ini menggunakan semuanya Microsoft - VS, C#, Xaml, Xamarin, mono, .Net...
Bukankah datang dari Microsoft secara langsung merupakan alasan utama bagi sebagian orang untuk menghindarinya?

Saya akan senang mendengar argumen apa pun yang menentang penggunaan Uno Platform yang menargetkan banyak platform (Windows, iOS, Android, Web) yang menghasilkan paket aplikasi berkinerja tinggi menggunakan UWP API sekarang, WinUI nanti. Ini menggunakan semuanya Microsoft - VS, C#, Xaml, Xamarin, mono, .Net...
Bukankah datang dari Microsoft secara langsung merupakan alasan utama bagi sebagian orang untuk menghindarinya?

Ini akan menjadi argumen yang lebih baik beberapa tahun yang lalu, tetapi banyak perusahaan yang ingin berinvestasi dalam membangun aplikasi atau sistem, perlu mengetahui bahwa platform yang mereka kembangkan memiliki dukungan dan umur panjang dari perusahaan besar dengan sumber daya yang luas seperti Microsoft.

Masalah dengan argumen itu adalah bahwa dekade terakhir telah menunjukkan Microsoft meninggalkan platform, dan basis pengguna, dan Windows dipindahkan ke warisan atau prioritas yang berkurang di dalam Microsoft.

Jadi, Anda tidak dapat menyalahkan pengembang baru untuk beralih ke platform web, jika mereka ingin menjalankan layanan yang terhubung - atau berfokus pada platform yang sedang dikembangkan secara aktif, dan tampaknya memiliki dukungan kuat di masa depan.

Pada saat yang sama ada beberapa perusahaan besar seperti Adobe, dengan aplikasi lawas - jadi memindahkan platform dengan itu hampir tidak mungkin. Ada juga penghobi dan bisnis dengan perangkat lunak khusus.

Microsoft telah melakukannya dengan baik dengan dukungan .NET dan Win32. Dan WinUI mungkin merupakan kesempatan untuk mengizinkan Win32 dan .NET - tetapi dengan UI modern.

Silverlight, WinRT, UWP - semuanya ditinggalkan. (Saya tahu UWP tidak secara teknis, tetapi WinUI kemungkinan besar akan dilihat sebagai pengganti).

Zune, Windows Media Center, Windows Phone 7, Windows Phone 8, Windows 8 - mengecewakan para penggemar dan orang-orang yang mereka coba injili.

Bagaimana Microsoft memposisikan WinUI dan juga memastikan masa depan Windows aman, akan _sangat penting_

WinUI untuk Desktop terlihat menjanjikan, tetapi saya merasa bahwa setidaknya sebagian dari XAML-nya harus dapat berjalan di Web; WinUI di Web, seperti Silverlight baru tetapi berjalan di .NET 5 dan WebAssembly.

Silverlight, WinRT, UWP - semuanya ditinggalkan. (Saya tahu UWP tidak secara teknis, tetapi WinUI kemungkinan besar akan dilihat sebagai pengganti).

Zune, Windows Media Center, Windows Phone 7, Windows Phone 8, Windows 8 - mengecewakan para penggemar dan orang-orang yang mereka coba injili.

Setuju.
Tidak dapat dipercaya beberapa Silverlight saya (aplikasi web0 masih digunakan setiap hari oleh beberapa pengguna.
Mengikuti Microsoft semakin sulit. Orang-orang di balik Uno Platform mengembangkan dan memeliharanya untuk mendukung bisnis aplikasi roti dan mentega mereka. Ini adalah open-source dengan banyak kontributor. Saya merasa bahwa saya membonceng bus yang sangat bagus dengan pengemudi terbaik yang mengetahui dengan baik cara menavigasi labirin atau kekacauan Microsoft.

2 sen saya: satu-satunya harapan UWP dan WinUI, adalah jika mereka dengan cepat membuatnya lintas platform, termasuk web, sebelum tidak ada yang tersisa.
Uno Platform adalah cara yang cepat, mudah, dan mungkin juga cara teraman untuk mencapainya.
Seperti yang disebutkan @zipswich , Uno telah menjadi Microsoft selama ini; dalam pedoman pengkodean, perkakas, pemilihan bahasa, dan rendering, dan siap dengan desain Lancar.
Ini 100x lebih bias Microsoft daripada Xamarin, misalnya. Jangankan React atau Electron, dan semua teknologi HTML & CSS atau JS jelek MS sangat terobsesi menyanjung dan menipu.

Dan biarlah keras, C# hanya bahasa server dengan kurangnya .NET Standard dari kerangka UI.
Semakin lama tetap seperti ini, Dart atau teknologi lainnya akan menjadi bahasa server, dan mengambil alih sepenuhnya.
Anda melihat bahwa orang rela menggunakan bahasa jahat (JS), sebagai pengorbanan untuk dapat menggunakan basis kode satu bahasa, baik di klien maupun server. C# mungkin memudar seperti XAML, atau bisa menang bersama XAML jika penyelamatan darurat diberikan.

Saya tidak percaya bahwa Uno akan menjadi masa depan. Ini sangat mirip dengan Xamarin.Forms, menjadi kerangka kerja Xaml yang dipreteli dengan banyak fungsi yang hilang dan banyak hal tambahan rumit yang ditambahkan untuk memungkinkannya berintegrasi di semua platform, dengan beberapa peretasan dan solusi. Tentu Anda dapat menggunakannya, tetapi Anda sangat terbatas dalam kontrol apa yang Anda miliki dan API apa yang dapat Anda gunakan. Masalah utamanya adalah ia mencoba mewujudkan UI Xaml dengan kontrol asli setiap platform. Ini selalu bermasalah dan membuat Anda hanya memiliki sebagian kecil fungsi yang kebetulan berfungsi di semua platform.

Masa depan adalah menggunakan WinUI asli dan menyediakan penyaji nyata untuk setiap platform, diimplementasikan dalam mesin 3D asli platform. Ini akan memberi kita fitur lengkap, semua kebaikan WinUI, berjalan dengan kinerja asli, lintas platform.

Sebenarnya, Microsoft sudah menjalankan sesuatu seperti ini dengan sangat baik: UI UWP sebagian besar didasarkan pada kode Silverlight, dan Microsoft memiliki plugin Silverlight untuk semua platform utama, yang berarti mereka sudah memiliki mesin rendering dasar untuk semua platform ini. Mereka tidak up-to-date, karena sekarang UWP memiliki banyak tambahan dibandingkan dengan Silverlight. Tapi itu adalah dasar yang bisa dibangun.

Microsoft yakin memiliki sumber daya untuk melakukan ini. Inilah yang diinginkan orang, dan inilah yang harus mereka lakukan.

C# mungkin memudar seperti XAML >

Jelas tidak setuju dengan pernyataan ini tentang C #. C# jauh lebih besar dari XAML. Jika Anda mengikuti Blazor, Anda akan tahu bahwa ini tidak benar. Saya melihat Blazor sebagai pengubah permainan bagi saya terutama menggunakan UWP/Xamarin dan untuk pengembang C# pada umumnya yang secara khusus menargetkan pengguna bisnis.

Akan menyenangkan untuk memiliki WinUI x-platform tetapi saya pikir jalan termudah ke web /x-platform adalah Blazor terutama sekarang Blazor juga mendukung sebagian kelas yang berarti saya dapat mengambil sebagian besar kode yang ada apa adanya dan mulai menggunakannya di Blazer. Beberapa cegukan bisa menjadi alternatif untuk Sqlite , Proyek Bersama dan ReactiveUI. Saya seharusnya dapat menggunakan arsitektur MVVM yang ada dan mem-portingnya ke Blazor dengan cukup mudah.

Batu sandungan yang paling penting bagi saya adalah kurangnya dukungan .net core 3 di UWP. Saya pikir sangat penting bagi MS untuk menyelaraskan Blazor + UWP dalam pengalaman pengembang. Saya tahu tim UWP sedang mengerjakannya.

Juga, saya ingin melihat halaman Blazor di aplikasi UWP / WINUI. Model UI hibrida akan sangat cocok untuk saya di aplikasi UWP sehingga saya dapat menggunakan aset UI terbaik yang tersedia. (html5 versus XAML) dan juga tidak meniru upaya UI saya antara UWP dan Blazor di tempat yang masuk akal.

Saat ini Electron menggunakan Javascript, HTML + CSS. Tidak ada alasan mengapa kami tidak dapat menggunakan Electron dengan Blazor => C# , HTML + CSS + gRPC

tetapi Anda sangat terbatas dalam kontrol apa yang Anda miliki dan API apa yang dapat Anda gunakan.

@lucasf Sudahkah Anda mencoba Uno? Tahukah Anda bahwa Uno mengizinkan penggunaan API asli apa pun melalui Xamarin jika tidak ada API UWP yang sesuai. Saya hanya menggunakan beberapa API asli di aplikasi berbasis Uno saya bahkan untuk aplikasi streaming video real-time saya yang menggunakan codec perangkat keras dan membutuhkan latensi rendah.

tetapi Anda sangat terbatas dalam kontrol apa yang Anda miliki dan API apa yang dapat Anda gunakan.

@lukasf Sudahkah Anda mencoba Uno? Tahukah Anda bahwa Uno mengizinkan penggunaan API asli apa pun melalui Xamarin jika tidak ada API UWP yang sesuai. Saya hanya menggunakan beberapa API asli di aplikasi berbasis Uno saya bahkan untuk aplikasi streaming video real-time saya yang menggunakan codec perangkat keras dan membutuhkan latensi rendah.

@zipswich Kumpulan kontrol Xaml standar di Uno cukup kecil, tidak mendekati apa yang ditawarkan UWP atau WinUI3 lengkap. Untuk mewujudkan UI yang bagus/kompleks, Anda biasanya harus menyematkan kontrol dan kode UI asli khusus platform tambahan. Jadi pada akhirnya Anda akan menemukan diri Anda dengan campuran beberapa platform UI (Uno Xaml, Android asli, iOS Asli, mungkin Windows asli atau WebAssembly). Ini bukan yang saya sebut sebagai pengalaman pengembang yang hebat.

Jika kami memiliki perender x-platform asli untuk WinUI, kami hanya memiliki satu UI tunggal dengan set fitur WinUI lengkap, tanpa segala jenis hal khusus platform di dalamnya. Dan WinUI akan langsung merender pada GPU dengan kinerja penuh, seperti yang Anda harapkan. Tidak perlu menambahkan kontrol Android tambahan atau kontrol iOS tambahan. Seperti inilah seharusnya pengembangan x-platform.

Apa kekurangan WinUI (dan bagaimana cara meningkatkannya) untuk meyakinkan manajer program Microsoft agar Tim Microsoft beralih dari ElectronJS ke WinUI/UWP?

Pertanyaan bagus. Sejumlah besar pengguna akan sangat senang jika mereka melakukan ini.

Faktor besar adalah kurangnya ukuran kinerja yang membandingkan kerangka kerja. Halaman yang membandingkan aplikasi setara yang dilakukan di UWP dan Electron dan membandingkan kecepatan dan penggunaan memori sudah cukup. Ini bisa meluas ke kerangka kerja lain. Dari biaya ini untuk pengguna, efek pada penggunaan, dan manfaat konsolidasi kode dapat ditimbang terhadap biaya keuangan.

Kurangnya penelitian saat ini membantu kerangka kerja yang tidak efisien menjadi populer.

Berbicara jujur: Saya ragu MS memiliki rencana untuk membuat "WinUI" ( Windows UI) lintas platform. Selain itu, fakta bahwa sekarang open source biasanya berarti Microsoft tidak lagi menganggapnya sebagai teknologi kritis/strategis. Mereka mencoba memanfaatkan sumber daya komunitas alih-alih menurunkan jumlah karyawan internal sambil mempertahankannya tetap hidup. Jangan salah paham, saya senang WinUI adalah open source sekarang dan menghargai semua waktu yang diberikan pengembang Microsoft ke dalam platform yang membawanya ke WinUI 3.0 -- ini adalah langkah yang bagus untuk mengkonsolidasikan platform presentasi windows baik untuk native maupun aplikasi yang dikelola. Saya hanya tidak berpikir Microsoft melihat Windows sebagai masa depan dan saya tidak berpikir mereka tertarik untuk mengambilnya lintas platform (tentu saja itu adalah kesalahan mereka jika benar).

Kerangka kerja pengembangan lintas platform nyata yang tidak memaksa pengembang untuk menggunakan teknologi sub-par adalah yang dibutuhkan dunia. Sepertinya kebanyakan orang di sini setuju. Apa yang sebagian besar berarti adalah:

• Pustaka kontrol dan markup (XAML) yang dapat dirender seperti desain asli platform (kita hanya memerlukan gaya kontrol untuk iOS, Android, dll.)
• Perlu ditulis dalam kode terkelola seperti WPF. Hanya lapisan dasar di C++, kontrol tidak boleh apa pun selain C#.
• Rendering perlu dilakukan dengan Metal/Vulcan/DirectX (bukan di atas kontrol yang ada seperti Uno)
• Input harus diimplementasikan kembali dengan cara platform-X
• Aksesibilitas adalah masalah besar yang sayangnya jauh lebih mudah dipecahkan menggunakan pendekatan Uno

Jika itu yang kami inginkan, menurut saya, WinUI tidak akan melakukannya. Fakta dan cara penerapannya secara asli (beberapa lapisan COM/.net di antaranya) sendiri berarti akan sangat sulit untuk menggunakan lintas platform ini. Sebaliknya, kami memiliki UNO dan Avalonia. Avalonia adalah cahaya nyata di ujung terowongan tetapi mereka tidak memiliki sumber daya apa pun. Apa yang kurang lebih mungkin sekarang adalah menggunakan teknologi rendering Avalonia sebagai backend ke WPF (bagian yang dikelola). Itu akan memberi kita kerangka UI lintas platform yang sebenarnya dalam waktu singkat. Masalahnya adalah WPF dirancang untuk desktop dan banyak pekerjaan yang dilakukan UWP untuk membuat WPF/Silverlight ramah untuk perangkat berukuran ponsel dan input sentuh/interaktif modern.

Sejujurnya saya berpikir pada titik ini kita akan lebih baik jika kita semua hanya memberikan kontribusi uang dan kode di Avalonia. Kami sudah terlalu lama meminta Microsoft untuk UI lintas platform dan mereka puas untuk beralih ke teknologi web sendiri. Microsoft bahkan mengubah aplikasi UWP seperti XBox menjadi Electron dan teknologi web sekarang. Aplikasi juga tidak dijual di Microsoft Store.

Ironisnya, Microsoft sangat sukses di masa lalu karena mereka memberi pengembang alat yang mereka butuhkan untuk membangun aplikasi hebat. Ini menarik pengguna dan Anda memiliki umpan balik yang sangat konstruktif. Suatu saat hal itu terlupakan. Sekarang pengembang beralih ke teknologi sub-par (HTML/CSS awalnya tidak pernah dirancang untuk aplikasi... itu untuk markup dokumen!) Tetapi penghematan hanya dengan mengembangkan aplikasi satu kali dan menjalankannya di Electron dan web jauh lebih besar daripada pengorbanan dalam fungsionalitas, integrasi sistem, dan kinerja saat ini.

Ironisnya, Microsoft sangat sukses di masa lalu karena mereka memberi pengembang alat yang mereka butuhkan untuk membangun aplikasi hebat. Ini menarik pengguna dan Anda memiliki umpan balik yang sangat konstruktif. Suatu saat hal itu terlupakan. Sekarang pengembang beralih ke teknologi sub-par (HTML/CSS awalnya tidak pernah dirancang untuk aplikasi... itu untuk markup dokumen!)

kata baik. Selain BASIC, saya mulai menggunakan Microsoft IDE dari Quick C, lalu VC++... Microsoft dulu berevolusi, berinovasi dengan cara yang stabil, konsisten, dan agak dapat diprediksi. Kami mencoba mengikutinya, dan sepertinya mengikuti tren orang-orang yang seharusnya mengikuti kami. Saya biasa memberi tahu magang dari universitas riset tingkat atas untuk menggunakan teknologi Microsoft untuk aplikasi perusahaan tempat mereka diminta untuk bekerja. Tidak ada penolakan, dan mereka dengan senang hati mengambil barang-barang Microsoft dengan cepat. Saya bertanya-tanya apakah Microsoft telah melihat seperti apa anak-anak hari ini, lalu ikuti mereka.

Aplikasi juga tidak dijual di Microsoft Store.

Benar sayangnya. Namun, saya menyalahkan toko aplikasi terburuk (untuk pengguna dan penerbit), bukan teknologi pengembang. Rasio unduhan harian versi aplikasi UWP vs Android: 1:20 . Mereka membutuhkan jumlah usaha yang sama untuk berkembang. Hal ini tidak berlebihan. Saya baru saja melihat data pengunduhan kemarin. Jika saya bekerja untuk penghitung kacang, saya akan segera dipecat karena menghabiskan begitu banyak upaya pada versi UWP yang menghasilkan sedikit pengembalian.

Benar sayangnya. Namun, saya menyalahkan toko aplikasi terburuk (untuk pengguna dan penerbit), bukan teknologi pengembang.

@zipswich , ya, Anda punya poin bagus. Saya hanya berasumsi bahwa Microsoft secara internal melihat angka penjualan dan berasumsi (dengan benar) ekosistem sedang sekarat. Hal ini kemudian meyakinkan mereka bahwa jenis teknologi pengembangan dasar yang kita bicarakan sudah usang sehingga mereka mulai berinvestasi dan pergi ke arah lain. Pada kenyataannya, sebagian besar pengembang aplikasi Microsoft dapat melihat kebutuhan yang jelas untuk kerangka kerja lintas platform yang tidak tertulis melupakan 20 tahun terakhir kemajuan teknologi UI (WPF benar-benar merupakan pengubah permainan ketika muncul).

Kami tidak hanya membutuhkan lintas platform: kami membutuhkan sesuatu yang dilakukan dengan bahasa dan markup yang kuat/dapat diskalakan dan memiliki cakupan yang berarti (dimaksudkan untuk aplikasi, katalog kontrol yang baik) sejak awal. Saya tidak berpikir kita dapat mengandalkan Microsoft lagi untuk itu. Mereka telah memperjelas bahwa mereka melihat keuntungan yang lebih tinggi menghabiskan waktu/sumber daya mereka di area lain.

Saya akan segera dipecat karena menghabiskan begitu banyak upaya pada versi UWP yang menghasilkan sedikit pengembalian.

Saya mendengar Anda, saya membuat pernyataan itu berdasarkan aplikasi saya sendiri di Microsoft Store juga.

@robloo Anda memiliki beberapa poin bagus di sana, tetapi saya tidak benar-benar mengikuti Anda. Berikut adalah beberapa pemikiran:

• Microsoft telah mengerahkan banyak upaya dan sumber daya ke dalam kerangka kerja sumber terbuka lainnya juga, seperti .NET Core, ASP.Net Core, EF Core. Jelas mereka melihat masa depan dalam open source, pengembangan lintas platform (setidaknya untuk aplikasi server). Mereka juga memasukkan sumber daya ke dalam kompilasi AOT, sehingga .NET Core dapat dikompilasi ke iOS dan Android juga (di mana JIT tidak diperbolehkan). Jadi saya tidak bisa mengikuti Anda mengatakan bahwa WinUI sudah mati sekarang, hanya karena mereka menjadikannya open source. Maksud saya, itu bisa jadi benar, tetapi jika satu-satunya argumen Anda adalah "karena mereka menjadikannya open source", maka ini tidak terlalu meyakinkan.

• Qt adalah kerangka kerja UI lintas platform, yang diimplementasikan dalam C/C++ asli. Ini memiliki perender OpenGL/Direct3D yang dipercepat perangkat keras, sehingga terlihat sama dan memiliki kinerja hebat di semua platform. Tidak diperlukan kode khusus platform, semua kontrol berjalan di semua platform, termasuk iOS dan Android. Jadi mengapa secara teknis tidak mungkin menjalankan WinUI di iOS dan Android, jika Qt dapat melakukan hal itu? WinUI diimplementasikan di WinRT, yang merupakan C++ asli, seperti Qt. Secara internal, ia hanya menggunakan beberapa teknologi COM (antarmuka IUnknown ditambah sistem pabrik COM). Seharusnya tidak terlalu sulit untuk mengabstraksikannya atau mengimplementasikan kembali apa yang dibutuhkan untuk platform lain. Saya tidak berpikir bahwa kode COM apa pun langsung digunakan dalam kode WinUI.

• Silverlight menggunakan teknologi yang sama dan tersedia x-platform.

• Windows masih menjadi OS desktop nomor 1, banyak digunakan, tidak hanya di rumah tetapi juga (terutama) oleh bisnis. Dikombinasikan dengan lisensi Office, ini menghasilkan banyak pendapatan yang solid untuk Microsoft. Mereka akan kehilangan pendapatan ini jika membiarkan semua platform pengembangan UI utama mati. WinForms dan WPF sudah mati, jadi WinUI adalah satu-satunya platform UI aktif di Windows. Saya tidak percaya mereka ingin menyingkirkan sistem Windows/Office/Enterprise yang lengkap, jadi saya tidak percaya mereka ingin menyingkirkan WinUI.

• Membuat WinUI open source sangat bagus untuk pengembang, tidak hanya untuk Microsoft.

• Bisa jadi UWP akan mati. Banyak pengembang menjauhinya karena semua batasan bodoh. Windows Store tidak berhasil dari jarak jauh. Windows Phone sudah mati, yang merupakan alasan utama untuk memulai seluruh UWP.

• Membawa WinUI ke aplikasi desktop dengan WinUI 3.0 dan menjadikannya open source, sebenarnya bisa menjadi langkah untuk menyimpannya, bukan mematikannya!

Saya hanya berasumsi bahwa Microsoft secara internal melihat angka penjualan dan berasumsi (dengan benar) ekosistem sedang sekarat. Hal ini kemudian meyakinkan mereka bahwa jenis teknologi pengembangan dasar yang kita bicarakan sudah usang sehingga mereka mulai berinvestasi dan pergi ke arah lain.

@robloo Tidak harus demikian. Saya telah mengatakan selama ini bahwa itu adalah toko aplikasi terburuk yang membunuh Windows Phone, platform seluler terbaik.

Mereka dapat membunuh dua burung dengan satu batu: mengalihdayakan toko ke pihak ketiga yang kompeten dan mengakhiri mimpi buruk .Net Native. Ini akan mengurangi biaya mereka dan (saya percaya) menggandakan, empat kali lipat... Aplikasi Windows mengunduh dengan cepat. Lebih dari 90% masalah aplikasi UWP saya semata-mata terkait dengan mimpi buruk .Net Native.

@lukasf Saya pikir Anda salah mengartikan banyak dari apa yang saya katakan.

Saya tidak dapat mengikuti Anda mengatakan bahwa WinUI sudah mati sekarang, hanya karena mereka menjadikannya open source.

Saya tidak akan pernah mengatakan WinUI sudah mati. Saya memang mengatakan Microsoft mungkin tidak lagi melihatnya sebagai produk jangka panjang yang kritis/strategis. Mereka melihat keuntungan yang lebih tinggi di area lain (layanan dan cloud) jadi pastikan untuk menghabiskan waktu mereka di mana ada keuntungan yang lebih tinggi bagi pemegang saham. Ini berarti saya pikir mereka tidak akan mengembangkan WinUI secara signifikan untuk membuatnya lintas platform dan tetap hidup yang saya pastikan untuk mengatakan alih-alih "mati". (Saya bukan seseorang di UWP/WinUI yang ikut-ikutan mati). Saya juga sangat merasa Microsoft melakukan hal yang hebat dengan WinUI 3.0 yang saya nyatakan. Ini memungkinkan semua Windows, win32 asli dan terkelola, untuk berkonsolidasi dengan satu kerangka UI.

Jadi mengapa secara teknis tidak mungkin menjalankan WinUI di iOS dan Android

Secara teknis apa pun mungkin. Saya mengatakan itu akan sangat sulit karena dirancang dan diimplementasikan hanya untuk Windows. Saya juga memberikan contoh bagaimana ia berkomunikasi dengan kode yang dikelola sebagai sesuatu yang saya pikir akan sangat sulit untuk dilakukan lintas platform. Akan lebih baik bagi kita semua jika saya salah di sini.

Silverlight menggunakan teknologi yang sama dan tersedia x-platform.

Dan Silverlight mati bukan karena secara teknis tidak mungkin, tetapi karena ini bukan lagi kasus bisnis yang bagus yang merupakan poin terpenting saya. Perhatikan bahwa itu juga mati karena teknologi HTML/CSS/JS yang sama sekarang mengambil alih pengembangan desktop dan seluler.

Mereka akan kehilangan pendapatan ini jika membiarkan semua platform pengembangan UI utama mati.

Ini mungkin dapat didiskusikan dengan beberapa cara berbeda tetapi mungkin benar-benar keluar dari cakupan topik dengan cukup cepat (yang saya tahu sudah saya lakukan). Intinya, tentu saja Microsoft tidak akan membiarkan semua platform UI Windows mati. Anda masih harus menulis aplikasi untuk Windows... Saya tidak pernah mengatakan sebaliknya.

Membuat WinUI open source sangat bagus untuk pengembang, tidak hanya untuk Microsoft.

Saya memang mengatakan "Saya senang WinUI adalah open source sekarang dan menghargai semua waktu yang diberikan pengembang Microsoft ke dalam platform yang membawanya ke WinUI 3.0" Tujuannya adalah untuk menyampaikan sentimen saya bahwa saya juga berpikir open source bagus untuk sejumlah alasan saya tidak menyentuh. Sebagai contoh, bahkan Platform Uno yang sekarang memiliki akses ke sumbernya sangat bagus seperti yang mereka nyatakan di UnoConf.

Bisa jadi UWP akan mati.

Tunggu, kamu di pihak mana? ha ha. Tapi serius saya menganggap WinUI/UWP pada dasarnya adalah hal yang sama dan UWP hanya akan memiliki evolusi kecil menjadi WinUI tanpa hambatan besar untuk pengembang.

Membawa WinUI ke aplikasi desktop dengan WinUI 3.0 dan menjadikannya open source, sebenarnya bisa menjadi langkah untuk menyimpannya, bukan mematikannya!

Saya setuju dengan Anda dan tidak pernah bermaksud mengatakan sebaliknya. Saya sedang melihat beberapa tren gambar yang lebih besar dan juga berbicara tentang mengambilnya lintas platform.

@zipswich

Mereka dapat membunuh dua burung dengan satu batu: mengalihdayakan toko ke pihak ketiga yang kompeten dan mengakhiri mimpi buruk .Net Native. Ini akan mengurangi biaya mereka dan (saya percaya) dua kali lipat, empat kali lipat.

Kabar baiknya adalah Microsoft telah memutuskan untuk membunuh .net native. Secara teknis ia memiliki sejumlah batasan konyol yang tidak mengikuti spesifikasi .net yang sepertinya Anda lebih kenal. Saya pikir itu adalah sesuatu yang dilakukan dengan cepat/kotor untuk memperbaiki masalah startup dan kinerja pada windows phone dan mereka tidak pernah repot untuk kembali dan memperbaikinya sejak windows phone mati.

Sekarang Microsoft sedang mengembangkan kompilasi AOT penuh, berkinerja tinggi, menggunakan teknologi Mono dan LLVM. Saya pikir ini akan keluar tahun depan dan juga berguna untuk Blazor sisi klien dengan webassembly. Miquel de Icaza memberikan presentasi bagus yang menyentuhnya awal tahun ini di UnoConf: https://www.youtube.com/watch?v=tYk2us6W6Gg (dia adalah presenter pertama).

@robloo Oke mungkin saya salah dalam beberapa poin.

Jadi mengapa secara teknis tidak mungkin menjalankan WinUI di iOS dan Android

Secara teknis apa pun mungkin. Saya mengatakan itu akan sangat sulit karena dirancang dan diimplementasikan hanya untuk Windows. Saya juga memberikan contoh bagaimana ia berkomunikasi dengan kode yang dikelola sebagai sesuatu yang saya pikir akan sangat sulit untuk dilakukan lintas platform. Akan lebih baik bagi kita semua jika saya salah di sini.

Silverlight menggunakan teknologi yang sama dan tersedia x-platform.

Dan Silverlight mati bukan karena secara teknis tidak mungkin, tetapi karena ini bukan lagi kasus bisnis yang bagus yang merupakan poin terpenting saya. Perhatikan bahwa itu juga mati karena teknologi HTML/CSS/JS yang sama sekarang mengambil alih pengembangan desktop dan seluler.

Maksud saya di sini adalah: Silverlight sudah menjalankan lintas platform. Itu dapat digunakan dengan kode yang dikelola. Lapisan UWP Xaml UI dari Windows 8 pada dasarnya adalah Silverlight, hanya dengan namespace baru dan beberapa metadata tambahan. Sekarang telah berkembang, tetapi pada awalnya jelas hanya Silverlight Xaml dengan namespace baru. Jadi jika mereka dapat menjalankan lintas platform Silverlight saat itu, mereka juga dapat menjalankan lintas platform WinUI. Dan saya tidak percaya bahwa ini akan "sangat sulit" tetapi saya lebih suka mengatakan itu akan lebih mudah bagi perusahaan besar seperti Microsoft. Mereka sudah memiliki lapisan rendering lintas platform untuk Silverlight Xaml. Seharusnya tidak terlalu sulit untuk memperbaruinya sehingga dapat menjalankan WinUI terbaru.

Bisa jadi UWP akan mati.

Tunggu, kamu di pihak mana? ha ha. Tapi serius saya menganggap WinUI/UWP pada dasarnya adalah hal yang sama dan UWP hanya akan memiliki evolusi kecil menjadi WinUI tanpa hambatan besar untuk pengembang.

WinUI hanyalah lapisan Xaml UI, sedangkan UWP adalah kerangka aplikasi lengkap dan lapisan API sistem, terikat ke Windows Store, dan dengan banyak keterbatasan dibandingkan dengan aplikasi desktop klasik. Jadi ini adalah dua hal yang sangat berbeda. Saya benar-benar tidak tahu apakah Microsoft melihat masa depan di UWP dan Windows Store. Tidak memperbaiki batasan UWP yang parah dan tidak benar-benar mengerjakan masalah Windows Store tidak membuat saya sangat optimis. Tetapi mereka pasti membutuhkan semacam kerangka kerja UI, dan itu akan menjadi WinUI, tidak peduli apakah digunakan dari UWP atau dari aplikasi desktop. Dan jika mereka benar-benar ingin sukses, mereka harus membuatnya lintas platform. Jika tidak, orang akan beralih ke kerangka kerja lain, dan kemudian mereka mungkin pada titik tertentu meninggalkan platform Windows sepenuhnya juga. Membuat lintas platform WinUI akan menjadi sarana untuk membuat para pengembang tetap menggunakan Windows.

Maksud saya di sini adalah: Silverlight sudah menjalankan lintas platform. Itu dapat digunakan dengan kode yang dikelola. Lapisan UWP Xaml UI dari Windows 8 pada dasarnya adalah Silverlight, hanya dengan namespace baru dan beberapa metadata tambahan. Sekarang telah berkembang, tetapi pada awalnya jelas hanya Silverlight Xaml dengan namespace baru. Jadi jika mereka dapat menjalankan lintas platform Silverlight saat itu, mereka juga dapat menjalankan lintas platform WinUI. Dan saya tidak percaya bahwa ini akan "sangat sulit" tetapi saya lebih suka mengatakan itu akan lebih mudah bagi perusahaan besar seperti Microsoft. Mereka sudah memiliki lapisan rendering lintas platform untuk Silverlight Xaml. Seharusnya tidak terlalu sulit untuk memperbaruinya sehingga dapat menjalankan WinUI terbaru.

Saya tidak tahu bahwa sejarah basis Silverlight digunakan untuk UWP/Win8 saat itu, jika itu masalahnya, itu membuat saya lebih optimis tentang seberapa layak ini. Terima kasih atas koreksinya!

WinUI hanyalah lapisan Xaml UI, sedangkan UWP adalah kerangka aplikasi lengkap dan lapisan API sistem, terikat ke Windows Store, dan dengan banyak keterbatasan dibandingkan dengan aplikasi desktop klasik. Jadi ini adalah dua hal yang sangat berbeda.

Ya, Anda benar dan saya seharusnya memilih kata-kata saya dengan lebih hati-hati. Tentunya UWP dalam model dan kemasan aplikasi akan terus eksis untuk saat ini. Namun lapisan UI akan beralih ke WinUI yang saya coba komunikasikan. Saya pikir akan ada lebih banyak perubahan di tahun-tahun mendatang dengan .net native diganti tetapi kemasan/model Aplikasi/API yang diperkenalkan dengan UWP akan tetap ada dalam beberapa bentuk. Saya sangat setuju bahwa Microsoft mungkin tidak melihat masa depan di sini. Untungnya, selama XAML dan C# masih ada, migrasi ke model aplikasi baru atau pengemasan/distribusi biasanya relatif cepat. Andai saja Avalonia selesai...

Dan jika mereka benar-benar ingin sukses, mereka harus membuatnya lintas platform. Jika tidak, orang akan beralih ke kerangka kerja lain, dan kemudian mereka mungkin pada titik tertentu meninggalkan platform Windows sepenuhnya juga. Membuat lintas platform WinUI akan menjadi sarana untuk membuat para pengembang tetap menggunakan Windows.

Saya juga setuju dengan Anda 100% dan telah menyatakan hal yang sama di beberapa tempat. Saya sampai pada kesimpulan bahwa untuk beberapa alasan itu tidak akan terjadi.

Saya sangat tidak setuju dengan komentator yang mengatakan:

WinUI 3.0 harus lintas platform!

1) Kami membutuhkan kerangka kerja UI sekarang, bukan dalam N tahun lagi ketika proyek lintas platform teoretis stabil.
2) Kami membutuhkan kerangka kerja UI yang sedekat mungkin dengan OS. Dengan lintas platform, selalu ada trade off. Baik penyebut umum terendah untuk fungsionalitas, atau rendering kontrol yang tidak konsisten karena rendering kustom.

Solusinya, menurut saya, adalah memiliki kerangka kerja lain yang dibangun di atas WinUI 3.0 (jika Anda ingin mempertahankan Lancar, dan memiliki sedikit pekerjaan dalam rendering, pengujian hit, dll), atau dari bawah ke atas dengan Komposisi WinUI jika Anda menginginkan kinerja maksimal, dan tidak keberatan melakukan semua rendering dan pengujian sendiri (dengan potensi biaya tidak konsisten).

Saya ingat saya melihat kalimat itu beberapa hari yang lalu:
"Sistem operasi bukan lagi lapisan terpenting bagi kami... Yang terpenting bagi kami adalah model aplikasi dan pengalaman."
Jadi jelas bahwa WinUI harus menjadi pengalaman GUI terbaik, dan saya pikir itu akan menjadi, seperti yang terbaik dari WPF, UWP dan Windows 10,

Tetapi jelas bahwa Web dan javaScript+HTML-nya yang lama digunakan di mana-mana, dan kerangka kerja web serta tumpukannya digunakan secara besar-besaran, bukan karena lebih baik, tetapi karena sudah tersedia di browser web ponsel, dan browser web desktop. Anda dapat membuat file HTML di Notepad, beri tag Script dengan alert('Hello World'); dan Anda memiliki Aplikasi.

Jadi saya melihat bahwa mungkin dan bahkan perlu untuk menggantinya dengan .NET+XAML menggunakan WebAssembly. Kami membutuhkan .NET untuk sama-sama ada di mana-mana seperti javaScript saat ini.

Silverlight adalah cahaya harapan... dan sekarang dengan WebAssembly, saya melihat kemungkinan Silverlight untuk kembali.

Saya akan senang dengan ini:
WinUI menjadi GUI bertenaga OS penuh dan setidaknya sebagian dari XAML-nya dapat berjalan di WebBrowser.

Jadi saya melihat tim UNO sangat penting, dan berharap mereka akan bergabung dengan Microsoft dalam waktu dekat untuk bergabung dalam upaya luar biasa ini yaitu WinUI.

@MarkIngramUK Yessss

Jadikan WinUI pilihan UI terbaik bagi siapa pun yang mempertimbangkan pengembangan Windows asli. Menyelesaikan:

• Validasi input & kontrol datagrid asli
• ~170 proposal fitur lainnya di sini
• ~300 tiket terbuka lainnya
• .NET Asli > .NET Core migrasi (untuk .NET Core 3+5, .NET Standard 2.1+, dan C# 8...)
• Kompiler AOT baru
• Dapatkan pedoman desain yang lebih koheren dan lancar yang dikeluarkan dan diterbitkan
• Sempurnakan sistem gaya/tema
• Kurangi penekanan fitur komposisi yang mengganggu (miring, penggunaan akrilik berat, buka) dan lebih fokus pada sistem & animasi kedalaman+bayangan (yang memberikan kejelasan dan memandu pengguna)

Ini adalah hal-hal yang akan membuat WinUI lebih menarik bagi orang-orang yang mempertimbangkannya vs. Electron di masa depan.

Lapisan gula pada kue kemudian akan menjadi:

• Alat untuk membantu menjaga gaya CSS <-> XAML Anda tetap sinkron
• Pedoman untuk menjaga logika aplikasi terpisah dari tampilan untuk penggunaan kembali kode .NET maksimum di platform lain
• Beberapa alat untuk menghasilkan terjemahan kasar satu kali dari kontrol HTML> XAML untuk memulai pengembang dengan aplikasi WinUI asli mereka (daripada mengasumsikan sebagian besar pengembang akan memulai dengan aplikasi XAML dan keinginan untuk menuju HTML)

2. We need a UI framework that is as close to the OS as possible. With cross-platform, there is always a trade off. Either lowest common denominator for functionality, or inconsistent control rendering due to custom rendering.

@MarkIngramUK Silverlight adalah lintas platform, berfitur lengkap, dan dirender sama persis di semua platform. Qt adalah lintas platform, berfitur lengkap, dan dirender sama persis di semua platform. Anda hanya mendapatkan rendering yang tidak konsisten dan kontrol common denominator terendah jika Anda mencoba mewujudkan kontrol Anda dengan menerjemahkannya secara internal ke kontrol asli dari platform yang berbeda (yang coba dilakukan oleh Xamarin dan Uno). Jika Anda melakukan abstraksi tidak pada level kontrol tetapi pada level terendah (lapisan rendering GPU), Anda bisa mendapatkan 100% output yang sama di semua platform dengan set kontrol lengkap. Set kontrol sudah ada, itu adalah WinUI 3.0, dan ini sangat bagus bahkan sekarang. Satu-satunya hal yang hilang adalah merender implementasi lapisan untuk platform lain (dan sebagian dapat diambil dari sumber Silverlight lama).

Saya sangat ingin melakukan pengembangan aplikasi lintas platform. Tapi baik Xamarin maupun Uno tidak terlihat menarik bagi saya dan saya tidak terlalu suka JS/HTML dan segala sesuatu yang didasarkan padanya. Sayangnya, mengembangkan secara eksklusif untuk Windows Store adalah pilihan yang buruk jika Anda benar-benar ingin menghasilkan uang dengannya. Setidaknya saya memiliki pengalaman yang agak buruk dengan itu, dan kemudian setelah Microsoft mematikan ekosistem Windows Phone, saya kurang lebih telah mengakhirinya (meskipun ada beberapa proyek kecil "hanya untuk bersenang-senang"). Saya akan langsung mulai mengerjakan aplikasi baru lagi jika WinUI menggunakan lintas platform.

Semua kerangka kerja lintas platform saat ini memiliki keterbatasan yang kurang lebih parah dan/atau pengalaman pengembangan yang buruk. Jika Microsoft bisa membuat WinUI lintas platform, itu benar-benar bisa menjadi terobosan teknologi. Xamarin sudah cukup sukses, terlepas dari semua tepi dan sudut dan keterbatasannya. Bayangkan betapa suksesnya WinUI jika dijalankan di semua platform dengan set fitur lengkap dan pengalaman pengembang Visual Studio terbaik.

@lukasf , ini poin saya:

Silverlight bersifat lintas platform, berfitur lengkap, dan ditampilkan persis sama di semua platform.

Saya tidak ingin rendering yang sama di semua platform. Saya ingin setiap aplikasi terlihat konsisten dengan aplikasi lain pada platform target. Itu sebabnya kontrol asli perlu dibungkus - tetapi kemudian itu mengarah ke penyebut umum terendah.

@MarkIngramUK Saya melihatnya seperti ini: Aplikasi sederhana tetap pada kontrol UI stok suatu platform. Aplikasi hebat memiliki tampilan+rasanya sendiri. Mereka tidak membutuhkan kontrol platform saham. Lihat Spotify, Netflix, atau aplikasi hebat+sukses lainnya yang tersedia untuk berbagai platform. Anda tidak dapat mengetahui platform yang mereka gunakan, hanya dengan melihat kontrol mereka.

Saya ingin aplikasi lintas platform saya terlihat dan terasa sama persis di semua platform.

@MarkIngramUK Senang Anda menyentuh kenyataan di luar teori. Inilah kenyataannya bagi saya: Saya memiliki banyak aplikasi yang berevolusi dari SL/WP > WinRT > UWP yang perlu menargetkan banyak platform kemarin. Saya melihat ke Phonegap/Cordova, dan menghabiskan banyak waktu menjelajahi Xamarin dengan sangat serius, dan akhirnya menyerah. Saya jatuh cinta dengan Uno karena berbagai alasan segera setelah saya mulai menggunakannya. Saat ini saya tidak tahu teknologi X-platform praktis lain yang menjanjikan dan ramah terhadap C# dan Xaml yang dapat saya gunakan saat ini . Ketika WinUI berevolusi menjadi X-platform API 1, 2, atau 3 tahun kemudian, orang-orang Uno terkemuka akan memigrasikan Uno dari UWP ke WinUI, dan semua aplikasi berbasis Uno saya akan dapat bermigrasi dengan tepat dan cepat. Tidak ada yang perlu saya khawatirkan sekarang.
Saya sama sekali tidak menentang diskusi teoretis yang menarik di sini. Senang mendengar segala macam ide.

Tidak bisakah WinUI/MS memanfaatkan proyek Blazor untuk menjadikan WinUI sebagai Aplikasi "Blazor Asli"?

Saya tahu Steve Sanderson mempresentasikan Butter di mana Flutter Google dapat dirender menggunakan Blazor (dan itu adalah UI berbasis XML). Tampaknya tim Blazor memiliki beberapa teknologi bagus di sisi rendering UI untuk memanfaatkan kerangka kerja UI yang berbeda. Jika Blazor dapat menangani Flutter, itu harus dapat menangani setara tipe WinUI/Sillverlight.

Potensinya adalah ekosistem MS yang tidak terlalu terfragmentasi dan jauh lebih kuat, mulai dari web dan diakhiri dengan aplikasi asli x-platform menggunakan .net 5 terpadu.

@lukasf :

@MarkIngramUK Saya melihatnya seperti ini: Aplikasi sederhana tetap pada kontrol UI stok suatu platform. Aplikasi hebat memiliki tampilan+rasanya sendiri. Mereka tidak membutuhkan kontrol platform saham. Lihat Spotify, Netflix, atau aplikasi hebat+sukses lainnya yang tersedia untuk berbagai platform. Anda tidak dapat mengetahui platform yang mereka gunakan, hanya dengan melihat kontrol mereka.

Saya ingin aplikasi lintas platform saya terlihat dan terasa sama persis di semua platform.

Kami menggabungkan kedua pendekatan untuk aplikasi kami (https://affinity.serif.com). Pelanggan kami bisa sangat vokal jika kami tidak mengadopsi standar platform umum, misalnya pemesanan tombol pada dialog (Windows biasanya OK lalu Batal, sedangkan macOS Batal lalu OK), tombol dengan sudut bulat, status melayang, kotak centang vs sakelar, tata letak kontrol dll. Jadi ya, di permukaan, aplikasi kami terlihat sama pada platform Windows dan macOS, tetapi kami memiliki perbedaan halus (rendering dan interaksi UI). Kami juga memanfaatkan sepenuhnya platform host kami dengan menggunakan API asli mereka, dan oleh karena itu kami tidak pernah mengalami masalah penyebut umum terendah.

Saya masih berpikir diskusi di atas menyesatkan, WinUI adalah kerangka UI tingkat terendah yang disediakan Microsoft. Jika Anda menginginkan perpustakaan lintas platform, maka bangun di atasnya. Ini sama dengan mengatakan, "Win32 harus lintas platform!". Tidak, Win32 harus menjadi kerangka kerja terbaik untuk platform Windows. Argumen yang sama di sini, WinUI harus menjadi kerangka kerja terbaik untuk platform Windows 10.

@MarkIngramUK menulis:

WinUI adalah kerangka kerja UI tingkat terendah yang disediakan Microsoft. Jika Anda menginginkan perpustakaan lintas platform, maka bangun di atasnya.

Itu menurut saya sebagai solusi praktis yang benar-benar bisa berhasil, tergantung pada detailnya (walaupun belum tentu satu-satunya solusi). Dua lapisan:

1. Microsoft WinUI: Bukan lintas platform.
2. Microsoft CrossXYZ-UI: Lintas platform. Implementasi internalnya untuk Windows akan ditulis menggunakan WinUI.

Solusi 2 lapis seperti itu akan membantu mengurangi masalah yang saya sebutkan dalam pesan asli saya:

Versi WinUI yang berpotensi baru mungkin secara substansial tertunda karena peningkatan jumlah pekerjaan/kesulitan mempertahankan dukungan untuk beberapa sistem operasi yang berbeda. Misalnya, "Kami bisa saja merilis versi baru WinUI ini, beberapa bulan yang lalu, kecuali untuk masalah bahwa kami telah menyelesaikan debugnya hanya untuk Windows dan belum untuk Android atau MacOS atau Apple iOS."

Menurut pengalaman saya dengan pengembangan lintas platform di masa lalu, saya perhatikan bahwa solusi 2 lapis ini akan lebih berhasil jika berbagai perubahan/penambahan diterapkan di WinUI untuk tujuan mendukung dan membantu lintas platform terpisah "CrossXYZ -UI" lapisan. Jika tidak, jika WinUI tidak melakukan apa pun untuk membantu lapisan lintas platform, maka menurut pengalaman saya, ini biasanya berarti bahwa lapisan lintas platform sering dipaksa untuk melompati lingkaran berkerut yang membuat pemrograman dan keandalan menjadi sulit dan tertunda.

Menurut teori layering, WinUI tidak perlu tahu atau peduli tentang lapisan "CrossXYZ-UI" yang menggunakan WinUI, tetapi teori itu berfungsi buruk dalam praktiknya di dunia nyata, oleh karena itu saya mengatakan bahwa WinUI perlu memperhitungkan dan membantu lapisan "CrossXYZ-UI", tapi maksud saya bukan ide mengerikan untuk membuat dependensi pada "CrossXYZ-UI" di dalam WinUI, dan maksud saya bukan kait pribadi khusus di dalam WinUI yang hanya digunakan oleh "CrossXYZ-UI ". 2 lapisan masih harus disimpan terpisah dengan cara yang bersih. Saya hanya mengatakan bahwa ketika keputusan desain API dibuat untuk WinUI, keputusan ini perlu dilakukan dengan pertimbangan dampaknya pada lapisan "CrossXYZ-UI" yang terpisah, dan dengan pertimbangan bagaimana WinUI dapat membuat hidup lebih mudah bagi " CrossXYZ-UI", tidak hanya dengan pertimbangan untuk aplikasi yang langsung menggunakan WinUI.

Saya tidak tahu apakah Xamarin sudah mencoba untuk beroperasi dengan cara 2-lapisan yang dijelaskan di atas, tetapi jika ya, maka saya membayangkan saat ini mengecualikan bagian dari gagasan di mana WinUI mendukung/membantu lapisan lintas platform yang terpisah. Sulit untuk mempercayai Xamarin ketika Microsoft tidak cukup mempercayai Xamarin untuk menggunakannya untuk Microsoft Teams dan berbagai aplikasi Microsoft lainnya.

Di masa lalu, saya menerbitkan perangkat lunak lintas platform yang berfungsi dengan sukses dan dengan kinerja yang baik, tetapi saya akhirnya membatalkan pekerjaan lintas platform karena alasan non-teknis. Misalnya, pelanggan yang menggunakan perangkat lunak versi Linux bersikeras bahwa harga perangkat lunak harus $0. Jadi biaya produksi dan pemeliharaan versi Linux jauh melebihi $0 pendapatan dari "pelanggan" yang menggunakan Linux, sehingga jelas tidak berkelanjutan.

Sebagai pengembang aplikasi, hanya karena Anda _dapat_ secara teoritis menghasilkan aplikasi lintas platform, itu tidak selalu berarti Anda _harus_. Menariknya, saya perhatikan dalam diskusi lintas platform saat ini bahwa orang menyebut Android tetapi bukan Linux lagi. Salah satu alasan terbesar untuk perubahan ini mungkin adalah masalah $0 yang disebutkan di atas.

Platform Re Uno:

Bahkan jika Uno memiliki desain dan implementasi teknis yang andal dan andal, risiko dan kekhawatirannya adalah bahwa Uno mungkin menghilang dalam beberapa tahun karena masalah $0 yang serupa atau pendapatan yang tidak mencukupi yang pada akhirnya memicu kejenuhan dan pembatalan atau stagnasi proyek. Atau sekadar pengembang Uno yang paling penting suatu hari tiba-tiba mendapatkan hobi/minat/obsesi baru dan kehilangan minat pada Uno, atau pekerjaan/majikan baru dan tidak ada lagi waktu untuk mengerjakan Uno. Seperti yang dikatakan @mdtauk :

banyak perusahaan yang ingin berinvestasi dalam membangun aplikasi atau sistem, perlu mengetahui bahwa platform yang mereka kembangkan memiliki dukungan dan umur panjang dari perusahaan besar dengan sumber daya yang luas seperti Microsoft.

Saya juga setuju dengan komentar lain @mdtauk :

Masalah dengan argumen itu adalah bahwa dekade terakhir telah menunjukkan Microsoft meninggalkan platform,

Ya Microsoft telah kehilangan beberapa derajat reputasi/kepercayaan/ketergantungan melalui pembatalan platform. Saya pikir Microsoft perlu berhati-hati untuk menghindari hilangnya reputasi dan kepercayaan lebih lanjut melalui pembatalan lebih lanjut. Versi baru dari platform yang ada lebih baik daripada platform baru.

Bahkan jika versi baru utama dari platform yang ada perlu memperkenalkan perubahan yang melanggar, itu masih lebih baik (atau kurang buruk) daripada platform baru dengan hilangnya reputasi/kepercayaan/ketergantungan yang menyertainya. Untuk pengembang aplikasi, biaya beralih ke platform baru sangat tinggi dan kadang-kadang sama sekali tidak terjangkau, oleh karena itu setiap kali Microsoft membatalkan platform, itu adalah berita yang sangat buruk dan merusak hubungan/kemitraan antara pengembang aplikasi dan Microsoft.

Jika menurut Anda pendekatan dua lapisan itu sangat menarik, maka Anda dapat melanjutkan sekarang dan menggunakan Xamarin atau Uno. Anda tidak perlu menunggu kerangka kerja seperti itu, mereka sudah ada dan bekerja dengan sangat baik. Tetapi Anda akan kehilangan semua manfaat dan peningkatan dari WinUI segera setelah Anda menargetkan Android atau iOS. Tidak ada lagi NavigationView, tidak ada AppBars, tidak ada lagi SemanticZoom, dll. Apa pun yang dilakukan dalam repo ini, semua peningkatan tidak tersedia lintas platform, karena lintas platform berarti penyebut umum terendah. Anda hanya dapat menggunakannya jika Anda secara khusus menargetkan platform Windows. Jadi, Anda harus menerapkan kembali semua hal keren WinUI lagi secara manual, menggunakan kontrol asli Android atau iOS.

Jika itu terdengar bagus untuk Anda, gunakan saja Xamarin atau Uno. Tidak perlu kerangka ketiga seperti ini. Tapi bagi saya ini tidak terdengar bagus sama sekali. Saya ingin satu kerangka kerja dengan set kontrol yang hebat, yang dapat digunakan untuk menargetkan semua platform secara langsung, dengan fungsionalitas penuh di setiap platform. Saya tidak ingin mengimplementasikan kembali navigasi aplikasi saya dan hal-hal di setiap platform secara terpisah, memiliki definisi UI yang rumit dan duplikat. Bagi saya itu terdengar seperti ide yang mengerikan. Jika WinUI adalah lintas platform menggunakan pendekatan penyaji, saya dapat langsung menggunakan semua fiturnya dan setiap peningkatan di sini di setiap platform. Dan jika saya ingin kontrol saya terlihat lebih seperti iOS pada target itu, saya bisa menerapkan iOS ResourceDictionary. Masalah terpecahkan, tanpa harus mengacaukan kontrol asli dan menggandakan implementasi UI.

Argumen bahwa rilis akan ditunda karena "perender untuk platform lain tidak diperbarui" adalah argumen yang tidak realistis. Lapisan rendering bekerja pada perintah menggambar tingkat rendah seperti "menggambar persegi panjang, menggambar garis, menggambar teks". Jika Anda menambahkan kontrol baru ke WinUI, Anda menulis logika kontrol Anda dan Anda menyediakan template kontrol, yang menggunakan Grid, Borders, TextBoxes dan hal-hal seperti itu. Tidak ada kontrol baru yang memerlukan pembaruan pada penyaji, penyaji akan memiliki tingkat yang sangat rendah dan dengan tingkat perubahan yang sangat rendah. Hanya ada kasus langka di mana penyaji perlu disentuh, misalnya saat menambahkan kuas atau efek baru. Qt menggunakan pendekatan penyaji dan ini adalah salah satu kerangka kerja UI lintas platform yang paling populer. Pendekatan ini tampaknya bekerja sangat baik untuk mereka.

@lukasf

Saya ingin satu kerangka kerja dengan set kontrol yang hebat, yang dapat digunakan untuk menargetkan semua platform secara langsung, dengan fungsionalitas penuh di setiap platform.

Setiap insinyur dan dolar yang dihabiskan untuk membuat WinUI cross-plat adalah insinyur dan dolar yang bisa digunakan untuk membuat WinUI di Windows lebih baik.

Argumen bahwa rilis akan ditunda karena "perender untuk platform lain tidak diperbarui" adalah argumen yang tidak realistis.

Bukan hanya tugas sederhana untuk membuat mesin rendering 1:1 yang sempurna yang bekerja di iOS, Android, MacOS, Linux, dan Windows 7/8. Ada banyak sekali API Windows 10 yang diandalkan oleh aplikasi & kerangka kerja. Anda pada dasarnya akan membuat kerangka kerja aplikasi yang benar-benar baru.

Juga, lihat utas Reddit baru-baru ini: Apa yang harus saya gunakan untuk antarmuka pengguna di C #

Secara harfiah nol menyebutkan WinUI, dan satu setengah rekomendasi untuk menggunakan UWP. Pengembang harus antusias menggunakan WinUI di Windows jauh sebelum mencoba membuatnya lintas-plat, mengingat semua investasi besar yang diperlukan.

@lukasf ,

Anda dapat melanjutkan sekarang dan menggunakan Xamarin atau Uno

Saya menyinggungnya di posting saya sebelumnya, tetapi kami menulis ujung depan yang terpisah untuk setiap platform yang kami targetkan. Windows (WPF), macOS (Cocoa), iOS (UIKit).

jika saya ingin kontrol saya lebih mirip iOS pada target itu, saya bisa menerapkan iOS ResourceDictionary. Masalah terpecahkan

Sampai pengguna memperbarui OS mereka dan semua aplikasi berubah tampilan, kecuali milik Anda.

Lapisan rendering berfungsi pada perintah menggambar tingkat rendah seperti ...

Anda membutuhkan lebih dari sekadar rendering untuk lintas platform. Manajemen jendela, input, penanganan teks, rendering, integrasi sistem (mis. Taskbar / Aero Peek dll). Tidak mungkin mencoba mengubah fokus WinUI dari Windows-only ke cross-platform tidak akan menyebabkan penundaan yang ekstrem.

Dalam hal rendering, WinUI dibangun di atas Windows.UI.Composition , jadi Anda harus sepenuhnya mengganti perpustakaan tingkat yang lebih rendah itu, dengan sesuatu yang bersifat lintas platform, dan mudah-mudahan tidak menimbulkan penalti kinerja apa pun dari abstraksi Anda, dan kemudian port itu ke platform lain. Atau, tulis ulang WinUI sepenuhnya agar tidak bergantung pada Windows.UI.Composition . Sekali lagi, bukan pekerjaan kecil.

Hanya untuk mengulangi - Saya tidak menentang perpustakaan lintas platform. Mereka melayani suatu tujuan, saya hanya tidak berpikir WinUI harus menjadi satu.

@lukasf

karena cross-platform maka berarti common denominator terendah. ...... Saya ingin satu kerangka kerja dengan set kontrol yang hebat, yang dapat digunakan untuk menargetkan semua platform secara langsung, dengan fungsionalitas penuh di setiap platform.

Anda menginginkannya dengan fungsionalitas penuh di setiap platform -- saya juga -- terdengar luar biasa; sebuah mimpi -- tetapi hanya karena Anda dan saya menginginkannya, tidak berarti itu harus mungkin dan praktis. Keinginan dan hasilnya bisa sangat berbeda. Keinginan bisa menjadi fungsionalitas penuh sementara hasilnya sebagian besar menjadi masalah yang sama seperti yang Anda sebutkan - penyebut umum terendah. Ide Anda memiliki manfaat tetapi tidak kebal untuk menjadi korban masalah penyebut umum terendah yang Anda sebutkan.

Jika WinUI adalah lintas platform menggunakan pendekatan penyaji, saya dapat langsung menggunakan semua fiturnya dan setiap peningkatan di sini di setiap platform.

Benarkah SEMUA fiturnya dan SETIAP peningkatan di SETIAP platform? Apakah Anda yakin bahwa tujuan yang mengesankan seperti itu dapat dicapai hanya dengan mendasarkan WinUI pada penyaji lintas platform? Begitu mudahkah solusinya? Saya pikir Anda membuat ide itu tampak jauh lebih mudah daripada kenyataannya, karena sebenarnya lebih dari yang dibutuhkan penyaji, seperti:

• Manajemen jendela plus flyout, popup, menu konteks, dialog modal.
• Manajemen tampilan dan resolusi serta menanggapi perubahan.
• Perangkat input (keyboard, mouse, layar sentuh dengan gerakan, pena).
• Animasi.
• Font dan gaya, mendapatkan info dan pengukuran, tidak hanya rendering. Juga pemrosesan teks unicode.
• Seret dan lepas.
• Clipboard cut/copy/paste yang bekerja dengan berbagai format, tidak hanya teks.
• Menggulir dengan kinerja yang baik, tidak seperti kinerja gulir yang buruk dari panel obrolan di MS Teams.
• Membaca/memuat sumber daya (dari berbagai jenis) yang disimpan di dalam paket aplikasi, seperti sumber daya gambar dan lainnya.
• Pemutaran audio dan video.
• Otomatisasi untuk pembaca layar dll untuk aksesibilitas.
• Tema/penampilan konsisten dengan apa pun yang saat ini dikonfigurasi di OS.
• Pengambilan berbagai pengaturan OS yang memengaruhi GUI, seperti pemformatan internasional, pengaturan mouse dan keyboard, dll.
• Masalah untuk mendukung perangkat seluler plus tablet plus desktop.
• Dan berbagai hal lainnya ditambah ratusan detail yang mudah dilupakan saat memperkirakan ukuran proyek dan tanggal rilis.

Saya masih berpikir ide Anda memiliki manfaat tetapi jauh lebih sulit dan jauh lebih tidak jelas daripada yang Anda buat. Itu juga bisa sangat memperlambat pengembangan dan kemajuan WinUI.

Tidak bisakah WinUI/MS memanfaatkan proyek Blazor untuk menjadikan WinUI sebagai Aplikasi "Blazor Asli"?

@pinox , ya kami pasti bisa, tetapi Blazor Native tidak akan menjadi lintas platform, kecuali jika mereka menargetkan Uno (yang akan menjadi preferensi pribadi saya).

Cross-plat jelas merupakan sesuatu yang telah kami pikirkan, dan kami telah melakukan beberapa penyelidikan yang cukup menyeluruh terhadap arsitektur kerangka kerja lintas platform yang berbeda. Kami sampai pada kesimpulan yang sama yang dimiliki semua orang di utas ini, yaitu bahwa kedua solusi memiliki pro dan kontra, dan bahwa pelanggan kami cukup terpecah

@lukasf Saya pikir "penyebut umum terendah" yang saat ini ada di Uno adalah masalah keterbatasan sumber daya, dan bukan karena pelapisan. Saya ingin sekali terbukti salah, tetapi saya pikir masalah itu bisa diselesaikan, dan tidak menjadi lebih buruk di masa depan.

Ada subset XAML untuk menawarkan rendering kontrol UI dan jendela yang tampak asli - atau Anda dapat memiliki renderer di macOS, iOS, Android, Linux - dan merender kontrol dan template "Lancar" yang sama di semua platform.

Selain membuat semacam varian implementasi CoreWindow / App Window agar berfungsi dengan OS asli - semua yang ada di dalam jendela, dapat dirender.

Di Windows itu DirectX, tapi Apple punya Metal, dan Linux punya OpenGL. Pengembang harus melakukan semacam pernyataan IF untuk menangani file asli IO, Pemberitahuan, dll - tetapi Xamarin akan membantu dengan itu

@stevenbrix -- Saya melihat Anda membalas ide @Pinox _"render WinUI sebagai Aplikasi Asli Blazor",_ tetapi apa pendapat Anda tentang ide _other_ Pinox? Menariknya, @Pinox juga menulis:

Saat ini Electron menggunakan Javascript, HTML + CSS. Tidak ada alasan mengapa kami tidak dapat menggunakan Electron dengan Blazor => C# , HTML + CSS + gRPC.

@Pinox -- Saya setuju bahwa "Electron C#" akan tampak lebih masuk akal daripada "Electron JS", tetapi jika menggunakan C# dan Blazor seperti yang Anda sarankan, maka saya pikir aplikasi MS Teams mungkin tidak membutuhkan Electron lagi karena Blazor akan sepenuhnya menggantikan Electron? Saya bisa saja salah -- saya tidak cukup tahu tentang fitur apa saja yang didukung Electron. Meskipun, jika ElectronJS saat ini memiliki fitur berguna yang tidak dimiliki Blazor, maka fitur yang hilang ini mungkin dapat didukung di versi Blazor berikutnya.

Jadi saya kira Anda mengangkat poin penting dengan menyebutkan Blazor. Solusi yang layak untuk aplikasi MS Teams mungkin beralih dari ElectronJS ke Blazor + WebAssembly. Itu sangat menarik.

Jika aplikasi MS Teams beralih dari ElectronJS ke Blazor, maka itu mungkin atau mungkin tidak menggunakan bagian mana pun dari WinUI. Baik koneksi atau non-koneksi antara Blazor dan WinUI dapat dieksplorasi lebih lanjut, seperti yang sudah Anda mulai lakukan. Menarik!

Silverlight, WinRT, UWP - semuanya ditinggalkan. (Saya tahu UWP tidak secara teknis, tetapi WinUI kemungkinan besar akan dilihat sebagai pengganti).

Pemahaman saya adalah bahwa UWP adalah runtime, sedangkan WinUI adalah GUI/widget layer/dll. Yaitu Win UI akan berjalan di Win32, atau .NET, tanpa UWP API.

Hal yang membuat saya gila adalah bahwa UWP sebenarnya adalah API yang cukup kompeten. Ini tidak sekuat Win32, tetapi dibandingkan dengan Android (misalnya) jauh lebih waras. Saya pikir pengembang telah melewatkan poin bahwa sekarang ada API runtime terpadu, yang memiliki model objek yang konsisten, API, tidak tumpul, dll, dll .... apakah ada orang lain di sini yang menulis aplikasi Win32 di tahun 90-an atau awal 00s sebelum .NET ada di tempat kejadian? Menggunakan API platform asli sangat buruk.

Kembali ke masalah yang dihadapi, saya benar-benar ingin melihat lintas platform WinUI. Ada posting tentang itu diikat ke COM dll ... Kerangka kerja plugin Core Foundation Apple (CFPlugin) adalah, IIRC, berdasarkan COM, jadi mungkin lift dan shift akan sesederhana menulis penyaji untuk platform Apple. Hal yang lebih logis adalah menutupi perbedaan platform dan mempertahankan objek WinUI tingkat tinggi.

Saya ingin melihat upaya lintas platform yang kohesif dari Microsoft, yang menargetkan Windows terutama, tetapi membeli model objek yang sepenuhnya kompatibel dan dialek XAML untuk seluler, Linux, dan macOS. Sudah ada ekosistem lintas platform yang fantastis (minus GUI) di .NET Core. Gunakan kerangka kerja XAML yang kompeten dan tidak akan sulit untuk semua pengembangan sisi klien, terutama jika visualnya terlihat asli. Misalnya CommandBar -> tampilan NSToolbar di Mac, Navigation View -> NSOutlineView di Mac, dll.

Nilai 2c saya, tetapi saya melihat fokus besar pada ini.

Saya juga berharap (meskipun saya tidak akan menahan nafas) bahwa Microsoft akan kembali memasuki pasar dengan telepon berbasis Windows. Menjadi lingkungan lintas platform yang meyakinkan akan sangat membantu tujuan ini.

Saya akan menonton diskusi ini dengan penuh minat.

Silverlight, WinRT, UWP - semuanya ditinggalkan. (Saya tahu UWP tidak secara teknis, tetapi WinUI kemungkinan besar akan dilihat sebagai pengganti).

Pemahaman saya adalah bahwa UWP adalah runtime, sedangkan WinUI adalah GUI/widget layer/dll. Yaitu Win UI akan berjalan di Win32, atau .NET, tanpa UWP API.

Secara teknis saya pikir WinRT (Windows RunTime) adalah runtime, dan UWP (Universal Windows Platform) dibangun di atas runtime itu. Dan UWP mendukung penggunaan XAML sebagai satu kerangka UI.

WinUI akan menjadi bagian XAML dari UWP, tetapi diperluas untuk memungkinkannya digunakan dengan kode Win32, dengan interop melalui Kepulauan XAML dengan kerangka kerja WPF dan WinForms.

Hal yang membuat saya gila adalah bahwa UWP sebenarnya adalah API yang cukup kompeten. Ini tidak sekuat Win32, tetapi dibandingkan dengan Android (misalnya) jauh lebih waras. Saya pikir pengembang telah melewatkan poin bahwa sekarang ada API runtime terpadu, yang memiliki model objek yang konsisten, API, tidak tumpul, dll, dll .... apakah ada orang lain di sini yang menulis aplikasi Win32 di tahun 90-an atau awal 00s sebelum .NET ada di tempat kejadian? Menggunakan API platform asli sangat buruk.

UWP dibangun dengan pendekatan modern untuk masa pakai baterai, keamanan, identitas, validasi toko - semua hal yang diharapkan pengembang dari platform seperti macOS, iOS, dan Android. Karena kualitas yang melekat itu, ia dapat bekerja di banyak faktor bentuk dan jenis perangkat.

Kembali ke masalah yang dihadapi, saya benar-benar ingin melihat lintas platform WinUI. Ada posting tentang itu diikat ke COM dll ... Kerangka kerja plugin Core Foundation Apple (CFPlugin) adalah, IIRC, berdasarkan COM, jadi mungkin lift dan shift akan sesederhana menulis penyaji untuk platform Apple. Hal yang lebih logis adalah menutupi perbedaan platform dan mempertahankan objek WinUI tingkat tinggi.

Saat Anda mempertimbangkan dukungan .NET Core, yang sudah didukung lintas platform, lapisan UI adalah bagian yang hilang. WinUI awalnya sepenuhnya berfokus pada Windows, tetapi mudah-mudahan pada waktunya, Microsoft dapat melakukan refactor sedemikian rupa, sehingga platform dapat menggantikan rendering mereka sendiri yang memungkinkan UI identik untuk berjalan di berbagai platform.

Saya ingin melihat upaya lintas platform yang kohesif dari Microsoft, yang menargetkan Windows terutama, tetapi membeli model objek yang sepenuhnya kompatibel dan dialek XAML untuk seluler, Linux, dan macOS. Sudah ada ekosistem lintas platform yang fantastis (minus GUI) di .NET Core. Gunakan kerangka kerja XAML yang kompeten dan tidak akan sulit untuk semua pengembangan sisi klien, terutama jika visualnya terlihat asli. Misalnya CommandBar -> tampilan NSToolbar di Mac, Navigation View -> NSOutlineView di Mac, dll.

Segera setelah Anda mulai melihatnya dengan cara ini, di mana Anda menerjemahkan Windows ke kontrol dan konsep Asli Platform, Anda berakhir dengan Xamarin Forms. Anda menargetkan pendekatan penyebut umum terendah, daripada mengizinkan UI Identik untuk berjalan di mana-mana.

Nilai 2c saya, tetapi saya melihat fokus besar pada ini.

Saya juga berharap (meskipun saya tidak akan menahan nafas) bahwa Microsoft akan kembali memasuki pasar dengan telepon berbasis Windows. Menjadi lingkungan lintas platform yang meyakinkan akan sangat membantu tujuan ini.

Saya akan menonton diskusi ini dengan penuh minat.

Saya pikir salah satu bagian dari cerita ini, yang belum dirinci adalah memungkinkan aplikasi UWP untuk dikompilasi, dan berjalan di Android - yang akan menyelesaikan masalah aplikasi yang berjalan di Surface Duo.

Ada proyek Astoria... Android di Windows Bridge, yang bisa masuk ke Windows untuk memungkinkan aplikasi Android masuk ke Microsoft Store. Setelah Microsoft memiliki basis kode Android mereka sendiri, itu membuat prospek lebih mudah untuk dibayangkan.

Saya melihat Anda membalas ide @Pinox "render WinUI sebagai Aplikasi Asli Blazor", tetapi apa pendapat Anda tentang ide Pinox yang lain? Menariknya, @Pinox juga menulis:

Saat ini Electron menggunakan Javascript, HTML + CSS. Tidak ada alasan mengapa kami tidak dapat menggunakan Electron dengan Blazor => C# , HTML + CSS + gRPC.

Saya setuju bahwa "Electron C#" akan tampak lebih masuk akal daripada "Electron JS", tetapi jika menggunakan C# dan Blazor seperti yang Anda sarankan, maka saya pikir aplikasi MS Teams mungkin tidak membutuhkan Electron lagi karena Blazor akan sepenuhnya menggantikan Elektron? Saya bisa saja salah -- saya tidak cukup tahu tentang fitur apa saja yang didukung Electron. Meskipun, jika ElectronJS saat ini memiliki fitur berguna yang tidak dimiliki Blazor, maka fitur yang hilang ini mungkin dapat didukung di versi Blazor berikutnya.

@verelpode seperti yang saya pahami, Elektron akan selalu ada dalam gambar. Jika Teams secara hipotetis pindah ke Blazor, mereka masih menginginkan aplikasi klien mandiri seperti yang mereka lakukan hari ini, dan Electron paling masuk akal bagi mereka. Secara teori, dan seseorang dapat mengoreksi saya jika saya salah, tetapi beralih ke Blazor + WebAssembly akan membuat kinerja aplikasi mereka jauh lebih baik saat dijalankan di Electron. Meskipun saya berani bertaruh masalah kinerja mereka lebih disebabkan oleh masalah arsitektur daripada yang lainnya, VS Code adalah aplikasi Electron dan saya sangat terkesan dengan kinerja di sana.

Perlu diingat bahwa WebAssembly juga dapat berjalan di luar WebBrowser...
Saya melihat Blazor sebagai cara dari yang datang dari ASP.Net, sebuah eksperimen yang membawa .NET ke WebBrowser, tetapi jalur yang paling lengkap adalah XAML di .NET Core, Xamarin, UWP/WinUI dan UNO; XAML lengkap pada WinUI /Windows 10 dan sebagian dari XAML-nya juga dapat berjalan di Web.

@verelpode @stevenbrix Pemahaman saya adalah bahwa Blazor berjalan pada kawat di Elektron. Jadi langsung dari .net core ke Electron dengan menggunakan gRPC. Oleh karena itu saluran gRPC berkomunikasi dengan elektron dan bukan lagi penyaji JS yang saya asumsikan. Tolong koreksi saya jika saya salah. Tidak ada WASM yang terlibat.

Akan sangat menarik untuk melihat peningkatan kecepatan menggunakan gRPC secara langsung dengan Electron. Dalam pikiran saya itu bisa sangat besar jika dioptimalkan.

Dalam klip youtube Steve Sanderson dia menyebutkan penggunaan no WASM ( 53:13 menit ke dalam video )
https://www.youtube.com/watch?v=uW-Kk7Qpv5U

Tidak dapat mengingat di mana saya membaca bagian gRPC, Ngomong-ngomong, oleh karena itu saya menyelidiki komunitas apakah sesuatu seperti Silverlight yang setara dengan WinUI menggunakan gRPC dengan Electron dimungkinkan? Tidak ada WASM, bisa dibilang begitu.

@verelpode @stevenbrix Pemahaman saya adalah bahwa Blazor berjalan pada kawat di Elektron. Jadi langsung dari .net core ke Electron dengan menggunakan gRPC. Oleh karena itu saluran gRPC berkomunikasi dengan elektron dan bukan lagi penyaji JS yang saya asumsikan. Tolong koreksi saya jika saya salah. Tidak ada WASM yang terlibat.

Akan sangat menarik untuk melihat peningkatan kecepatan menggunakan gRPC secara langsung dengan Electron. Dalam pikiran saya itu bisa sangat besar.

Dalam klip youtube Steve Sanderson dia menyebutkan penggunaan no WASM ( 53:13 min ) ke dalam video.
https://www.youtube.com/watch?v=uW-Kk7Qpv5U

Terima kasih @Pinox! Sepertinya aku harus menonton! Apa yang Anda gambarkan terdengar seperti Blazor sisi server bagi saya, saya sedang berpikir/berbicara tentang sisi klien yang berjalan di browser dan secara langsung memanipulasi DOM. Saya tidak akan mengatakannya lagi sampai setelah saya menonton video itu, karena saya bisa memasukkan kaki saya ke mulut saya dengan mengatakan hal-hal seperti itu

@stevenbrix Anda mungkin benar tetapi aplikasi elektron berjalan offline karenanya saya berasumsi ini bukan rendering sisi server.

Dugaan saya adalah jika perender JS menggunakan gRPC untuk berbicara dengan Electron maka Anda dapat menggunakan mesin silet blazer untuk melakukan hal yang sama.

gRPC adalah fitur baru di .net core 3.0. Blazor mendukung .net core 3.
Oleh karena itu gRPC di .net core 3 membuka kemungkinan untuk mengganti teknologi JS yang ada dengan c# dengan menggunakan "tautan umum" (gRPC) . Pintar bergerak MS ;))

tetapi aplikasi elektron berjalan offline karenanya saya berasumsi ini bukan rendering sisi server.

@Pinox - ya itu membuat saya agak bingung. Saya menduga itu menggunakan https://github.com/ElectronNET/Electron.NET , tapi itu murni spekulatif

jika aplikasi MS Teams beralih dari ElectronJS ke Blazor, maka itu mungkin atau mungkin tidak menggunakan bagian mana pun dari WinUI. Baik koneksi atau non-koneksi antara Blazor dan WinUI dapat dieksplorasi lebih lanjut, seperti yang sudah Anda mulai lakukan. Menarik! >

@verelpode yang membuat gambar ini sangat menarik adalah "jangkauan" Blazor. Sebagai seorang app guy, saya dapat mengatakan bahwa pengalaman saya yang terbatas dengan Blazor sejauh ini adalah => wow ini terasa sangat berkinerja, hampir seperti aplikasi. Melihat gambar, peta jalan hampir pasti akan menyertakan WinUI sebagai platform asli. (walaupun saat ini tidak terikat)

Jika mereka dapat membuat flutter bekerja di sisi Blazor Native, apa yang menghentikan tim Blazor untuk menghubungkan platform React Native untuk menjangkau semua platform asli tersebut. Blazor dapat dengan mudah menjadi perekat bagi pengembang C# dalam segala hal.

Bagi saya, tujuan jangka pendeknya adalah naik bus dengan UI HTML untuk melengkapi WinUI saya yang sudah ada.
Antara WinUI / Xamarin dan Blazor hampir tidak ada yang tidak bisa saya lakukan. Satu basis kode, 3 kerangka kerja UI. Ini akan menjadi sangat menarik untuk melihat ke mana arahnya karena pilihannya tampaknya tidak ada habisnya.

Bagi saya yang terbaik selalu super performant .net core (C#) => Blazor ??? => UI asli - ini akan menjadi upaya rekayasa utama.

Saya harus mengatakan bahwa ini adalah diskusi yang sangat menginspirasi! Banyak pandangan dan argumen yang berbeda, banyak fakta yang bahkan tidak saya ketahui ("Blazor + Native UI?? Wow").

Seperti yang telah disebutkan @stevenbrix , tampaknya ada perpecahan di komunitas antara mereka yang ingin menjalankan UI yang sama persis pada kerangka kerja yang berbeda (pendekatan perender) dan mereka yang ingin merender di setiap platform menggunakan kontrol asli. Kedua pendekatan tersebut memiliki kelebihan dan kekurangannya masing-masing. Saya setuju dengan @stevenbrix bahwa dengan tenaga yang cukup, masalah "penyebut umum terendah" dapat diatasi (misalnya kontrol WinUI tidak tersedia secara asli pada platform X secara internal dapat direalisasikan di Uno oleh sekelompok kontrol asli tingkat yang lebih rendah dari platform X itu, atau dengan rendering kustom parsial). Kemudian kita bisa memiliki hampir set kontrol WinUI lengkap yang tersedia, tetapi masih mendapatkan rendering asli. Sayangnya, sumber daya Uno tampaknya agak terbatas saat ini, mengingat banyaknya masalah terbuka di github mereka.

Apa yang jelas di sini adalah bahwa ada permintaan yang tinggi di komunitas untuk kerangka kerja lintas platform yang menarik, berkinerja tinggi. Dan tidak ada kerangka kerja yang tersedia saat ini yang benar-benar memenuhi salah satu dari dua sisi komunitas (terpisah). Akan sangat menarik untuk melihat apakah Microsoft memiliki rencana untuk memperbaiki situasi.

Saya akan mengatakan, dengan Surface Duo dan Neo di cakrawala, Microsoft harus membuat cerita yang tepat tentang bagaimana mengembangkan aplikasi lintas platform yang berjalan di Surface Duo dan Surface Neo. Mungkin Microsoft harus membeli Uno dan mendanainya dengan benar, sehingga mereka dapat memperbaiki semua masalah terbuka itu dan menambahkan lebih banyak dukungan kontrol. Atau kembangkan lapisan rendering Android untuk WinUI. Dengan perangkat yang direncanakan untuk Liburan 2020, semuanya harus segera mulai bergerak.

@lukasf

dengan tenaga kerja yang cukup, masalah "penyebut umum terendah" dapat diatasi

Tenaga kerja yang cukup... Saya setuju dengan semua yang ada dalam pesan Anda, tetapi saya juga ingin menekankan kerugian signifikan yang disebutkan @kmgallahan :

Setiap insinyur dan dolar yang dihabiskan untuk membuat WinUI cross-plat adalah insinyur dan dolar yang bisa digunakan untuk membuat WinUI di Windows lebih baik.

Saya terpecah karena di satu sisi, lintas platform akan sangat bagus (jika itu benar-benar berfungsi dengan baik), tetapi di sisi lain, saya tidak ingin lintas platform jika itu menyebabkan penundaan besar dalam perbaikan berbagai masalah di WinUI pada Windows, atau jika itu menghambat kemajuan WinUI terlalu banyak dan menghalangi peningkatan dan fitur baru.

Bagaimana jika topik lintas platform berarti bahwa kita semua dipaksa untuk memilih di antara salah satu hasil berikut?

1. Versi luar biasa dari WinUI yang hanya berjalan di Windows; atau
2. WinUI berkualitas sedang, tidak dapat diandalkan, dan/atau lambat yang berjalan di setiap platform, dan mengalami laju pengembangan yang sangat lambat dengan banyak masalah luar biasa yang belum diperbaiki selama 5 hingga 10 tahun.

Itu masalah besar yang perlu dicegah. Dalam kegembiraan untuk lintas platform, sangat mudah untuk secara tidak sengaja berhenti memperhatikan pencegahan masalah besar ini.

Bagaimana jika topik lintas platform berarti bahwa kita semua dipaksa untuk memilih di antara salah satu hasil berikut?

1. Versi luar biasa dari WinUI yang hanya berjalan di Windows; atau

2. WinUI berkualitas sedang, tidak dapat diandalkan, dan/atau lambat yang berjalan di setiap platform, dan mengalami laju pengembangan yang sangat lambat dengan banyak masalah luar biasa yang belum diperbaiki selama 5 hingga 10 tahun.

@verelpode Pertama, Anda melebih-lebihkan di sini. Kedua: Microsoft memiliki sumber daya yang besar. Seharusnya tidak menjadi masalah sama sekali untuk mendanai peningkatan WinUI asli dan solusi lintas platform, jika Microsoft benar-benar tertarik untuk menyediakan kerangka kerja lintas platform. Sebenarnya mereka sedang melakukan itu sekarang: Mereka mengembangkan dan meningkatkan WinUI, dan pada saat yang sama mereka mengembangkan dan meningkatkan Xamarin. Mereka memiliki banyak proyek yang terjadi pada waktu yang sama. Jadi, jika Microsoft benar-benar berkomitmen untuk menyediakan kerangka kerja UI Windows yang hebat (yang pasti) dan menyediakan kerangka kerja lintas platform (yang akan sangat masuk akal dengan Surface Neo dan Duo di cakrawala), maka kami tidak memilikinya untuk memilih. Keduanya bisa diwujudkan tanpa kompromi. (Dan umumnya tidak seperti ini adalah sesuatu yang dapat kita pilih. Microsoft akan mengambil keputusan mereka dan kita akan melihat apa hasilnya.)

Jadi mendanai kerangka kerja lintas platform tidak berarti sama sekali bahwa pengembangan dan stabilitas WinUI harus menderita. Jika strategi Uno dipilih, Uno sepenuhnya independen dari WinUI, karena berada di atas. WinUI dapat dikembangkan lebih lanjut, dan Uno mencoba untuk mengambil kontrol dan konsep WinUI baru (mungkin pada tingkat yang lebih lambat). Juga jika pendekatan penyaji dipilih, itu tidak berarti bahwa itu akan menunda WinUI di Windows. Bisa jadi versi WinUI baru rilis tapi renderer androidnya belum ada. Kemudian pengembangan lintas platform akan menggunakan rilis WinUI yang lebih lama, hingga perender Android diperbarui ke WinUI vLatest. Pengembang Windows dapat menggunakan WinUI vLatest sejak awal. Jika sumber daya ada, keduanya dapat dikembangkan dengan kecepatan yang sama.

@lukasf

Microsoft memiliki sumber daya yang besar.

Benar, benar, tetapi ada sisi lain dari itu yang juga benar: Banyak manajer proyek telah belajar dengan cara yang sulit bahwa membuang lebih banyak uang, staf, dan sumber daya pada sebuah proyek tidak selalu menghasilkan kesuksesan.

Microsoft memiliki sumber daya yang besar.

Benar, benar, tetapi ada sisi lain dari itu yang juga benar: Banyak manajer proyek telah belajar dengan cara yang sulit bahwa membuang lebih banyak uang, staf, dan sumber daya pada sebuah proyek tidak selalu menghasilkan kesuksesan.

Maka masalahnya mungkin manajer proyek dan struktur organisasi;)

Mungkin Microsoft harus membeli Uno dan mendanainya dengan benar, sehingga mereka dapat memperbaiki semua masalah terbuka itu dan menambahkan lebih banyak dukungan kontrol.

Saya tahu nventive telah mendekati Microsoft selama beberapa bulan terakhir (akuisisi Microsoft mungkin adalah strategi keluar mereka). Di Uno Conference juga ada partisipasi besar dari Microsoft. Bahkan Xamarin menggunakan Uno sekarang untuk mendukung web.

Saya tahu kita dapat memperdebatkan opsi (1) render asli atau (2) implementasi/lapisan UI lain tanpa henti tetapi melihat apa yang tersedia sekarang dan apa yang kita butuhkan untuk Duo permukaan, Uno sebenarnya adalah satu-satunya solusi yang masuk akal. Seperti yang dikatakan @lukasf , Microsoft harus membuang sumber daya mereka dan melihat seberapa jauh mereka bisa mendapatkan dalam setahun. Jika berhasil (fitur lengkap, stabil), saya tidak berpikir pengembang akan terlalu peduli tentang bagaimana itu diterapkan di belakang layar. Jika menjadi jelas bahwa pendekatan yang benar adalah WinUI yang diberikan secara asli untuk setiap platform yang dapat menjadi diskusi selama beberapa tahun ke depan. Saat ini lebih baik memulai dengan platform Uno 25% lengkap daripada tidak sama sekali.

@stevenbrix di sini :

@lukasf Saya pikir "penyebut umum terendah" yang saat ini ada di Uno adalah masalah keterbatasan sumber daya, dan bukan karena pelapisan. Saya ingin sekali terbukti salah, tetapi saya pikir masalah itu bisa diselesaikan, dan tidak menjadi lebih buruk di masa depan.

Kalian salah.
Uno tidak mengikuti mantra 'lowest common denominator' dari Xamarin, tetapi sebaliknya, ia mencoba untuk memastikan semua kontrol XAML (dan bahkan Windows Community Toolkit!), bekerja di semua platform.

Uno tidak mengikuti mantra 'lowest common denominator' dari Xamarin, tetapi sebaliknya, ia mencoba untuk memastikan semua kontrol XAML (dan bahkan Windows Community Toolkit!), bekerja di semua platform.

@weitzhandler Anda benar sekali! Saya percaya arsitektur mereka akan meminjamkan diri untuk suatu hari memiliki paritas lengkap dengan set kontrol WinUI, yang mungkin tidak mungkin dengan Xamarin.Forms. Jika saya mengerti dengan benar, set kontrol itu belum dibuat, itulah yang saya dan @lukasf maksudkan. Saya bisa saja salah, saya belum cukup bermain-main untuk mengetahuinya, saya hanya mempercayai apa yang saya dengar dari orang lain :)

Pendekatan @weitzhandler Uno untuk mengimplementasikan kembali API UWP/WinUI yang sebenarnya jauh lebih baik daripada penemuan Xamarin tentang dialek XAML baru. Tetapi jika Anda menjalankan Galeri Kontrol Uno Xaml, Anda akan menemukan beberapa area kosong. Set kontrol mereka pasti lebih baik daripada Xamarin.Forms, tetapi belum sepenuhnya UWP/WinUI. Saya pikir Uno membutuhkan lebih banyak pekerjaan di permukaan API, dan juga lebih banyak pekerjaan untuk membuat kontrol yang tersedia benar-benar stabil dan berfitur lengkap.

Saya bisa melihat Uno sebagai opsi yang layak. Tapi itu membutuhkan beberapa kemajuan nyata, di situlah Microsoft bisa ikut bermain.

Di titik yang berbeda, saya sangat setuju dengan apa yang dikatakan @lukasf di sini :

Aplikasi hebat memiliki tampilan+rasanya sendiri. Mereka tidak membutuhkan kontrol platform saham. Lihat Spotify, Netflix

Saya juga berpikir bahwa idealnya, solusinya adalah membuat desain WinUI + Lancar membuat yang sama di semua platform, dan mungkin menyediakan tema tampilan dan nuansa asli bagi mereka yang membutuhkan desain stok, untuk diterapkan pada platform tertentu.
Saya rasa web harus sama dengan desktop, jadi hanya Droid dan iOS yang menjadi kandidat untuk itu.

Kontrol lintas platform sebenarnya tidak bergantung pada kerangka kerja lintas platform.

Hipotesis: di masa mendatang, kontrol .Net tidak akan terbatas pada platform tertentu.

Ada kerangka kerja lintas platform UI .Net yang ada (Xamarin.Forms, Avalonia). Juga akan ada FutureXplatDotNetUI yang diimpikan semua orang dan tidak ada yang bisa mendefinisikannya.

Saat Anda membuat kontrol, Anda dapat membuatnya menggunakan fitur khusus platform. Misalnya pemutar video menggunakan pemutar asli di setiap platform. Atau Anda bisa melakukannya dengan cara platform-agnostik, misalnya menggunakan SkiaSharp.

Apa pun itu, kontrol Anda dapat diinstal ke proyek .Net UI mana pun.

Akibat wajar: FutureXplatDotNetUI hanya membutuhkan satu set kontrol minimal

Ini perlu mendefinisikan kelas Tampilan dan infrastruktur tata letak, tetapi tampilan atau grup tampilan tertentu dapat ditambahkan dengan menginstal paket .Net UI standar dari nuget.

(Posting ini adalah komentar pada lintas platform .Net UI dan karena itu tidak terkait dengan WinUI.)

Saya merasa bahwa prioritas tim WinUI saat ini bukan untuk "aplikasi Windows asli baru". Alih-alih, mereka lebih fokus pada memodernisasi aplikasi yang ada, dan menjadikan WinUI sebagai dukungan mendasar dari beberapa kerangka kerja UI tingkat yang lebih tinggi...

@reli-msft
Saya merasa bahwa tim WinUI sudah menyerah mengharapkan orang untuk menulis aplikasi Windows asli baru, dan WinUI dirancang untuk memutakhirkan aplikasi yang ada

Berasal dari orang yang bekerja di Microsoft itu agak aneh.

Saya merasa bahwa tim WinUI sudah menyerah mengharapkan orang untuk menulis aplikasi Windows asli baru, dan WinUI dirancang untuk memutakhirkan aplikasi yang ada

Berasal dari orang yang bekerja di Microsoft itu agak aneh.

@weitzhandler
Saya harus menggunakan kata yang lebih akurat yang saya gunakan ... Ini bukan "menyerah" tetapi "tidak peduli". Pokoknya itu hanya perasaan dari seseorang di luar tim WinUI.
Namun, memodernisasi aplikasi yang ada mungkin lebih penting _untuk saat ini_, dan mungkin itulah alasan WinUI memutuskan untuk mendukung Win32.

Anda berbicara tentang apa yang tim WinUI pikirkan.

Sebagai MS umum, sayangnya itu sebenarnya masuk akal.
Saya berharap Microsoft akan memberi WinUI cinta React atau Electron atau HTML CSS dan teknologi JS lainnya (baca komentar saya di atas ).

@charlesroddie

Anda selalu membutuhkan kerangka kerja untuk mengembangkan kontrol Anda. Anda memerlukan kelas dasar untuk diwarisi, antarmuka untuk diimplementasikan. Anda memerlukan kelas untuk mengakses pohon kontrol, templat, dll. Jadi, Anda benar-benar tidak dapat memisahkan kontrol dari kerangka kerja. Tidak ada kontrol yang dapat bekerja di banyak kerangka kerja, kecuali kerangka kerja tersebut menggunakan konsep, kelas, dan ruang nama yang persis sama.

Anda dapat membagikan beberapa kode antara kontrol WinUI (berbasis C#) dan WPF, tetapi masih akan sulit karena ruang nama yang berbeda dan API yang berbeda. Tetapi sangat tidak mungkin untuk membagikan kontrol XAML dengan kerangka kerja Android atau iOS.

Selain itu, saya benar-benar tidak yakin apakah .NET adalah teknologi yang tepat untuk membangun tumpukan UI. Microsoft mencobanya dengan WPF dan akhirnya menyerah dan beralih ke C++. Memiliki jeda GC selama tata letak dan rendering tidak membuat kesan terbaik bagi pengguna akhir, di saat animasi menjadi semakin penting. Mungkin ini tidak benar lagi jika Compositor tersedia, yang menangani animasi halus sepenuhnya terlepas dari utas UI. Kemudian tumpukan kontrol dapat berupa C# dan hanya bagian rendering dan animasi tingkat terendah yang akan menjadi kode asli. Namun saat itu, kinerja adalah alasan utama mengapa C# benar-benar ditinggalkan dalam kerangka kerja UI XAML berikut (Silverlight dan UWP/WinUI).

@lukasf Tidak ada kontrol yang dapat bekerja di banyak kerangka kerja

Ini tidak benar. Saya memberikan dua cara di mana kontrol dapat bekerja di banyak kerangka kerja. Pendekatan pertama adalah menulis kode khusus platform. Kemudian Anda perlu mengetahui kerangka kerja yang Anda dukung untuk menghubungkan kode khusus platform Anda ke setiap kerangka kerja; Anda dapat melakukan ini sekarang tetapi perancah dapat dibuat lebih mudah di masa depan. Pendekatan kedua (rendering platform-independen) sangat mudah dan sedang dilakukan sekarang. Misalnya CSharpMath.SkiaSharp dapat digunakan di semua platform .Net UI.

@charlesroddie Oke mungkin saya salah posting. Tapi kemudian kontrol tidak benar-benar independen dari kerangka kerja. Itu hanya dapat diinstal di aplikasi yang kerangka kerjanya secara eksplisit didukung oleh kontrol. Dan rendering hanyalah sebagian kecil dari sebuah kontrol. Logika kontrol, pengikatan data, dan penanganan input harus diterapkan untuk setiap kerangka kerja tunggal yang didukung, di setiap kontrol tersebut, bahkan jika Anda menggunakan perender platform independen. Itu tidak terdengar sangat efektif bagi saya, kecuali kerangka kerja yang didukung sangat mirip. Seperti yang saya nyatakan, dimungkinkan untuk membagikan beberapa kode antara WPF, Silverlight dan UWP. Tapi di luar itu menjadi sangat sulit, dan saya ragu saya akan pernah melihat kontrol seperti itu.

Kerangka kerja lintas platform biasanya memungkinkan Anda untuk menulis semua logika kontrol, penanganan data dan input (dan terkadang bahkan rendering) hanya sekali untuk satu API, dan kemudian secara otomatis akan memetakannya ke setiap kerangka kerja. Jadi begitu kerangka kerja ada, implementasi kontrol jauh lebih efisien.

Itu hanya dapat diinstal di aplikasi yang kerangka kerjanya secara eksplisit didukung oleh kontrol.

Itu benar, tetapi mendukung lebih banyak platform dapat dipermudah.

Logika kontrol, pengikatan data, dan penanganan input harus diterapkan untuk setiap kerangka kerja yang didukung.

Pengikatan data tidak perlu diimplementasikan oleh kerangka kerja UI. Ini adalah kesalahpahaman yang dipupuk oleh pendekatan .Net yang populer tetapi lebih rendah. Kontrol hanya perlu menentukan konstruktor dan properti. Mereka tidak perlu menentukan cara khusus apa pun untuk mengikat data karena begitu properti gettable/settable ditentukan, konsumen dapat menggunakan kerangka pendekatan apa pun untuk memindahkan data yang mereka inginkan. (Dan hampir semua pendekatan/kerangka kerja lebih baik daripada pengikatan data WPF/UWP/Xamarin.)

Logika kontrol secara alami diimplementasikan di .Net dengan cara yang tidak bergantung pada platform, sehingga dipenuhi dengan sempurna dalam kedua pendekatan yang saya berikan.

Penanganan input memang mendapat manfaat dari "kerangka kerja lintas platform", tetapi ini bisa menjadi kerangka kerja kontrol yang sangat kecil, yang dapat dirujuk dalam proyek khusus platform dan lintas platform, dengan API yang sangat kecil yang hanya mendefinisikan mouse/sentuh dan masukan papan ketik. Proyek kontrol SkiaSharp.Extended bergerak ke arah ini.

Jika Anda ingin pengikatan data berfungsi di WPF atau WinUI, maka Anda harus mendeklarasikan DependencyProperties. Saya sangat ragu bahwa siapa pun akan menggunakan kontrol XAML yang tidak berfungsi dengan pengikatan data. Pengikatan data adalah hal yang paling umum dari kerangka kerja ini, dan itu membutuhkan DependencyProperties untuk bekerja, jika Anda suka atau tidak. Jika Anda tidak menambahkannya, Anda tidak dapat menggunakan kontrol Anda di salah satu kerangka kerja platform Windows saat ini.

Dengan "logika kontrol" saya menyebutkan lebih banyak interaksi dengan kontrol lain, seperti mendefinisikan atau membuat sub-kontrol untuk kontrol tingkat atas Anda, penanganan data dan status antara kontrol, tata letak, sinkronisasi dengan sub-kontrol ini. Ini semua adalah kerangka kerja khusus. Itu dikombinasikan dengan kode pengikatan data (jika diperlukan oleh kerangka kerja target) dan penanganan input mungkin membuat >90% dari kode kontrol. Bagian umum antara implementasi kerangka kerja yang berbeda untuk satu kontrol seperti itu mungkin sangat kecil, hanya tidak masuk akal bagi saya untuk bekerja seperti itu.

Saya tidak mengatakan bahwa itu tidak bisa dilakukan. Tapi itu akan menjadi sangat rumit, karena kerangka kerja sangat berbeda. Maksud saya, adalah mungkin untuk menulis kontrol seperti itu sekarang, tetap saja saya belum pernah melihatnya. Dan secara pribadi saya tidak percaya bahwa ini akan menjadi pendekatan yang bahkan sedikit populer.

Anda tidak dapat menggunakan kontrol Anda di salah satu kerangka kerja platform Windows saat ini

Itu tidak benar. Kontrol yang tidak mengimplementasikan DependencyProperties dapat digunakan di WPF/WinUI. Ini adalah salah satu kelemahan dari pengikatan data .Net tradisional: ini mendorong penambahan DependencyProperties palsu ke kontrol yang sudah menentukan properti yang dapat diatur. Duplikasi kode besar. (Omong-omong, kontrol lintas platform tidak akan menjadi "kontrol XAML" dan Anda tidak boleh terpengaruh oleh penyalahgunaan "XAML" dalam bahasa pemasaran WinUI. Xaml adalah bahasa markup opsional yang dapat digunakan dengan beberapa . Kerangka UI bersih.)

sub-kontrol untuk kontrol tingkat atas Anda

Ya, kontrol perlu menentukan sub-kontrol, jadi agar kontrol tingkat yang lebih tinggi tersedia lintas platform, kontrol tingkat yang lebih rendah juga akan tersedia. Jika kontrol tingkat yang lebih rendah tersedia lintas platform, maka mengintegrasikannya dengan mudah. Anda membayangkan menulis kontrol tingkat yang lebih tinggi sebelum kontrol tingkat yang lebih rendah yang bukan merupakan pendekatan yang efisien.

Kabar baiknya adalah Microsoft telah memutuskan untuk membunuh .net native.

@robloo Saya akan mengadakan pesta untuk merayakannya ketika ini terjadi.

Bahkan jika Uno memiliki desain dan implementasi teknis yang andal dan andal, risiko dan kekhawatirannya adalah bahwa Uno mungkin menghilang dalam beberapa tahun karena masalah $0 yang serupa atau pendapatan yang tidak mencukupi yang pada akhirnya memicu kejenuhan dan pembatalan atau stagnasi proyek. Atau sekadar pengembang Uno yang paling penting suatu hari tiba-tiba mendapatkan hobi/minat/obsesi baru dan kehilangan minat pada Uno, atau pekerjaan/majikan baru dan tidak ada lagi waktu untuk mengerjakan Uno.

@verelpode
Saya berbagi keprihatinan yang sama mungkin lebih dari kebanyakan orang lain. Saya menggunakan lebih sedikit paket sumber terbuka yang tidak didukung oleh perusahaan besar (misalnya Oracle, Google, Microsoft) daripada rata-rata. Saya percaya kedua kondisi berikut harus dipenuhi agar ini terjadi:

1. Nventive menutup usahanya. Nventive mengandalkan Uno untuk bisnis roti dan menteganya.
2. Orang-orang utama di belakang Uno kehilangan minat mereka pada proyek yang luar biasa ini.

Untuk #1, saya telah mendengar Nventive mengembangkan gedung mereka saat ini dan pindah ke fasilitas yang lebih besar, sehingga Uno Conf 2020 yang diperluas (2 hari hingga 3 hari) akan diadakan di gedung yang berbeda. Saya bukan seorang ekonom, jadi saya tidak dapat memprediksi apakah akan ada resesi parah yang membuat banyak perusahaan gulung tikar. Setidaknya saya tidak melihat krisis ekonomi dalam waktu dekat sekarang (tingkat pengangguran di daerah kami telah di bawah 2% untuk sementara waktu).

Adapun #2, saya jarang melihat jenis gairah yang dimiliki orang-orang Uno utama untuk proyek mereka. Ini hampir seperti tujuan mulia, bukan produk perangkat lunak belaka bagi mereka. Yah, hanya orang bodoh yang tidak berubah pikiran, jadi saya tidak akan mengatakan kemungkinan mereka kehilangan minat adalah nol, tetapi mungkin tidak jauh dari nol. Sejujurnya, inilah alasan utama saya untuk menikmati dan tetap berpegang pada Uno saat ini. Sama seperti platform lainnya, Uno memiliki banyak masalah (BTW, melewatkan beberapa fitur yang bagus tidak menjadi masalah bagi saya.), tetapi mereka mengatasi masalah kritis dengan cepat. Saya pikir mereka memiliki setengah lusin atau lebih rilis setiap hari. Salah satu aplikasi saya tidak dapat dipublikasikan karena bug yang diketahui dari suatu platform, dan secara harfiah membutuhkan waktu lebih dari setengah tahun bagi perusahaan besar (😉) untuk memperbaikinya (saya telah mengarsipkan tiketnya).

Berdasarkan pengalaman luas saya dengan Sliverlight, SDK Windows Phone 7/7.1/8/8.1, Windows 8/8.1/10 (WinRT, UWP…) (Ponsel utama saya adalah Windows Phone, platform seluler terbaik dalam sejarah manusia, hingga menit terakhir sebelum saya tidak punya pilihan selain beralih ke Android tahun ini), saya lebih percaya pada umur panjang Platform Uno daripada hal serupa dari Microsoft. Ya, Uno didasarkan pada semua teknologi Microsoft, tetapi mereka menangani migrasi ketika Microsoft mengubah banyak hal.

Saya bertanya-tanya apakah alasan Miguel mendukung Uno dan menyampaikan keynote di Uno Conf adalah karena dia melihat Uno seperti bayinya Mono di masa-masa awal, dan Nventive seperti Ximian-nya.

Saya memang mempersiapkan skenario terburuk – kematian Uno. Karena semua proyek Uno menggunakan dua teknologi favorit saya – C# dan Xaml, saya dapat memigrasikannya ke platform yang muncul berdasarkan mereka dengan mudah. Setidaknya saya dapat mengatakan bahwa kode C# menua dengan sangat baik. Sebagian besar kode di perpustakaan utilitas inti saya yang dibagikan oleh semua proyek berusia lebih dari satu dekade. Mereka masih bekerja dengan sempurna, dan saya menduga mereka akan melakukannya dalam beberapa dekade mendatang.

@stevenbrix @weitzhandler @Pinox

Diskusi yang menarik, juga memperhatikan Blazor Native disebutkan di sini juga.

Sudah ada conf NDC baru dari Steve dengan Blazor yang mungkin menarik untuk disimak, video di atas menggunakan Blazor + Native menggunakan Flutter sebagai renderer. Namun dalam video NDC Conf baru, Steve sekarang menggunakan Xamarin.Forms untuk merender UI seluler dengan markup mirip XAML. Saya dapat melihat Blazor Native sebagai solusi x-platform paling praktis yang dapat bekerja saat ini dengan WinUI karena akan mendukung React Native dalam nada yang sama seperti yang saya lihat mendukung Blazor Native seperti itu. Jadi .Net sekarang dapat menargetkan (Web, Mobile, Win Desktop).

MEMPERBARUI:
Versi baru MS Teams dirilis baru-baru ini, dan ini meningkatkan waktu yang dibutuhkan untuk melihat pesan obrolan terbaru. Dalam pesan sebelumnya, saya menyebutkan bahwa butuh sekitar 27 detik, tetapi untungnya versi baru lebih cepat dalam menampilkan pesan obrolan terbaru.

Terima kasih kepada anggota staf Microsoft yang bekerja untuk peningkatan ini. :senyum:

Perspektif saya:

Microsoft: Dapat mengembangkan Webview2 minimum (Mirip dengan Carlo) yang dapat menonaktifkan hampir semua fitur dan mengurangi hanya pengikatan acara ke HTML UI...mungkin semua fitur lainnya berkembang di C#/asli/di luar cakupan komunitas (Sebagai lintas platform Pustaka backend asli).
Saya tahu betapa rumitnya sisi HTML/CSS tetapi saya ingin memanfaatkan pengetahuan UI itu dan ikatan satu lawan satu pada kode C# di belakang kode acara dll.

Microsoft: Dapat mematikan satu ram 8/32gb dari mereka yang memiliki 4x 8gb/4x 32gb...Menghemat banyak energi.

Untuk melakukan ini, kami menyingkirkan selusin aplikasi yang dikembangkan dengan Electron...yang bergantung pada tujuan Microsoft dan Bill Gates.

Meskipun tujuan terbaik adalah untuk semua orang mulai mengembangkan aplikasi dan mendapatkan daya tarik dari beberapa Kerangka GUI standar CSS3...mungkin seperti QT/GTK... tapi sayang sekali GTK bukan non copyleft, dan mungkin seperti QML dengan kesetaraan .net.

MEMPERBARUI:
Batalkan apa yang saya katakan di pesan saya sebelumnya tentang masalah yang diperbaiki ️ Ini tidak diperbaiki. Ini aneh: Selama beberapa minggu, sepertinya masalahnya hilang, tetapi masalahnya kembali baru-baru ini! MS Teams sekali lagi memberi saya kesulitan dan penundaan ketika hanya mencoba melihat pesan obrolan terbaru.

Bugginess dari MS Teams tidak mengejutkan ketika Anda menganggap bahwa itu ditulis dalam JavaScript. _Tentu saja_ aplikasi yang ditulis dalam JavaScript bermasalah -- mengapa ada yang mengharapkan sebaliknya? MS Teams menggunakan ElectronJS yang menggunakan JavaScript meskipun faktanya diketahui bahwa JavaScript tidak pernah dimaksudkan untuk menjadi bahasa pemrograman yang sebenarnya, melainkan hanya add-on skrip biasa untuk browser web.

JavaScript bahkan tidak menyertakan pemeriksaan tipe waktu kompilasi -- begitulah buruknya. Oleh karena itu perlunya TypeScript untuk mencoba memperbaiki masalah _major_ ini dalam JavaScript. Sebenarnya, ini adalah masalah yang sangat buruk jika Anda menganggap JavaScript sebagai bahasa pemrograman -- JavaScript buruk sebagai bahasa pemrograman -- tetapi seperti yang saya katakan, itu dimaksudkan untuk menjadi bahasa skrip biasa, bukan bahasa pemrograman, oleh karena itu Anda dapat maafkan JavaScript karena gagal menyertakan esensi bahasa pemrograman, karena aplikasi pemrograman bukanlah tujuan JavaScript.

Apa yang tidak dapat dimaafkan adalah keputusan yang tidak dapat dipahami untuk menggunakan bahasa skrip biasa seolah-olah itu adalah bahasa pemrograman. Saya sangat terkejut melihat bahwa Microsoft memilih bahasa non-profesional untuk aplikasi yang sama pentingnya dengan Teams. Saya tidak berpikir mungkin bagi siapa pun untuk mengatakan nama "JavaScript" sambil secara bersamaan lupa bahwa "JavaScript" memiliki "Script" dalam namanya karena memang bahasa scripting bukan bahasa pemrograman. Entah bagaimana keberadaan kata "Script" di "JavaScript" baru saja benar-benar tercampur.

Anggota tim WinUI telah bekerja keras untuk banyak perbaikan pada WinUI. Keputusan Microsoft untuk menggunakan bahasa skrip kasual alih-alih WinUI tidak masuk akal.

Ada banyak aplikasi web JavaScript yang ditulis dengan sangat baik dan berkinerja tinggi. Tentu Anda bisa mendapatkan kinerja yang lebih baik dengan teknologi lain. Tetapi alasan mengapa Teams lambat untuk Anda tentu saja bukan karena didasarkan pada JavaScript. Itu disebabkan oleh beberapa implementasi yang buruk di sisi server atau sisi klien (mungkin masalah async/threading). Pasti akan mungkin untuk menulis Teams dalam JavaScript dengan kinerja yang jauh lebih baik.

Jangan salah paham, saya sama sekali bukan penggemar JavaScript. Bahkan menurut saya itu adalah bahasa yang mengerikan. Hanya mengatakan bahwa masalah yang Anda lihat tidak disebabkan oleh fakta bahwa Teams menggunakan teknologi JavaScript. Bahkan dimungkinkan untuk menjalankan mesin Unreal dalam JavaScript dengan kinerja yang baik (bukan yang terbaik).

WinUI adalah kerangka kerja desktop Windows saja. Jadi tidak mungkin untuk mengembangkan aplikasi x-platform Teams berdasarkan itu, dan bahkan hari ini tidak mungkin. Tapi mungkin masalah dengan Teams akan membantu Microsoft mempertimbangkan untuk membuat WinUI lintas platform. Dengan x-platform WinUI dan .NET Core yang sebenarnya, akan jauh lebih mudah untuk mengembangkan aplikasi responsif yang dapat diskalakan dengan baik.

WinUI adalah kerangka kerja desktop Windows saja. Jadi tidak mungkin untuk mengembangkan aplikasi x-platform Teams berdasarkan itu, dan bahkan hari ini tidak mungkin. Tapi mungkin masalah dengan Teams akan membantu Microsoft mempertimbangkan untuk membuat WinUI lintas platform. Dengan x-platform WinUI dan .NET Core yang sebenarnya, akan jauh lebih mudah untuk mengembangkan aplikasi responsif yang dapat diskalakan dengan baik.

Menggunakan Uno, WinUI adalah lintas platform. Lihat Kalkulator UNO di Google Play store. Ini adalah versi porting dari kalkulator Windows 10.

Seseorang meminta perbandingan UWP vs Elektron, ini ada beberapa:

https://twitter.com/emiliano84/status/1198177284533956608

https://twitter.com/emiliano84/status/1198179206548602881

aplikasi XBOX baru itu konyol, dapat dengan mudah menghabiskan 1,5 GB RAM tanpa biaya

alangkah baiknya jika seseorang dapat membuat video untuk menunjukkan betapa lambatnya mereka dibandingkan dengan UWP

Saya pikir sebagian besar peserta diskusi tentang WinUI & X-platform ini telah membaca tentang cerita ini, tetapi untuk berjaga-jaga jika ada yang melewatkannya, inilah WinUI di Windows 7 – Ya, itu mungkin dengan Uno Platform . Setelah aplikasi didasarkan pada Uno, itu menargetkan Windows, Web, iOS, dan Android.

@lukasf

Pasti akan mungkin untuk menulis Teams dalam JavaScript dengan kinerja yang jauh lebih baik.

Ya itu _mungkin_, dan juga _mungkin_ untuk menulis Tim MS di PowerShell dengan kinerja yang dapat diterima (saya suka PowerShell), dan juga _mungkin_ bagi SpaceX untuk pindah ke Rusia dan masih berhasil meluncurkan satelit, tetapi itu masih merupakan manajemen yang tidak kompeten keputusan untuk memindahkan SpaceX ke Rusia, atau untuk menulis aplikasi MS Teams dalam bahasa skrip seperti PowerShell atau JavaScript. Jika SpaceX pindah ke Rusia, maka SpaceX masih bisa beroperasi, itu mungkin, tapi jujur ​​kita harus mengatakan bahwa Elon Musk tidak akan benar-benar menjadi manajer yang efektif dan tidak akan benar-benar tahu apa yang dia lakukan.

Saya tidak 100% yakin bahwa Electron yang harus disalahkan. Visual Studio Code dikatakan didasarkan pada Electron juga, tetapi kinerjanya cukup solid. Aplikasi elektron pada dasarnya adalah aplikasi web, dan ada ribuan alasan di balik aplikasi web yang berkinerja buruk.

Tidak banyak yang bisa dilakukan WinUI untuk "memenangkan Teams over". Bukan teknologinya, tapi produknya. Tim seperti perusahaan rintisan yang menempatkan dirinya di jalur pertumbuhan yang cepat. Itu perlu berjalan di banyak platform dengan paritas fitur, dan mereka harus mencapai ini secepat mungkin. Ini adalah satu-satunya alasan untuk memilih teknologi berbasis web. Di ponsel mereka dapat menggunakan React Native karena itu satu-satunya cara untuk memasuki perangkat keras dengan JavaScript, tetapi di Desktop, mereka perlu mempertahankan paritas fitur dan pemeliharaan kode dengan aplikasi web, mac, dan versi Linux. Mereka harus menggunakan kerangka kerja yang menargetkan win32 karena mereka tidak sabar menunggu model aplikasi UWP menambahkan fitur yang dibutuhkannya. Mampu melakukan berbagi desktop dengan opsi untuk memilih desktop mana atau aplikasi spesifik mana yang akan dibagikan adalah salah satu fitur utamanya. Ini adalah bagaimana produk seperti startup dikembangkan. Slack menggunakan jquery untuk meretas pertumbuhan ketika mereka pertama kali memulai dan berakhir dengan kode yang sangat buruk, tetapi begitu mereka memiliki waktu untuk melakukan refactor, mereka dengan cepat menulis ulang semuanya dengan reaksi, dan Slack sekarang jauh lebih cepat dari sebelumnya. WinUI dan Electron tidak berada dalam kategori yang sama, dan karena itu tidak akan menggantikan Electron untuk aplikasi yang benar-benar membutuhkannya, apa pun fitur yang ditambahkannya.