Microsoft - Please Bring Order to the Chaos that is Client-Side Web Development!!

[Peter Moore Chicago]

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.

[Peter Moore Chicago]

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.

[Nathan Minier]

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

[Fandango68]

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!

[ngoj]

What chaos? What are you talking about? >> just imagine how much life would improve for everyone if we could use the same language for both client and server side coding Answer is:none, zero!

[Asday]

Funny; I've wanted python as an alternative to JavaScript for a long time...

[rhyous]

Dropping Silverlight was a huge mistake. The adoption was crazy being it wasn't cross platform. Microsoft should reverse course here.

[Member 3051919]

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).

[Theraot]

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[^].

[Leng Vang]

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.

[Andre_Prellwitz]

Not sluggish compared to Java client apps; if you use Visual Studio (since 2010) then you're using WPF.

[Andre_Prellwitz]

Maybe using asm.js, NaCl, or some other intermediary, to get to native code.

[firegryphon]

If I do this, will I also be required to go hunt down Sarah Connor?

[Lost User]

No, we're not :)

Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)

[Daniel Wilianto]

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.

[Peter Moore Chicago]

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 of HelloWorldPage similar to what happens with XAML or the WinForms designer (hence partial 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();