[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.