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!
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();