Programming Thoughts

Lucy is a new DSL (domain-specific language) for describing Finite State Machines and Statecharts. It compiles to JavaScript using XState.

Painting and art can be a good second hobby for programmers who have had too many side projects.

In 2013 the Extensible Web Manifesto was formed and it has influenced how web APIs are developed ever since. For those who aren't familiar, the manifesto roughly follows this model:

Hat-tip (🎩 💵) to Caleb Porzio for the name, as I asked what to call this idea on Twitter.

When discussing new features for the web we often distinguish between low-level and high-level features. I'll leave defining what these are for another day. However, we usually think of high-level APIs are being the (hopeful) end-game of years (often decades) long work where low-level primitives are discovered and implemented until we have everything we need to build a pristine high-level API that makes everything super easy.

Using the Alexa Skills SDK you have the ability to save state for a particular session. A session is one continuous use of the skill by a user. If you're familiar with web development then you've probably used sessions before. Here sessions are more about saving state information in a back-and-forth conversation with a user.

Recent criticisms of web components have highlighted the limitations of HTML as it is today and raised the question of whether the will exists to fix them. A replacement might be a more likely candidate.

I recently received an invite to GitHub's new Package Registry and have been itching for an opportunity to try it out. For those unaware, GitHub Package Registry is a new feature that allows publishing packages for many programming environments including  RubyGems, Maven, and npm. I was most interested in npm.

Front-end view libraries typically set out to solve two important problems for developers:

Robot is a new library for building finite state machines in only 1.3kB. Here's an obligatory toggle machine example:

APIs for component based libraries have long taken a declarative approach. The developer provides a set of options on how to configure a new component and the library produces the component. In Vue it looks like so:

Warning, this post assumes you are familiar with Svelte and the history of the project. If you're not, you're better off checking out the home page than reading this.

The Web App Manifest is the format that defines metadata about an application, so that a user can add it to their homescreen.

So, in a side project I'm working on I wanted to make it so that the navbar would disappear when not in use. So I made it so that it has opacity: 0 by default. If you click in the middle of the viewport it becomes opacity: 1. After a few seconds it hides itself again.

A while ago I tweeted a thread about how a small JavaScript snippet, one that can fit in a single tweet in fact, can be used to allow defining custom elements purely in HTML. This post will expand on the idea, show how the snippet works, and argue for why you might want to actually use this.

Every time you post to your Gatsby blog your JavaScript grows by 100 bytes.

Too often when I get excited about some new browser API and I discuss it with colleagues I'm met with the dreaded question we've all heard: "But what's the browser support?"

One of the things that makes front-end development difficult is the duplication of our data structures. The mainstream thing to do today is to put your data into JavaScript structures (Objects and Arrays) and then project those back onto the DOM.

The :defined CSS selector allows you to target custom elements. See the MDN docs for full usage. Let's compare a couple of ways you could target custom elements:

I recently saw on Twitter about how Golang now supports WebAssembly. I've become a bit of a fan of Go so I was pretty excitted to try it out for myself. For me printing Hello world to the console isn't enough so I thought I'd try building a web component instead. Luckily the interop story with JavaScript is pretty solid (with caveats, explained later) so it wasn't much work at all.

system-npm is an amazing plugin for SystemJS that enables you to load your NPM dependencies with zero configuration.  Just load system-npm and then load your project; require your NPM dependencies just as if you were in Node.

tldr; you can't. However what you can do is use an old computer to sync between Google Drive and your other cloud drives, providing (close to) the same effect. I set up a Raspberry Pi, which was previously setting in my basement looking pretty and acting as a Cloud Print server but nothing else, as a WebDAV server which has worked out rather nicely. The one downside is that Chromebooks only support Google Drive as a cloud drive service.

This will be short and sweet. When working on a large JavaScript application (or a small one, for that matter) you're going to have an entry point where you set up your world and get everything started. It probably looks something like this:

I've been developing on a Chromebook for quite a while so I feel I have a pretty good grasp on the strengths and weaknesses as they exist today. The tldr; is that, yes, you can develop on Chromebook and depending on what you consider to be "developing on a Chromebook" the experience can either be on-par with other computers or a tad... funky.

I don't use Windows as my main OS any more, but still do use it regularly enough to test out libraries I work on. One thing I regularly find frustrating is trying to remove a large folder. Using Explorer always seems to be slow, and I'd prefer to use the command-line anyways. On a Unix machine a simple rm -rf folder/ does the trick.

Recently I was working on a template and ran into issues trying to make it responsive purely using CSS media queries. The problem is that the mark-up of the mobile view and that of the desktop were just too different. In fact, the functionality of the two views were a bit different as well.

With StealJS you can easily set up an open-source library that fits with the way you like to organize your code. A common directory structure might look like this:

Builds as part of development workflow hinder your ability to write small, well tested, modules. When you use need to always build you tend to do all of your development within the full application. In order to test out a widget you are currently working on you need to drill down to where that widget exists, test out your changes, and repeat. This makes for a poor feedback loop. There are a variety of tools that have been created to workaround this problem that builds create; hot module swapping is one, stuff like React Storybook are another.

If you're like me and are excited about getting started using web components today, you might find yourself struggling coming up with practical uses that aren't the typical carousel, calendar, or accordion widgets that we've all written a hundred times in plain JavaScript.

A couple of days ago on the WHATWG Blog there was a post about a new value being added to the script tag: type=module. You can use it like this:

tdlr; check out leni, a low-level tool for communicating with web workers.

JavaScript allows you to define functions two different ways. We call the two types of functions, Function Declarations and Function Expressions.

JavaScript. The combination of dynamic typing, liberal use of state mutation, closures, and asynchronousity can lead to bugs that are frightening to try and fix. I'm by no means a debugging Jedi, but over the years I have accumulated a number of techniques that help me find the source of even the nastiest bugs eventually.

Many articles and discussions on Twitter have popped up in the last year or so debating when to use the new let and const bindings. Some will say you should only use const for things like string constants, while others take the opposite approach and say to always use const, unless you specifically plan on changing the value later.

I've finally come around to liking HTML-based templates. I've been a hold-out for a long time but I'm finding it harder and harder to resist the tide and I'm officially calling it today; HTML templates have won.

One of my ongoing curiosities is with how to design books for the web. Although there are many good books available on the web, I haven’t encountered one that is more than just the book contents with some <p> tags intermingled. The web has many unique advantages that makes it ideal for reading, but for whatever reason it hasn’t translated to long-form text (anything longer than a single article) very successfully.

Steal added hot module swapping (aka live reload, aka hot module replacement) about 6 months ago, but how it works isn't obvious, so I thought I'd write about it. You can read more about the feature and how to use it here.  This article is more technical and explains what happens under the hood. Don't worry, there's nothing overly complex here and it's rather easy to understand once you understand dependency graphs.

While working on done-ssr I wanted to make a simple API where a Stream is created for each request and piped into the response. The API should be as simple as:

Motivation

Today, modularity on the web is completely broken. The web, in fact, doesn't support modules at all. Since modularity is such an important part of building large applications we have various work-arounds for having modules on the web; module loaders and module bundlers being the big two.

Recently came across a blog post about a JavaScript function to convert state names to abbreviations (or vice versa) and realized that it's an excellent topic to present the power that can be had from functional programming in JavaScript.

Update: To do this demo you first need to enable experimental web platform features in chrome://flags.

tdlr; check out flora, a templating engine that allows you to stream HTML.

In the newly released version of done-autorender you now have access to your application's View Model globally.

In modern web applications we build focused components that are combined together to become a fully functioning app. We use modules to organize our components into smaller pieces. This is fairly universal no matter what framework you use (or if you don't use a framework at all).

I learn best by doing, so in an effort to learn more about can.Component I've been creating common types of components using the new framework. An accordion is one such example and I wanted to write about my experience creating the component. Note that this article doesn't constitute a best practice, I've only been using can.Component for a few weeks now. Nor is the goal here for the least amount of code (My first couple of iterations used less code actually), rather I wanted to write the component as DRY as possible.

I've been thinking a lot about web worker rendering lately. If you haven't heard of the term, worker rendering refers to using a Web Worker to calculate a page's UI, leaving the main thread (what I usually refer to simply as the window) only for patching changes and handling events.