I've always hated the idea of some server-side language (like ASP.Net, GWT, RoR, what-have-you) generating JS code to run on the client. I'm glad at least Eich agrees with me, as is published in this interview. (Jump to page 3 for this excerpt.)
I did not intend JS to be a "target" language for compilers such as Google Web Toolkit (GWT) or (before GWT) HaXe and similar such code generators, which take a different source language and produce JS as the "object" or "target" executable language.
The code generator approach uses JS as a "safe" mid-level intermediate language between a high-level source language written on the server side, and the optimized C or C++ code in the browser that implements JS. This stresses different performance paths in the JS engine code, and potentially causes people to push for features in the Ecma standard that are not appropriate for most human coders.
JS code generation by compilers and runtimes that use a different source language does seem to be "working", in the sense that JS performance is good enough and getting better, and everyone wants to maximize "reach" by targeting JS in the browser. But most JS is hand-coded, and I expect it will remain so for a long time.
That said, I think Eich doesn't highlight some of the other problems with server-generated JavaScript: ability to debug, potentially unoptimized output, and potentially inefficient code. I've worked with server-generated JavaScript in ASP.Net and RoR, and I know what a pain it can be.
2 comments:
your site is very nice ...
this is very helpful and attractive.
visit for asp.net help asp.net help
Your sharing in the article is very meaningful, the content is very rich and contains good things. visit here
Post a Comment