Live data from Hacker News

New C# to Javascript compiler released

erik-kallen.se

31–40 of 81 posts

Re: New C# to Javascript compiler released

#31
post #18

Thanks Erik! I haven't touched Script# due to the fact that development stalled and it (was) closed source. Looking forward to seeing how this performs.

Script# is alive and well AFAIK. It is hosted on github, with about 9 commits from the primary author in the last week.

https://github.com/nikhilk/scriptsharp/commits/master

Re: New C# to Javascript compiler released

#32
post #18

Thanks Erik! I haven't touched Script# due to the fact that development stalled and it (was) closed source. Looking forward to seeing how this performs.

Script# is alive and well AFAIK. It is hosted on github, with about 9 commits from the primary author in the last week. https://github.com/nikhilk/scriptsharp/commits/master

But all those commits are, unfortunately, tiny. Also the compiler is not open-source only the runtime library (which Saltarelle uses a modified copy of).

Re: New C# to Javascript compiler released

#33

I don't really get this. Surely JavaScript and C# are so hugely different that any converted code would be horrific? Wouldn't it be simpler to just write JavaScript in JavaScript?

- Translating a statically-typed Object Oriented language to JS wouldn't produce hugely different (/horrific) code. From inheritance to lambdas, there are comparable features available in JS. Going from JS to C# might be harder though.

- It might be simpler to write JS, but I can imagine people wanting to see if type-safety has benefits.

Re: New C# to Javascript compiler released

#34
post #33

I don't really get this. Surely JavaScript and C# are so hugely different that any converted code would be horrific? Wouldn't it be simpler to just write JavaScript in JavaScript?

- Translating a statically-typed Object Oriented language to JS wouldn't produce hugely different (/horrific) code. From inheritance to lambdas, there are comparable features available in JS. Going from JS to C# might be harder though. - It might be simpler to write JS, but I can imagine people wanting to see if type-safety has benefits.

That's right, it doesn't get horrific until you use goto or yield (which don't exist in Javascript so they have to be emulated).

Re: New C# to Javascript compiler released

#35
post #22

I totally agree that JavaScript can easily end up being a huge mess especially when project grows. Using more strict language like C# can help on that. I have to try this, good job!

There are frameworks and best practices for organizing JavaScript heavy projects. I'm all for solutions to unify front and backend web application development so cheers to Erik for developing this, I've just never been a fan of cross language compilation.

Re: New C# to Javascript compiler released

#36
post #27
post #6

Earlier quoted context omitted.

"... but when it is JavaScript that will be run by the browser then JavaScript is what you should be writing." So by that logic, one shouldn't be writing C# that targets the CLR either, but should rather be coding in MSIL directly. Mmm, no thanks!

But JavaScript is not (another daft meme) "the assembler of the web" as it is itself interpreted (or what have you) into byte code for execution. The point is that one should limit the level of abstraction to one which sits in that comfort zone between code that is sensible to humans and code that is sensible to the machine running it and (perhaps more importantly) the available dev/debug tools.

I don't agree that JavaScript being good enough for one person makes it good enough for everyone.

I don't agree that limitations should be placed on abstractions; I have no clue what's happening at the CPU level when a line of JavaScript or MSIL or bla bla executes. I don't need to know what's happening at all the layers of abstraction beneath the one I'm working on, and that helps me be productive.

There might be a pragmatic argument against using compile-to-JS languages _right now_, but with things like Google Chrome's Source Maps, this is a problem that is being solved if it hasn't been already.

Re: New C# to Javascript compiler released

#37
post #27
post #6

Earlier quoted context omitted.

"... but when it is JavaScript that will be run by the browser then JavaScript is what you should be writing." So by that logic, one shouldn't be writing C# that targets the CLR either, but should rather be coding in MSIL directly. Mmm, no thanks!

But JavaScript is not (another daft meme) "the assembler of the web" as it is itself interpreted (or what have you) into byte code for execution. The point is that one should limit the level of abstraction to one which sits in that comfort zone between code that is sensible to humans and code that is sensible to the machine running it and (perhaps more importantly) the available dev/debug tools.

No, one should limit the level of abstraction to the fastest one that is reliable enough to get the job done. There's nothing intrinsic about high abstraction layers that say they must suck for debugging what you need debugged. It just depends on what you need to do with it. If it gets your job done faster and it's reliable enough for your job, then why not? That's why higher abstractions are created in the first place.

In short, you can't instantly rule out this compiler without knowing exactly what you'd want to do with it. And exactly how good it would be at that specific problem.

Re: New C# to Javascript compiler released

#40
post #33

Earlier quoted context omitted.

- Translating a statically-typed Object Oriented language to JS wouldn't produce hugely different (/horrific) code. From inheritance to lambdas, there are comparable features available in JS. Going from JS to C# might be harder though. - It might be simpler to write JS, but I can imagine people wanting to see if type-safety has benefits.

That's right, it doesn't get horrific until you use goto or yield (which don't exist in Javascript so they have to be emulated).

Some browsers, and ES Harmony, have yield. You could add a compiler switch to use native support, although only Firefox seems to support this just now.

Curious to see how you managed the emulation - splitting up a function? Web workers? :)

Post reply on HN