artemave

Everybody knows React. But what is Hyperdom?

Hyperdom is a virtual dom based framework. It's been first released around 5 years ago and back then was known as Plastiq.

Hyperdom was set out to fix some of the react shortcomings (more on that later) and it has succeeded to do so. The ultimate goal however was to make a tool that we could use to build websites for our clients faster and easier. As a consequence Hyperdom remained in the dark as no attempts to market it were made.

Back then the SPA framework scene was fluctuating without a clear leader. And so we were able to get away with using Hyperdom. That seems to have changed in recent years with React emerging a defacto standard. At least according to what our clients demand (fun fact: 5 years ago they were insisting on Angular 1).

Over the years a strong community built up around React. There is plethora of solid complimentary projects that solve all sorts of problems. To be fair, that alone is a good reason to stick to React.

artemave

Everybody knows React. But what is Hyperdom?

Hyperdom is a virtual dom based framework. It's been first released around 5 years ago and back then was known as Plastiq.

Hyperdom was set out to fix some of the react shortcomings (more on that later) and it has succeeded to do so. The ultimate goal however was to make a tool that we could use to build websites for our clients faster and easier. As a consequence Hyperdom remained in the dark as no attempts to market it were made.

Back then the SPA framework scene was fluctuating without a clear leader. And so we were able to get away with using Hyperdom. That seems to have changed in recent years with React emerging a defacto standard. At least according to what our clients demand (fun fact: 5 years ago they were insisting on Angular 1).

Over the years a strong community built up around React. There is plethora of solid complimentary projects that solve all sorts of problems. To be fair, that alone is a good reason to stick to React.

artemave

Mithril vs Hyperdom

Mithril is a "A modern client-side Javascript framework for building Single Page Applications". So are many other frameworks out there. So is my personal favorite - Hyperdom. What sets Mithril apart from the some other frameworks that I looked into is just how similar it is to Hyperdom in terms of development experience.

This is because they both operate under these two fundamental assumptions: "component instances are not recreated on each render" and "automatically redraw everything on some common events". In practice, that means that there is no reason for the framework to manage application state. State can be simply stored in plain javascript objects that have nothing to do with the framework. If you're familiar with React, imagine you could write state.foo = 'bar' (state being a regular javascript object) instead of this.setState({foo: 'bar'}) and bar will still show up in the DOM. Even if state.foo is referenced

artemave

const vdomToHtml = require('vdom-to-html')
const path = require('path')
const fs = require('fs')

module.exports = function (viewPath, options = {}) {
  let vdom

  let view = require(viewPath)
  if (typeof view == 'function') {
    view = view(options)

artemave

This title is so 2009 - I couldn't resist it. And even back then everybody already knew that all it takes is git push heroku master. And an occasional heroku run rails db:migrate. The latter was a bit manual, so eventually heroku introduced a release task.

So... What is there to write about?

The problem is that migrating database in the release task seems to leave a small opportunity for things to go wrong. Only a teensy one, but when you're in charge of deploying changes to the real production system, this might be enough to keep you uneasy.

Release task is designed to keep serving the previous deployment until the release command finished. On the surface this is good enough, but consider what happens from the time migration is finished (and the changes are committed) and the switcheroo to the new deployment. It's only a few seconds gap, but during that time new db schema powers the old code. Now what if there is more than one migration? Suddenly the gap is wider. It's also not uncommon to run data

artemave

  scope :latest_prices, lambda {
    joins('
          LEFT JOIN client_products filter
          ON filter.product_id = "client_products"."product_id"
          AND "client_products"."created_at" < filter.created_at')
      .where('filter.id IS NULL')
      .where('"client_products"."price_per_pack" > 0')
  }

  has_many :client_products, -> { merge Client.latest_prices }

artemave

I write javascript code. I use CLI for everything I can and Chrome debug tools for everything else. I write code in cli vim, under tmux session.

I normally have tmux sessions (one per project) so I can quickly switch between them without closing/opening new terminal windows, cd'ing, etc.

I also have some automation that allows me to run particular tests from within vim such that it runs in a separate (designated to tests) tmux window.

I really love my setup (even though, at this point, it's probably more out of habit than anything else) and I don't want anything else.

But. The other day I've been pairing with my mate Josh and he kept doing this one thing over and over again and it was such a basic thing, yet such powerful thing at the same time, that I could feel my perfect cli world shaking.

artemave

fswatch -0 -r . | xargs -0 -n 1 git ls-files | tee /dev/tty | xargs -n 1 ctags $(git ls-files)

artemave

var isBrowser = typeof window !== 'undefined';

var pushState, replaceState;

pushState = replaceState = function(state, title, url) {
  window.location.pathname = url;
  (window.__registeredEvents['onpopstate'] || []).forEach(cb => cb({}));
};

if (!isBrowser) {

artemave

const {Builder} = require('selenium-webdriver')

const driver = new Builder()
  .forBrowser('chrome')
  .setChromeOptions(
    new chrome.Options()
      .addArguments('user-data-dir=./.webdriver-chrome-user-data')
  )