Important

This project is very much in its infancy.
This README is half features in a workable state, and half wishful thinking.
This holds true for rest of the docs as well.

Warning

Safety & Security policies have not been implemented or fully tested yet. Running untrusted XML files on VS can lead to arbitrary code execution on your machine with your user privileges.

Hey, you there! Yes you! May I entertain you with something slightly cursed?
Have you ever woken up in the middle of the night, thinking:

"Maaan, I'd really love to put a pinch of C, JS and WASM into my XML files and get a UI with vibes out of the 90' for my fancy codebase".

Well, you should eat lighter before nighttime.
Still, it is your lucky day, & this project might be for you!

What is VS (naming review pending)

VS is a front-end framework based on the concept of composable SFCs (Single File Components).
More specifically, VS is a runtime with very low resource requirements, that takes a dependency tree of XML SFCs, and renders it using a portable native toolkit library into a lightweight UI.
Layout, style, data handling and embedded scripts are all part of these reusable components. They are embedded in the XML file pretty much as you would do with HTML.

VS is based on FLTK, a very lightweight and portable UI toolkit.
Comparing its memory footprint with GTK or QT is not even fun.

Example

The obligatory "counter" example:

<?xml version="1.0" encoding="UTF-8"?>
<app xmlns:fl="vs.fltk">
    <fl:window box="0,0,320,240" label="Demo Counter">
        <mixin name="+fl:button" bg.colour="#aa3300" label.colour="#99ee4f" />
        <script lang="c">
        <![CDATA[
        unsigned int counter = 0;

        void _update(){
            static char str_buf[32];
            itoa(counter,str_buf,10);
            $$prop($("main-text"),"label",str_buf);
        }

        void on_add(){
            counter++;
            _update();
        }

        void on_dec(){
            counter--;
            _update();
        }

        $cb(on_add);
        $cb(on_dec);
        ]]>
        </script>

        <fl:label name="main-text" label="0" label.size="90" box="20,20,280,120" />
        <fl:button label="Add" on.callback="on_add" box="20,160,80,50" />
        <fl:button label="Remove" on.callback="on_dec" box="120,160,80,50" />
        <fl:button label="Console" box="220,160,80,50">
            <script lang="c">
            <![CDATA[
            void callback(){
                $log(LOG_LOG,"Hello world!");
            }
            ]]>
            </script>
        </fl:button>
    </fl:window>
</app>

There is also a js version for reference.

Why?

Because the current landscape of UI development kind of stinks. And to be totally honest, a lot of that smell comes from web technologies.
We constructed layers over layers of complexity to wrap and bend HTML, to the point that its native UI components are not even used.
And now we are required to waste at least 100MB of RAM just for the privilege of running webkit with an empty page.

It is sad to see that most of the modern native toolkits followed this same trend: QT & GTK both became a bloated mess over the last few years.
For many desktop applications, any UI is just an overlay to give easy and intuitive access to the complex application below. And to make features discoverable. We don't need transparency, animations or a super complex logic to determine the state of a widget.
And oftentimes, we want to run them on very low spec Linux system, without resorting to something as bare bone as lvgl.

vs is an attempt to bring together the best of the techniques and patterns we learned in modern UI frameworks & web technologies onto a native runtime with a miniscule footprint.

Compared to other approaches, vs is extremely opinionated and tries to enforce just one way to make things right. It does not mean it is inflexible, just that it makes clear where complexity should be (spoiler, not in the UI). If you are coming from a less restrictive context you might find these limitations unpleasant at first, so I compiled a list of frequently asked questions no one asked for, to make things easier.

Planned Features

• FLTK UI elements properly mapped into XML.
  • A set of better themes
  • A markdown component to render it directly (replacing the ancient HTML2.0 webview FLTK offers)
• A simple tree model to handle scoping, events and queries
• Native support for datasets & data models
• Custom components
  • Native custom components, externally compiled from any language
  • WASM custom components, externally compiled from any language
  • XML custom components, capable of embedding any other component
  • A compiler to transform XML components in C code (to be natively run or compiled to WASM)
  • An XML preprocessor like XSLT to compile templates + static data down to components directly on client
• Inline code inside XML components (like JS in HTML)
  • C as a scripting language, backed by tinycc.
  • Other derived alternatives, like cello or vala would also be possible.
  • JS powered by QuickJS.
  • Lua, either based on the reference implementation or LuaJIT.
  • WASM to run any language which can be compiled to this target & their compilers.
• Distribution of components via http/https and gemini.
• A self-hosted visual editor to design, code and test new components (something like gambas or fluid).
• A robust permission system to decide what components can do based on their origin.
• A target for single executables; compile your app down into one sharable file for systems onto which vs is not already distributed.

You can read more about which features are planned in the milestones page.

Useful documentation

• Instuctions for developers
• Instuctions for users of vs
• Complete specifications.

Licences

Currently, most of this project is source available, under the terms of CC BY-ND.
Still, any derivative work for private use, or for the sake of merging functionalities to the main repository is allowed and encouraged.
I am taking PR, but contributors should understand that the project is very early, and changes in direction might make their time wasted.
They should also be ok with their code being relicensed to a more permissive licence later on, as this is the general direction for this project once stable enough.

Still, some part of this repo are licenced separately:

• All bindings are CC0
• examples and docs are CC BY-SA
• Each of the subprojects imported clearly keep its own licence and copyright notice.

Unless a file comes with a custom licence in its header, they will inherit the one of the closest parent folder.

Dependencies

This project is based on the following dependencies:

Core features

• fltk the UI toolkit library used.
• fmt to format strings and as printf replacement.
• pugixml to parse xml.
• mio memory mapping for loading files.
• hashlib for cryptographic functions (and not).
• libuv for me not to care about portable code.
• vs.templ a library to parse markdown (not just to HTML).

For embedded scripts

• libffi to simplify symbol sharing between languages.
• tcc the embeddable C compiler used for C scripts.
• quickjs the embeddable JS runtime used for JS scripts.
• lua and luajit to support Lua scripts.
• wamr the embeddable WASM runtime used for scripts, portable compiled components & compilers.
• cello an unholy macro machine for C to transform it into a dynamic language.

For custom components

• treesitter to handle parsing of languages (used for some components and the self-hosted editor).
• md4c a library to parse markdown (not just to HTML).
• nlohmann-json to parse json in some data directives