> This works if browser is the only application that runs on machine.

I don't understand what you mean - individual applications within a multi-application system can absolutely utilise multiple cores. It isn't true that it won't work. The kernel schedules all the tasks of all applications across the available cores.

And even if you have many applications running, most of them don't need multiple cores all the time, so it makes sense for each application to be able to use as many cores as possible, when the user is looking at it and doing something.

For example if I'm using my text editor and browsing docs. My text editor only needs tiny a fraction of a core every now and again, but each time I navigate it'd be great if the browser temporarily used all sixteen cores to do that as quickly as possible.

While true one concern is that proliferation of threads/processes per application could reach the point where context switching and thread management alone consume a lot of the capacity. IIRC super computers often need special interconnects and software to minimize the distribution costs of so many cores.

"supercomputers" are designed (typically) to run CPU-bound tasks.

User applications with GUIs are almost never CPU-bound, so the comparison is not really appropriate.

Common misconception. Most supercomputer tasks are communication-bound or memory-throughput-bound, and devs just try to fill the resulting slack with more work.

> User applications with GUIs are almost never CPU-bound

I watch live streams of music producers working with DAWs and they actually end up needing to offload synthesis and filtering to multiple separate machines as they can't do it on one.

Also if you think things aren't CPU-bound then why do you think people spend hundreds or thousands of dollars on CPUs?

I'm the author of a crossplatform DAW. I know what they are capable of. Also, that story of multiple systems is becoming a thing of the past in these days of 32 core ryzen threadrippers.

The vast majority of what the vast majority of users do on computers remains non-CPU-bound. I chose not enumerate all the exceptions, because as usual, they are exceptions.

I'd assume the author of ardour knows what they are talking about! I remember running most things just fine on a dual athlon mp, cubase and ardour. Granted this is quite awhile ago.

This seems contradictory to me.

Most people aren't doing CPU-bound work and there's no point parallelising your application... but people are buying 32-core processors? Why do you think they're doing that?

I'm just a normal developer and I am very frequently CPU-bound in my work, and I see many other people in other fields also CPU-bound. I'd absolutely love to have a massive Xeon in my laptop. I think it'd have a genuine impact on my productivity.

"Just a normal developer" ... you're already in a tiny minority of computer users.

And sure, as someone who regularly spends 4 minutes waiting for my 16 core threadripper to build my application, I appreciate the sentiment.

But ... this is very very far from the majority of computer users do and quite far from what "supercomputers" are used for (frequent, repeated, long lived CPU-bound workloads).

> User applications with GUIs are almost never CPU-bound, so the comparison is not really appropriate.

Video conferencing, JS heavy web browsing, video editing, and gaming are all examples of CPU-intense applications that are becoming increasingly common

Of the things you listed only JS would count as "CPU intense" in the strict definition of CPU as microprocessor unit; the others are typically bound on specialized hardware -- hardware video encoders/decoders, and GPUs.

And, having done plenty of video dev work recently, beyond the codecs and GPUs, it's also memory bandwidth/lock contention/data path that's really key for getting good video performance. We're almost never decoding or encoding video by CPU anymore. If we can avoid it.

Arguably with JS heavy web browsing you're also looking at memory bandwidth or lock contention as a key limitation -- garbage collection in the JS interpreter, fetching and dispatching opcodes, etc. CPU is only part of the story.

Life just became so so very complicated in the 90s when CPU performance started to compltely outstrip main memory and bus performance.

1) I don't tend to think of games as applications with GUIs, but you're right, they really are, and yes, they can be CPU-bound sometimes. However, a game that was actually CPU-bound would be very unpleasant to play. That's not true for the applications that run on super-computers: they just take longer to run that someone would like.

2) video conferencing is not CPU-bound unless you're doing 1-to-many/many-to-1 feeds locally.

3) JS heavy web browsing ... 'nuff said.

4) Very few people do video editing that is CPU bound. Certainly for video editors, it is an issue.

Clearly, I should have said:

  "The majority of applications used by the majority of users are rarely CPU-bound"

But more importantly: even the exceptions are really nothing like "supercomputer workloads".

> While true one concern is that proliferation of threads/processes per application could reach the point where context switching and thread management alone consume a lot of the capacity.

Have you ever played around with BeOS or its community-driven successor Haiku? They are what's called "pervasively multithreaded" such that every single widget in the standard UI toolkit has its own thread. It's literally possible in BeOS/Haiku to lower the priority of a single radio button.

This is an OS designed around early '90s era dual CPU hardware. Considering that they made this choice at that time and still ended up with an OS that's remembered primarily for its performance and responsiveness when multitasking it seems hard to believe that threading overhead itself is too big of a deal even at extreme levels.

> IIRC super computers often need special interconnects and software to minimize the distribution costs of so many cores.

This is for entirely different reasons. The specialized supercomputer interconnects exist to minimize the cost of sharing data across nodes. Basically they provide DMA over a network fabric. It only really matters once your workload is large enough that you can't just throw a larger single machine at it but also impossible to split up in to smaller chunks that would fit within individual nodes.

If you're familiar with NUMA in multi-socket systems (or first-gen Epyc/Threadripper) you can think of the supercomputer interconnects as basically extending that principle up another tier to encompass multiple independent servers.

> It's literally possible in BeOS/Haiku to lower the priority of a single radio button.

This is not true, individual widgets most definitely do not have their own threads. Windows each have their own threads, which is indeed different from virtually every other OS which does not have this (or even allow off-the-main-thread UI operations.)

WPF can have a different Dispatcher per window, but inded, that's a fairly rare capability. I can't say I've ever needed to use this, though.

Win32 in general allows multiple threads each with its own UI event loop and associated windows.

It depends... On Raspberry Pi for example (ARM device) parallel compilation (make ... -j 4) makes its UI completely non-responsive.

The only reasonable option for UI rendering these days (high-DPI monitors) is to delegate rasterization to GPU. CPU is for running application logic. If you would do UI on CPU then this will be the only task your CPU will do. E.g. animations require stable frame rate (60 FPS or more) so UI must run on highest possible priority on your OS.

-j4 on a pi freezes the UI because you're using 100% of all cores continually for minutes - smaller chunks of work and better scheduling (or the "trick" of -j3) fixes this, and it's doubtful that a browser uses 100% of CPU for any length of time.

I know how to tackle such problems.

My comment is rather about "multi-core UI". Many UI tasks have almost real-time requirements (animations, synchronized rendering, video) so they behave as "make -j 4" meaning that the device is just busy rasterizing pixels but not doing anything meaningful.

And all that while we have dedicated powerful (YMMV) GPU that supposed to do those for us.

I don't think you can run layout code on a GPU effectively. It isn't a data-parallel problem.

Obviously actual pixel rendering is is done on a GPU - why would you do it it anywhere else, but that's not what we're talking about here.

It's real-time but not particularly CPU-hungry. Playback an animation and see how much CPU time it actually uses - you'll end up yielding most of the time, so other apps can use the remainder just fine.

If make -j4 makes your UI unresponsive, it is probably due to swapping. The CPU scheduler lowers the priority of CPU intensive tasks over time.

It could be that you need to “renice -5” X11 or something (I think some distributions used to tweak the UI runtime priorities. Not sure if they still do.)

>On Raspberry Pi for example (ARM device) parallel compilation (make ... -j 4) makes its UI completely non-responsive.

Have you tried using nice(1) to set the make's priority lower?

> Sciter's Quark (https://quark.sciter.com) - 5 MB binary and 28 MB RAM by default is probably the lowest what you can get for HTML/CSS/script engine.

That doesn't even run standard HTML/CSS/JavaScript. That fact alone would make me completely ignore it for any possible application.

I really like Sciter, the different script language may be annoying the first day but you'll get used to it, specially after using the Reactor Component, it has the best of both worlds: very good performance and separation of the app code and layout (in my case: Go | html/css). Took me 4 days to write (Go+Sciter) something that took a full month in Qt(C++) and the resource usage is almost the same (using the Skia renderer: linux: 50mb ram, windows: 25mb ram), I just wish the Nim bindings were up to date so that i could get binaries of <1mb? + 5mb(5 being sciter's size), currently with Go it is 13mb+5mb.

> very good performance

This may very well be true depending on the use case, but I'd be very surprised if V8 doesn't just blow Sciter out of the water with regards to performance, like you can be a genius and come up with a comparable engine that's 50x smaller (e.g. QuickJS), but V8 is not big for bigness sake, it's also ~35x faster according to this: https://bellard.org/quickjs/bench.html

I'm mentioning QuickJS here because I couldn't find benchmarks comparing Sciter Script and V8, if anybody has some I'd be interested in seeing them.

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

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.

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

Yes, it uses its own script yet supports HTML5 and CSS2.1 + some CSS3 modules.

But if you just need to create some relatively small utility, let's say, calculator.exe then it is pretty adequate for the task.

If you want to run something that is designed for Web browser then you need browser and server (Electron or Atom for example).

> But if you just need to create some relatively small utility, let's say, calculator.exe then it is pretty adequate for the task.

If making a calculator with web technologies is more important to me than making a very resource efficient one why would I _ever_ use Sciter for this that doesn't give me not proper web technologies to use and neither an actually resource-efficient calculator?

That's probably true for calculator. But if you need some aside application for communication (e.g. Slack, Skype, whatever) accompanying your main workflow then it is better if that will consume as less resources as possible.

But even for more or less feature rich calculator, e.g. something like personal accounting/finances utility, you'd better have flexible UI.

> then it is better if that will consume as less resources as possible.

Which would automatically mean Sciter would not be a good fit for this.

> you'd better have flexible UI.

If that's more important then why not going with proper web technologies?

> 5 MB binary and 28 MB RAM by default

I wonder how WPE [1] compares to that.

[1]: https://webkit.org/wpe/

It's always nice to see you around! Usually I catch threads too late to participate.

Sciter is a really cool technology. However I've always wanted to ask you - do you ever feel that your deviation from standards has reduced your market? I was considering Sciter for a project previously, but ultimately decided against it because it required me to write two separate implementations for desktop and browser.

There's obviously benefits from deviating from HTML / CSS / JS, they're very much products of history. Sciter's native (and seamless) custom HTML tags, some built-in preprocessing, being more immediately feature complete, all just wonderful. I'd just like to hear your specific reasoning, though.

And if you're able to comment on it, how many people maintain this project? It seems like a huge task, but most of the discussions I've seen hint toward it just being yourself.

Finally, how is accessibility support? This seems like a big point, but it's not directly addressed in the documentation I've seen. In one forum post I saw you say that Sciter assigns some screen reader semantics based on a custom behavior tag in the CSS?

> deviation from standards has reduced your market

Just an example why that happens: Sciter got flexes and grid 10 years ago as they are the must for desktop UI. Web platform got them practically only in couple of last years. And it is simply to late to change anything - many customers rely on them. But its quite easy to solve this problem using @media sciter {...} sections. Features are easily transformable: https://terrainformatica.com/w3/flex-layout/flex-vs-flexbox....

Same is about script. classes, namespaces, symbols, async/await were in Sciter 7 years ago - I cannot change too much there. Support of existing customers is very critical for me.

> how many people maintain this project?

I did Sciter by myself only. Beside of customers there are three independent developers (Russia, Brazil and France) that requested and have access to Sciter source tree. I am accepting patches from them and customers. 3 AV vendors independently did security audit of the code. Yet Symantec (Norton Antivirus) provided Accessibility support implementation as for them Section 508 was the must.

Thank you for the quick response!