c-smile

> will contact even more of NATO

Geography and Istanbul would be agreement to make Ukraine neutral tells exactly the opposite.

But "let's just fight" (c) Boris Johnson (GB PM at that time). Yeah, why not?

I would add there _creativity_ in the sense of creation. And joy of it.

Just in case...

In Sciter I have three editing behaviors (element controllers) associated with these elements by defualt:

* <textarea> - plain text editor working with single text node.

* <htmlarea> - WYSIWYG editor working with a DOM tree.

* <plaintext> - editor working with a list of <text> elements. Each <text> element is allowed to have only inline and inline-block subelements and text nodes [1].

<plaintext> is optimized to work as a source code editor. Local editing in one <text> element invalidates text layout of that only element but not the whole content as in case of <textarea>.

All editors support ::highlight - to style fragments of text without the need to change underlying DOM.

<plaintext> provides streaming API allowing to access content of the element as pure plain text but with methods to ::highlight ranges in it to minimize problems with encodings and mappings of text positions to corresponding node trees and making syntax highlighting simpler:

See screenshot: https://sciter.com/wp-content/uploads/2026/09/plaintext-colo...

<htmlarea> and <plaintext> also support transactional updates allowing to make non-trivial DOM tree mutations undoable as a single operation.

[1] behavior:plaintext - https://docs.sciter.com/docs/behaviors/behavior-plaintext

> for mhtml to be embedded with light weight renderer so it does'nt have to rely on other browser

That's Sciter (https://sciter.com) and Sciter.Quark (https://quark.sciter.com) in particular, no?

It is better to be D language then - natively compiled and has superb meta programming features.

Especially if to consider that I've added native D support to Sciter [1].

[1] https://terrainformatica.com/2026/06/05/ai-assisted-developm...

I think that my Sciter is better option when you need HTML/CSS/JS native application running on Windows (XP and beyond), MacOS and Linuxes.

Sciter SDK [1] contains scapp[.exe] - standalone Sciter engine that can be attached to HTML/CSS/JS bundle making standalone (single exe file) and portable executable. https://quark.sciter.com/ tool allows to compile such apps.

Size of "hello world" is a size of scapp.exe binary + size of compressed HTML/CSS/JS bundle.

On Windows scapp.exe is of ~14 Mb. On Linux ~18 Mb.

Linux version at startup detects GTK4, Wayland or X11 and uses those as windowing backends.

On all platforms Sciter provides out of the box: HTML/CSS/JS runtime, libuv based Node.JS alike runtime, GPU accelerated rendering, WebGL 3D runtime, JS built-in persistence (NoSQL DB).

It does not have TS compiler built-in as Deno, but that TS-to-JS compiler is better to be outside anyway as it is used only once - at app loading.

[1] https://gitlab.com/sciter-engine/sciter-js-sdk/

Yes, that. And also:

Rust was designed to build core mechanisms of UI, like internals of a browser.

But as a language-behind-ui it is quite suboptimal so I think the most successful UI framework for Rust most likely will use some form of DSL.

But if DSL then inevitably we are getting question: why not HTML/CSS/JS then?

Visual styles, layout, structure, UI logic like "on click here, hide stuff there and expand section over there" is what HTML/CSS/JS was designed for.

"Render therefore unto Cesar the things which are Cesar's;"

I've spent 2 weeks (2-4h per day) to make D language[1] version of Sciter SDK [2]

Choice of AI "tooling" was by accident - typed something like "how to define copy constructor in D for custom structure" in Microsoft's Copilot in Edge browser that gives context for AI.

The answer was good enough for me and so I went with it further.

[1] D language HQ : https://dlang.org/

[2] AI-Assisted Development with D Language, Creating Sciter SDK: https://terrainformatica.com/2026/06/05/ai-assisted-developm...

What would be the name of the society where, say, 30,000 people + technology produce enough food and goods to satisfy the needs of the rest of Earth population?

So those people will get whatever they need for life but will not be technically obligated to produce anything.

We will first switch to 4 day working week, then 3 and so on, right? We will see Universal Basic Income "experiments" [1] more often until they become a norm.

At least we are on the way to all this...

[1] https://weall.org/resource/finland-universal-basic-income-pi...

Yep. Evolutionary way to get to communism where "from each according to his ability, to each according to his needs" [1]

[1] "https://en.wikipedia.org/wiki/From_each_according_to_his_abi...", circa 1875

What if:

1. JS supports JSX literals so

   let elDef = <div id="some">Text</div>;

will be compiled into

   let elDef = ["div", {id:"some"}, ["Text"]];

2. We extend DOM API to accept such constructs:

   element.append(elDef);  // same thing as element.append("<div id=some>Text</div>");
   element.prepend(elDef); // ditto
   element.patch(elDef);   // patch element's DOM by elDef

3. Add appropriate events: componentDidMount, componentWillUnmount, etc. for cases when tag in JSX (uppercased) resolves to a class or function.

4. Add render() support. A method that generates tree of elDef's. It gets called by append(),prepend() and patch().

And we will get native React implementation. This will be quite useful and allowed to marry React alike approach with WebComponents into single mechanism.

1...4 is how it is implemented in my Sciter as the Reactor thing, see: https://docs.sciter.com/docs/Reactor/

> On most platforms it's quite easy to embed a browser in a frame

Citing other answer here "This is a common misconception among programmers, and is actually the opposite of the truth."

If platform is Windows then you need three different mechanisms for doing so, depends on OS version. And be ready to the fact that it can be no browser installed in standard way.

And if platform is Linux... Good luck with that in general... GTK may help here but be ready to GTK2/GTK3/GTK4 zoo. And sure you will not be happy with performance of the result.

> There is no real alternative.

Not sure if my Sciter qualifies as a native solution.

Check this chat alike virtual list with MD items: https://sciter.com/wp-content/uploads/2026/05/virtual-list-m...

Yes, MD gets translated to DOM tree. But virtual list implementation in Sciter is a native thing. Load whole chat is not an option usually. Yes, JS is used in process but mostly as a configuration option: take output of one native function -> transform it -> pass as an input to other native function.

Essentially there is no so significant difference with any other SwiftUI/TextKit solution. It is just a difference in terms - SwiftUI uses tree of Views that is conceptually the same as DOM tree in terms of Sciter.

> Is there a good reason browsers could and or should not support ts out of the box?

Yes, there is a reason. Most critical requirement for the "language-behind-web-UI" is to be efficiently parseable (parsing speed and memory). So it should have one-pass compiler/interpreter without the need of building AST (syntax tree). Speed of execution and type strictness is on the third and tenth places correspondingly.

JS matches that basic requirement but TS is not.

> lack of browser engine implemented basic UI elements as default HTML.

I'd argue that browsers already have full set basic UI elements.

But the thing is that "basic set" is different for each developer / site and that is OK.

Attempt to make a browser to include everything is a path nowhere. Today we have carousel as the thing, tomorrow something else.

That's the moving target. And don't forget about versioning. Each feature has to have a fallback:

   <carousel>
      ...
   </carousel>  
   <nocarousel>
      ...
   </nocarousel>

Old browsers and old machines are still there.

Instead we should have really handy component system like

   <section class="carousel">
      ...
   </section>  

   <style>
      section.carousel {
        controller: Carousel url(/js/carousel-desktop.js); 
      }
      @media handheld { 
        section.carousel {
          controller: Carousel url(/js/carousel-mobile.js); 
        }
      }  

    </style>

USSR at big extent was there too.

Like OGAS[1] - a unified economic management system. The idea was simple yet technocratically rational: if the system has enough sensors and effectors on society then it can reach a maximum of satisfaction for the society as a whole (with the given set of common resources).

[1]https://museum.dataart.com/short-stories/ogas-the-red-bit-sy...

Yeah, that's definitely needed.

That's why I've added Graphics.Text (https://docs.sciter.com/docs/Graphics/Text) in Sciter.

Graphics.Text is basically a detached <p> element that can be rendered on canvas with all CSS bells and whistles.

It is not. Not to that extent at least.

I am developing Sciter[1] engine that works on all desktops: Windows, MacOS, Linux (3 distinct backends: pure X11, pure Wayland and GTK4).

Among all those, Windows API is still the most consistent and stable.

Whole of Windows functionality can still be accessed by plain C. For some things (COM) is better to use C++ but C works too.

Just in case: I am in this business for 20+ years.

[1] sciter.com

> cross platform GUIs are ugly by default,

... was said reading it in a browser on who knows what OS/DWM.

I mean that 90% (if not more) of all UI interactions happen now in a browser or in multi-platform applications (e.g. messengers, SublimeText, VSCode, etc).

WYSIWYG is #1 reason I believe.

Markdown is fundamentally WYSIWYG - you edit something and you get it rendered 1 to 1. Either in plain text (a.k.a. "source") or when it converted to HTML/CSS and then presented.

WYSIWYG requires 1:1 mapping between "source" and "presentation". Markdown is exactly that. While HTML/CSS is 1:N mapping - same presentation can be achieved with many combinations of HTML/CSS rules. That's why "true WYSIWYG" is barely achievable with HTML/CSS.

Lua syntax is pretty good for DSL (domain specific language) cases / configuration definitions.

For example Premake[1] uses Lua as it is - without custom syntax parser but with set of domain specific functions.

This is pure Lua:

   workspace "MyWorkspace"
      configurations { "Debug", "Release" }
   
   project "MyProject"
      kind "ConsoleApp"
      language "C++"
      files { "**.h", "**.cpp" }
   
   filter { "configurations:Debug" }
      defines { "DEBUG" }
      symbols "On"
   
   filter { "configurations:Release" }
      defines { "NDEBUG" }
      optimize "On"

In that sense Premake looks significantly better than CMake with its esoteric constructs. Having regular and robust PL to implement those 10% of configuration cases that cannot be defined with "standard" declarations is the way to go, IMO.

[1] https://premake.github.io/docs/What-Is-Premake

<output type="currency">123456.00</output> formats output using user's settings: https://www.elevenforum.com/attachments/currency_format_cont...

If you want specific country format then you may use lang:

<output type="currency" lang="de-DE">123456.00</output>

Currency conversion is not a subject of a browser.

"better" in what sense? If in hypothetical semantic meaning then another old zombie <var> is better in that sense, isn't it?

Not sure I understand why do you need exchange rates with it.

<output type="currency"> uses the same convention as "Intl.NumberFormat/style=currency": https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Also, if to allow form.value to accept JSON-ish objects it will be possible to set form values in single shot:

   form.value = { transAmount: 12345n, transDate: new Date() };

where form is

   <form>
     ... <output type="currency" name="transAmount" />
     ... <output type="date-local" name="transDate" />
   </form>

Problem with <output> is that it is half-baked making its usage almost useless.

It would be significantly more practical for the output to have "type" attribute in the same way as in the input.

I did experiment with oputput|type in my Sciter and added these:

   type="text" - default value, no formating
   type="number" - formats content as a number using users locale settings,
   type="currency" - formats content as a currency using users locale settings,
   type="date"  - as a date, no TZ conversion, 
   type="date-local" - as a date in users format, UTC datetime to local,
   type="time" - as a time
   type="time-local" - as a local time, value treated as UTC datetime. 

This way server can provide data without need to know users locale.

I used to have NEC MobilePro 900 like here: https://live.staticflickr.com/213/481422006_92cdaeb6ee_b.jpg

I miss that form factor really.

And BTW, I regret that WindowsCE is not the thing anymore. IMO it has the best development infrastructure out there backed with MSVC IDE.

I classify OSes into two major groups: "writer OS" (all desktop OSes primarily) and "reader OS" (all mobiles). But there is a void in between for palmtop form factor devices.

Sigh, probably its only me who needs this ...

Well, Highlight API ( https://developer.mozilla.org/en-US/docs/Web/API/Highlight ) should just work inside <textarea> too.

At least it works in my Sciter like this:

    <style>
      textarea::mark(myHighlight) {
        background-color: yellow;
        color: red;
      }
    </style>
    <body>
       <textarea>Lorem ipsum dolor sit amet</textarea>
    </body>
    <script>

      // Select a range of text to highlight
      const range = document.createRange();
      const textNode = document.querySelector('textarea').firstChild; 

      range.setStart(textNode, 6); // Start at the 6th character
      range.setEnd(textNode, 11); // End at the 11th character

      // Highlight the range
      range.highlight("myHighlight")

    </script>

Ask your browser vendor to enable highlight API in <textarea> too :) so such tricks will not be required.

DOM per se, as a tree of elements, is not that bad. CSS is also not that bad in general.

Their API is probably the problem. Not modular so makes the mess.

Options to modularize them:

DOM, concept of interfaces/behaviors rather than inheritance leading to huge maps. Let say for <textarea> we may have separate "textarea" interface:

   element.tagName
   ... and the rest of DOM-as-a-tree methods ...
   element.textarea // <textarea> specific interface of its behavior
   element.textarea.select(startEnd) // interface method
   element.textarea.selectionStart // interface prop
   element.textarea.selectionEnd // interface prop
   element.textarea.rows // interface prop
   element.textarea.columns // interface prop
   ...

CSS, that huge flat table is a nightmare, not just because of its size, but because of extensibility problems right now and in the future. Example, all CSS grid related properties should rather go to their own namespace:

   section {
     color: red;
     // ... and other basic CSS 2.1 props

     display: grid(
       rows: ...;
       columns: ...;
       align-items: center;
       justify-items: start
     );
   }

So different layouts ( like display:flex(), display:waterfall() ) may have their own rows, columns, etc.

As sooner we will do that - the better. API is on the brink of collapsing / combinatorial explosion, indeed.

From the very beginning in Sciter an Image can be constructed in two ways at runtime ( other than just getting loaded image reference):

1. By painting on it using Canvas/Graphics API:

    new Graphics.Image(width, height, painter(graphics) [,initColor]);  

Where _painter_ is a function used for paining on the image surface using Canvas/Graphics reference.

2. By making snapshot of the existing DOM element:

    new Graphics.Image(width, height, element [,initColor])

Such images can be used in DOM, rendered by other Canvas/Graphics as also in WebGL as textures.

See: https://docs.sciter.com/docs/Graphics/Image#constructor