[
  {
    "path": "LICENSE",
    "content": "MIT License\n\nCopyright (c) 2021 André de Sousa\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in all\ncopies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.\n"
  },
  {
    "path": "README.md",
    "content": "# TypeScript Best Practices\n\nThis is a guideline of best practices that we can apply to our TypeScript project.\nThese tips are based on TypeScript documentation, books, articles and professional experience.\nMost of these recommendations also apply to JavaScript.\n\n## Table of Contents\n\n1. [Follow conventions](#follow-conventions)\n2. [Testing](#testing)\n3. [Strict configuration](#strict-configuration)\n4. [Avoid any. Type everything](#avoid-any-type-everything)\n5. [Strings should be safe](#strings-should-be-safe)\n6. [Call things by their name](#call-things-by-their-name)\n7. [Use utility types](#use-utility-types)\n8. [Use const and let](#use-const-and-let)\n9. [Use === instead of ==](#use--instead-of-)\n10. [Use shortcut notation sparingly](#use-shortcut-notation-sparingly)\n11. [Avoid globals](#avoid-globals)\n12. [Avoid mixing with other technologies](#avoid-mixing-with-other-technologies)\n13. [Avoid heavy nesting](#avoid-heavy-nesting)\n14. [Avoid long functions](#avoid-long-functions)\n15. [Reduce function parameters](#reduce-function-parameters)\n16. [Do not use flags as function parameters](#do-not-use-flags-as-function-parameters)\n17. [Comment as much as needed but not more](#comment-as-much-as-needed-but-not-more)\n18. [Use the fastest way to loop arrays](#use-the-fastest-way-to-loop-arrays])\n19. [Prefer array methods](#prefer-array-methods)\n20. [Do not trust any data](#do-not-trust-any-data)\n21. [Do not use short-hand](#do-not-use-short-hand)\n22. [Use parameter defaults](#use-parameter-defaults)\n23. [Use spread and destructuring](#use-spread-and-destructuring)\n24. [Use template literals](#use-template-literals)\n25. [End the switches with defaults](#end-the-switches-with-defaults)\n26. [Use the prefix \"is\" and \"has\" for Booleans](#use-the-prefix-is-and-has-for-booleans)\n27. [Declarations on top](#declarations-on-top)\n28. [Initialize variables](#initialize-variables)\n29. [Use iterators and generators](#use-iterators-and-generators)\n30. [Prefer pure functions](#prefer-pure-functions)\n31. [Prefer immutability](#prefer-immutability)\n32. [Avoid side effects](#avoid-side-effects)\n33. [Avoid magic numbers](#avoid-magic-numbers)\n34. [Avoid conditionals](#avoid-conditionals)\n35. [Handle JavaScript errors](#handle-javascript-errors)\n36. [Prefer promises over callbacks](#prefer-promises-over-callbacks)\n37. [Do not use weird JavaScript features](#do-not-use-weird-javascript-features)\n38. [Do not yield to web browser whims](#do-not-yield-to-web-browser-whims)\n39. [Place scripts at the bottom of the page](#place-scripts-at-the-bottom-of-the-page)\n40. [Keep DOM access to a minimum](#keep-dom-access-to-a-minimum)\n41. [Allow configuration and translation](#allow-configuration-and-translation)\n42. [Progressive Enhancement](#progressive-enhancement)\n43. [Raw JavaScript is faster](#raw-javascript-is-faster)\n44. [Organize and remove unused imports](#organize-and-remove-unused-imports)\n45. [Modularization](#modularization)\n46. [Lazy-Loading](#lazy-Loading)\n47. [Compress the files](#compress-the-files)\n48. [Minify the code](#minify-the-code)\n49. [Use Google LightHouse](#use-google-lighthouse)\n50. [Use Web Workers](#use-web-workers)\n\n## Follow conventions\n\nCode conventions are base rules that allow the creation of a uniform code base across an organization.\nFollowing them does not only increase the uniformity and therefore the quality of the code.\n[Airbnb JavaScript Style Guide](https://github.com/airbnb/javascript) is very popular and recommended. We can complete them with rules just for TypeScript.\nTo make it mandatory, we need a linter, formatter and strong code review. The code conventions must be dynamic and adaptable for each team and project.\nIt is up to each team to define its convention.\n\n## Testing\n\nTesting is more important than shipping.\nIf we have no tests or an inadequate amount, then every time we ship code, we won't be sure that we didn't break anything.\nThere's no excuse to not write tests.\nThere are plenty of good JavaScript test frameworks with typing support for TypeScript.\nAlways write tests for every new feature/module we introduce.\n\n## Strict configuration\n\nThe stricter configuration should be mandatory and should be enabled by default because there is not much value in using Typescript without these few flags.\nOtherwise, our types will be too permissive, and it is what we are trying to avoid as much as possible with Typescript.\n\n```json\n{\n  \"forceConsistentCasingInFileNames\": true,\n  \"noImplicitReturns\": true,\n  \"strict\": true,\n  \"noUnusedLocals\": true,\n}\n```\n\nThe most important one here is the `strict` flag which actually covers four other flags.\nWe could add independently to progressively introduce Typescript in an existing codebase and slowly get stricter over time: `noImplicitAny`, `noImplicitThis`, `alwaysStrict` and `strictNullChecks`.\n\n## Avoid any. Type everything\n\nAlways declare variables or constants with a type other than any.\nWhen declaring variables or constants in Typescript without a typing, the typing of the variable/constant will be deduced by the value that gets assigned to it.\nThis will cause unintended problems.\nAnother advantage of having good typings in our application is that it makes refactoring easier and safer.\nThe any type isn't necessarily a bad thing and, in fact, does still come in useful sometimes.\nHowever, in most cases, there is a better alternative that leads to having better defined types overall.\nIn new projects, it is worth setting `strict:true` in the `tsconfig.json` file to enable all strict type checking options.\n\n## Strings should be safe\n\nIf we have a variable of type string that can have only a set of values, instead of declaring it as a string type, we can declare the list of possible values as the type.\n\n```typescript\ntype MyStringType = 'First' | 'Second';\n```\n\nBy declaring the type of the variable appropriately, we can avoid bugs while writing the code during compile time rather than during runtime.\n\n## Call things by their name\n\nThis is a no-brainer, but it is scary how often you will come across variables like `x1`, `fe2` or `xbqne` in JavaScript, or, on the other end of the spectrum, long variable names like `incrementorForMainLoopFromTenToTwenty` or `createNewMemberIfAgeOverTwentyOneAndMoonIsFull`.\nNone of these make much sense.\nGood variable and function names should be easy to understand and tell us what is going on.\nNot more and not less.\nOne trap to avoid is marrying values and functionality in names.\nA function called `isLegalDrinkingAge()` makes more sense than `isOverEighteen()` as the legal drinking age varies from country to country, and there are other things than drinking to consider that are limited by age.\nKeeping to English is a good idea, too, because, programming languages are in English.\n\n## Use utility types\n\nTypeScript already has a few utility types built-in, such as `Partial<T>`, which makes all properties of `T` optional, or `Readonly<T>`, which makes `T` read-only.\nThey will help make our code much easier to understand.\nAs a side note, only try to break interfaces or types into smaller nested interfaces/types if it makes sense from our code's domain point-of-view.\nOnce they are aggressively split up, it's hard to see the structure, especially when using code completion.\n\n## Use const and let\n\nJavaScript first searches to see if a variable exists locally, then searches progressively in higher levels of scope until global variables.\n`var` is function scope, but, `let` and `const` are block scope. Using `let` and `const` where appropriate makes the intention of the declarations clearer.\nIt will also help in identifying issues when a value is reassigned to a constant accidentally by throwing a compile time error.\nDo use a linter that automates checking and fixing this so that changing let to const doesn't become a delay in code review.\n\n## Use === instead of ==\n\nJavaScript utilizes two different kinds of equality operators: `=== | !==` and `== | !=`.\nIt is considered best practice to always use the former set when comparing.\nIf two operands are of the same type and value, then `===` produces `true` and `!==` produces `false`.\nHowever, when working with `==` and `!=`, we'll run into issues when working with different types.\nIn these cases, they'll try to coerce the values, unsuccessfully.\n\n## Use shortcut notation sparingly\n\nShortcut notation is a tricky subject.\nOn the one hand it keeps our code small but on the other we might make it hard for other developers.\nWell, here's a small list of what can (and should) be done:\n\n- Use `{}` instead of `new Object()`\n- Use `\"\"` instead of `new String()`\n- Use `0` instead of `new Number()`\n- Use `false` instead of `new Boolean()`\n- Use `[]` instead of `new Array()`\n- Use `/()/` instead of `new RegExp()`\n- Use function `(){}` instead of `new Function()`\n\n## Avoid globals\n\nGlobal variables and function names are an incredibly bad idea.\nThe reason is that every JavaScript file included in the page runs in the same scope.\nIf we have global variables or functions in our code, scripts included after ours that contain the same variable and function names will overwrite our variables/functions.\n\n## Avoid mixing with other technologies\n\nAlthough it is possible to create everything we need in a document using JavaScript and DOM, it is not necessarily the most effective way of doing so.\nTechniques such as [CSS-in-JS](https://en.wikipedia.org/wiki/CSS-in-JS) are very popular.\nHowever, mixing different technologies in the same file, JavaScript, HTML and CSS, it can be dangerous.\nA good separation of concerns is always the best practice.\n\n## Avoid heavy nesting\n\nNesting code explains its logic and makes it much easier to read.\nHowever nesting it too far can also make it hard to follow what we are trying to do.\nReaders of our code shouldn't have to scroll horizontally or suffer confusion when their code editors wrap long lines.\nThe other problem of nesting is variable names and loops.\nAs we normally start our first loop with as the iterator variable, we'll go on with `j`, `k`, `l` and so on.\nThis can become messy quite quickly.\n\n## Avoid long functions\n\nLong functions generally indicate that they are doing too many things.\nSmall functions are better to read and faster to understand the purpose.\nIf our function has more than 10 lines we need to ask yourself if it would be better to break it into smaller functions.\nThe best functions or methods are from 5 to 10 lines of code.\nThe method itself might be doing one thing, but inside it, there are a few other operations that could be happening.\nWe can extract those methods into their own method and make them do one thing each and use them instead.\n\n## Reduce function parameters\n\nLimiting the amount of function parameters is incredibly important because it makes testing our function easier.\nHaving more than three leads to a combinatorial explosion of test scenarios.\nOne or two arguments is the ideal case, and three should be avoided if possible.\nAnything more than that should be consolidated.\nUsually, if we have more than two arguments then our function is trying to do too much.\nIn cases where it's not, most of the time a higher-level object will suffice as an argument.\n\n## Do not use flags as function parameters\n\nFlags tell our user that this function does more than one thing.\nFunctions should do one thing.\nSplit out our functions if they are following different code paths based on a Boolean.\nWhen functions do more than one thing, they are harder to compose, test, and reason about.\nWhen we can isolate a function to just one action, it can be refactored easily, and our code will read much cleaner.\n\n## Comment as much as needed but not more\n\nComments are our messages to other developers.\nHowever, if we are adding a comment, it's because it's not self-explanatory and we should choose a better way to implement it.\nGood comments are informative comments, when be useful to provide basic information.\nBad Comments are commented-out code is a common practice, but we shouldn't do it, because other developers will think the code is there for a reason and won't have the courage to delete it.\nJust delete the code.\nAnother case is noise comments.\nSome comments that we see are just noise.\nRedundant comments are comments that are not more informative than the code.\nThese comments only clutter the code.\n\n## Use the fastest way to loop arrays\n\nThere are many ways to loop through array.\nThe first way is a `for` loop.\nOther ways include the `for...of` loop, the `forEach` method for arrays, `map`, `filter`, and others.\nThere is also the `while` loop.\nThe `for` loop is the fastest way.\nCaching the `length` makes the loop performs better.\nSome browser engines have optimized the `for` loop without manually caching the `length` property.\nThe `forEach` is slower than the `for` loop, so it's probably better to avoid it, especially for large arrays.\nHowever, unless we are desperate for performance at the code level (which is rare), make it readable.\nFor example, we can use the `for` loop in server-side applications and the array methods in client-side applications, because, in general, we don't have expensive operations on the client-side.\n\n## Prefer array methods\n\nIt is recommended to use a functional approach without intermediate variables.\nThe base JavaScript `for` loop can be more performant in some browsers but the benefit can be measured only by iterating over millions of items.\nIt is job of compiler and runtime to remove penalty of using new array methods.\nWe should ignore critics and switch to new syntax because it is shorter and more readable.\nAnother thing, we will use functional programing instead of imperative programing.\nThe functional programming paradigm was explicitly created to support a pure functional approach to problem solving.\n\n## Do not trust any data\n\nOne of the main points to bear in mind when talking about code and data security is not to trust any data.\nMake sure that all the data that goes into our systems is clean and exactly what we need.\nThis is most important on the back end when writing out parameters retrieved from the URL.\nThe same applies to forms that validate only on the client side.\nAnother very insecure practice is to read information from the DOM and use it without validation.\n\n## Do not use short-hand\n\nTechnically, we can get away with omitting most curly braces and semi-colons.\nMost browsers will correctly interpret the following:\n\n```typescript\nif(someVariableExists)\n   x = false\n```\n\nHowever, this approach is dangerous and not recommended.\nThis is a terrible practice that should be avoided at all costs.\nThe only time that curly braces should be omitted is with one-liners, and even this is a highly debated topic.\n\n## Use parameter defaults\n\nWhen we call a function and forget to pass a parameter to it, then the missing argument is set to undefined.\nES6 introduced default parameters for the function.\nWe can do this:\n\n```typescript\nfunction logNumber(num = 25): void {}\n```\n\nIt is a good habit to assign default values to arguments.\n\n## Use spread and destructuring\n\nThe [spread syntax](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Operators/Spread_syntax) allows us to expand something that is currently grouped inside a particular container and assign it to a different container.\nCompatible containers include: arrays, strings, objects and any iterable (such as Maps, Sets, TypedArrays, etc) and their elements can be expanded into function arguments, array elements and key-value pairs.\nAnother interesting new feature from JavaScript is [destructuring](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment).\nThis syntax allows us to unpack values from objects and arrays into individual properties.\n\n## Use template literals\n\nTemplate literals make working with strings so much easier than before.\nNo more long string concatenation.\nTo create a template literal, instead of single quotes (') or double quotes (\") quotes we use the backtick (`) character.\nThis will produce a new string, and we can use it in any way we want.\n\n## End the switches with defaults\n\nDon't leave the switch statements without a default case because something can go wrong, and we want to make sure it is detected.\nHowever, in some cases, it is unnecessary.\nTo avoid duplicate conditions, we can combine the default statement with another switch statement:\n\n```typescript\nfunction getEmoji(key: string): string {\n  switch (key) {\n    case 'dog':\n      return '🐶';\n    case 'cat':\n      return '😺';\n    // the rest of the emojis...\n    default: case 'smile':\n      return '🙂';\n  }\n}\n```\n\n## Use the prefix \"is\" and \"has\" for Booleans\n\nUsing variables with prefixes `is` and `has` will communicate clearly that the variable is a Boolean.\nThe code is read more often than it is written.\nCorrectly used variable names do not need comments and explanations that can get out of sync with the code rather quickly.\nThe code is written and should be readable for humans.\n\n## Declarations on top\n\nIt is a good coding practice to put all declarations at the top of each script or function.\nThis will give cleaner code, provide a single place to look for local variables, make it easier to avoid unwanted (implied) global variables and reduce the possibility of unwanted re-declarations.\n\n## Initialize variables\n\nIt is a good coding practice to initialize variables when we declare them.\nThis will give cleaner code, provide a single place to initialize variables and avoid undefined values.\nVariables should be declared and initialized at the beginning.\n\n## Use iterators and generators\n\nUse [iterators and generators](https://developer.mozilla.org/docs/Web/JavaScript/Guide/Iterators_and_Generators) when working with collections of data used like a stream.\nThere are some good reasons such as decouples the call from the generator implementation, lazy execution because the items are streamed on demand, built-in support for iterating items using the `for-of` syntax and iterables allow to implement optimized iterator patterns.\n\n## Prefer pure functions\n\nA [pure function](https://www.freecodecamp.org/news/what-is-a-pure-function-in-javascript-acb887375dfe/) is a function where the return value is only determined by its input values, without observable side effects.\nThey're easier to reason about, easier to combine, easier to test, easier to debug, easier to parallelize.\nOther benefits of writing pure functions for functional programming, for instance, they are idempotent, offer referential transparency, are memoizable and can be lazy.\n\n## Prefer immutability\n\nThe immutability in JavaScript allows us to differentiate objects and track changes in our objects.\nIt may sound petty and insignificant, but it turns out to be crucial, especially in front-end applications.\nIn frameworks such as [Angular](https://angular.io/) and [React](https://reactjs.org/), we'll actually get a performance boost by using immutable data structures.\nWe gain predictability, change tracking, easiness of implementing reactive interface, change history and others such as testability and a single source of truth.\n\n## Avoid side effects\n\nA function produces a side effect if it does anything other than take a value in and return another value or values.\nA side effect could be writing to a file or modifying some global variable.\nWe do need to have side effects in a program on occasion.\nWhat we want to do is to centralize where we are doing this.\nThe main point is to avoid common pitfalls like sharing state between objects without any structure, using mutable data types and not centralizing where our side effects occur.\n\n## Avoid magic numbers\n\nMagic numbers are values that appear in source code without any explanation of what they mean.\nThis makes the code difficult to understand and maintain.\nMagic numbers should be avoided as they often lack documentation.\nForcing them to be stored in variables gives them implicit documentation.\nWith [no-magic-numbers](https://palantir.github.io/tslint/rules/no-magic-numbers/) lint rule, we make code more readable and refactoring easier by ensuring that special numbers are declared as constants to make their meaning explicit.\n\n## Avoid conditionals\n\nThis seems like an impossible task.\nUpon first hearing this, most people say, \"how am I supposed to do anything without an if statement?\".\nThe answer is that we can use polymorphism to achieve the same task in many cases.\nThe second question is usually, \"well that's great but why would I want to do that?\".\nThe answer is the clean code concept, that is, a function should only do one thing.\nWhen we have classes and functions that have if statements, we are telling our user that our function does more than one thing.\n\n## Handle JavaScript errors\n\nThrown errors are a good thing.\nThey mean the runtime has successfully identified when something in our program has gone wrong and it's letting us know by stopping function execution on the current stack, killing the process (in Node), and notifying us in the console with a stack trace.\nJavaScript as well as TypeScript allow us to throw any object.\nA Promise can also be rejected with any reason object.\nIt is advisable to use the throw syntax with an Error type.\nThis is because our error might be caught in higher level code with a `catch` syntax.\n\n## Prefer promises over callbacks\n\nPromises are easy to use and anything with a callback can be “promisified”.\nCallbacks are synchronous and with promises and `async…await`, we get to do things asynchronous which help speed up the code, especially because JavaScript is single-threaded.\n\n## Do not use weird JavaScript features\n\nThings like updating array length property, using the `with` keyword, `void` keyword, updating native Object prototypes like Date, Array, Object, etc.\nOthers like `eval()` function or passing a string to `setTimeout` and `setInterval`.\nJust because the language allows us to, does not mean we should.\n\n## Do not yield to web browser whims\n\nWriting code specific to a certain web browser is a sure-fire way to keep our code hard to maintain and make it get dated quickly.\nIf we look around the web, we'll find a lot of scripts that expect a certain browser and stop working as soon as a new version or another browser comes around.\nThis is wasted time and effort.\nWe should build code based on agreed standards.\nThe web is for everybody, not an elite group of users with a state-of-the-art configuration.\nAs the browser market moves quickly, we will have to go back to our code and keep fixing it.\nThis is neither effective.\n\n## Place scripts at the bottom of the page\n\nWhen loading a script, the browser can't continue until the entire file has been loaded.\nThus, the user will have to wait longer before noticing any progress.\nIf we have JavaScript files whose only purpose is to add functionality, for example, after a button is clicked, we place those files at the bottom, just before the closing body tag.\nThe primary goal is to make the page load as quickly as possible for the user.\nThis is absolutely a best practice.\n\n## Keep DOM access to a minimum\n\nAccessing the DOM in browsers is an expensive thing to do.\nThe DOM is a very complex API and rendering in browsers can take up a lot of time.\nTo make sure that our code is fast and doesn't slow down the browser to a halt try to keep DOM access to a bare minimum.\nInstead of constantly creating and applying elements, have a tool function that turns a string into DOM elements and call this function at the end of our generation process to disturb the browser rendering once rather than continually.\n\n## Allow configuration and translation\n\nOne of the most successful tips to keep our code maintainable and clean is to create a configuration object that contains all the things that are likely to change over time.\nIf we have this as a part of a module pattern and make it public, we even allow implementers to only override what they need before initializing the module.\nIt is of utmost importance to keep code maintenance simple, avoiding the need for future maintainers having to read all our code and find where they need to change things.\n\n## Progressive Enhancement\n\nWe should do is write code that works regardless of available technology.\nIn the case of JavaScript, this means that when scripting is not available (say on an old browser, or because of an over-zealous security policy) our web products should still allow users to reach a certain goal, not block them because of the lack of JavaScript which they can't turn on, or don't want to.\nFor example, imagine links to navigate to other pages after the click action.\nThe problem starts when the navigation is done by JavaScript.\nWhen JavaScript is disabled, users cannot navigate.\nUsing the correct HTML construction (Hyperlinks), we were able to get rid of JavaScript.\n\n## Raw JavaScript is faster\n\nJavaScript libraries, such as [jQuery](https://jquery.com/), can save us an enormous amount of time when coding, especially with AJAX operations.\nHaving said that, always keep in mind that a library can never be as fast as raw JavaScript.\njQuery's `each` method is great for looping, but using a native `for` loop will always be an ounce quicker.\n\n## Organize and remove unused imports\n\nWith clean and easy to read import statements we can quickly see the dependencies of current code.\nWith [no-unused-variable](https://palantir.github.io/tslint/rules/no-unused-variable) lint rule are automatically remove unused imports, variables, functions, and private class members, when using TSLint's --fix option.\n[ordered-imports](https://palantir.github.io/tslint/rules/ordered-imports) lint rule requires that import statements be alphabetized and grouped.\n\n## Modularization\n\nThis is a general programming best practice.\nMaking sure that we create functions that fulfill one job at a time makes it easy for other developers to debug and change the code without having to scan through all the code to work out what code block performs what function.\nThis also applies to creating helper functions for common tasks.\nIf we are doing the same thing in several different functions then it is a good idea to create a more generic helper function.\n\n## Lazy-Loading\n\nLazy, or \"on demand\", loading is a great way to optimize our site or application.\n[Lazy loading](https://angular.io/guide/lazy-loading-ngmodules) helps keep initial bundle sizes smaller, which in turn helps decrease load times.\nThis practice essentially involves splitting our code at logical breakpoints, and then loading it once the user has done something that requires, or will require, a new block of code.\nThis speed up the initial load of the application and lightens its overall weight as some blocks may never even be loaded.\n\n## Compress the files\n\nUse a compression method such as [Gzip or Brotli](https://medium.com/oyotech/how-brotli-compression-gave-us-37-latency-improvement-14d41e50fee4) to reduce the size of our JavaScript files.\nWith a smaller sizes file, users will be able to download the asset faster, resulting in improved performance.\nIn today's web environment, many browsers and servers both support compression.\nIts ability to reduce file sizes by up to 70% provides a great incentive to make use of this compression method.\nTo enable compression is considered a high-priority recommendation by site speed test tools, as without it we are unnecessarily increasing our webpage's load time.\n\n## Minify the code\n\nBundling our application's components into `*.js` files and passing them through a JavaScript minification program will make our code leaner.\nTo compress, minimize or minify code simply refers to removing unnecessary characters from the source code like white spaces, new line characters and a host of redundant data without affecting how the code or resource is processed by the browser.\nThis is a very effective technique otherwise called code minimization that improves the load time of the application and by implication the overall web performance because of a smaller file size.\nWe can do this by choosing a popular code [minification tool](https://blog.bitsrc.io/10-javascript-compression-tools-and-libraries-for-2019-f141a0b15414).\n\n## Use Google LightHouse\n\n[Google Lighthouse](https://developers.google.com/web/tools/lighthouse) is an open-source, automated tool for improving the quality of web pages.\nWe can run it against any web page, public or requiring authentication.\nIt has audits for performance, accessibility, progressive web apps, SEO and more.\nWe can run Lighthouse in Chrome DevTools, from the command line, or as a Node module.\nWe can also install it as a plugin in Chrome browser.\n\n## Use Web Workers\n\nUse web workers when we need to execute code that needs a lot of execution time.\nWeb Workers help us to run scripts in background threads.\nThe worker thread can perform tasks without interfering with the user interface.\nThey can perform processor-intensive calculations without blocking the user interface thread.\n\n## Bibliography\n\n- [8 Best Practices for Future-Proofing Your TypeScript Code](https://medium.com/better-programming/8-best-practices-for-future-proofing-your-typescript-code-2600fb7d8063)\n- [15 JavaScript Tips: best practices to simplify your code](https://www.educative.io/blog/javascript-tips-simplify-code)\n- [19 simple JavaScript coding standards to keep your code clean](https://medium.com/javascript-in-plain-english/19-simple-javascript-coding-standards-to-keep-your-code-clean-7422d6f9bc0)\n- [45 Useful JavaScript Tips, Tricks And Best Practices](https://modernweb.com/45-javascript-tips-tricks-practices/)\n- [50 Javascript Best Practice Rules to Write Better Code](https://beforesemicolon.medium.com/50-javascript-best-practice-rules-to-write-better-code-86ce731311d7)\n- [Clean Code TypeScript](https://github.com/labs42io/clean-code-typescript)\n- [Design Patterns](https://refactoring.guru/design-patterns)\n- [Design Patterns in TypeScript](https://github.com/torokmark/design_patterns_in_typescript)\n- [Five tips I wish I knew when I started with Typescript](https://codeburst.io/five-tips-i-wish-i-knew-when-i-started-with-typescript-c9e8609029db)\n- [JavaScript Best Practices for Beginners](https://medium.com/javascript-in-plain-english/javascript-best-practices-for-beginners-b573cbc1ec0f)\n- [JavaScript Best Practices](https://www.w3schools.com/js/js_best_practices.asp)\n- [JavaScript best practices](https://www.w3.org/wiki/JavaScript_best_practices)\n- [TypeScript Style Guide and Coding Conventions](https://github.com/basarat/typescript-book/blob/master/docs/styleguide/styleguide.md)\n- [TypeScript: Do's and Don'ts](https://www.typescriptlang.org/docs/handbook/declaration-files/do-s-and-don-ts.html)\n- [Typescript Best Practices](https://engineering.zalando.com/posts/2019/02/typescript-best-practices.html)\n"
  }
]