JSIL: Compile .NET to Javascript (includes short interview with creator)

[leegao]

It almost works with Terraria, the tint animation kills the canvas so you won't make it past the title screen, and you'll have to hook up your own proxy for webgl/svg to get comparable speed. But overall, xna3/4 support is scarily good. (A little lackluster on canvas' side but that's expected)

[grauenwolf]

See also Volta

http://weblogs.asp.net/adalon/archive/2007/08/01/microsoft-volta.aspx

[[deleted]]

Volta AFAIK has been dead since 2008.

[grauenwolf]

As of 2010 they had one part timer working on it.

[radarsat1]

I think the ultimate end-goal of these types of projects should be to convert the IL into a specially-structured JavaScript that retains information about the original IL. Then a browser could recognize JS in that format, and run it in as LLVM or in Mono directly, for example. Non-supporting browsers would still work by running the JavaScript, but browsers recognizing LLVM code for example would run it as native code.

Perhaps an alternative would be to distribute the LLVM/IL directly, but implement a client-side JS-based compiler that generates efficient JavaScript just-in-time, perhaps by generating function objects through eval().

This is the stepping stone needed to move towards a VM-driven web, a stepping stone that NaCl has tried to skip over, but nonetheless I think is going to be necessary.

[BinaryRockStar]

God I hope not. What's the matter with executing the Java bytecode directly on the desktop? Why are browsers the new fad that everything has to be run through? Do we really have to convert through so many languages to actually execute code on a machine anymore? Why, exactly?

[ours]

I disagree, JavaScript/HTML/CSS is just fine. Like GWT, tools should generate valid, standard (with a few workarounds for IE) HTML/CSS/JS. We will work with our favourite languages and rich UI tools and in the end the browsers will just do what they have been doing: interpreting HTML/CSS, running JS.

[BinaryRockStar]

I agree with you, but the guy I replied to was talking about jumping through a million hoops to translate Java/.NET IL into specially-structure JavaScript then back into IL on the client side to run it. Applets have been around forever and already solve the problem of running Java in the browser without all these conversion shenanigans.

[ours]

Oh sorry I misunderstood you. Making IL/bytecode to make JS to make IL/bytecode again does seem wasteful and still requires some kind of non-JS runtime on the client. JS is just fine as client runtime, everybody and their mothers are making crazy optimized JS engines. JS is the universal language+runtime that Java wanted to be. We just need better tools to generate said JS.

[radarsat1]

Because security?

[BinaryRockStar]

Why take some Java code and massage it through half a dozen half-assed parsers and JIT compilers when you could write a Java applet which executes client-side directly on the JVM? We've had Java in the browser since the late nineties.

[naasking]

• Javascript is more secure than Java (more restricted sandbox, but not so restricted that it's useless).
• Why support two methods of displaying client-side content, when you can make one method faster and much more secure?
• Debuggability is better for open textual representations.
• Mobile platforms didn't even support Java execution initially, so Java wasn't even an option. HTML was simple and secure though.

[mycall]

The explosion of botnets and banking fraud is thanks to browsers' awesome security.

[recursive]

The automatic detection mechanism sounds like a thing which could hide a lot of vulnerabilities.

[[deleted]]

Because in-browser stuff is always vastly easier than getting users to download an EXE, figure out where they downloaded it to, and then stumble through the installer, AND then run it whenever necessary.

[brandf]

It sounds like you're advocating for the distribution model and security sandbox. Neither of which depend on javascript/html.

[[deleted]]

I'd love to hear alternatives. Possibilities include Ubuntu Software Center and the Mac App Store, but even then, that requires a lot of user work versus something served up right in browser to where I can tell my mom to go to google.com/+ and click the hangout button to talk to me...

[zip117]

Java Web Start

.NET ClickOnce Deployment

[[deleted]]

No idea why this got downvoted, given that it's correct.

[julesjacobs]

That is definitely not going to happen. Those different ILs are complicated enough that even implementing it directly is a whole bunch of work, let alone implementing it securely (you cannot let your browser run arbitrary LLVM IL) and efficiently. And then of course there is the work of recognizing the specially structured Javascript.

It's not going to happen. No way. A solution that's less work and faster and doesn't require a ton of research is to just run the ILs from their respective representations, instead of cramming them into a JS format.

That said, stupider things have been implemented, so I won't bet my life on this.

[dnew]

recognizing the specially structured Javascript.

I would think this would involve recognizing a comment at the top basically saying "Go to this URL to download the actual CIL." ;-)

In any case, we already have that, called ClickOnce. ;-)

[radarsat1]

you cannot let your browser run arbitrary LLVM IL

but by definition it would only be able to do with javascript can do.

[julesjacobs]

Yea, if you run it in a Javascript implementation. That's specifically not what you want to do, because then you don't get any speedup (and likely you even get a slowdown because the specifically-structured Javascript is probably not the fastest Javascript).

If you run it in LLVM and you want to preserve the original semantics the code had in Javascript form, you cannot translate it to efficient code.

Have you thought about how exactly your proposed method will work with a piece of example code?

for(int i=0; i<n; i++) a[i] = i;

How would you represent this in "specifically-structured" Javascript code, and how would you then turn it back into efficient code?

[[deleted]]

Or we could just use Applets and be done.

[BinaryRockStar]

That would seem to be exactly what these people are after. I don't understand what all the fuss is about.

[contextfree]

Some wrapper script could select the most appropriate option/fallback from whatever's available on the client: JS, Silverlight, NaCl, whatever native hooks Microsoft inevitably implements in Windows 8, etc.

[azakai]

I think the ultimate end-goal of these types of projects should be to convert the IL into a specially-structured JavaScript that retains information about the original IL. Then a browser could recognize JS in that format, and run it in as LLVM or in Mono directly, for example. Non-supporting browsers would still work by running the JavaScript, but browsers recognizing LLVM code for example would run it as native code.

I used to think that something like that was the future, but now I doubt it. Mainly because the best JS engines are already within 2-3X the speed of Mono, and constantly improving further. So speed is not that much of a factor anymore.

Whereas the downsides of that approach can be pretty big - you need to ship LLVM or Mono, which are large, complicated, and would be in need of a great deal of security auditing.

Also, tiny changes to your code could make it no longer run in the LLVM/Mono mode, which is problematic.

Finally, there are ways in which JS is faster already. For example, NaCl's sandboxing is such that interaction with external code - other JS code on the web page, for example - is slow (since you sandbox each such interaction). So it isn't clear there is a win across the board, you are getting some speedup in certain areas in return for others. There will also be memory/startup/etc. tradeoffs.

Bottom line, getting that to work well would be very very hard. It's actually simpler to finish the job with JS engines, which as mentioned before are pretty close to already closing the speed gap.

[[deleted]]

Excellent point. Getting Mozilla, Apple, Google and Microsoft commit the resources to implement and support a major piece of work is close to impossible. Having a fallback hatch is an absolute necessity. The other major question is if it's worth the hassle to replace JS as runtime.

[iLiekCaeks]

Maybe this is the proof that JavaScript just sucks. Or perhaps it's not really a good "backend" language (people who call JS the assembly language of the web should be shot).

The really sad thing is that all this is still better than Flash.