4 ms·

I wonder why they used QuickJS instead of a faster engine like V8 or JSC?

numpad0 5y ago
I wonder what are the global scale environmental consequences will be, long term. Could it make a difference between couple nuclear reactors urgently needed and no longer needed?
longstation 5y ago
My guess is probably the QuickJS has less resource usage compared to the more performant V8. UPDATE: Now I have read the linked article, here is the reasons (copied from the article): API and integration principles are close to what TIScript uses – it took me just 1 month to add QuickJS to Sciter core. And 4 months more to expose HTML/CSS runtime to JS. Relatively compact implementation – QuickJS is slightly more fatty (by 100 kb) but still in acceptable range. For the note: full version of V8 is about 40 mb – 5 times larger than Sciter itself; Liberal MIT license. Sciter cannot use GPL/LGPL code – many customers expressed this requirement; Readable source code. Well… almost readable.
zamadatix 5y ago
There is a section with the key reasons it was picked, in particular: "Relatively compact implementation – QuickJS is slightly more fatty (by 100 kb) but still in acceptable range. For the note: full version of V8 is about 40 mb – 5 times larger than Sciter itself"
- samus 5y ago
  40mb is just nuts. These days, jlink would allow me to shrink a Java JVM down to something like that. And that would already include some nontrivial batteries, which Javascript doesn't AFAIK.
- gigel82 5y ago
  A full V8 is 8Mb on 32bit Windows and 12Mb on 64bit Windows, so not sure where that 40Mb is coming form.
  - c-smile 5y ago
    Pure V8 - yes, close to 8 Mb - that is still larger than whole Sciter that beside of script VM contains HTML/CSS/Graphics, etc. 40 Mb came from Node.JS distribution (V8 + native runtime = node.exe). Sciter is more comparable to NodeJS as it includes good chunk of NodeJS alike runtime too.
    - ncann 5y ago
      While I appreciate the conscious size-saving effort, I need to ask: is 30 MB difference that big of a deal for desktop applications nowadays? A random Electron app that I download will easily take up hundreds of MBs disk space.
      - CamperBob2 5y ago
        That's the wrong question, IMO. The right question is, "Does it need to be that big?" The answer is "No." Things that are too big are usually composed of smaller things that are also too big.
        8note 5y ago
        The proper question is: what's the cost of it being that big? Is it acceptable? Is it worth making it smaller?
        WastingMyTime89 5y ago
        I personally don’t think it’s acceptable and the disregard for files sizes generally extends to disregard for RAM usage which is even more unacceptable. Sadly I don’t really have a choice regarding using most of these apps.
  - CamperBob2 5y ago
    Is it even possible to distill V8 into a single Windows DLL anymore? The version I use was about 3.5 MB in 2013. I tried updating it a couple of years ago, but quickly gave up and backed away, groping for the doorknob.
c-smile 5y ago
"a faster engine like V8" It is actually not the fact that V8 in context of Sciter alike use cases will be faster. Consider this statement: document.body.patch(<body>Hello world</body>); In case of Sciter this expression runs with native speed. JSX is built-in and element.patch() method is native. While in browser, in case of ReactJS, you will run that patch() (reconciliation procedure ReactDOM.render) with JS VM speed as that algorithm is implemented on JS/TS. The whole point of Sciter is in its embeddability - you can add native objects of your app callable directly from script. Check this example of native object: https://github.com/c-smile/sciter-js-sdk/blob/main/demos/integration/frame.cpp#L8 https://github.com/c-smile/sciter-js-sdk/blob/main/demos/int... So you really don't need V8 JIT infrastructure to achieve max performance - just add native objects when needed.

I wonder what are the global scale environmental consequences will be, long term. Could it make a difference between couple nuclear reactors urgently needed and no longer needed?

longstation 5y ago

My guess is probably the QuickJS has less resource usage compared to the more performant V8. UPDATE: Now I have read the linked article, here is the reasons (copied from the article): API and integration principles are close to what TIScript uses – it took me just 1 month to add QuickJS to Sciter core. And 4 months more to expose HTML/CSS runtime to JS. Relatively compact implementation – QuickJS is slightly more fatty (by 100 kb) but still in acceptable range. For the note: full version of V8 is about 40 mb – 5 times larger than Sciter itself; Liberal MIT license. Sciter cannot use GPL/LGPL code – many customers expressed this requirement; Readable source code. Well… almost readable.

zamadatix 5y ago

There is a section with the key reasons it was picked, in particular: "Relatively compact implementation – QuickJS is slightly more fatty (by 100 kb) but still in acceptable range. For the note: full version of V8 is about 40 mb – 5 times larger than Sciter itself"

samus 5y ago
40mb is just nuts. These days, jlink would allow me to shrink a Java JVM down to something like that. And that would already include some nontrivial batteries, which Javascript doesn't AFAIK.
gigel82 5y ago
A full V8 is 8Mb on 32bit Windows and 12Mb on 64bit Windows, so not sure where that 40Mb is coming form.
- c-smile 5y ago
  Pure V8 - yes, close to 8 Mb - that is still larger than whole Sciter that beside of script VM contains HTML/CSS/Graphics, etc. 40 Mb came from Node.JS distribution (V8 + native runtime = node.exe). Sciter is more comparable to NodeJS as it includes good chunk of NodeJS alike runtime too.
  - ncann 5y ago
    While I appreciate the conscious size-saving effort, I need to ask: is 30 MB difference that big of a deal for desktop applications nowadays? A random Electron app that I download will easily take up hundreds of MBs disk space.
    - CamperBob2 5y ago
      That's the wrong question, IMO. The right question is, "Does it need to be that big?" The answer is "No." Things that are too big are usually composed of smaller things that are also too big.
      - 8note 5y ago
        The proper question is: what's the cost of it being that big? Is it acceptable? Is it worth making it smaller?
        WastingMyTime89 5y ago
        I personally don’t think it’s acceptable and the disregard for files sizes generally extends to disregard for RAM usage which is even more unacceptable. Sadly I don’t really have a choice regarding using most of these apps.
- CamperBob2 5y ago
  Is it even possible to distill V8 into a single Windows DLL anymore? The version I use was about 3.5 MB in 2013. I tried updating it a couple of years ago, but quickly gave up and backed away, groping for the doorknob.

c-smile 5y ago

"a faster engine like V8" It is actually not the fact that V8 in context of Sciter alike use cases will be faster. Consider this statement: document.body.patch(<body>Hello world</body>); In case of Sciter this expression runs with native speed. JSX is built-in and element.patch() method is native. While in browser, in case of ReactJS, you will run that patch() (reconciliation procedure ReactDOM.render) with JS VM speed as that algorithm is implemented on JS/TS. The whole point of Sciter is in its embeddability - you can add native objects of your app callable directly from script. Check this example of native object: https://github.com/c-smile/sciter-js-sdk/blob/main/demos/integration/frame.cpp#L8 https://github.com/c-smile/sciter-js-sdk/blob/main/demos/int... So you really don't need V8 JIT infrastructure to achieve max performance - just add native objects when needed.