kwasm
voby
| kwasm | voby | |
|---|---|---|
| 2 | 12 | |
| 12 | 156 | |
| - | - | |
| 0.0 | 9.7 | |
| about 2 years ago | almost 2 years ago | |
| Kotlin | TypeScript | |
| - | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
kwasm
-
Four Eras of JavaScript Frameworks
Where we will go from here, is pretty obvious.
Now that we've realized SSRs cannot be an optional afterthought, we'll soon realize SSRs with running JS on the server is a nightmare to scale - https://engineeringblog.yelp.com/2022/02/server-side-renderi...
Just search HN for "scaling server side rendering" and you'll land on a bunch of practical complications.
That doesn't mean SSR is bad. It just means we know the solution but stuck with the wrong tools.
My hypothesis is that we'll capitalize WebAssembly to run our UI rendering logic and a tiny platform-specific rendering layer to translate rendering commands from WASM to platform. Interesting side-benefit: Language choices other than Javascript.
I've already started working on a proof-of-concept React-ish library that runs on a WASM VM. IT lets you specify your UI component declaration and behaviour in Kotlin - https://github.com/joelewis/kwasm
-
Spin – WebAssembly Framework
3. A platform specific embedder can then write a tiny layer of renderer that translates commands from the WebAssmelby VM into native UI updates.
This way we can liberate UI programming from being too close to a platform and possibly could run on servers (damn fast SSR)
I'm attempting a proof of concept and I've logged my thoughts as I'm working through the project - https://github.com/joelewis/kwasm/blob/master/notes.txt
voby
- Voby: New React-like framework with Solid-like performance (no Babel, no magic)
- Voby: The new high-performance web framework, Observable-based, JSX support, no special Babel magic
- Voby: The new high-performance web framework with React-like convenience but Solid-like performance (and no magic)
- Voby: A new high-performance framework that achieves Solid-level performance with TypeScript's basic JSX transform
- Voby: A new high performance framework for writing rich applications
- Voby: A new frontend framework for high performance applications (no special Babel transform required!)
- Voby: a new reactive web framework that looks like React but with Solid-level performance, without needing a special Babel transform
- Voby: the new high-performance framework with React-like APIs but Solid-like performance (no special Babel transform required!)
- Voby: the new React-like framework with Solid-like performance (no special Babel transform required!)
-
Four Eras of JavaScript Frameworks
Actually that's just a common misconception, which I believed too.
The complex compile-time transforms enable almost no performance improvements.
As a proof just take a look at the js-framework-benchmark table [0], my framework (Voby [1]) is faster than both in the framework despite having an API very similar to Solid and no requirement for a Babel transform or other compile-time transform (though the basic React-like JSX transform is supported for convenience).
Those transforms actually exist 99% just for providing some convenience features to the developer. If that weren't the case it would be possible to make something similar without a transform that's faster than both. In fact Svelte is actually quite a bit slower than both Voby and Solid.
[0]: https://krausest.github.io/js-framework-benchmark/current.ht...
[1]: https://github.com/fabiospampinato/voby/
What are some alternatives?
wit-bindgen - A language binding generator for WebAssembly interface types
Svelte - Cybernetically enhanced web apps
spin - Spin is the open source developer tool for building and running serverless applications powered by WebAssembly.
oby - A rich Observable/Signal implementation, the brilliant primitive you need to build a powerful reactive system.
spec - WebAssembly for Proxies (ABI specification)
voby - A high-performance framework with fine-grained observable-based reactivity for building rich applications.
lunatic - Lunatic is an Erlang-inspired runtime for WebAssembly
ag-Grid - The best JavaScript Data Table for building Enterprise Applications. Supports React / Angular / Vue / Plain JavaScript.
wasmblog - Blog using Bartholomew served by WASI
Marble.js - Marble.js - functional reactive Node.js framework for building server-side applications, based on TypeScript and RxJS.
bartholomew - The Micro-CMS for WebAssembly and Spin
estrela - Full Reactive Framework.