TypeScript Types for Productivity

There’s no shortage of articles on the web weighing the assumed overhead involved in using TypeScript and incorporating types in your development workflows. It’s one of the metrics in what’s often referred to as the “TypeScript Tax”. The more I’ve been using TypeScript, however, I’ve found that there are common cases where incorporating types can improve my productivity.

Continue reading

Font Loading Performance for Single-Page Applications

If you’ve ever worked in a project architected as a single-page application, the following pattern may look familiar:

<!doctype html>
<title>My Application</title>
<div id="app"></div>
<script src="https://unpkg.com/react@16/umd/react.production.min.js"></script>
<script src="https://unpkg.com/react-dom@16/umd/react-dom.production.min.js"></script>
<script>
ReactDOM.render(
    React.createElement( 'span', null, 'Hello World' ),
    document.getElementById( 'app' )
);
</script>

Note the empty div element. While this example uses React, most any of the common JavaScript frameworks will follow this convention of mounting an application into some root container element. It’s not until the application code has loaded and computed the rendered result that anything is shown on the page.

If an application uses custom fonts, there’s an interesting side-effect of this loading procedure which we might not anticipate. Presumably in an effort to optimize network requests of unused assets, Chrome will not load a font file if there is not any text in the page which uses that font. Even if we declare the fonts used in a CSS @font-face rule, a font file will not be requested until after the initial rendering of the application. This is due to the fact that, until that point, there’s effectively no text shown anywhere in the page.

This has the unfortunate effect of introducing what is known as a “flash of unstyled text”, where the text in an application may be shown using a fallback font until the font has finished loading.

Ideally, if we know that our application will render text, we would want the font to be loaded as early in the page lifecycle as possible.

Continue reading

Back to Basics: A Possible Future Without JavaScript Build Tools

As someone who spends the majority of their time working in a modern front-end JavaScript tech stack, it may be surprising to hear that I’m often disillusioned by the rate of churn in our development workflows. But for me, it’s not the near-daily introduction of new libraries. In fact, I find this perpetual inventiveness to be inspiring. No; instead, it’s that we push ourselves further and further away from anything resembling a shared baseline of knowledge. For each new paradigm we layer into our stack, we too easily overlook its broader human impact as a barrier to entry, a prerequisite of knowledge unique to our project.

Continue reading

TypeScript Tooling for Your JavaScript Projects

When evaluating TypeScript, it’s usually considered as an investment into the language itself. For this reason, and despite all its merits, some developers might be inclined to dismiss it altogether out of a lack of interest in learning a new syntax, or a worry to impose that requirement onto others as part of your onboarding workflow.

But even if you’re determined to use plain-ol’ JavaScript in your projects, it’s worth considering the tooling that TypeScript offers. I suspect that many developers would be surprised to find they can achieve the benefits of type safety without leaving the comfort of JavaScript.

There are many reasons why one should or shouldn’t adopt TypeScript into their workflows. This blog post isn’t concerned with convincing you one way or the other. Instead, I’ll focus on demonstrating how you can benefit from TypeScript tooling even if you choose not to adopt the language itself.

Continue reading

Publishing Small npm Libraries with Rollup

Over the past few months, I’ve published a number of Node modules aimed at implementing a very minimal and focused set of features. In doing so, I’ve made a point to take special care in keeping the size of the code as small as possible; ideally a kilobyte or less in size when minified. Not only does this force me to think of the simplest solution, it importantly reduces the burden on applications in using it, especially when it’s bundled to be served on the web. There are a number of techniques I’ve employed toward this goal, and for the purpose of this post I’ll focus on the module bundler: Rollup.

Continue reading