
The V8 Myth: Why JavaScript is not a Worthy Competitor - codetonowhere
http://blogs.adobe.com/avikchaudhuri/2012/01/17/the-v8-myth-why-javascript-is-not-a-worthy-competitor/
======
vessenes
At best, this reeks of like 2000-era Microsoft, "Why does everybody get so
excited about Javascript still? ActionScript is way better! Duh!"

As far as actual points in the fine article -- a test using some sort of
strongly typed data on an unreleased actionscript vm ran three times faster
than v8 running similar code.

I'm not shocked at all, and think Javascript could badly use at the least some
type hinting, personally. But, this author is at best just missing it, at
worst is misleading others.

I recently ported a Flex app to HTML5. Frame rates quintupled on a modern
browser; in a real, mixed-use environment, ActionScript-based tools,
interpreted with the Flash or Flex runtime, are roughly one-fifth the speed in
the modern browser.

If this speed delta trended the other way, Flash would still be vigorously
defended by developers all over the world who would say "we have to have this
speed, don't take it away from us!"

~~~
pangram
Out of interest, is there anything you can share about the particulars of your
application? We did the same Flash vs. HTML5 analysis in the context of
Facebook games, but in our experiments it looked like Flash still won handily
in terms of performance.

~~~
wslh
Not just that, even the Google Chrome support for SVG is terrible, it crashes
very quickly if you draw a lot of nodes. I also found very simple bugs like
moving a SVG objects leaves a trail behind. A good vectorial support is needed
to replace flash.

~~~
untog
It's a constant disappointment to me that Canvas is favoured over SVG. Just
drawing simple shapes and moving them is so much more complicated with Canvas.

------
tommorris
The Web: You are indeed brave, Sir Knight, but the fight is mine.

Adobe: Oh, had enough, eh?

The Web: Look, you stupid bastard. You've got no arms left.

Adobe: Yes, I have.

The Web: Look!

Adobe: Just a flesh wound.

The Web: What are you going to do, bleed on me?

Adobe: Oh. Oh, I see. Running away, eh? You yellow bastards! Come back here
and take what's coming to you. I'll bite your legs off!

~~~
dmethvin
Upvoted not for the humor, but for the aptness of the analogy. JavaScript is
universal and free. If Adobe can create a sort-of-compatible environment that
allows certain classes of apps like games to run better, great for them.
Perhaps their marketing can be, "If JavaScript isn't fast enough, we've got
you covered."

At least it's not Dart!

~~~
kls
It really is appropriate. I love how we keep getting told by guys that are not
writing large apps in dynamic languages, that we can't write large apps in
dynamic languages meanwhile guys like me are out there building some of the
largest code bases in the world with JavaScript. And when it works and we
release something revolutionary to the world, they tell us after the fact that
it is not going to work. AMD and module dependencies have done far more for
advancing building large JavaScript applications than most of these other
cures.

~~~
pnathan
"building some of the largest code bases in the world with JavaScript" You
have over 100 MLoc?

~~~
kls
You are focusing on the wrong part of the conjecture, the point is, large code
bases are being written in JavaScript everyday. Yet, People with the position
like the author continue to argue that it can't happen, despite the evidence
being readily available.

I don't want to dodge your question thought, the answer is yes I have worked
on some JavaScript code bases that are several MLoc. Which I would consider
for conjecture sake to rank in the largest. what constitutes that bar is up
for debate whether they are the top 50 or 500th or 5000th largest, but I do
feel that they qualify as large code bases. Which sufficed for the point I was
making.

~~~
pnathan
Project complexity tends to scale exponentially-ish, so I was wondering what
you considered "Largest codebases"... according to Googling, Windows is 50M,
Android 12M. So a couple million LoC is pretty awesome.

Static typing evangelists seem to have a blind spot: they persistently tend to
assert that you can't write good and large dynamic codebases.

~~~
kls
_Windows is 50M, Android 12M_

IIRC in webOS a substantial portion of the user-land utilizes JavaScript, as a
whole one could surmise that they constitute modular parts of an overall
system. I do not know what the TLoc on webOS is, but I would assume that it
would have to be in the ball park of large. I think it is as valid as the
total line count of windows or android it is also the problem with looking at
these things from just a TLoc perspective.

 _Static typing evangelists seem to have a blind spot: they persistently tend
to assert that you can't write good and large dynamic codebases._

Thanks you probably summed up my post better than I did.

------
VikingCoder
The bytecode myth: Why JavaScript and ActionScript are not Worthy Competitors

Use Native Client. You'll get as close to machine code as you'll ever get,
while running in a sandbox. The only way to go faster is to fully trust the
code on your machine.

Checkmate.

See, I can write the word checkmate, too. How many more times can we come up
with a slightly better argument, using only one train of thought about what is
actually a very complicated issue involving multiple vendors, multiple
platforms, multiple standards committees, ease of use, ease of deployment,
different memory, bandwidth, and cpu constraints, and then just say
'checkmate' as though everyone else is being completely ridiculous?

Several, I bet.

~~~
comex
"Use Native Client. You'll get as close to machine code as you'll ever get,
while running in a sandbox. The only way to go faster is to fully trust the
code on your machine."

Nitpick: The only way to go faster is to use the hardware privilege separation
that Chrome is always already running under, which is considered insufficient
to sandbox untrusted code for historical reasons and organizational reasons
(Chrome doesn't have much control over the kernels it's running under), but no
technical reasons.

------
a_a_r_o_n
I have absolutely no idea how I would write Hello World in Flash. What
compiler do I need. Do I need a compiler. Do I need to buy it? Is that all I
need?

Compared to:

    
    
        $ vim helo.html
        <script>
        alert("hellooooo");
        </script>
    

And if you can't write that from scratch, ViewSource on most web pages will
give you a good clue.

That looks like trump for mindshare, disputed performance questions aside.

~~~
sjs
A couple of months ago I was looking at Flex. It's a complete nightmare to try
and play around with. I downloaded the SDK and tried to make some kind of
hello world thing but just trying to make a module with a single function and
then call that function was not straightforward at all. I didn't even want a
module but I have to have one. Fine. How do I make one? The docs don't even
cover this sort of thing. There is basically no tutorial or documentation I
could find that told me how to do this. I gave up.

Oh, and that was after I had to add manifest types everywhere like I was
writing Java, without a free IDE to complete that junk for me. All the docs I
found assumed you have the Flex IDE or Flash Builder whatever it is. Which
costs over $500. Apparently it's still 1995 at Adobe Inc.

And people say Haskell is hard to use. I had no trouble getting started with
Haskell. `ghci<return>` and away you go.

(I'd like to think that it wasn't my fault. Maybe I'm not as capable as I
think I am, but I have written compilers and interpreters in C, Haskell, and
Lisp. I have written an x86 assembler in Ruby that emits real x86 machine code
as Mach-O binaries. I can write hello world in at least 10 languages. I feel
like I have the capacity to understand this stuff. Hello world with an
existing compiler should be a piece of cake, not an exercise in frustration.)

edit: Ok, I searched for "flex hello world" and did find something that looks
like what I want. I deleted Flex and can't try to run it now though. Still
don't like all the complexity but it does look like what I said I couldn't
find:
[http://livedocs.adobe.com/flex/3/html/help.html?content=02_G...](http://livedocs.adobe.com/flex/3/html/help.html?content=02_Getting_Started__23.html)

~~~
Erwin
With no Flash experience I had no trouble building a few Flex apps, and it was
the same for a team member that quickly build a performant Flex app using
their table widgets (which kills something like jQuery data tables plugin even
on Chrome).

I did read O'Reilly's Flex book first though. I'm not sure people code Flex
for fun, so good documentation costs money.

Was this your first time writing code for a GUI toolkit? Flex has an
interesting model that merges XML definition of a UI with module-based code. I
don't find it particular complex compared to say, writing an MFC application
or C Win32 code to write a UI. I actually prefer it to the jungle of HTML,
CSS, JS and dozens of JS libraries which aren't really geared for a
professional type UI and fall down when you want to display 10,000 items in
your table.

~~~
sjs
Not my first GUI code. I've done lots of web development in the past 15 years.
Front and back. I've written an OS X app, several iOS apps including some
universal ones, a few Android apps, a few webOS apps, and one Windows Phone 7
app. In a previous life I made games and utilities with Visual Basic and
played around with Gtk+ in C (but quickly ran away).

------
dugmartin
I've written both large ActionScript 3 (AS3) projects and large single page
Javascript applications so I think I have a pretty good understanding of both
languages.

For those of you who haven't done any AS3 programming it is a superset of the
ECMAScript 4 standard while browser based Javascript uses ECMAScript 3.1. AS3
"feels" more like Java in that it adds syntax for types and classical
inheritance but if you are lazy you can use * for the type and prototypical
inheritance still works. Both of those might horrify static language/GOF
purists but it does allow you to pass objects around on the side without
refactoring pure OOP interfaces or inheritance trees.

In the end I enjoy working in AS3 with its static type checking more than I do
Javascript pushed through JSLint. With large Javascript apps, even with strict
use of the Module pattern, I feel like my code contains hidden runtime bombs
waiting to do off.

Some caveats - I'm on a Windows machine and Flash runs great for me. I've also
never developed with "use strict" in Javascript, which I probably should.

------
jasonwatkinspdx
While the benchmark is certainly valid, he general argument is weak and he
comes to a mistaken conclusion.

The argument assumes that compiling a program is a fixed amount of work, hence
a AOT compiler will always have an advantage.

This is wrong.

We can chose how much effort a compiler expends, and this choice has a complex
relationship with the execution speed of our built program. Read Andreas Gal’s
PhD thesis, then look through the source of LuaJIT for an example of how one
can achieve peak execution speed while spending only a fraction of the time
that’s typical inside the compilation machinery.

What this means is that AOT vs JIT vs Tracing is a complex topic with no
simple winner. Real systems will increasingly be hybrids.

Lastly, wtf does Santa have to do with anything? If you’re making a claim,
support it with a logical argument and evidence, not a lame rhetorical appeal.

------
drblast
"Best performance" is irrelevant if the performance of javascript is good
enough.

Maybe this illustrates the dichotemy between traditional engineering and
computer science, but in most other forms of engineering you want just-good-
enough-to-fulfill-the-requirements because any better means you are spending
extra money or doing extra work uneccessarily.

If javascript lets you write a game that runs at a solid 30 frames per second,
and write it easily and portably for free, any additional performance is
overkill.

For many of the simple types of games people play in a web browser, javascript
has been good enough for years. Increased hardware performance will only help
javascript.

<http://drblast.sourceforge.net/tetris.html>

~~~
talmand
Just to expand, in most cases 30fps is considered the minimum while 60fps is
your target. Most people cannot see the benefit above 60fps. As browsers start
using the GPU available on the device in hand then 60fps should be easily
attainable; unless you're doing something crazy complicated.

~~~
jiggy2011
I think the problem comes as soon as you need to do any floating point work
within the Javascript VM , not sure what javascript FP performance is like but
I guess it's not pretty.

------
jmileham
I'm not an ActionScript hero, so I can't really weigh in on its awesomeness,
but the fact that they rewrote it three times and ultimately ended up with a
solid language is to be applauded but not surprising. If you were to put the
perfect language and smartest compiler into (what I percieve to be) a somewhat
kludgy proprietary environment like Adobe's present toolchain, that doesn't
strike me as a recipe for win, though. If I'm wrong about the state of affairs
there, feel free to educate me.

Dusting off the age-old interpreted vs. precompiled fight as a closing
argument strikes me as a little weak as well. If raw runtime performance and
the benefits of static typing were the ultimate measure of a language's
utility, nobody would write Ruby.

The author would probably be wise to read up on disruptive innovation. The
biggest mistake an incumbent can make is to overestimate the importance of the
disruptor's weaknesses while the disruptor is busy eating the incumbent's
lunch.

------
lightblade
I've been a Flash developer first before coming to JavaScript. In many ways,
ActionScript just may be the superior language. A language's performance is
really subjective to its implementation. So lets not argue that. But IMHO, a
language's "usability" depends a large part on its community almost like a
slippery slope. The larger and active the community, the more tools and
libraries are available, the more popular the language get.

------
lukev
Some valid points: ActionScript probably is, objectively, a better language
than JavaScript.

The article, however, comes across as clueless and obnoxious.

------
jrmuizel
This performance claim doesn't seem to match the measurements others have
done.

For example, using the code from <http://iq12.com/blog/as3-benchmark/> which
I've put up here: <http://people.mozilla.com/~jmuizelaar/v8-flash.html>, I get
a score of 2134 with Flash vs 11796 in Chrome. At least on this benchmark, it
looks like V8 is a worthy competitor.

------
Ctech237
I think this has to do with large companies resenting the fact open source
developers spend their time making a free eco system better instead of
improving their own frameworks for free.

I understand that JavaScript has its limitations, and Google tried to address
this with their own language Dart. But this boils down to, you have a 100
billion dollar company serving 1 billion searches a day so you have different
scalability issues than I do. But that’s not my problem. With the current
technologies like Node, MongoDB, Reids, etc… I can build a 1 billion dollar
startup without the same scalability issues that a 100 billion dollar company
has.

I would be quite happy to have a these scalability issues once I have a 100
billion dollar company then it will be my problem. But until then, getting a
start-up up and running is ridiculously hard, the last thing I need is
companies generating truckloads of cash putting their development issues on to
open source developers.

------
mef
Yes, a typed language has a speed advantage over an untyped language, and if
the argument is "which language executes faster", ActionScript will win. But
this post declares that JavaScript is not a "worthy competitor" to
ActionScript, completely ignoring all the advantages JavaScript has that
explain why its usage eclipses that of ActionScript.

------
timc3
Adobe yet again not getting it?

I realize that one person does not the voice of Adobe make, but I would have
thought that he would realize that Javascript is very often not used in
isolation, and more often than not as part of a large suite of technologies
(Databases, network infrastructure, backend code - if not JS).

~~~
jiggy2011
I think he's talking about using Javascript in flash's tradition role, i.e web
games and interactive content.

~~~
randomdata
I was going to comment, if Tamarin is so great, why haven't you integrated it
into the browsers? But in doing my due diligence, I realized that Adobe did
give the code to Mozilla for exactly that.

So this is actually about the language beyond Flash.

~~~
gcp
Wikipedia:

"The project to integrate Tamarin and SpiderMonkey was called
"ActionMonkey",[6] but was canceled in 2008[7] because Tamarin's interpreter
turned out to be slower than SpiderMonkey."

Ironically, it was too slow :P

------
angelbob
So... Adobe is arguing that nobody will ever figure out how to put a better
compiler in front of JavaScript under any circumstances, so we have to pack it
in now?

I realize current JIT sucks in many ways, but seriously... claiming that "we
can put this compiler in front of our stuff and since the other guys can
never, never figure out how to compile first, we will win forever" isn't just
stupid. It seems _willfully_ stupid.

Like, what about the second and successive times you run a given page's
JavaScript, like if the page were in cache. Are they certain that open
source's brain trust can never figure out how to compile that ahead of time?

Really?

~~~
gcp
Not knowing ActionScript, the point seems to boil down to no more than
"statically typed languages will always be faster than dynamic ones". This is
true no matter what, "open source brain" can't fix that.

However, one could make the same argument for C++: Why Python is not a worthy
competitor. Sounds silly? It is, just like the original post.

~~~
VMG
> However, one could make the same argument for C++: Why Python is not a
> worthy competitor. Sounds silly? It is, just like the original post.

Not quite. Nobody claims that python will completely eliminate the need for
C++, but there are people claiming that JS will replace flash.

------
blago
Disappointingly trivial post:

1) I don't know a single person that would seriously argue that dynamically
typed languages can perform better than their statically typed cousins.

2) As we all know, programming is the art of making tradeoff. One common pair
is ease of writing vs. performance...

3) I think Adobe should be more worried about making a flash player/plugin I
can't use to warm my hands by playing video after I come back from lunch.

~~~
regularfry
I wouldn't be so sure about 1). JIT compilers can _in principle_ beat AOT by
taking account of runtime profiling which AOT compilers have to make guesses
at. I don't know how much (if any) of this V8 does, but it's a _hell_ of a
leap to go from "static system 'a' beats dynamic system 'b'" to "all static
systems of type 'A' will inevitably beat dynamic systems of type 'B'".

------
mmcconnell1618
Is this an official Adobe communication or just some guy who will be packing
his desk later today?

~~~
dnvsfn
hahaha, exactly.

------
mmatey
I want to see the benchmarks and the tests used...

------
voidr
Pointless article, JS is not competing with ActionScript in the way that the
author compares it.

Most of the time your app will probably be slow because of the DOM
interactions, not because of your JavaScript, most time is usually spent in
the rendering and fetching stuff from the network.

To give a better viewpoint: You won't write a database engine in Ruby or PHP,
you will write it in C, C++, Java, but you will use PHP/Ruby to interact with
it.

We have low level programming and high level programming for these distinct
purposes. I am sure that if you won't write something in JavaScript you will
probably not write it in ActionScript either.

------
jdietrich
V8 is the catalyst, but it's only a small part of the bad news for Adobe.

There are many horses in the Javascript optimisation race. Chrome is the
faraway leader, but all major browsers have delivered large improvements in
Javascript performance over the past few years. Actionscript has hardly
improved in five years.

<http://iq12.com/blog/as3-benchmark/>

------
nwmcsween
The argument in the article is true but this applies to any AOT language not
just actionscript. A look at two popular 'alternatives' are native client and
a vm in this instance serve two separate issues: sandboxing and
standardization / interoperability. The issue with the latter is standardizing
a bytecode would be complicated and a candidate could possibly be the parrot
vm.

------
mdda
I'm surprised noone has mentioned HaXe[1] : Which is an open source
Actionscript-like language, with types (if you want them), which can compile
down to .SWF, .JS, .CPP or even .PHP. All with an open source tool-chain.

[1] : <http://haxe.org/doc/intro>

------
billybob
In other news, cars are faster than trucks, so clearly there is no valid
reason to drive a truck.

------
acdha
Entertaining, given how bad the Flash toolchain is: I'd have to be in a very
bad performance spot to consider giving up a stable, functioning debugger,
real text editor, usable tools and high quality APIs.

------
rythie
This screams "Innovator's Dilemma" to me for some reason.

------
billybob
That's nice, except I uninstalled Flash on my machine. It has an abysmal
security history and I just don't need it that much.

------
akavlie
When I saw the domain name I was expecting some juvenile propaganda, rather
than serious analysis. I was not disappointed.

------
bitwize
If Flash weren't a pile of shit. Adobe might have a leg to stand on.

That's a big if.

------
GlennS
Oh, so _now_ Adobe cares about performance.

------
SaltwaterC
While we're at it, can the Adobe folks explain to the rest of the world when
Flash is going to suck less? I mean really. Don't care about the on paper
gibberish.

------
funkah
Oh, I guess all the JS devs who work in the language every day didn't get the
memo.

But in all seriousness, who couldn't have guessed that there would be some
Flash/Actionscript dead-enders? Incredibly unsurprising that this was posted
on adobe dot com.

~~~
tomjen3
I work with Javascript everyday.

And I hate it. It is broken as a language (var hoisting, this can mean pretty
much whatever you want it to, no types, not even a good damm s32int).

But it works on all platforms and so it will always beat Flash.

~~~
michaelmior
Agreed that var hoisting can be tricky before you encounter a situation where
it break something. (I suspect this happens to most JS devs at some point.
Certainly has to me!)

However, what's wrong with not having types? Sounds like you're just not a fan
of dynamic languages since this isn't a JS-specific issue.

~~~
tomjen3
I am a fan of typeless languages for small project and build files. But js
takes the cake because it doesn't even distinguish between ints and floats.

------
shareme
Yet they bought phonegap anyway..ah huh sure ..

------
cpeterso
Code or STFU.

------
asto
A strawman argument by an Adobe shill. Javascript and V8 aren't competition
because they're faster, they're worthy competition because they're fast enough
for most applications.

------
asto
I just looked up the author. Here's his Linkedin
<http://www.linkedin.com/in/achaudhuri>

_July 2010 – Present (1 year 7 months) specification, design, and
implementation of ActionScript_

Well, that explains a lot now, doesn't it?

