DEV Community: Gaurav Behere

Time to say goodbye to Webpack?

Gaurav Behere — Thu, 13 Jan 2022 09:50:25 +0000

Before we answer the big question, lets look at why we are even considering it.

If you look at bestofJS data for 2021, you would see that the rising star in the build tools category is Vite, leaving Webpack far behind in terms of popularity.
Check out more stats here:
2021 JavaScript Rising Stars

Lets have a closer look at `Vite`

Vite (French word for "quick", pronounced /vit/, like "veet") is a build tool that aims to provide a faster and leaner development experience for modern web projects.

Please note the emphasis on development. Vite does not promise a multifold optimization or better production experience. So don't expect your production build to be optimized or any drastic reduction in the bundle size you generate.

So what does `Vite` do to make the development experience better?

It consists of two major parts:

A dev server that provides rich feature enhancements over native ES modules, for example extremely fast Hot Module Replacement (HMR).
A build command that bundles your code with Rollup, pre-configured to output highly optimized static assets for production.

Vite is opinionated and comes with sensible defaults out of the box, but is also highly extensible via its Plugin API and JavaScript API with full typing support.

It has been long since we have been writing JS code in a modular fashion specially since ES6 modules. Since not a lot of browsers were handling loading ES6 modules natively, we have the concept of bundling our code, using tools that crawl, process and concatenate our source modules into files that can run in the browser.

Tools like Webpack, parcel & rollup do the same job.
When you start a project, the size & number of JS modules may look like a smaller problem but as you write more code, the project grows & you see that starting a dev server takes a long time.
Since it has to transpile the code & concatenate the code in a way that can be loaded in browsers.
The slow feedback loop can greatly affect developers' productivity and happiness.

Vite aims to address these issues by leveraging new advancements in the ecosystem: the availability of native ES modules in the browser, and the rise of JavaScript tools written in compile-to-native languages.

Vite splits the bundles into two parts:

External dependencies (Vendor code): Dependencies are mostly plain JavaScript that do not change often during development.
Vite pre-bundles dependencies using esbuild. Esbuild pre-bundles dependencies 10-100x faster than JavaScript-based bundlers.
Your code (ES modules): Vite serves source code over native ESM. This is essentially letting the browser take over part of the job of a bundler. Vite only needs to transform and serve source code on demand, as the browser requests it.

Here, Vite assumes that while you are developing in your local machine you would have latest of browsers that support loading ES6 modules natively.

That essentially means no time spent on bundling your code before the server can start.

Awesome, so why bundle for production?

Though most of the browsers now support loading ES modules natively, if not all of your target audience is on latest browsers, you still need bundling.
If you don't bundle, you are going to make a lot of round trips on the network to fetch modules. To get the optimal loading performance in production, it is still better to bundle your code with tree-shaking, lazy-loading and common chunk splitting (for better caching).

Getting started with `Vite`

With minimal dev dependencies, you can be off to a flying start

"devDependencies": {
  "@vitejs/plugin-react": "^1.1.4",
  "vite": "^2.7.10"
}

A very basic vite.config.js

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [react()]
});

Two simple commands to start a dev server & make a production build:
vite & vite build respectively.

Vite looks for an index html entry in the root directory from where you need to load the root/index module of your code.

index.html

<!DOCTYPE html>
<html>
<head></head>
<body>
  <div id="root"></div>
  <script type="module" src="./index.jsx"></script>
</body>
</html>

index.jsx

import React from 'react';
import ReactDOM from 'react-dom'
import App from './src/app';

ReactDOM.render(
    <React.StrictMode>
        <App />
    </React.StrictMode>,
    document.querySelector('#root')
);

src/app.jsx

import React from 'react';

const App = () => {
  return <>
    <div>Hello There</div>
    <div>Time right now: {new Date().toTimeString()}</div>
  </>
}

export default App;

Without bundling the code, server starts in a fraction of a second

If you look at how the ES modules are loaded in the browser, note that app.jsx loaded as a native ES module

Hot replacement of modules (HMR)

Developers need to get immediate feedback of changes made in the code. You can't wait for full bundling to happen again & reloading the page which breaks the current state & flow.
This is why some bundlers support Hot Module Replacement (HMR), allowing a module to "hot replace" itself without affecting the rest of the page. Again as the project grows, HMR also takes a long time which can be a productivity killer.

Vite takes an edge over other bundling tools by performing HMR over native ESM. When a file is edited, Vite only needs to precisely invalidate the chain between the edited module and its closest HMR boundary (most of the time only the module itself), making HMR updates consistently fast regardless of the size of your application.

Vite also takes advantage of HTTP headers to speed up full page reloads. Source code module requests are made conditional via 304 Not Modified, and dependency module requests are strongly cached via Cache-Control: max-age=31536000,immutable so they don't hit the server again once cached.

Recap

Vite starts your dev server fast by skipping the bundling.
Vite make use of HTTP status codes for a faster reload & caching.
Vite uses native ESM for hot module replacement. Thus your changes reflect in your app faster.
Since Vite is a bit opinionated about the config, with a minimal config you are good to go.

Server side rendering

Vite is also pre-configured to handle your build as a universal app. Vite can pre-render the HTML pages, so robot crawlers can fetch your page content without executing js.
Read more https://vitejs.dev/guide/ssr.html

So should we just move to `Vite` & stop using tools like Webpack?

Coming back to the question that we started with. With all the benefits listed above, it seems promising to move to Vite.

What gives you a lot of simpler APIs with a lot of abstraction and an opinion is often hard to configure.

Based on this principle if you use some very specific long tail configurations of Webpack, it won't be a good idea to jump to Vite rightaway. If you use Webpack with basic configurations, you should move to Vite for a better developer experience.

If I am starting a new project, it will be using Vite for sure.

Thank you for reading. If you have moved a large scale project from Webpack to Vite, do share your experience. It will be great to learn from your experience.

Unit testing service workers

Gaurav Behere — Wed, 15 Dec 2021 13:03:27 +0000

Writing unit tests for service workers made easy.

Prelude

While service workers amaze us with its capabilities to cache requests, edit headers before putting requests on the network etc.
I think you will agree that unit testing service workers is not straight-forward.
The biggest question is 'what to mock?'

A big shout out to Zack Argyle for writing Service Worker Mock. This library prepares all the mocks & lets your tests have an environment where you have the recipe to test your service worker.

Note

This code sample is an enhancement on top of Service Worker Mock. Service Worker Mock explains how to write unit tests for service works. Since it is not maintained any more, I am writing this code sample to unblock ourselves from the current issues in that library.
Tests are written using the sample service worker given at service worker example

Problem with the current version (2.0.5) of service worker mock

Object.assign(global, makeServiceWorkerEnv()) no longer puts EventTarget methods like addEventListener into the global scope because they are no longer "own" properties of ServiceWorkerGlobalScope

Workaround

Make addEventListener an enumerable property ```

beforeEach(() => {
const serviceWorkerEnv = makeServiceWorkerEnv();
Object.defineProperty(serviceWorkerEnv, 'addEventListener', {
value: serviceWorkerEnv.addEventListener,
enumerable: true
});
Object.assign(global, serviceWorkerEnv)
jest.resetModules();
});


### Testing Event registration

it('should add listeners', async () => {
require('../src/sample-sw');
await self.trigger('install');
expect(self.listeners.get('install')).toBeDefined();
expect(self.listeners.get('activate')).toBeDefined();
expect(self.listeners.get('fetch')).toBeDefined();
});


### Testing cache deletion on activation

it('should delete old caches on activate', async () => {
require('../src/sample-sw');

// Create old cache
await self.caches.open('OLD_CACHE');
expect(self.snapshot().caches.OLD_CACHE).toBeDefined();

// Activate and verify old cache is removed
await self.trigger('activate');
expect(self.snapshot().caches.OLD_CACHE).toStrictEqual({});
});


### Testing fetch event to see if it returns cached response

it('should return a cached response', async () => {
require('../src/sample-sw');

const response = await self.trigger('fetch', cachedRequest);
expect(response.data.key).toEqual('value');
});


### Testing if fetch event makes network call & updates cache. Also test any custom logic like appending a bearer token in the request

it('should fetch and cache an uncached request and append the right auth token in the header', async () => {
const mockResponse = { clone: () => { return { data: { key: 'value' } } } };
global.fetch = (response) => Promise.resolve({ ...mockResponse, headers: response.headers });

require('../src/sample-sw');

const request = new Request('/test');
const response = await self.trigger('fetch', request);
expect(response.clone()).toEqual(mockResponse.clone());

expect(response.headers.get('authorization')).toBe('Bearer my secret auth');

const runtimeCache = self.snapshot().caches.runtime;
expect(runtimeCache[request.url]).toEqual(mockResponse.clone());
});


### Testing if the requests to the external domains are ignored

it('should ignore the requests to external world', async () => {
const mockResponse = { clone: () => { return { data: { key: 'value' } } } };
global.fetch = (response) => Promise.resolve({ ...mockResponse, headers: response.headers });

require('../src/sample-sw');

const request = new Request('http://google.com');
const response = await self.trigger('fetch', request);
expect(response).not.toBeDefined();
});


## Coverage
<img src="https://raw.githubusercontent.com/gauravbehere/unit-test-service-worker/main/coverage.PNG"/>

## Epilogue
Check out the code repo for this sample here:
[unit-test-service-worker](https://github.com/gauravbehere/unit-test-service-worker)

Inversion of Control — A simple & effective design principle

Gaurav Behere — Sun, 17 Oct 2021 13:57:49 +0000

Reducing code complexity with IoC

Inversion of control (IoC)

If you have heard of dependency injection(DI) you have been using inversion of control but maybe not knowingly.
IoC is often seems used interchangeably with DI but IoC as a concept is much more than that.

IoC is a design principle that helps you in reducing the complexity of code that you may want to ship as a reusable component or a library.
DI is one of the patterns that help in implementing IoC.

Usually, we have seen libraries/components implementing all the features for us & expose APIs to be called in a certain way to get the functionality we need. We may call the same API with a different set of parameters & value combinations to get what we want.

There is a level of abstraction to us in a way that we need not bother about the library/component reusable code but we need to know the meaning of each option/parameter to be passed so that we can understand the API’s behavior better.

Now put yourself in the shoes of the guy who wrote that library or the reusable component.

There is n number of use cases that he needs to support out of the same piece of code. There can be different values of the parameters & different combinations of those which may result in the same API or component to behave differently.

What does this translate to in code?

Lots of IF ELSE statements

What does it lead to?

More cyclomatic complexity

Less maintainable code

Lengthier documentation about all the options & their combinations

Any new feature that our generic component now has to support will have to be done very carefully so that we don’t break any existing support.

When we refactor the code it is not easy to get away with any option or any conditional branch as we may not know who is consuming our component using that code flow.

All these are very usual problems we see almost every day, isn’t it? This is an ever-growing problem too as the request for new functionalities with more if-else will keep coming.
Let’s look at this piece of code to understand the problem better.

You are writing a function that does the sorting of an array:

const sortArray = (array) => array.sort();

At a very basic level, it just returns the native sort. This is not sufficient as it doesn’t work well with numbers & custom sort for objects, also the default order of sort would be ascending. Let's add these features one by one.

Let us add support for descending sort:

// order = 1 -> ascending
// order = 2 -> descending
const sortArray = (array, order=1) => {
  if(order === 1)
    return array.sort();
  else if(order === 2)
    return array.sort((a,b) => b - a);
  else
   console.error("Unsupported sort order provided")
}

Let us add support for sorting objects with a specified key:

// @param order(number) = 1 -> ascending
// @param order(number) = 2 -> descending
// @param objectSort(boolean) 
const sortArray = (array, objectSort, key, order=1) => {
  if(objectSort) {
    if(order === 1)
      return array.sort((a,b) => a[key] - b[key]);
    else if(order === 2)
      return array.sort((a,b) => b[key] - a[key]);
    else
     console.error("Unsupported sort order provided")
  }
  else {
    if(order === 1)
      return array.sort();
    else if(order === 2)
      return array.sort((a,b) => b - a);
    else
     console.error("Unsupported sort order provided")
  }
}

As you can see that addition of features is adding code paths & branches in our code. Now say we need to support a case insensitive sort based on an option & we want to keep all the undefined values at the start of the array, that too based on an option, how many more if-else do we need?

This list of features is ever-growing.

I took the example of sorting as a library function because the native sorting in JavaScript is also based on the principle of IoC.

Inversion of Control

As Wikipedia explains it:

A software architecture with this design inverts control as compared to traditional procedural programming: in traditional programming, the custom code that expresses the purpose of the program calls into reusable libraries to take care of generic tasks, but with inversion of control, it is the framework that calls into the custom, or task-specific, code.

In simple terms, in the inversion of control, the library or the reusable component lets the consumer take control of what the functionality is & it provides an abstraction on top of it.

Now imagine passing the sorting method as a parameter to the library & it actually invokes your own sorting method to do the sorting.

How does it help?

The extensibility of functionality is now independent of the code complexity in the library rather the consumer gets a handle to override the default behavior in its own way.

const sortArray = (array, sortFunction) => {
  if (sortFunction) {
    return array.sort(sortFunction);
  }
  return array.sort();
}

Testability: We can substitute the core functionalities with mocks during the testing.
Substitutability: We enable a plugin architecture that makes it easy for us to swap out plugins, and program against code that doesn’t yet exist. All we need to do to substitute the current dependency is to create a new one that adheres to the contract defined by the interface.
Flexibility: According to the “Open Closed Principle”, a system should be open for extension but closed for modification. That means if we want to extend the system, we need only create a new plugin in order to extend the current behavior.
Delegation: IoC is the phenomenon we observe when we delegate behavior to be implemented by someone else but provide the hooks/plugins/callbacks to do so. We design the current component to invert control to another one. Lots of web frameworks are built on this principle.

There are many real-life use cases where you would have seen IoC in action. A good example is a state reducer pattern.
React, rather than providing a complex way of managing your state, lets you do that with your own reducer function & lets you provide your reducer as a hook before rendering your components.

Dependency Injection in angular is also based on this principle. Dependency Injection (DI) is one of the implementations of IoC based on the composition of dependencies in the container (the library).

Hooks in React are based on the IoC too.

Conclusion

Though IoC is a good principle to follow & there is a large number of libraries following it, it should be a conscious decision to choose IoC. In case you are aware of all the possible functionalities & code branches, a non-inverted control would make the consumption of the library easier. If you dealing with unknown extensibilities, it would be recommended to implement an inverted control.

Re-architecting authentication with Service Workers

Gaurav Behere — Mon, 13 Sep 2021 06:06:42 +0000

A use case of changing the authentication mechanism of a web application without touching a lot of legacy codebase

Many times you would encounter situations where you have a legacy codebase in front of you which has been in the market for quite a while. It may be written in a technology that is seeing a downward trend in terms of popularity. You cannot make a change very easily in the architecture of such applications as the amount of risk, testing efforts & impact is huge.
Let me run you through such a use case where we recently had to change the authentication mechanism of an existing legacy web application from a JSP session & a cookie-based authentication mechanism to an MSAL (Microsoft Authentication Library) token-based authentication method.
What this essentially means is the login should grant a token to the web application acquiring the token using MSAL (react-msal) in our case & the same token should be used for making further calls to the server.
Read more about MSAL tokens here:
https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/acquire-token.md

Challenges

There are two challenges we are looking at:

Changes to the webserver: The web server should be able to authenticate our requests with the token that the client application is going to send as a bearer token.
Changes to the legacy UI code written in JSP: The amount of legacy code which is an amalgamation of many UI technologies where there are requests like POST from FORM submits, XHR calls, calls through native JS fetch, Jquery’s $.ajax & a bit of axios too. It becomes very hard to avoid changes in almost every part of the code & still get the new authentication mechanism working where every call to our server should have a bearer token attached to the HTTP header.

Adding to the complexity of the application, the code base grew up with a lot of acquisitions of companies adding to the integrations in the existing codebase. Thus the application grew horizontally in terms of technology over the last 10 years.

Also when you have such a legacy codebase, it becomes hard to keep the knowledge fresh. There are pieces of the code that developers might not have even looked at for a long long time. Touching such code may result in unaccounted for side effects as the application has a significant number of customers who are using different versions & flows of the application.

How can we have a centralized solution which avoids making changes to a lot of files?

Service workers & promises to the rescue.
We try to avoid changes in the front-end code updating the APIs to authenticate based on the incoming MSAL token.
The solution is to capture all the network calls originated from the web application & append a bearer token in the HTTP header in the request.

Take a hold of all the network calls generated by your web application using a service worker registered at the root of your web application.

self.addEventListener('fetch', (event) => {
  const token = "some dummy token"; // This needs to be requested from MSAL library

  // Responding with a custom promise
  const promise = new Promise((resolve, reject) => {
    // edit event.request & respond with a fetch of a new request with new headers
    let sourceHeaders = {};
    for (var pair of event.request.headers.entries()) {
      sourceHeaders[pair[0]] = pair[1];
    }
    const newHeaders = { ...sourceHeaders, 'Authorization': 'Bearer: '+ token };
    const newRequest = new Request(event.request, {headers: newHeaders}, { mode: 'cors' });
    resolve fetch(event.request);
  });

  event.respondWith(promise);
});

In the fetch event we need to respond with a new request that has HTTP headers we need. In the gist above, we are just adding a dummy auth token to the request. Here we do a couple of things:

a. We copy all the headers of the incoming request.
b. We create a new request with incoming headers & a new authorization header containing a token.

Now let us get the right token.

Here comes the tricky part. A service worker comes with its own limitations, it has no access to DOM & it can’t access shared storage between the page & itself. Somehow we need to get the token from the main thread & the container app.
Here is a good article explaining how to establish communication between a service worker & the container page.

https://felixgerschau.com/how-to-communicate-with-service-workers/

We choose the Broadcast API to get away with the need of the two parties to remember the ports to have a 1:1 communication channel.

// Create a channel for communication
const channel = new BroadcastChannel('TOKEN_EXCHANGE');

const getAToken = () => {
  const promise = new Promise((resolve, reject) => {
    // Listen to token response
    channel.onmessage = (e) => {
      resolve(e.data);
    };
    // Send a token request to the main thread
    channel.postMessage("TOKEN_REQUEST");
  });
  return promise;
}

Changes in the container app

The container app now needs to listen to the messages on the same broadcast channel & respond with a token.
This allows up to keep the front end legacy code as-is & at the same time have a new authentication mechanism.

Things to note

As our solution is based on service workers, promises & Broadcast API, browser compatibility can be a limitation.
We still had to re-factor the APIs to honor tokens in the request for authentication.

Must-Have Weapons in Your React Armory

Gaurav Behere — Mon, 13 Sep 2021 05:48:48 +0000

Weapons (tools) make a soldier (developer) effective. Advanced and effective weapons (tools) in your armory ensure you have the firepower to handle the complexity of an ever-growing code base.
Let’s look at a few of the tools I used in my last project. These tools helped me to write code quickly yet maintain quality.

React Dev Tools

Programming is 20% coding and 80% debugging. Debugging is what makes a programmer efficient in comparison to others.
React Developer Tools let you inspect a React tree, including the component hierarchy, props, state, and more. To get started, just open the React Developer Tools and switch to the React Components or React Profiler tab.
By selecting one of the components in the tree, you can inspect and edit its current props and state in the panel on the right. In the breadcrumbs, you can inspect the selected component, the component that created it, the component that created that one, and more.
React developer tools are available for Chrome and Firefox as an extension.

Styled Components

While styling components, we also have to take care of vendor prefixes for cross-browser operability. If we’re using LESS or SASS we have to compile code to CSS.
With a component being an individual entity and a basic building block for building apps, it’s recommended for styling to be included within the component, rather than the container app taking care of styling with class names.
Styled components allow us to keep the styles within the component, coupled with the JavaScript code.
Read about some more benefits here.

React-Intl

Having strings, a lot of text in the UI, and having to internationalize it can be painful at times. With the right translation based on browser locale or user preference, presenting the user interface in a different language can be tricky.
React-Intl handles it in an elegant way, wrapping your components in a scope and rendering strings based on the locale.
With support for formatting dates, numbers, plurals, etc out of the box, it makes handling such translations easy. Moreover, for a fully-fledged translation conversion, you can have translations based on languages you want to support and you can configure React-Intl to pick up the right translation file at runtime.
Read more here.

Storybook

Storybook allows you to write and test components in isolation.
When there are multiple people working on UI components that need integration at a later point in time, storybook makes it easier for individual developers to write and test their components in isolation.
Moreover, the storybook also serves as a living document of what has been done so far. You can look at all the components at a glance and check how they behave. You can play with a component by modifying supplied props and testing its behavior.
I may sound crazy if you’ve only worked with a smaller codebase but when projects grow, there are times when a developer ends up writing a component that already existed or a behavior variation of an existing component could have met the purpose. In such cases, the storybook acts as a go-to page to see what components & what behaviors already exist.
Check out how you can add stories to your components and make it available as a storybook, here.

React Testing Library

It comes last in this piece but this is the most important one and a lifesaver when testing React apps.
Based on this principle, and I quote the author,

The more your tests resemble the way your software is used, the more confidence they can give you.

The biggest confusion I have as a developer is when writing tests whether my suite is under mocked or over mocked. Am I testing with the right expectations?
React Testing Library comes up with guidelines about what should be tested, allowing us to test the DOM changes and updates as good as what the end-user will perceive.
Combine it with Jest and you get a robust set of APIs that you need to be able to render your components in isolation, mimic behavioral changes, and observe DOM changes.
Get started here.

I have listed the tools that have helped me. That said, there may be tools that have helped you, which you think are better than the ones I’ve listed. I’d love to hear about them.

JavaScript - All The Things, Mostly

Gaurav Behere — Wed, 01 Sep 2021 04:56:02 +0000

JavaScript - All The Things, Mostly

Curated list of awesome JS resources

Books

JavaScript: The Good Parts - Douglas Crockford
Programming JavaScript Applications - Eric Elliott
JavaScript: The Definitive Guide, 7th Edition - David Flanagan
Learning JavaScript Design Patterns - Addy Osmani
You Don't Know JS: ES6 & Beyond - Kyle Simpson
Exploring ES6 - Axel Rauschmayer
High Performance JavaScript - Nicholas C. Zakas
JavaScript for Kids - Nick Morgan
Eloquent JavaScript - Marijn Haverbeke
Effective JavaScript - David Herman

Video Tutorials
What the heck is the event loop anyway? | Philip Roberts | JSConf EU
JavaScript Tutorial for Beginners: Learn JavaScript in 1 Hour [2020]
JavaScript Tutorial for Beginners - Full Course in 8 Hours [2020]
Learning Functional Programming with JavaScript - Anjana Vakil - JSUnconf
JavaScript: The Good Parts
ES6 and Beyond Workshop Part 1 at PayPal (Jan 2017)
ES6 and Beyond Workshop Part 2 at PayPal (March 2017)
Jafar Husain: Async Programming in ES7 | JSConf US 2015
JavaScript: Understanding the Weird Parts - The First 3.5 Hours
Debugging The Web (Chrome Dev Summit 2016)
Rediscovering JavaScript by Venkat Subramaniam
Franziska Hinkelmann: JavaScript engines - how do they even? | JSConf EU
Recursion, Iteration, and JavaScript: A Love Story - Anjana Vakil | JSHeroes 2018
Learn JavaScript - Full Course for Beginners
Object-oriented Programming in JavaScript: Made Super Simple | Mosh

Courses
JavaScript Fundamentals Workshop
Learn JavaScript
The Complete JavaScript Course 2020
JavaScript Tutorials for Beginners
Getting Started With Javascript | Javascript Tutorial For Beginners
JavaScript Best Practices
JavaScript Tutorials and Courses

Useful Blogs/Articles
Prototypes and Inheritance in JavaScript
A Guide to Proper Error Handling in JavaScript
Service Workers: an Introduction
10 JavaScript concepts you need to know for interviews

Websites
Google Web Developers
ECMAScript 6
Node JS
MDN
JavaScript.info
Superhero.js

Dev Channels
JSConf
Google Chrome Developers
web.dev
JavaScript Daily

Publications/Magazines
JavaScript on Medium
JavaScript on Smashing Magazine
JavaScript on Dev.to
JavaScript Weekly
Node Weekly

Useful Github Links
33-js-concepts
JavaScript Questions
Front-end-Developer-Interview-Questions
es6-cheatsheet
clean-code-javascript

People
BrendanEich
Kent C. Dodds
Addy Osmani
Paul Irish
Douglas Crockford
Ben Awad
Eric Elliott
Dan Abramov
Marijn Haverbeke
Kyle Simpson
Wes Bos
Dan Wahlin

These resources have helped me a lot in keeping up with JS. If you have a suggestion, please comment. I would love to read & add to this.

DEV Community: Gaurav Behere

Time to say goodbye to Webpack?

Lets have a closer look at Vite

So what does Vite do to make the development experience better?

That essentially means no time spent on bundling your code before the server can start.

Awesome, so why bundle for production?

Getting started with Vite

Hot replacement of modules (HMR)

Recap

Server side rendering

So should we just move to Vite & stop using tools like Webpack?

Unit testing service workers

Prelude

Note

Problem with the current version (2.0.5) of service worker mock

Workaround

Inversion of Control — A simple & effective design principle

Reducing code complexity with IoC

Inversion of control (IoC)

What does this translate to in code?

What does it lead to?

Inversion of Control

How does it help?

Conclusion

Re-architecting authentication with Service Workers

Challenges

How can we have a centralized solution which avoids making changes to a lot of files?

Changes in the container app

Things to note

Must-Have Weapons in Your React Armory

React Dev Tools

Styled Components

React-Intl

Storybook

React Testing Library

JavaScript - All The Things, Mostly

JavaScript - All The Things, Mostly

Curated list of awesome JS resources

Books

Video Tutorials

Courses

Useful Blogs/Articles

Websites

Dev Channels

Publications/Magazines

Useful Github Links

People

Lets have a closer look at `Vite`

So what does `Vite` do to make the development experience better?

Getting started with `Vite`

So should we just move to `Vite` & stop using tools like Webpack?