Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New C# to Javascript compiler released

erik-kallen.se

Post reply on HN
Print view View original

71–80 of 81 posts

Re: New C# to Javascript compiler released

#71

Post by randomfool »

eckyptang wrote: post #45
Kototama wrote: post #11

Earlier quoted context omitted.

Maybe that's where source maps come handy? http://www.html5rocks.com/en/tutorials/developertools/source...

This sounds like a solution to a problem that probably shouldn't exist because there is a solution that shouldn't exist to start with which has caused a problem that doesn't need to occur. The slightly overbearing complexity of the solution matches the linguistic complexity of the statement above :)

I don't see how these are significantly different than .PDBs which allow Windows developers to step through their source code when debugging compiled binaries.

Re: New C# to Javascript compiler released

#72

Post by randomfool »

My largest criticism for projects like this is that I absolutely abhor running into compiler errors. When you don't fully trust the compiler, it suddenly becomes a suspect when code isn't working like you think it should.

Given decent source maps to allow debugging through the original code, I don't think solutions like this are terribly different than native Javascript. The primary difference though is that I trust the browser JS interpreters and VMs more than I trust many X->JS compilers.

Re: New C# to Javascript compiler released

#73

Post by erik-kallen »

azakai wrote: post #64
erik-kallen wrote: post #30

Earlier quoted context omitted.

JSIL is also great, but its philosophy is that yo write .net code and run it in the browser, whereas Saltarelle's (and Script#'s) is that you write Javascript but with better tools. Also, the script that JSIL generates is very far from what you would write by hand, whereas that generated by Saltarelle/Script# can be distinguished from hand-written script primarily because the indentation is always correct and there i…

Could you not somehow reuse the JSIL code generator, and add things for the approach you took in Saltarelle (good integration with JQuery etc.)? Another question, did you do any performance comparisons of Saltarelle? (to normal C# builds, to JSIL, or anything else?)

I think the tools fill different purposes, so integration with JSIL is absolutely a possibility in the future. I did not do any speed comparisons, I just translate what you write in C# to the equivalent script, so if you write a fast script it will be fast, if you write a slow script, it will be slow :)

Re: New C# to Javascript compiler released

#74

Post by michaelwww »

bdfh42 wrote: post #28
WayneDB wrote: post #16

Earlier quoted context omitted.

I don't see the problem. - If I had written Javascript, I would have to debug the Javascript that is running in the browser. - If a tool writes Javascript for me, I have to debug Javascript running in the browser. A better wish would be: I hope that your tool outputs nicely formatted and easy to debug Javascript.

But it will not write JavaScript the way you would write it - and (avoiding arguments about personality in code) that JavaScript will be way harder to follow and debug.

It's likely there would be less need for JavaScript debugging.

Re: New C# to Javascript compiler released

#75

Post by azakai »

erik-kallen wrote: post #73
azakai wrote: post #64

Earlier quoted context omitted.

Could you not somehow reuse the JSIL code generator, and add things for the approach you took in Saltarelle (good integration with JQuery etc.)? Another question, did you do any performance comparisons of Saltarelle? (to normal C# builds, to JSIL, or anything else?)

I think the tools fill different purposes, so integration with JSIL is absolutely a possibility in the future. I did not do any speed comparisons, I just translate what you write in C# to the equivalent script, so if you write a fast script it will be fast, if you write a slow script, it will be slow :)

Well, how you create data structures might matter for performance - if you turn C# structs into JS typed arrays for example and do the proper conversions, that could be much faster than simple JS objects or even arrays.

Re: New C# to Javascript compiler released

#76

Post by michaelwww »

skrebbel wrote: post #63

As I see the author reads these comments, I'd just like to add that this makes me very excited. C# is my favourite language by far, combining some of the most powerful (mainstream) language features with some of the most powerful dev tools out there. Having the ability to run the same code in the browser and on the server, in C# , is really a big thing for me. I think the debugging problem stated in many comments her…

After the initial curve of getting VC10 configured right, I did an inheritance test. It worked (copied base class prototype, called base constructor with this.) Minutes later I was happily converting C# code to nicely formatted JavaScript. Having spent the last two weeks converting JS to Dart (basically a one way process because you don't want to look at Dart->JS), I'd say this project is a winner and immediately usable. I'm positive there are C# features and libraries that don't convert well, or at all, but I'm not interested in those in the browser any way.

Re: New C# to Javascript compiler released

#78

Post by eckyptang »

randomfool wrote: post #71
eckyptang wrote: post #45

Earlier quoted context omitted.

This sounds like a solution to a problem that probably shouldn't exist because there is a solution that shouldn't exist to start with which has caused a problem that doesn't need to occur. The slightly overbearing complexity of the solution matches the linguistic complexity of the statement above :)

I don't see how these are significantly different than .PDBs which allow Windows developers to step through their source code when debugging compiled binaries.

It is similar to PDB files, which is fine but that is not the issue. The issue is that the abstraction is criminally tall. We're talking a tower of:

Process: C# --(compiler)--> Js --(parser)--> IL --(compiler)--> machine code/interpreter.

Type conversions: Static --> dynamic --> static --> none.

That's just too much to go wrong in my mind. I wouldn't touch it with a barge pole.

Re: New C# to Javascript compiler released

#79

Post by hpguy »

Fizzer wrote: post #47

Looks impressive! I'm curious how you're doing the parsing. I see that you reference both NRefactory (which reads C#) and Cecil (which reads IL) -- can you talk about how are each of these used and how you combine them? Also, did you consider using Roslyn (Microsoft's official C# parser)? Obviously it's still beta, but once it's complete would it remove the need for Cecil and NRefactory completely?

NRefactory itself depends on Cecil, so his translator might not use Cecil at all.

Re: New C# to Javascript compiler released

#80

Post by eranation »

randomfool wrote: post #70
DougWebb wrote: post #57

Earlier quoted context omitted.

I hear you, but I can't agree. Maybe it's my background. For 13 years as a professional developer my primary languages were Perl and Javascript, using Vim and the Unix command-line as my IDE. For the past 1.5 years I've swapped C# for Perl and Visual Studio for my IDE (still have a vi emulator though.) Intellisense is definitely useful, but I find it gets in the way a lot... both literally by overlapping the code aro…

For statically typing Javascript, I strongly recommend Google's Closure toolset- it uses JS comments to statically type and validate your code, plus you can either run it compiled or uncompiled. https://developers.google.com/closure/ There are no editors that give you the nice intellisense bells and whistles, but static typing is by far the most important for me.

There were tools ones in eclipse that used comments / annotations to give you full "static" feeling with JavaScript... I wonder where did it go...

Here is a nice side project, static typed coffee script, with eclipse IDE support...

I really don't want to go back to GWT or move to Dart...

Scala's Javascript DSL is another hope I have, but it's still under development

Post reply on HN