A point of reference
ben.bucksch at beonex.com
Wed Mar 7 19:31:13 UTC 2018
R Kent James wrote on 07.03.18 19:34:
> I have not attempted myself to profile why this is true, but with all
> of these real-world examples of problems with serious attempts at
> JS-only implementations, you need to question the blanket statement
> "the JS engine itself is very fast and on par with C code". That is
> the assumption we have made for years, but experience has shown us
> that it is not that easy.
Before making drastic architectural decisions, we should investigate
*why* things are slow.
For every app changing from JS to C++, there are 10 apps that change
from C++ to JS.
I've myself led efforts of applications that were C++ being rewritten in
JS, and the result in JS was fast. And much nicer :-). That application
had 5 million users. The old C++ version had only 1 million users, which
shows that the JS re-implementation was a success.
I suspect that there is a common mistake in *how* JS is being used. For
many JS-driven websites, it's pretty clear why they are slow - bad
engineering, e.g. linking several MB of JS library code. We need to find
the issue and fix/avoid it.
More information about the tb-planning