Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript is Dead. Long Live JavaScript

peter.michaux.ca

Post reply on HN
Print view View original

61–69 of 69 posts

Re: JavaScript is Dead. Long Live JavaScript

#61

Post by igouy »

nxn wrote: post #32
azakai wrote: post #18

Earlier quoted context omitted.

1. JavaScript's speed is actually not far from Mono's now. And constantly getting closer. 2. I don't think anyone but Microsoft would support .NET bytecode in the browser, simply because Microsoft controls .NET and has patents on it. It would take a lot more to reassure other browser vendors than Microsoft's existing CPs. 3. Running dynamic languages on Mono is slow. Look at the speed of all the dynamic languages on…

>> 1. JavaScript's speed is actually not far from Mono's now. And constantly getting closer. http://shootout.alioth.debian.org/u32/benchmark.php?test=all... >> 3. Running dynamic languages on Mono is slow. Look at the speed of all the dynamic languages on Mono (or the JVM for that matter), and compare them to native implementations of dynamic languages, in particular JavaScript and Lua. The native implementations bea…

What does "not fair" mean? (A fable)

They raced up, and down, and around and around and around, and forwards and backwards and sideways and upside-down.

Cheetah's friends said "it's not fair" - everyone knows Cheetah is the fastest creature but the races are too long and Cheetah gets tired!

Falcon's friends said "it's not fair" - everyone knows Falcon is the fastest creature but Falcon doesn't walk very well, he soars across the sky!

Horse's friends said "it's not fair" - everyone knows Horse is the fastest creature but this is only a yearling, you must stop the races until a stallion takes part!

Man's friends said "it's not fair" - everyone knows that in the "real world" Man would use a motorbike, you must wait until Man has fueled and warmed up the engine!

Snail's friends said "it's not fair" - everyone knows that a creature should leave a slime trail, all those other creatures are cheating!

Dalmatian's tail was banging on the ground. Dalmatian panted and between breaths said "Look at that beautiful mountain, let's race to the top!"

Re: JavaScript is Dead. Long Live JavaScript

#62

Post by igouy »

azakai wrote: post #36
nxn wrote: post #32

Earlier quoted context omitted.

>> 1. JavaScript's speed is actually not far from Mono's now. And constantly getting closer. http://shootout.alioth.debian.org/u32/benchmark.php?test=all... >> 3. Running dynamic languages on Mono is slow. Look at the speed of all the dynamic languages on Mono (or the JVM for that matter), and compare them to native implementations of dynamic languages, in particular JavaScript and Lua. The native implementations bea…

1. The Alioth results are not necessarily final - they compare a single JS engine, and we have several fast ones now (SpiderMonkey with type inference can be significantly faster on some benchmarks, for example). Even so, the median speed there is 2X, which is fairly close. Admittably there are some bad cases though, in particular pidigits (badly written benchmark code? bug in v8?). 2. It is true that JS on Mono has…

>>in particular pidigits1) Always read the program source code!

Why the performance difference between the C# Mono #2 program

http://shootout.alioth.debian.org/u32/program.php?test=pidig...

and the C# Mono #3 program?

http://shootout.alioth.debian.org/u32/program.php?test=pidig...

2) Always read the program source code!

Why the fast fast fast V8 regex-dna performance?

http://shootout.alioth.debian.org/u32/program.php?test=regex...

Re: JavaScript is Dead. Long Live JavaScript

#63

Post by yid »

aufreak3 wrote: post #60
kbd wrote: post #2

Great and thorough article. Here's a TLDR: * Javascript has some warts, and here are some examples. * It's going to take way too long to get these fixed to the point that we can actually start using new versions of Javascript because of slow browser adoption. * To get around this problem, people are treating Javascript as a compilation target for other languages, the most prominent example being CoffeeScript. * Discu…

What if the standard could be changed from a language to a runtime specification? For example, a subset of LLVM assembler could play the role of a substrate (very much like what NaCl is doing) and leave the language part open. Runtimes with sufficiently rich capabilities can evolve over a much longer period than languages. This could liberate client-side coding from language specific-ness just like it doesn't matter…

This is a great idea, and I agree NaCl is the most exciting thing I've seen in a while. However, the modern JS engines already have JIT compilers for JS. As these improve more, JS effectively becomes your "bytecode". That's also an entirely reasonable direction that maintains backward compatibility.

Re: JavaScript is Dead. Long Live JavaScript

#64

Post by petermichaux »

seanp2k wrote: post #49

I really hate when "X is dead; long live X!" is misused like this. The original phrase is "The king is dead; long live the king!", used when the OLD king died and the NEW king takes over. Googling around, I see tons of misuse: Example of bad usage: "White Stripes are dead (long live white stripes)" Example of proper usage: "Palm is dead; long live Palm!" (this would mean that Palm got acquired or reformed) "Paper is…

They didn't say "The King Henry VIII is dead. Long live the King Edward VI". In the JavaScript article, The "OLD king" is "JavaScript the source language". The "NEW king" is "JavaScript the compilation target". So the idea of old and new is in there. Sort of. :-)

Re: JavaScript is Dead. Long Live JavaScript

#65

Post by bzbarsky »

masklinn wrote: post #57
bzbarsky wrote: post #51

Earlier quoted context omitted.

Actually, the forEach version can end up faster than the let version... especially if you self-host forEach so that the JIT can do its job (e.g. inlining the LIB_addEventListener calls so there aren't actually any function invocations, etc).

> Actually, the forEach version can end up faster than the let version... Theoretically maybe, but I've yet to see that. A regular `for(;;)` is generally 3-5 times faster than using `Array.prototype.forEach`. Re. JIT, hand-rolling a foreach in javascript can be up to twice as fast as the native one, depending on the features you leave out.

> Theoretically maybe, but I've yet to see that

Compare the let version to the code in https://bugzilla.mozilla.org/show_bug.cgi?id=602132

Re: JavaScript is Dead. Long Live JavaScript

#66

Post by nxn »

bzbarsky wrote: post #54
nxn wrote: post #32

Earlier quoted context omitted.

>> 1. JavaScript's speed is actually not far from Mono's now. And constantly getting closer. http://shootout.alioth.debian.org/u32/benchmark.php?test=all... >> 3. Running dynamic languages on Mono is slow. Look at the speed of all the dynamic languages on Mono (or the JVM for that matter), and compare them to native implementations of dynamic languages, in particular JavaScript and Lua. The native implementations bea…

> which is already approaching a limit of how fast it can go Do you have data to back this up? At least SpiderMonkey has projects in the works that give significant speedups on various workloads already, and lots of headroom left... I would not be surprised to see another factor of 5 or so speedups on various code in the next few years in JS implementations.

"At Google I/O they mentioned V8 is about as fast as it will get." from: http://news.ycombinator.com/item?id=2669494

Yeah I know, it's not a proper citation, I tried to find where exactly that was said at Google IO but found nothing so far. Either way, I didn't question it at the time I read it because given how dynamic JavaScript is I'd imagine there's only so much you can do to speed it up. Then again, this was coming from Google, and for all anyone knows the cause might just be them focusing more on Native Client instead of V8 for apps that need performance.

Re: JavaScript is Dead. Long Live JavaScript

#67

Post by nxn »

igouy wrote: post #61
nxn wrote: post #32

Earlier quoted context omitted.

>> 1. JavaScript's speed is actually not far from Mono's now. And constantly getting closer. http://shootout.alioth.debian.org/u32/benchmark.php?test=all... >> 3. Running dynamic languages on Mono is slow. Look at the speed of all the dynamic languages on Mono (or the JVM for that matter), and compare them to native implementations of dynamic languages, in particular JavaScript and Lua. The native implementations bea…

What does "not fair" mean? (A fable) They raced up, and down, and around and around and around, and forwards and backwards and sideways and upside-down. Cheetah's friends said "it's not fair" - everyone knows Cheetah is the fastest creature but the races are too long and Cheetah gets tired! Falcon's friends said "it's not fair" - everyone knows Falcon is the fastest creature but Falcon doesn't walk very well, he soar…

Ok, sorry for using the term "not fair", I should have probably said that it's "unsound" to judge the speeds of current dynamic languages on mono/.net to the speeds of v8, SpiderMonkey, etc. The cause being that the speeds of the latter were fueled by very high browser competition and a lot of resource investment. Dynamic languages on .NET got the benefit of neither of these, so it should not be surprising that they are slower than their native implementations (which also get better funding/bigger communities). It would have made more sense if Microsoft or other companies threw millions of dollars at the Iron* languages and still couldn't make them fast.

Re: JavaScript is Dead. Long Live JavaScript

#68

Post by nxn »

Groxx wrote: post #50
nxn wrote: post #35

"Optional Parameters and Default Values" Since JavaScript will still invoke a function call even if the number of arguments don't match up, parameter defaults will not completely eliminate all the problems he lists. function(a = 1, b = "Smith", option = {}) { .. } Will still break upon trying to invoke it without parameter 'b' since param 'option' will just take its place while option will become an empty object. Fur…

I'm very much in agreement with objects-as-named-params. Default params just mitigate the problem, ambiguous function calling still rears its head as soon as you have multiple optional arguments of the same type. As to the "option = option || {}", he was referring to the ultimate "option = {}" assignment if you passed a falsy value (0, "", false), which is different than if you didn't pass a value (undefined). Which…

Ahh, I see. The thing is, I can't think of a single way to make {} be treated as false in the boolean context, so 1) I don't think you'd ever need anything more than "option = option || {}", 2) I think the example would have been better off using an integer or string where you actually might have to use the ugly long format.

EDIT: Unless of course you get some non object value passed in and you want to be sure to keep it regardless of whether or not it is falsy. Not sure why you'd want to do that -- I am sure I would NOT like to see someone do that if I had to deal with their code.

Re: JavaScript is Dead. Long Live JavaScript

#69

Post by bzbarsky »

nxn wrote: post #66
bzbarsky wrote: post #54

Earlier quoted context omitted.

> which is already approaching a limit of how fast it can go Do you have data to back this up? At least SpiderMonkey has projects in the works that give significant speedups on various workloads already, and lots of headroom left... I would not be surprised to see another factor of 5 or so speedups on various code in the next few years in JS implementations.

"At Google I/O they mentioned V8 is about as fast as it will get." from: http://news.ycombinator.com/item?id=2669494 Yeah I know, it's not a proper citation, I tried to find where exactly that was said at Google IO but found nothing so far. Either way, I didn't question it at the time I read it because given how dynamic JavaScript is I'd imagine there's only so much you can do to speed it up. Then again, this was com…

Ah, interesting. Yeah, that sounds like they're just planning to stop optimizing V8 or something, since you can clearly do better than that. The type inference branch of Jaegermonkey is already faster than V8+Crankshaft on compute-heavy (as opposed to GC-heavy, where V8's better garbage collector gives it a big edge) workloads, and that's without LICM or smart register allocation or any of the other global optimizations that are still coming online.

It's unfortunate that Google is deciding to focus on Native Client, with its portability issues, if that's what's going on.

Post reply on HN