c-smile

> please consider using actual threads.

Bad advice in general.

Why would you run separate thread if you only want is to iterate over nodes in a tree (as an example of non flat collection).

C++ version of the approach: https://www.codeproject.com/Tips/29524/Generators-in-C

I am using this in my Sciter, just in case. Works quite well and convenient.

If I am not mistaken, NanoVG actually can render as by CPU (need external path rasterizer) as by GPU (OpenGL and other options).

NanoVG provided Canvas.Context kind of API in plain C.

About premake5 in general.

premake5 is a monolithic/portable executable that contains Lua + specific runtime.

Thus it does not rely on installed Python as in GN case as other tools.

Having standard and well known and documented Lua on board benefits the maker a lot. In my opinion any modern build system must include generic and known PL.

And that above is the problem of modern CMake. It started as simple static declarative thing but life forced it to evolve into dynamic programming language with very strange notation and runtime model.

> it's a pain to build

Yes. So in Sciter I've replaced its build system with relatively simple premake5 script. That replacement took couple of days but was worth it. Premake5 generates human-readable IDE solutions and make files. So you need just a compiler to build the whole thing.

> building it from source takes 20-30 minutes on a modern laptop.

It is not that bad actually. Just tried full rebuild of x64/Windows version:

Whole sciter.dll (HTML/CSS/JS/Graphics) with Skia backend:

   sciter.dll build completed at 9:11 AM and took 07:03.415 minutes

Same sciter.dll but with Direct2D backend:

   sciter.dll build completed at 9:22 AM and took 02:34.412 minutes

So Skia takes ~4 minutes to build on pretty average development desktop machine.

> it's constantly changing its APIs

That's very true and is a pain indeed if to change its version frequently. Yet there is no such concept as "Skia version" - just revisions/milestones. It used to be an attempt to make stable plain C API but AFAIR it was removed recently.

Same thing about Google ANGLE that I started to use recently in Sciter.GLX: https://sciter.com/sciter-glx-beta2/

Original EverNote (v 2.0, first public version) was built on that idea - endless tape of notes : https://notes.sciter.com/wp-content/uploads/2017/09/evernote...

Plain text is OK, or Markdown as poor man WYSIWYG for that matter, but at least images should be there too.

What if to keep it standing for the whole day?

You can try my Sciter. On Windows it uses as Direct2D/DX11 as Skia over DX12|Vulkan|OpenGL (whatever is available).

In both cases it uses GPU rendering and I see no problems with scrolling in them - 60 FPS kinetic scrolling by mouse wheel and touchpad.

You can try by yourself by running usciter.exe demo browser from

- https://gitlab.com/sciter-engine/sciter-js-sdk/-/tree/main/b... - Direct2D backend. - https://gitlab.com/sciter-engine/sciter-js-sdk/-/tree/main/b... - Skia backend.

You can load in usciter this document:

https://gitlab.com/sciter-engine/sciter-js-sdk/-/blob/main/s...

It shows pretty large colorized texts so you can estimate how Direct2D and Skia handle GPU accelerated text rendering. For these two binaries the difference is only in graphics used - Direct2D and Skia.

> In practice, it still re-renders a lot.

Neither framework will fix programmer's errors.

This

   for(let child of container)
      child.innerHTML = getHtmlFor(i++);

will always be slower than this:

   for(let i = 0; i < N; ++i)
      html += getHtmlFor(i++);
   container.innerHTML = html;

N transactions versus 1 transaction.

I mean that compiling separate N "small" DOM access calls is not always faster than one integral update.

How does M3 stand with SvelteJS?

Seems like these are two conceptually similar things.

> React traverses the virtual DOM tree to update the UI, resulting in O(n) time complexity.

That's the worst case, on initial load. On most of UI changes nothing stops React to update only local portions of the tree - elements that have their state changed.

Educated guess: In Million and React.JS cases major bottleneck is inside browser re-layout mechanism, not on JS side I think.

I have a customer, a company, they specialized on porting my Sciter on old and exotic platforms to create new modern looking software for them. Win95, old Unixes still getting new soft developed for them.

Another company, behemoth, I would say, with 30000 stuff, using Sciter to make frontend for their old mainframe based system (COBOL I think). Mainframe sends 80x24 terminal screens where the frontend gets fields by x/y coordinates to show it in modern HTML/CSS UI.

You may notice a lot of crazy things in dusty corners of IT.

I do not really understand what is the problem with flexible <select> implementation in browser.

In my Sciter[1] the following are supported ( see screenshot [2] ):

    <select type="dropdown"> - select with popup
    <select type="list"> - select list 
    <select type="tree"> - hierarchical select (a.k.a. tree view) 

and all of them may have

    <select multiple> - multi-select, value = array[]
    <select multiple="checkmarks"> - multi-select, value = array[]

select type="tree" may have also

    <select type="tree" treelines> - draw treelines 

<select> and <option>'s may have arbitrary markup inside (<hr>,<img>, whatever), even more any DOM element may have role="option" defined making it a selectable option :

    <li role="option">...</li>
    <option value="Sc"><code>Sc</code>Scandium</option>

And as a bonus, by declaring different flows in CSS in list you may have:

    select { flow:horizontal; } // horizontal select
    select { flow:vertical-wrap; } // multicolumn select

[1] https://sciter.com [2] https://sciter.com/wp-content/uploads/2024/01/select-variant...

Each tool is good for particular tasks it was designed for.

That's why my Sciter [1] supports both - as retained mode (DOM/CSS) as immediate mode (element.paintXXX()).

Consider the task of marking some div as resizable - with eight square handles [2]. With immediate mode drawing that task is trivial:

   const div = ...;
   
   // draw sizing handles:
   div.paintForeground = function(gfx) {
     gfx.fillColor = "#0f0";
     for(let r of this.sizingHandlePlaces()) 
       gfx.fillRect(r); 
   }

otherwise, if we have only retained mode as in browsers, we will need to modify the DOM heavily and create temporary elements for handles.

[1] https://sciter.com [2] https://stackoverflow.com/questions/20984181/how-do-i-make-a...

Runtime model is not clear.

Like my Sciter is an embeddable multiplatform HTML/CSS/JS UI engine. You create your native app using PL of your choice and create HTML/CSS/JS window[s] using Sciter API calls. So it is HTML/CSS/JS UI layer for native applications. And then you put that app in app stores...

And now about EXT ...

What does it mean "desktop software" in EXT context?

Am I right that this is about creating Google Chrome Webviews in detached (non-tabs) windows? So the desktop software require Chrome to work, right?

Early version of Sciter was HTMLayout engine where I put my email in dll resources.

That was terrible idea. I did not realize how creative users are to get that email from resources.

HTMLayout was especially popular among shareware INDIE authors - HTML/CSS was easy to create cool looking UI.

So I started to receive tons of emails like "your electronic enlarger is a crap - she is still not satisfied". All such sort of things.

So we are about to cool down Earth's core?

Climate changing v.2.0 due to Earth loosing its magnetic field ...

JSX is useful not just for advanced string interpolation but for representing/generation of tree alike structures / literals in PL. JSX is not only about HTML but XML too.

I don't know how JSX is made in LuaX but in my QuickJS fork [1] JSX allows to generate as tree literals as procedure calls (JSX(tag,props,kids)) that can be used for various purposes - DOM population, VDOM generation, HTML/XML string composition, etc.

And being embedded into a compiler JSX a) prevents common mistakes like non-closed tags and b) effective internalization ( translation happens at compile time once ).

[1] JSX implementation for QuickJS : https://gitlab.com/c-smile/quickjspp/-/blob/master/quickjs-j...

Agree about virtualization in principle. Not that nightmarish though.

My Sciter supports built-in virtualization out of the box. But I shall admit that this is second approach to the problem.

Currently Sciter's behavior:virtual-list supports as fixed-height items (that's easy) as variable-height items like messages [1] in chats.

API is relatively simple [2]: single event "contentrequired" that virtual-list sends to JS. In response JS shall either append or prepend requested number of DOM elements to the container (a.k.a. sliding window scroller). Example, grid showing 20000 records: https://gitlab.com/sciter-engine/sciter-js-sdk/-/blob/main/s...

And needless to say that this supports animated (a.k.a. kinetic) scroll.

[1] https://sciter.com/behaviorvirtual-list-for-sciter-and-scite... [2] https://docs.sciter.com/docs/behaviors/behavior-virtual-list

Just in case, Sciter has built-in element <terminal> that can be used for various purposes.

Escape codes are supported, see: https://sciter.com/wp-content/uploads/2022/10/terminal.png

Docs/API: https://docs.sciter.com/docs/behaviors/behavior-terminal

> warehouse deliveries

Main problem here is that it is a floating device. As soon as it unloads 4 tons of cargo it gets pushed up with 4 tons force upwards. And you'd better do not release helium to compensate that - it is quite expensive.

Without solving that problem airships are mostly for travel...

> that most of hte libraries taking a JSON document approach are wasting a lot of time/memory

I agree. That's the same situation as with XML/HTML. In many cases you don't really need to build a DOM or JSOM in memory. If your task is about deserializing some native structures.

This XML scanner of mine does not allocate any memory at all while parsing HTML/XML: https://www.codeproject.com/Articles/14076/Fast-and-Compact-...

It is even simpler than SAX parser.

With each release of Windows there are less and less HWND/GDI based applications.

Standard set of HWND/GDI controls (EDIT,COMBOBOX, BUTTON + so called common controls) is not changing since Win95 so it is a dead end.

And in general modern UI tends to move to composition of UI from primitive ctls achieving rich agglomerates. Like in Web UIs:

   <div class="search-input">
     <input type="text" />
     <button />
   </div>

HWND/GDI is really dead for many reasons. Badly scalable on high-DPI, no alpha, no 3D like here: https://sciter.com/sciter-webgl-is-officially-published-in-v... (second screenshot) and no styling/customization.

Why each article about project completion in Rust is read as ex-husband words about his ex-wife:

- I loved here. I am still is. But we needed a divorce.

N1 (USSR Lunar mission) rocket had similar engine group design - 30 similar engines (NK-15).

I remember one professor in our university who did post-mortem analysis of the program failure.

He compared that setup with 3-body problem (https://en.wikipedia.org/wiki/Three-body_problem) where system exhibits nearly chaotic behavior on small disturbances - not stable. 30+ driving engines just multiply the severity - extremely not stable. Plus parasitic resonances in engines and all such wonders.

N1 had very fat backlink (for that time) to base where control system / computers of the engine pack was located. Sure, computers are better now than when but I suspect problem of controlling such pack is not really solvable due to instability of physical system.

I really want to be mistaken but here is my educated guess - this thing will not fly.

All successful designs so far have one or two main engines, may have additional engines but of significantly lower thirst.

Floating takes zero energy.

Why pure helium but not a mixture of helium-hydrogen?

At some level [1] that mix is not flammable. That will add at least some additional payload.

[1] https://h2tools.org/bibliography/experimental-study-safety-h...

Keep GIL but introduce Workers a la JS [0] ?

Worker [thread] is a sandboxed VM [context] with its own GIL.

Communication between these is done through messaging so no sync primitives are required.

Go's routines have similar concept.

I think that if it OK for Go it should be OK for Python, no?

[0] https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

Just in case, in my Sciter horizontal margins do collapse in horizontal flows:

   container {
     flow: horizontal; /* single row */
   }

   container > child {
     margin:1em; /* will collapse */
   }

See: https://docs.sciter.com/docs/CSS/flows-and-flexes#flowhorizo...

Hmmm... if America I would expect to see plates from, say, Bolivia too ...

> "Every tool expands until turning complete"

In that respect I think PreMake (Lua based configuration and build system) is more humanistic.

Lua syntax provides pretty comfortable, DSL alike, way of defining rules/declaration. And at the same time it is regular and compact PL with established runtime for those 10% of cases when static declarations are not enough.

CMake, IMHO, went wrong way of defining DSL first and then trying to accommodate it to needs of full PL and real life. In any case need for debugger for configuration tool is a bad sign. IMO.