You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
👉 Insert project badges separated by a space (remove this comment)
Describe briefly the pupose of the project in one sentence.
👉 If for some reason you need a deeper explanation on what the project covers we suggest an unordered list starting with a strong preceding motivation like React's README (https://github.com/facebook/react/blob/master/README.md) (remove this comment)
Draft explaining how releases work now and how could work in the future in KITT
KITT Release Process Draft
This draft will explain how hypothetically the release process of a new version of kitt would work if it's implemented.
PR creation process and initial setup
When an engineer, as part of the design system team or not, makes a change in the code base a new PR gets created. Commit are done following Karma's Git Commit message standard, which is how's currently managed in the repository and in all common frontend libraries from Typeform.
This is prefixing commit messages, fix for patch releases, feat for minor releases and BREAKING CHANGE footers for major releases. Along with these we have chore, test, docs and refactor which don't trigger a new version but get attached to the next released.
[DRAFT] Faster boot up times for static sites with Rollup
Faster boot up times for static sites with Rollup
Bundlers are a fundamental part of any web project nowadays. They allow us to encapsulate, share and organize our codebases better and give us access to vast collection of packages ecosystem to consume from. But did you ever wonder how the output of a bundler looks like and how it impacts your scripts runtime?
The footprint of bundlers
As modules weren't a thing on the web, tools like browserify or webpack needed to create a way for CommonJS modules to run on browsers.
The general approach was to add an overhead on top of the input code. This overhead consists in an array wrapping all the modules (local and from the npm registry) in your project and a iife (immediately invoked function expression) that kicks off the script.
Font loading strategy for single page applications
Web fonts bring a sense of identity to our projects and have become a crucial asset of product design nowadays, but as for static sites they can delay content display time severely, specially for slow connections.
With no effective font loading strategy, users will experiment what's call FOIT (Flash of Invisible Text) as the font files are downloading.
Instead it's preferable to go for FOUT (Flash of Unstyled Text), users will see content sooner with a font from the system and switch to the web font later.
A while ago I wrote about how to properly [load a web font in static sites][1] with a recipe which included a deferred font bundle, font observation to switch when fonts are usable, and a combination of stylesheet injection with web storage for future visits.