41–50 of 81 posts
Earlier quoted context omitted.
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? :)
Earlier quoted context omitted.
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).
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".
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).
Wow, very cool. I like C#, and the DOM is actually specified with types, so statically-typed web dev with this would be awesome.
Wow, very cool. I like C#, and the DOM is actually specified with types, so statically-typed web dev with this would be awesome.
You can get the majority of this functionality with Closure Compiler though, without needing to abstract the entire language away.
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 JavaScri…
Maybe that's where source maps come handy? http://www.html5rocks.com/en/tutorials/developertools/source...
The slightly overbearing complexity of the solution matches the linguistic complexity of the statement above :)
Earlier quoted context omitted.
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 pla…
Check out this stack trace:
http://www.ibm.com/developerworks/java/library/os-ecspy1/sta...
Now imagine that across three different languages.
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?
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.
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 JavaScri…
Maybe that's where source maps come handy? http://www.html5rocks.com/en/tutorials/developertools/source...
