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:
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.
While I'm trying to take a test it seems too much to start a Hello world application, or just to bundle my existing "dist" folder of a part time project.
Is it possible to install some tool, and give it a "dist" fold path and the application is generated all alone?
I'm stupidly lazy, and I hate work with graphical UIs to start a project and input that many fields, make me feel like visiting a 1990 web page requires me registering with tons of information and most of them are useless or at least I can provide later if needed.
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.
I don't see how you can relate this to communism. Sounds more like oligarchy/roman empire: a few own almost everything, but most have almost nothing and are being controlled with bread and games. Marxism is the opposite where everything is owned by everyone (in theory).
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.
Some suggestions for naming this, depending on how you organize ownership, redistribution, who gets to decide what you need: paternalism, welfare capitalism, neo-feudalism, technofeudalism, welfare state, social democracy, UBI-and-oligarchy, oligarchy, plutocracy.
We are already in a position where we could house and feed everyone, but we choose not to do so. Instead a few own almost everything, money gets spend on killing people, instead of feeding them.
If we choose not to do it now, i don't see how we can make UBI work in the future.
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.
If you are making it native to the browser, why have a "virtual DOM" "definition language" middleman and not just jump straight to real DOM, the browser's existing bread and butter?
let ele = <div id="some">Text</div> // ele is now HTMLDivElement
Doing that `element.append(ele)` just works with existing DOM APIs.
Instead of supporting classes and functions in browser-supported JSX with their own life cycle model, you can just require registered Web Components and reuse existing Web Component life cycles.
I think if Browser-native JSX support were to happen it should probably either be real DOM or remain a function tree so that at least some tree operations can be amortized by the function compiler.
Which is that most JSX is actually compiled to nested calls like:
The `jsx` function can potentially avoid some future tree walks/recursion by the nature of being unrolled by the compiler into nested calls instead. That's a useful property lost in trying to agree on a single virtual tree definition. It's also one maybe unnecessary if just relying on real DOM trees, because browsers have their own optimizations for DOM tree walking.
> 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.
reply