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!"
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.
It was a business intelligence app; the front end rendered graphs and charts based on data over Zend.
We staged out of that architecture by implementing a REST endpoint on top of Zend, and moved our graphing over to the (now-superceded) protovis library.
Our engineers weren't used to worrying about data transfer, so we had to do a little bit of engineering work on the JSON side once we switched out, but the graphs, charts and rendering are VASTLY faster.
That said, it could well be the Flex runtime that added all the badness; flash games definitely render faster than our app did.
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.
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.
This is what I'm having trouble believing. If ActionScript can be "compiled to death", where in this case "compiled" means "to bytecode" then presumably the same thing could happen to JavaScript.
In the V8 environment it should be possible to aggressively optimize the code in question with various command line options. Where is -O5?
The real problem is a lack of an open-standard for JavaScript bytecode. Being able to serve "pre-compiled" JavaScript would go a long way towards improving performance.
Nonsense. JavaScript bytecode would still be dynamically typed. At best a JavaScript bytecode standard would be equivalent to a compressed AST. That still might be a useful thing to have, but it wouldn't improve runtime performance.
Well, the problem (one problem) is that Javascript has no typing system. This makes running valid javascript code super, super slow at times. You can't promise to a javascript interpreter that you will always and only use the variable i_am_only_ever_an_integer as an 8 bit integer. This makes lots of things super slow.
Of course you can promise types to the JS engine. Ints in particular are easy. With modern type-inferring JITs like SpiderMonkey, an expression like "var x = 3;" will infer x to int, and there will be no type checks or unboxing. In more complex cases, you can add "|0". For example:
function f(x) {
x = x|0;
...
}
This has the effect of forcing an int interpretation for the argument, and there will be no type checks or unboxing performed thereafter.
I understand that actually getting speed out of JS for binary data is still quite 'hacky' though, for instance Fabrice Bellard used Typed Arrays extensively implementing his Linux-on-Javascript project: http://bellard.org/jslinux/tech.html
> Of course you can promise types to the JS engine.
Because a variable can always change types, it's actually trivially proven that in a dynamically-typed language, there will always be programs in which the type cannot be inferred.
Well, statically-typed languages have a "dynamic" type too. Consider void * in C and C++ and Object in Java and C#. You have to downcast to do anything with them. That's the equivalent of what JS is doing with its dynamic typing. The basic difference is that the "dynamic" type is the default in JS, and the static type is the default in statically-typed languages.
That is not true. I'm not entirely sure what you mean by "no typing system" so I'll go ahead and assume what you likely meant - no static type system.
Optimizing code written in a dynamically typed language is a pretty well understood problem (now) thanks to the SELF research at SUN and more recently the V8 Javascript engine. Both VMs employ type profiling at runtime to figure out what the compiler should assume the type of a dynamically typed variable should be. It can then emit code that treats a variable like it always has the profiled type - like a C++ compiler would. When such an assumption is broken at runtime, implementations typically fallback to an unoptimized version of the code (V8) to execute the rest of the continuation. Well written code is expected to achieve type stability pretty fast making the fallback overhead insignificant.
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."
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.
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.
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.
For your argument to be believable, you shouldn't make unsubstantiated and prima facie bogus claims. Your post would've have the same message without that claim, but by putting it in it sticks out like a sore thumb and makes the rest of your argument moot for debating purposes.
Actually alot of your really large codebases are internal facing projects. Like airline management systems or hotel inventory and allotment systems. They are generally found where there are deep technical problems and usually require complex workflows to manage. Complex workflows are where you will see a lot of JavaScript utilized. In the consumer web space, generally we try to simply interfaces and reduce the complex nature of tasks. In the corporate world, generally the user will be skilled in the complexities of a UI designed for power users. It is the reason that in some organizations the console or green screen apps still exist. For certain tasks once trained, keyboard based navigation console systems are optimal and save organizations 100's of millions of dollars.
If we follow the analogy: after failing repeatedly to find the Holy Grail, Adobe will get arrested by police just as they are about to attack Castle Aaaaarrrrrrggghhh.
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?
"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.
Do you have to compile different binaries for different platforms on native client? Would you need to compile x86, x64, and ARM binaries separately?
Also, I think the question is how to get performance for dynamic runtimes. Native client isn't inherently dynamic. I guess you could compile Lua into native client and build your app ontop of Lua but then you still have the issue of how to get a performant dynamic runtime.
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.
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...
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.
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).
Download that and the free Flex SDK from Adobe, create a new Flex 4 project and stick this in the Application tag in the generated Main.mxml file and you are done:
<s:Label text="Hello, world!" />
Use an AIR Flex 4 project instead with the same label control and now your app runs on both Macs and PCs (and Linux but not as cleanly) in its own native window with full access to the native file system and the Internet without any AJAX proxy issues.
I admit its not as nice as instant browser compilation but for some class of applications Flash/Flex is very nice.
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.
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.
"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.
I'm sorry but tetris isn't exactly state of the art in game design these days. We already have tons of games that javascript/html simply cannot even come close to handling. Naturally people are starting to think about how we can get there, while maintaining all the benefits of a dynamic runtime. So the point is that what javascript is today is not good enough, thus the exploration into how to make it faster.
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.
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.
In addition, it has no performance on all the devices that don't support ActionScript at all (iDevices and most Android devices) or where it is abandonware (a few Androids).
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.
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.
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.
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.
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).
But that is the point, its gradually being ignored as there are other ways of achieving the same functionality natively.
Personally I deal a lot with Video on the web, and although I have a Flash player my main body of development is in native implementations and transcoding profiles for Ogg, WebM and using x264 for preview.
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.
"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."
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?
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.
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'".
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.
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.
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.
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.
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.
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.
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.
Compiles to beautiful JavaScript and gives programmers the ability to check types at compile-type. If you've never used it, I'd compare CoffeeScript to an amalgam of Ruby and Python, with a little Haskell thrown in (take a look at how you specify contracts, for example). If you like functional programming, you'll love CoffeeScript:
['fizz' unless i%3] + ['buzz' unless i%5] or i for i in [1..100]
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.
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.
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!"