The issue is that this isn't actually an Electron alternative; the author is upfront about this not actually being a browser-compatible rendering engine. It's just a rendering engine that happens to use some subset / superset of HTML, JS and CSS, but it is not compatible with web libraries and components.
As a basic example, SciterJS crashes loading the "hello world" ReactJS project (at least it did last time I tried it - the author recommended I used a custom version of React he publishes). It's perfectly fine to come up with a lightweight cross-platform UI rendering engine (we know we need more of those), but having it web-adjancent while not really web-compatible is a recipe for frustration.
- Element.patch(...JSX expression...) - native VDOM reconciliation implementation.
- Element.append/prepend(...JSX expression...) - DOM population by JSX
- Native support of lifecycle "events": componentDidMount/WillUnmount and componentUpdate.
So after reading the post it seems you switched to a new language for your framework, integrated a new language runtime and implemented all these additional features for that runtime within half a year? And you did that all by yourself? That's pretty incredible.
I really like these and think it'd be great if browsers implemented them.
People upthread are complaining that you can't take some common web libraries and use them in Sciter, but have you given any thought / effort to the opposite? Having a library/polyfill/source translator that allows you to use sciter code in the browser?
These are all great things, but the fact we can't take some well-tested, used-by-millions library from npm and start building on it makes things very confusing.
It also makes skills non-transferable for the millions of web developers out there. Imagine hiring a SQL expert for your project that uses SQOL which is almost SQL but not quite, so everything they learn won't be useful in their future SQL jobs and the quirks / differences will make them pull their hair out and call it quits in short time.
It almost feels like building an entirely new language would be a better choice (maybe TSX+CSS, with no HTML) to reduce frustration if nothing else.
I appreciate the work you're doing on this project, as always.
SQL is a particularly poor choice for your analogy, as there are no two dialects of SQL that are exactly alike, both in basic syntax and much more importantly in performance characteristics. And yet, knowledge of SQL is mostly transferrable between Oracle and Postgres, between MSSQL and SQLite and so on.
Basic skills are very much transferable between e.g. Ruby and Python, despite a ton of differences.
More narrowly, skills are transferable between ReactJS and React Native, despite a ton of component and CSS differences. Skills are transferable between Java-based and Kotlin-based Android development.
So I'd say that a well-defined subset of web APIs, without strategically placed footguns, could be a quite okay target; if code is not directly reusable, it can be easily ported.
That doesn't sound like an "issue", that sounds like a perk. Even the "crashing running ReactJS" part. If my semi truck crashes when I tilt it over on 2 wheels like a motorcycle, I don't call it an "issue".
I don't know. I like small and minimal, synonymous with Fabrice Bellard (TCC and QuickJS!), and I am glad the herd of elephants wasn't dragged in the door! But then again, I am not a front end dev or a full-time coder; I have been coding since 1978, and I don't only reminisce about small OS's and programs, but I think there should be an alternate path on software dev focusing on minimalism. I program in APL/J for starters, and C and Lisp (April at the moment, a subset of APL in Lisp), so I am happy to play with JS using QuickJS. I tried React, but it just exposed my non-front-end eyes to just how layered and large these ecosystems have become. I guess when that's what you work with all day, it's so familiar you take it for granted. I'd love to hear thoughts on this due to my ignorance on the matter. Thanks!
> having it web-adjancent while not really web-compatible is a recipe for frustration
Exactly. What's the point of using HTML/CSS/JS for a desktop UI, when you can't make use of the incredible amount of effort that has been spent on frameworks, toolkits, and libraries to make building a HTML UI bearable?
I don’t know exactly what’s supported by this thing, but it’s certainly not a strange idea to choose a subset of functionality to support that covers a huge range of use cases but improves performance, predictability, maintainability, file sizes, etc. Strict mode in JavaScript is a similar concept.
The issue is that this isn't actually an Electron alternative; the author is upfront about this not actually being a browser-compatible rendering engine. It's just a rendering engine that happens to use some subset / superset of HTML, JS and CSS, but it is not compatible with web libraries and components.
As a basic example, SciterJS crashes loading the "hello world" ReactJS project (at least it did last time I tried it - the author recommended I used a custom version of React he publishes). It's perfectly fine to come up with a lightweight cross-platform UI rendering engine (we know we need more of those), but having it web-adjancent while not really web-compatible is a recipe for frustration.