4 ms·

Note, Sciter does not embed a browser engine but reimplements the DOM/CSS/JS (via QuickJS) logic in C++ which means many familiar web patterns will work, many w

by e1g 4y ago

Note, Sciter does not embed a browser engine but reimplements the DOM/CSS/JS (via QuickJS) logic in C++ which means many familiar web patterns will work, many will not, and many might behave differently. Unlike Electron, Sciter will not be the best option to wrap an existing web app and expect it to work as a desktop app. Partial compatibility tables are at https://sciter.com/developers/for-web-programmers/ https://sciter.com/developers/for-web-programmers/

Waterluvian 4y ago
Honest question: how is ”reimplements in C++” different from implementing their own browser engine? Is it purely the absence of a JS virtual machine and instead compiles JS code directly to C++ and into native code?
- The_Colonel 4y ago
  It does have a JavaScript VM, just slower (QuickJS as compared to electron's V8).
  - EGreg 4y ago
    So what's "Quick" about it? Would having a slower JS engine be outweighed by some other savings? Honestly, the biggest one is memory... Electron is the biggest memory hog I've ever seen, ONE application slows my 16GB macbook to a crawl and it starts swapping to HD. How to stop that?
    - cyber_kinetist 4y ago
      It's "Quick" in the sense that it's a bytecode interpreter instead of a heavyweight JIT, so much faster startup times (although overall compute performance is much slower). And the library is much smaller than more heavyweight engines like V8, so good for reducing overall app size. Recently Facebook had to implement a whole new non-JIT Javascript engine just for the purpose of optimizing startup times for React Native apps (https://github.com/facebook/hermes https://github.com/facebook/hermes). If you consider how even Facebook had to ditch the V8 JIT for their purpose it's totally understandable why Sciter chose QuickJS as their new Javascript engine.
    - The_Colonel 4y ago
      If it's ONE application why do you jump to the conclusion it has to be electron's as opposed to the actual application's fault? Electron has some baseline overhead (~100 MB RAM IIRC), but otherwise it's not difficult to write well behaving applications with it.
      - ale42 4y ago
        An Electon app simply uses much more memory than a native one, there's no way around that...
- e1g 4y ago
  Yes, and the difference is the maturity of the engine. For example, to execute JS files Sciter uses QuickJS which runs ~20-30x slower than V8 JIT [1] and has no support for Intl [2]. Sciter's spin on HTML/CSS is also different [3], which might even be better than the standard DOM/CSS, but different means you're coding specifically against the internals of this packaging/distribution method. [1] https://bellard.org/quickjs/bench.html https://bellard.org/quickjs/bench.html [2] https://test262.report/?engines=v8%2Cqjs https://test262.report/?engines=v8%2Cqjs [3] https://sciter.com/tutorial-learn-sciters-html-components-in-5-minutes/ https://sciter.com/tutorial-learn-sciters-html-components-in...
  - tannhaeuser 4y ago
    > Sciter's spin on HTML/CSS is also different [3] Hmm, that was new to me and quite disappointing TBH. I thought the entire point of an embeddable web rendering component is to leverage existing "standards"/practices, especially CSS' out-of-this-world complexity. Why would anyone in normal mental health condition embrace HTML and CSS for coding apps if the result can't even be used in browsers? I had counted Sciter towards browser implementations; but now I see it does nothing to prevent our fall into a second medieval age once no-one understands the job-security machine that is CSS. What an utter piece of garbage CSS is, counter to the entire point of using markup.
- kybernetikos 4y ago
  > different from implementing their own browser engine Because sciter (at least as I understand it) does not have any intention to be a general browser. It intends to be an application development framework, and is quite happy to behave differently to browsers if doing so aids in that goal.
wener 4y ago
Sciter is like React Native with extra Web like feature and a more flex "jsx".
deleted 4y ago
[deleted]

by e1g 4y ago

Waterluvian 4y ago

Honest question: how is ”reimplements in C++” different from implementing their own browser engine? Is it purely the absence of a JS virtual machine and instead compiles JS code directly to C++ and into native code?

The_Colonel 4y ago
It does have a JavaScript VM, just slower (QuickJS as compared to electron's V8).
- EGreg 4y ago
  So what's "Quick" about it? Would having a slower JS engine be outweighed by some other savings? Honestly, the biggest one is memory... Electron is the biggest memory hog I've ever seen, ONE application slows my 16GB macbook to a crawl and it starts swapping to HD. How to stop that?
  - cyber_kinetist 4y ago
    It's "Quick" in the sense that it's a bytecode interpreter instead of a heavyweight JIT, so much faster startup times (although overall compute performance is much slower). And the library is much smaller than more heavyweight engines like V8, so good for reducing overall app size. Recently Facebook had to implement a whole new non-JIT Javascript engine just for the purpose of optimizing startup times for React Native apps (https://github.com/facebook/hermes https://github.com/facebook/hermes). If you consider how even Facebook had to ditch the V8 JIT for their purpose it's totally understandable why Sciter chose QuickJS as their new Javascript engine.
  - The_Colonel 4y ago
    If it's ONE application why do you jump to the conclusion it has to be electron's as opposed to the actual application's fault? Electron has some baseline overhead (~100 MB RAM IIRC), but otherwise it's not difficult to write well behaving applications with it.
    - ale42 4y ago
      An Electon app simply uses much more memory than a native one, there's no way around that...
e1g 4y ago
Yes, and the difference is the maturity of the engine. For example, to execute JS files Sciter uses QuickJS which runs ~20-30x slower than V8 JIT [1] and has no support for Intl [2]. Sciter's spin on HTML/CSS is also different [3], which might even be better than the standard DOM/CSS, but different means you're coding specifically against the internals of this packaging/distribution method. [1] https://bellard.org/quickjs/bench.html https://bellard.org/quickjs/bench.html [2] https://test262.report/?engines=v8%2Cqjs https://test262.report/?engines=v8%2Cqjs [3] https://sciter.com/tutorial-learn-sciters-html-components-in-5-minutes/ https://sciter.com/tutorial-learn-sciters-html-components-in...
- tannhaeuser 4y ago
  > Sciter's spin on HTML/CSS is also different [3] Hmm, that was new to me and quite disappointing TBH. I thought the entire point of an embeddable web rendering component is to leverage existing "standards"/practices, especially CSS' out-of-this-world complexity. Why would anyone in normal mental health condition embrace HTML and CSS for coding apps if the result can't even be used in browsers? I had counted Sciter towards browser implementations; but now I see it does nothing to prevent our fall into a second medieval age once no-one understands the job-security machine that is CSS. What an utter piece of garbage CSS is, counter to the entire point of using markup.
kybernetikos 4y ago
> different from implementing their own browser engine Because sciter (at least as I understand it) does not have any intention to be a general browser. It intends to be an application development framework, and is quite happy to behave differently to browsers if doing so aids in that goal.

wener 4y ago

Sciter is like React Native with extra Web like feature and a more flex "jsx".

deleted 4y ago

[deleted]