unframework

import React, { useEffect, useRef } from 'react';
import ReactDOM from 'react-dom';
import { EventEmitter } from 'events';
import { Terminal } from 'xterm';
import { render } from 'ink';
/// <reference types="node" />

import 'xterm/css/xterm.css';

// this spins up Xterm.js, initializes Ink inside it and sets up

unframework

svg viewBox="-186 -46 374 48" width='374' height='48'
  defs
    clipPath id="lines"
      - for i in (0 .. 10)
        rect x=-300 y=(-47 + i * 5) width=600 height=4

  text.main x=0 y=0 text-anchor='middle' font-family='Days One' font-size='64px' letter-spacing='-3.5px'
    '<tspan clip-path='url(#lines)'>Beam</tspan>works

unframework

.logo <var>Beam</var>works

unframework

Keybase proof

I hereby claim:

• I am unframework on github.
• I am nickmatantsev (https://keybase.io/nickmatantsev) on keybase.
• I have a public key whose fingerprint is DEB7 3791 D4A3 7178 8DBF 1E00 0FCD 9C3F 4CB3 7BCA

To claim this, I am signing this object:

unframework

var vdomLive = require('vdom-live');

var counter = 0;

function incrementIt() {
    counter += 1;
}

vdomLive(function (renderLive) {

unframework

Maintainable Internationalization

Internationalization is a concern that affects almost everything in the frontend. It's hard to fix process mistakes. It's too easy to let cruft accumulate over a couple months, and have literally hundreds of files be affected. Adding a new locale means ensuring comprehensiveness of translation, and adding new UI text means updating all locales accordingly.

Workflow Requirements

• inventory of every localized piece of text
  • verify completeness of translation, audit use of idioms
• identify unused translation definitions

unframework

The Joel Spolsky Test (per www.joelonsoftware.com/articles/fog0000000043.html)

• Do you use source control?
• Can you make a build in one step?
• Do you make daily builds?
• Do you have a bug database?
• Do you fix bugs before writing new code?
• Do you have an up-to-date schedule?
• Do you have a spec?
• Do programmers have quiet working conditions?

unframework

Reading an HN thread on view frameworks (one of many such threads), I was reminded of my own past gist with sample code of an extremely idealized UI rendering loop:

// if only this was realistic...
setInterval(function () {
  // naively render the entire UI in its glory
}, 16); // 1000ms / 60fps

unframework

Focus is simply a pinpoint of interest, that then can be queried at render time. We shouldn't get caught up in thinking that it's a fixed enum thing; instead, each focus point is a simple boolean: is it on or is it off? Tab rendering is a particular application where one might multiplex the UI, and only one choice of several is selected - that 'radio' behaviour is another interesting thing.

If we go with habit and assume an hierarchy, what are the implications? Radio behaviour means that only one point in the hierarchy is focused at any point.

unframework

MVC and Modeling User Attention Span

A lot of user-facing app architecture can be simplified down to two main categories of code - model and presentation. Or M and VC of MVC (or MC and V, depending on one's interpretation of that venerable acronym).

Which code is considered which? I think the philosophical difference is that model is state that persists even when user is not directly interacting or watching it (non-visually as well, of course), and presentation is specifically tied to user attention span. That's a very vague definition, but it's food for some thought.

The pattern that typically ends up making sense is to of course make the model agnostic to how it is being rendered. User input mostly is "fed" into the model via direct imperative method calls. Resulting view of the model is given read-access to model state, to "pull" data out on demand.

But when to "pull" new data when the model changes?