Live data from Hacker News

Mono and WebAssembly – Updates on Static Compilation

mono-project.com

11–20 of 47 posts

Re: Mono and WebAssembly – Updates on Static Compilation

#11

Earlier quoted context omitted.

Edit : I misread this article. Neiter of the projects i mentioned target webassembly. But CoreRT could one day. Microsoft has two similar projects: CoreRT : Which is a managed re-implementation of the CLR allowing for AoT compilation. LLILC : A LLVM Backend for .NET MSIL. (Stalled) https://github.com/dotnet/corert https://github.com/dotnet/llilc

CoreRT's WASM support is being worked on: https://github.com/dotnet/corert/tree/master/src/ILCompiler.... There are some instructions here: https://github.com/dotnet/corert/blob/master/Documentation/h...

Very cool! It seems I was more correct than I thought.

Re: Mono and WebAssembly – Updates on Static Compilation

#13
post #4

Has anyone heard about Microsoft working on a similar project? The proof of concept last summer seemed to have raised a lot of interest among Microsoft people. I hope they take that route.

Blazor is an experimental web UI framework using C#/Razor and HTML, running client-side via WebAssembly.

Blazor : https://github.com/SteveSanderson/Blazor

Re: Mono and WebAssembly – Updates on Static Compilation

#14
post #2

Does anyone know if there is work being done to add JSX syntax to C# (either into the language directly or as part of a pre-processor)?

Why would you pick jsx instead of TSX?

JSX is the the syntax for embedding HTML in a non-HTML language. TSX is just a file extension implying that the non-HTML language is typescript, which it wouldn’t be here because C#.

Re: Mono and WebAssembly – Updates on Static Compilation

#15
post #9
post #2

Does anyone know if there is work being done to add JSX syntax to C# (either into the language directly or as part of a pre-processor)?

The CSharpLang github[1] repository would be where to look for this. I didn't find anything that mentioned adding language support for it, and IIRC, in the past they rejected the idea of inline XML or JSON support. Going the other way of C# inside HTML, you have Razor[2] and Blazor[3], the latter of which is a prototype of Razor running in the browser via web assembly. [1]: https://github.com/dotnet/csharplang [2]: h…

Blazor is pretty amazing, but my coder fantasies mostly revolve around a React-JSX-in-C# vision - the syntax and approach just feel so natural and so right. Your point about rejecting inline XML is probably a pretty good data point that I shouldn’t expect what I’m hoping for to happen.

Re: Mono and WebAssembly – Updates on Static Compilation

#17
post #2

Does anyone know if there is work being done to add JSX syntax to C# (either into the language directly or as part of a pre-processor)?

Investigate a possibility to support JSX | https://github.com/bridgedotnet/Bridge/issues/808

Bridge.NET translates C# to JavaScript, but JSX is not currently supported.

Re: Mono and WebAssembly – Updates on Static Compilation

#18
I've always envied the JVM's class reloading abilities. Edit-n-continue in Visual Studio has so many "it doesn't work if you do this" cases, that's it next to useless.

I would love to be able to put the C# debugger into interpreter mode and be able to change anything, anywhere while debugging and keep on trucking without having to stop debugger, make changes, restart debugger, etc..

Re: Mono and WebAssembly – Updates on Static Compilation

#19
post #17
post #2

Does anyone know if there is work being done to add JSX syntax to C# (either into the language directly or as part of a pre-processor)?

Investigate a possibility to support JSX | https://github.com/bridgedotnet/Bridge/issues/808 Bridge.NET translates C# to JavaScript, but JSX is not currently supported.

I like Bridge.NET but I’m not sure how they will survive once the current Mono WebAssembly tech hits release.

Re: Mono and WebAssembly – Updates on Static Compilation

#20
post #18

I've always envied the JVM's class reloading abilities. Edit-n-continue in Visual Studio has so many "it doesn't work if you do this" cases, that's it next to useless. I would love to be able to put the C# debugger into interpreter mode and be able to change anything, anywhere while debugging and keep on trucking without having to stop debugger, make changes, restart debugger, etc..

Even the JVM has a fair number of issues if you use class reloading to do Weird Stuff (tm), especially with advanced debugger tricks added into the mix. That's one of the reasons some of the folks I know who use Scala switched in the first place.

I think any hot-reloading solution for a big, complex, introspective/reflective language is going to have some warts* and places where it stops working in some scenarios. The trick is just to minimize those to where they don't get on your nerves on a daily basis. C# will hopefully get there soon.

* Unless, that is the language is designed from the ground up to support code reloading. Erlang/Elixir's runtime inspection/injection/behavior alteration capability is second to none, and largely replaces the role of a true/traditional debugger. And you can do other cool stuff with it like zero-downtime in-place deployments, though that doesn't exactly come for free.

Post reply on HN