Microsoft is bringing .NET to Browser based Web Apps with an Experimental Project

[Sniperfox47]

9 minutes ago, AluminiumTech said:

You're assuming people go out of their way to use Javascript and worship it.

I can tell you from experience that JS is only used by a fair few people because they can't use a different language.

Programming in C# is substantially more pleasant than JS. And besides it's probably gonna end up being more performant thanks to WASM.

Well yes but I meant actual C# code and not transpiled code or something like that.

Reread what I said. 3 points, all seperate.

 

1. C# to JS 'transpiling', as you refered to it, was already possible, defeating the "C# is nicer to code' in argument.
2. Running "native" C# code in a web browser means running a VM (the .NET runtime) inside a VM (the WASM runtime) so I don't get how you think that would be faster than straight ASM.js 'transpiled' code. JavaScript, specifically ASM which bridge.NET uses, has seen crazy levels of performance optimization in the past years.
3. So if the issue is with the performance of 'transpiled' C# to JavaScript code and you truly believe that running a VM inside a VM will get you better performance, why not just cut out the middle man and 'transpile' your code straight to WASM and save the extra memory, compilation, and garbage collection overheads of the C# runtime.

[AlTech]

12 minutes ago, Sniperfox47 said:

C# to JS 'transpiling', as you refered to it, was already possible, defeating the "C# is nicer to code' in argument.

JS isn't known for being terribly performant.

Quote

Running "native" C# code in a web browser means running a VM (the .NET runtime) inside a VM (the WASM runtime) so I don't get how you think that would be faster than straight ASM.js 'transpiled' code. JavaScript, specifically ASM which bridge.NET uses, has seen crazy levels of performance optimization in the past years.

No. I think you're mistaken.

 

The compiler for turning C# into Web Assembly is less than a year old (it's just over 6 months old).

 

And Web Assembly is incredibly performant and easily destroys JS in terms of performance.

Quote

So if the issue is with the performance of 'transpiled' C# to JavaScript code and you truly believe that running a VM inside a VM will get you better performance, why not just cut out the middle man and 'transpile' your code straight to WASM and save the extra memory, compilation, and garbage collection overheads of the C# runtime.

We don't know how Web Assembly running .NET in a runtime performs compared to JS.

[Sniperfox47]

2 minutes ago, AluminiumTech said:

JS isn't known for being terribly performant.

Yes. I am aware. That's the whole reason WASM exists.

2 minutes ago, AluminiumTech said:

No. I think you're mistaken.

 

The compiler for turning C# unto Web Assembly is less than a year old (it's just over 6 months old).

 

And Web Assembly is incredibly performant and easily destroys JS in terms of performance.

I am well aware that WASM destroys JS in terms of performance.

 

C# code compiled to WASM is faster than C# code compiled to JS. I never debated that.

 

But my point is also that, at the very least, 'transpiled' WASM will be *way* faster than a full C# runtime stack JIT compiling standard C# bytecode all running on top of WASM, which is what you've made this project out to be so far.

 

6 minutes ago, AluminiumTech said:

We don't know how Web Assembly running .NET in a runtime performs compared to JS.

You're not wrong. We know that WASM running a full runtime stack is faster than JS running a full runtime stack. And you're right that we don't know how a full runtime stack in WASM compares to 'transpiled' JavaScript code.

 

But neither of those are the important point I was getting at. The point is that 'transpiled' WASM code is faster than running a full .net stack on top of WASM and having it JIT 'transpile' the code to WASM and then having to additionally still run that.

[Doobeedoo]

Oh this is neat

[AlTech]

12 minutes ago, Sniperfox47 said:

But my point is also that, at the very least, 'transpiled' WASM will be *way* faster than a full C# runtime stack JIT compiling standard C# bytecode all running on top of WASM, which is what you've made this project out to be so far.

We don't know.

[LAwLz]

Wait... Why?

Won't this just add a bunch of overhead compared to other solutions not only performance wise (since .NET is JIT and has to be translated from .NET assembly to machine code, and runs inside a virtual machine) but also size wise (since you have to send over the .NET runtimes along with the code in order to get it working).

I don't see the point.

[dfsdfgfkjsefoiqzemnd]

Hang on ... does this mean we need to put that .NET garbage on our Linux machines too? 

[Guest]

1 minute ago, Captain Chaos said:

Hang on ... does this mean we need to put that .NET garbage on our Linux machines too? 

No, all you need is a browser that supports wasm (Most modern browsers by now?)

[leadeater]

6 hours ago, GoodBytes said:

Yes, but JavaScript is not Java. Beside the name "Java" in the name, and being both programming languages, they are not related. They are different languages.

I know they are different, was just naming something that is actually annoying and horrible most of the time .

[leadeater]

6 hours ago, AluminiumTech said:

I'm gonna go out on a limb here and guess that it's the PaperMF client.

Actually no, PaperCut is nice though and far less broken than the one I'm referring to.

[Sniperfox47]

8 hours ago, Captain Chaos said:

Hang on ... does this mean we need to put that .NET garbage on our Linux machines too? 

If you have anything with mono as a dependency, you already have that

[yian88]

its microsoft tecchnology so it must not be good , keep javascript