Aspnetcore: Pisahkan Pengalaman .NET Core ke WASM dari Blazor

Hai @EisenbergEffect! Pekerjaan inti WebAssembly sebenarnya sedang ditangani oleh tim Mono. Kami sedang membangun Blazor di atas apa yang mereka sediakan. Orang lain di komunitas .NET juga bebas melakukannya dan beberapa sudah ( Ooui , Uno , cshtml5 ). Anda dapat mengikuti perkembangan mono.wasm di repo Mono .

Saya sangat tidak tertarik untuk mengkompilasi Mono ke WebAssembly. Saya hanya tertarik pada .NET Core. Yang saya minta adalah sesuatu seperti ini:

• Gunakan .NET CLI untuk membuat proyek .NET Core C#.
• Gunakan .NET CLI untuk mengkompilasi proyek .NET Core saya ke WASM, dengan 3 output yang dijelaskan di atas.

@ danroth27 Apakah itu didukung hari ini?

Orang-orang Mono juga sedang mengerjakan kompilasi penuh sebelumnya (AoT) kode .NET ke WebAssembly bersama dengan MSBuild SDK yang mendukung. Pembaruan terakhir yang mereka publikasikan tentang upaya tersebut adalah http://www.mono-project.com/news/2018/01/16/mono-static-webassembly-compilation/. @mhutch mungkin adalah kontak terbaik untuk mendapatkan status terbaru.

Saya tidak tertarik pada Mono. Saya tertarik pada .NET Core saja. Apakah ada cerita untuk .NET Core WASM?

Apakah ada cerita untuk .NET Core WASM?

Tidak saat ini. .NET Core terutama digunakan saat ini untuk skenario server lintas platform. Mono adalah runtime .NET yang digunakan saat ini untuk skenario klien lintas platform (Android, iOS, macOS, game). Sebagian besar skenario WebAssembly saat ini adalah skenario klien, jadi Mono adalah cara termurah untuk maju saat ini. Seiring waktu, masuk akal untuk mengharapkan akan ada konvergensi, tetapi itu akan memakan waktu.

FWIW Saya benar-benar berpikir masalah runtime dan target platform ini perlu ditangani terlebih dahulu. Ketika saya mendengar bahwa saya harus menggunakan dua rasa yang berbeda dari .NET untuk membangun sebuah aplikasi...menggunakan Mono untuk klien Anda dan kemudian menggunakan .NET Core untuk server Anda...itu tidak membuat saya bersemangat sama sekali. Saya hanya ingin menggunakan .NET Core, dan terus terang, saya lupa bahwa ada .NET lainnya. Tolong satu .NET :)

@EisenbergEffect dari perspektif konsumsi itu harus cukup banyak detail implementasi yang runtime menjalankan kode Anda.

saya tidak setuju. Tidak pernah dalam sejarah saya sebagai seorang insinyur perangkat lunak, saya mempertimbangkan run-time mana yang menjalankan kode saya sebagai detail implementasi yang dapat saya abaikan.

@ danroth27 Hanya beberapa umpan balik dari tim pengembangan saya, kami juga ingin melihat Blazor menggunakan .NET Core pada akhirnya. Kami tidak tertarik pada Mono atau bahkan kerangka .NET lengkap. Kami menginginkan runtime yang sama pada klien dan server.

Kami tidak tertarik pada Mono atau bahkan kerangka .NET lengkap. Kami menginginkan runtime yang sama pada klien dan server.

Yah, apa pun yang kami lakukan, Anda tidak akan memiliki runtime yang persis sama di server dan di browser: runtime browser harus berbasis WebAssembly, tetapi server tidak. Ini tidak berbeda dengan bagaimana berjalan di iOS pada dasarnya berbeda dengan berjalan di server. Faktor pemersatu pada klien dan server adalah .NET Standard. Yang mengatakan, saya pikir kami berbagi tujuan Anda ingin bersatu pada implementasi runtime tunggal. Tidak masuk akal bagi Microsoft dalam jangka panjang untuk memiliki dan memelihara dua runtime dengan harga dua kali lipat. Pekerjaan konvergensi sudah terjadi dalam banyak hal. Semakin banyak kode di Mono dan .NET Core yang dibagikan. Tetapi mencapai satu runtime masih merupakan upaya besar yang akan memakan waktu.

Sementara itu Blazor adalah sebuah eksperimen dan kami sedang bereksperimen dengan apa yang dapat dibuat untuk bekerja hari ini

@ danroth27 Terima kasih atas tanggapannya yang luar biasa, Dan!

Luar biasa setuju sekali

Pada Selasa, 15 Mei 2018, 10:54 paulost [email protected] menulis:

@danroth27 https://github.com/danroth27 Terima kasih untuk yang luar biasa
respon, Dan!

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/aspnet/Blazor/issues/835#issuecomment-389046589 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/ACnwPz_cCiVg6iti9VR9pQWY34_Hibf4ks5tymapgaJpZM4T-jpA
.

@EisenbergEffect Saya memiliki pandangan yang sama tentang Mono, namun ketika saya mengetahui bahwa sejak Microsoft mengakuisisi Xamarine, Mono adalah teknologi Microsoft... Dan dioptimalkan untuk skenario klien... Dan saya dapat menggunakannya untuk menjalankan kode ".net standard" saya di dalamnya browser hari ini... Semua kekhawatiran disingkirkan.

Untuk mengambil komponen runtime browser saja:
https://jenkins.mono-project.com/job/test-mono-mainline-wasm/label=ubuntu-1804-AMD64/

... Sekarang saya kembali membangun tumpukan UI berbasis XAML saya di C# yang menargetkan WebGL

Untuk lebih jelasnya, ini bukan tentang menggunakan teknologi non-Microsoft. Ini tentang keinginan untuk hanya menggunakan .NET Core. Saya mencari satu, open source, cross-platform .NET dengan CLI lintas-plat terpadu. Bukan dua atau tiga .NET atau beberapa kompiler. Saya akan berpikir bahwa upaya baru akan difokuskan di sekitar .NET Core dan unifikasi, jadi saya terkejut bahwa WASM hanya untuk Mono dan memerlukan toolchain yang berbeda.

Saya pribadi telah meminta penyatuan dalam platform .NET selama lebih dari 10 tahun. Jadi, maafkan saya jika saya sedikit gelisah di thread ini, karena setelah 10 tahun saya masih membutuhkan 3 .NET untuk membangun layanan dan klien saya. Ada sangat sedikit hal yang saya bersedia untuk menunggu 10 tahun. Saya meninggalkan .NET beberapa tahun yang lalu dan sejak Desember telah melihat kembali ke dalamnya untuk melihat apakah situasinya telah membaik. Saya lebih dari sedikit berkecil hati untuk menemukan banyak masalah yang sama yang saya tinggalkan, masih tersisa.

Maksud saya ini dengan segala ketulusan, saya ingin mencintai .NET lagi. Tolong, anggap ini serius.

Maksud saya ini dengan segala ketulusan, saya ingin mencintai .NET lagi. Tolong, anggap ini serius.

Kami menangani masalah ini dengan serius dan kami secara aktif bekerja pada konvergensi berbagai runtime .NET. Tetapi itu akan memakan waktu, dan kami mungkin memutuskan bahwa dalam jangka pendek karena pertimbangan praktis, masuk akal untuk melanjutkan Mono dengan peta jalan yang lebih panjang untuk konvergensi dengan .NET Core.

Saya masih membutuhkan 3 .NET untuk membangun layanan dan klien saya

Saya berasumsi tiga .NET yang Anda maksud adalah .NET Framework, .NET Core dan Mono. Kabar baiknya adalah kami mengumumkan di BUILD bahwa .NET Core 3 akan memiliki dukungan untuk aplikasi desktop Windows, jadi semoga itu akan mengurangi kebutuhan akan salah satu runtime tersebut dan memberikan bukti lebih lanjut bahwa konvergensi adalah tujuan bersama kami.

FWIW, Mono telah beralih ke kompiler Roslyn dan sistem build msbuild, jadi itu bukan toolchain yang benar-benar berbeda. Anda dapat membangun proyek berbasis .Net Core dan Mono dalam satu solusi, dengan sistem build dan kompiler yang sama. Mono juga menggunakan bagian besar dan terus meningkat dari classlibs .NET Core.

WASM adalah target yang sangat tidak biasa. Tidak hanya tidak mungkin untuk mengkompilasi JIT, hal-hal seperti threading, file, dan soket memiliki model yang sangat berbeda dengan kebanyakan platform lainnya. Mono memiliki banyak teknologi yang dikembangkan untuk port ke platform lain yang tidak biasa/terkendala seperti iOS, watchOS, PS4, dll yang membantu dengan port WASM, seperti penerjemah IL, penangguhan GC kooperatif, AOT Penuh (sangat sulit untuk obat generik) dengan berbagi obat generik , backend bitcode LLVM, dan penautan terkelola.

Saya sepenuhnya mengharapkan jenis proyek WASM Mono untuk menggunakan proyek bergaya SDK, dengan MSBuild SDK yang dikirimkan melalui NuGet, dan dapat digunakan dari dotnet .

Saya pikir saya mencium bau kebencian Mono di sini, bukan?
Tolong jangan terlalu cepat ingin membuang Mono. Ingat ketika Microsoft tidak menyukai Linux? Mono ada di sana untuk C# devs. Ingat ketika Microsoft tidak menyukai Mac OS? Mono ada di sana lagi. Sekarang JavaScript memakan makan siang kita, tebak siapa yang muncul? Anda bertaruh, Mono ada di sini untuk menyelamatkan hari, menjadi .net lengkap pertama yang dijalankan di Wasm. Tolong tunjukkan rasa hormat!

Dengar, kami C# devs di sisi ini menyukai Mono. Mereka melakukan pekerjaan yang fantastis. Tinggalkan Mono sendiri. Jika anak keren .Net Core ingin berpesta, tidak apa-apa juga, TAPI MONO TINGGAL!

@humbersoft Jika Anda menginginkan alasan mengapa kami "membenci" Mono, saya akan memberi Anda satu. Ini melihat kesalahan seperti ini di konsol browser Anda: "WASM: Seharusnya sudah diinstal di `/Users/builder/jenkins/workspace/test-mono-mainline-webassembly/label/highsierra/sdks/out/wasm-interp/ lib/mono/4.5/mscorlib.dll' direktori." Siapa itu jenkins? Sungguh pesan yang aneh! Seorang pengembang Mono jelas-jelas mengkodekan jalur pribadinya di runtime.

@paulost Jenkins adalah layanan pembangunan berkelanjutan. Mencari itu. Ini sangat populer.

Terima kasih @MisinformedDNA tetapi mengapa Mono memberi tahu saya bahwa itu harus dipasang di jalur yang tepat di sistem saya? Saya tidak mencoba membangun Mono tetapi hanya menggunakannya untuk menjalankan aplikasi blazer. Runtime yang dikirimkan seharusnya tidak memberi tahu Anda tentang jalur layanan build-nya.

Saya tidak memiliki konteks lengkap kesalahan, tetapi saya dapat menjamin Anda akan melihat info debug tambahan karena Blazor bukan produk yang dikirim. Mono mungkin dikirimkan, tetapi kami mungkin juga menggunakan versi pratinjau Mono atau pustaka pratinjau yang dibuat di atas Mono. Ingat, kita masih dalam tahap percobaan.

Akhirnya, Xamarin berjalan di Mono, yang mungkin menjalankan ribuan aplikasi seluler. Ini adalah teknologi yang dilakukan dengan baik. Apakah lebih baik memiliki satu runtime? Tentu saja. Tetapi .NET Framework hanya untuk Windows dan Mono kemudian dibuat sebagai port untuk kompatibilitas dengan Linux dan .NET Core kemudian dibuat untuk skalabilitas yang lebih baik di cloud. Apakah Anda benar-benar berpikir MS lebih suka mengelola tiga runtime terpisah? Tentu saja tidak. Tetapi tidak setiap bahasa memiliki skala atau ambisi .NET. Juga, jika Anda melewatkannya, MS mem-porting WPF, WinForms dan UWP ke .NET Core 3.0 . .NET Core adalah masa depan, tetapi itu akan memakan waktu.

Ya, dukungan mono webassembly dalam pratinjau dan belum dikirimkan dalam rilis apa pun.

Dalam kasus khusus ini, runtime mencoba menentukan direktori rakitan runtime (yang berisi file seperti mscorlib.dll) berdasarkan lokasi sistem file saat ini, dan fallback terakhir adalah jalur di mana runtime dikompilasi. Pada saat itu, konsep "lokasi sistem file" tidak benar-benar berlaku... Pada penyiapan tersemat serupa lainnya, kode penyematan biasanya mendaftarkan penyelesai rakitan khusus (mis. untuk menyelesaikan dari zip APK Android), dan saya rasa itu belum telah diatur di sini belum.

@PaulOst
Itulah masalahnya dengan hidup di tepi pendarahan, Anda kemungkinan akan terluka. Mono untuk WASM masih dalam tahap awal dan sangat eksperimental, tetapi lebih lengkap daripada DotNet Anywhere yang awalnya menjadi basis Blazor. Ini belum dipoles dengan pasti, jadi kesalahan seperti yang Anda alami sudah bisa diduga.

Beberapa pengembang menyukai bit panas, beberapa lebih suka menunggu sampai semuanya dingin dan tenang. Ini adalah bit panas, mungkin Anda perlu menyesuaikan harapan Anda sedikit. Saya mengerti perspektif, Anda menginginkan produk yang dipoles. Bisakah Anda bayangkan menunggu .NET Core untuk menargetkan Wasm? Mereka mungkin tidak bisa melakukannya sampai 3 tahun. Mono adalah produk yang solid dan merupakan hal yang beruntung bahwa Microsoft memilikinya, jika tidak, kami tidak akan memiliki cerita .NET untuk WASM dan begitu banyak platform lainnya.

Hal lain, saya sampaikan kepada Anda bahwa sebagian besar pengembang lebih menyukai Microsoft baru yang mengembangkan teknologi penting seperti ini di tempat terbuka. Kami akan berakhir dengan produk yang lebih baik pada akhirnya.

Dengan semua itu, Blazor mungkin bahkan tidak melihat cahaya hari karena berbagai alasan bagus. Rencanakan juga.

Saya melanjutkan dan mulai membangun mesin Xaml yang berjalan secara native di browser. Anda dapat memeriksanya di sini: https://github.com/XamlEngine/Samples

Bergabung dengan diskusi ini agak terlambat, tetapi terkejut bahwa begitu banyak orang yang peduli bagaimana kode standar .NET mereka berjalan. Tempelkan label apa pun yang Anda inginkan ke runtime - Mono, .NET Core, FlubberGast - apa pun runtime yang sebenarnya akan berbeda. Tidak mungkin .NET Core di server akan sama dengan .NET Core di WASM atau dikompilasi dengan WASM. Jadi siapa sih yang benar-benar peduli?

Yang penting adalah bagaimana karet memenuhi jalan atau betapa mudahnya mengakses kode runtime itu. Saya setuju dengan @EisenbergEffect bahwa memiliki jalur level bawah yang lebih mudah untuk mendapatkan bootstrap .NET bisa menjadi dorongan besar untuk .NET secara umum.

Mengapa tidak menjadikan ini sebagai dorongan serius selain apa yang dilakukan Blazor karena ini pasti akan mendorong inovasi dalam berbagai cara menggunakan .NET di browser. Ini hanya bisa menjadi nilai tambah yang besar untuk visibilitas NET jika banyak proyek baru muncul yang menggunakan .NET dengan cara baru dan inovatif di browser. Saya yakin Rob bertanya karena dia memiliki beberapa ide tentang bagaimana membangun semacam kerangka kerja baru :-)

Ini dapat dilakukan hari ini dengan modul Mono.wasm saat ini dan di masa depan dengan .NET Core atau setidaknya kompiler Mono AOT, tetapi saya pikir membangun antarmuka hosting standar yang dapat memfasilitasi .NET bootstrap ke dalam browser akan sangat membantu tujuan ini. Runtime yang sebenarnya kemudian dapat dicolokkan dan ditukar ketika teknologi dan sumber daya yang diperbarui tersedia.

Ini sepertinya merupakan peluang besar bagi .NET untuk menjadi pengguna awal di ruang Majelis Web. Apa yang saya lihat dengan Blazor terlihat sangat menjanjikan, tetapi saya pikir itu tidak cukup progresif jika itu satu-satunya titik paparan WASM resmi dari .NET. Saya sangat menyukai model Blazor dan apa yang memungkinkannya, tetapi saya pikir itu hanya puncak gunung es dari apa yang mungkin terjadi jika sistem ramah lingkungan untuk menjalankan .NET sesederhana membuat aplikasi .NET standar. Saya tidak perlu berbicara tentang kerangka kerja UI di sini - tetapi bahkan hanya dapat mem-bootstrap dan memanggil kelas .NET yang longgar baik sebagai titik masuk dan pemrosesan seperti Pekerja Web, atau bahkan sebagai sarana untuk interop dari aplikasi JavaScript yang ada. Bahkan untuk itu manfaat berbagi beberapa kode bisnis/validasi bisa sangat berharga.

Banyak potensi - akan keren untuk mengaktifkannya sebanyak mungkin dengan membuatnya mudah untuk menggunakan teknologi ini, bahkan bit level yang lebih rendah!

@RickStrahl Ini mungkin tidak terlihat progresif karena mereka masih dalam tahap percobaan, tetapi mereka memiliki banyak ide yang sedang mereka kerjakan termasuk rendering server, aplikasi desktop/seluler, pekerja web, dll. Ini akan memberi Anda ide yang lebih baik tentang apa mereka sedang mempertimbangkan.

Oh, saya tidak berpikir bahwa Blazor tidak progresif - saya mengklarifikasi dalam pesan saya di atas. Bahkan hanya bermain-main dengan ini, saya benar-benar dapat mengatakan bahwa ini akan menjadi cara yang bagus untuk membangun aplikasi. Ada begitu banyak momen kecil di mana Anda baru saja pergi - ini akan sangat merepotkan dalam Javascript/TypeScript.

Maksud saya terutama adalah saya pikir mereka juga harus menambahkan fungsionalitas .NET mentah di samping hal-hal Blazor. Infrastruktur ini harus dibangun untuk mendukung Blazor, jadi mengapa tidak mengeksposnya dengan cara yang lebih ramah pengguna sehingga mudah untuk menjatuhkan .NET 'hosting' ke dalam aplikasi klien.

Saya tidak yakin saya mengerti, Blazor memungkinkan kami menggunakan sebagian besar fungsionalitas .NET, fungsionalitas khusus apa yang menurut Anda hilang?

Saya harus menggunakan Blazor. Bagaimana jika saya memiliki aplikasi HTML yang sudah ada, atau membangun sesuatu dengan kerangka kerja lain dan tidak membutuhkan Blazor? Masih ada kasus penggunaan yang bagus untuk menyediakan akses ke kode .NET di browser di luar kerangka kerja HTML (berbagi kode validasi, utilitas, dll., dll.).

Saya harus menggunakan Blazor. Bagaimana jika saya memiliki aplikasi HTML yang sudah ada, atau membangun sesuatu dengan kerangka kerja lain dan tidak membutuhkan Blazor? Masih ada kasus penggunaan yang bagus untuk menyediakan akses ke kode .NET di browser di luar kerangka kerja HTML (berbagi kode validasi, utilitas, dll., dll.).

Saya tidak mengerti. Blazor pada dasarnya adalah:

1. Sintaks pisau cukur untuk komponen web,
2. berbagai pembantu interop JS,
3. WebAssembly berbasis mono .NET

Anda mungkin menginginkan yang kedua dan ketiga, dan yang pertama tidak merugikan Anda.

Maksud saya terutama bahwa saya pikir mereka juga harus menambahkan fungsionalitas .NET mentah di samping hal-hal Blazor. Infrastruktur ini harus dibangun untuk mendukung Blazor, jadi mengapa tidak mengeksposnya dengan cara yang lebih ramah pengguna sehingga mudah untuk menjatuhkan .NET 'hosting' ke dalam aplikasi klien.

Itu tentu maksud dari usaha mono.wasm seperti yang saya pahami. Kami sering menyebut Blazor dan mono.wasm dalam satu nafas, tetapi pada kenyataannya Blazor hanyalah sebuah kerangka web. Ini adalah mono.wasm yang menyediakan runtime .NET berbasis WebAssembly yang mendasarinya. Kerangka kerja lain bebas untuk dibangun di atas runtime yang sama, dan kerangka kerja alternatif sudah ada ( Ooui , Uno ). @kumpera @mhutch mungkin adalah orang yang tepat di tim Xamarin untuk berbicara dengan pengalaman dev yang mereka harapkan dapat diaktifkan menggunakan mono.wasm terlepas dari kerangka UI tertentu.

File zip menyediakan, hari ini, dukungan yang sangat mentah untuk menulis aplikasi C# tanpa Blazor. Ini cukup baik untuk memvalidasi teknologi tetapi membutuhkan banyak pekerjaan manual.

Ini adalah tujuan kami untuk memberikan apa yang disarankan oleh deskripsi masalah ini, rantai alat lengkap termasuk binding yang kaya dan debugging.

File zip yang mana?

@EisenbergEffect yang harus Anda pedulikan adalah .NET Standard, bukan .NET Core.
Pastikan API dependen Anda bergantung pada .NET Standard dan Anda baik-baik saja.

@weitzhandler Saya pikir Anda mungkin kehilangan poin saya. Jika saya ingin membangun sesuatu dengan .NET, saya harus menginstal beberapa perangkat konkret, bukan? Saya mulai bekerja dengan .NET lebih dari 15 tahun yang lalu, jadi saya pribadi tidak menemukan hal ini menakutkan atau membingungkan (walaupun saya lebih memilih untuk tidak memasang alat kuasi-duplikat di mesin saya). Tapi, bayangkan seseorang yang tidak memiliki pengalaman dengan .NET dan pengguna Mac. Mereka memutuskan ingin membangun aplikasi .NET, baik front-end maupun back-end. Mereka mendengar bahwa .NET Core adalah yang terbaru, hal yang manis, jadi mereka bersusah payah untuk menginstal .NET CLI dan VS Code. Kemudian, mereka mengetahui bahwa mereka tidak dapat membangun front-end mereka dengan itu. Mereka perlu mendapatkan seperangkat alat yang berbeda (dengan nama yang berbeda, dari tempat yang berbeda, dengan kepemimpinan yang berbeda, dll.). Sekali lagi, bayangkan mereka tidak memiliki riwayat sebelumnya dengan .NET. Ini bukan pengalaman pertama yang baik. Ok, sekarang bayangkan bahwa orang ini adalah seorang Arsitek atau CTO yang mencoba memberikan penilaian baru tentang .NET baik untuk pertama kalinya atau setelah beberapa tahun. Mungkin mereka sedang menentukan arah untuk perusahaan mereka. Apakah ini pengalaman yang Anda inginkan dari orang itu atau penasihat teknisnya? Mereka akan membandingkannya dengan Go, Node, Rust, dll.

Mengenai perasaan pribadi saya, toleransi saya cukup rendah setelah bertahun-tahun dan begitu banyak versi .NET. Saya mencoba membantu orang-orang seperti @danroth27 memahami sedikit tentang apa yang harus terjadi agar orang-orang seperti saya tertarik pada .NET lagi. Ada lebih banyak dari ini, tetapi memiliki sedikit lebih banyak penyatuan pasti akan membantu. Saya hanya ingin menginstal satu CLI dan VS Code. Proses membangun dan menjalankan aplikasi .NET full-stack pada platform non-Windows seharusnya tidak lebih rumit dari itu.

Posting asli saya dimaksudkan untuk melukiskan gambaran sederhana tentang seperti apa "bintang utara" WASM dari pengalaman dev dan membangun perspektif output. Saya menginstal CLI, saya menulis beberapa kode C # (dengan editor apa pun yang saya inginkan) dan kemudian saya menjalankan perintah CLI untuk membangun kode C # saya ke WASM, menghasilkan satu set file output yang masuk akal (wasm, binding, tipe). Itu harus menjadi tujuannya. Jika tidak ada hari ini, itu bisa dimengerti. Namun, mari kita pastikan bahwa kita berlayar dengan kapal .NET ke arah yang benar, menuju pengalaman terbaik, tidak puas dengan apa yang termudah atau tercepat bagi para insinyur Microsoft.

@EisenbergEffect
Rob, saya setuju tujuan akhirnya adalah menjalankan .NET Core di mana-mana bahkan mengganti Mono dengannya.
Saya bahkan menginginkan " .NET UI Standard " yang membuat di mana-mana sama untuk disertakan dengan .NET Core, tetapi .NET Core relatif baru. .NET Standard adalah solusi terbaik untuk mendapatkan bentuk divergensi ini, dan saat ini sepertinya Anda tidak dapat meminta sesuatu yang lebih baik.

Suara saya adalah untuk mengganti Mono dengan .NET Core untuk poin yang sama yang dibuat

@EisenbergEffect Saya memimpikan micro caliburn untuk web, apakah ini yang Anda pikirkan? Saya sebenarnya mulai mengerjakan penerus spiritual dengan knockout dan Duocode (port JavaScript mscorlib) beberapa waktu lalu sebelum webassembly menjadi sesuatu.

@AndersMalmgren Aurelia sangat mirip dengan Caliburn.Micro untuk web hari ini. Versi vNext yang sedang kami kerjakan untuk rilis tahun ini bahkan mendukung perender alternatif sehingga tidak hanya dapat dirender ke HTML tetapi juga aplikasi desktop, 3d, dan konsol asli. Itu ditulis dalam TypeScript, bukan .NET. Dimungkinkan untuk mem-port Aurelia ke .NET Core di beberapa titik di masa mendatang, setelah teknologi ini sedikit lebih matang.

Yang mengatakan, karena Microsoft sedang membangun Blazor, saya cenderung tidak secara pribadi membangun apa pun untuk .NET WASM karena itu akan membuat saya bersaing dengan Microsoft. Dari sejarah, kita tahu bahwa tidak ada sumber terbuka di dalam ekosistem .NET yang berarti apa pun ketika Microsoft telah memutuskan untuk membangun sesuatu yang serupa, terlepas dari apakah sumber terbuka itu dirancang lebih baik, lebih dapat diperluas, lebih berkinerja, dll. Saya akui cantik letih di sini. Satu-satunya hal yang mungkin mengubah ini adalah jika Microsoft mempekerjakan saya untuk memimpin kerangka dan ekosistem front-end berbasis .NET Core. Itu bukan Blazor. Blazor tidak dirancang dengan benar (itu mengulangi .NET pola anit dari 10 tahun yang lalu), juga tidak cukup ambisius, cukup sesuai standar, atau cukup melihat ke depan, menurut pendapat saya. Ini adalah peluang yang lebih besar yang dipertaruhkan untuk Microsoft, tetapi jendelanya akan ditutup. Saya telah mencoba meyakinkan berbagai orang di Microsoft untuk menerima apa yang dapat mereka lakukan, tetapi sejauh ini saya tidak berhasil. Front-end sepertinya tidak menjadi prioritas besar bagi Microsoft saat ini.

@EisenbergEffect Masalahnya bagi saya adalah bahwa Blazor menggunakan Razor yang MVC. Kami membutuhkan MVVM sejati yang dapat menggunakan kekuatan runtime clr penuh. Seperti template berbasis konvensi jenis dll. Saya memulai pekerjaan ini dengan DuoCode dan knockout dan menggunakan Knockout.BindingConventions saya untuk merekatkannya. Saya bahkan mendapatkan sintaks seperti ini berfungsi

public IEnumerable<IResult> Save()
{
    var confirm = new ConfirmResult("Proceed?");
    yield return confirm;

    if (confirm.Result == ConfirmResults.Cancel)
        yield break;

    yield return new service.SendCommand(new SaveSomethingCommand(this.something));
}

https://github.com/AndersMalmgren/Knockout.BindingConventions.DuoCode/wiki/IResult-state-machine

Knockout mati dan minat saya dengan itu. Tapi mimpi itu tetap hidup :D

Yah, saya mungkin mengambil pekerjaan itu lagi tetapi dengan Vue atau yang serupa.

Mungkin Aurelia bukan Vue, karena Aurelia turun dari Durandal, yang berasal dari Caliburn.Micro. Juga, Aurelia memiliki konvensi, model vanilla JS, berkinerja lebih baik, memiliki kepatuhan standar yang kuat, dan lebih banyak kebaikan yang tidak dimiliki kerangka kerja lain

Itu bukan Blazor. Blazor tidak dirancang dengan benar (itu mengulangi .NET pola anit dari 10 tahun yang lalu), juga tidak cukup ambisius, cukup sesuai standar, atau cukup melihat ke depan, menurut pendapat saya.

Apakah ada yang salah?

@EisenbergEffect atau Aurelia. Saya suka Aurelia tetapi karena menggunakan JavaScript atau TypeScript yang merupakan bahasa penghapusan tipe, Anda kehilangan semua keajaiban runtime CLR manis yang dapat Anda lakukan. Plus JavaScript DI adalah omong kosong yang jujur ​​​​dibandingkan dengan apa yang dapat Anda lakukan dengan runtime clr yang tepat. Saya menerapkan wadah DI kecil untuk Duocode untuk proyek yang sama yang disebutkan sebelumnya dan injeksi berbasis tipe di frontend adalah cara maju menurut saya. Saya perlu melihat ke dalam modularitas Aurelia, knockout sangat dapat diperpanjang pada masa itu, dan Vue tampaknya melanjutkan tren itu.

@AndersMalmgren Aurelia mungkin adalah kerangka kerja front-end yang paling dapat diperluas saat ini. Implementasi vNext yang sedang kami kerjakan juga membawanya ke level lain. Anda juga mungkin akan terkejut dengan apa yang dapat kami lakukan dengan DI kami :) Ini berbasis tipe dan memiliki masa pakai yang dapat diperpanjang, dll. Karena JS memiliki dukungan asli untuk kelas, tidak ada penghapusan. Kami juga dapat memodelkan antarmuka dengan metode pembantu DI atau Simbol Vanilla JS. Jadi, TS dapat menggabungkannya dengan antarmuka TS, memungkinkan pola yang sama seperti .NET. Dengan kata lain, Anda dapat menginjeksikan IAuthenticationService ke dalam kelas dengan baik saat runtime Sejauh yang saya tahu, kami adalah satu-satunya kerangka kerja yang dapat melakukan ini. Saya mencoba membawa sebanyak mungkin bagian yang baik dari Xaml dan Caliburn.Micro ke web sambil meninggalkan bagian yang buruk. Jadi MVVM bahkan jauh lebih sederhana dan lebih kuat di Aurelia juga. Saya akan mengumpulkan serangkaian posting blog di Aurelia untuk pengembang Xaml dan Aurelia untuk pengembang ASP.NET MVC. Itu mungkin membantu orang menghubungkan titik-titik dan memahami mengapa/bagaimana hal itu membuat pengembangan front-end tidak hanya cepat dan mudah, tetapi juga SOLID.

@manigandham Saya menghabiskan bertahun-tahun sebagai pengembang .NET, pemimpin sumber terbuka .NET, dan Microsoft MVP, memberikan banyak umpan balik kepada Microsoft tentang hal-hal seperti ini. Saya bahkan bekerja untuk Microsoft sebagai Sr. PM, Sr. PM Manager dan Principal PM Manager untuk sementara waktu (bukan di tim .NET). Sayangnya, selama sekitar 12 tahun atau lebih ketika saya melakukan itu, saya melihat sangat sedikit yang datang darinya, terutama mengenai umpan balik yang saya berikan seputar kerangka kerja front-end. Jadi, Anda harus memaafkan saya jika saya tidak ingin menghabiskan hari Sabtu saya dengan menulis makalah 10 ribu kata tentang masalah desain dengan Blazor, masalah standar web, visi produk, dll. Saya tidak yakin itu akan terjadi. jumlah untuk apapun. Jika Microsoft ingin mempekerjakan saya untuk memimpin masa depan front-end bagi mereka, saya pasti akan mempertimbangkannya, tetapi seperti yang saya katakan, front-end bukanlah prioritas bagi mereka saat ini. Dan sejauh yang saya tahu, Blazor bahkan belum didanai.

Dan bagi mereka yang tidak mengenal saya, saya hanya ingin menambahkan bahwa saya tidak marah tentang semua ini atau orang yang marah. Saya tahu terkadang hal-hal tampak seperti itu ketika Anda tidak mengenal saya dan Anda hanya membaca komentar saya di sini atau di sana. Namun, saya sangat sangat bersemangat tentang front-end. Saya telah membangun kerangka kerja front-end, perpustakaan, dan alat untuk hampir seluruh karir saya. Ini adalah 15 tahun yang singkat, tetapi waktu yang relatif lama untuk dihabiskan untuk fokus di bidang ini. Jadi, saya telah melihat banyak hal, melakukan banyak hal dan benar-benar memiliki pendapat yang kuat. Saya bersemangat dan frustrasi ketika saya melihat Microsoft mengulangi kesalahan lama atau melakukan hal-hal yang saya lihat salah di tempat lain. Jadi, saya tidak punya niat buruk di sini. Saya sangat ingin Microsoft berhasil. Saya ingin melihat mereka menjadi pemimpin di front-end. Saya hanya merasa frustrasi dan sedikit sedih untuk jujur, ketika saya melihat itu tidak terjadi. Saya ingin yang terbaik untuk .NET dan komunitasnya.

Anda harus memaafkan saya jika saya tidak ingin menghabiskan hari Sabtu saya menulis makalah 10 ribu kata tentang masalah desain dengan Blazor

Intinya adalah Anda membuat klaim, dan kemudian seseorang hanya meminta Anda untuk menjelaskan lebih detail tentang hal itu:

Blazor tidak dirancang dengan benar (itu mengulangi .NET pola anit dari 10 tahun yang lalu), juga tidak cukup ambisius, cukup sesuai standar, atau cukup melihat ke depan, menurut pendapat saya.

Saya juga ingin tahu tentang contoh-contoh tertentu.

Dan mengingat sifat Blazor saat ini, saya tidak yakin adil untuk membandingkannya dengan produk Microsoft pada umumnya. Ini _belum_ produk, dan sedang dikembangkan di tempat terbuka jauh lebih banyak daripada jika memang demikian.

@chucker saya mengerti. Sangat murah bagi saya untuk membuat klaim seperti itu dan tidak menjelaskan secara rinci. Saya bersyukur Anda tertarik untuk mendengar lebih banyak.

Dari sudut pandang saya, sebagian besar dari apa yang akan saya katakan adalah umpan balik yang telah saya berikan kepada Microsoft sebelumnya, seringkali berulang kali sebelumnya. Jadi, meskipun ini akan menarik bagi Anda, saya tidak yakin itu akan membuat perbedaan bagi Microsoft. Saya tidak tahu apakah ada yang akan berubah.

Yang mengatakan, saya akan mencoba untuk mulai menguraikan sesuatu. Akan terlalu lama untuk memberikan komentar GitHub. Saya agak takut akan reaksi balik jika saya mempublikasikan blog tentang hal itu. Saya telah diganggu dan dibenci berkali-kali dalam karir saya oleh berbagai kelompok yang tidak suka dikritik. Sementara itu sebagian besar adalah anggota tim Facebook/React baru-baru ini, saya tidak yakin saya ingin membuka diri untuk itu lagi.

Mungkin ada beberapa cara saya dapat membingkai posting seperti itu di mana itu akan membuat perbedaan dan tidak mengundang banyak hal negatif. Ini adalah permainan yang sulit untuk dimainkan. Aku akan memikirkannya.

Saya dapat mengonfirmasi bahwa dalam banyak hal, baik Blazor yang dikenal maupun yang tidak dikenal tidak dirancang dengan sempurna dan kami menerima umpan balik yang membangun untuk menjadikannya lebih baik. Sebagaimana dibuktikan oleh backlog masalah kami, ada banyak pekerjaan yang harus dilakukan! Dan sementara kesempurnaan desain hampir pasti akan tetap sulit dipahami, pada akhirnya yang terpenting adalah apakah pengembang menganggap penggunaan Blazor produktif dan bermanfaat. Itu sepertinya bisa dicapai.

@EisenbergEffect Saya tentu saja menyambut kritik atau umpan balik yang objektif dan membangun yang mungkin Anda miliki. Seperti halnya kritik objektif, saya tidak bisa menjanjikan itu akan mengubah apa pun. Saya hanya bisa mengatakan bahwa kami akan melakukan yang terbaik untuk mempertimbangkannya dengan serius.

Selain itu, tidak ada seorang pun yang pantas diganggu atau dibenci dan perilaku seperti itu secara eksplisit bertentangan dengan Kode Etik kita .

Menurut pendapat saya, Blazor telah berhasil. Dalam 20 tahun saya berkembang dengan teknologi Microsoft dan non Microsoft, saya telah melihat pola yang sama muncul setiap saat. Ketika sesuatu yang baru keluar, Anda melihat dua jenis pengembang. Orang yang melihat model pemrograman sebagai kendaraan untuk mencapai suatu tempat dan orang yang suka menghabiskan berjam-jam bermain-main dengan perpustakaan yang berbeda. Saya telah mencoba meyakinkan diri sendiri bahwa menggunakan semua perpustakaan js yang berbeda dari semua perusahaan yang berbeda ini memberi saya lebih banyak mobilitas dan kebebasan sebagai pengembang tetapi segera menemukan bagaimana mereka semua terpisah dalam visi, misi, dan sayangnya, kompatibilitas di beberapa titik waktu. Saya selalu mencari model pemrograman terpadu dan menyadari bahwa konvensi yang ketat tidak selalu merupakan hal yang buruk. Pendeknya. Saya peduli dengan solusinya dan Microsoft tidak pernah mengecewakan saya. Beberapa aplikasi web terbaik dan paling sering saya gunakan semuanya dilakukan pada teknologi Microsoft dan saya percaya Blazor akan menghadirkan model pemrograman terpadu yang bagus yang berfungsi dengan baik tetapi tidak bergantung pada ratusan perpustakaan lain yang bekerja bersama.

Menurut pendapat saya, Blazor telah berhasil. Dalam 20 tahun saya berkembang dengan teknologi Microsoft dan non Microsoft, saya telah melihat pola yang sama muncul setiap saat. Ketika sesuatu yang baru keluar, Anda melihat dua jenis pengembang. Orang yang melihat model pemrograman sebagai kendaraan untuk mencapai suatu tempat dan orang yang suka menghabiskan berjam-jam bermain-main dengan perpustakaan yang berbeda. Saya telah mencoba meyakinkan diri sendiri bahwa menggunakan semua perpustakaan js yang berbeda dari semua perusahaan yang berbeda ini memberi saya lebih banyak mobilitas dan kebebasan sebagai pengembang tetapi segera menemukan bagaimana mereka semua terpisah dalam visi, misi, dan sayangnya, kompatibilitas di beberapa titik waktu. Saya selalu mencari model pemrograman terpadu dan menyadari bahwa konvensi yang ketat tidak selalu merupakan hal yang buruk. Pendeknya. Saya peduli dengan solusinya dan Microsoft tidak pernah mengecewakan saya. Beberapa aplikasi web terbaik dan paling sering saya gunakan semuanya dilakukan pada teknologi Microsoft dan saya percaya Blazor akan menghadirkan model pemrograman terpadu yang bagus yang berfungsi dengan baik tetapi tidak bergantung pada ratusan perpustakaan lain yang bekerja bersama.

Jika Microsoft tidak mengambil pengaruh dari luar, kami akan terjebak pada winforms dan webforms

https://devblogs.microsoft.com/dotnet/introducing-net-5/
Hari ini, kami mengumumkan bahwa rilis berikutnya setelah .NET Core 3.0 adalah .NET 5. Ini akan menjadi rilis besar berikutnya dalam keluarga .NET.

Hanya akan ada satu .NET yang akan datang, dan Anda akan dapat menggunakannya untuk menargetkan Windows, Linux, macOS, iOS, Android, tvOS, watchOS dan WebAssembly dan banyak lagi.

Kami akan memperkenalkan .NET API baru, kemampuan runtime, dan fitur bahasa sebagai bagian dari .NET 5.