System libraries support level about jsil

[kg]

How, specifically, would this issue be resolved?

[adontz]

Probably adding a Wiki page with list of supported APIs will be a good start point.

As the next step, while assembly decompiling is already present in project, it seems reasonable to provide some migration analysis tool (just like MoMA for Mono) which will analyze assemblies against unsupported API calls. Maybe this can be implemented like an extension for existing analysis tool, like FxCop.

Maybe it will be a good idea (I'm really not sure) to implement some Windows.Forms compatibility layer, built on top of some JavaScript UI framework. And vice versa, provide fake WinForms controls to be mapped to real JS ones, to draw on canvas and so on.

Referencing XML/SOAP web-services (ASMX/WCF) is also very-very interesting. LINQ is not must have, but it will be cool to have LINQ: linq2xml and linq2objects.

It seems very promising to debug all business logic with strongly types language like C#, with powerful IDE like VS. I'm not a JS expert, so this project looks very promising for me :-)

[kg]

Supporting the full set of .NET libraries is not directly in scope for JSIL, actually, though I can see how you got that impression. Perhaps it would be best to clarify this in the documentation.

Right now the set of JS 'stubs' provided exists merely so that the compiler itself can be tested. In practice I may continue expanding the stubs, but it's equally likely that I will investigate alternate solutions - for example, having you compile the Mono version of mscorlib, and then translate that to .js files alongside your application. In that case, the feature support would not be directly part of JSIL.

I will also note that if you generate 'stubs' for your libraries, you automatically get warnings about uses of any methods that haven't been implemented when running the output javascript. You can see this in the live demos, since my stubs only implement a small set of methods/properties.

[adontz]

I do not think there is a need to support full set of libraries. I see this project as a better way to write 3-tier applications with JavaScript/WebBrowser as a rich, but still thin, client tier. A lot of logic, like data validation, is duplicated in client and server, so this approach may help in DRY. So, it looks more realistic to talk about just some part of client being generated from .Net assembly, not whole one.

[jtrana]

I rather agree with the bit about supporting the full set of libraries. Porting all of mscorlib, for example, may prove very heavy. Not only that, but there will always be questions about "Why doesn't this work like I expect? Is feature X supported?" When I think about using JSILc, I think about having a few core pieces of functionality that I can port over into the web: basic C# syntax (so IEnumerable, etc. for baked in interfaces), string manipulation (also possible w/o "using System" - how core are strings?), arrays, List, and Dictionary<K,T>. Beyond that, I don't think a whole lot more should come in the starter libs and I think the starter libs should have different namespaces. What's your take on that?
Personally, my ultimate goal is not to port existing .NET apps to the web as-is, but to provide a solid OO base for coding on the web and still use a server backend to do the heavy work. Security always has to be server side, so the amount that can stay client side in most practical code bases (IMO) doesn't go that far beyond the UI layer; games are a different matter but I'd be willing to have a restricted library if it guaranteed portability.

[kg]

Types like String, List, Dictionary, and Array are definitely considered 'core', so I intend to support apps that use them, either through providing full implementations in Bootstrap or by making it possible to translate Mono's implementation (in the case of List/Dictionary).

[adontz]

IMHO, if we're talking about developing UI, binding infrastructure is must have too.

[kg]

I've never used any of the stock binding systems. Are you referring to WPF's?

[adontz]

No, I mean observable model: INotifyProperyChanging, INotifyProperyChanged, IBindingList, INotifyCollectionChanged, ICancelAddNew, IRaiseItemChangedEvents.

[jtrana]

WPF does hook into the observable model interfaces, but supplies its own binding implementations. I think semantically the binding may work a little differently if the binding exists across the network. If it exists solely client side, then yeah, they'd probably work fine but once you go over the intarwebs I think the usual threading model inherent in those (at least in WPF+UI thread land) may break down. Maybe I'm the only one wanting to do view models on the server, if so, ignore me...

I guess that brings up a good question: what is the end goal of this framework?
#1 Client side only JS translated from .NET, no specified UI framework
#2 Client side only JS translated from .NET, stock UI framework targeting some web standard
#3 Client side JS + server side C# and some stock communication mechanisms.
#4 Client side JS + server side C#, stock communication, stock UI on client + bindings

... or some combination of the above, etc.

Kevin, it sounds like #1 was much more of your original design but the demos you're putting out seem like you've definitely toyed around with #2. I think if #3+ were ever hit, it could very much change the way web apps are developed today for not only standalone apps but also for full-fledged business apps etc.

[markusjohnsson]

I want to throw in my five cents here.. I think it would be wise to keep JSIL as compiler/translator+runtime (#1 by jtrana, above) only and build a UI framework as a separate project with JSIL as a dependency. That way, if one UI approach does not take off, there might be another that does and JSIL won't get bad rep for the fail.

Regarding libraries, I would think that translating mono assemblies to js is the way to go. But there are probably several types that need to exist in the runtime, and not be compiled from those assemblies.

Anyway, this is a fun project, have been playing with it over the weekend and I think I will continue to do so and contribute code too.

[markusjohnsson]

kevingadd: on the subject of translating mono assemblies, have you given it more though?

I want to give it a try, but I'm stuck at how to organize the code from the two projects:

• Should mono be added as a submodule to JSIL?
• Should we fork mono so that we can use the mono build scripts and add JSIL specific code to framework classes?
• Should we do this in a separate project/repository independent from both JSIL and mono?

It would also be nice to have NUnit running on JSIL so that we can run mono's test suite..

[kg]

The current biggest obstacle to using the Mono mscorlib is that it doesn't translate into fully working code yet. I have some improvements into the pipeline that should fix that, but they aren't ready.

Edit: Running NUnit inside JSIL is unlikely to happen; NUnit relies on threads and appdomains, and neither of those features are feasible to translate to JS.

[markusjohnsson]

Oh, of course, never thought it would be translatable at this point. My plan was to get a build going to help find test-cases where JSIL need improvements.

On NUnit: ok, running NUnit is probably not doable, but perhaps a subset, like most of Assert.*?

[markusjohnsson]

For anyone interested, my work on building a mono-based corlib with jsil can be found in my fork (github.com/markusjohnsson/JSIL), in the branch jsil_corlib.

Right now, a small subset of the corlib compiles (using VS) and translates (using JSIL), but it crashes during load for various reasons. I will file separate issues for those problems.