c-smile

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

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

   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

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>

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"

[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() };

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

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>

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

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

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

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]);  

2. By making snapshot of the existing DOM element:

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

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

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(...);
      ...
   }

"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