Aspnetcore: .NET कोर को WASM अनुभव को Blazor से अलग करें

हाय @EisenbergEffect! मुख्य WebAssembly कार्य वास्तव में मोनो टीम द्वारा नियंत्रित किया जा रहा है। हम ब्लेज़र को उनके द्वारा प्रदान की जाने वाली चीज़ों के ऊपर बना रहे हैं। .NET समुदाय के अन्य लोग भी ऐसा करने के लिए स्वतंत्र हैं और कई पहले से ही हैं ( Ooui , Uno , cshtml5 )। आप मोनो रेपो में mono.wasm पर प्रगति के साथ-साथ अनुसरण कर सकते हैं।

मुझे मोनो को WebAssembly में संकलित करने में बहुत दिलचस्पी नहीं है। मुझे केवल .NET कोर में दिलचस्पी है। मैं जो मांग रहा हूं वह ऐसा कुछ है:

• .NET कोर C# प्रोजेक्ट बनाने के लिए .NET CLI का उपयोग करें।
• मेरे .NET कोर प्रोजेक्ट को WASM में संकलित करने के लिए .NET CLI का उपयोग करें, जिसमें ऊपर वर्णित 3 आउटपुट हैं।

@ danroth27 क्या यह आज समर्थित है?

मोनो लोग सहायक MSBuild SDK के साथ WebAssembly को .NET कोड के पूर्ण अग्रिम समय (AoT) संकलन पर भी काम कर रहे हैं। इस प्रयास पर उनके द्वारा प्रकाशित अंतिम अपडेट http://www.mono-project.com/news/2018/01/16/mono-static-webassembly-compilation/ था @mhutch शायद सबसे अच्छा संपर्क है।

मुझे मोनो में कोई दिलचस्पी नहीं है। मुझे केवल .NET कोर में दिलचस्पी है। क्या .NET कोर WASM के लिए कोई कहानी है?

क्या .NET कोर WASM के लिए कोई कहानी है?

फिलहाल नहीं। .NET कोर आज मुख्य रूप से क्रॉस-प्लेटफ़ॉर्म सर्वर परिदृश्यों के लिए उपयोग किया जाता है। मोनो आज क्रॉस-प्लेटफ़ॉर्म क्लाइंट परिदृश्यों (Android, iOS, macOS, गेमिंग) के लिए उपयोग किया जाने वाला .NET रनटाइम है। अधिकांश WebAssembly परिदृश्य आज क्लाइंट परिदृश्य हैं, इसलिए मोनो अभी सबसे सस्ता तरीका है। समय के साथ यह उम्मीद करना उचित है कि एक अभिसरण होगा, लेकिन इसमें कुछ समय लगेगा।

एफडब्ल्यूआईडब्ल्यू मुझे सच में लगता है कि रनटाइम और प्लेटफॉर्म लक्ष्य के इस मुद्दे को पहले संबोधित करने की जरूरत है। जब मैंने सुना कि मुझे ऐप बनाने के लिए .NET के दो अलग-अलग फ्लेवर का उपयोग करना है ... अपने क्लाइंट के लिए मोनो का उपयोग करें और फिर अपने सर्वर के लिए .NET कोर का उपयोग करें ... यह मुझे बिल्कुल भी उत्साहित नहीं करता है। मैं सिर्फ .NET कोर का उपयोग करना चाहता हूं, और स्पष्ट रूप से, भूल जाओ कि कोई अन्य .NET मौजूद है। एक .NET कृपया :)

@EisenbergEffect उपभोग करने वाले परिप्रेक्ष्य से यह एक कार्यान्वयन विवरण होना चाहिए जो रनटाइम आपका कोड चला रहा है।

मैं असहमत हूं। एक सॉफ्टवेयर इंजीनियर होने के अपने इतिहास में मैंने कभी भी इस पर विचार नहीं किया है कि कौन सा रन-टाइम मेरे कोड को एक कार्यान्वयन विवरण के रूप में चला रहा है जिसे मैं अनदेखा कर सकता हूं।

@ danroth27 बस मेरी विकास टीम से कुछ प्रतिक्रिया, हम अंततः ब्लेज़र का उपयोग .NET कोर का उपयोग करते हुए देखना चाहेंगे। हमें मोनो या यहां तक ​​कि पूर्ण .NET ढांचे में कोई दिलचस्पी नहीं है। हम क्लाइंट और सर्वर पर समान रनटाइम चाहते हैं।

हमें मोनो या यहां तक ​​कि पूर्ण .NET ढांचे में कोई दिलचस्पी नहीं है। हम क्लाइंट और सर्वर पर समान रनटाइम चाहते हैं।

खैर, कोई फर्क नहीं पड़ता कि हम क्या करते हैं, आपके पास सर्वर और ब्राउज़र में बिल्कुल समान रनटाइम नहीं होगा: ब्राउज़र रनटाइम को WebAssembly आधारित होना चाहिए, लेकिन सर्वर एक नहीं है। यह इसके विपरीत नहीं है कि आईओएस पर कैसे चलना सर्वर पर चलने से मौलिक रूप से अलग है। क्लाइंट और सर्वर पर एकीकृत कारक .NET मानक है। उस ने कहा, मुझे लगता है कि हम आपके लक्ष्य को एक रनटाइम इम्पेमेंटेशन पर एकजुट करने के लिए साझा करते हैं। Microsoft के लिए लंबे समय में दो रनटाइम को दोगुने मूल्य पर रखने और बनाए रखने का कोई मतलब नहीं है। कन्वर्जेंस का काम पहले से ही कई तरह से हो रहा है। मोनो और .NET कोर में अधिक से अधिक कोड साझा किए जाते हैं। लेकिन सिंगल रनटाइम तक पहुंचना अभी भी एक बड़ा प्रयास है जिसमें कुछ समय लगेगा।

इस बीच ब्लेज़र एक प्रयोग है और हम प्रयोग कर रहे हैं कि आज क्या काम किया जा सकता है

@ danroth27 उत्कृष्ट प्रतिक्रिया के लिए धन्यवाद, डैन!

बहुत बढ़िया पूरी तरह से सहमत

मंगलवार, मई १५, २०१८ को सुबह १०:५४ बजे पाउलोस्ट नोटिफिकेशन @github.com ने लिखा:

@ danroth27 https://github.com/danroth27 उत्कृष्ट के लिए धन्यवाद
प्रतिक्रिया, दान!

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/aspnet/Blazor/issues/835#issuecomment-389046589 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/ACnwPz_cCiVg6iti9VR9pQWY34_Hibf4ks5tymapgaJpZM4T-jpA
.

@EisenbergEffect मेरे पास मोनो पर समान विचार था, हालांकि जब मुझे पता चला कि चूंकि Microsoft ने Xamarine का अधिग्रहण किया है, मोनो Microsoft तकनीक है ... और क्लाइंट परिदृश्यों के लिए अनुकूलित है ... और मैं इसका उपयोग अपने ".net मानक" कोड को चलाने के लिए कर सकता हूं। ब्राउज़र आज... सभी चिंताओं को दूर कर दिया गया।

ब्राउज़र रनटाइम केवल घटकों को हथियाने के लिए:
https://jenkins.mono-project.com/job/test-mono-mainline-wasm/label=ubuntu-1804-amd64/

... अब मैं सी # लक्ष्यीकरण वेबजीएल में अपना स्वयं का एक्सएएमएल आधारित यूआई स्टैक बनाने के लिए वापस आ गया हूं

स्पष्ट होने के लिए, यह गैर-Microsoft तकनीक का उपयोग करने के बारे में नहीं है। यह केवल .NET कोर का उपयोग करने के बारे में है। मैं एक एकीकृत क्रॉस-प्लेट सीएलआई के साथ एक, खुला स्रोत, क्रॉस-प्लेटफ़ॉर्म .NET ढूंढ रहा हूं। दो या तीन .NET या एकाधिक कंपाइलर नहीं। मैंने सोचा होगा कि नए प्रयास .NET कोर और एकीकरण के आसपास केंद्रित होंगे, इसलिए मुझे यह आश्चर्यजनक लगा कि WASM केवल मोनो के लिए था और एक अलग टूलचेन की आवश्यकता थी।

मैं व्यक्तिगत रूप से 10 से अधिक वर्षों से .NET प्लेटफॉर्म में एकीकरण के लिए कह रहा हूं। तो, अगर मैं इस धागे में थोड़ा उत्तेजित हूं, तो मुझे क्षमा करें, क्योंकि 10 वर्षों के बाद भी मुझे अपनी सेवाओं और ग्राहकों को बनाने के लिए 3 .NET की आवश्यकता है। बहुत कम चीजें हैं जिनके लिए मैं 10 साल इंतजार करने को तैयार हूं। मैंने कई साल पहले .NET छोड़ दिया था और दिसंबर के बाद से यह देखने के लिए कि क्या स्थिति में सुधार हुआ है। मैं उन्हीं मुद्दों में से कई को पाकर थोड़ा निराश हूं, जिन्हें मैंने पीछे छोड़ दिया था, जो अभी भी सुस्त हैं।

मेरा मतलब पूरी ईमानदारी के साथ है, मैं फिर से .NET से प्यार करना चाहता हूं। कृपया, इसे गंभीरता से लें।

मेरा मतलब पूरी ईमानदारी के साथ है, मैं फिर से .NET से प्यार करना चाहता हूं। कृपया, इसे गंभीरता से लें।

हम इस मुद्दे को गंभीरता से ले रहे हैं और हम विभिन्न .NET रनटाइम के अभिसरण पर सक्रिय रूप से काम कर रहे हैं। लेकिन इसमें समय लगेगा, और हम बहुत अच्छी तरह से तय कर सकते हैं कि व्यावहारिक विचारों के कारण अल्पावधि में .NET कोर के साथ अभिसरण के लिए लंबे रोडमैप के साथ मोनो के साथ आगे बढ़ना समझ में आता है।

मुझे अपनी सेवाएं और क्लाइंट बनाने के लिए अभी भी 3 .NET की आवश्यकता है

मुझे लगता है कि आप जिन तीन .NET का जिक्र कर रहे हैं, वे .NET फ्रेमवर्क, .NET कोर और मोनो हैं। अच्छी खबर यह है कि हमने बिल्ड में घोषणा की थी कि .NET कोर 3 में विंडोज डेस्कटॉप अनुप्रयोगों के लिए समर्थन होगा, इसलिए उम्मीद है कि यह उन रनटाइमों में से एक की आवश्यकता को कम करेगा और आगे सबूत प्रदान करेगा कि अभिसरण हमारा सामान्य लक्ष्य है।

एफडब्ल्यूआईडब्ल्यू, मोनो पहले से ही रोसलिन कंपाइलर और एमएसबिल्ड बिल्ड सिस्टम पर स्विच कर चुका है, इसलिए यह वास्तव में एक अलग टूलचेन नहीं है। आप एक ही बिल्ड सिस्टम और कंपाइलर के साथ, एक ही समाधान में .Net Core और Mono- आधारित प्रोजेक्ट बना सकते हैं। मोनो .NET कोर क्लासलिब्स के बड़े और लगातार बढ़ते भागों का भी उपयोग कर रहा है।

WASM एक बहुत ही असामान्य लक्ष्य है। न केवल जेआईटी संकलन करना संभव नहीं है, थ्रेडिंग, फाइल और सॉकेट जैसी चीजें अधिकांश अन्य प्लेटफार्मों के लिए बहुत अलग मॉडल हैं। मोनो के पास आईओएस, वॉचओएस, पीएस 4 आदि जैसे अन्य असामान्य/बाधित प्लेटफार्मों के लिए बंदरगाहों के लिए विकसित कई मौजूदा प्रौद्योगिकियां हैं जो डब्लूएएसएम पोर्ट के साथ मदद करती हैं, जैसे आईएल दुभाषिया, सहकारी जीसी सस्पेंड, पूर्ण एओटी (जेनेरिक के लिए आश्चर्यजनक रूप से कठिन) जेनरिक साझाकरण के साथ , LLVM बिटकोड बैकएंड, और प्रबंधित लिंकिंग।

मैं पूरी तरह से उम्मीद करता हूं कि मोनो के डब्ल्यूएएसएम प्रोजेक्ट प्रकार एसडीके-शैली परियोजनाओं का उपयोग करें, एमएसबिल्ड एसडीके के साथ NuGet के माध्यम से वितरित किया गया है, और dotnet से प्रयोग योग्य है।

मुझे लगता है कि मुझे यहाँ कुछ मोनो से नफरत है, नहीं?
कृपया मोनो को बाहर फेंकने के लिए इतनी जल्दी न करें। याद है जब Microsoft को Linux से कोई प्यार नहीं था? सी # देवों के लिए मोनो वहां था। याद है जब माइक्रोसॉफ्ट को मैक ओएस से कोई प्यार नहीं था? मोनो वहाँ फिर से था। अब जावास्क्रिप्ट हमारे लंच खा रहा है, अनुमान लगाओ कि कौन दिखाता है? आप शर्त लगाते हैं, मोनो दिन बचाने के लिए यहां है, वासम पर चलने वाला पहला पूर्ण .net होने के नाते। कृपया कुछ सम्मान दिखाएं!

सुनो, हम सी # देव इस तरफ मोनो से प्यार करते हैं। वे शानदार काम कर रहे हैं। मोनो को अकेला छोड़ दो। अगर कूल किड। नेट कोर पार्टी करना चाहता है, वह भी ठीक है, लेकिन मोनो स्टेज़!

@humbersoft यदि आप कोई कारण चाहते हैं कि हम मोनो से "नफरत" क्यों करते हैं तो मैं आपको एक दूंगा। यह आपके ब्राउज़र कंसोल में इस तरह की त्रुटियां देख रहा है: "WASM: इसे `/Users/builder/jenkins/workspace/test-mono-mainline-webassembly/label/highsierra/sdks/out/wasm-interp/ में स्थापित किया जाना चाहिए था। lib/mono/4.5/mscorlib.dll' निर्देशिका।" जेनकिंस कौन है? क्या अजीब संदेश है! एक मोनो देव ने रनटाइम में अपने व्यक्तिगत पथ को स्पष्ट रूप से हार्ड-कोड किया।

@paulost जेनकींस एक सतत निर्माण सेवा है। इसको ढूंढो। यह बहुत लोकप्रिय है।

धन्यवाद @MisinformedDNA लेकिन मोनो मुझे क्यों बता रहा है कि इसे मेरे सिस्टम पर उस सटीक पथ में स्थापित किया जाना चाहिए? मैं मोनो बनाने की कोशिश नहीं कर रहा हूं लेकिन केवल ब्लेज़र ऐप चलाने के लिए इसका इस्तेमाल करता हूं। एक शिप किया गया रनटाइम आपको इसके निर्माण सेवा पथ के बारे में नहीं बताना चाहिए।

मेरे पास त्रुटि का पूरा संदर्भ नहीं है, लेकिन मैं गारंटी दे सकता हूं कि आपको अतिरिक्त डीबग जानकारी दिखाई देगी क्योंकि Blazor एक शिप किया गया उत्पाद नहीं है। मोनो भेज दिया जा सकता है, लेकिन हम मोनो के पूर्वावलोकन संस्करणों का भी उपयोग कर रहे हैं या मोनो के शीर्ष पर निर्मित पूर्वावलोकन पुस्तकालयों का उपयोग कर रहे हैं। याद रखें, हम अभी भी प्रायोगिक चरण में हैं।

अंत में, Xamarin मोनो पर चलता है, जो संभवत: हजारों मोबाइल ऐप चलाता है। यह एक अच्छी तकनीक है। क्या एक रनटाइम रखना बेहतर होगा? बेशक। लेकिन .NET Framework केवल विंडोज़ है और मोनो को बाद में Linux के साथ संगतता के लिए एक पोर्ट के रूप में बनाया गया था और .NET Core को तब क्लाउड में बेहतर मापनीयता के लिए बनाया गया था। क्या आपको सच में लगता है कि MS तीन अलग-अलग रनटाइम को प्रबंधित करना पसंद करता है? बिलकूल नही। लेकिन हर भाषा में .NET का पैमाना या महत्वाकांक्षा नहीं होती है। साथ ही, यदि आप चूक गए हैं, तो MS WPF, WinForms और UWP को .NET Core 3.0 में पोर्ट कर रहा है। .NET कोर भविष्य है, लेकिन इसमें समय लगेगा।

हां, मोनो वेब असेंबली समर्थन पूर्वावलोकन में है और अभी तक किसी भी रिलीज में शिप नहीं किया गया है।

इस विशेष मामले में, रनटाइम अपने वर्तमान फाइल सिस्टम स्थान के आधार पर रनटाइम असेंबली निर्देशिका (जिसमें mscorlib.dll जैसी फ़ाइलें शामिल हैं) निर्धारित करने का प्रयास करता है, और अंतिम-खाई फ़ॉलबैक वह पथ है जिसमें रनटाइम संकलित किया गया था। wasm पर "फाइल सिस्टम स्थान" की अवधारणा वास्तव में लागू नहीं होती है ... अन्य समान एम्बेडेड सेटअप पर एम्बेडिंग कोड आम तौर पर एक कस्टम असेंबली रिज़ॉल्वर पंजीकृत करता है (उदाहरण के लिए एंड्रॉइड एपीके ज़िप से हल करने के लिए), और मुझे लगता है कि ऐसा नहीं है अभी तक यहां स्थापित किया गया है।

@PaulOst
खून बहने वाले किनारे पर रहने के साथ यही बात है, आपको कट जाने की संभावना है। WASM के लिए मोनो अपने शुरुआती चरण में है और बहुत प्रयोगात्मक है, लेकिन यह डॉटनेट एनीवेयर की तुलना में अधिक पूर्ण है जिस पर ब्लेज़र मूल रूप से आधारित था। यह अभी तक निश्चित रूप से पॉलिश नहीं किया गया है, इसलिए आपके द्वारा अनुभव की जाने वाली त्रुटियों की अपेक्षा की जानी चाहिए।

कुछ देवों को हॉट बिट्स पसंद हैं, कुछ लोग तब तक प्रतीक्षा करते हैं जब तक कि सब कुछ शांत और शांत न हो जाए। ये हॉट बिट्स हैं, हो सकता है कि आपको अपनी अपेक्षाओं को थोड़ा समायोजित करने की आवश्यकता हो। मैं परिप्रेक्ष्य को समझता हूं, हालांकि, आप एक पॉलिश उत्पाद चाहते हैं। क्या आप कल्पना कर सकते हैं कि Wasm को लक्षित करने के लिए .NET Core की प्रतीक्षा की जा रही है? वे इसे 3 साल तक नहीं प्राप्त कर सकते हैं। मोनो एक ठोस उत्पाद है और यह सौभाग्य की बात है कि माइक्रोसॉफ्ट के पास यह है, अन्यथा, हमारे पास WASM और कई अन्य प्लेटफार्मों के लिए .NET कहानी नहीं होती।

एक और बात, मैं आपको प्रस्तुत करता हूं कि अधिकांश देव नए Microsoft को पसंद करते हैं जो खुले में इस तरह की महत्वपूर्ण तकनीक विकसित कर रहा है। हम अंत में एक बेहतर उत्पाद के साथ समाप्त होंगे।

कहा जा रहा है कि, ब्लेज़र कई अच्छे कारणों से दिन के उजाले को भी नहीं देख सकता है। उसके लिए भी योजना बनाएं।

मैंने आगे बढ़कर एक Xaml इंजन बनाना शुरू किया जो ब्राउज़र में मूल रूप से चलता है। आप इसे यहां देख सकते हैं: https://github.com/XamlEngine/Samples

इस चर्चा में शामिल होने में थोड़ी देर हुई, लेकिन आश्चर्य हुआ कि इतने सारे लोग चिंतित हैं कि उनका .NET मानक कोड कैसे चलता है। रनटाइम पर आप जो भी लेबल चाहते हैं उसे थप्पड़ मारें - मोनो, .NET कोर, फ्लबरगैस्ट - जो भी वास्तविक रनटाइम अलग होने वाला है। कोई रास्ता नहीं है। सर्वर पर .NET कोर WASM पर .NET कोर के समान होगा या WASM के विरुद्ध संकलन करेगा। तो बिल्ली वास्तव में कौन परवाह करता है?

क्या मायने रखता है कि रबर सड़क से कैसे मिलता है या उस रनटाइम कोड तक पहुंचना कितना आसान है। मैं @EisenbergEffect से सहमत

ब्लेज़र क्या करता है इसके अलावा इसे एक गंभीर धक्का क्यों न दें क्योंकि यह निश्चित रूप से ब्राउज़र में .NET का उपयोग करने के विभिन्न तरीकों के आसपास नवाचार को बढ़ावा देगा। यह नेट की दृश्यता के लिए केवल एक बड़ा प्लस हो सकता है यदि ब्राउज़र में नए और अभिनव तरीकों से .NET का उपयोग करने वाले बहुत से नए प्रोजेक्ट पॉप अप होते हैं। मुझे यकीन है कि रोब पूछ रहा है क्योंकि उसके पास कुछ विचार हैं कि किसी प्रकार का नया ढांचा कैसे बनाया जाए :-)

यह वर्तमान Mono.wasm मॉड्यूल के साथ और भविष्य में .NET कोर या कम से कम मोनो AOT कंपाइलर के साथ करने योग्य है, लेकिन मुझे लगता है कि एक मानक होस्टिंग इंटरफ़ेस का निर्माण करना जो .NET को ब्राउज़र में बूटस्ट्रैप करने की सुविधा प्रदान कर सके, एक लंबा रास्ता तय करेगा। यह लक्ष्य। वास्तविक रनटाइम को तब प्लग इन किया जा सकता है और अद्यतन तकनीक और संसाधन उपलब्ध होने पर स्वैप किया जा सकता है।

यह वेब एसेंबली स्पेस में .NET के लिए एक प्रारंभिक अंगीकार होने के लिए एक बड़े अवसर की तरह प्रतीत होता है। मैंने ब्लेज़र के साथ जो देखा है वह बहुत आशाजनक लगता है, लेकिन मुझे लगता है कि यह उत्तरोत्तर पर्याप्त नहीं है यदि यह .NET का एकमात्र आधिकारिक WASM एक्सपोज़र पॉइंट है। मुझे वास्तव में Blazor मॉडल पसंद है और इसके लिए क्या अनुमति देता है, लेकिन मुझे लगता है कि यदि .NET चलाने के लिए ईको सिस्टम मानक .NET एप्लिकेशन बनाने जितना आसान था, तो यह संभव है। मैं जरूरी नहीं कि यहां यूआई फ्रेमवर्क के बारे में बात कर रहा हूं - लेकिन यहां तक ​​कि सिर्फ बूटस्ट्रैप और ढीले .NET कक्षाओं में कॉल करने में सक्षम होने के नाते या तो एक प्रवेश बिंदु और वेब वर्कर जैसे प्रसंस्करण, या यहां तक ​​​​कि मौजूदा जावास्क्रिप्ट अनुप्रयोगों से इंटरऑप करने के साधन के रूप में। इसके लिए भी कुछ व्यवसाय/सत्यापन कोड साझा करने के लाभ अविश्वसनीय रूप से मूल्यवान हो सकते हैं।

बहुत सारी संभावनाएं - इस तकनीक का उपयोग करना आसान बनाकर जितना संभव हो सके इसे सक्षम करना अच्छा होगा, यहां तक ​​​​कि निचले स्तर के बिट्स भी!

@RickStrhl यह प्रगतिशील नहीं लग सकता है क्योंकि वे अभी भी प्रायोगिक चरण में हैं, लेकिन उनके पास बहुत सारे विचार हैं जिन पर वे काम कर रहे हैं, जिसमें सर्वर रेंडरिंग, डेस्कटॉप/मोबाइल ऐप, वेब वर्कर आदि शामिल हैं। यह आपको एक बेहतर विचार देगा कि क्या वे विचार कर रहे हैं।

ओह, मुझे नहीं लगता कि ब्लेज़र प्रगतिशील नहीं है - मैंने ऊपर अपने संदेश में स्पष्ट किया है। यहां तक ​​​​कि इसके साथ खेलते हुए भी मैं पूरी तरह से बता सकता हूं कि यह ऐप्स बनाने का एक शानदार तरीका है। ऐसे बहुत कम क्षण हैं जहां आप बस जाते हैं - यह जावास्क्रिप्ट/टाइपस्क्रिप्ट में ऐसा दर्द होगा।

मेरा कहना मुख्य रूप से यह है कि मुझे लगता है कि उन्हें ब्लेज़र सामग्री के अलावा कच्ची .NET कार्यक्षमता भी जोड़नी चाहिए। ब्लेज़र का समर्थन करने के लिए इस बुनियादी ढांचे को वैसे भी बनाया जाना है, तो क्यों न इसे अधिक उपयोगकर्ता के अनुकूल तरीके से उजागर किया जाए ताकि क्लाइंट ऐप में .NET 'होस्टिंग' को छोड़ना आसान हो।

मुझे यकीन नहीं है कि मैं समझता हूं, ब्लेज़र हमें अधिकांश .NET कार्यक्षमता का उपयोग करने देता है, आपको क्या लगता है कि विशेष रूप से कौन सी कार्यक्षमता गायब है?

मुझे ब्लेज़र का उपयोग करना है। क्या होगा यदि मेरे पास एक मौजूदा HTML एप्लिकेशन है, या किसी अन्य ढांचे के साथ कुछ बना रहा है और ब्लेज़र की कोई आवश्यकता नहीं है? HTML फ्रेमवर्क के बाहर ब्राउज़र में .NET कोड तक पहुँच प्रदान करने के लिए अभी भी एक बढ़िया उपयोग का मामला है (सत्यापन कोड, उपयोगिताओं आदि को साझा करना)।

मुझे ब्लेज़र का उपयोग करना है। क्या होगा यदि मेरे पास एक मौजूदा HTML एप्लिकेशन है, या किसी अन्य ढांचे के साथ कुछ बना रहा है और ब्लेज़र की कोई आवश्यकता नहीं है? HTML फ्रेमवर्क के बाहर ब्राउज़र में .NET कोड तक पहुँच प्रदान करने के लिए अभी भी एक बढ़िया उपयोग का मामला है (सत्यापन कोड, उपयोगिताओं आदि को साझा करना)।

मुझे समझ नहीं आ रहा है। ब्लेज़र अनिवार्य रूप से है:

1. वेब घटकों के लिए रेजर सिंटैक्स,
2. विभिन्न जेएस इंटरऑप हेल्पर्स,
3. मोनो-आधारित WebAssembly .NET

आप संभवतः उनमें से दूसरा और तीसरा चाहते हैं, और पहला आपको नुकसान नहीं पहुंचाता है।

मेरा कहना मुख्य रूप से यह है कि मुझे लगता है कि उन्हें ब्लेज़र सामग्री के अलावा कच्ची .NET कार्यक्षमता भी जोड़नी चाहिए। ब्लेज़र का समर्थन करने के लिए इस बुनियादी ढांचे को वैसे भी बनाया जाना है, तो क्यों न इसे अधिक उपयोगकर्ता के अनुकूल तरीके से उजागर किया जाए ताकि क्लाइंट ऐप में .NET 'होस्टिंग' को छोड़ना आसान हो।

जैसा कि मैं इसे समझता हूं, यह निश्चित रूप से mono.wasm प्रयास का इरादा है। हम अक्सर एक ही सांस में Blazor और mono.wasm का उल्लेख करते हैं, लेकिन वास्तव में Blazor एक वेब फ्रेमवर्क है। यह mono.wasm है जो अंतर्निहित WebAssembly आधारित .NET रनटाइम प्रदान करता है। अन्य ढांचे एक ही रनटाइम के शीर्ष पर निर्माण के लिए स्वतंत्र हैं, और वैकल्पिक ढांचे पहले से मौजूद हैं ( ओउई , यूनो )। @kumpera @mhutch शायद Xamarin टीम के देव अनुभव से बात करने के लिए सही लोग हैं, वे किसी विशेष UI ढांचे से स्वतंत्र mono.wasm का उपयोग करने में सक्षम होने की उम्मीद करते हैं।

ज़िप फ़ाइल आज, Blazor के बिना C# ऐप्स लिखने के लिए अत्यंत कच्चा समर्थन प्रदान करती है। यह तकनीक को मान्य करने के लिए काफी अच्छा है लेकिन इसके लिए बहुत सारे मैनुअल काम की आवश्यकता होती है।

यह हमारा लक्ष्य है कि इस मुद्दे के विवरण से क्या पता चलता है, समृद्ध बाइंडिंग और डिबगिंग सहित एक पूर्ण टूलचेन।

कौन सी ज़िप फ़ाइल?

@EisenbergEffect आपको
सुनिश्चित करें कि आपके आश्रित एपीआई .NET मानक पर निर्भर हैं और आप अच्छे हैं।

@weitzhandler मुझे लगता है कि आप मेरी बात याद कर रहे होंगे। अगर मैं .NET के साथ कुछ बनाना चाहता हूं, तो मुझे कुछ ठोस उपकरण स्थापित करने होंगे, है ना? मैंने १५ साल पहले .NET के साथ काम करना शुरू किया था, इसलिए मुझे व्यक्तिगत रूप से इसमें से कोई भी चुनौतीपूर्ण या भ्रमित करने वाला नहीं लगता (हालांकि मैं अपनी मशीन पर अर्ध-डुप्लिकेट टूलिंग स्थापित नहीं करना पसंद करता हूं)। लेकिन, किसी ऐसे व्यक्ति की कल्पना करें जिसे .NET का कोई अनुभव नहीं है और जो मैक उपयोगकर्ता है। वे तय करते हैं कि वे फ्रंट-एंड और बैक-एंड दोनों, एक .NET ऐप बनाना चाहते हैं। वे सुनते हैं कि .NET कोर नवीनतम, आकर्षक चीज है, इसलिए वे .NET CLI और VS कोड स्थापित करने के लिए रिगामारोल से गुजरते हैं। फिर, उन्हें पता चलता है कि वे इसके साथ अपना फ्रंट-एंड नहीं बना सकते। उन्हें उपकरणों का एक अलग सेट प्राप्त करने की आवश्यकता है (एक अलग नाम के साथ, एक अलग जगह से, अलग नेतृत्व के साथ, आदि)। फिर से, कल्पना कीजिए कि उनका .NET के साथ कोई पूर्व इतिहास नहीं है। यह पहली बार का अच्छा अनुभव नहीं है। ठीक है, अब कल्पना कीजिए कि यह व्यक्ति एक आर्किटेक्ट या सीटीओ है जो पहली बार या कई वर्षों के बाद .NET का एक नया मूल्यांकन देने की कोशिश कर रहा है। शायद वे अपनी कंपनी के लिए दिशा निर्धारित कर रहे हैं। क्या आप उस व्यक्ति या उनके तकनीकी सलाहकारों के लिए यही अनुभव चाहते हैं? वे इसकी तुलना गो, नोड, रस्ट आदि से करने जा रहे हैं।

जहां तक ​​मेरी व्यक्तिगत भावनाओं का सवाल है, इतने सालों और .NET के इतने सारे संस्करणों के बाद मेरी सहनशीलता काफी कम है। मैं @ danroth27 जैसे लोगों को

मेरी मूल पोस्ट का उद्देश्य एक WASM "उत्तर सितारा" की एक साधारण तस्वीर को एक देव अनुभव से देखना चाहिए और आउटपुट परिप्रेक्ष्य का निर्माण करना चाहिए। मैं सीएलआई स्थापित करता हूं, मैं कुछ सी # कोड लिखता हूं (जो भी संपादक मुझे चाहिए) और फिर मैं डब्लूएएसएम को अपना सी # कोड बनाने के लिए एक सीएलआई कमांड निष्पादित करता हूं, आउटपुट फाइलों (wasm, बाइंडिंग, प्रकार) का एक उचित सेट तैयार करता हूं। यही लक्ष्य होना चाहिए। अगर यह आज नहीं है, तो यह समझ में आता है। लेकिन, आइए सुनिश्चित करें कि हम .NET जहाज को सही दिशा में ले जा रहे हैं, सर्वोत्तम संभव अनुभव की ओर, माइक्रोसॉफ्ट इंजीनियरों के लिए सबसे आसान या तेज क्या है, इसके लिए समझौता नहीं कर रहे हैं।

@EisenbergEffect
रोब, मैं मानता हूं कि लक्ष्य अंततः .NET कोर को हर जगह चलाना होगा यहां तक ​​​​कि मोनो को इसके साथ बदलना।
मैं एक " .NET UI मानक " भी चाहता हूं जो .NET कोर के साथ शामिल किए जाने के लिए हर जगह समान रूप से प्रस्तुत करता है, लेकिन .NET कोर अपेक्षाकृत ताज़ा है। इस विचलन को आकार में लाने के लिए .NET मानक सबसे अच्छा समाधान था, और वर्तमान में ऐसा नहीं लगता कि आप कुछ बेहतर मांग सकते हैं।

मेरा वोट उसी बिंदु के लिए मोनो को .NET कोर से बदलने के लिए है @EisenbergEffect बनाया गया।

@EisenbergEffect मेरे पास वेब के लिए कैलिबर माइक्रो का सपना है, क्या आपके मन में यही है? मैंने वास्तव में कुछ समय पहले नॉकआउट और डुओकोड (mscorlib का जावास्क्रिप्ट पोर्ट) के साथ आध्यात्मिक उत्तराधिकारी पर काम करना शुरू किया था, इससे पहले कि webassembly एक चीज थी।

@AndersMalmgren ऑरेलिया आज वेब के लिए कैलिबर्न.माइक्रो की तरह है। इस साल रिलीज के लिए हम जिस vNext संस्करण पर काम कर रहे हैं, वह वैकल्पिक रेंडरर्स का भी समर्थन करता है, ताकि यह न केवल HTML बल्कि देशी डेस्कटॉप, 3D और कंसोल ऐप्स को भी रेंडर कर सके। यह टाइपस्क्रिप्ट में लिखा गया है, हालांकि .NET में नहीं। भविष्य में किसी बिंदु पर ऑरेलिया को .NET कोर में पोर्ट करना संभव हो सकता है, एक बार यह तकनीक थोड़ी और परिपक्व हो जाए।

उस ने कहा, चूंकि Microsoft Blazor का निर्माण कर रहा है, इसलिए मेरे .NET WASM के लिए व्यक्तिगत रूप से कुछ भी बनाने की संभावना कम है क्योंकि यह मुझे Microsoft के साथ प्रतिस्पर्धा में डाल देगा। इतिहास से, हम जानते हैं कि .NET पारिस्थितिकी तंत्र के अंदर कोई भी खुला स्रोत कभी भी कुछ भी नहीं होता है जब Microsoft ने कुछ ऐसा ही बनाने का फैसला किया है, भले ही वह खुला स्रोत बेहतर डिज़ाइन किया गया हो, अधिक एक्स्टेंसिबल, अधिक प्रदर्शन करने वाला, आदि। मैं सुंदर होने के लिए स्वीकार करता हूं यहाँ घिसा हुआ है। केवल एक चीज जो इसे बदल सकती है, वह यह है कि यदि Microsoft मुझे .NET कोर-आधारित फ्रंट-एंड फ्रेमवर्क और पारिस्थितिकी तंत्र का नेतृत्व करने के लिए नियुक्त करता। हालांकि यह ब्लेज़र नहीं होगा। Blazor को सही ढंग से डिज़ाइन नहीं किया गया है (यह 10yrs पहले से .NET anit-patterns दोहरा रहा है), न ही यह पर्याप्त महत्वाकांक्षी है, मानकों का अनुपालन पर्याप्त है, या मेरी राय में पर्याप्त आगे देख रहा है। Microsoft के लिए दांव पर एक बड़ा अवसर है, लेकिन खिड़की बंद हो रही है। मैंने माइक्रोसॉफ्ट में विभिन्न लोगों को यह समझाने की कोशिश की है कि वे क्या कर सकते हैं लेकिन अभी तक मैं असफल रहा हूं। Microsoft के लिए अभी फ्रंट-एंड एक बड़ी प्राथमिकता नहीं है।

@EisenbergEffect मेरे लिए समस्या यह है कि ब्लेज़र रेजर का उपयोग करता है जो एमवीसी है। हमें एक सच्चे एमवीवीएम की जरूरत है जो एक पूर्ण क्लियर रनटाइम की शक्ति ले सके। जैसे टाइप कन्वेंशन आधारित टेम्प्लेटिंग आदि। मैंने यह काम डुओकोड और नॉकआउट के साथ शुरू किया और उन्हें एक साथ गोंद करने के लिए अपने नॉकआउट.बाइंडिंग कन्वेंशन का उपयोग किया। मुझे इस काम की तरह सिंटैक्स भी मिला है

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

नॉकआउट खत्म हो गया और इसमें मेरी दिलचस्पी थी। लेकिन सपना जिंदा रहता है :D

ठीक है, मैं काम फिर से शुरू कर सकता हूं लेकिन Vue या इसी तरह के साथ।

शायद Vue के बजाय Aurelia, क्योंकि Aurelia Durandal से उतरती है, जो Caliburn.Micro से आती है। इसके अलावा, ऑरेलिया में सम्मेलन हैं, वेनिला जेएस मॉडल हैं, बेहतर प्रदर्शन करते हैं, मजबूत मानकों का अनुपालन करते हैं और बहुत अधिक अच्छाई है जो अन्य ढांचे में नहीं है

हालांकि यह ब्लेज़र नहीं होगा। Blazor को सही ढंग से डिज़ाइन नहीं किया गया है (यह 10yrs पहले से .NET anit-patterns दोहरा रहा है), न ही यह पर्याप्त महत्वाकांक्षी है, मानकों का अनुपालन पर्याप्त है, या मेरी राय में पर्याप्त आगे देख रहा है।

इसके साथ गलत क्या है?

@EisenbergEffect या ऑरेलिया। मुझे ऑरेलिया पसंद है लेकिन चूंकि यह जावास्क्रिप्ट या टाइपस्क्रिप्ट का उपयोग करता है जो कि एक प्रकार की मिटाने वाली भाषा है, आप उस सभी मीठे सीएलआर रनटाइम जादू को खो देते हैं जो आप कर सकते हैं। प्लस जावास्क्रिप्ट DI एक उचित clr रनटाइम के साथ आप जो कर सकते हैं उसकी तुलना में ईमानदार बकवास होना है। मैंने पहले उल्लेखित उसी परियोजना के लिए डुओकोड के लिए एक छोटा डीआई कंटेनर लागू किया और मेरी राय में फ्रंटएंड में टाइप आधारित इंजेक्शन आगे का रास्ता है। मुझे ऑरेलिया की प्रतिरूपकता पर गौर करने की जरूरत है, दिन में नॉकआउट बहुत विस्तार योग्य था, और Vue उस प्रवृत्ति को जारी रखता है।

@AndersMalmgren Aurelia शायद आज का सबसे एक्स्टेंसिबल फ्रंट-एंड फ्रेमवर्क है। हम जिस vNext कार्यान्वयन पर काम कर रहे हैं, वह इसे दूसरे स्तर पर भी ले जाता है। आप भी आश्चर्यचकित हो सकते हैं कि हम अपने डीआई के साथ क्या कर सकते हैं :) यह टाइप आधारित है और इसमें एक्स्टेंसिबल लाइफटाइम आदि हैं। चूंकि जेएस के पास कक्षाओं के लिए मूल समर्थन है, इसलिए कोई इरेज़र नहीं है। हम DI हेल्पर मेथड या Vanilla JS Symbol के साथ इंटरफेस को मॉडल भी कर सकते हैं। इसलिए, TS .NET के समान पैटर्न को सक्षम करते हुए, TS इंटरफेस के साथ विलय कर सकता है। दूसरे शब्दों में, आप IAuthenticationService को रनटाइम पर ठीक कक्षा में इंजेक्ट कर सकते हैं जहां तक ​​​​मुझे पता है, हम एकमात्र ढांचा हैं जो ऐसा कर सकते हैं। मैंने खराब हिस्सों को पीछे छोड़ते हुए Xaml और Caliburn.Micro से अधिक से अधिक अच्छे भागों को वेब पर लाने की कोशिश की। तो एमवीवीएम औरेलिया में भी अधिक सरल और अधिक शक्तिशाली है। मैं Xaml डेवलपर्स के लिए ऑरेलिया और ASP.NET MVC डेवलपर्स के लिए ऑरेलिया पर ब्लॉग पोस्ट की एक श्रृंखला एक साथ रखूंगा। इससे लोगों को बिंदुओं को जोड़ने और यह समझने में मदद मिल सकती है कि यह फ्रंट-एंड विकास को न केवल तेज़ और आसान बनाता है, बल्कि ठोस भी बनाता है।

@manigandham मैंने .NET डेवलपर, .NET ओपन सोर्स लीडर और Microsoft MVP के रूप में कई, कई साल बिताए, इस तरह की सामग्री पर Microsoft को बहुत सारी प्रतिक्रिया दी। मैंने माइक्रोसॉफ्ट के लिए सीनियर पीएम, सीनियर पीएम मैनेजर और प्रिंसिपल पीएम मैनेजर के रूप में भी कुछ समय के लिए काम किया (हालांकि .NET टीम में नहीं)। दुर्भाग्य से, लगभग 12 या इतने वर्षों की अवधि में जब मैं ऐसा कर रहा था, मैंने देखा कि इससे बहुत कम आया, विशेष रूप से उस प्रतिक्रिया के संबंध में जो मैंने फ्रंट-एंड फ्रेमवर्क के आसपास दी थी। इसलिए, अगर मुझे ब्लेज़र के साथ डिज़ाइन के मुद्दों, वेब मानकों की समस्याओं, उत्पाद की दृष्टि, आदि पर 10k शब्द का पेपर लिखने में अपना शनिवार खर्च करने का मन नहीं है, तो आपको मुझे माफ़ करना होगा। मुझे यकीन नहीं है कि यह होगा कुछ भी करने के लिए राशि। यदि Microsoft मुझे उनके लिए फ्रंट-एंड के भविष्य का नेतृत्व करने के लिए नियुक्त करना चाहता है, तो मैं निश्चित रूप से विचार करूंगा, लेकिन जैसा कि मैंने कहा, फ्रंट-एंड वास्तव में उनके लिए अभी प्राथमिकता नहीं है। और जहाँ तक मुझे पता है, Blazor को अभी तक वित्त पोषित भी नहीं किया गया है।

और जो लोग मुझे नहीं जानते, उनके लिए मैं बस इतना ही जोड़ना चाहता हूं कि मैं इस सब से नाराज़ नहीं हूं या नाराज़ व्यक्ति नहीं हूं। मुझे पता है कि कभी-कभी चीजें कुछ इस तरह लगती हैं जब आप मुझे नहीं जानते हैं और आप मेरी टिप्पणियों को यहां या वहां पढ़ते हैं। हालांकि, मैं फ्रंट-एंड को लेकर बहुत जुनूनी हूं। मैं अपने लगभग पूरे करियर के लिए फ्रंट-एंड फ्रेमवर्क, लाइब्रेरी और टूल्स का निर्माण कर रहा हूं। यह 15 वर्ष छोटा है, लेकिन इस क्षेत्र में ध्यान केंद्रित करने के लिए तुलनात्मक रूप से यह एक लंबा समय है। इसलिए, मैंने बहुत सारी चीज़ें देखी हैं, बहुत सारी चीज़ें की हैं और पूरी तरह से मजबूत राय रखता हूँ। मैं भावुक हूँ और मैं निराश हो जाता हूँ जब मैं देखता हूँ कि Microsoft पुरानी गलतियों को दोहरा रहा है या वे काम कर रहा है जो मैंने पहले ही कहीं और गलत होते हुए देखे हैं। इसलिए, मेरी यहां कोई दुर्भावना नहीं है। मैं वास्तव में चाहता हूं कि माइक्रोसॉफ्ट सफल हो। मैं उन्हें फ्रंट-एंड में लीडर बनते देखना चाहता हूं। मैं बस निराश हो जाता हूं और ईमानदार होने के लिए थोड़ा दुखी होता हूं, जब मैं देखता हूं कि ऐसा नहीं हो रहा है। मैं .NET और उसके समुदाय के लिए सर्वश्रेष्ठ चाहता हूँ।

अगर मेरा शनिवार को ब्लेज़र के साथ डिज़ाइन के मुद्दों पर 10k शब्द का पेपर लिखने में मेरा मन नहीं लगता तो आपको मुझे माफ़ करना होगा

मुद्दा यह है कि आपने दावा किया था, और फिर किसी ने आपसे इसके बारे में अधिक विस्तार से जानने के लिए कहा:

Blazor को सही ढंग से डिज़ाइन नहीं किया गया है (यह 10yrs पहले से .NET anit-patterns दोहरा रहा है), न ही यह पर्याप्त महत्वाकांक्षी है, मानकों का अनुपालन पर्याप्त है, या मेरी राय में पर्याप्त आगे देख रहा है।

मैं भी, विशेष उदाहरणों के बारे में उत्सुक रहूंगा।

और अभी Blazor की प्रकृति को देखते हुए, मुझे यकीन नहीं है कि इसकी तुलना औसत Microsoft उत्पाद से करना उचित है। यह अभी तक एक उत्पाद नहीं है, और इसे खुले में विकसित किया जा रहा है, अगर यह होता तो यह कहीं अधिक होता।

@ चकर मैं समझता हूँ। इस तरह का दावा करना और विस्तार में नहीं जाना मेरे लिए सस्ता है। मैं आभारी हूं कि आप और अधिक सुनने में रुचि रखते हैं।

हालांकि, मेरे दृष्टिकोण से, मैं जो कुछ कहूंगा वह वह फीडबैक है जो मैंने पहले माइक्रोसॉफ्ट को दिया है, अक्सर बार-बार पहले। इसलिए, जबकि यह आपके लिए दिलचस्प होगा, मुझे यकीन नहीं है कि इससे Microsoft पर कोई फर्क पड़ेगा। मुझे नहीं पता कि कुछ बदलेगा या नहीं।

उस ने कहा, मैं कुछ रूपरेखा शुरू करने की कोशिश करूंगा। हालांकि गिटहब टिप्पणी में ड्रॉप करना बहुत लंबा होगा। अगर मैं इसके बारे में एक ब्लॉग प्रकाशित करता हूं तो मुझे बैकलैश का थोड़ा डर है। मुझे अपने करियर में कई बार विभिन्न समूहों द्वारा धमकाया गया और नफरत की गई, जिन्हें आलोचना पसंद नहीं थी। हालांकि हाल ही में ज्यादातर फेसबुक/रिएक्ट टीम के सदस्य रहे हैं, मुझे यकीन नहीं है कि मैं इसके लिए खुद को फिर से खोलना चाहता हूं।

हो सकता है कि कोई ऐसा तरीका हो जिससे मैं इस तरह की पोस्ट को फ्रेम कर सकूं, जहां इससे फर्क पड़ेगा और बहुत से नकारात्मक लोगों को आमंत्रित नहीं किया जाएगा। यह खेलना कठिन खेल है। हालांकि मैं इसे कुछ विचार दूंगा।

मैं पुष्टि कर सकता हूं कि कई मायनों में ज्ञात और अज्ञात दोनों ब्लेज़र पूरी तरह से डिज़ाइन नहीं किए गए हैं और हम इसे बेहतर बनाने के लिए किसी भी रचनात्मक प्रतिक्रिया का स्वागत करते हैं। जैसा कि हमारे मुद्दे के बैकलॉग से पता चलता है कि करने के लिए बहुत काम है! और जबकि डिजाइन पूर्णता लगभग निश्चित रूप से मायावी रहेगी, अंत में वास्तव में क्या मायने रखता है अगर डेवलपर्स ब्लेज़र का उपयोग उत्पादक और उपयोगी पाते हैं। इतना कुछ हासिल करने योग्य लगता है।

@EisenbergEffect मैं निश्चित रूप से आपके किसी भी उद्देश्य और रचनात्मक आलोचना या प्रतिक्रिया का स्वागत

साथ ही, कोई भी धमकाए जाने या घृणा करने का पात्र नहीं है और ऐसा व्यवहार स्पष्ट रूप से हमारी आचार संहिता के विरुद्ध है।

मेरी विनम्र राय में ब्लेज़र पहले ही सफल हो चुका है। Microsoft और गैर Microsoft दोनों तकनीकों के साथ विकसित होने के अपने २० वर्षों में मैंने देखा है कि हर बार एक ही पैटर्न उभरता है। जब भी कुछ नया सामने आता है तो आप दो तरह के डेवलपर देखते हैं। एक जो प्रोग्रामिंग मॉडल को कहीं जाने के लिए एक वाहन के रूप में देखता है और वह जो विभिन्न पुस्तकालयों के साथ घंटों-घंटों के साथ छेड़छाड़ करना पसंद करता है। मैंने खुद को यह समझाने की कोशिश की है कि इन सभी अलग-अलग कंपनियों के इन सभी अलग-अलग जेएस पुस्तकालयों का उपयोग करने से मुझे एक डेवलपर के रूप में अधिक गतिशीलता और स्वतंत्रता मिलती है, लेकिन जल्द ही पता चलता है कि कैसे वे सभी दृष्टि, मिशन और अफसोस की बात है, किसी समय संगतता में अलग हो जाते हैं। मैं हमेशा एक एकीकृत प्रोग्रामिंग मॉडल की तलाश में समाप्त हुआ और महसूस किया कि सख्त सम्मेलन हमेशा एक बुरी चीज नहीं होते हैं। संक्षेप में। मुझे समाधान की परवाह है और माइक्रोसॉफ्ट ने मुझे कभी निराश नहीं किया है। मेरे कुछ सबसे अच्छे और सबसे अधिक उपयोग किए जाने वाले वेब ऐप सभी Microsoft तकनीक पर किए गए हैं और मेरा मानना ​​है कि ब्लेज़र एक अच्छा एकीकृत प्रोग्रामिंग मॉडल लाएगा जो अच्छा खेलता है लेकिन एक साथ काम करने वाले सैकड़ों अन्य पुस्तकालयों पर निर्भर नहीं है।

मेरी विनम्र राय में ब्लेज़र पहले ही सफल हो चुका है। Microsoft और गैर Microsoft दोनों तकनीकों के साथ विकसित होने के अपने २० वर्षों में मैंने देखा है कि हर बार एक ही पैटर्न उभरता है। जब भी कुछ नया सामने आता है तो आप दो तरह के डेवलपर देखते हैं। एक जो प्रोग्रामिंग मॉडल को कहीं जाने के लिए एक वाहन के रूप में देखता है और वह जो विभिन्न पुस्तकालयों के साथ घंटों-घंटों के साथ छेड़छाड़ करना पसंद करता है। मैंने खुद को यह समझाने की कोशिश की है कि इन सभी अलग-अलग कंपनियों के इन सभी अलग-अलग जेएस पुस्तकालयों का उपयोग करने से मुझे एक डेवलपर के रूप में अधिक गतिशीलता और स्वतंत्रता मिलती है, लेकिन जल्द ही पता चलता है कि कैसे वे सभी दृष्टि, मिशन और अफसोस की बात है, किसी समय संगतता में अलग हो जाते हैं। मैं हमेशा एक एकीकृत प्रोग्रामिंग मॉडल की तलाश में समाप्त हुआ और महसूस किया कि सख्त सम्मेलन हमेशा एक बुरी चीज नहीं होते हैं। संक्षेप में। मुझे समाधान की परवाह है और माइक्रोसॉफ्ट ने मुझे कभी निराश नहीं किया है। मेरे कुछ सबसे अच्छे और सबसे अधिक उपयोग किए जाने वाले वेब ऐप सभी Microsoft तकनीक पर किए गए हैं और मेरा मानना ​​है कि ब्लेज़र एक अच्छा एकीकृत प्रोग्रामिंग मॉडल लाएगा जो अच्छा खेलता है लेकिन एक साथ काम करने वाले सैकड़ों अन्य पुस्तकालयों पर निर्भर नहीं है।

अगर माइक्रोसॉफ्ट ने बाहर से प्रभाव नहीं डाला तो हम विनफॉर्म और वेबफॉर्म पर फंस जाएंगे

https://devblogs.microsoft.com/dotnet/introducing-net-5/
आज, हम घोषणा कर रहे हैं कि .NET Core 3.0 के बाद अगली रिलीज़ .NET 5 होगी। यह .NET परिवार में अगली बड़ी रिलीज़ होगी।

आगे केवल एक .NET होगा, और आप इसका उपयोग Windows, Linux, macOS, iOS, Android, tvOS, watchOS और WebAssembly आदि को लक्षित करने के लिए कर सकेंगे।

हम .NET 5 के भाग के रूप में नए .NET API, रनटाइम क्षमताओं और भाषा सुविधाओं को पेश करेंगे।