[c-smile]

> V8 doesn't just blow Sciter out

And it really does not - in most of typical UI tasks Sciter is faster.

Reason is in different goals. Sciter is an embeddable engine. Script there is a glue: take output of one native function, transform it, and pass as input to other native function.

In places where UI needs maximum performance applications use native functions in C/C++, Rust, Go, etc. This allows to keep script VM compact and achieve maximum performance without sacrifices. Why do you need JIT or WebAsm (and tons of associated binaries) if you can compile what you need with battle-proof compilers to native code?

So good portions of jQuery were implemented natively. React[or] is also natively implemented - JSX is a part of script syntax (and so uses built-in native compiler), reconciliation (Element.merge()) is also native thus you don't need all that nightmare TS-to-JS, then load ReactJs script, then compile, then JIT-compile/warm-up, etc. All those ...

As of pure script performance ...

Slower than V8 but faster than, let's say, Python.

[fabiospampinato]

> And it really does not - in most of typical UI tasks Sciter is faster.

I'd really like to see some benchmarks about this, could you maybe make Sciter run the test suite QuickJS is benchmarked against and report back? https://bellard.org/quickjs/bench.html

> In places where UI needs maximum performance applications use native functions in C/C++, Rust, Go, etc.

That's cool, but I'm talking about JavaScript performance here, these kind of cross-language computations can totally be coded on top of Electron and I would imagine any other mature similar framework.

> if you can compile what you need with battle-proof compilers to native code?

The compiler might not be the problem here, not even the Chrome guys can manage to write completely memory-safe C++ for example, that's trivial to do in JavaScript and a reason why one might not want to write everything in C++ for example, among other potential reasons.

[c-smile]

> QuickJS benchmarks

Typically we do not do such task in scripts. And indeed who would need ray tracing in script if you have native libraries for that? 100% that number crunching tasks will be slower in order of magnitude than native ones so why to bother?

For the comparison you can try https://notes.sciter.com/ that uses Sciter not just for UI but its logic layer is also using script (https://github.com/c-smile/sciter-sdk/tree/master/notes/res). The application has UI and complexity similar to VSCode, Slack, etc.

It is hard to come up with some formal benchmarks but startup times, CPU/RAM consumption, responsiveness can be estimated.

[fabiospampinato]

> Typically we do not do such task in scripts. And indeed who would need ray tracing in script if you have native libraries for that? 100% that number crunching tasks will be slower in order of magnitude than native ones so why to bother?

Those kind of synthetic benchmarks aren't there because ray tracing is what you would use JavaScript for, but for giving a measurable quantity about the speed of the interpreter.

Put it simply if V8 produces a number that's 10x higher than another interpreter you can be sure that it's going to be faster than that other interpreter pretty much across the board by a significant margin.

By the way V8 can compile some optimized JavaScript that executes at half the speed of optimized C++, not in "order of magnitude" slower, can Sciter do the same? I really don't think so, happy to be proven wrong with some numbers.

So can you run the benchmark suite with Sciter or not? Is Sciter even able to run it properly? Do you think that benchmark does an acceptable job at telling which interpreter is faster between the tested ones or not?

> The application has UI and complexity similar to VSCode

Sure it has, come on man, be real, there isn't even an app menu loading in this thing: https://i.imgur.com/MXw1LZX.png , this thing is crap.

These kind of claims are an insult to all the people working on VSCode.

> It is hard to come up with some formal benchmarks but startup times, CPU/RAM consumption, responsiveness can be estimated.

There are literally just already written benchmarks that one just runs and they output NUMBERS, how is that hard? Compare that to measuring "responsiveness".

[c-smile]

Check this: https://sciter.com/wp-content/uploads/2020/06/ide.png

that one has menu, check menu.htm in that sample: https://github.com/c-smile/sciter-sdk/tree/master/samples/id...

> So can you run the benchmark suite with Sciter or not?

Yes, I may do that but purpose is not clear. Their compiled C versions in Sciter will run definitely faster.

These functions have nothing with UI per se.

Yet, you can extend Sciter with native DirectX or OpenGL code (see: https://sciter.com/sciter-and-directx/) , that will definitely beat any possible browser/Electron solution. So script benchmarks are orthogonal to the reality.

They make sense in Electron case as JS is the only realistic option to write app code. But not in Sciter case. It is not a browser for that matter.