[bdfh42]

The very best of luck when it comes to debugging the code when it is running in the browser.

Maybe your experiences are different to mine but I avoid such abstractions wherever possible.

It has become fashionable to say things like "JavaScript ... is not well suited for developing large systems" - indeed so much so it often passes without comment but when it is JavaScript that will be run by the browser then JavaScript is what you should be writing.

[marcelvr]

"... 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!

[weego]

Come on, we all know that isn't a logical equality.

[giulianob]

Once the debugging tools are able to keep everything abstracted then you no longer need to dig down. Example is of course writing assembly.

[0ptr]

Yeah there's no logical equality to machine code and C++ but still people use debuggers. I don't think this is something that cannot be solved.

[bdfh42]

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.

[vibrunazo]

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.

[eckyptang]

Yes no limits to abstractions always works perfectly..

Check out this stack trace:

http://www.ibm.com/developerworks/java/library/os-ecspy1/sta...

Now imagine that across three different languages.

[erik-kallen]

Java has been said to be a DSL to convert XML configuration into stack traces. But what does this have to do with compiling C# to Javascript?

[eckyptang]

The abstraction is too deep. The stack trace above is an example of what too deep abstractions do to those who have to use them.

[marcelvr]

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.

[erik-kallen]

Actually, debugging is quite simple. The generated script (unless minified) is very similar to the input code. Are you also against other options such as CoffeeScript? And do you think it is very hard to debug higher-level languages such as C, C# or Java because "if you are writing code to run on a processor, it is assembly you should be writing"?

[prasincs]

The question is how similar? Coffeescript has come a long way in keeping symbols similar enough to be debuggable and not polluting the javascript namespace. Once the code grows to a certain size, tracing from line number in error to a line of code in your source becomes non-trivial.

Also, since this has been a constant pain for me when using Google Closure compiler, how do you anticipate this tool working with existing javascript libraries? Hypothetically, can I port a C# application ( a reasonable/simple one, not with crazy winforms and stuff)? Is there a spec you're adhering to?

[erik-kallen]

It comes with metadata for jQuery and jQueryUI, so obviously those libs can be used. I know of people using Node as well (and I hope to include that import lib in the distribution at some point).

As for porting an existing C# application, it will probably not be trivial, but the back-end stuff is most likely possible (as long as it doesn't have external references). Personally, for my own stuff I tend to compile stuff like DTOs and helpers to both Javascript (running on the client) and regular MSIL (running on the server), but that code has been written with this intent from the beginning.

I prefer to regard working with this to be writing Javascript but with tooling from 2012 instead of 1995.

[jrajav]

Well, he actually said "debugging code when it is running," which a lot of people find valuable. Of course you can debug anything in the looser sense of the term, but tools like debuggers make the process more productive.

And yes, many people are against Coffeescript too for precisely this reason.

[erik-kallen]

You can use the Chrome debugger just as if you had written the Javascript directly.

[prasincs]

I agree. Having had used GWT and other similar cross compiling to javascript type tools, it's often a huge problem in debugging than if you just write a short javascript code. No offense to the author but projects like these that try to fit a static language like Java/C# that run in their own managed environments into dynamic world of Javascript fail miserably.

I fear projects like these tend to attract programmers who know C#, Java but don't quite want to learn javascript and they don't even try to do it once they run out of runway in this tool. And, the code becomes undebuggable, bloated on the browser.

Nothing against other languages, they're amazing at what they do. But, javascript is, for better or worse, the language of browsers. And it's really powerful with established best practices to organize, debug code + great tools (thanks to Chrome Team @ Google and Mozilla).

From a programming languages/compilers standpoint, it definitely tickles my fancy :)

[giulianob]

I program both C# and JS on an almost daily basis and am pretty well versed in both. I have to say that JS is great for adding scripting to pages but for large apps it's a nightmare (especially when coupled w/ the dom).

[bdfh42]

I think it would help the discussion if you could define a "large app" as far as JavaScript is concerned and why you think it is a "nightmare".

[giulianob]

I'd call something with more than 100k LOC a large app. It can get messy even before then though. The main concerns I have with Javascript are:

1) Most frameworks try to make JS into a typical OOP language which tends to hurt performance and can make debugging a PITA.

2) In "one page apps" it can become difficult to map nodes to JS objects so things get cleaned up properly. You often see memory build ups even in jQuery because of html node wrappers and events that get cached but don't get cleaned up.

3) Static analysis. It's possible to get some level of static analysis if you use JSDoc but it's still very poor compared to something like C#. For example, you need to add tons of JSDoc code to make autocomplete somewhat usable. After using something like Resharper, you can really see how lack of good static analysis hurts.

4) Difficult to refactor large apps. Since the static analysis is poor, it's difficult to use tools to create dependency graphs, finding usages, etc... I really wish Js would just let you specify a type of an object like ActionScript 3 does. You can still use var if you want but 99% of the time an object has an expected type.

5) Lack of visibility keywords. This makes it hard to organize code into modules and prevent programmers from getting access to things they aren't supposed to. I'm sure there are entire debates on this point alone.

6) Performance. The browsers try to do tons of optimizations during runtime to speed up javascript. If you want to get the most out of JS, you really need to know about them (e.g. always initialize your class vars in the same order).

[raverbashing]

Really, really

GWT is not the answer, Dart is not the answer, not writing JS is not the answer (maybe CoffeeScript but I'm skeptical)

JS may have its warts, but in the end that's what browsers understand. That's what you'll have to know to debug things.

And the browser doesn't have to execute 2x, 3x the code, and use more memory as well

If you want something to help my perception is that it should be a thin shin (like CS) rather than "full bells and whistles" on top like GWT or Dart

[Kototama]

Maybe that's where source maps come handy?

http://www.html5rocks.com/en/tutorials/developertools/source...

[eckyptang]

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 :)

[randomfool]

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.

[eckyptang]

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.

[dmethvin]

They do come in handy, if only they were supported everywhere. Right now it's just Chrome and a small number of tools.

[mistercow]

>when it is JavaScript that will be run by the browser then JavaScript is what you should be writing.

Of course, source maps will soon make this point largely moot.

[batista]

Haven't happened for the last 2 years we've been waiting for them.

[dotborg]

You should run and debug the C# code, before you compile it to JS, that's how I understand the idea behind this project.

[WayneDB]

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.

[bdfh42]

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.

[jdonaldson]

I agree, but generating "harder to debug" output isn't really a big argument against generators.

The first argument is that "the style is different". I use a js generator language (not this one, I don't want to shift attention), and it does "nice" things that would be a pain for me to do manually... like setting up namespaces for code, spacing everything perfectly. Even if the output is not to your taste, at least you know that the style will be 100% consistent in style and implementation. I never have problems debugging.

The other argument is that "the generated code is complex/ugly". Unfortunately, "fast" code is often ugly. Static compilers can do some optimizations by default (e.g. optimized for loops), and you only need to worry about the "pretty" code at the higher level of abstraction. I doubt you will ever have to debug one of these optimizations, any decent compiler should get them right. You merely have to understand why they were used, which often makes you a better programmer to boot.

[michaelwww]

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