c-smile

Consider <textarea> that has resizing handle on the corner (try to reply to this message to see it alive). And now try to imagine how would you render those diagonal lines in HTML/CSS ?

While in Sciter, that has such immediate mode rendering form the very beginning, you can simply draw them as:

   resizableElement.paintForeground = function(gfx) { // draw on top of background & content

      let box = this.getBoundingClientRect();
      gfx.moveTo(...); gfx.lineTo(...);
      gfx.moveTo(...); gfx.lineTo(...);
      ...
   }

Easy, right? And does not need to modify DOM and place artificial positioned elements.

> "Includes" functionality is considered to be server-side

Exactly! Include makes perfect sense on server-side.

But client-side include means that the client should be able to modify original DOM at unknown moment of time. Options are

1. at HTML parse time (before even DOM is generated). This requires synchronous request to server for the inclusion. Not desirable.

2. after DOM creation: <include src=""> (or whatever) needs to appear in the DOM, chunk loaded asynchronously and then the <include> DOM element(sic!) needs to be replaced(or how?) by external fragment. This disables any existing DOM structure validation mechanism.

Having said that...

I've implemented <include> in my Sciter engine using strategy #1. It works there as HTML in Sciter usually comes from local app resources / file system where price of issuing additional "get chunk" request is negligible.

See: https://docs.sciter.com/docs/HTML/html-include

yEd, for those of us who knows word "Visio"

https://www.yworks.com/products/yed

Interesting timing...

I've just made something similar but with JS: C modules in JS.

    import * as CModule from "./module.c";

C module gets compiled to native code on load. I think that clear separation of execution models is a good thing.

https://sciter.com/c-modules-in-sciter/

https://sciter.com/here-we-go/

> anti-virus companies decided to use your platform?

One of the reasons: AV application should look modern to give an impression that the app is adequate to modern threats. So while app backend is relatively stable, its UI shall be easily tweakable. CSS/HTML is good for that.

Check this: https://sciter.com/wp-content/uploads/2018/06/n360.png

Slightly orthogonal...

In my Sciter, that uses QuickJS (no JIT), instead of JIT I've added C compiler. That means we can add not just JS modules but C modules too:

   import * as cmod from "./cmodule.c"

Such cmodule will be compiled and executed on the fly into native code. Idea is simple each language is good for specific tasks. JS is flexible and C is performant - just use right tool that is most optimal for a task.

c-modules play two major roles: FFI and number crunching code execution.

Sciter uses TCC compiler and runtime.

In total size of QuickJS + TCC binary bundle 500k + 220k = 720k.

For the comparison: V8 is of 40mb size.

https://sciter.com/c-modules-in-sciter/ https://sciter.com/here-we-go/

NSUserDefaults is a key-value storage. Same as localStorage in browsers/js.

On other side persistence in QuickJS is more than that. Essentially it is a NoSQL DB integrated into the language and its runtime. For example you can write

   let uname = root.users[2].firstName; 

to access the data using pure language constructs. While with NSUserDefaults you will need to call DB's facade methods like objectForKey("some") and so on.

And also, in QuickJS, Storage is not reading whole DB in memory but fetches/unloads data on demand transparently for the user. You can think about content of DB as about genuine language data structure with root at storage.root

= Value Database

I've added this feature to QuickJS [1] and it works quite well in Sciter as persistent Storage [2] mechanism, used in Sciter.Notes [3] for example.

     let storage = Storage.open(filename);
     let persistentData = storage.root;
     if( !persistentData ) storage.root = persistentData = {... initial storage structure ...};

Everything written to persistentData will be persistent between runs.

= Semi-Dynamic Language

De-facto we already use similar approach quite a while. In form of GPU shaders or WebAssembly. The solution is not in making script JIT friendly (that is against its nature) but with an option to use native/compiled/loadable modules written in languages that were designed to be compileable from the beginning.

My Sciter, as an embeddable engine, is an example of such environment. Native host application exposes native functions/classes to HTML/CSS/JS engine that implements UI layer of the application. UI is dynamic (fluid,styleable,etc.) by nature while application backend (a.k.a. business logic layer) is more static and linear by nature.

[1] https://gitlab.com/c-smile/quickjspp

[2] https://docs.sciter.com/docs/Storage/introduction

[3] https://notes.sciter.com/

Correct CSS grid layout calculation is about solving system of equations and constraints. In simple cases, when there are no spanned cells (like in flexbox), it can be done relatively trivially.

Otherwise solving that system is far from being trivial, you will need simplex solver or the like, for example https://constraints.cs.washington.edu/solvers/cassowary-toch...

Eh, if you drink, then drink...

1. Add `;` as a separator of elements, so you may have:

   { a: "foo"; b:"bar; }

2. Add array tags and space separated value lists so you may have

   { a: 12 13 14; }

   to be treated as [12, 13, 14] with the tag " ". Normal arrays are parsed with the tag ","

3. Add "functors" as, again, tagged arrays

   rgb(128,128,14);

   will be parsed to an array with the tag  "rgb". Also you may have calc(128 + 14);

4. Add tagged numbers so

   90deg 

   will be parsed as a number with the tag "deg"

And you will get pretty much CSS that is proven to define quite complex constructs with minimal syntax.

You can use my Sciter if you need native widgets.

Sciter is an HTML/CSS/JS engine with the ability to attach native widgets to DOM elements. So you'll benefit from two worlds: HTML/CSS layout richness and native widgets.

The major problem though is Linux family of OSes in this respect. I have version of Sciter that works directly on X11 or Wayland ( https://sciter.com/sciter-glx-generation-4/ ). Windows and MacOS have clear concept of child windows/widgets but no such things on X11 or Wayland realistically speaking.

So react-native is practically iOS/Android only thing.

Well we are (humans) are quite lazy (by nature).

The only way for us to move anywhere is to establish set of motivations. Utopias (as extreme goals) are such grand scale motivations.

Were we, as a society, would be without Russian revolution and its attempt to implement extreme utopia of "happiness to everybody and free of charge here and now". I suspect that modern Europe and US that are social-democratic now (but not centuries later) is a result of that idealistic and utopian push Russians tried to implement ahead of time.

Humanity needs global goals that will motivate us to move further. Global warming fight is OK but not enough I think. Something great like "jump to stars now" and is required, no?

I am working on Sciter.GLX - Sciter Engine (HTML/CSS/JS) combined with OpenGL runtime working on all platforms, even on those that do not support OpenGL natively (e.g. Windows/ARM and MacOS).

Sciter offers access to OpenGL as by WebGL/JS as by native OpenGL API access.

Idea is simple: pretty much any 3D application needs some form of 2D UI/Chrome. And so Sciter.GLX provides just that - HTML/CSS/JS UI with <webgl> islands.

Sciter.GLX is also about direct support of as Wayland as X11 on Linux.

Check preview: https://sciter.com/sciter-glx-generation-4/

We MUST, having life on just one planet waiting for the next mass extinction event here is too optimistic.

Check https://docs.sciter.com/docs/Reactor/

Just in case:

Sciter has Reactor - its own native and built-in implementation of React.

Main difference is that component is instanceof Element - components are DOM elements. This allows to unify React and WebComponent under the same umbrella/mechanism. Yet to extend standard DOM methods by use of JSX, so this

    someDomElement.append(<div>Hello</div>)

works just fine - appends content from the vDOM.

In fact Reactor is three entities implemented natively:

* JSX - embedded into JS compiler (830 LOC) - https://gitlab.com/c-smile/quickjspp/-/blob/master/quickjs-j... , produces vDOM literals

* Element.prototype.patch(JSX/vDOM) (420 LOC) - reconciliation / diff implementation

* Binding of lifecycle methods (200 LOC) - componentDidMount and Co.

There is also native implementation of Signal's (310 LOC) but they are optional for React'alike functionality.

As with any other Open Source project - contact its author and discuss with him/her.

1. These wrappers are Open Source.

2. I do not have customers that requested either one of these wrappers.

3. Customers that do use one of wrappers, as AdGuard for example, maintain their own version of Sciter/Go: https://github.com/AdguardTeam/go-sciter

Sciter's support forum is pretty active : https://sciter.com/forums/

Mr. Yuri (Pravic) has his own agenda these days. As far as I know creation of Go, Rust and Python backends for Sciter was a method for him to determine best frontend technology for his organization.

If someone wants to take care about Go, Rust and Python wrappers - let me know.

As of Sciter and "antialiasing" issues mentioned in the article...

Author did not enable high-DPI support in his/her application. As simply as that...

Either in Visual Studio : https://sciter.com/wp-content/uploads/2024/06/high-dpi-aware...

Or by including proper manifest: https://gitlab.com/sciter-engine/sciter-js-sdk/-/blob/main/d...

That actually is explained in "Hello C++" tutorial: https://sciter.com/hello-cpp-tutorial/

> Almost-Linear-Time Algorithm

From O(mn) to O(m) ... thus excluding N (number of vertices) from computation ...

Too good to be true?

This seems to be modelled after Sciter's popups that existed 10 or so years.

anchorElement.popup(elementToPopup, options) - https://docs.sciter.com/docs/DOM/Element/#popup

In Sciter popup element is always associated with its anchor element and appears relative to it.

CSS was expanded to support popups: :popup state flag/selector is "on" the popup element and :owns-popup is "on" on popup anchor element when the popup is shown. Also several CSS properties: popup-position, popup-anchor-reference-point, popup-reference-point, popup-animation.

Sciter has built-in JSX and so element.popup() accepts JSX that creates popup DOM element on demand, for example this

   button.onclick = function() {
      button.popup(<select type="list">
        <option>A</option>
        <option>B</option>
        <option>C</option>
      </select>)
   }

will popup selectable list as dropdown popup.

Politics aside, how that in principle is different from "hostile takeover" (https://www.investopedia.com/terms/h/hostiletakeover.asp) ?

> being able to deploy same codebase on web and desktop

Desktop UI and Web UI models are so different that in reality you cannot use the same codebase on 100% in both targets.

Web UI uses traditional Web's "endless tape" model where only width is known. This does not really work on desktop where width and height are finite. See this Sciter based app https://notes.sciter.com/ as an example.

> reusing the vast selection of libraries for web

If you do need this then you can use Sciter's WebView that is a <frame> backed by system browser:

https://sciter.com/wp-content/uploads/2022/04/sciter-webview...

USSR !== Russian Empire.

Anyway...

Vertical writings are fading out not because someone's political will, but because of their impracticability in modern era.

First commercial typewriter appeared in US in 1874 and it effectively set the end for any non-LTR writing system.

In that respect, can we attach USA to that imperial club that killed TTB writing systems?

> past Russian ... imperial impact

Not sure how "past Russian impact" is at all related to ttb writings ...

Could you elaborate on that?

There was a whole team behind Microsoft Trident (IE engine) that was dissolved in favour of third-party (for them) Blink engine. That team was surely knowledgeable, but they had gone.

Blink source is de facto current spec. Each function, if not single line, there is a paragraph in spec.

I remember at WHATWG / HTML5 WG times when Ian Hickson (Google) was pushing whole SQLite (and its SQL flavour) to be included in HTML5 ...

The spec area is so huge and indeed obscure that even Microsoft could not handle it.

> Every time someone releases a new rich text editor ... uses contentEdtiable

Sciter is using its own implementation (obviously).

contentEdtiable thing is indeed quite limited for general purpose WYSIWYG editor.

For example Web platform is missing transactional update [1] mechanism that allows to put custom DOM mutation groups into unified undo/redo stack.

Sciter's <htmlarea> element ( implement behavior:richtext - WYSIWYG ) allows to build specialized editors. For example it is used in Sciter.Notes [2].

[1] https://docs.sciter.com/docs/behaviors/behavior-richtext#ric... [2] https://notes.sciter.com/

I am not sure that "good soldier" is a correct translation.

Czech "dobrého vojáka" is more "of brave (in `dashing` conotation) soldier".

So Hašek's humor starts right from the title.

In my childhood I'd standing at gates of the event, catching those devices with care...