If you’ve ever worked in a project architected as a single-page application, the following pattern may look familiar:
React.createElement( 'span', null, 'Hello World' ),
document.getElementById( 'app' )
Note the empty
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.
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.
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.
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.
Regimen is a side-project I’ve been building off-and-on for the past few months. It’s a web app that I’d originally created for myself out of frustration for the lack of options in helping me plan my workouts. Specifically, most weightlifting routines offer some form of downloadable Excel spreadsheet, but these are cumbersome to work with when at the gym. I found myself either fumbling with the Google Sheets app on my phone, or printing a paper copy of the spreadsheet – neither was a great solution.