Hacker News Reader

Comment by c-smile | Hacker News Reader

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

View on HN

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.

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

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

Reply on news.ycombinator.com