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

We've been lied to: JavaScript is fast

jyelewis.com

Post reply on HN
Print view View original

31–40 of 86 posts

Re: We've been lied to: JavaScript is fast

#31

Post by snek_case »

tannhaeuser wrote: post #30
snek_case wrote: post #28

Earlier quoted context omitted.

I recently got back to a web app with node I'd been working on two years ago, and I'm finding packages deprecated, command-line arguments that no longer work, etc. Lots of breaking changes all the time. There's definitely something worse than average with the node development experience. Things are quickly changing and at the same time very poorly documented.

Well, why did you choose packages that change quickly and are poorly documented then? There are packages that, OTOH, have up to zero dependencies, and haven't changed in years; if you consider those stale, I guess nobody can help you.

I chose the most basic and common packages I could find (terser and rollup), and the changing, no longer valid command-line options I was talking about were command-line options of the npm package manager.

Re: We've been lied to: JavaScript is fast

#32

Post by andai »

snek_case wrote: post #28
JoeBot3000 wrote: post #7

Earlier quoted context omitted.

I don't know that I agree with this article, while there is absolutely a problem with package/framework/build tools churn that makes development super painful, I don't feel that developing with JavaScript has been any more painful than developing with VB, C#, PHP etc was in the past. All languages have their pain points, and modern JS/TS, while undisputably having their quirks, aren't particularly more quirky than JS…

I recently got back to a web app with node I'd been working on two years ago, and I'm finding packages deprecated, command-line arguments that no longer work, etc. Lots of breaking changes all the time. There's definitely something worse than average with the node development experience. Things are quickly changing and at the same time very poorly documented.

I took a break from my 3rd attempt at learning Node (which I have since abandoned permanently) to learn C and write my own software 3D renderer in it. I found this, to my surprise, a vastly simpler and more pleasant experience.

Re: We've been lied to: JavaScript is fast

#33

Post by JoeBot3000 »

tannhaeuser wrote: post #30
snek_case wrote: post #28

Earlier quoted context omitted.

I recently got back to a web app with node I'd been working on two years ago, and I'm finding packages deprecated, command-line arguments that no longer work, etc. Lots of breaking changes all the time. There's definitely something worse than average with the node development experience. Things are quickly changing and at the same time very poorly documented.

Well, why did you choose packages that change quickly and are poorly documented then? There are packages that, OTOH, have up to zero dependencies, and haven't changed in years; if you consider those stale, I guess nobody can help you.

The majority of packages in JS land change quickly and are poorly documented, unfortunately :(

There certainly are stable packages, but sometimes to do what you need to do there is no other option.

Re: We've been lied to: JavaScript is fast

#35

Post by tgsovlerkhgsel »

JavaScript has incredibly good async APIs (promises, async/await, and the seamless integration between the two).

As a result, I'm convinced that software written in JS is much more likely to actually perform long-running (IO-bound) tasks in the background/in parallel, simply because it isn't a huge pain to do it.

The actual execution speed matters a lot less at that point.

Re: We've been lied to: JavaScript is fast

#36

Post by codyswann »

tasogare wrote: post #18
armchairhacker wrote: post #12

JavaScript is still really slow compared to compiled languages - C, C++, even Java. That super-simple benchmark even after JIT is still 2-3x as slow as the C version, and more complex code can’t be optimized nearly as well. I can confidently say that games and apps in the browser and Electron are noticeably slower than other apps. You don’t see many web games because the graphics required for games today can’t really…

It's fast now because a bunch of mega-corps (Google, Apple, Microsoft before dropping the ball) put a huge investment in making JavaScript interpreters fast.

Is that a problem?

Re: We've been lied to: JavaScript is fast

#37

Post by pjscott »

strken wrote: post #13

It was never slow. The event loop is very performant compared to a language with a GIL and a culture of synchronous IO (looking at you, python and ruby), and V8 is amazing. I notice that the author doesn't give any links to claims that JavaScript is slow, and the first two pages of search results are either discussions of how fast JS is or guides to JS performance. Who exactly was lying?

The old JS interpreters were actually quite slow! That's why they made V8 in the first place. Speed was its big selling point.

Re: We've been lied to: JavaScript is fast

#38

Post by titzer »

pizlonator wrote: post #23

Those are some really bad benchmarks. JavaScript is probably like 10x or 100x slower than C or similar languages when you write something bigger and any of the following happens: - the ratio of code size to run time is too big. Then the jit can’t keep up. - you use a lot of value types. Them be structs in C, no need for allocation. In JS them be objects. The JS VM will try to escape analyze them, and it will succeed…

I've been thinking a lot about this over the years. Having been a dyed-in-the-wool Java VM person for years, and then also working on JS, I started to see the marketing speak I blabbed for years just kind of disappear in the face of huge applications.

JavaScript, Java, C#, generally all JITed languages will eventually end up exhausting the size of their JIT code caches. You just gotta hope that your hot paths are contained in there and that the JIT balances its hunger for deep inlining with the need to not overcompile. Because there's nothing worse for a JIT when the entire application is just a tepid soup and there are no hotspots. Then you aren't getting escape analysis, you end up with tons of polymorphism, and generally, performance suffers.

Despite 20 years working on JITs and dynamic optimization, I am more convinced than ever you just can't beat static compilation and programs designed to not over-allocate, to not overabstract with too much polymorphism, closures, and heavy allocation. Programs still need to be a bit miserly to get maximum performance.

Re: We've been lied to: JavaScript is fast

#40

Post by pjscott »

kccqzy wrote: post #19

Stop writing C code like this author does! C is a language for experts and there are lots of things that are wrong here. Especially when writing benchmark code, when you do want the compiler to optimize. > int main() The easiest way to find someone who's inexperienced in C is to find someone who declares a function that takes no arguments with an empty pair of parentheses. In C but not C++ you need to write "void" in…

The compiler used, Clang 13.0.0, does indeed optimize out everything except for the "return 0;" at the end unless you compile with -O0 to disable optimization. I'm not sure whether the author benchmarked with -O0 or benchmarked a no-op, but either one is probably a mistake.
Post reply on HN