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!
What you're really saying is, "Please bring about a way to stop trial-and-error style developing", which is the "hell" most C# programmers have to contend with, when it comes to having to learn and use JavaScript. The short answer of course is "good luck"! That's why we are paid a tonne of money (ok maybe a little more than average wages) compared to most professions, is because no one, and I mean NO ONE other than a dedicated web or systems development programmer can do what we do. I dare you to ask someone in the street if they've ever heard of C-SHARP, and they'll say yes of course - it's a musical note!
-
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!
-
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!
I think that the Webassembly (You can than develop in C#, Java, whatever has a web assembly compiler) is in the long run the only architechture / endevour that could put an end to that (yes I too consider it to be a) misery. It still has some not yet solved problems (like Garbage Collection, multithreading and more) and the task is daunting. But it is very well under way. If this really is to be more than a good platform for game developers remains to be seen. But as far as I understand the potential is there. Like an ecology of libraries for DOM Manipulation. And Tooling in the Style of WPF/Universal Windows XAML/Java FX: so one easyly develop "Desktop" style apps, that in the end write to the HTML Canvas or so. The implications are vast. And I would really like to see that that pulls of. It is the only concept I know of, that would dispense with the manifold of fundamental problems of the current situation with developing clients for a browser.(Which I have done extensively in the last years).
-
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!
There has been a series of solutions for .NET on the web, those include the infamous Silverlight[^]/Moonlight[^], Unity Web Player[^], JSIL: .NET to Javascript compilation[^], and even an implementation of WPF for JavaScript[^] based on that. What stops JSIL is porting .NET to javascript, if I remember correctly threading and multimedia were particulary problematic - that only bothers you if you want to run .NET apps on JavaScript without modification. The current maintainer said they need funding. Regardless, the implementation is good enough for many solutions, including some games, such as their platforming demo[^]. you try the compilation online in their test page[^]. There was also effort put into running .NET on NaCl. Which is what Bastion used to run on the browser, see How Bastion Can Run in a Web Browser with Google's Native Client - Tested[^].
-
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!
Do you realize what you are asking? Billions of dollars will be needed to rebuild mountains of existing software across multitude of companies just to make developers happy? I guess if Vulcan suddenly come down to visit Earth and money goes the way of the dinosaur, may be.
-
Not sluggish compared to Java client apps; if you use Visual Studio (since 2010) then you're using WPF.
-
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.
Maybe using asm.js, NaCl, or some other intermediary, to get to native code.
-
You have a good point. Here's another idea: One of us needs to grab a time machine and go back in time to the mid 1990's. Invent a technology called "Java Applets" that runs state-of-the-art object-oriented code in the browser. Once everyone realizes how awesome it is, crude hackish Javascript frameworks will never have the chance to rise and turn web development into a mess.
If I do this, will I also be required to go hunt down Sarah Connor?
-
Not sluggish compared to Java client apps; if you use Visual Studio (since 2010) then you're using WPF.
-
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!
I second this. C# is a pleasure to work with. C# 7 is coming our way too. What prevents people from making websites that is pure C#? Why are we stuck with HTML and CSS hell? Why are we stuck with Angular, jQuery, Node.js, React, and thousands of libraries? They gave me headaches... Someone said that it's impossible to do this since people wouldn't want to rewrite billions of websites. Now. Now. Who said that they have to rewrite? Browsers can simply accept a brand new extension for websites. Even now, they accept several extension: html, php, aspx.
-
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!
It looks like there has been a little bit of confusion among some people as to what I'm actually suggesting here. Not suggesting going back to ActiveX or Silverlight, or putting WPF in the browser. Let me give a more concrete example. Consider this extremely simple interactive page:
<html>
<head>
<script>
function onClick() {
main = document.getElementById("_main");
main.innerHTML = "Paragraph changed.";
}
</script>
</head><body>
Hello, world!
<button onclick="onClick()">Try it</button> </body>
</html>
In my brave new world of .NETScript (that's what I just decided to call it :)), you'd do this instead:
<!DOCTYPE html>
<html x:Class="MyApplication.HelloWorldPage">
<head>
<script x:lang="cs">
using System;
using System.NetScript;
public partial class HelloWorldPage : Page
{
public HelloWorldPage()
{
InitializeComponent();
}
private void onClick(object sender, NetScriptEventArgs e)
{
_main.InnerHTML = "Paragraph changed";
}
}
</script>
</head><body>
Hello, world!
<button onclick="onClick">Try it</button> </body>
</html>
What tangible advantages does this bring? First off, we can forever lose
getElementByID
because the scripting engine would be smart enough to expose_main
as a private class member ofHelloWorldPage
similar to what happens with XAML or the WinForms designer (hencepartial class
). Next, we'd get all .NET functionality, including multi-threading capability, for free, e.g., this would be possible:<html x:Class="MyApplication.HelloWorldPage">
<head>
<script x:Lang="cs">
using System;
using System.Threading.Tasks;
using System.NetScript;
namespace MyApplication
{
public partial class HelloWorldPage : Page
{
TimeSpan _timeOpen;
public HelloWorldPage()
{
InitializeComponent();
}
private void onClick(object sender, NetScriptEventArgs e)
{
_main.InnerHTML = "Paragraph changed";
}
private async void onPageLoad (object sender, NetScriptEventArgs e)
{
while (true)
{
_timer.InnerHTML = _timeOpen.ToString();