3.1 KiB
WIP (the experimentation phase) | source code on GitHub | mirrored on Gitea
Vanilla by default — steroids if needed …use simple DOM API by default and library tools and logic when you need them
const value= S("");
document.body.append(
el("span", { style: { fontWeight: "bold" }, textContent: value }),
el("input", { type: "text" },
on("change", event=> value(event.target.value)))
);
Deka DOM Elements
Creating reactive elements, components and Web components using IDL/JavaScript DOM API and signals (Signals — whats going on behind the scenes | by Ryan Hoffnan | ITNEXT or The Evolution of Signals in JavaScript - DEV Community).
Inspiration and suggested alternatives
- my previous (mostly internal) library: jaandrle/dollar_dom_component: Functional DOM components without JSX and virtual DOM.
- vanjs-org/van: 🍦 VanJS: World's smallest reactive UI framework. Incredibly Powerful, Insanely Small - Everyone can build a useful UI app in an hour.
- hyperhype/hyperscript: Create HyperText with JavaScript.
- adamhaile/S: S.js - Simple, Clean, Fast Reactive Programming in Javascript (adamhaile/surplus: High performance JSX web views for S.js applications)
- potch/signals: a small reactive signals library
Why an another one?
This library should lies somewhere between van/hyperscript and solid-js (S). In the meaning of size, complexity and usability.
An another goal is making clear library logic. Starting from pure native JavaScript (DOM API),
then using small utils (assign
, S
, …, el
, …) and end up with way to write complex code.
Therefore, you can use any „internal” function to make live with native JavaScript easier
(assign
, classListDeclarative
, on
, dispatchEvent
, …, S
, …) regarding if you don’t
need complex library/framework.
As consequence of that, it shouldn’t be hard to incorporate the library into existing projects. That can make potecial migration easier.
To balance all requirements above, lots of compromises have been made. To sumarize:
- library size 10–15kB minified (10kB originaly)
- allow using signals optionaly and allow registering own signals implementation
- no build step required
- prefer a declarative/functional approach
- prefer zero/minimal dependencies
- support/enhance custom elements (web components)
- support SSR (jsdom)
- WIP provide types