This title is greatly misleading. The article (nor what it's talking about) has nothing to do with a "C# on Javascript" runtime, and that would be ludicrous. Anders is a language designer, so it makes a lot of sense he would use his knowledge to help improve language support for the next big thing. C# has matured; Javascript can still use some work.
Agreed - the real news here is that Anders Hejlsberg is doing something that not only isn't C#, but is JS-related. Surprising, and therefore immediately interesting.
Where's that headline changing mod, when you need him? ;)
At Goto in Aarus [1] Anders is giving a keynote on "A yet to be disclosed project in the Development Tools space".
Sometime in the last 2 days this page [1] changed. It previously listed a co-presenter with Anders from the Chakra JavaScript team.
Not sure why the other presenter (can't remember his name) was removed; it could be as simple as he can't make the trip. Or Microsoft was afraid of letting the cat out of the bag too early?
Oddly ms already has/had some sort of 'compiler'. Memory is fuzzy on it, internal use and only used to build one thing, libs for messenger in browser I think.
You're thinking of Script# (http://scriptsharp.com/) and it's used at the very least to develop the Office web apps as well as Exchange's Outlook Web Access.
I'd suspect they have several tools like this for code portability. It's relatively trivial to make a simple translator that compiles to Javascript; take CoffeeScript for example. I'd be surprised if there weren't all sorts of tools like these floating around Redmond. The notion of a "runtime" sitting on top of Javascript? That doesn't even make sense. It would also be a waste of Anders's strengths. His strength is in taking something popular and making it modern and usable (e.g. Java -> C#). Coming from him, I'd expect more along the lines of a framework or language extension or ECMA contribution than a runtime or compiler.
Basically, you could write C# and mark different segments of the code as being server side and client side. the client side code would be compiled to JavaScript and run in the browser ... and you got full debug support across tiers with the original uncompiled C# source.
Erik Meijer has — for sometime now — advocated treating Javascript as a target language.
This fact would be unremarkable except that a few years ago he advocated bringing functional programming to the .NET platform and we ended up with LINQ.
I LOVE C#... its a really great language. I use it every day, and have been doing so for the past 4 years. But the thought of "Microsoft Javascript" scares the shit out of me.
"Microsoft could potentially add some new, interesting features to the JavaScript standard"....
Scary! Don't do it Microsoft—don't screw this up again. We spent ten years dealing with your "add some new, interesting features to the ??? standard," and we won't tolerate ten more. Standards are there for a reason. Do as you will, but don't break compatibility with the greater web.
They did invent Ajax (AFAIK). So it's not all bad.
And IIRC Canvas was in Safari before it became standard (it is now right?).
I don't think vendor specific extensions are necessarily a bad thing. The bigger issue with IE was just that it stagnated so long. If the IE6 to IE10 cycle, which happened over just a few years, would have happened when it should of, I don't think we'd have nearly as much to complain about when it came to browsers.
The Java situation was a bit different I guess, but honestly that may have a lot more to do with the state of non-MS platforms not really having an analogue to the J/Direct and RNI stuff? Wasn't really into Java at the time so I dunno if that's fair or not.
> They did invent Ajax (AFAIK). So it's not all bad.
May be true—but the mechanism for XMLHTTPRequest (and async requests in general, through iframes or other ways) was around far before anyone had the bright idea to do anything with it, so it was more of a stroke of luck.
I think you misread me. They (AFAIK) invented the first XmlHttpRequest implementation years before anyone else. In fact, there's comments/submissions on this site describing developer experiences with AJAX on IE before anyone called it that.
I'm not claiming MS coined the term AJAX. They didn't. I am claiming some bright people there saw the potential in it years before anyone else, and then released an actual implementation you could use.
No idea who that was, if it was a lone shark sneaking it into the system, or if it was a team/management effort that saw the potential in the idea and ran with it, but that person deserves a cookie.
Erm Microsoft added a lot of good stuff over the years and provide a hell of a lot of test cases for HTML5. They are also conservative about adding features and when they do, they work.
Chrome is far more worrying, especially with things like NaCl, store front and various far future standards being implemented without proper consultation and ratification with othe vendors.
I'm not really sure why your comment was down voted, it seems like a reasonable question to me. Just because something is open source doesn't automatically make it better (or worse) than a proprietary (in the sense of closed source) solution [1].
But if it isn't adopted by all of the __other__ browsers, then you're back to the same situation of having a fragmented browser experience, reminiscent of the "best viewed in Browser X" issues, some of which continue to plague developers today.
I think it's legitimate, at least for some concerns, to compare NaCL to ActiveX, and be mindful of these concerns so that NaCL does not repeat some of the mistakes of ActiveX.
It's about the same, but everyone including Microsoft doesn't push ActiveX any more or that model as they admit that it's bad.
Google are pushing it into Chrome as if it's the second coming.
Also, fun facts: ActiveX was always an open well documented specification (based on COM) and was cross platform. It even worked on Solaris and HPUX with IE4 and on NT/MIPS!
I'm surprised no one has mentioned it yet, but it's my understanding that NaCl whitelists native instructions, whereas ActiveX is pure native that didn't run through any security hoops. Implication: NaCl is supposedly more secure.
One of the big things they seem to be pushing is the windows 8 store, and one of the platforms they offer is HTML and Javascript. To that end they have a large javascript api library of calls that seems to match the c++/C# ones...
I don't know if these libraries would work outside the ms store environment.
The whole thing reminds me a little of OSX dashboard widgets, but html/javascript have come a long way since then.
It would make sense for Microsoft to invest in tools to run C# or .NET code in general in JavaScript, because letting people use Microsoft dev tools that they are familiar with (Visual Studio) + letting them generate code that runs on the web without plugins = win.
There are already some tools for this, Script# from Microsoft, JSIL and so forth. Would be nice if Microsoft decided to officially support this approach with something very robust.
ngen isn't really an AOT compiler so much as an "ahead of just in time" compiler. You use it to run the JIT compiler and have Windows cache the output so that it can be reused instead of regenerated every time the program is run. Compared to a real AOT, it has several technical limitations, including:
1. You can't distribute native code. The usual workflow is that you deploy bytecode assemblies, and run ngen during installation to get the machine code into the local machine's native image cache.
2. You're still dealing with a two-phase compilation. This implications for what kinds of compiler optimizations are possible.
3. For the paranoid, having to still distribute bytecode means that your binaries are still easy to decompile.
On the other hand, it also has some technical advantages. Generating machine code on the client machine makes more processor-specific optimizations possible, for example. And keeping JIT compilation in the loop means that you can still support features like Reflection.Emit().
1. I don't want to distribute native code and I do run ngen during installation. I don't want an entire configuration and toolchain for each assembly and target platform (x86/x64/ARM RT/ARM WP/Silverlight) for example which we deploy one shared assembly to. It's hassle. The CLR is a virtual machine and one of the important things is that this problem goes away.
2. I would rather the compiler decides the optimisation for me. I really don't want to deal with that side of things. What I want is something that makes the problem go away which it does and let me deal with writing code rather than playing with compiler flags (I did a fair bit of VC++ and the CL.exe compiler optimisation options are crazy complicated).
3. I'm not too fussed about bytecode decompilation as most of our logic is server-side :)
Yeah, and for server-side I think ngen is the way to go - then you're really just looking for a way to shorten startup time, and that's perfect.
But for something like mobile devices or video games, being able to do a real AOT compilation becomes a lot more interesting. You've only got one or two target platforms to worry about, which mitigates the concern about dealing with different build configurations. And you're dealing with an area that's more constrained in both space and speed, so there's more to be gained from some of the more tenacious optimizations that a C++-type compiler might do.
Yup, and Xamarin's put it to great use on mobile devices.
Incidentally, Microsoft's got their own line of mobile devices that run their own implementation of .NET which doesn't currently support real AOT compiling. (Just ngen.)
