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
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
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
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.Continue reading
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.