| HN Mirror

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

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

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

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

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.

UnnoTed 2195 days ago

You don't need Sciter's script to do the heavy stuff, you can do it in another language and feed the data to Sciter through it's script language, in my case i write Go for the app's backend and write Sciter's script to control the html/css UI, then send data to it by creating a function in Sciter's script and calling it from Go through `window.Call("the_script_function", args)` or if i want to get data from the app's backend: register a function in Go as script function with `window.DefineFunction("function_name", myFunc)` and run it in Sciter's script through the view namespace `var result = view.function_name(args);`.

Sure, I suppose maybe Sciter makes this easier to code, but one could totally do the same in Electron as well, that doesn't seem a good enough reason to not go with HTML/CSS/JavaScript proper rather than whatever Sciter implements.

Well, applications that use Sciter UI are native ones: https://sciter.com/#customers

And applications that use Electron are not. Just because the only reasonable option (for many reasons) to write code there is script. And so each such application will have full blown web browser and web server (NodeJs) under the hood.

What's your definition of "native" though? Sciter interprets "scripts", Electron interprets JavaScript, it'd say both will produce (to varying degrees) interpreted applications. Either of them can run code written in other languages, again with varying degrees of ease, e.g. https://keminglabs.com/blog/building-a-fast-electron-app-wit...

Last time I checked Evernote, mentioned in the page you linked, renders notes under macOS using WebKit, why don't they use Sciter?

> What's your definition of "native" though?

Let's take some typical native GUI calculator application.

The code a) creates window by calling CreateDialog(...,template,...). That template sits in .RC file - that is UI layout and structure definition.

Then you have b) event handling code and c) so called business layer code (a.k.a. data model code) that does calculation that end up in UI again.

Same thing in applications that use Sciter. It is just that UI definitions are not in some proprietary format but in HTML/CSS. Rest is the same - event handling is done either in script (that will end up in some native calls) or directly in native code - Sciter allows event handlers to be defined in native code directly. So Sciter applications are native ones in this regard.

As of EverNote...

EverNote 2.0 was using what later will become Sciter Engine.

Please check my article: https://notes.sciter.com/2017/09/11/motivation-and-a-bit-of-...

At some point they hired technical director who made decision to switch to WebKit. No one knows reasoning behind that very bad decision (IMO) but the company lost innovation momentum somewhere around that time.

My https://notes.sciter.com/ is just a proof that you don't need WebKit for those tasks.

filleduchaos 2195 days ago

> but I'd be very surprised if V8 doesn't just blow Sciter out of the water with regards to performance

V8 in Electron comes bogged down with Chromium and its bloat. Sciter's engine does not. For building UIs, that's a huge difference.