unframework

HTML/CSS Encapsulation At Runtime

Web-based UIs are hard to componentize into encapsulated widgets. DOM + CSS and the browser runtime have their roots in a document-based, progressive-rendering mentality, and that creates friction when attempting to develop components that don't step on each others' feet.

My ultimate starting point when dealing with encapsulation in-browser is to consider the runtime state produced by the combination of JS, DOM API and CSS behaviour.

In purest form, there are just JS objects that exist in memory of the browser and interact with each other via vanilla method calls and data access. The surface of encapsulation of a pure-Javascript component is just its public methods and properties.

When it comes to displaying things on screen, part of the widget component contract becomes rendering something visible in the browser viewport. Of course, we typically use DOM and CSS to do that (although Canvas-driven app UIs do exist). It makes sense to look at DOM and CSS as a sort of

unframework

Enterprise Apps: ORM vs Key-Value Storage Model

Enterprise software models the real world of human activity, interaction, business transactions. Let's consider a typical person modeled by a run-of-the-mill e-commerce app. They'll have a few attributes (read: DB table columns):

• first, last name
• authentication credentials
• shipping address
• payment info (PayPal/Stripe token, billing address, etc)
• avatar picture

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?

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

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

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

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

var counter = 0;

function incrementIt() {
    counter += 1;
}

vdomLive(function (renderLive) {

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

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

.logo <var>Beam</var>works