getify

The Root of All (Web) Evils

The consumer web as we know it is around 30 years old, but of course its origins stretch back many years before. In those original days of the web, the infrastructure of how content was distributed and accessed was fairly de-centralized. If I had something to share, I'd put it in a digital location I owned/controlled, and you were invited to get that information directly. Nobody could tell me what I should and shouldn't create and share, and nobody could prevent your access if you wanted to see it.

But over the decades, this infrastructure has consolidated into ever more complex, and ever more expensive, centralized cloud providers. The "server-client" model is so ubiquitous now that it's hard for nearly anyone to imagine a web that could work in any other way than with "Big Cloud". While the centralization of the web has offered numerous scalability (and efficiency) benefits for web developers and web adminstrators, it has come with a vast increase in cost. And no I'm not real

getify

I'm the author of an npm package that comes as a single ESM-format module, let's call it "A". This package is only a client-side (browser) library, it will not work in Node -- it interacts with client-only web platform APIs.

The "A" package doesn't use any typical build tools (typescript, webpack/vite, etc). But it does include a simple "publish-build" script that's used at npm publish time to prepare a dist/ directory for the package.

The package relies on three npm package dependencies (call them "B", "C", and "D"), which I do not own/control. These 3 packages only distribute themselves as plain .js window-global style scripts. They cannot be imported, because (unfortunately) they make assumptions about global-scope this (being window), non-strict mode, etc. That also means they can't just be inlined into the "A" distribution module file.

Moreover, these dependencies are big enough (and potentially useful enough) that a user of "A" might also want to access and use "B", "C", or "D" functi

getify

var r = Reader();

console.log(
  r
  .map(env => ({ ...env, y: 2 }))
  .chain(env => Reader(() => ({ ...env, z: 3 })))
  .evaluate({ x: 1 })
);
// { x: 1, y: 2, z: 3 }

getify

// note: this requires a JS library for the IO monad, for example Monio: https://github.com/getify/monio/blob/master/MONIO.md#io-monad-one-monad-to-rule-them-all

// CHARACTER STATS...
//   letters, numbers, string-literal-chars (a-z A-Z 0-9 / < >): 273
//   non-letters-non-whitespace: 78
//     simple symbols (. ` " ( ) { } $ , =): 63
//     compound symbols (=>): 4 (8 chars)
//     optional semicolons: 6
//   whitespace: 73

getify

// note: this uses proposed JS syntax for pipeline operator: https://github.com/tc39/proposal-pipeline-operator

// CHARACTER STATS (code comments and their padded whitespace ignored)...
//   letters, numbers (a-z A-Z 0-9): 317
//   non-letters-non-whitespace: 138
//     simple symbols (+ - * / . " : ( ) [ ] { } , =): 94
//     compound symbols (=> ?? ?. |> %%): 15 (30 chars)
//     optional semicolons: 14
//   whitespace: 90

getify

function A() {
  var x = 1;
  C(B);
  
  function B() { console.log(x); }
  
  function C(callback) {
    B === callback;      // true
    
    B();                 // is this console.log() using a closure or not? depends on perspective.

getify

// ..

self.addEventListener("periodicsync",onPeriodicSync);

// ..

await registerPeriodicSync();

// ..

getify

if my three friends and I split a pizza evenly, and we all want more than one piece, how many slices should we cut the pizza into?

If you and your three friends want to split a pizza evenly and each person wants more than one piece, you should cut the pizza into at least 8 slices.

If you cut the pizza into 8 slices, each person can have two slices, and there will be two slices left over. You can decide how to split the remaining slices among yourselves, or you could also save them for later.

getify

(* as checked here: https://mdkrajnak.github.io/ebnftest/ *)
(* ebnf syntax rules defined here: https://github.com/Engelberg/instaparse *)

Program                 := WhSp* (StmtSemi WhSp*)* StmtSemiOpt? WhSp*;

Stmt                    := AStmt | BStmt | CStmt | DStmt;
StmtSemi                := Stmt? (WhSp* ";")+;
StmtSemiOpt             := Stmt? (WhSp* ";")*;

WhSp                    := "_";

getify

Comparing: array method chaining, generator delegations, and transducing

I'm writing this quick post to respond to a recent twitter conversation where claims were made about the merits (or lack thereof) of transducers, as they relate to composing list comprehensions (map, filter).

For comparison sake throughout the rest of my post, below you'll find three (actually four!) implementations of a simple list operation demo:

• Array Method Chaining (jump to analysis)
  • Alternate: Array Method Composition (jump to analysis)
• Generator/Iterator Delegations (jump to analysis)
• Transducing (jump to analysis)