I am using GWT, which includes a Java-to-JavaScript compiler. Before this project, targeting the JavaScript runtime from a different language hadn't occurred to me, and I'm enjoying the GWT experience.
A quick search revealed Java2Script as another Java-to-JavaScript solution. Are there any other mature compilers that target the JavaScript runtime?
List of languages that compile to JS
You also have Haxe. It features static, structural, strong and inferred typing; algebraic data types; lambda expressions with closure support; a module system and can compile not only to JavaScript but also Flash, C++, Neko, PHP. Java support is under development too.
Pyjamas compiles Python to JavaScript.
HotRuby runs Ruby source code under JavaScript and Flash.
Orto is (was?) a JVM implemented in JavaScript. (Original site is down; link is to a blog entry.)
The ZK framework, which likes to compare themselves favorably against GWT, uses Java and XML to generate JavaScript. (They claim that it takes far less code than GWT to do the same stuff.)
And I have heard it well-argued that jQuery is a separate language that happens to be implemented in, and run under, JavaScript. :-)
OpenLaszlo is on open source XML -> Javascript (technically DHTML, also can compile to Flash) compiler. I've played with it a little bit and it seemed interesting, although have never used it seriously (bad IDE support when I tried it).
Objective-j is a similar project that resembles objective-c, although runs as javascript (not sure if it compiles it or has a js interpreter). I don't know much about it, but do see posts about it on the Ajaxian from time to time.
Parenscript is "a translator from a small Lispy language to JavaScript". It's not Common Lisp -- it's mostly just Lisp syntax for Javascript, though for simple things you can write the same code to target both, if you're careful. I'm not sure I'd call it "mature", either.
While there are other products which compile to javascript (noted in the other comments), I believe that GWT is, by far, the most mature one out there, in terms of real-world usage.
The simple fact that a number of Google's core applications use GWT (e.g.: the new adwords GUI, Google wave, etc) means you can have confidence the product is going to be maintained for at least the next few years, it isn't just going to fade away anytime soon.
Another thing to keep in mind is that GWT is far more than a java-to-javascript compiler, it also is an optimizing compiler, it has hosted mode, it is fully interoperable with native javascript, it does image bundling, it does code spliting in the new version, etc.
Script #
JSC
cappuccino (sort of)
The inventors of Clojure (a JVM based Lisp dialect) launched ClojureScript in mid-2011. ClojureScript compiles Clojure source code into JavaScript, making use of the Google Closure compiler and the Closure framework. ClojureScript code can run both in the browser client, or on node.js servers.
Here's a shameless plug for a project I started and am continuing to develop: scxml-js, a Statecharts-to-JavaScript compiler
Related
I'm looking for a way to protect some javascript code from reading/modifying. I know many people consider that impossible, but still...
From what I see the Chrome's V8 engine does a number of optimizations when it sees JS code, probably compiles it (?) and then runs it.
So I'm wondering is it possible to use V8's C++ api to compile the JS code into machinecode/chromecode and then feed that directly into Chrome (I don't care about other browsers)?
Supposedly it will not only be faster, but also non-humanly readable, something like ASM.
Is this possible?
WebAssembly is doing this thing so I don't understand why we can't do it with JS code.
There's also EncloseJS and pkg that are doing a very similar thing.
V8 developer here. No, it is not possible to compile JavaScript ahead of time and send only the compiled code to the browser. V8 (and other virtual machines like it) contain compilers, but they cannot be used as standalone compilers to produce standalone binaries.
In theory, you could compile JavaScript to WebAssembly -- any two turing-complete programming languages can in theory be compiled to each other. As far as I know, no such compiler exists today though. One big reason for that is that performance of the end result would be horrible (see the discussion with Andreas Rossberg for details); so considering that browsers can execute JavaScript directly, people have little reason to develop such a thing. (It would also be a large and difficult task.)
As for your stated goal: your best shot at making JavaScript code unreadable is to minify it. In fact, that is effectively just as good as your idea to generate assembly, because disassemblers exist that turn assembly back into minified-like higher-level language code; they cannot reconstruct variable names or comments (because that information is lost during compilation), but they can reconstruct program logic.
What I ended up doing is moving some of the logic from JavaScript into C++ and compiling that into NodeJS native modules (that's possible for Electron apps).
It works pretty good, it's very fast, the source is... as protected as it can get, but you may need to worry about cross-platform issues, also compiling/linking can be a bit of a pain, but other than that it's great.
WebAssembly is not doing that. And no, it's not possible either. The web is supposed to be both browser- and hardware-independent.
Moreover, a language like JS would not be faster if compiled offline -- it only is anything close to fast because it is dynamically compiled and optimised, taking dynamic profile information into account.
I saw those javascript front-end build tools, e.g. webpack, using the word "compile" from time to time. I am not sure what does compile javascript codes mean exactly, at least not like compile c/c++ codes.
I think I understand the "build" process in general, like bundle all js codes into one big file, minify/uglify the codes, using babel to transforms ES6 syntax(transpile). But what does compiling mean here, how does it fit in the whole building process or it is just another name for the whole build process?
Currently, I thought it may be just another name for using Babel to transforms ES6 syntax.
PS. after reading this SO Is Babel a compiler or transpiler? I believe my question is not same as that. Because it is not just related to Bable. For example, webpack also uses the term compiler https://webpack.js.org/api/compiler/ I do not understand its meaning there!
Browserify uses compiler as well e.g, https://github.com/robrichard/browserify-compile-templates "Compiles underscore templates from HTML script tags into CommonJS in a browserify transform"
It's better to describe the process as "transpilation."
Javascript always executes in a specific environment: in Chrome and Electron, it's the V8 engine; in Firefox, it's SpiderMonkey; etc. Each of these engines supports a specific set of language features and not others. As an example, some engines only support var and do not support const or let. Some support async/await, and others only support Promise.
But web developers know about these other features, and they want to use them, even when they're writing for an engine that doesn't support those features. Why? Most new language features are designed with the goal of making it possible to express complicated concepts in simpler and cleaner ways. This is extremely important, because the number one job of code is to make its purpose clear.
Thus, most language features are essentially syntactic sugar for existing functionality. In those cases, it's always possible to express a routine using both new and old syntax. This is a logical necessity.
A transpiler like Babel can read a script written using advanced syntax, and then re-express the script using a restricted set of language features. Relying on an intermediate representation called an abstract syntax tree, it can produce code that is guaranteed to be functionally equivalent, even though it does the work using very different, more widely-supported control structures.
Perhaps we web developers have gotten lazy in our terminology. When we talk of "compiling" javascript, we aren't usually talking about converting the script to something like bytecode. We're talking about transpilation.
Other kinds of build tasks are also becoming quite common. These days, the front-end is obsessed with a million flavors of "templating," because it's extremely tedious and confusing to describe DOM changes using pure javascript, and because application complexity is increasingly very rapidly. Some frameworks require you to convert source code to other intermediary forms that are later consumed by the web application at runtime. Others permit devs to describe UI using invented syntaxes that no browser is even attempting to support natively. Which tasks are needed varies by application depending on which frameworks are being used, the particulars of the application architecture, and the contours of the deployment environment, and that's just a start.
At its foundation, a web page is built using HTML, CSS, and javascript. That much hasn't changed. But today, most serious applications are built almost entirely in javascript (or something very much like it) and sass. Building the application is the process of applying a set of transformations to the source code to yield the final artifacts in those three bedrock languages.
We lump all that stuff under the term "compile."
You pretty much hit the nail on the head. When the Compile (or more appropriately transpilation) operation happens on a JavaScript project it can mean a number of things. As you mentioned these could range from minification, applying polyfills, shims, or the literal act of "compiling" the scripts into a single bundle file for platform/browser consumption.
Transpilation when using super sets of the JavaScript language such as TypeScript, ActionScript, or UnityScript describes the process of converting the source x-script back into native JavaScript which can be in turn be interpreted by a browser (since the browser doesn't recognize the superset languages).
However you are absolutely correct. We aren't compiling our JavaScript into binary, but the term gets thrown around a lot which can lead to confusion. All that said, we are closing in on the age of adoption of WebAssembly and ASMJs which promises to bring the age of bytecode running in the browser which will bring about some interesting possibilities, but alas... That's a story for another day ;)
You're right when you say these front-end Javascript tools don't use the word compile in same context in what your used to with build tools for languages like C/C++. C/C++ compilers turn source code into machine code.
These JavaScript build tools-- like Webpack-- use the word compile in a sense thats more metaphorical than conventional.
When web build tools use the word compile, they're using it in the sense that they are transpiling, minifying (a.k.a uglyfying), and bundling the source files so they are better optimized for client browsers and network requests. (Smaller file sizes, better browser compatibility, less HTTP requests from bundled assets, etc.)
I recently realised that Actionscript and Javascript are both implementations of ECMA script. Now I'm wondering what this means in practice.
I have a Flex application written in Actionscript and I'm looking at porting parts of it to Javascript for use in AJAX apps. I have had virtually no exposure to JS so far (not counting occasional onClick handlers in my HTML), so maybe the question is silly. But can I just take my Actionscript classes and use them in JS code?
Naturally, I can't use any of the Flash Player APIs in JS and no DOM in my Flash movie, this much is obvious. Are there other important libraries on either side that can't be used on the other?
AS3 is an ECMA-script dialect at best. It is an implementation of a ECMA-script draft that has been completely dropped. JS is a subset of AS3. However the ActionScript compiler included in the Flex SDK will complain about any untyped variable or function, so you'll have an awfull lot of warnings when you compile.
You should definitely have a look at Jangaroo.
And, as always, my personal advice is for you to slowly migrate (at least the logical parts of your application) to Haxe for obvious reasons. You can use as3tohaxe, to facilitate porting.
No, not usually. The languages are similar but different. Case-sensitivity of identifiers is one big one (for old versions of ActionScript).
There are AS2 and AS3 languages and they are based on different versions of ECMA script and not compatible. Application code on AS2 without flash API is quite similar to js.
I am looking for an ECMAScript alternative to work as a scripting language for custom application logic. There are things I like about ECMA, especially the syntax for the newer spec(like AS3).
Unfortunately, the AS3 engine is not open source to be able to integrate in a project. I would like a scripting language that was designed for object oriented use.
Specifically, is there a language that has:
Statically typed variables(optional)
Classes, including public/private members
Inheritance, including Interfaces
Packages(optional)
Clean syntax
Must be able to interface as an internal scripting language for an application(like Javascript for a browser), can not be an external system call.
Things I would rather do without
The messy ECMA prototype object
What languages that you know about fit this profile? I've had difficulty finding a quality scripting language that was designed for good object oriented design.
In Java the best ECMAScript (Javascript) option is to embed Rhino. I don't find the prototype-based inheritance a deal killer, as with a bit of discipline you can make it behave almost like class-based inheritance.
If you want something that interoperates very closely with Java, go with Groovy. If you need JVM compatibility, also look into Jython (python on the JVM), Jruby (Ruby on the JVM) and Scala (a functional language on the JVM). If you don't care about Java and JVM compatibility, look at Ruby, Python, and Erlang. Clojure is a dialect of Lisp on the JVM.
Going further afield, TCL (Tool Command Language) lets you embed an interpreter in C/C++ code, there are many embeddable Lisp and Scheme interpreters, etc.
If you want a scripting language that works like ECMAScript, why not use ECMAScript? There are many Open Source implementations, just take a look at the list on Wikipedia.
I'd recommend either Python or Ruby. Neither are like ECMA, but I learned them after JavaScript, and they were a snap to pick up. Plus, they are more powerful languages, making it a better alternative to using a JavaScript engine inside of your application (Rhino for Java).
Python
Forces clean syntax (almost like English while is not False:)
Multiple inheritance (no interfaces)
Interpreter can be extended using C/C++ (possibly used for your adapters, if needed)
Ruby
Syntax is supposed to be close to English (unless conditional, until loop)
Everything is an object
Only supports single inheritance, but uses Mixins to add functionality
Both
Classes
Can be embedded in another application
Private members
Packages
Lua - everything you want and more in ~100KB
See this page for comparison betwen Lua and other mentioned languages.
Haxe on Neko looks like the exact thing you want. I don't know how embeddable nekovm is, but it is opensource so you can fiddle with it. http://haxe.org
The Ruby interpreter can also be embedded within C programs, and may be considered by some to be more object-oriented than Python.
We use ECMAscript as an extension language for the software product I work on and it works quite well. Being a standard (and popular) language, it's nice to be able to point our users to the copious off the shelf documentation for the language. We built our own ECMAscript compiler that translates into bytecode for the platform we are running on, but if I had it to do over again, I'd seriously consider embedding Google's V8 ECMAscript engine (in fact, I'd even consider building our entire app on it).
I'd go with something fairly mainstream to simplify things. Having read your requirements, I'd recommend Python. It doesn't really have interfaces in the Java/C# way, but it doesn't really need them, either. Other than that, it should be a good fit.
QtScript is ECMAScript. You don't mention what the main part of your application is written in, but I suppose it's not Qt, or you'd already know about QtScript.
Is there a way for me to pre-compile my JS code when building my solution? I would like to be made aware of common problems before I get to the browser. Ideally I would build the sln and, if necessary, have a plugin or call from the build events examine the js code against a Java compiler.
Thank you very much in advance!
Despite what many of the other posters have said, in many cases (incl. the Mozilla Spidermonkey engine found in the Firefox browser) Javascript is in fact compiled into bytecodes, vaguely similar to (but not compatible with) the ones used in Java. You just don't see the compiler's output because it is never available to you, only to the Javascript bytecode interpreter. It's also not possible to save the compiled bytecodes for reuse (at least in the web browser context; in alternate uses of the Spidermonkey engine I do think it is possible to save the compiled bytecodes in memory for reuse, but not in a form that can be saved to disk for another future use), as far as I know.
I use a Javascript shell JSDB which also uses the Spidermonkey engine; when you load in a file, it will complain about syntax errors before it runs even one line of code. This is not the same type of compilation as Java, though; Javascript is a loosely-typed language and so it won't catch problems the way a Java compiler would (e.g. complain about every last thing under the sun that it knows you haven't done right).
Having said that, I would second JSLint as it would probably catch many of your errors.
As a side note, the Rhino project lets you compile Javascript into Java classes; i've never tried this but it sounds interesting.
Javascript is an interpreted language, it's not compiled till runtime. Also, javascript has very, very little to do with Java. Netscape released JavaScript around the same time Sun released Java, and there was some sort of marketing deal between them. Otherwise, they're unrelated.
I apologize for my misuse of the term 'compile'. I do fully understand the difference between compiled and interpreted languages. What I am interested in is to have my syntax checked routinely during a build so typos, invalid method calls and the like are flagged. I'm going to look into what Jason S recommended for this. I am also fully aware that JavaScript is not Java, but have read before that you could run your JS code through a Java Compiler for syntax checking. I was hoping to find something better integrated with VS.
Thank you very much to everyone understanding the intent of my request.
Javascript isn't compiled, has nothing to do with Java but some shared syntax, and is best tested by loading your app into a browser.
There are some JS testing frameworks/tools available but I couldn't recommend any of them myself.
Try JSLint.VS