> Javascript are still quite slow, inconsistent and memory inefficient outside of trivial benchmarks.

I thought this meme was dead already. Of course, you might not be able to squeeze out the same amount of performance compared to a brilliantly written C or Rust program, but for what it is, JavaScript is pretty damn fast already.

DOM manipulation on the other hand, is still a very common bottleneck people come across when writing typical JavaScript code.

> but for what it is, JavaScript is pretty damn fast already.

It's fast compared to other dynamically typed language implementations but it's still very slow compared to basically all of the popular statically typed languages.

> It's fast compared to other dynamically typed language implementations

true

> it's still very slow compared to basically all of the popular statically typed languages.

Not true.

The main slowdown for javascript (AFAIK) is the checks the optimizer has to put into place to ensure the assumptions it's made about the type are still valid. If, however, those assumptions are valid then javascript ends up emitting pretty much the same assembly that you'd see for and highly optimized statically typed language. In fact, there are some circumstances where it can beat a language like C++ or Rust due to the fact that it has to incorporate runtime information into optimizations.

With C++ or rust, if you add dynamic dispatch, unless you are doing PGO and whole program optimization, you are pretty much sunk with 2 memory lookups on every function call. This is the case where javascript can end up beating C++/Rust.

(All of this is talking about hot code after warmup. During the initial execution javascript will almost certainly always be slower).

Part of the proof of this was asm.js, the precursor to wasm. V8 at the time it was introduced could execute asm.js nearly as fast as what firefox could do with it's optimized asm.js compiler. That is, when you stripe out all the actions that make javascript slow, it very often ends up being just as fast as a compiled language.

What stuff ends up making it slow? Generally speaking, stuff that makes the types unpredictable (adding fields, removing fields, sending in a number and a string and expecting the VM to be able to handle both).

You can see a lot of this writeup around the discussions about why Dart was originally "optionally typed". Basically, the entire selling point to make dart fast was simply to remove the abilities to dynamically change types like you have in javascript. With that, the VM authors at the time were capable of making a VM that's every bit as fast as what Java has.

> With C++ or rust, if you add dynamic dispatch, unless you are doing PGO and whole program optimization, you are pretty much sunk with 2 memory lookups on every function call. This is the case where javascript can end up beating C++/Rust.

GCC at least is capable of speculative devirtualization by using local heuristics, without PGO. And of course it is capable of devirtualizing in many cases when the knowledge actual type can be constant-propagated.

Also note that the vast majority of calls are not dynamic in C++ (as opposed to most dynamic languages), so devirtualization is significantly less impactful.

Fair point, AFAIK C++ templates are pretty heavily used to avoid a dynamic dispatch. Couple that with the fact that polymorphic OO has fallen out of favor generally and I could see this mattering a lot less now-a-days.

> That is, when you stripe out all the actions that make javascript slow, it very often ends up being just as fast as a compiled language.

ok...

> In fact, there are some circumstances where it can beat a language like C++ or Rust due to the fact that it has to incorporate runtime information into optimizations.

People used to make the same claim about Java and in every single example I've ever seen the Java/Javascript is extremely optimized, performance isn't consistent across VM versions, and the C++/Rust is extremely naive (usually allocating unnecessarily and not using arenas in hot paths that are allocation heavy).

absolutely spot on, there was a time when Hotspot was going to bring Java to the promised land.

It never happened.

None of these tests really show JS winning, but they are showing that it's within spitting distance of C++ in multiple tests [1]

And, you can look at the code yourself, most of the examples read pretty much exactly the same as their C++ counterparts.

Mind you, this is also a test that looks at execution start to finish and doesn't give warmup time (which will always favor statically compiled languages).

> performance isn't consistent across VM versions

That's true for C++ compilers, so why would you expect performance to remain constant with a JIT compiler?

[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

JustJS would like a word https://www.techempower.com/benchmarks/#section=data-r20&tes...

Trivial benchmarks where all of the significant data structures and networking are done in C++ and the tiny amount of Javascript is just passing some strings around. I guess it's "fast" if you can restrict yourself to little more than hello world where you do nothing more than pass a few strings to functions written in faster languages.

Notice that in the Java, C#, Go, Rust, Swift or Ocaml examples almost all of the underlying data structures and much of the networking stack are built in the respective language. This is not possible with Javascript, Python, Ruby etc. because it would be ludicrously slow and extremely memory inefficient.

I think what cracks me up about this conversation is that it's an almost verbatim repeat of a conversation I had on reddit a few weeks ago.

There's a certain segment of the developer population that I don't think realizes just how fast C and C++ are. Javascript is _relatively_ fast when compared to other dynamic languages, but not when compared to C, C++, FORTRAN, etc.

The take I have is that with a dynamically typed language you still have a static analysis step. It’s just that the analysis happens in your and other developers’ brain and it is objectively worse. I honestly can’t think of a single thing in favor of dynamic typing.

I write Clojure in my day job and it’s insane how often we have issues where it would have been immediately caught by a static type check.

May I interest you in some unmentioned static analyzer possibilities for Clojure: https://github.com/clj-kondo/clj-kondo https://github.com/jonase/eastwood You seem dissatisfied with Clojure in your day job -- I am sure that there are others that would be happier in your situation.

I'm aware of these, but thank you nevertheless. Clojure has plenty of nice things balancing the scales, so it's not all pain and misery!

I'd love to learn more. Are you part of a large team (enterprise or SMB, whatever you can share)?

How have you experienced using Type Clojure, spec, Malli, etc. to determine correctness?

I've only worked on solo projects with Clojure, with most of it fitting into my head. I imagine with teams of size N > 1 things can change quite a bit.

> Javascript are still quite slow

Can you describe your usecase for which JavaScript is slow? There are many languages that are slower than js like python or elixir, but they are doing just fine, that's why I won't agree that js is slow, but sure there are cases for which js just wasn't designed, and any CPU intensive task will be slow, but there are ways to get around it as well.

> Dynamic typing also makes a ton of optimizations basically impossible and even after monumental efforts languages like Javascript are still quite slow, inconsistent and memory inefficient outside of trivial benchmarks.

Please provide evidence for this extreme claim. I can point to benchmarks[1] where JavaScript is competitive with or even better than compiled static-typed languages like Java.

(any argument that those are "trivial benchmarks" is automatically invalid without actual empirical evidence)

[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...