Chopping It Up With Henning

We’ve been having a bit of a break on the Reactive Podcast. The break was involuntary and just caused by normal life stuff. But we are working on getting back on track. Henning and I managed to put out a couple of episodes in which we chop it up about various things.

The topics vary from what we’re working on currently to other random stuff that shot through our heads while recording the podcast.

Check out 97: A Smoother-ish On-Boarding Process and 98: It’s Tiring Too, But It’s Good everywhere where you like to get your podcasts (unless its Spotify, we’re not on Spotify).

New Job, Who Dis?

Last month I started working at LogMeIn as a Staff Software Engineer. My team is working on the web version of GoToMeeting. We are migrating legacy code to a new, modern tech stack, while improving the product as well as working on features.

The new tech stack consists of TypeScript, React, Redux & redux-observable.

Coming from Angular, not being super-fond of the complexity of the framework, I was expecting to enter the lands of simplicity with React and Redux. Little did I know what was about to transpire right into my face!

Using React with the canoncial way of using Redux is so far off straight-forward, you get dizzy just thinking about it. I honestly felt reminded of Angular’s abstraction hell.

I always felt that the concept of Redux actually fits much better into a Reactive Programming paradigm. That’s why I built flow-state and never reached for the original Redux.

Reactive Programming allows you to granularly manage how, when and under which conditions the new state should reach the components. This means you can just set the framework to re-render whenever new state reaches, no other checks necessary.

But I digress, so, new job. So far so good. Lots to learn. I like the team and I do like working with React etc. We’ll see where this leads to.

Just One Link

Many designers and developers are taking the time, in various forms, to curate link-list-newsletters.

They contain 5-ish links in fat type with a low-contrast small-type link description below each link.

Over time I have subscribed to many of those and although I appreciate the work that people put into them, they have lost their value to me.

It’s their sameness. I also don’t know why the author has chosen those links. Did they actually read the content? Why do they think it is important?

I don’t even know which is which anymore. I just see a link list, maybe read a couple link titles and am back to whatever I was doing.

There is nothing that keeps me in the mail and it has become work to figure out which link could be interesting for me to check out.

This is what I would like to see instead:

Send an email with just one link. Write a paragraph about why you are sending out this link. Why does it excite/interest/enrage you?

Let me read your voice.

I’d be thrilled to receive your newsletter and read it every time.

96: Without Cheese You Are Nothing →

Henning and Raquel talk about, the Poison Dart Frog, moving cheese, when to maintain and when to develop features, a laptop theft ring and the fact that Slack is mostly PHP 😱

Another stellar conversation between my incredible co-hosts Raquel and Henning.

[DE] Revision 328: Web Components →

Inspiriert durch einen Artikel von Mikeal Rogers berichtet Kahlil von seiner Begeisterung für Web Components. Neben konkreten Webstandards wie Custom Elements, Shadow DOM, Template-Elementen und HTML Imports (RIP) und Tools im Stile von Polymer und dem CDN unpkg treibt uns auch die Frage nach dem Warum und den möglichen Vorteilen von Web Components um.

Während Kahlil in Web Components, kombiniert mit modernen Template-Libraries (lit-html, hyperHTML/viperHTML) bzw. Data Binding für Template Elemente (wie in Revision 319 besprochen) eine Alternative zu bzw. neue Basis für Frontend-JS-Frameworks sieht – zu nennen wären neben Polymer X-Tag und Stencil – ist Peter weniger euphorisch.

Die durch Web Components hergestellte Interoperabilität von Komponenten kann ein großes Plus sein (EA-Erfahrungsbericht bei der Polymer-Conf), doch wie oft sich das wirklich positiv zu Buche schlägt, bleibt dahingestellt. Peter setzt selbst Web Components ein (html-import, scoped-style), sieht sie jedoch nur als eine für sehr bestimmte Anwendungsfälle brauchbare HTML-Abstraktion, quasi das jQuery-Plugin 2.0.

Habe beim Working Draft Podcast ein wenig über Web Components herum gestammelt. Shoutout an Peter und Hans für’s aushalten!

Stimulus: A modest JavaScript framework for the HTML you already have →

Stimulus works by continuously monitoring the page, waiting for the magic data-controller attribute to appear. Like the class attribute, you can put more than one value inside it. But instead of applying or removing CSS class names, data-controller values connect and disconnect Stimulus controllers.

Think of it like this: in the same way that class is a bridge connecting HTML to CSS, data-controller is a bridge from HTML to JavaScript.

On top of this foundation, Stimulus adds the magic data-action attribute, which describes how events on the page should trigger controller methods, and the magic data-target attribute, which gives you a handle for finding elements in the controller’s scope.

Stimulus offers a very simple, elegant and concise way to upgrade your server-rendered site with JavaScript.

Once you see it, you think: “Wow, why didn’t anybody come up with this earlier?”.

To be fair: a big part of the elegance is to be able to use ES2015 classes.

And to be even fairer: other people had similar ideas way before Basecamp. Flight by Twitter for instance has a similar approach, but IMHO it was stuck in the past already a few years ago and it is not under active development anymore.

Stimulus is basically the better, modern version of Flight.

Fun fact: it turns out that Google is using almost identical patterns to Stimulus in most of their consumer facing web apps, since years:

Malte Ubl, head honcho of Google AMP on Twitter:

This is almost identical to Wiz which runs most of Google's consumer web apps.

— Malte Ubl (@cramforce) January 31, 2018

Malte also said they decided against open sourcing it years ago.

Which I would argue, is not a bad thing. Basecamp found a much nicer name, they made a really beautiful website for it and the writing in the Stimulus handbook is really great! I doubt Google would have done as good of a job at that.

This is a micro blog post. A blog post without a title that has 280 characters or less. All my blog posts and micro blog posts are distributed to my Micro.blog account.

Reactive 95: Career Pro Tip: Make Yourself Irrelevant →

Henning and Raquel talk about The Swamp Hackathon, working at Slack and a book called Punished By Reward.

I couldn’t make it on this episode because of my new flamingo farm, but I really enjoyed the discussion my two co-hosts were having there.

Reactive 94: There Are So Many Channels In The Slack Slack →

We’re back and talk about Raquel working at Slack, Henning and the hackathon, blockchain, Kahlil’s new Electron app and Bootstrap 4.

Our first episode this year!

electron-serve →

In a default setup, Electron serves the app’s index.html file directly from disk with the file:// protocol. This does not work well with JavaScript apps that want to use client-side routing.

The browser does not support history.pushState for files served from disk. This means every time you navigate to a different route with a client-side router it will try to resolve the path on disk which leads to a 404.

Thankfully earlier this year, @sindresorhus published electron-serve. This package registers a custom file protocol called app:// with a slightly tweaked behavior to file://:

It serves a file if it exists and serves index.html as a fallback if it doesn’t.

This makes it possible for client-side routers to process routes and for the app to respond to them without having to spin up a server in your Electron app.

One thing I had to do to get it to work though was to pass a fully resolved path to the require call for my entry file. I used path.resolve to do that. It did not work with a regular relative path like require('./renderer').

Keeping TypeScript Benefits In A JavaScript Project With Visual Studio Code

When I started Grit I was excited to find out that the Electron team is shipping types with Electron which expose the Electron API in your tooling. Since I am a fan of TypeScript I set up my dev environment to write my code in TypeScript as well.

After a few days of writing TS code to transpile it for my app, I started to get annoyed with the fact that I am transpiling code. And here is the reason:

In Electron you write code for a very capable browser. ES2015 is fully implemented minus ES Modules. That means the code I can write for the browser directly is already so close to ideal for me that it felt wrong to transpile from something else. So I converted my project back to JavaScript.

After years of dealing with Babel and TypeScript, writing ES2015+ code directly for the browser feels very freeing.

No source maps to decode, no types to manage.

Losing the types would be a little annoying though. For me personally, in this one-man-project, I enjoy the types especially because they enhance the tooling.

Thankfully there is VSCode!

VSCode has introduced something that is called jsconfig.json. It’s a configuration file that tells VSCode that the folder containing it is a JavaScript project.

From code.visualstudio.com:

jsconfig.json is a descendent of tsconfig.json, which is a configuration file for TypeScript. jsconfig.json is the tsconfig.json with the "allowJs" attribute set to true.

Adding that file tells VSCode to turn on the JavaScript Language Service which is based on the TypeScript Language Service. This gives you powerful Intellisense features throughout the project.

This means you get autocompletion and type errors for a normal JavaScript project. Types are being inferred by TypeScript type definition files as well as JSDoc comments.

Setting up jsconfig.json For Electron

In order to get it to work satisfyingly for my Electron setup, I had to configure a few things. jsconfig.json is just a tsconfig.json so the options are the same.

First of all, I excluded node_modules since I don’t want VSCode to type check all my dependencies.

"exclude": ["node_modules"]

In the compileroptions property, I set the checkJs property to true so that the JavaScript code is type checked as much as possible.

Because I (have to) use CommonJS Modules in Electron I had to set the module property to commonjs so that index.js files are resolved CommonJS-style.

And last but not least in order to be able to write ES2015+ code without warnings I set the target property to es2017.

You can have a look at my config file right here.

Adding A Type Definition For HyperHTMLElement

I had to create a type definitions file for HyperHTMLElement because the JavaScript Language Service didn’t like me having to use the default property on the required module. This is the code in question:

const HyperHTMLElement = require('hyperhtml-element').default;

I went to the trouble to actually add all the class properties in the definition which gives me the sweet sweet code completion feature in VSCode. If you need it you can pick it up from here.

This setup allows me to write modern JavaScript code directly for the browser as well as benefit from many TypeScript features. Love it.

Building Grit

Static Site CMS is now Grit. I wanted to give it a name because I want to keep writing about building this thing and Static Site CMS is a shitty name.

Grit will be a Markdown editor for managing blog posts for your static site. There is nothing to see yet, I am still working on the MVP.

I’ll be writing a series of posts about the process of building Grit. The titles of these blog posts will be prefixed with “Building Grit:“.

I am using Electron, Web Components, a bunch of packages by Sindre Sorhus and a Router called Navigo to build Grit. I am constantly learning new things and I am looking forward to sharing them here.

Why Grit?

It has two meanings.

1. dirt
2. determination despite difficulty

Namely the second meaning is very fitting since it takes real grit to keep a blog going. Using Grit is supposed to remove some of the friction that comes with blogging on a static site, which should help you having the grit to keep going.

But to be quite honest “dirt” is fitting as well since this software will be quite rough around the edges for a while lol.

Gritty Road

The road ahead for Grit is simple. I am in the process of building a simple MVP with an extremely limited feature set and we go from there.

Let me know if you’re interested in trying it out! ✌️

learnrx.io →

Finally some human-friendly docs about RxJS. Huge effort by Brian Troncone.

Switching To hyperHTML And HyperHTMLElement

When starting work on Static Site CMS I originally planned on using Custom Components and lit-html instead of a JavaScript framework.

In the process of setting up my development environment I was a little annoyed to realize that lit-html can only be used with ES Modules and not with CommonJS modules. Since Electron uses CommonJS that is a requirement for my current project.

I heard that hyperHTML basically does the same thing as lit-html so I went and checked it out.

I was very happy to discover that not only does hyperHTML do basically the same thing as lit-html, it also supports all module types and as a bonus there is a little ecosystem around it that enhances Custom Elements and even supports server side rendering. What?! Nice! See a chart that compares the two right here.

HyperHTMLElement is a Custom Element subclass that is exactly what I just had started to do with LitElement, only better. The author @WebReflection knows these emerging web standards very well and does an amazing job making them really usable and useful today.

In turn @WebReflection is not a fan of TypeScript so neither hyperHTML nor HyperHTMLElement have type definitions. Since I decided to use TypeScript in my app I created a simple type definition file for HyperHTMLElement. I didn’t add it to @types yet but you can grab it from my project right here.

All in all lit-html and hyperHTML are very similar in what they do. The biggest difference at the moment is that hyperHTML is more complete and feels more mature, not to mention the addition of HyperHTMLElement and server side rendering via ViperHTML.

Working Title: Static Site CMS

Product development has always been of huge interest to me. I love creating something with web technologies that solves a problem and iterating on it. That is basically what I do at work but I always wanted to have my own thing.

During the last year I have played around with a couple of ideas while trying out different JavaScript frameworks. Altogether I think I must have at least started working on 4 or 5 things. Among those I made two small barely usable products: TinyDraft and Kaf. They are very simple and incomplete but they do implement a very minimal use case quite OK.

I always end up hitting a wall when it comes to adding a backend with database, authentication and authorization. Typically I would use services for that. But since I really just get to work on my personal stuff on the road during my commute I can’t easily add any services. My connectivity is very limited during those train rides.

I also tried out using Hoodie which is great to work with locally but deploying a Hoodie backend wasn’t trivial to me and ultimately I only really want to think about the frontend side and have the backend just work and be there in local development as well as in production.

So these products are going nowhere.

I realized in order to build and iterate on anything during my very limited free time I have to remove as much friction as possible. The solution to that problem came to me just a couple weeks ago.

Recently I hooked up NetlifyCMS to my site. It uses Netlify’s auth service and GitHub to add posts to your site. If you set up automatic deployment via GitHub on Netlify that is a really great solution to adding posts to a static site through a nice UI.

But here I had the same problem. I write my stuff on the road and I can’t rely on being online. But I really liked some of the functionality that NetlifyCMS provided, namely the scaffolding of posts, easy Front Matter editing as well as the automatic Git commit functionality.

I thought to myself: “That’s cool, I wish I had that for the desktop.”

That’s the moment when it clicked! I could make this myself with Electron! I actually love working on Electron apps and I would be solving a problem for myself as well as removing my above-mentioned friction from app building. This type of Electron app can be developed without being online at all. Hooray!

I have started working on this over the holidays and I am developing it in the open, the code is on GitHub and I will be posting about my progress here.

For now the product really does not have a name. The working title is Static Site CMS.

In my next post I will be writing about the setup I am using to build it.

Template Instantiation

Happily stumbled upon this little video by @dassurma and @jaffathecake. Apparently there is a template instantiation proposal out there somewhere that would add lit-html / hyperHMTL - like functionality to the template element.

This would be huge if it made it into the platform. This would mean that Web Components would be complete because, as I outlined before, the only web standard missing for them to be useful out of the box is an API like lit-html that allows for their DOM to be rendered over and over again in an efficient way.

Here the (extremely short) video for your viewing pleasure:

ZeroFux - A Stateless Unidirectional Data Flow Implemented With Custom Events

Undirectional Data Flow, Flux, Redux, Whateverux is essentially this:

• something happens
• what happened is being described with an action object
• that action object is being dispatched through a central point, the dispatcher
• on the other side of that dispatcher actions are matched to reducers
• the reducers take the information of the actions and return state

This allows you to manage interactions in your UI in a stateless and synchronous manner.

As a developer, the only thing that really interests you are the actions and the reducers, all the rest is just implementation detail. Actions and reducers shape the app‘s state.

In the following I describe a really simple way how you can implement this type of state management with Custom Events.

Actions

First let’s define what an action is. An action is a JavaScript object that has one required property with the key „type“ and two optional ones with the keys „payload“ and „error“. Here an action defined as a TypeScript interface.

{
  type: string;
  payload?: any;
  error?: boolean;
}

I think we can agree that the JavaScript community mostly agrees on this definition pioneered by Redux, maybe minus the error property. I stole that from redux-observable.

Dispatcher

So, now that we have actions how do we dispatch them through the dispatcher and what is the dispatcher?

We want to use Custom Events. Those event get dispatched on a DOM element with the dispatchEvent method. That means our dispatcher is a DOM element. It is really not important which one but let’s just use the body element since that element is present on any web app.

const dispatcher = document.querySelector('body');

Great. Now that we have the dispatcher how do we dispatch an action? That’s where the Custom Events come in. We‘re using Custom Events because they allow us to add Custom event data (which we will, sneakily, call actions).

dispatcher.dispatchEvent(
  // The first argument of the Custom Event is 
  // the event name. The event name is the same
  // as the action type.
  // The second argument are options.
  new CustomEvent('SOME_ACTION', {
    // Here goes our custom data, the action object.
    detail: { 
      // Action type and event name are the same.
      type: 'SOME_ACTION', 
      // Here goes the optional data.
      payload: someData, 
      error: false,
    },
  })
)

So now that all these actions are being piped through one point in the DOM via Custom Events, we can match them to reducers.

In your component that expects some some state, take an array of action names that the component is interested in and set up event listeners. In the event listeners callback match a reducer with the same name per action to update the component state:

// Some example action names.
const ACTIONS = [
  'INCREMENT',
  'DECREMENT',
  'ADD_TEN',
];

...

// As a convention components need a setter and 
// a getter for the state property. 
// That allows you to call a render function or similar
// whenever state is set to a new value.
set state(s) {
  this._state = s;
  // Use lit-html or some other library that efficiently
  // can update DOM in the render function. 
  this.render();
}

get state() {
  return this._state;
}

// This is a method on some component.
setReducers() {
  ACTIONS.forEach(ACTION => {
    if (reducers[ACTION]) {
      // Again we are using the reference to the body
      // element as the dispatcher.
      dispatcher.addEventListener(ACTION, e => {
        // Reducers are kept in an object and matched
        // via action name.
        this.state = reducers[ACTION](e.detail, this.state);
      });
    } else {
      throw new Error(
        `Please add a reducer for the "${ACTION}" action.`
      );
    }
  });	
}

...

The ZeroFux Library

The code above is a little boilerplate-y so let’s make a simple library out of it. No Flux plus no Redux euquals ZeroFux:

export class ZeroFux {
  constructor(element) {
    if (element) {
      this.dispatcher = element;
    } else {
      this.dispatcher = document.querySelector('body');
    }
  }

  // The dipatch method takes an action argument
  // of the previously defined action type.
  dispatch(action) {
    this.dispatcher.dispatchEvent(
      new CustomEvent(action.type, {
        detail: action,
        // In case you set a custom dispatcher element
        // and want them to bubble.
        bubbles: true,
        // In case your custom dispatcher is in the
        // Shadow DOM and you want them to bubble between
        // the borders or Shadow DOM and regular DOM.
        compose: true,
      })
    )
  }

  // This method takes an array of action types
  // that can influence a component's state,
  // an object with reducers with the same names
  // as the action types and a reference
  // to the component on which we want to set
  // the state propery.
  setReducers(actionTypes, reducers, component) {
    actionTypes.forEach(actionType => {
      if (reducers[actionType]) {
        this.on(actionType, e => {
          const action = e.detail;
          component.state = reducers[actionType](component.state, action);
        });
      } else {
        throw new Error(
          `Please add a reducer for the "${actionType}" action.`
        );
      }
    });
  }
}

export const zeroFux = new ZeroFux();

🎉 tadaa!

It’s up on Github and npm right now if you want to try it.

You can see ZeroFux in action in this CodePen.

Side Effects

“Ah-haaa! How do we manage side effects with ZeroFux?”, you may ask. Well, there is actually a simple zero-fux way to deal with this.

Since these custom events are all streaming through one point in the DOM, the point that we can access via zeroFux.dispatcher, we can just listen to these events separately and fire effects on certain actions.

These side effects have to fire an action themselves when they are done with whatever they were doing. That’s how we introduce data coming from theses side effects synchronously back into the the data flow.

This is how your SideEffects class could look:

import { zeroFux } from 'zero-fux';

export class SideEffects {
  run() {
    const on = zeroFux.dispatcher.addEventListener;
    on('SOME_ACTION', () => { 
      someApi.doSomethingAsync()
        .then(data => zeroFux.dispatch({
          type: 'SOME_RESPONSE_ACTION',
          payload: data,
        }));
    });
    
    ...
  }
}

See it in action in the CodePen.

Conclusion

So there it is, a bare bones, straight forward unidirectional data flow implementation using custom events.

It uses the same principle I have also used in oddstream, a unidirectional data flow library implemented with RxJS: matching a “stream of actions” to reducers. This just has zero dependencies and is practically no code.

In Node this could be implemented using EventEmitter.

I think this solution for a unidirectional data flow could be used in apps of any size because ultimately all you have to manage and think about is actions and reducers, same as in any other unidirectional data flow solutions.

Use Web Components To Build JavaScript Apps

Web Components are generally described as “custom, reusable, encapsulated HTML tags” that encapsulate some DOM, some styling and behavior implemented with JavaScript.

I don’t understand why this use case is pushed so extensively when Web Components offer a perfectly good component abstraction for building complete JavaScript web apps.

I’m not so much interested in Web Components for individual new custom tags à la <google-maps></google-maps> or something. I’m interested in using Web Components for building full fledged JavaScript apps with a component-tree architecture, unidirectional data flow and efficient DOM rendering. And I think they are perfect for it!

And they are perfect for it now.

Web Components are typically described as the combination of the following four web standards:

• Custom Components
• Shadow DOM
• HTML Template
• HTML Imports

First of all let’s forget about HTML Imports. Vendors don’t agree on them, they block rendering and honestly they feel super clunky to me.

We have ES Modules. Web Components don’t work without JavaScript anyway so let’s import them via ES Modules or bundle them up and serve them from a server or CDN.

Mikeal Rogers actually already built a solution for himself that allows him to write Web Components in JavaScript, publish them to npm and automatically serve them automatically on a CDN via unpkg.

That’s totally the way to go. But he also talks about isolated components as far as I can see.

Like I said I think they are the perfect building blocks for building JavaScript web apps how we build them today with React, Vue, Angular and so on.

My opinionated list of things that of what Web Components consist looks like this.

• Custom Components (with Shadow DOM and HTML Template behind the scenes)
• Tagged Template Literals

Custom Components are the heart. They are the building blocks for web applications. Shadow DOM should always be used for encapsulation and HTML Template should be used to efficiently build the DOM for the component.

The developer should really just interact with a Custom Component class without having to think about Shadow DOM and the HTML Template.

What Custom Components are missing is an efficient way to automatically update the DOM on component state changes.

Basically something like React‘s vDOM.

But adding a vDOM library doesn’t feel right because one of the big wins of Web Components is that you don’t have to manage a separate DOM next to the one in the browser. So what to do?

While watching the talks of the 2017 Polymer Summit I stumbled on this talk about lit-html and I was impressed by it right away.

It’s a genius little 2k-sized library that goes with Web Components beautifully. It allows you to build the DOM for your Custom Component with a tagged template literal.

Tagged Template Literals are a JavaScript standard. They are Template Literals that are marked by a function name. The string contained in the Template Literal is processed by that function before it’s returned. In the case of lit-html it looks like this:

const markup = html`
  <div>
    ${state.someValue}
  </div>
`;

lit-html comes with the html-function to use with Template Literals and with a render function that efficiently renders updated state to the DOM.

Under the hood lit-html uses HTML Template to efficiently clone the markup. The html function returns something called a TemplateResult which gets passed to the render function along with the DOM element to which it should be rendered. lit-html remembers the dynamic parts of the template and makes sure these get updated when needed. The static parts of the template are always just rendered once.

According to this talk from the Google Web Summit lit-html fairs pretty well performance-wise.

I think it is the perfect library for managing DOM updates of Custom Components because it it just uses Web Standards to do its job and refrains from maintaining a second DOM tree in order to be fast.

With a little luck some sort of efficient DOM updating will also land in the browser as a standard but for now this is great!

So in conclusion: the perfect web app building block for me is just a Custom Component that uses a base class that hides away creating the Shadow DOM and the usage of lit-html.

I made such a subclass for my little Café search app, it’s called LitElement and it is str8 🔥.

// A super chill custom element subclass with
// some nifty default behavior.
export class LitElement extends HTMLElement {
  constructor() {
    super();
    // Initialize the state variable.
    this.state = {};
    // Create the Shadow DOM for this element.
    this.attachShadow({ mode: 'open' });
    // Just a convenient alias for addEventListener
    this.on = this.addEventListener;
  }
  
  // The state getter.
  get state() {
    return this._state;
  }
  
  // The state setter calls the 
  // invalidate function, which invalidates the
  // state and calls render.
  set state(s) {
    this._state = s;
    this.invalidate();
  }

  // This function makes sure that 
  // the lit-html render function is called 
  // when invalidate() is called. 
  // But it makes sure it is always called 
  // on next tick so that render calls are 
  // batched.
  invalidate() {
    if (!this.needsRender) {
      this.needsRender = true;
      Promise.resolve().then(() => {
        this.needsRender = false;
        // this.render is the render function of 
        // the Custom Component that subclasses this
        // class and it returns a TemplateResult created
        // with the lit-html html-function and a Tagged 
        // Template Literal. 
        // The location to which the DOM is rendered to is
        // always the shadow root of the component.
        render(this.render(this.state), this.shadowRoot);
      });
    }
}

❤️ the platform.

Web Components And The CMD-R Development Workflow

A couple of months ago I stumbled across Mikeal Rogers’ article I’ve seen the future, it’s full of HTML. in which he lays out his reasons why he started to dive into Web Components for the web apps he is working on right now and hinted to the workflow he uses.

His enthusiasm for Web Components is infectious and because I have a lot of respect for Mikeal and his work, his article was a strong signal for me personally that Web Components might be something to take a closer look at.

I have ignored them so far because the little I knew about them seemed a little gross to me: HTML imports? HTML, CSS and JavaScript in one file? Ewww. Who wants to write code like that?

Polymer didn’t help a lot either: all I heard was Polyfills and Bower and WTF is Shady DOM?

And oh yeah everybody kept screaming “OH PRAISETH OUR NEW LORD AND SAVIOR HIS HOLINESS THE REACT”.

So I kept ignoring it.

But then Mikeal came along and showed how to write Web Components purely with JavaScript. He said the only tooling he uses is a little Browserify in order to package the component so he can distribute it via npm and automatically serve it via a CDN.

I was like: “No tooling? Hmmm… that sounds pretty sweet.”

A few weeks ago I took some time to write a tiny application just with Web Components. I used no tooling, no compilation no polyfills, no nothing. Just Chrome, ES 2015+, ES Modules, <template>, Custom Elements and an “actions up data down” data flow with Custom Events.

I used the CMD-R (CTRL-R on Windows) web development workflow as Alex Russel calls it.

Now that’s a developer experience 😉!

It was surprising to me how freeing it was to be able to use modern syntax, modules and a component architecture in the browser without any tooling. Not to mention the excellent debuggability since you are feeding the browser what you write directly.

The browser has become the only tool and even the only “framework” we need to write JavaScript apps.

Just write your app using Chrome and then make a bundle with dynamically loaded polyfills to make it work everywhere.

As it stands currently that latest versions of Google Chrome, Safari and Opera support these technologies natively, Firefox and Edge are lagging behind but working on it.

Netflix functions without client-side React, and it’s a good thing →

Jake Archibald on Netflix removing React from their landing page:

Netflix has shown you could start with React on the server, then activate the client side parts if you need them, when you need them, and where you need them.

I hope this starts to become state of the art.

Working Draft Podcast, Revision 314: DDD, CQRS und WTF →

In this episode of the German podcast Working Draft Golo Roden does a great job explaining what DDD (Domain-Driven Design), CQRS (Command Query Responsibility Segregation) and Event Sourcing is and how his new project wolkenkit can help developers applying those principles and patterns.

Why I wrote Just. by Angus Croll →

Just is a collection of dependency-free modules for common operations on Arrays, Collections, Strings, Objects and Functions started by @angustweets. “Do we really need something like that when we have Lodash?” you might ask.

Angus does a great job explaining why he started Just:

Just is designed for those who value easy to follow, debuggable utilities over version lotto and yak-shaving down the module tree. There’s nothing fancy or particularly clever here. You won’t find elaborate routines that optimize for trillion element arrays; just short, cohesive, readable code––the sort of helper functions we all inline in our projects every day because edge case optimizations that we’ll never need aren’t worth the overhead and the uncertainty of a sprawling dependency chain.

I Finally Understood Functions As A Service

Since I heard it for the first time, I was struggling to understand what “Functions As A Service” like AWS Lambda really is. I heard people explaining it on podcasts and read what it said on the AWS Lambda landing page but it just didn’t click.

Last week me and Henning recorded the lastest episode of our podcast REACTIVE. On that episode Henning talks about how he uses AWS Lambda and an AWS database to build an API for their app at work. This made me finally understand what this is all about.

They built the API by writing some code that parses request parameters, retrieves some data from the database and then sends that data back as JSON in the JSON API format. That code is the function that is being provided “as a service”.

That is it.

The HTTP layer, security and scalability is all provided by AWS services. Functions As A Service also means that you only pay for computing time when the function is used. When there is no requests to the API then you don’t pay.

This is an incredibly fast and efficient way to build an API that is production ready in no time.

On the podcast we also talked about how more and more of these “solved problems” like security and scalability will be packed up into some service and how the usage of them will certainly be very widespread in the not so distant future.

@codepo8 said it best on Twitter yesterday:

Prediction: in five years most of what we call "coding" now will be done by machines. And they'll be much better at it.

— Chris Heilmann (@codepo8) October 23, 2017

How Matt Mullenweg Single-Handedly Made Facebook Relicense React to MIT

OK, I have no proof that this is actually true, but it is a fun thought experiment / conspiracy theory. Here me out.

Facebook just announced that they are relicensing a few of their open source projects to the MIT license.

I am pretty sure this change will be extremely well received by everybody using React.

It will also ensure that the majority of React users will switch to React 16 (the first version under the MIT license) because their BSD + patents license is widely mistrusted and / or disliked.

I for one like to think that this change was triggered by the shots that Matt Mullenweg fired in his post “On WordPress and React” a few days ago. I re-read his post a couple of times because I found some of the statements he made very interesting. At first glance the post reads like “OK WordPress just ditched React no big dizzle” but after re-reading it I realized that Matt just deprived React of a quantum leap in growth. Wow. Let’s go through the interesting points:

First 💥:

Big companies like to bury unpleasant news on Fridays

This statement is in context of Facebook’s post about sticking with the BSD + patents license after the Apache Foundation put their license on the black list.

Right in the beginning of his article he accuses Facebook of shady behavior.

Second 💥:

I’m not judging Facebook or saying they’re wrong, it’s not my place.

This is hilarious. Translation: “I am judging Facebook and I am saying they are wrong.”

Third 💥:

We had a many-thousand word announcement talking about how great React is and how we’re officially adopting it for WordPress, and encouraging plugins to do the same. I’ve been sitting on that post, hoping that the patent issue would be resolved in a way we were comfortable passing down to our users.

Now for the squeeze.

Translation: “We were going to officially adopt React as the WordPress JavaScript thing and make a big fuss about it which would have been massive promo for you for free and would most likely have pushed React adoption into jQuery-like spheres. But now we’re not doing that, lol.”

Fourth 💥:

Squeeze even harder:

Core WordPress updates go out to over a quarter of all websites, having them all inherit the patents clause isn’t something I’m comfortable with.

Translation: “For realz Facebook?!?!? You don’t want your Framework to be used by over 25% of all websites on the internet with a snap of a finger!?!? Maybe y’allz want to think about that a little bit?”

Fifth 💥:

Now for the kill:

But we have a lot of problems to tackle, and convincing the world that Facebook’s patent clause is fine isn’t ours to take on. It’s their fight.

Translation: “We don’t need all your drama. You’re on your own.”

We’ll look for something with most of the benefits of React, but without the baggage of a patents clause that’s confusing and threatening to many people.

Translation: “React is not indispensable and can easily be switched out with something similar, thank you.”

So good. He whacked them over the head in the nicest way possible.

It makes total sense to me that Matt’s post would make them rethink their licensing strategy. The Apache Foundation reject did not really mean a big impediment to their growth but loosing WordPress would deprive them of more massive adoption and may even mean a decline in React adoption going forward because Matt and WordPress as a project are just incredibly influential in the web development community.

Potentially being the JavaScript thing for WordPress and WordPress plugins and the growth React would gain by that must outweigh the litigation costs they would save by sticking with BSD + patents.

Matt has already reacted to Facebook’s anouncement:

I am surprised and excited to see the news that Facebook is going to drop the patent clause that I wrote about last week. They’ve announced that with React 16 the license will just be regular MIT with no patent addition. I applaud Facebook for making this move, and I hope that patent clause use is re-examined across all their open source projects.

Matt is pleased about the change.

But Facebook has lost the chance to be the designated WordPress JavaScript framework:

Particularly with Gutenberg there may be an approach that allows developers to write Gutenberg blocks (Gutenblocks) in the library of their choice including Preact, Polymer, or Vue, and now React could be an officially-supported option as well.

Looks like the WordPress team found out about this new-fangled compiler that Jason Miller of Preact-fame is working on which compiles, Web Components, VueJS components and Preact components into highly optimized Preact components. That’s awesome.

Interestingly Matt is not mentioning if they will still switch away from React for Calypso. Somebody opened an issue asking about it but nobody has responded yet.

Meanwhile React 16 has been released and the license is indeed MIT.

All New

My blog used to be a Medium publication with a linked domain but I ditched Medium. I was disappointed with the design directions they are taking. I was a big fan of Medium’s design before the recent change to the new serif wordmark. It feels disjointed to me now and it is apparent that they are pushing their paid services and are working hard to make an actual business out of Medium. That’s all good and fine but I don’t like the changes and that made me realize I need to have more control over my blog again.

Also I wanted to consolidate kahlil.info and kahlillechelt.com. So here we are. New blog same old me.

For now I am leaving my old blog posts over there on Medium. I will port them over eventually. Maybe. I will be cross posting my blog posts from here over at Medium as well. The readership you get over there via their network is really nice.

Design

The initial inspiration for the design was a quick study that @magalhini posted to Twitter a while ago. I played around with it but wanted a different font pairing. After some googling I found Typewolf Google Fonts and Great Simple, two websites that suggest Google font pairings. I ended up choosing Roboto Mono as a main font and Rubik for my wordmark.

I found the pairing here and after I saw it I kept coming back to it. So I went with it. I really like using a monospace font for the body text.

I am happy with it. Keeping it simple.

It’s A Static Site

As a web developer I have to use a static site generator of course. Which one you ask?

Hugo!

Hugo is written in Go and comes as a binary. It’s wicked fast and can easily deal with huge amounts of posts.

It has been around for a while now and is really flexible. It works very similarly to other static site generators like Jekyll or Metalsmith.

Hosting

For hosting I went with Netlify, I’ve been really impressed with their user experience for hosting static pages. If your site is on Github it is incredibly easy to deploy it to Netlify:

• link your Github respository
• tell them the command that builds your site
• tell them the name of the folder that the built site end up in

Done!

The site gets redeployed every time you push to master (this feature can be turned off) and if I push a branch to the site’s Github repo Netlify will attempt to deploy a preview automatically. It’s truly a joy to use.

If you are interested in the code for this site you can find it on Github.