Live data from Hacker News

The V8 Myth: Why JavaScript is not a Worthy Competitor

blogs.adobe.com

71–80 of 100 posts

Re: The V8 Myth: Why JavaScript is not a Worthy Competitor

#71
post #37

Earlier quoted context omitted.

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…

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

Re: The V8 Myth: Why JavaScript is not a Worthy Competitor

#73
post #58

"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 frame…

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

Re: The V8 Myth: Why JavaScript is not a Worthy Competitor

#75
post #44
post #12

Earlier quoted context omitted.

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 modu…

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.

Re: The V8 Myth: Why JavaScript is not a Worthy Competitor

#76
post #71
post #37

Earlier quoted context omitted.

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…

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

Re: The V8 Myth: Why JavaScript is not a Worthy Competitor

#77
post #58

"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 frame…

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.

Re: The V8 Myth: Why JavaScript is not a Worthy Competitor

#78
post #63
post #51

Earlier quoted context omitted.

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 b…

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?…

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

Re: The V8 Myth: Why JavaScript is not a Worthy Competitor

#79
post #51

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 alert("hellooooo"); 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 b…

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.

Re: The V8 Myth: Why JavaScript is not a Worthy Competitor

#80
post #50

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 alert("hellooooo"); 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.
Post reply on HN