loreanvictor

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

loreanvictor

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

loreanvictor

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:

loreanvictor

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 !:

loreanvictor

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:

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

loreanvictor

/**
 *
 * 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) => {

loreanvictor

//
// 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 {