## DEV Community π©βπ»π¨βπ» is a community of 966,904 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Ryan Carniato for This is Learning

Posted on • Updated on

# The Quest for ReactiveScript

This article isn't going to teach you about the latest trends in frontend development. Or look in detail into the way to get the most performance out of your website. Instead I want to write about something that I've been playing with in my head for the past year but never can find the time to work on. Reactivity as general purpose language.

If you want someone to blame. Blame Jay Phelps (I kid). After a demo I made showing off the power of fine-grained reactivity he got it in my head that we should look at this more as a generalized language. I was content in my DSL bubble, thinking of ways we can make building frameworks easier, but he challenged me to think about it more generally.

I've been meaning to take him up on his offer, but in the meantime what I can do is write about it. Because the last year I've done a lot of searching and thinking into how I'd approach this. And thanks to more recent conversations around Svelte, Vue Ref Sugar, and my work on Marko etc.. this seems as good time as ever to share what I've learned.

## The Destiny Operator

One of the best introductions I've ever read to reactivity, after the fact is What is Reactive Programming?. I can't promise it's the best introduction for the uninitiated. But it introduced reactivity in a very simple way. That reactivity is when an equation which holds true even after its values change. If `a = b + c`, then it is reactive if `a` still reflects this sum after `b` or `c` updates.

This article proposes the use the "Destiny Operator" `<=` to denote this relationship:

``````var a = 10;
var b <= a + 1;
a = 20;
Assert.AreEqual(21, b);
``````

A simple addition to the language but capable of doing so much. Most importantly it highlights the difference between a reactive declaration and an assignment. It makes no sense for `b` to ever be re-assigned as then its relationship of always being one larger than `a` wouldn't hold. Whereas `a` needs to be re-assigned or this system isn't really doing much.

This is just the start. In many ways this has been seen to be the ideal. Reality is a bit more complicated than that. We will return to the "Destiny Operator" a bit later.

## Identifiers

If you've ever used a fine-grained reactive library in JavaScript you've seen the common pattern of using function getters/setters. They might be hidden behind proxies but at the core there is an accessor so that values can be tracked and subscriptions made.

``````const [value, setValue] = createSignal(0);

// log the value now and whenever it changes
createEffect(() => console.log(value()));

setValue(10); // set a new value
``````

In fact I'd say the majority of frontend JavaScript frameworks have fallen into this 3 part reactive API/language:

1. Reactive State (Signal, Observable, Ref)
2. Derived Values (Memo, Computed )
3. Side Effects (Effect, Watch, Reaction, Autorun)

The example above uses Solid but you should be able to picture that pretty easily in React, Mobx, Vue, Svelte etc. They all look very similar.

For a more in detailed introduction check out A Hands-on Introduction to Fine-Grained Reactivity

The problem is no matter what we do with fine-grained reactivity at runtime there is extra syntax. There is no way at runtime to just have `value` be a value and be reactive. It's going to be `value()` or `something.value` or `value.something`. A small ergonomic detail but one that there is a desire to solve.

The simplest compiler aided approach is decorate the variable identifiers to let it know it should compile to function calls. I first saw this in the framework Fidan and later in some Babel plugins the community had created for Solid.

``````let value\$ = createSignal(0);

// log the value now and whenever it changes
createEffect(() => console.log(value\$));

value\$ = 10; // set a new value
``````

``````let value\$ = createCustomReactiveThing();
``````

However, now our signal is always treated as a value. How would we pass it outside of this module context and retain reactivity? Maybe we reference it without the `\$`? Do we pass it in a thunk `() => value\$`, do we invent a syntax for this? Do we have control over if the reactive value is readonly? As shown above derived reactive values probably should be. I actually saw a version of this where single `\$` meant mutable and `\$\$` meant readonly.

The crux though is this syntax doesn't simplify the mental model. You need to be aware exactly what is being passed around and what you are receiving. You are saving typing some characters, possibly as little as 1 as the shortest way to express reactivity without compiler tricks is 2 characters(`()` or `_.v`). It's hard for me to consider adding all this is worth it.

## Keywords, Decorators, Labels

So how to do this better? Well what if reactivity was a keyword, decorator, or label? MobX has been doing this for ages with decorators on classes but Svelte has taken this to a whole new level.

The basic idea is:

``````signal: value = 0;

// log the value now and whenever it changes
effect: console.log(value);

value = 10; // set a new value
``````

Svelte realized that if it treated every variable as a Signal it could reduce that to:

``````let value = 0;

// log the value now and whenever it changes
\$: console.log(value);

value = 10; // set a new value
``````

If this draws similarities to the "Destiny Operator" it should. Svelte's `\$:` label is really approaching it. They recognized the "Destiny Operator" was insufficient as you don't only have reactive derivations but side effects like this `console.log`. In so you can use `\$:` both define variables with reactive declarations like the "Destiny Operator" as well as reactive effectful expressions.

So we're done right. Well no. There are huge limitations of this approach. How does reactivity leave this module? There is no way to get a reference to the reactive signal itself; just its value.

Note: Svelte does have 2 way binding syntax and `export let` as a way to do parent to child passing of reactivity. But in general you can't just export or import a function and have it reactive without using an auxiliary reactive system like Svelte Stores.

How do we know what to do with:

``````import createCustomReactiveThing from "somewhere-else";

let value = createCustomReactiveThing();
``````

Is it reactive? Can it be assigned? We could introduce a symbol on our identifiers for this case, but we are back to where we were with the last solution. What if you wanted to extract out a derivation like `doubleValue` how would the template know what to do with it.

``````let value = 0;

// can this
\$: doubleValue = value * 2;

// become
const doubleValue = doubler(value);
``````

Not intuitively. We have a keyword(label) for it and it doesn't transpose.

## Function Decoration

Well composition is king. Probably the single most important part of React's success and for many of us no composition is a non-starter. Svelte has composition and extensibility through its stores, but the focus here today is in the reactive language where it falls short.

There is another approach that I first came across talking with the Marko team almost 2 years ago. Marko is an interesting language because it heavily values markup syntax, and the maintainers had basically resolved that they wanted to bring their reactivity into their tags.

``````<let/value = 0 />
<!-- log the value now and whenever it changes -->
<effect() { console.log(value); }/>

value = 10; // set a new value
``````

Definitely foreign on the first look but by using tags they'd basically solved Svelte's problem. You knew these were reactive. It is the syntax version of something similar to React's convention that `use____` is a hook.

Interestingly enough, about a year later Evan You independently came to the same conclusion with version 2 of his Ref Sugar API for Vue 3. Version 1 was labels like above but he realized the shortcomings of that approach and ended up with:

``````let value = \$ref(0)

// log the value now and whenever it changes
watchEffect(() => console.log(value));

value = 10; // set a new value
``````

Well it's almost the same thing as the Marko example. This approach actually gives most of what we are looking for. We've regained composition.

However, there is one consideration here still when it comes to passing references out of our current scope. Since Vue is using this as a bit of a syntax sugar like the identifier example earlier it needs to tell the compiler still when it wants to pass by reference instead of by value, and there is the `\$\$()` function for that. For instance if we wanted to pass explicit dependencies in:

``````let value = \$ref(0)

// log the value now and whenever it changes
watch(\$\$(value), v => console.log(v));
``````

Notice how `watch` here is just an ordinary function. It couldn't know how to handle `value` any differently. If left alone it would compile to `watch(value.value, v => ... )`, which would do the reactive access too soon outside a tracking scope.

There are some comments in the proposal asking for a `\$watch` to handle exactly that but I suspect they won't pass because that is specific behavior that `\$(function)` doesn't have. Vue's goal is to be composable, so having `\$watch` be special isn't acceptable. That makes it basically a keyword, as `\$mywatch` wouldn't be known to be given the same behavior, unless we added another syntax or made more general changes to behavior.

In fact none of the solutions, short of Marko's tags, handle that case without extra syntax. Marko can leverage the knowledge of being a tag to make some assumptions you can't make about an ordinary function. And being tags we inadvertently stumbled on what I believe might be the actual solution.

## Rethinking Reactive Language

All the approaches suffer from the same challenge. How do we preserve reactivity? We are always worried about losing it, and we are forced into this pass by reference vs pass by value discussion. But that is because we are living in an imperative world, and we are a declarative girl paradigm.

Let me elaborate a bit. Marko uses a `<const>` tag for declaring reactive derivations. Our "Destiny Operator" so to speak. This sometimes confuses people because derived values can change so how is it "const"? Well it never gets re-assigned and the expressions holds for all time.

When I was trying to explain this to someone new, Michael Rawlings(also on the Marko team) clarified it was the `let`(Signal) that was special not the `const`(Derivation). Every expression in our templates act like a derivation, every attribute binding, component prop. Our `<const value=(x * 2)>` is no different than a `<div title=(name + description)>`.

Which got me thinking what if we've been looking at this all backwards. What if expressions were reactive by default and instead we needed to denote the imperative escape hatches? Instead of a "Destiny Operator" we'd need a side-effect operator.

This seems crazy because would it be intuitive to change the semantic meaning of JavaScript yet keep the same syntax? I assumed no, but I mean we've already seen this done to great success. Svelte's scripts are nothing like "plain JavaScript" yet people seem to be accepting of those and some even advertising them as such.

I did poll a while back and while not conclusive the results suggested many developers are much more sensitive to syntax than semantics.

So the question is can we do something using the existing syntax of JavaScript and keep all the tooling advantages(even TypeScript)? I mean completely mess with how it executes in the way things like Svelte, React Hooks, or Solid's JSX defies expectations but do so with pure JavaScript syntax and in way people can make sense of. Well, we can try.

## Designing ReactiveScript

For all of my, what might sound like criticism, over decisions made in the various approaches above there is a lot of great prior work to tap into. I think Svelte today is a good starting point as it has simple syntax and already distorts the expected semantics. Taking the example from above picture we want to hoist the `console.log` into another function (maybe imported from another module). This isn't something Svelte does today but maybe something like this:

``````function log(arg) {
\$: console.log(arg);
}

let value = 0;

// log the value now and whenever it changes
log(value);

value = 10; // set a new value
``````

For the sake of visualizing how things actually behave I'm going to "compile" these down to Solid's explicit runtime syntax. Although this being runtime based isn't a requirement.

``````function log(arg) {
createEffect(() => console.log(arg());
}

const [value, setValue] = createSignal(0);

// log the value now and whenever it changes
log(value); // or log(() => value())

setValue(10); // set a new value
``````

All function arguments get wrapped in functions (or pass the function straight through). All local scoped variables get called as functions.

How about if we want to create a derived value? In our new reactive world that might look like:

``````let value = 0;
const doubleValue = value * 2;

// log double the value now and whenever it value changes
log(doubleValue);

value = 10; // set a new value
``````

Or we could even hoist it out:

``````function doubler(v) {
return v * 2;
}

let value = 0;
const doubleValue = doubler(value);
``````

Which could compile to:

``````function doubler(v) {
return () => v() * 2;
}

const [value, setValue] = createSignal(0);
const doubleValue = doubler(value);
``````

You might be scratching your head at this example because well does anything ever run? Well it doesn't unless it needs to. As in it is used in a side effect denoted by `\$:`. We have a lazy evaluated language that only runs code when absolutely needed.

Our derived value is still assigned to a `const` so it remains consistent. No need for new syntax to know exactly what its behavior is. In a sense reactive values don't escape their local scope like in Svelte from a mutation standpoint but they do from a tracking standpoint. The retains clear control while affording the convenience of local mutation.

This "every expression is reactive" can extend to language primitives as well. In a similar way to how Solid transforms ternaries in JSX we could look at things like `if` and `for` statements and compile them accordingly.

``````let value = 0;

if (value < 5) {
log("Small number");
} else log("Large number");
// logs "Small number"

value = 10;
// logs "Large number"
``````

This code would end up running both branches of the `if` once the condition changes. And those side effects don't need to `console.logs` at all and could be anything like maybe JSX.

What if you could write components like this and have it work with minimal executing fine-grained reactivity.

``````function Component({ visible }) {
let firstName, lastName = "";
if (!visible) return <p>Hidden</p>;

// only do this calculation when visible
const fullName = `\${firstName} \${lastName}`

return <>
<input onInput={e => firstName = e.target.value} />
<input onInput={e => firstName = e.target.value} />
<p>{fullName}</p>
</>
}
``````

## Just a taste

Honestly, there is a ton of details to work through. Like loops for example. We naturally want a `.map` operator rather than a `for` in this paradigm so how do we reconcile that? However what this has going for it is, it is analyzable and the pattern applied consistent.

Performance of such a system might require a lot more consideration. I think this actually has more potential with additional analysis and compile time approaches. Looking at what `let`/`const` are actually stateful could inform what to wrap or not. And once on that path, well, this goes many places. It could be used as a tool for things like partial hydration to know exactly what code actually can update and be sent to the browser.

Honestly this is just an idea for now. And I have a lot more thoughts on how this could function. But with all the recent discussions I thought someone might be interested in exploring this and I encourage them to reach out and discuss!

IMO, the part about svelte's reactive language falling short is only half-truth. In svelte if we want composition we'd start with writable store in the first place, with practically the same reactive language like Vue's.

Giving the `\$store` syntax sugar, it feels very native to svelte's reactive language, and shouldn't be left unmentioned.

``````let a = writable(0);  // equiv to \$ref(0)
\$: doubled = \$a * 2;

\$a = 10;

// or without language sugar magic:

// equiv to watch(\$\$(a), v => {...})
a.subscribe(value => {
const doubled = value * 2;
console.log(doubled)
}

a.set(10);

``````

Talking about store being auxiliary, it's actually a good thing, not some kind of burden/cost. Cus it's opt-in, swappable. You can freely switch to redux or rxjs store if you want. You don't get eco locked-in like with Vue's `\$ref` or Solid's `createSignal`.

Ryan Carniato • Edited on

Right, but as mentioned a couple of times, that is outside of the "language" part. I like Svelte stores. And they solve a very very necessary problem and having sugar makes them feel more native. But the juxtaposition makes it instantly clear of language/compiler limitations. It wraps a 2nd completely different reactive system. If Svelte only used stores I suspect it might not have been so. The insistence on being just JS/HTML by its followers also amplify this.

And really the purpose of this article is wondering if we can somehow find the holy grail. A truly composable reactive system that doesn't introduce a ton of new syntax. Svelte gets most of the way there, but what does all the way look like?

Kenneth Tilton

Not sure how holy anything I make can be, but my reactive system hides pretty well behind "define_property": tilton.medium.com/simplejx-aweb-un...

I have been enjoying your surveys of reactive alternatives and learned a few new ones! I need to get out more, missed Recoil completely!

Jin

``````var a = 10;
var b <=> a + 1;

a = 20;
Assert.AreEqual(21, b);

b = 20;
Assert.AreEqual(19, a);
``````

Luke Chu

This would be impossible to implement in the general case because the compiler would essentially be solving an equation. In most cases, this would be impossible because there could be multiple solutions for a depending on the value of b. In other cases, reversing the operation would simply be impossible, e.g. a hash function.

Azriz Jasni

``````var a = 10;
reactive b = a + 1; // of course to long :D

a = 20;
Assert.AreEqual(21, b);
``````

Ryan Carniato

Then we are looking at a label/keyword example and that all applies. My point is it is easy to bucket all solutions into these categories or hybrids of them. We can debate the exact naming/syntax but I have been wondering if we can escape this altogether.

Jin • Edited on
``````var a = 10;
ever b = a + 1; // not so long

a = 20;
Assert.AreEqual(21, b);
``````

Ryan Carniato

That's interesting. Scares me a bit. Part of me really wants to make mutation(assignment) special and isolated but I just might not be letting go enough to fully embrace this thinking. Would it ever be difficult to reverse the derivations? Sure subtracting 1 from b is easy enough. I just wonder if that wouldn't always be the case.

Jin • Edited on

It's the lens in general. See JS example:

``````let _a = 10
const a = ( next = 10 )=> return _a = next
const b = ( next )=> a( next === undefined ? undefined : next - 1 ) + 1

a(20);
Assert.AreEqual(21, b());

b(20);
Assert.AreEqual(19, a());
``````

We actively use this that approach in this way:

``````class App {

// it's signal
@ \$mol_mem
static a( next = 10 ) { return next }

// it's derivation but with same api as signal
@ \$mol_mem
static b( next ) {
return this.a( next === undefined ? undefined : next - 1 ) + 1
}

}

App.a(20);
Assert.AreEqual(21, App.b());

App.b(20);
Assert.AreEqual(19, App.a());

``````

3Shain

It only makes sense if the mapping is a bijection (math term). It's a really rare property, meaning zero information loss.

Jin

No, It's very common. We can bind local property with part of json which bind with local storage as example. So write to property will change json at local storage and affects to same property of another instance of same app. Example:

``````class Profile {

@ \$mol_mem
store() {
return new \$mol_store_local({
profile: { name: 'Anon' }
})
}

@ \$mol_mem
name( next?: string ) {
return this.store().sub( 'profile' ).value( 'name', next )
}

}

const profile = new Profile

profile.name() // 'Anon'
profile.name( 'Jin' ) // 'Jin'
// restart app
profile.name() // 'Jin'
localStorage.getItem( 'profile', '{ "name": "Anon" }' )
``````

3Shain

Bi-directional bindings re-invented? Fair enough.

Kenneth Tilton

The problem may be in trying to make standalone vars reactive. But standalone vars may be a requirement because objects got thrown out, because a reactive object can hide reactivity behind reactive accessors. So the real problem, then, is throwing out objects. The funny thing being that objects where different instances can have different reactive definitions for the same property, and where different instances can have additional properties (the prototype model), kinda solves all the problems of OO. But we cannot have objects because ReactJS (how ironic now is that name?) needs functions everywhere so they can control state change, which is also why React add-ons must now let React manage all state. See "concurrent mode". So the real problem may be the impedance mismatch between trying to achieve reactive state in ReactJS, which has officially rejected the paradigm for its eagerness.

the tl;dr for the above is "slippery slope". :)

Oxford Harrison

These are all interesting experimentations. And here's one approach I've been explororing since last year: Subscript - reactivity without any special syntaxes or language tokens, but just regular, valid JavaScript.

It is implemented as a UI binding language:

``````<div title="">
<script type="subscript">
let title = this.state.title || 'Some initial text';
this.setAttribute('title', title);
</script>
</div>
``````

Above, the 'this' keyword is a reference to the `<div>` element; and `this.state.title` is the state being observed. Now the `let` expression evaluates each time the state of `this.state.title` changes, and the `this.setAttribute()` call picks up the new value of `title` each time. This is what happens when state is changed as in below:

``````let div = document.querySelector('div');
div.state.title = 'New title';
``````

It's that simple; it's pure JavaScript that works reactively by just understanding reference stacks. Details are here: webqit.io/tooling/oohtml/docs/gett...

I moved on implementing it's runtime and making a real world app with it. Waiting to see where this leads.

Ryan Carniato

I see in this example you have accessor on the state on the element which serves as the signal and the script("subscript") itself is the wrapped effect. Makes sense. I see no problem with runtime reactivity without special syntax. SolidJS works that way today. But the desire for getting rid of the `this.___` or `state.___` is almost feverish pitch so I thought I'd try my hand at the problem.

Evan You

FWIW, the Vue example is a bit misleading: you don't need `\$\$()` for common reactive effects if using `watchEffect`:

``````let value = \$ref(0)

// log the value now and whenever it changes
watchEffect(() => console.log(value));

value = 10; // set a new value
``````

`\$\$()` is only needed if you have external composition functions that explicitly expect a raw ref object as arguments.

Ryan Carniato • Edited on

Ok. Thanks Evan. I have updated that section to better represent common patterns in Vue. Thank you.

For what it's worth, without completely messing with the semantics I think the Function decoration approach like found in Vue Ref Sugar is the only approach that actually checks all the boxes. But I'm interested in what happens if we do just mess with everything.

I love the concepts. For these new concepts to be adoptable into EcmaScript they'd have to play well with the existing imperative constructs, living along aside them, while reducing any chance for ambiguity.

Maybe the label idea isn't so bad if it propagates into every place it the feature is used, like

``````import { foo@ } from './foo'

signal count = 0

log(count@)

setInterval(() => foo@ * count@++, 1000)

function log(value@) {
effect { console.log(value@) }
}
``````

or something.

Now, I'm not sure this is the best syntax, or that it doesn't have any issues, or that `@` is the best symbol, but the idea with signal names requiring to be postfixed with `@` in the example is

• usage sites are clear and semantic: we know we're dealing with a signal
• receiving or passing sites (identifiers in import or export statements, function parameters, etc) have the same naming requirement and can only accept or receive signals (so passing "by ref" or "by value" is not relevant at these sites anymore, we just "receive a signal" or "pass a signal").

Another thing to consider is that, if dependency-tracking were applied to all of JavaScript's existing features, what would this imply for performance?

The performance characteristic of every variable, every property, every parameter, every usage site, would change (probably get slower) just so that reactivity works. With a parallel syntax to keep the imperative and declarative paradigms decoupled, we can limit any overhead strictly to those signal variables and their consumers, without affecting the engine implementation of the other features. This would reduce implementation complexity for people who write and maintain the JS engines.

I'm hoping this will spawn more discussion on the possibilities!

Andrea Giammarchi

I've played around this topic a bit myself, and the gist was something like this:

``````const invoke = \$ => \$();
const signal = value => function \$() {
if (arguments.length) {
value = arguments[0];
if (effects.has(\$))
effects.get(\$).forEach(invoke);
}
return value;
}

const effects = new WeakMap;
const effect = (callback, \$\$) => {
const fx = () => callback(...\$\$.map(invoke));
for (const \$ of \$\$) {
if (!effects.has(\$))
effects.set(\$, []);
effects.get(\$).push(fx);
}
fx();
return fx;
};
``````

This basically lets one compose values as effects too, example:

``````const a = signal(1);
const b = signal(2);
const c = effect((a, b) => a + b, [a, b]);

console.log(a(), b(), c()); // 1, 2, 3

a(10);
console.log(a(), b(), c()); // 10, 2, 12

b(7);
console.log(a(), b(), c()); // 10, 7, 17
``````

My thinking is that a variable that effects from others won't ever directly change itself, so that setting `c(value)` might, instead, throw an error.

As for the syntax, I find the reactive bit being well represented by functions so that `let b <- a + 3;` doesn't look too bad:

• it's broken syntax these days, so it can be used/proposed
• it is the equivalent of `() => a + 3;` except it accepts zero arguments as it cannot be directly invoked, and the arrow points at the reference that should reflect whatever the body/block returns.

Interesting stuff. I wrote a language that I never got to implement (of course but who knows if one day I won't find the time to do it) that does what you suggest. The language is simple, and based on the core functional reactive programming concepts. You have events, effects, and pure computations. Excerpts:

``````-- events. Syntax: event => effect (here state update)
clickPlus => counter <- counter + 1
clickMinus => counter <- counter - 1

-- equations
unit_price = 100
price = counter * unit_price
...

-- effect. Syntax: event => effect
update(price, counter, ...) => render ...
``````

So just three key elements of syntax, `event => action` notation to express reactions, `=` for equations that must always hold at any point of time (your `const` ?), and `<-` to update an equational variable.

There is nothing particularly smart there. Synchronous reactive languages are not much different than that (Lucid, Esterel, etc.). It is not the smartness, it is more the simplicity of the notation.

For composition, it is simply about noting that a program is a set of events (left side of x => y), variables (left side of x = y), and action/effect handlers (right side of x => y). So `Program<Events, Variables, Effects>` basically. To get one big Program from two small Programs, just import those two small in the big one and possibly rename the variables, events, effects (to avoid shadowing) - just like you would do with template partials in good old HTML templating systems. But the story was not perfect for composition. Renaming is a hassle that breaks a bit module independence (the big component that reuses the small one need to know about the details of the used component. Ideally you should not need to know about the variables in the reused component, they should be encapsulated).

Haven't put myself to solve these problems though. So it is interesting to read this writing.

Jin

It is interesting to see here the destiny operator, in which we have been using component composition description language for a long time.

A few examples of how we declare object methods (channels):

``````name \Jin
``````

This is a method that returns a constant string (one way channel).

``````name?val \Jin
``````

This is the same, but the meaning can be changed (singal in your terminology and two-way channel in ours).

Now the operator of destiny:

``````greeting /
\Mr.
<= name
``````

There is already a derived method that returns an array from a constant string and the values of another method.

And now, the most interesting thing is the bidirectional channel:

``````title?val <=> name?val
``````

We can read and write in 'title' without even knowing that we are actually working with 'name'.

And then there is the reverse destiny operator:

``````name => title
``````

It may seem that this is the same as the normal destiny operator, but it matters when linking components to each other:

``````sub /
<= Input \$mol_string
value => name
<= Output \$mol_paragraph
title <= name
``````

Now the `Output` directly uses the value from the `Input`, and we control it through the "name" channel.

And yes, `Input` and `Output` is channels too which returns cached instance of other components.

Here you can see the generated TS code.

Artyom

When we talk about reactive language we should think not about reactive programming or even reactive data accessors, but about reactive data structures. The main point of separate language for reactive datas is that it should work perfectly (effecianlty) with a data with all possible (by a language) ways. In other words, the language should expose API for data accesing and transformation and limit it to fit in a most efficient compile output. It means we should be able to analize AOT all accessors in classic `for` / `map` and optimize it or throw it away from a language and replace it by some variations of `pick`: `listOfAC = listOfAB.pick({a: 'identity', b: b => toC(b) })`.

Ryan Carniato

I think there probably is some amount of API that is unavoidable but there is something attractive about not having much in the way of API for this. We might have no choice for things like lists. To specially handle compilations for things like array literals. Mostly I don't view this necessarily always been in a runtime primitive mechanism. The reason I focus on language is because as our analysis gets better the implementation could change dramatically. We see this with Svelte and I've seen this taken even further with Marko. Those don't even have reactive primitives anymore at runtime but just call some functions. My hope is that behavior (but not the implementation) can be well defined in mostly with regular language mechanisms. Lists might just have to be the exception.

Dumb Down Demistifying Dev

Svelte `?:`
Solid `!:`

Need a better mental model for async/await?

Check out this classic DEV post on the subject.