Hacker News Reader

Comment by gigel82 | Hacker News Reader

Some previous discussion on SciterJS here: https://news.ycombinator.com/item?id=24797423

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.

View on HN

"custom version of React he publishes..."

It is not a a custom version of React but rather extension of DOM model by just these:

1. Native JSX support. In Sciter QuickJS was extended to support JSX literals out of the box: https://github.com/c-smile/quickjspp/blob/master/quickjs-jsx...

2. Native methods:

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

Surprisingly, these are enough to allow to use pretty much all ReactJS functionality, and with native speed. And without the need for any external libraries. Check: https://github.com/c-smile/sciter-js-sdk/tree/main/docs/md/r...

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.

So in order to get an editor to work properly I need to use custom versions of frameworks.

Rrrright....

https://news.ycombinator.com/item?id=29745034

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.

I don't think it's as dramatic.

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.

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.

> we can't take some well-tested, used-by-millions library

You can.

Here is an example of Sciter application that uses RemarkableJS library (https://github.com/jonschlinkert/remarkable) as it is:

https://quark.sciter.com/quark-application-samples/hello-mar...

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?

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

That's a shame. Being able to use React/Vue/Svelte/etc with a relatively tiny native dependency would be fantastic.

Any pointers to discussion on what JS/DOM features it's missing that React needs?

- React works with some modifications: check https://github.com/c-smile/sciter-js-sdk/blob/main/samples/r...

- VueJS works as it is.

- PReact works as it is, also with built-in JSX support of Sciter: https://github.com/c-smile/sciter-js-sdk/blob/main/samples/p...

- MithrilJS also works as it is.

- Svetle also works: https://sciter.com/forums/topic/svelte-sciter-js/

Oh neat. What actual React code changes were needed for compatibility?

They mentioned it in a sister comment

https://news.ycombinator.com/item?id=29745224

Maybe check out Tauri then

https://tauri.studio/en/

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?

Web UI has really different model - different enough to be barely usable in desktop applications.

You can re-use components though like LifeletJS : https://sciter.com/sciter-js-runs-leafletjs-as-it-is/

But use of component frameworks have problems. Usually browser window spans whole desktop. But desktop application as a rule do not. Check this discussion: https://sciter.com/forums/topic/what-js-framework-is-prefere...

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.

It's easy to pick up by people that already know web technologies, which is what made Electron attractive in the first place.

Reply on news.ycombinator.com