3 ms·

Kind of a chicken and egg situation, I looked at sciter for a project about a year ago and estimated that it would cost more time/money to get things off the gr

by qppo 6y ago

Kind of a chicken and egg situation, I looked at sciter for a project about a year ago and estimated that it would cost more time/money to get things off the ground in your framework than using my existing codebase and frameworks with larger ecosystems. I can't really commit to sciter and your flavor of JS until it has a larger community, more docs, and more onboarding materials so I can get teams up to speed and working quickly, reinventing fewer wheels, and have more discoverability in your docs and community so I can even know how to do things and what I don't need to rewrite. Some bencharks comparing engine performance to V8 would also be much appreciated.

c-smile 6y ago
1. I've been told that it takes 1..2 weeks for average front end developer to get into Sciter and features that I've added to HTML/CSS to support desktop UI use cases. 2. "larger ecosystems..." Sciter is embeddable and extendable engine, this means that you can extend it by existing native libraries, time proven and effective. Here is how SQLite native namespace looks in Sciter: https://github.com/c-smile/sciter-sdk/blob/master/sqlite/sciter-sqlite.h https://github.com/c-smile/sciter-sdk/blob/master/sqlite/sci... 3. "it has a larger community..." I am aiming not to larger but rather more professional community. Sciter sources contains patches from these dev teams: https://sciter.com/#customers https://sciter.com/#customers Security audit was made by Symantec and 3 more AntiVirus vendors. All that... Source code base is compact enough for a C++ programmer to get into when needed. "Some bencharks comparing engine performance to V8" Slower than V8 but faster than Python 3. But script performance in Sciter is not that critical (never been a bottleneck) for simple reason: script treated as a glue between native function calls. If you need something to run with bare metal speed - just provide native function(s) for this functionality. JS approach in this respect is simply crazy: to run something fast add megatons of JIT implementation and then another twist: WebAssembler. Why not just to compile what is needed with C++ into native code and call it? Again, Sciter is embeddable and extendable by design.
- qppo 6y ago
  Very interesting work. I need to re-evaluate in the future.

by qppo 6y ago

c-smile 6y ago

1. I've been told that it takes 1..2 weeks for average front end developer to get into Sciter and features that I've added to HTML/CSS to support desktop UI use cases. 2. "larger ecosystems..." Sciter is embeddable and extendable engine, this means that you can extend it by existing native libraries, time proven and effective. Here is how SQLite native namespace looks in Sciter: https://github.com/c-smile/sciter-sdk/blob/master/sqlite/sciter-sqlite.h https://github.com/c-smile/sciter-sdk/blob/master/sqlite/sci... 3. "it has a larger community..." I am aiming not to larger but rather more professional community. Sciter sources contains patches from these dev teams: https://sciter.com/#customers https://sciter.com/#customers Security audit was made by Symantec and 3 more AntiVirus vendors. All that... Source code base is compact enough for a C++ programmer to get into when needed. "Some bencharks comparing engine performance to V8" Slower than V8 but faster than Python 3. But script performance in Sciter is not that critical (never been a bottleneck) for simple reason: script treated as a glue between native function calls. If you need something to run with bare metal speed - just provide native function(s) for this functionality. JS approach in this respect is simply crazy: to run something fast add megatons of JIT implementation and then another twist: WebAssembler. Why not just to compile what is needed with C++ into native code and call it? Again, Sciter is embeddable and extendable by design.

qppo 6y ago
Very interesting work. I need to re-evaluate in the future.