OSNews

Yes, I do wish they would. Because JavaScript is such a poorly defined language engines like V8 have to use heuristics on it over time. JavaScript didn't suddenly become a world beating language environment because of V8. Those who do code shit like node.js.

Depends of what version of are you targering to, if you talk about an old version of javascript then yes, if it is a newer specification like Harmony then no.

Edited 2013-02-05 00:16 UTC

It not poorly defined. JavaScript is a proper programming language with a proper language specification.

JavaScript is simply dynamically typed.

There are some oddities that come up thanks to the JavaScript Semi-colon insertion mechanism and the function scope (i.e. Hoisting).

There are some evil things that the programming language allows you to do (some of the more evil things can be effectively disabled with "Use Strict").

JavaScript has a pretty strong community and if you really get your head around it you can do some very neat things that you can't do in other languages easily.

As another has said the newer specifications are pretty good.

As for the viability of things like node.js, Trello and other quite robust web apps that were developed in reckon time pretty much disproves the notion that it is rubbish.

Edited 2013-02-05 00:35 UTC

The "almost" is the key word here.

As the original poster suggests, why should I (an end user) have to have poor performance (and a lot of resources uselessly being used) because the programmer of my applications did not know how to implement them in some native language?

Edited 2013-02-05 00:24 UTC

Why not, javascript is widely use for server side, mobile and desktop applications, and it is faster than Python BTW.

Edited 2013-02-05 00:29 UTC

Firstly we must have a different definition of "almost".

Secondly these days the main cost of any project is not the hardware, but rather the development costs. Most cheap mobile phones have more memory and processing power than we had a decade ago. I doubt you will even notice it.

Thirdly I expect there is more client side processing on a lot of webpages and applications that you probably aren't aware of.

I been writing a Samsung TV applications. Everything is done via client side processing ... it works fine on a TV's which is running some flavour of Linux and probably has either MIPS or an ARM processor.

"JS VMs are almost as fast as compiled code these days. I wish people would fact check this stuff."

That is a fantasy:
http://benchmarksgame.alioth.debian.org/u32/which-programs-are-fast...

Also you will find most small JS applications spend a lot of time executing library functions written in C and as the application has more and more actual Javascript, performance really degrades. This degradation is both execution speed and memory usage.

What is really surprising is in that link it shows how the Go programing languaje that is suposed to be native is slower than javascript.

Include Python in that chart - as the high level dynamic glue language JavaScript is meant to replace in Gnome application development - and JS will indeed look in the same ballpark as C.
C to JS a factor 3.5, JS to Python a factor> 15
Plus, I expect the tooling and engines for JS to grow faster than those for Python

Depends what the code is compiled to doesn't it?

There is native and there is byte code. I meant the latter. V8 performance doesn't stack up bad against Mono and Java for something that is JIT compiled.

Edited 2013-02-05 09:33 UTC