> It’s way more efficient, I ran a benchmark rendering 10k rectangles on a canvas and the difference was huge: Emscripten hit around 40 FPS, while my setup hit 100 FPS.
Just curious, what would the FPS be using native plain pure JavaScript for the same exact test?
I don't like this html-syntax, cause you use a separate syntax-methods for existing js-functions wrapped as html-tags:
<if text.isEmpty()>
<div class="preview-text empty">Start typing...</div>
<else>
<div class="preview-text">{text}</div>
</else>
</if>
Here something that looks little more like PHP-Style, better separation, but too much to type:
<?coi
if (empty($text)) {
?>
<div class="preview-text empty">Start typing...</div>
<?coi
} else {
?>
<div class="preview-text">${text}</div>
<?coi
}
?>
if (empty($text)) {
$(<div class="preview-text empty">Start typing...</div>)
} else {
$(<div class="preview-text">${text}</div>)
}
Vue style attribute directives are imho a far better dx compared to all of the above.
It's perfectly fine to allow if in tags (the compiler can figure it out). In Mint you can do that no problem: https://mint-lang.com/sandbox/6lnZHiG8LVRJqA
component Main {
fun render : Html {
<div>
if true {
<div>"Hello World!"</div>
} else {
<div>"False"</div>
}
</div>
}
}It's nice to see that we are converging on the same syntax I came up for Mint (https://mint-lang.com) 8 years ago (feels strange to write it down). I saw Ripple some time ago its syntax has the same structure more or less (component, style, render, state, etc...)
:O this is so cool how did I never run into it! The most different SPA framework I had seen so far was ELM.
Sounds interesting!
But do you think it would be possible to achieve similar results without a new language, but with a declarative API in one of your existing languages (say, C++) instead?
If possible, that would remove a big adoption barrier, and avoid inevitably reinventing many language features.
A C++ library could wrap DOM APIs (WebCC already does this), but achieving a fine-grained reactive model purely in library code involves major trade-offs
A dedicated compiler allows us to trace dependencies between state variables and DOM nodes at compile-time, generating direct imperative update code. To achieve similar ergonomics in a C++ library, you'd effectively have to rely on runtime tracking (like a distinct Signal graph or VDOM), which adds overhead.
I think this genuinely might be the first time I'm seeing a language rework for UI's that actually makes sense and incorporates all that we've learned in the modern age about UI code.
What I am wondering is how language interop will work? The only way I see this growing is either you can easily import js libraries or you get a $100,000 dono and let Claude or any other LLM run for a few days converting the top 200 most used react packages to Coi and letting it maintain them for a few months until Coi's own community starts settling in.
I would love to use this for non web use cases though, to this date UI outside of the browser(native, not counting electron) is still doggy doo doo when compared to the JS ecosystem.
Well, you claim to combine server interesting features. Type safety, small binary size, high performance, predictable performance (no GC). So, I'm interested how this will turn out.
For web small binary size is really important. Frameworks like Flutter, Blazor WASM produce big binaries which limits their usability on the web.
JS/TS complicates runtime type safety, and it's performance makes it not suitable for everything (multithreading, control over memory management, GC etc.)
I wonder how much/if no GC hurts productivity.
It looks like Coi has potential to be used for web, server and cross-platform desktop.
Since the intermediate step is C++ I have a question what this means for hot-reload (does that make it impossible to implement)?
> It’s a component-based language that statically analyzes changes at compile-time to enable O(1) reactivity. Unlike traditional frameworks, there is no Virtual DOM overhead
This itself is quite cool. I know of a project in ClojureScript that also avoids virtual DOM and analyzes changes at compile-time by using sophisticated macros in that language. No doubt with your own language it can be made even more powerful. How do you feel about creating yet another language? I suppose you think the performance benefits are worthwhile to have a new language?
So the style and view parts work like f-strings in Python?
That's something I could live with.
From a syntax perspective, I prefer the component syntax in Vue / Riot, which is HTML-like. That way, the general structure is clear, and you have to learn only the additional directives. As a bonus, syntax highlighting in most editors just works without an additional plugin.
Gotta say the Shared Memory approach is genius. Finally someone's cutting down the clunky back-and-forth.
This looks very interesting! Do you have any tips/pointers on how one could use Coi to generate a component and then integrate it into an existing project which uses a traditional Javascript framework?
This looks quite promising. How long does it take to compile?
Did you compare with Svelte?
It appears in comparison chart on the linked page.
Came to ask this.
React and Vue aren't exactly known for their performance and Svelte does compile time optimizations.
Heh, not an argument against you or any point you made, today you are right. But when React first made an appearance, basically the two big selling points was 1) use same state in multiple places and 2) better performance.
Fun how with time, the core purpose of a library ever so slightly change :)
I mean, that was a decade ago and back in the day the only reasonable contenders were Angular and maaaaybe ExtJS.
Backbone.js, Knockout.js, Ember, Dojo, Prototype, YUI all were reasonable alternatives at the time. Although all with their own warts and highlights, as is tradition.
Nice work ! Thanks for shating
It reminds me of https://leptos.dev/ in Rust, although the implementation might be very different
Binary size alone got me interested. What's missing before 1.0?
would love to try it soon!
Awwww.. another language.
https://www.gnu.org/software/stow/manual/stow.html If what you want is an orchestrated symlink farm, here's your dude.
tl;dr wasm does not have access to dom, so i see no point in reading this.