I'm an admitted novice JavaScript programmer and am attempting to learn more. So I turn to you folks for help, with this easy question :). The O'Reilly book that I'm reading keeps referring to the compile-time of the JavaScript code. My knowledge of functional programming (scheme and the likes) tells me that the JavaScript is actually interpreted by the browser, most likely requiring two passes through the JavaScript.
Am I incorrect in my assessment? Or is the compile-time that the book references actually just the first pass of the interpreter, similar to how Perl or Python would function? Thanks!
It is browser-dependent. Look up WebKit's SquirrelFish Extreme and Google V8 to see what's at the fastest end of things, and look at Mozilla's JaegerMonkey for that implementation.
AFIAK V8 and SFX are JITs, so they compile JS code to native. JaegerMonkey and TraceMonkey combine in Firefox to form a system where if code would be faster traced, TraceMonkey executes it, and if code were faster native, JaegerMonkey compiles it, just like SFX.
Do you have a sentence that you could quote to help with context?
Javascript is compiled at the browser (it's sent to the browser in plain source). But it only gets compiled as it is loaded. So if you have a script tag followed by a div tag followed by a script tag then it will load those things sequentially. The browser will stop loading the entire page (it still downloads resources, just doesn't load HTML) until your script has been loaded (this is because the script may have 'document.write' within it).
<script>
var someVariable = 'hello world';
alert(document.getElementById('someid')); //alerts undefined
</script>
<div id='someid'></div>
<script>
alert(document.getElementById('someid')); //alerts 'someid'
alert(someVariable); //alerts 'hello world'
</script>
There's read-time and run-time in JS (as I like to think of it, since it's not really compiled, but interpreted). It sounds like the O'Reilly book is using compile-time as a synonym for read-time.
Read-time is when the engine reads all of the code and evaluates everything at the global scope. Usually this sets up hooks on events that will trigger code execution.
Run-time is everything else.
Related
Sorry if this is a trivial question, so if this has already been asked, please direct me to the question.
I know that the tostring method in javascript, if called on a function will print the source code (more about it: link). Is it possible to do the same thing in Java?
So if I have the following identity function definition:
public class class1 {
int f1(int x){
return x;
}
}
And the following main function:
class Main {
public static void main(String args[]) {
class1 c1 = new class1();
????
}
}
Is there anything I can put in place of '????' that would print something like
int f1(int x){
return x;
}
Disclaimer: I'm not an expert at Java, or any programming language for that matter. However, I do know how to find information online.
This concept does not seem very doable within Java. To start:
JavaScript is an interpreted language, not a compiled language. A program such as C++ or Java needs to be compiled before it is run. The source code is passed through a program called a compiler, which translates it into bytecode that the machine understands and can execute. In contrast, JavaScript has no compilation step. Instead, an interpreter in the browser reads over the JavaScript code, interprets each line, and runs it. More modern browsers use a technology known as Just-In-Time (JIT) compilation, which compiles JavaScript to executable bytecode just as it is about to run.
Basically, JavaScript has the advantage of reading directly from the file with the source code, and executing it on the fly. Compiled languages such as Java won't have that sort of functionality built in by default for many reasons, including security. An application should be able to run without allowing hackers access to its source code as much as possible.
There have been attempts at doing various forms of what you're interested in, but the two easiest methods seem to be
Printing the original .java file line by line
Storing a string reference to the entire code or the method(s) required.
It also seems possible to print the method name, but not the body.
Aside from that, the only thing you might be able to get from a compiled, running java program, is bytecode, which would require a decompiler to have any hope of understanding the source behind it.
You can continue reading up on it through a few of the links here:
How do I print the method body reflectively?
Save a method into a variable, java 8
View a method's implementation (method body) using Java Reflection
Probably yes, but not a trivial one with a ready command. JavaScript is an interpreted language where the executing environment has access to the source code in its original form. That is how you can inspect it in a browser console and see the same variable names as are in the source code.
While the compiled/interpreted distinction is fuzzy for Java, it is definitely modified before execution. The bytecode used by Java's Just-in-Time compilation may be more readable than a fully compiled binary file, it is not the source. If the running program does not have access to the source code, it is less able to output it. A debugger running in an IDE can reference problems in the source; otherwise, you are limited to debugging the bytecodes.
This is why Keno Clayton suggested the question on Quine programs, which are meant to reproduce themselves. This answer outputs the source code by hard-coding it as a class attribute. You could take a similar approach with a pre-compilation script that went through all the methods and made strings out of their sources, but the result would be bulky and potentially sensitive.
What's the most performant way to execute JS directly after a HTTP request in JRuby? I know about all the test frameworks like HtmlUnit, Celerity, Capybara + PhantomJS == Poltergeist, CasperJS etc. but they're still test frameworks.
What I need is a simple way to execute all JS code which is included in HTML after fetching the URL e.g. by Net::Http.
First of all, it goes with out saying: DON'T DO THIS IN PRODUCTION!
Executing some script that's been pulled from somewhere on the internet is a recipe for disaster. If you're using it as part of your testing infrastructure, it may be of some use but I'd guess that there's a simpler way to solve your problem.
To answer the more general question, here's how you'd initialize a JavaScript engine bundled with JDK 1.6+ (effectively a cut down version of Rhino, although this will change in Java 8 probably):
import javax.script.ScriptEngineManager
import javax.script.SimpleBindings
manager = ScriptEngineManager.new
engine = manager.getEngineByName("JavaScript")
bindings = SimpleBindings.new
bindings['x'] = 1
engine.eval("print(x)", bindings)
Getting your engine to evaluate any dependencies like jQuery is left as an exercise to the user. Have a look at the javax.script JavaDoc.
If you need more control over the evaluation environment you'll have to use Rhino directly, or wait for Nashorn...
We are working on an extension to google-code-prettify which does the code-coloring for source-code on a webpage. We have a very long list of keywords (approx 4000) in Mathematica and while the performance is still very good, I wondered whether I can speed things up.
The regular expression for our keyword list looks like this
var keywords = 'AbelianGroup|Abort|AbortKernels|AbortProtect|Above|Abs|Absolute|\
AbsoluteCurrentValue|AbsoluteDashing|AbsoluteFileName|AbsoluteOptions|\
AbsolutePointSize|AbsoluteThickness|AbsoluteTime|AbsoluteTiming|AccountingForm';
new RegExp('^(?:' + keywords + ')\\b')
Can such an or-ed regex be made faster when it is compiled? Would it in the first place make sense to compile it, since google-code-prettify is a JavaScript running on the server. I don't know whether this script is loaded freshly every time a web-page is loaded. In this case, it is maybe not worth the overhead to compile it.
google-code-prettify runs on the client (it's a script; the source is requested from the server by the browser).
Creating the RegExp object does compile it, at runtime.
In other words, just leave it as-is.
I'm developing a networked application between the browser and a server running node.js. I'm sharing a lot of code right now, but when I actually deploy this I'd like the client to only get client specific code. My options right now are:
1.) Implement any browser/node.js differences using inheritance. I've tried this in a few places and I end up with a lot of classes that are very, very basic customizations of their parent often only partially specializing a single function. This is not a style I like very much because it means a lot indirection when you're trying to find out what's actually going on.
2.) Define a constant like IS_BROWSER at global scope and then check it whenever I need to change code paths on the browser vs node.js. Then closure compile all js with advanced optimizations to remove dead code on the browser (setting IS_BROWSER = true). Are there any problems with this approach assuming I do whatever I need to do to get advanced optimizations going in closure compiler?
3.) ?? I'm open to suggestions.
If you use advanced compilation, any unused code should be removed; if you use the compiler's export system correctly, any server-side code that your client code does not call will not be in the compiled version of the client code.
You could write all of your code in one big blob then, for your client, add one file with contents like
goog.require('my.client.app');
goog.exportSymbol('my.app.entryPoint', my.client.app.entryPoint);
the compiled code will not include anything that is not in the call tree of my.client.app.entryPoint. Likewise, if your compilation only exports a server entry point, client code will be excluded.
The above style is for writing your script to provide some function which will then get called by an inline script; to make the whole thing into a single script you could do something much simpler:
goog.require('my.client.app');
my.client.app.entryPoint();
To verify that you are not getting a lot of dead code in your compilation output, you could play around with something like this: ScriptCover
I've been arguing for some time against embedding server-side tags in JavaScript code, but was put on the spot today by a developer who seemed unconvinced
The code in question was a legacy ASP application, although this is largely unimportant as it could equally apply to ASP.NET or PHP (for example).
The example in question revolved around the use of a constant that they had defined in ServerSide code.
'VB
Const MY_CONST: MY_CONST = 1
If sMyVbVar = MY_CONST Then
'Do Something
End If
//JavaScript
if (sMyJsVar === "<%= MY_CONST%>"){
//DoSomething
}
My standard arguments against this are:
Script injection: The server-side tag could include code that can break the JavaScript code
Unit testing. Harder to isolate units of code for testing
Code Separation : We should keep web page technologies apart as much as possible.
The reason for doing this was so that the developer did not have to define the constant in two places. They reasoned that as it was a value that they controlled, that it wasn't subject to script injection. This reduced my justification for (1) to "We're trying to keep the standards simple, and defining exception cases would confuse people"
The unit testing and code separation arguments did not hold water either, as the page itself was a horrible amalgam of HTML, JavaScript, ASP.NET, CSS, XML....you name it, it was there. No code that was every going to be included in this page could possibly be unit tested.
So I found myself feeling like a bit of a pedant insisting that the code was changed, given the circumstances.
Are there any further arguments that might support my reasoning, or am I, in fact being a bit pedantic in this insistence?
Script injection: The server-side tag could include code that can break the JavaScript code
So write the code properly and make sure that values are correctly escaped when introduced into the JavaScript context. If your framework doesn't include a JavaScript "quoter" tool (hint: the JSON support is probably all you need), write one.
Unit testing. Harder to isolate units of code for testing
This is a good point, but if it's necessary for the server to drop things into the page for code to use, then it's necessary. I mean, there are times when this simply has to be done. A good way to do it is for the page to contain some sort of minimal block of data. Thus the server-munged JavaScript on the page really isn't "code" to be tested, it's just data. The real client code included from .js files can find the data and use it.
Thus, the page may contain:
<script>
(function(window) {
window['pageData'] = {
companyName: '<%= company.name %>',
// etc
};
})(this);
</script>
Now your nicely-encapsulated pure JavaScript code in ".js" files just has to check for window.pageData, and it's good to go.
Code Separation : We should keep web page technologies apart as much as possible.
Agreed, but it's simply a fact that sometimes server-side data needs to drive client-side behavior. To create hidden DOM nodes solely for the purpose of storing data and satisfying your rules is itself a pretty ugly practice.
Coding rules and aesthetics are Good Things. However, one should be pragmatic and take everything in perspective. It's important to remember that the context of such rules is not always a Perfect Divine Creation, and in the case of HTML, CSS, and JavaScript I think that fact is glaringly clear. In such an imperfect environment, hard-line rules can force you into unnecessary work and code that's actually harder to maintain.
edit — oh here's something else I just thought of; sort-of a compromise. A "trick" popularized (in part) by the jQuery gang with their "micro template" facility (apologies to the web genius who actually hit upon this first) is to use <script> tags that are sort-of "neutered":
<script id='pageData' type='text/plain'>
{
'companyName': '<%= company.name %>',
'accountType': '<%= user.primaryAccount.type %>',
// etc
}
</script>
Now the browser itself will not even execute that script - the "type" attribute isn't something it understands as being code, so it just ignores it. However, browsers do make the content of such scripts available, so your code can find the script by "id" value and then, via some safe JSON library or a native browser API if available, parse the notation and extract what it needs. The values still have to be properly quoted etc, but you're somewhat safer from XSS holes because it's being parsed as JSON and not as "live" full-blown JavaScript.
The reason for doing this was so that the developer did not have to define the constant in two places.
To me, this is a better argument than any argument you can make against it. It is the DRY principle. And it greatly enhances code maintainability.
Every style guide/rule taken to extreme leads to an anti-pattern. In this case your insistence of separation of technology breaks the DRY principle and can potentially make code harder to maintain. Even DRY itself if taken to extreme can lead to an anti-pattern: softcoding.
Code maintainability is a fine balance. Style guides are there to help maintain that balance. But you have to know when those very guides help and when they themselves become a problem.
Note that in the example you have given the code would not break syntax hilighting or parsing (even stackoverflow hilights it correctly) so the IDE argument would not work since the IDE can still parse that code correctly.
it simply gets unreadable. You have to take a closer look to divide the different languages. If JavaScript and the mixed-in language use the same variable names, things are getting even worse. This is especially hard for people that have to look at others people code.
Many IDEs have problems with syntax highlighting of heavily mixed documents, which can lead to the loss of Auto-Completion, proper Syntax Highlighting and so on.
It makes the code less re-usable. Think of a JavaScript function that does a common task, like echoing an array of things. If you separate the JavaScript-logic from the data it's iterating over, you can use the same function all over your application, and changes to this function have to be done only once. If the data it's iterating over is mixed with the JavaScript output loop you probably end up repeating the JavaScript code just because the mixed in language has an additional if-statement before each loop.