The V8 Myth: Why JavaScript is not a Worthy Competitor | Hacker News Reader

The V8 Myth: Why JavaScript is not a Worthy Competitor

blogs.adobe.com

85 pointscodetonowhere95 comments

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!"

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.

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.

but you have to admit this isn't very obvious or well documented

> 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.

Statically.

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.

The premise of this article is that Javascript's pure dynamic variables lead to slowness.

I'm not sure what your point with this post was because if you litter your C/C++ code with non-static casts, it is also going to be much slower than code without casts.

The parent comment was pointing out that there exist programs in JavaScript in which the types cannot be inferred. All I was saying was that this is not unique to JavaScript, or to dynamically typed languages generally.

Interesting. I didn't know this.

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

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.

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.

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.

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.

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.

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!

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!

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.

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

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.

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.

That was my point, you don't have to believe me, there are a lot of public examples that are not associated with me. In fact I did not want to get into my personal accomplishments, for that very reason. For a post, it can be stated that there are large JavaScript code bases in the wild without justifying such conjecture for the sake of brevity. That is why I said it was conjecture it is an assumption of truth without providing proof, if people are interested they can do the research to make it fact, in their mind, because what they consider to be "large" will be a personal variable as well. I don't feel I made a bogus claim, I just wrote a post and not a dissertation on the subject. In doing so, I drew upon my own personal experiences to formulate my post. If people want to ignore it as bogus they can, or they can simply read my post for what it is and decide to look into it. I don't think I asked anyone to take my post as proof, rather stated my position on the subject at hand. If it appears to not be the case, then I apologize it was not my intention.

Which javascript project did you work on that had several million lines of code?

If you can't tell us that, at least tell us what _kind_ of project it was please.

I don't know what project the OP was working on, but right now I'm working on a crm/accounting/scheduling product with several hundred thousand lines of javascript code. Due to the modular nature of the code base, I don't see any reason why I can't break the million mark and keep going.

Although I probably won't. Because I don't have to.

Because unlike with a traditional code base, much of the functionality is provided by the browser (CSS, HTML, SVG, Canvas, Image Support, Geolocation, Storage, you get my point) and not by external libraries which add to the lines of code.

It was a product for IBM, a platform for NATO and the UN that consisted of several JavaScript platforms.

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.

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.

You can , if you have good communication or a small team.

I have a PHP Project that is about ~200Kloc , ok that's not enormous (and it's about 60% boilerplate) and I can maintain it happily enough but I wouldn't want to let a large team loose on that.

I think I would have heard about it if you'd released something revolutionary using several million lines of JavaScript...

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?

Several, I bet.

"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.

File -> New

Costs about $700 for that privilege.

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).

I've never used Flex in my Flash projects, I just use straight AS3 with FlashDevelop. Requires the Flex SDK to compile but none of the code.

You do not need to purchase anything from Adobe to compile a AS3 project.

edit: I don't mean for this post to be as negative sounding as it may appear, it's not a comment on your abilities.

You don't need to buy anything. Here is an excellent free open source AS3 (and other languages) editor/debugger (for Windows):

http://www.flashdevelop.org/

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.

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

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).

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.

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.

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.

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

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

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.

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.

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).

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

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.

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

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?

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.

> 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.

They actually have various ways to compile Python. So that's an especially apt comparison :-)

Well, to be fair, the article does start with the warning that this is not the opinion of Adobe.

But yes, it seems absurd to say that JIT compilers will never get better, especially given the improvements we've seen in the last few years.

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.

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'".

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

hahaha, exactly.

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

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.

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

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.

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

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

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.

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

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.

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

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

That's a big if.

Oh, so now Adobe cares about performance.

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.

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.

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.

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.

Also no types means no type completion and no refactoring.

You might want to try out CoffeeScript with contracts:

http://disnetdev.com/contracts.coffee/

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]

(fizzbuzz one-liner from http://ricardo.cc/2011/06/02/10-CoffeeScript-One-Liners-to-I...)

That one-liner is awesome! But it also has some evil type conversions in the form of <array> + <array> = <string> hehe

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

Code or STFU.

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.

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?

Reply on news.ycombinator.com