Develop Reference

Is procedural code significantly faster than object-oriented code in compiled javascript when working with cloud hosting?

I was told that object oriented code is significantly slower when working with multiple clients interacting with a cloud-based server, and not worth considering. From what I understand, if treated as an interpreted language, the difference in speed is negligible when compared to other possible optimizations that could be made. Is it truly different for compiled Javascript, say through Rhino perhaps?
I am not privy to the architecture of the code yet, and I could not find any information that answered my question elsewhere. The code is written in Javascript. Memory footprint is not an issue.
Thank you.

Can you compile JS code using V8 and feed that directly to Chrome?

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.

does FP make code run faster in V8?

Recently i have played a lot with Javascript(Chrome) there are some things that came to my mind.
V8 has a JIT which make code running faster.
Functional programming means you write logic into functions and invoke/combine them by chain, means core functions will be invoked frequently(not its real definition just for get my point).
JIT is one best practice of exchange time with space basically in first time cache machine code of high-level functions and run caches in next time.
So may i say that apps will be faster if write code in FP way and run by VM that has JIT feature.

A good read on this subject is here: http://thibaultlaurens.github.io/javascript/2013/04/29/how-the-v8-engine-works/
Particularly the section that talks about how V8 compiles and injects JIT code
How V8 compiles JavaScript code?
V8 has two compilers!
A “Full” Compiler that can generate good code for any JavaScript: good
but not great JIT code. The goal of this compiler is to generates code
quickly. To achieve its goal, it doesn’t do any type analysis and
doesn”t know anything about types. Instead, it uses an Inline Caches
or “IC” strategy to refine knowledge about types while the program
run. IC is very efficient and bring about 20 times speed improvement.
An Optimizing Compiler that produces great code for most of the
JavaScript language. It comes later and re-compiles hot functions. The
optimizing compiler takes types from the Inline Cache and make
decisions about how to optimize the code better. However, some
language features are not supported yet like try/catch block for
instance. (The workaround for try/catch blocks is to write the “non
stable” code into a function and to call the function in the try
block)
In short, your fastest code is that which does not modify objects or prototypical function definitions after they've been defined

What compilers target JavaScript runtimes?

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

Are GWT wrappers on top of javascript libraries discouraged?

I'm in a process of selecting an API for building a GWT application. The answer to the following questions will help me choose among a set of libraries.
Does a third-party code rewritten in
GWT run faster than a code using a
wrapped JavaScript library?
Will code using a wrapped library
have the same performance as a pure
GWT code if the underlying
JavaScript framework is well written
and tuned?

While JavaScript libraries get a lot of programming eyeballs and attention, GWT has the advantage of being able to doing some hideously not-human-readable things to the generated JavaScript code per browser for the sake of performance.
In theory, anything the GWT compiler does, the JavaScript writers should be able to do. But in practice the JS library writers have to maintain their code. Look at the jQuery code. It's obviously not optimized per browser. With some effort, I could take jQuery and target it for Safari only, saving a lot of code and speeding up what remains.
It's an ongoing battle. The JavaScript libraries compete against each other, getting faster all the time. GWT gets better and better, and has the advantage of being able to write ugly unmaintainable JavaScript per browser.
For any given task, you'll have to test to see where the arms race currently places us, and it'll likely vary between browsers.

In some cases you don't have another option. You can not rewrite everything when moving to GWT.
In a first step you could just wrap your existing code in a wrapper and if it turns out to be a performance bottleneck you can still move the code to Java/GWT
The code optimisation in GWT will certainly be better than what the majority of JS developpers can write. And when the Browsers change, it is just a matter of modifying the GWT optimizer and your code will be better tuned for the latest advances in Js technology.

Depends on how well the code is
written.
I would think so.
Generally look at the community around a 3rd party library before using it unless it is open-source (so you can fix bugs) and specifically look for posts concerning bugs - how quick do the maintainers respond to items. How long is a release cycle, etc.