Microsoft - Please Bring Order to the Chaos that is Client-Side Web Development!!
-
An open plea to TPTB at Microsoft: Today I read a hilarious, and scarily on-point article courtesy of the CodeProject Daily News, about the chaos that is today's state of client-side web development. As I read it a realization hit me: we need .NET for the browser. With Mono, Roslyn, .NET Core, etc., all coming into their own, there is at this point no longer any good technological or business-related reason why all web browsers, on any platform, cannot be made to run C# code scripts on the client-side, powered by .NET. Sure, there have been efforts to do this before, Silverlight for example. But I'm not talking about just making a browser-hosted shell that is running compiled applications. I'm talking about using C# as a client-side script, powered by .NET Core and Roslyn, to forever replace the hell that is JavaScript and the upteen-zillion libraries and other variants that are built on it. Just imagine how much life would improve for everyone if we could use the same language for both client and server side coding. How much more stability there would be if .NET were the standard for all client-side programming rather than having a new flavor of the month come out every, well, month. As I read that article I realized that so many of the shortcomings of JavaScript that all these libraries are meant to address would all be moot if .NET and C# were the client-side standard. I understand why this hasn't happened before. .NET was until recently seen as a proprietary Microsoft-only framework. But that's clearly changing. Google, Apple, and Mozilla would just as easily be able to integrate a .NET-based scripting system into their browsers as Microsoft could. There are no patent or royalty issues. Everything that would be needed is open source. Someone just needs to lead the charge. Microsoft lost the browser wars, but that doesn't mean it can't still revolutionize the way web development is done. Heck, even if it only worked on IE and Edge, in the beginning, it would be so attractive that I'd even consider accepting the limitation that my application required those browsers to run. In any event, someone has to be first. Please, for the sake of our sanity - bring C# and .NET to the browser!
Peter Moore - Chicago wrote:
someone has to be first. Please, for the sake of our sanity - bring C# and .NET to the browser
The holy grail of web development, I thought we had gotten there with Silverlight. I posted that article to our development manager in the hope that it may shake some sense into her.
Never underestimate the power of human stupidity RAH
-
An open plea to TPTB at Microsoft: Today I read a hilarious, and scarily on-point article courtesy of the CodeProject Daily News, about the chaos that is today's state of client-side web development. As I read it a realization hit me: we need .NET for the browser. With Mono, Roslyn, .NET Core, etc., all coming into their own, there is at this point no longer any good technological or business-related reason why all web browsers, on any platform, cannot be made to run C# code scripts on the client-side, powered by .NET. Sure, there have been efforts to do this before, Silverlight for example. But I'm not talking about just making a browser-hosted shell that is running compiled applications. I'm talking about using C# as a client-side script, powered by .NET Core and Roslyn, to forever replace the hell that is JavaScript and the upteen-zillion libraries and other variants that are built on it. Just imagine how much life would improve for everyone if we could use the same language for both client and server side coding. How much more stability there would be if .NET were the standard for all client-side programming rather than having a new flavor of the month come out every, well, month. As I read that article I realized that so many of the shortcomings of JavaScript that all these libraries are meant to address would all be moot if .NET and C# were the client-side standard. I understand why this hasn't happened before. .NET was until recently seen as a proprietary Microsoft-only framework. But that's clearly changing. Google, Apple, and Mozilla would just as easily be able to integrate a .NET-based scripting system into their browsers as Microsoft could. There are no patent or royalty issues. Everything that would be needed is open source. Someone just needs to lead the charge. Microsoft lost the browser wars, but that doesn't mean it can't still revolutionize the way web development is done. Heck, even if it only worked on IE and Edge, in the beginning, it would be so attractive that I'd even consider accepting the limitation that my application required those browsers to run. In any event, someone has to be first. Please, for the sake of our sanity - bring C# and .NET to the browser!
Javascript isn't the main problem (I can't believe I just said that.) It's the HTML, CSS, browser incompatibility, and all the cruft you have to add to get SPA's, REST calls, automatic client-side updating (aka SignalR), responsive web (aka auto-save), client-side models, events, etc., all working. OK, .NET could solve some of those problems, but not all. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
-
You double posted this. Please delete the other one. You must've hit some client-side javascript-hell bug... LMAO.
#SupportHeForShe Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
I did indeed! My apologies. :)
-
Umm, there is such a technology, created by Microsoft, actually created by Anders Hejlsberg, the creator of C#. It is called TypeScript[^]. Google ditched their Dart language in favor of Typescript when setting the default for Angular 2. Speaks volumes about the quality of Typescript. Edit: BTW the article you are referencing is typical for the React crowd, which indeed needs to put together a bunch of libraries in order to start developing. Angular 2 is a monolithic framework pretty much everything included, so it doesn't have those problems.
But TypeScript isn't C#... Does it even use .NET?
-
But TypeScript isn't C#... Does it even use .NET?
It is as close as it can get. It is included as a first class language in Visual Studio. It doesn't use the .NET Framework libraries of course since it compiles to JavaScript. Nobody will redesign their browsers to ditch HTML5 Javascript and CSS and switch to WPF. Not even Microsoft. You can even now create WPF apps for browser, however let me tell you a secret. There is a reason why not everybody switched to WPF by now. It is not that good.
-
It is as close as it can get. It is included as a first class language in Visual Studio. It doesn't use the .NET Framework libraries of course since it compiles to JavaScript. Nobody will redesign their browsers to ditch HTML5 Javascript and CSS and switch to WPF. Not even Microsoft. You can even now create WPF apps for browser, however let me tell you a secret. There is a reason why not everybody switched to WPF by now. It is not that good.
How can you create Wpf apps for a browser? Disagree strongly about Wpf not being good - at least on the desktop (non browser) side it is the pinnacle. IMHO of course.
-
How can you create Wpf apps for a browser? Disagree strongly about Wpf not being good - at least on the desktop (non browser) side it is the pinnacle. IMHO of course.
-
It is as close as it can get. It is included as a first class language in Visual Studio. It doesn't use the .NET Framework libraries of course since it compiles to JavaScript. Nobody will redesign their browsers to ditch HTML5 Javascript and CSS and switch to WPF. Not even Microsoft. You can even now create WPF apps for browser, however let me tell you a secret. There is a reason why not everybody switched to WPF by now. It is not that good.
WPF is excellent - if difficult to learn. Also MVVM muddied the waters
-
An open plea to TPTB at Microsoft: Today I read a hilarious, and scarily on-point article courtesy of the CodeProject Daily News, about the chaos that is today's state of client-side web development. As I read it a realization hit me: we need .NET for the browser. With Mono, Roslyn, .NET Core, etc., all coming into their own, there is at this point no longer any good technological or business-related reason why all web browsers, on any platform, cannot be made to run C# code scripts on the client-side, powered by .NET. Sure, there have been efforts to do this before, Silverlight for example. But I'm not talking about just making a browser-hosted shell that is running compiled applications. I'm talking about using C# as a client-side script, powered by .NET Core and Roslyn, to forever replace the hell that is JavaScript and the upteen-zillion libraries and other variants that are built on it. Just imagine how much life would improve for everyone if we could use the same language for both client and server side coding. How much more stability there would be if .NET were the standard for all client-side programming rather than having a new flavor of the month come out every, well, month. As I read that article I realized that so many of the shortcomings of JavaScript that all these libraries are meant to address would all be moot if .NET and C# were the client-side standard. I understand why this hasn't happened before. .NET was until recently seen as a proprietary Microsoft-only framework. But that's clearly changing. Google, Apple, and Mozilla would just as easily be able to integrate a .NET-based scripting system into their browsers as Microsoft could. There are no patent or royalty issues. Everything that would be needed is open source. Someone just needs to lead the charge. Microsoft lost the browser wars, but that doesn't mean it can't still revolutionize the way web development is done. Heck, even if it only worked on IE and Edge, in the beginning, it would be so attractive that I'd even consider accepting the limitation that my application required those browsers to run. In any event, someone has to be first. Please, for the sake of our sanity - bring C# and .NET to the browser!
They could call it something snappy like "ActiveX".
-
An open plea to TPTB at Microsoft: Today I read a hilarious, and scarily on-point article courtesy of the CodeProject Daily News, about the chaos that is today's state of client-side web development. As I read it a realization hit me: we need .NET for the browser. With Mono, Roslyn, .NET Core, etc., all coming into their own, there is at this point no longer any good technological or business-related reason why all web browsers, on any platform, cannot be made to run C# code scripts on the client-side, powered by .NET. Sure, there have been efforts to do this before, Silverlight for example. But I'm not talking about just making a browser-hosted shell that is running compiled applications. I'm talking about using C# as a client-side script, powered by .NET Core and Roslyn, to forever replace the hell that is JavaScript and the upteen-zillion libraries and other variants that are built on it. Just imagine how much life would improve for everyone if we could use the same language for both client and server side coding. How much more stability there would be if .NET were the standard for all client-side programming rather than having a new flavor of the month come out every, well, month. As I read that article I realized that so many of the shortcomings of JavaScript that all these libraries are meant to address would all be moot if .NET and C# were the client-side standard. I understand why this hasn't happened before. .NET was until recently seen as a proprietary Microsoft-only framework. But that's clearly changing. Google, Apple, and Mozilla would just as easily be able to integrate a .NET-based scripting system into their browsers as Microsoft could. There are no patent or royalty issues. Everything that would be needed is open source. Someone just needs to lead the charge. Microsoft lost the browser wars, but that doesn't mean it can't still revolutionize the way web development is done. Heck, even if it only worked on IE and Edge, in the beginning, it would be so attractive that I'd even consider accepting the limitation that my application required those browsers to run. In any event, someone has to be first. Please, for the sake of our sanity - bring C# and .NET to the browser!
Good luck trying to get Apple to accept running .NET in Safari. They seem to actively block progress today, in the much the way MS used to with IE 6. Personally, I think Web Assembly is our best hope here - .NET can compile to Web Assembly, as can any other language.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
An open plea to TPTB at Microsoft: Today I read a hilarious, and scarily on-point article courtesy of the CodeProject Daily News, about the chaos that is today's state of client-side web development. As I read it a realization hit me: we need .NET for the browser. With Mono, Roslyn, .NET Core, etc., all coming into their own, there is at this point no longer any good technological or business-related reason why all web browsers, on any platform, cannot be made to run C# code scripts on the client-side, powered by .NET. Sure, there have been efforts to do this before, Silverlight for example. But I'm not talking about just making a browser-hosted shell that is running compiled applications. I'm talking about using C# as a client-side script, powered by .NET Core and Roslyn, to forever replace the hell that is JavaScript and the upteen-zillion libraries and other variants that are built on it. Just imagine how much life would improve for everyone if we could use the same language for both client and server side coding. How much more stability there would be if .NET were the standard for all client-side programming rather than having a new flavor of the month come out every, well, month. As I read that article I realized that so many of the shortcomings of JavaScript that all these libraries are meant to address would all be moot if .NET and C# were the client-side standard. I understand why this hasn't happened before. .NET was until recently seen as a proprietary Microsoft-only framework. But that's clearly changing. Google, Apple, and Mozilla would just as easily be able to integrate a .NET-based scripting system into their browsers as Microsoft could. There are no patent or royalty issues. Everything that would be needed is open source. Someone just needs to lead the charge. Microsoft lost the browser wars, but that doesn't mean it can't still revolutionize the way web development is done. Heck, even if it only worked on IE and Edge, in the beginning, it would be so attractive that I'd even consider accepting the limitation that my application required those browsers to run. In any event, someone has to be first. Please, for the sake of our sanity - bring C# and .NET to the browser!
Because ActiveX objects were such a good idea the first time around....
"There are three kinds of lies: lies, damned lies and statistics." - Benjamin Disraeli
-
Ohh ok. I thought you were referring to some recent development. Anyway .net/c# and Wpf are not one and the same.
-
Because ActiveX objects were such a good idea the first time around....
"There are three kinds of lies: lies, damned lies and statistics." - Benjamin Disraeli
Did you not read my actual post? I specifically said I did NOT want some kind of compiled extension that is downloaded and runs on the client. I want C# as a scripting language, powered by Roslyn and .net.
-
Did you not read my actual post? I specifically said I did NOT want some kind of compiled extension that is downloaded and runs on the client. I want C# as a scripting language, powered by Roslyn and .net.
Yeah, and ActiveX object hooks were a thing in IE that did not require browser extensions, as they were baked in. You're suggesting that .NET be baked in. It's the same thing. Yes, I read your post. I honestly hoped you were joking: from the level of indignation I'm guessing not.
"There are three kinds of lies: lies, damned lies and statistics." - Benjamin Disraeli
-
An open plea to TPTB at Microsoft: Today I read a hilarious, and scarily on-point article courtesy of the CodeProject Daily News, about the chaos that is today's state of client-side web development. As I read it a realization hit me: we need .NET for the browser. With Mono, Roslyn, .NET Core, etc., all coming into their own, there is at this point no longer any good technological or business-related reason why all web browsers, on any platform, cannot be made to run C# code scripts on the client-side, powered by .NET. Sure, there have been efforts to do this before, Silverlight for example. But I'm not talking about just making a browser-hosted shell that is running compiled applications. I'm talking about using C# as a client-side script, powered by .NET Core and Roslyn, to forever replace the hell that is JavaScript and the upteen-zillion libraries and other variants that are built on it. Just imagine how much life would improve for everyone if we could use the same language for both client and server side coding. How much more stability there would be if .NET were the standard for all client-side programming rather than having a new flavor of the month come out every, well, month. As I read that article I realized that so many of the shortcomings of JavaScript that all these libraries are meant to address would all be moot if .NET and C# were the client-side standard. I understand why this hasn't happened before. .NET was until recently seen as a proprietary Microsoft-only framework. But that's clearly changing. Google, Apple, and Mozilla would just as easily be able to integrate a .NET-based scripting system into their browsers as Microsoft could. There are no patent or royalty issues. Everything that would be needed is open source. Someone just needs to lead the charge. Microsoft lost the browser wars, but that doesn't mean it can't still revolutionize the way web development is done. Heck, even if it only worked on IE and Edge, in the beginning, it would be so attractive that I'd even consider accepting the limitation that my application required those browsers to run. In any event, someone has to be first. Please, for the sake of our sanity - bring C# and .NET to the browser!
-
How can you create Wpf apps for a browser? Disagree strongly about Wpf not being good - at least on the desktop (non browser) side it is the pinnacle. IMHO of course.
-
Yeah, and ActiveX object hooks were a thing in IE that did not require browser extensions, as they were baked in. You're suggesting that .NET be baked in. It's the same thing. Yes, I read your post. I honestly hoped you were joking: from the level of indignation I'm guessing not.
"There are three kinds of lies: lies, damned lies and statistics." - Benjamin Disraeli
It's totally not the same thing. ActiveX controls were compiled, native code modules. If a page used one, you'd be prompted to download the ActiveX control if you didn't have it already, at which point it WOULD basically be a browser extension. (The extension - OCX - originally meant OLE Control Extension, but I believe it was just a DLL). The main reason they were a disaster was because they were unmanaged, insecure, natively compiled extensions; you needed 16-vs-32-vs-64 bit versions; and they were platform dependent. You're right, I'm suggesting that .NET be baked in. .NET is a robust, secure, proven framework for both application and server programming. It is now platform independent and more or less open source. Yes, it would be "baked in" - precisely the same way JavaScript interpreters are "baked in." But the C# scripts for each page would be dynamically compiled to IL on the fly by Roslyn with each page load, and the CLR would execute it. The server could send pages with dynamically generated C# script just as it does now with JavaScript. It would be secure, managed, and wonderfully easy to program. As someone else said, the holy grail. Not even close to ActiveX.
-
You do realize that changing the language running in the browser won't change the (over?) proliferation of libraries. We would just end up with three.net, react.net, redux.net and angular.net.
Good point! But, at least, the .NET framework has a lot more built in functionality so that we would not have to be so dependent on external libraries to do anything interesting.
-
Good luck trying to get Apple to accept running .NET in Safari. They seem to actively block progress today, in the much the way MS used to with IE 6. Personally, I think Web Assembly is our best hope here - .NET can compile to Web Assembly, as can any other language.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Hm. Despite what I said above, I wonder would Apple's involvement be necessary? or Google's or even Microsoft's for that matter? I confess I don't know much of anything about how to build modern browser extensions, but I wonder if it's possible to make browser extensions for all platforms that would be capable of intercepting all the script blocks and hooking into all of the rendered elements on the page. I'm guessing not, but if it were possible, it would be an intriguing project to attempt. Anyway, Mozilla's open source. Take Mozilla + Roslyn + Mono and we'd have a beautiful proof of concept to inspire the others.
-
It's totally not the same thing. ActiveX controls were compiled, native code modules. If a page used one, you'd be prompted to download the ActiveX control if you didn't have it already, at which point it WOULD basically be a browser extension. (The extension - OCX - originally meant OLE Control Extension, but I believe it was just a DLL). The main reason they were a disaster was because they were unmanaged, insecure, natively compiled extensions; you needed 16-vs-32-vs-64 bit versions; and they were platform dependent. You're right, I'm suggesting that .NET be baked in. .NET is a robust, secure, proven framework for both application and server programming. It is now platform independent and more or less open source. Yes, it would be "baked in" - precisely the same way JavaScript interpreters are "baked in." But the C# scripts for each page would be dynamically compiled to IL on the fly by Roslyn with each page load, and the CLR would execute it. The server could send pages with dynamically generated C# script just as it does now with JavaScript. It would be secure, managed, and wonderfully easy to program. As someone else said, the holy grail. Not even close to ActiveX.
Peter Moore - Chicago wrote:
The main reason they were a disaster was because they were unmanaged, insecure, natively compiled extensions; you needed 16-vs-32-vs-64 bit versions; and they were platform dependent.
I wholeheartedly disagree. The primary reason they were a disaster is because they gave native system hooks to mobile code; easy as that. They allowed the bad guys to break the sandbox with little-to-no effort. It had very little to do with the actual downloaded code. I have a better suggestion. Pull down NPM and start writing server-side JS. If you want an end-to-end code solution that's already existing one that doesn't arbitrarily attempt to hand all browser specifications to a for-profit company.
"There are three kinds of lies: lies, damned lies and statistics." - Benjamin Disraeli