Eugene Ghanizadeh loreanvictor

Reactive JavaScript

THIS SHOULD BE MOVED TO A REPOSITORY FOR BETTER ORGANIZATION, AS IT IS GETTING PRETTY MESSY HERE.

Also inspect whether a babel plugin can be developed for this (check this and this).

I have always wondered whether we could extend syntax of JavaScript to natively support reactive primitives, how would that look and whether that would be useful or not. This is a mental excercise on that front.

Some Definitions

Imperative Reactive Programming

Ok so this is a personal investigation of how reactive programming can be better embedded in imperative languages in general. I have conducted such an investigation for JavaScript already with interesting results, but focusing solely on JavaScript and its conventions might be a bit limiting as I feel results can be achieved that are more generally applicable.

The Problem

A lot of modern programs work with reactive values or observables, i.e. values that change over time (number of clicks on a button, time of a timer, position of the mouse cursor, etc.). These values need to get processed, combined with other observables, etc.

Imagine a simple use case: a text input with a word count display underneath. You can specify this with a simple pseudo-code as follows:

`pre`

No build is cool and all, but two things are inherently missing (and will remain missing):

Web components are rendered client side
No markdown support

Solution

The first issue can be resolved with the following simplistic tool:

Can We Get More Decentralised Than The Fediverse?

I guess that the [fediverse][fediverse] will be as decentralised as email: a bit, but not that much. Most people will be dependent on a few major hubs, some groups might have their own hubs (e.g. company email servers), personal instances will be pretty rare. This is in contrast to personal blogging, where every Bob can easily host their own (and they often do). I mean that's already implied by the name: fediverse is [a federated universe, not a distributed one][fed-v-dis].

Why does this matter? Well I like not being dependent on one entity, but I would like it much more if I was dependent on no entities at all. In other words, I like to publish my own personal blog and get all the goodies of a social network, without being dependent on other micro-blogging / social content platforms.

So in this writing, I'm going to:

❓ Contemplate on why the fediverse gets federated not distributed (spoilers: its push vs pull)
🧠 Ideate on how could we get a distri

these are some guidelines I find useful for designing good APIs, specifically for third-party consumers.

(ab-)use existing standards
minimise API surface
keep it crazy composable
provide least power
bake in security and privacy
mind what you promise
make it elegant
don't change things

Offer-based Chain of State Ledger

UTXOs make it hard to calculate account balance. This can be fixed by merging all UTXOs of an account into one UTXO, and forking that UTXO into one to the recipient account and the remainder to the same account, for "spending". This constraint can be baked into all transactions, which turns the ledger into an effective snapshot history of each account (chain of state), while still being as secure, predictable and light-weight, though with reduced parallelizability.

Since during each transfer affected UTXOs are "locked" (concurrent operations on them result in conflicts and all but one of such conflicting changes will be dropped, or alternatively they are locked to avoid concurrent modifications), and since in such a mechanism each account will be a single UTXO, conducting the fork (from source account) and merge (into t

	//
	// NOTICE: these two declaration modules should go into separate typing files, but since the purpose of this gist
	// is elaboration, I put them in the same place.
	//
	// NOTICE: the attributes are intentionally not typed strictly, allowing any custom tsx renderer to work with its own
	// objects (imagine passing functions or `Observable`s to attributes).
	//

	declare module HTML {
	interface Attributes {

	/**
	*
	* I think garbage collection with this scheme is definitely not enough.
	* However, I need to double check with the protocol, and perhaps with
	* this minimalist garbage collection scheme and a simple echoing of terminate signals
	* we will achieve proper dereferencing.
	*
	*/

	const makeStreamLayer = (receive) => {

	vec2d(x, y):
	length: $ sqrt(x * x + y * y)
	unitary op -: $ vec2d(-x, -y)
	binary op + (other): $ vec2d(x + other.x, y + other.y)
	binary op - (other): $ vec2d(x - other.x, y - other.y)
	binary op * (other): $ x * other.x + y * other.y
	binary op / (k): $ vec2d(x / k, y / k)
	unitary op ^: $ self / length

	unitary postfix op !: