c-smile

Joined 10 years ago

Karma

2,809

Submissions

1,113

Member since

May 20

Author of

- Sciter Engine - https://sciter.com

- Sciter Notes - https://notes.sciter.com

- HTML Notepad - https://html-notepad.com

MS in Applied Physics and Mathematics.

GH: https://github.com/c-smile/

SO: http://stackoverflow.com/users/421163/c-smile

CP: http://www.codeproject.com/Members/c-smile

Participated in HTML5 specification development at W3C HTML5 WG as an invited expert.

View on Hacker News

Recent submissions

Comment · 1 month ago

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

Comment · 1 month ago

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

Comment · 2 months ago

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

Comment · 4 months ago

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

Comment · 4 months ago

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

Comment · 4 months ago

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/

Comment · 4 months ago

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

Comment · 5 months ago

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

Comment · 5 months ago

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

Comment · 5 months ago

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

Comment · 5 months ago

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/

Comment · 5 months ago

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

Comment · 5 months ago

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

Comment · 6 months ago

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

Comment · 6 months ago

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