Tech learning roadmaps…

[dasari4kntr]

The Best JavaScript Tools in 2022: An Essential Guide to Better Development

A breakdown of the most important JS dev tools in 2022, including their most relevant tradeoffs, and some opinionated advice sprinkled on top.

 

In the world of software engineering, it’s important to have a firm understanding of the tools at your disposal.

 

But the landscape of JS tooling is always changing at such a rapid pace.

 

And 2022 is no different.

 

So I decided to break down the most important dev tools that you should be aware of in 2022.

We’ll start with the lowest-level tools and work our way up to higher-level tools from there. Let’s get started 💪

 

Compilers

Compilers are responsible for transforming your input code into some target output format. For our purposes, we’re focusing on compilers which support transpiling modern JavaScript and TypeScript into specific versions of ECMAscript that are compatible with browsers and recent versions of Node.js.

 

The most important thing to understand about this space is that it’s in the middle of undergoing a massive shift from compilers like tsc and babel, which are written in higher-level interpreted languages, to compilers like swc and esbuild, which are written in much faster, compiled languages.

 

This shift results in 10-100x faster compilation times as shown in this esbuild demo.

Source: esbuild

If you’re updating your devtools stack or starting a new project in 2022, then you’ll want to consider using one of these next-gen compilers under the hood. They may not be as mature as the official typescript compiler or babel, but the benefits of having 100x faster builds cannot be understated.

 

Note that neither swc nor esbuild perform type checking. They simply transpile code into the desired output format as quickly and efficiently as possible. For the time being, if you’re working with TypeScript, you’ll almost always need to have the official TypeScript compiler as part of your toolchain to guarantee that you’re getting the most out of TypeScript’s static type checking. It’s also worth mentioning that the author of swc, kdy1dev is working on porting tsc to Go in order to remove the need for tsc in many cases, as it tends to be the bottleneck in most toolchains.

 

SWC vs esbuild

swc and esbuild are both excellent, blazing fast, open source JS / TS compilers. They have comparable performance and are both used regularly in production by some of the world’s largest companies.

 

It’s likely that your choice between the two will be dictated more by the higher-level tools built on top of these compilers as opposed to choosing between them directly.

 

Notable projects using swc:

• Vercel and Next.js
• Deno’s linter, formatter, and docs
• Parcel
• nx

 

Notable projects using esbuild:

• Vite
• Nuxt.js
• Remix
• SvelteKit
• tsup

 

In software engineering, convenient statements such as “technology A is better than technology B” rarely hold much value. Rather, you should try to always keep context in mind. In this case, there are many scenarios where you’d be better off using tsc or babel.

 

Becoming a better software engineer often boils down to thoroughly understanding the tradeoffs involved with these types of decisions, and balancing those tradeoffs against the particular constraints of your project, team, and business’ needs.

 

Bundlers

 

 

 

Source: Webpack

 

Bundlers are responsible for taking all of your input source files and bundling them together into an easy-to-consume output format. The two most common use cases for bundlers are bundling libraries and bundling resources for web applications.

 

Bundlers like webpack and rollup are the swiss-army knives of modern JS toolchains. They are both extremely extensible, with well-maintained plugins covering major use cases. It’s relatively straightforward, for example, to use any of the popular compilers listed above to transpile TS code with either webpack or rollup.

 

Parcel, on the other hand, provides a mostly zero-config approach to bundling. It focuses on simplicity as opposed to extensibility and uses swc as a compiler under the hood.

Note that swc and esbuild both provide basic bundling capabilities as well, though compared with these alternatives, they’re not full-featured enough to be included on this list.

For a much more detailed comparison of these bundlers, check out tooling.report.

 

Package Managers

Package managers are responsible for managing dependencies in the form of NPM packages.

 

 

 

There’s a lot of history here, but the TL;DR is:

• All of these package managers have similar features and perf nowadays, so don’t be too worried about which one you’re using.
• pnpm seems to be gaining a lot of traction very quickly. 💪
• The way yarn berry was rolled out and the subsequent deprecation of yarn v1 turned a lot of people off from using yarn, though yarn berry has come a long way in the past few years.
• yarn plug’n’play is an interesting approach, but in practice, it has only seen adoption in cases with very large monorepos.
  • I can’t tell you the number of times I’ve wanted to inspect or add console.log statements to my node_modules, and not being able to do so is a real disadvantage.

 

Adoption by popular projects

 

 

 

A breakdown of the package managers chosen by popular projects. This image is from Sebastian Weber’s excellent package manager deep dive. Note that at the time of this writing, none of these projects are using Yarn PnP.

 

Library Development

These tools are meant to help library authors bundle and publish modern NPM packages.

 

 

 

If you’re developing a new library in 2022, you’ll likely want to use one of these higher-level tools to simplify your workflow.

 

• If you have a TS package and want to take advantage of extremely fast build times courtesy of esbuild, then tsup is a great option.
• If you have a TS package and need some additional features, then tsdx is a great option.
• If you have a TS or JS package, then microbundle is also a great option.
• Vite is mainly a tool for building frontend web apps, but it also includes support for outputting libraries and is a very solid all-around option.
• For monorepos, nx looks really promising.

 

My personal preference will be to use tsup for TS packages, mainly because once you’ve experienced 100x faster builds, it’s really difficult to consider switching back to anything else.

 

More Info

Most of these tools don’t currently provide great support for TS monorepos which take advantage of composite project references. For the time being, my recommendation for this case is to use tsc for type checking and generating .d.ts typings (with emitDeclarationOnly: true) and tsup for compiling code in each of the sub-packages. For an example of this approach, check out the react-notion-x monorepo (one of my OSS projects).

 

Publishing modern NPM packages is a nuanced topic that goes well beyond the scope of this article. For more info on ESM, commonjs, dual-package publishing, exports, and more see:

• What does it take to support Node.js ESM?
• Sindresorhus’ notes on publishing and

• Pure ESM package
  
  The package that linked you here is now pure ESM. It cannot be require()'d from CommonJS.
  
  This means you have the following choices:
  
      Use ESM yourself. (preferred)
      Use import foo from 'foo' instead of const foo = require('foo') to import the package. You also need to put "type": "module" in your package.json and more. Follow the below guide.
      If the package is used in an async context, you could use await import(…) from CommonJS instead of require(…).
      Stay on the existing version of the package until you can move to ESM.
  
  You also need to make sure you're on the latest minor version of Node.js. At minimum Node.js 12.20, 14.14, or 16.0.
  
  I would strongly recommend moving to ESM. ESM can still import CommonJS packages, but CommonJS packages cannot import ESM packages synchronously.
  
  ESM is natively supported by Node.js 12 and later.
  
  My repos are not the place to ask ESM/TypeScript/Webpack/Jest/ts-node/CRA support questions.
  FAQ
  How can I move my CommonJS project to ESM?
  
      Add "type": "module" to your package.json.
      Replace "main": "index.js" with "exports": "./index.js" in your package.json.
      Update the "engines" field in package.json to Node.js 14: "node": ">=14.16". (Excluding Node.js 12 as it's no longer supported)
      Remove 'use strict'; from all JavaScript files.
      Replace all require()/module.export with import/export.
      Use only full relative file paths for imports: import x from '.'; → import x from './index.js';.
      If you have a TypeScript type definition (for example, index.d.ts), update it to use ESM imports/exports.
      Optional but recommended, use the node: protocol for imports.
  
  Sidenote: If you're looking for guidance on how to add types to your JavaScript package, check out my guide.
  Can I import ESM packages in my TypeScript project?
  
  Yes, but you need to convert your project to output ESM. See below.
  How can I make my TypeScript project output ESM?
  
  Read the official ESM guide.
  
  Quick steps:
  
      Make sure you are using TypeScript 4.7 or later.
      Add "type": "module" to your package.json.
      Replace "main": "index.js" with "exports": "./index.js" in your package.json.
      Update the "engines" field in package.json to Node.js 14: "node": ">=14.16". (Excluding Node.js 12 as it's no longer supported)
      Add "module": "node16", "moduleResolution": "node16" to your tsconfig.json. (Example)
      Use only full relative file paths for imports: import x from '.'; → import x from './index.js';.
      Remove namespace usage and use export instead.
      Optional but recommended, use the node: protocol for imports.
      You must use a .js extension in relative imports even though you're importing .ts files.
  
  If you use ts-node, follow this guide. Example config.
  How can I import ESM in Electron?
  
  Electron doesn't yet support ESM natively.
  
  You have the following options:
  
      Stay on the previous version of the package in question.
      Bundle your dependencies with Webpack into a CommonJS bundle.
      Use the esm package.
  
  I'm having problems with ESM and Webpack
  
  The problem is either Webpack or your Webpack configuration. First, ensure you are on the latest version of Webpack. Please don't open an issue on my repo. Try asking on Stack Overflow or open an issue the Webpack repo.
  I'm having problems with ESM and Next.js
  
  Upgrade to Next.js 12 which has full ESM support.
  I'm having problems with ESM and Jest
  
  Read this first. The problem is either Jest (#9771) or your Jest configuration. First, ensure you are on the latest version of Jest. Please don't open an issue on my repo. Try asking on Stack Overflow or open an issue the Jest repo.
  I'm having problems with ESM and TypeScript
  
  If you have decided to make your project ESM ("type": "module" in your package.json), make sure you have "module": "node16" in your tsconfig.json and that all your import statements to local files use the .js extension, not .ts or no extension.
  I'm having problems with ESM and ts-node
  
  Follow this guide and ensure you are on the latest version of ts-node.
  
  Example config.
  I'm having problems with ESM and Create React App
  
  Create React App doesn't yet fully support ESM. I would recommend opening an issue on their repo with the problem you have encountered. One known issue is #10933.
  How can I use TypeScript with AVA for an ESM project?
  
  Follow this guide.
  How can I make sure I don't accidentally use CommonJS-specific conventions?
  
  We got you covered with this ESLint rule. You should also use this rule.
  What do I use instead of __dirname and __filename?
  
  import {fileURLToPath} from 'node:url';
  import path from 'node:path';
  
  const __filename = fileURLToPath(import.meta.url);
  const __dirname = path.dirname(fileURLToPath(import.meta.url));
  
  However, in most cases, this is better:
  
  import {fileURLToPath} from 'node:url';
  
  const foo = fileURLToPath(new URL('foo.js', import.meta.url));
  
  And many Node.js APIs accept URL directly, so you can just do this:
  
  const foo = new URL('foo.js', import.meta.url);
  
  How can I import a module and bypass the cache for testing?
  
  There's no good way to do this yet. Not until we get ESM loader hooks. For now, this snippet can be useful:
  
  const importFresh = async modulePath => import(`${modulePath}?x=${new Date()}`);
  
  const chalk = (await importFresh('chalk')).default;
  
  Note: This will cause memory leaks, so only use it for testing, not in production. Also, it will only reload the imported module, not its dependencies.
  How can I import JSON?
  
  JavaScript Modules will eventually get native support for JSON, but for now, you can do this:
  
  import fs from 'node:fs/promises';
  
  const packageJson = JSON.parse(await fs.readFile('package.json'));
  
  When should I use a default export or named exports?
  
  My general rule is that if something exports a single main thing, it should be a default export.
  
  Keep in mind that you can combine a default export with named exports when it makes sense:
  
  import readJson, {JSONError} from 'read-json';
  
  Here, we had exported the main thing readJson, but we also exported an error as a named export.
  Asynchronous and synchronous API
  
  If your package has both an asynchronous and synchronous main API, I would recommend using named exports:
  
  import {readJson, readJsonSync} from 'read-json';
  
  This makes it clear to the reader that the package exports multiple main APIs. We also follow the Node.js convention of suffixing the synchronous API with Sync.
  Readable named exports
  
  I have noticed a bad pattern of packages using overly generic names for named exports:
  
  import {parse} from 'parse-json';
  
  This forces the consumer to either accept the ambiguous name (which might cause naming conflicts) or rename it:
  
  import {parse as parseJson} from 'parse-json';
  
  Instead, make it easy for the user:
  
  import {parseJson} from 'parse-json';
  
  Examples
  
  With ESM, I now prefer descriptive named exports more often than a namespace default export:
  
  CommonJS (before):
  
  const isStream = require('is-stream');
  
  isStream.writable(…);
  
  ESM (now):
  
  import {isWritableStream} from 'is-stream';
  
  isWritableStream(…);

   

• ESM packages

 

Web App Development

These higher-level tools and frameworks are intended to help developers build modern web applications without worrying about all the details.

If you’re developing a new web app in 2022 using React, then I would highly recommend using Next.js. It has the best support, the most active community, and close integration with Vercel, the world’s leading deployment platform for modern web apps.

 

Remix provides a really compelling alternative to Next.js. It’s from the makers of react-router, and though it’s relatively new, they’re definitely a framework to keep an eye on.

 

If you’re developing a new web app using Vue, then Nuxt.js and Vite are both great options.

 

And last, but certainly not least, if you want something more light-weight, then give Parcel a try. 🤗

 

There seems to be a roughly equal number of projects building on top of swc and esbuild. The same observation goes for webpack and rollup.

 

Conclusion

Modern web development has evolved significantly over the past 10 years. Developers today are lucky to have such a wide range of amazing, well-maintained tools to choose from.

 

This is, however, by no means a comprehensive list of dev tools. If there’s something missing that you’d like to see added, let me know on twitter.

 

Hopefully this breakdown has helped you parse the most important aspects of the current JS / TS dev tools landscape, and hopefully it’ll help you to make more informed decisions going forwards.

[dasari4kntr]

 

 

[dasari4kntr]

On 12/1/2022 at 9:35 PM, dasari4kntr said:

interview preparation materials...

https://drive.google.com/drive/folders/1-xCQsuoY2_5dZ52LKr2UZP3BP0Mcde4P?usp=sharing

updated with few additions....

[csrcsr]

When I see this thread and started 150 questions of leetcode

https://www.instagram.com/reel/CjcfAvwsRAb/?igshid=MDJmNzVkMjY=

[chicagoafdb]

15 hours ago, csrcsr said:

When I see this thread and started 150 questions of leetcode

https://www.instagram.com/reel/CjcfAvwsRAb/?igshid=MDJmNzVkMjY=

150 questions and study plan share cheyyandi..

[csrcsr]

6 minutes ago, chicagoafdb said:

150 questions and study plan share cheyyandi..

E thread lo unayi bro a drive lo

https://drive.google.com/drive/folders/1-xCQsuoY2_5dZ52LKr2UZP3BP0Mcde4P?usp=sharing

More or less algoexpwrtio lo unayi

Courtesy @dasari4kntr

[Complex]

2 minutes ago, csrcsr said:

E thread lo unayi bro a drive lo

https://drive.google.com/drive/folders/1-xCQsuoY2_5dZ52LKr2UZP3BP0Mcde4P?usp=sharing

More or less algoexpwrtio lo unayi

Courtesy @dasari4kntr

algos chaduvuthunte mind divert avuthadha anna meku kuda..

[csrcsr]

7 minutes ago, Complex said:

algos chaduvuthunte mind divert avuthadha anna meku kuda..

Avakapothe e db lo undamd bro common it needed dedication vlose friends tho challenge esuko kodiga interst unna vala tho a drive lo daily 5 30 day plan undi adi try cheyi mee doing 4 chuddam holidays lo doubte

[dasari4kntr]

13 minutes ago, csrcsr said:

E thread lo unayi bro a drive lo

https://drive.google.com/drive/folders/1-xCQsuoY2_5dZ52LKr2UZP3BP0Mcde4P?usp=sharing

More or less algoexpwrtio lo unayi

Courtesy @dasari4kntr

after vacation…nenu full preparation start cheyyali…

 

[csrcsr]

https://www.instagram.com/reel/CmjasnwII76/?igshid=MDJmNzVkMjY=

[dasari4kntr]

FREE (Google) Courses you will regret not taking in 2023.


[1] Google Analytics for Beginners

🔗https://lnkd.in/deSN6Bsb

[2] Advanced Google Analytics

🔗https://lnkd.in/dA7dhdwi

[3] Google Analytics for Power Users

🔗https://lnkd.in/da42MiC5

[4] Fundamentals of digital marketing

🔗https://lnkd.in/dE7FFs6m

[5] Get started with Google Maps Platform

🔗https://lnkd.in/dX2aRzs9

[6] Google Cloud Computing Foundations:

🔗https://lnkd.in/dYW5FF_B

[7] Google Cloud Computing Foundations:

🔗https://lnkd.in/d_7VWMqv

[8] Google Cloud Computing Foundations: Data, ML, and AI in Google Cloud

🔗https://lnkd.in/dYJzj9R2

[9] Google Cloud Computing Foundations: Networking and Security in Google Cloud

🔗https://lnkd.in/dYuHD_3S

[10] Machine Learning Crash Course

🔗https://lnkd.in/dmZinF4p

[11] Basics of Machine Learning

🔗https://lnkd.in/dNTMQPM9

[12] Data Science with Python

https://lnkd.in/dkr4KGHD

[13] Python Basics for Data Analysis

🔗https://lnkd.in/dRunXPtA

[14] Data Science Foundations

🔗https://lnkd.in/d5Dz7q8Y

Happy Learning.💥

Follow Arif Alam for more. ✔️

[dasari4kntr]

One Diagram to Remember for C𝗼𝗱𝗲 R𝗲𝘃𝗶𝗲𝘄𝘀



An essential step in the software development lifecycle is code review. Code reviews are powerful means to improve code quality, establish best practices, opportunity to learn, and knowledge sharing and mentoring, as well as promotes team cohesion.


What to look for in a code review? Try to look for things such as 𝗱𝗲𝘀𝗶𝗴𝗻 (does this integrate well with the rest of the system and are interactions of different components make sense), 𝗳𝘂𝗻𝗰𝘁𝗶𝗼𝗻𝗮𝗹𝗶𝘁𝘆 (does this change is what the developer intended), 𝗰𝗼𝗺𝗽𝗹𝗲𝘅𝗶𝘁𝘆 (is this code more complex than it should be), 𝗻𝗮𝗺𝗶𝗻𝗴 (is naming good?), 𝗲𝗻𝗴. 𝗽𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲𝘀 (solid, kiss, dry), 𝘁𝗲𝘀𝘁𝘀 (are different kinds of tests used appropriately, code coverage), 𝘀𝘁𝘆𝗹𝗲 (does it follow style guidelines), 𝗱𝗼𝗰𝘂𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻, etc.
 
Code review is a conversation, not a queue of commands.

Code review checklist

A checklist helps you to create a structured approach to code reviews. Also, they remind you of all the quality checks you need to perform to approve code into the codebase.



𝟭. 𝗧𝗿𝘆 𝘁𝗼 𝗿𝗲𝘃𝗶𝗲𝘄 𝘆𝗼𝘂𝗿 𝗼𝘄𝗻 𝗰𝗼𝗱𝗲 𝗳𝗶𝗿𝘀𝘁

Before sending a code to your colleagues, try to read and understand it first. Then, search for parts that confuse you.

𝟮. 𝗪𝗿𝗶𝘁𝗲 𝗮 𝘀𝗵𝗼𝗿𝘁 𝗱𝗲𝘀𝗰𝗿𝗶𝗽𝘁𝗶𝗼𝗻 𝗼𝗳 𝘄𝗵𝗮𝘁 𝗶𝘀 𝗰𝗵𝗮𝗻𝗴𝗲𝗱

It should explain what changes were at a high level and why those changes were made.

𝟯. 𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗲 𝘄𝗵𝗮𝘁 𝗰𝗮𝗻 𝗯𝗲 𝗮𝘂𝘁𝗼𝗺𝗮𝘁𝗲𝗱

Leave to the system everything that can be automated, 
PMD, FindBugs, and Checkstyle are the most popular open-source code analyzers, 
Jenkins for CI-CD some code smells and bugs (SonarQube).

𝟰. 𝗗𝗼𝗻'𝘁 𝗿𝘂𝘀𝗵

You need to understand what is changed in every line of it. Read multiple times if required, class by class.

𝟱. 𝗖𝗼𝗺𝗺𝗲𝗻𝘁 𝘄𝗶𝘁𝗵 𝗸𝗶𝗻𝗱𝗻𝗲𝘀𝘀

Never mention the person (you), always focus on changes as questions or suggestions and leave at least one positive comment. Explain the "why" in your comments and suggestions for improving it.

𝟲. 𝗔𝗽𝗽𝗿𝗼𝘃𝗲 𝗣𝗥 𝘄𝗵𝗲𝗻 𝗶𝘁𝘀 𝗴𝗼𝗼𝗱 𝗲𝗻𝗼𝘂𝗴𝗵

Don't strive for perfection, but hold to high standards. Don't be a nitpicker.

𝟳. 𝗠𝗮𝗸𝗲 𝗿𝗲𝘃𝗶𝗲𝘄𝘀 𝗺𝗮𝗻𝗮𝗴𝗲𝗮𝗯𝗹𝗲 𝗶𝗻 𝘀𝗶𝘇𝗲

We should limit the number of lines of code for review in one sitting. Our brains cannot process so much information at once. The ideal number of LOC is 200 to 400 lines of the core at one time, which is usually 60 to 90 minutes. 

8) Review logic, not semicolons

Automation reduces the needless checks and let's you focus on the logic behind the changes rather than syntax errors and typos.

 

[dasari4kntr]

INTERVIEW QUESTION...

 

 

Interviewer : If you were working on a React application that was rendering a page very slowly, how would you go about investigating and fixing the issue?

What's your opinion ?
.
.
.
If a performance issue such as slow rendering is seen within a React app, the first step is to use the Profiler tool provided within the React Developer Tools browser plugin, which is available for Google Chrome and Mozilla Firefox.

The Profiler tool allows developers to find components that take a long time to render or are rendering more frequently than necessary.
One of the most common issues in React applications is when components re-render unnecessarily.

There are two tools provided by React that are helpful in these situations:
React.memo(): This prevents unnecessary re-rendering of function components
PureComponent: This prevents unnecessary re-rendering of class components

Both of these tools rely on a shallow comparison of the props passed into the component—if the props have not changed, then the component will not re-render. While both tools are very useful, the shallow comparison brings with it an additional performance penalty, so both can have a negative performance impact if used incorrectly.

By using the React Profiler, performance can be measured before and after using these tools to ensure that performance is actually improved by making a given change.

For more insightful checkout below:
GitHub - https://lnkd.in/dkW958Tj
YouTube - https://lnkd.in/dDig2j75 

[dasari4kntr]

What is cloud native?

.
.
Below is a diagram showing the evolution of architecture and processes since the 1980s.

Organizations can build and run scalable applications on public, private, and hybrid clouds using cloud native technologies.

This means the applications are designed to leverage cloud features, so they are resilient to load and easy to scale.

Cloud native includes 4 aspects:
🔹 1. Development process
This has progressed from waterfall to agile to DevOps.

🔹 2. Application Architecture
The architecture has gone from monolithic to microservices. Each service is designed to be small, adaptive to the limited resources in cloud containers.

🔹 3. Deployment & packaging
The applications used to be deployed on physical servers. Then around 2000, the applications that were not sensitive to latency were usually deployed on virtual servers. With cloud native applications, they are packaged into docker images and deployed in containers.

🔹 4. Application infrastructure
The applications are massively deployed on cloud infrastructure instead of self-hosted servers.

👉 Over to you: what comes into your mind when people talk about “cloud native”?

–
Subscribe to our weekly newsletter to learn something new every week:
https://bit.ly/3FEGliw

 

 

[dasari4kntr]

On 12/26/2022 at 10:23 PM, csrcsr said:

E thread lo unayi bro a drive lo

https://drive.google.com/drive/folders/1-xCQsuoY2_5dZ52LKr2UZP3BP0Mcde4P?usp=sharing

More or less algoexpwrtio lo unayi

Courtesy @dasari4kntr

updated the drive..with few additions...