Is MS building a C# on JavaScript runtime?
zdnet.com
zdnet.com
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?
[1] http://gotocon.com/aarhus-2012/presentation/Closing%20Keynot...
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.
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.
research.microsoft.com/~emeijer/papers/es012-meijer.pdf
LINQ is based in Monads.
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.
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.
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'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.
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.
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!
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.
[1] An older HN thread brought up some of these concerns: http://news.ycombinator.com/item?id=2876282 with naclbox.com.
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.
http://msdn.microsoft.com/en-us/library/windows/apps/br21137...
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.
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.)
http://msdn.microsoft.com/en-us/library/6t9t5wcf%28v=vs.80%2...
I meant a way to convert the application to binary that you can distribute without having a CLR VM installed.
We deploy 4.0 framework with our desktop software as well. ClickOnce takes care of the installation with the package manifest.
Github also do that with their GitHub for Windows app.
Maybe it would be enough to make NGEN more configurable, on the other hand I am yet to check the 4.5 improvements.
Ngen is unchanged in 4.5. There were a few big changes in 4.0.
http://msdn.microsoft.com/en-us/magazine/hh882452.aspx
I just have not had yet the opportunity to research this myself.
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 :)
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.