DEV Community: Bhavuk kalra

Creating my own programming language from scratch - Day 1

Bhavuk kalra — Tue, 22 Apr 2025 13:13:13 +0000

Why create this series?

I guess whenever we launch series we should ask ourselves why that series was created in the first place and It could be any of the following things

There was a gap in the market, That you wanted to fix.
You wanted to do it because its your job of writing content
You see it as a notemaking exercise that you can look back later and revise.

For me its none of the above. I wanna expand this to a fully unfiltered guide on what my state of mind looks like and how it evolves after I have created my first language.

Also, Let's admit it has been always in the back of our mind to create our own programming language someday right, Ever since we started coding?

Initial Exploration

So we start with a simple youtube search first of all and we landed with a pretty good video(Its in hindi tho)

I made my own programming language

From here we got to understand the basics of what a components a programming language requires to function (and a refresher of my college course)

Lexer/Tokenizer (Converts the program into tokens)
Abstract Syntax Tree creator (Takes input of the tokens in the previous step and Creates a AST which holds the logical flow how the program should process the tokens step by step)
Code Generator (Takes the input of created AST and converts it into machine understandable language)
Code Runner (Runs the machine code generated in the previous step)

I am pretty sure of how I used the above layman terms to describe each component that is required by a programming language to run. They are all going to get their technical descriptions later on and maybe new components might get added as well.

Self study material

While looking for more material to study through on the internet I came across Robert Nystrom CRAFTING INTERPRETERS. So called the HOLY GRAIL OF HOW TO MAKE YOUR OWN PROGRAMMING LANGUAGE

Exactly what we needed!

Now we start reading this

Here is a summary of few pages down the line

Started Reading the Book

Here is what I got to know so far

The book is written to use Java, but there are open source implementations of the same java snippets provided by the community (I Love open source man 💕). We are going to use the Javascript and C++ implementations of the same
The author suggests to be versed with recursion, dynamic arrays, trees, graphs, and hash tables.
Now connecting the dots backwards, It seems like we don't need to implement the lexer from scratch these days for Javascript as there are already libraries for it such as Lex and Yacc, so-called compiler-compilers.
That automatically generate some of the source files for an implementation from some higher-level description.
(We'll explore on what that means exactly later I guess)
This is what will be covered in the book. We'll make Two interpreters

First Interpreter - Based on Java. Focuses on being correct to get the basics down.
Second Interpreter - Based on C. Builds upon on the previous implementation and focuses in being fast

The C interpreter will contain a compiler that translates Lox to an efficient bytecode representation, which it then executes. This is the same technique used by implementations of Lua, Python, Ruby, PHP, and many other successful languages. We’ll even try our hand at benchmarking and optimization

Everything we did in JAVA and took it for granted will be implemented from scratch (I am personally very excited about this). Such as Dynamic Arrays, Hash Tables and We'll also create our own Garbage Collector.

At the end we are given this assignment.

Assignment

Define a doubly linked list of heap-allocated strings. Write functions to insert, find, and delete items from it to get a practice of pointers and Test them.

So first off what are HEAP ALLOCATED STRINGS. A quick Chat GPT search gives us this -

char str[] = "hello";

Above is stack allocated string in C

STACK STRINGS

It's stored on the stack.
It has a fixed size and goes away when the function returns.

char *heapStr = malloc(strlen("hello") + 1);
strcpy(heapStr, "hello");
// Always free heap strings
free(heapStr);

// OR

char *heapStr = strdup("hello");
// Always free heap strings
free(heapStr);

strdup allocates memory and copies the string.

heapStr must be free()d when done to avoid memory leaks.

Now that we understood this. We can start implementing some of the components from day 2

Summary of Day 1

We started analyzing on what it takes to build a programming language from scratch. In that search we found that there are a few essential elements that needs to be in place before we starting working towards implementing interpreter such as Lexer, AST. I don't know about this stuff yet but I am sure we'll be just fine as we go along. For the time I'll be following the book by Robert Nystrom's CRAFTING INTERPRETERS

There he uses Java and C but I am gonna try to convert that to javascript. As in the end I wanna make a language which can be ran on a browser.

TODO Day 2

We are gonna implement the doubly linked list with basic functionalities such as insert, Delete, Find and Create i.e basic CRUD.

Also start with the actual implementation of the Interpreter.

Understanding Singleton Design Pattern with a Logger Example - Part 2

Bhavuk kalra — Wed, 16 Apr 2025 22:17:01 +0000

Continuing from where we left off: We successfully created a singleton class for Logger, exposing a static method getLogger for all users interacting with the class.

To quickly recap, our Logger class includes the following key features:

🔹 Direct instantiation of the Logger class is not allowed.

🔹 Custom error handling is implemented to prevent direct instantiation.

🔹 All users of the class use a common static getLogger method to obtain an instance.

However, the current implementation is not suitable for production usage, as it does not account for scenarios involving multithreading—i.e., it is not thread-safe. That’s exactly what we’ll address in this article.

Pre-Requisites

`threading` vs `multiprocessing` in python

🧵 Threading in Python

What is it?

Threading lets you run multiple threads (tiny workers) inside a single process 🧠. They all share the same memory, like roommates sharing a house 🏠.

💡 How it works:

🔹 All threads share the same memory space 🧠

🔹 Great for I/O-bound tasks 📡 (e.g., web requests, file reading/writing).

🔹 Controlled by the threading module 🧵

🧠 Key Concepts:

🔹 Threads = lightweight 🚴‍♂️

🔹 Memory is shared across threads 🏠

🔹 But… there’s a pesky thing called the GIL (Global Interpreter Lock) ⛔ that means only one thread runs Python code at a time, so no true parallelism 😢 (for CPU-heavy stuff).

✅ Pros:

🔹 Super fast to start ⚡

🔹 Low memory usage 🪶

🔹 Threads can easily share data 🧠

❌ Cons:

🔹 Can’t utilize multiple CPU cores because of the GIL 🚫🧠

🔹 Risk of bugs like race conditions and deadlocks 🕳️

🔥 Multiprocessing in Python

What is it?

Multiprocessing creates separate processes, each with its own memory, and they run truly in parallel 🚀 — like different computers working together 🤝

💡 How it works:

🔹 Uses the multiprocessing module 🛠️.

🔹 Every process has its own memory space 📦.

🔹 No GIL here — each process gets a core! 🧠🧠🧠

🧠 Best for:

🔹 CPU-bound tasks 🧮 – number crunching, data processing, machine learning, etc.

🔹 When you need real parallelism ⚙️⚙️⚙️

✅ Pros

🔹True parallelism 💥

🔹Perfect for CPU-heavy tasks 🧠💪

🔹No GIL = no problem 🚫🔒

❌ Cons

🔹 More memory usage 🧠💸

🔹 Slower to spin up ⚙️

🔹 Sharing data between processes is trickier 🧵➡️📦

Which one we would be using?

Looking at different options that we have available for us in python ofcourse we are gonna go with threading module as this a I/O usecase and we are not doing any heavy computation as well here.

Why is it not thread safe?

Referring to the diagram above. Imagine a scenario where there are two threads Thread 1 and Thread 2 both trying to access the getLogger in the intial phases of running an application i.e __loggerInstance is None

🔹 Thread 1 checks if cls.__loggerInstance is None — it is, so it proceeds.

🔹 Thread 2 runs at the exact same time, checks cls.__loggerInstance — still None, so it proceeds too.

Both threads call __new__() and __init__() → 🧨 Boom! Two instances created!

That’s called a race condition, and it can definitely happen in multithreaded environments.

🧪 How to Reproduce It

You could artificially slow down the instantiation to provoke the issue: For Re-Producing the issue we'll make these changes to our already existing codebase

📄 Logger.py

import time

class Logger:

    # private Static variable to track num of instances created
    __numInstances = 0

    # private static variable to denote if instance was created
    __loggerInstance = None

    def __new__(cls):
        # Private constructor using __new__ to prevent direct instantiation
        raise Exception("Use getLlogger() to create an instance.")


    def __init__(self):
        Logger.__numInstances = Logger.__numInstances + 1
        print("Logger Instantiated, Total number of instances - ", Logger.__numInstances)

    def log(self, message: str):
        print(message)

    @classmethod
    def getLogger(cls):
        # Returns the singleton instance, creates one if it doesn't exist
        if cls.__loggerInstance is None:

            time.sleep(0.1)  # Simulate delay

            # Bypass __new__ and directly instantiate the class
            cls.__loggerInstance = super(Logger, cls).__new__(cls)

             # Trigger __init__ manually on first creation
            cls.__loggerInstance.__init__()

        return cls.__loggerInstance

📄 main.py

from user1 import doProcessingUser1
from user2 import doProcessingUser2
import threading
import multiprocessing


if __name__ == "__main__":

    t1 = threading.Thread(target=doProcessingUser1)
    t2 = threading.Thread(target=doProcessingUser2)

    t1.start()
    t2.start()

    t1.join()
    t2.join()

    print("All threads finished")

Added time.sleep(0.1) to simulate delay while executing the getLogger function.

Output (and we got a race condition)

Logger Instantiated, Total number of instances -  1
Log from the second user
Logger Instantiated, Total number of instances -  2
Log from the first user
All threads finished

✅ How to Make It Thread-Safe

Use a threading.Lock to synchronize access to the singleton logic. Let's make these changes then we'll discuss on what we have edited so far.

📄 logger.py

import time
import threading

class Logger:

    # private Static variable to track num of instances created
    __numInstances = 0

    # private static variable to denote if instance was created
    __loggerInstance = None

    __mutexLock = threading.Lock()  # For thread-safe singleton creation (private static)

    def __new__(cls):
        # Private constructor using __new__ to prevent direct instantiation
        raise Exception("Use getLlogger() to create an instance.")


    def __init__(self):
        Logger.__numInstances = Logger.__numInstances + 1
        print("Logger Instantiated, Total number of instances - ", Logger.__numInstances)

    def log(self, message: str):
        print(message)

    @classmethod
    def getLogger(cls):
        # Returns the singleton instance, creates one if it doesn't exist

        with cls.__mutexLock:

            if cls.__loggerInstance is None:

                time.sleep(0.1)  # Simulate delay

                # Bypass __new__ and directly instantiate the class
                cls.__loggerInstance = super(Logger, cls).__new__(cls)

                # Trigger __init__ manually on first creation
                cls.__loggerInstance.__init__()

        return cls.__loggerInstanc

Here we have added these things

🔹 private static variable __mutexLock for letting only one thread i.e Thread 1 or Thread 2 to access the getLogger function.

🔹 with cls.__mutexLock:

👉 What this does:
The with statement automatically acquires the lock when the block starts ✅

And then it automatically releases the lock once the block is exited (even if an exception happens!) 🔓

So technically, the lock is being released as soon as the indented block under with is done.

✅ So no need to manually call .acquire() or .release() — the with block takes care of it cleanly and safely 🙌

Here is a diagramatical representation of how this helps us in avoiding the original race condition that we faced earlier

🧵 Thread 1 and Thread 2 Execution Flow

🟩 Thread 1 (Left side of the diagram):
Calls getLogger()
→ Thread 1 wants the logger instance.

Acquires the lock 🔐
→ Since it's the first thread in, it grabs the lock on __mutexLock.

Executes getLogger()
→ Sees __loggerInstance is None, creates the singleton logger instance.

Releases the lock 🔓
→ Done with critical section, allows other threads to enter.

🟦Thread 2 (Right side of the diagram):
Also calls getLogger() at (roughly) the same time

Waits for the lock ⏳
→ It hits the lock, but Thread 1 already has it.

Still waiting... 😬
→ Thread 1 is doing its thing. Thread 2 just chills here.

Acquires lock (after Thread 1 releases) ✅
→ Now Thread 2 gets access to the critical section.

Executes getLogger()
→ But this time, it sees __loggerInstance is NOT None, so it just returns the existing logger!

✅ How This Prevents a Race Condition:

Without the lock:

Both threads could simultaneously check __loggerInstance is None, and both might try to create it at the same time → ❌ Multiple instances (race condition!).

With the lock:

Only one thread enters the critical section at a time, ensuring only one logger instance is ever created.

Final output

Logger Instantiated, Total number of instances -  1
Log from the first user
Log from the second user
All threads finished

Now as expected we only see one instance of the class gets instantiated, even in multi threaded environments

One last optimization

This optimization is based on the fact that the usage of locks is expensive on the process. So we are gonna use it smartly.

Notice one little small detail about our current getLogger function

def getLogger(cls):
        # Returns the singleton instance, creates one if it doesn't exist

        with cls.__mutexLock:

            if cls.__loggerInstance is None:

                time.sleep(0.1)  # Simulate delay

                # Bypass __new__ and directly instantiate the class
                cls.__loggerInstance = super(Logger, cls).__new__(cls)

                # Trigger __init__ manually on first creation
                cls.__loggerInstance.__init__()

        return cls.__loggerInstance

In the current implementation, we're acquiring a lock on every call to the getLogger function, which is inefficient.

However, locking is only necessary at the start of the program. Once the __loggerInstance is set, any subsequent threads that access the getLogger function won't create new instances—they'll simply receive the existing one.

To optimize this, we'll add a small check before acquiring the lock to ensure it's only used during the initial instantiation.

def getLogger(cls):
        # Returns the singleton instance, creates one if it doesn't exist
        if cls.__loggerInstance is None:  # 🚀 Quick no-lock check

            with cls.__mutexLock:

                if cls.__loggerInstance is None:

                    time.sleep(0.1)  # Simulate delay

                    # Bypass __new__ and directly instantiate the class
                    cls.__loggerInstance = super(Logger, cls).__new__(cls)

                    # Trigger __init__ manually on first creation
                    cls.__loggerInstance.__init__()

        return cls.__loggerInstance

We added the above condition if cls.__loggerInstance is None: to check if we are at the starting stages of the execution and then only acquire the lock to instantiate the class.

This type of locking is called Double-Checked Locking Pattern

🪄 Why this is better:

Most of the time (after the logger is created), the method will skip the lock completely 🙌

Locking only happens once, during the first initialization

Still 100% thread-safe ✅

as tested by the below response from main.py

Logger Instantiated, Total number of instances -  1
Log from the first user
Log from the second user
All threads finished

Which is exactly the same that we got earlier

Closing 🚀

This is the ending of a short two part series on single ton design pattern. Here is the summary of what we covered in these two parts

🔹 🧱 Base Logger Setup & Instance Tracking: Implemented a basic Logger class, observed that multiple instances were created when used in different files, and added a static variable to track instance count.

🔹 🔁 Converted Logger to Singleton: Restricted direct instantiation using __new__, implemented a getLogger() method to return a shared instance, ensuring only one Logger is created and reused across the application.

🔹 🧵 (Thread-Safety): Highlighted the potential issue of multiple instances being created in a multithreaded environment and introduced the need for locks to make the Singleton thread-safe.

🔹 Built a Thread-Safe Singleton Logger Class: Enhanced the original singleton pattern using threading.Lock to ensure only one instance is created even in multithreaded environments, preventing race conditions.

🔹 🔍 Explained Threading vs Multiprocessing in Python: Covered key differences, pros/cons, and why threading is the right choice here (I/O-bound task, not CPU-heavy).

🔹 🧠 Applied Double-Checked Locking Optimization: Improved performance by avoiding unnecessary locking after the logger instance is initialized, maintaining thread safety with better efficiency.

About me ✌️

Socials 🆔

Understanding Singleton Design Pattern with a Logger Example - Part 1

Bhavuk kalra — Fri, 04 Apr 2025 11:42:37 +0000

Written by Bhavuk Kalra✏️

In this post, we will explore how the Singleton design pattern is implemented in code and demonstrate one of its most common use cases: a Logger.

Why is a Logger a Singleton?

A logger should have a single instance that is shared across all files in an application. This ensures that all logs are stored in one place, making debugging and tracking events easier.

Project Overview

Let's consider a real-world scenario where we have two different files performing separate tasks, but both need to log information. To achieve this, we will create a Logger class that follows the Singleton pattern, ensuring that all logs are written to the same instance.

Project Structure

Our project will consist of three main files:

logger.py – This file will contain the Singleton Logger class.
user1.py and user2.py – These files represent different parts of the application that will use the logger.
main.py – This file acts as the central server, calling user1.py and user2.py to execute their respective processes.

After setting up, the directory structure will look like this:

└── root/
    ├── user1.py
    ├── user2.py
    ├── logger.py
    ├── main.py

In the next steps, we will implement the Singleton pattern for our logger and see it in action.

Boilerplate Code

Now, let's set up the basic functionality of our project. We'll define the Logger class and ensure that all logs are recorded using a single instance.

Setting Up the Logger

We’ll start by defining the Logger class in logger.py. This class will ensure that only one instance exists throughout the application.

📄 `logger.py`

class Logger:
    def __init__(self):
        print("Logger Instantiated")

    def log(self, message: str):
        print(message)

Using the Logger in Different Files

Both user1.py and user2.py will import and use the Logger class to log messages corresponding to two different processes.

📄 `user1.py`

from logger import Logger

def doProcessingUser1():
    loggerUser1 = Logger()
    loggerUser1.log("Log from the first user")

📄 `user2.py`

from logger import Logger

def doProcessingUser2():
    loggerUser1 = Logger()
    loggerUser1.log("Log from the second user")

Entry Point:

📄 `main.py`

from user1 import doProcessingUser1
from user2 import doProcessingUser2


if __name__ == "__main__":
    doProcessingUser1()
    doProcessingUser2()

Lets run the main.py file to check if our base setup is working.

`Output`

Logger Instantiated
Log from the first user
Logger Instantiated
Log from the second user

Logger Functionality 📝

For our Logger, we need to ensure:

🔹 Single Instance: Only one instance of the Logger class exists throughout the project.
🔹 Restricted Instantiation: Other processes must not create additional instances of the Logger.

With this setup, all logs will be managed by a single, central Logger instance, ensuring consistency and efficiency! 🚀

Tracking Logger Instances for Debugging 🧐

To ensure that our Singleton implementation is working correctly, we will track how many instances of the Logger class have been created. This will help us debug and verify that only one instance is used throughout the application.

How Will We Track Instances? 📊

🔹 Use a Static Variable – This will keep track of the number of instances created.
🔹 Why a Static Variable? – Unlike instance variables (which belong to a specific object), static variables belong to the class itself and are shared across all instances.

Implementing Instance Tracking 🔍

1️⃣ Add a static variable to count the number of instances created.
2️⃣Update the constructor to increment this counter whenever a new instance is attempted.
3️⃣ Log the instance count for verification.

With these changes, we’ll be able to confirm whether our Singleton pattern is correctly restricting multiple instances! 🚀

Since our Logger class should ideally have only one instance, we will implement functionality to print how many instances have been created. This will help us verify that the Singleton pattern is correctly enforced.

Updating the Codebase 🛠️

We implement a static counter belonging to a specific class and shared across all instances.

📄 `logger.py`

class Logger:

    # private Static variable to track num of instances created
    __numInstances = 0

    # private:


    def __init__(self):
        Logger.__numInstances = Logger.__numInstances + 1
        print("Logger Instantiated, Total number of instances - ", Logger.__numInstances)

    def log(self, message: str):
        print(message)

We have now introduced a static variable numInstances to keep track of how many instances of the Logger class have been created across the codebase.

Lets run the main.py to see if what we get

📄 `output`

Logger Instantiated, Current number of instances -  1
Log from the first user
Logger Instantiated, Current number of instances -  2
Log from the second user

which is an expected output as we are here creating two instances of Logger class in two different files namely user1.py and user2.py.

Converting to a Singleton Design Pattern 🏗️

To implement the Singleton design pattern for our Logger, we need to ensure that only one instance of the class is created and shared across the entire application.

Steps to Implement Singleton ✅

1️⃣ Make the Constructor Private

Prevents the creation of new instances directly.

2️⃣ Create a Static Instance

Stores the single instance of the class.
Ensures all users access the same instance.

3️⃣ Provide a Static Method for Access

This method will instantiate the static instance if it hasn’t been created yet.
All users will access the same instance through this method.

Implementation 🛠️

Making the constructor private 🔐

Since the constructor is private, no one can create multiple instances of the class. However, we still need at least one instance that other users can access, right?

What we can do is create a static function that returns the instance of the Logger class.

(Read that again if you have to so that you make sense of it)

Since Python is a very flexible language, we can't directly make a class constructor private like in C++ or Java.

Instead, we will use Name Mangling to achieve this.

Using `new` with Name Mangling

The __new__() method is called before __init__() and controls the instance creation.

By altering __new__ method we are going to restrict the access to the __init__ method. Raising an error every time a method tries to directly instantiate it.


class Logger:

    # private Static variable to track num of instances created
    __numInstances = 0

    # private static variable to denote if instance was created
    __loggerInstance = None

    def __new__(cls):
        # Private constructor using __new__ to prevent direct instantiation
        raise Exception("Use getLlogger() to create an instance.")


    def __init__(self):
        Logger.__numInstances = Logger.__numInstances + 1
        print("Logger Instantiated, Total number of instances - ", Logger.__numInstances)

    def log(self, message: str):
        print(message)

    @classmethod
    def getLogger(cls):
        # Returns the singleton instance, creates one if it doesn't exist
        if cls.__loggerInstance is None:
            # Bypass __new__ and directly instantiate the class
            cls.__loggerInstance = super(Logger, cls).__new__(cls)

             # Trigger __init__ manually on first creation
            cls.__loggerInstance.__init__()

        return cls.__loggerInstance

We use the @classmethod decorator to pass the caller class (cls) into the function. This makes our code safer in cases of inheritance and polymorphism.

Understanding `super(Logger, cls)` 🔄

super(Logger, cls) returns a proxy object that allows access to the parent class methods.

🔹 Logger – The current class where we start the lookup.
🔹 cls – The class whose instance we want to create.
🔹 This ensures that if we use inheritance, Python creates an instance of the correct class.

How super(Logger, cls).new(cls) Works ⚙️

🔹 __new__(cls) is a special method that creates a new instance of a class before initializing it.
🔹 Python looks for the parent class of Logger (which is object).
🔹 It then calls object.__new__(cls), ensuring that an instance of cls (either Logger or a subclass) is created properly.

This approach keeps our Singleton pattern safe and flexible when used with inheritance!

📄 `user1.py`

from logger import Logger

def doProcessingUser1():
    loggerUser1 = Logger.getLogger()
    loggerUser1.log("Log from the first user")

📄 `user2.py`

from logger import Logger

def doProcessingUser2():
    loggerUser1 = Logger.getLogger()
    loggerUser1.log("Log from the second user")

Output

Logger Instantiated, Total number of instances -  1
Log from the first user
Log from the second user

🔍 Observe the Singleton in Action

Even with two getLogger() calls, we still have only one instance of the Logger class being used. ✅

🚫 What Happens if Someone Tries to Instantiate the Logger?

Now that we have restricted direct instantiation, let’s imagine a scenario where a user tries to create a new instance manually.

To test this, we will modify our code and see what happens when someone attempts to instantiate the Logger class directly. 🛠️

📄 `user1.py`

from logger import Logger

def doProcessingUser1():
    loggerUser1 = Logger()
    loggerUser1.log("Log from the first user")

We get this error, which is our custom exception.

raise Exception("Use getLlogger() to create an instance.")

✅ First Step of the Singleton Pattern Completed!

But are we completely done? No! 🚫

⚠️ What’s the Next Challenge? (Hint: Multi-threading) 🧵

Our current implementation is not thread-safe.

🧐 What’s the Problem?

Imagine a scenario where two threads call getLogger() at the same time:

🔹 Both threads check if __loggerInstance is None.
🔹 Since both see it as None, they both try to create an instance.
🔹 As a result, two instances of Logger are created— **breaking **our Singleton pattern! ❌

🔒 Next Step: Making the Code Thread-Safe

In the next part, we will:

✔️ Explore different approaches to handling multi-threading.
✔️ Identify corner cases to watch out for.
✔️ Learn how to use mutex locks efficiently to prevent race conditions.

Stay tuned as we enhance our Singleton implementation! 🚀

All this good stuff in the part 2 of this tiny two part series on Singleton Design Pattern

About me ✌️

Socials 🆔

⚛️How to create a React Web Application without create-react-app CLI

Bhavuk kalra — Thu, 11 Apr 2024 12:21:59 +0000

In this post we'll build a React web application using webpack, Babel, React, and React DOM without relying on create-react-app

❓What is create-react-app

create-react-app is a CLI provided by facebook to make it easier for users to get started building with React.

It is ideal for beginners to run a single command to get your environment ready to get started, but it has two major flaws

It restricts customization for build configuration. For example you might want to use SWC (Speedy Web Compiler) for your deployment pipeline instead of pre-installed Babel for compilation of JS/TS codebase.
It abstracts a lot of the inbuilt tools that makes React functional like processes of Transpilation, Minification, Bundling which one should know about while making Web applications

ℹ️ Some Terminologies

Transpiler - Converts one form of JS code to another form of JS code. Convert ES6(ECMA Script 2015) into code that browsers can understand. Example Babel
Module Bundler - Takes different files HTML,JS, Style Sheets(CSS). And bundles them into a single file. Helps managing dependencies relations (Including loading modules in correct order), To improve performance, To organize your code, To reduce the number of HTTP requests Example Webpack, Parcel, and Rollup.
Minification - The process of removing unnecessary characters from programming languages or markup languages without changing its functionality. It is also known as minimization. Minification can include: Removing whitespace, Removing comments, Removing semicolons, Using shorter variable and function names, and Removing unused code.

🛠️ Tools used

Babel - A transpilerthat converts JSX -> JS, JS(ES6) -> JS(ES5)
Webpack - A module bundler. Converts all assets to single file which is code optimized, minified.

This combination allows developers to write code using the latest language features and ensure it's efficiently packaged for deployment.

❓Why use so many tools required to run react locally

Before we start with the walkthrough there is one important question we need to answer

why do we need these specific tools such as vite or node(npm) to run React locally. Why can't we just use normal HTML, CSS and JS?

As we use JSX(Javascript XML) syntax very frequently which can't be understood by the browser. We need the presence of special build tools (Here Babel for Transpiling JSX into JS)

/*
Function returning an HTML tag giving an error.
For using this type of syntax inside react we need a 
special build tool Babel (a Transpiler)
*/

function test(){
    return(
        <div>
            <h1>Hello world!</h1>
        </div>
    )   
}

Output -

For converting JS files using the syntax of JSX to the files that can be understood by the browser,

We need special setup like Vite etc (Includes Build tools which Transforms and optimizes code eg remove unnecessary whitespaces, Handles imports etc)

Note🗒️

You can skip the setup of having build tools by not using JSX syntax. You can use React without JSX if you don't want to set up compilation in your build environment. However Writing React without JSX can be more verbose than writing React with JSX.

We have built our base fundamentals and answered some cruicial questions. Now we are ready to start coding ⌨️

Lets start coding 🖮

Open your terminal and run the following commands in order as they appear.

npm init -y

Initiates the NPM project with default configs

npm i react

Install the React library (Ofcourse)

npm i react-dom

This package acts as a glue between React and the webpages DOM. DOM is just a programming Interface for webpages. To know more about on what is it and how its useful in web-dev click here MDN DOM

🧊 Install webpack and its dependencies

npm i webpack --save-dev

Install our module bundler webpack. Only needed as a dev dependency and not while our app is running on production.

npm i webpack-cli --save-dev

Provides a faster way to initialize and configure a webpack project through the cli. (Also watches for file changes).

npm i webpack-dev-server --save-dev

A utility complementing webpack. Provides a single line to setup a Live reload dev server using webpack.

npm i html-webpack-plugin --save-dev

Simplifies HTML file creation to serve our webpack bundles. Assists with adding our bundled files to index.html file.

🅱️ Install Babel and its utilities

npm i @babel/core --save-dev

The main core babel transpiler

npm i babel-loader --save-dev

Loader - Is what webpack uses to handle and process different file types. It dictates how certain file types are processed as they are imported into the project.

In this case transpile the js files from ES6 to ES5 before minifying them

As there are different files hence there are difference loaders

For example

babel-loader - For JS files. This package allows transpiling JavaScript files using Babel and webpack.
sass-loader - Transpiles SAAS files to css
style-loader - style-loader takes CSS you've imported in your JavaScript files, and injects them as Style tags into the DOM. It's particularly useful for inlining Critical CSS into the Head tag of your page.

npm i @babel/preset-react --save-dev

Preset is a set of plugins that support language features. By default Babel has the plugin ES2015 which add support for ES5 javascript

preset-react - Adds support for JSX(Javascript XML)

npm i @babel/preset-env --save-dev

preset-env is a smart preset that allows you to use the latest JavaScript without needing to micromanage which syntax transforms (and optionally, browser polyfills) are needed by your target environment(s). This both makes your life easier and JavaScript bundles smaller!

Contents of `package.json` After installing all modules.

{
  "name": "create-react-app",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "react": "^18.2.0",
    "react-dom": "^18.2.0"
  },
  "devDependencies": {
    "@babel/core": "^7.24.4",
    "@babel/preset-env": "^7.24.4",
    "@babel/preset-react": "^7.24.1",
    "babel-loader": "^9.1.3",
    "html-webpack-plugin": "^5.6.0",
    "webpack": "^5.91.0",
    "webpack-cli": "^5.1.4",
    "webpack-dev-server": "^5.0.4"
  }
}

Your installed versions might be different(higher) if you are following this at a later time.

After the above steps your directory structure should look like this.

└── root/
    ├── node_modules/
    ├── package.json
    ├── package-lock.json

Configure Webpack ⚒️

Create webpack.config.js in the root directory and add the following content

const path = require("path");
// For injecting the generated minified bundle.js to the index.html
const HTMLWebPackPlugin = require("html-webpack-plugin");

module.exports = {
  entry: "./src/index.js",
  output: {
    path: path.join(__dirname, "/dist"),
    filename: "bundle.js",
  },

  plugins: [
    new HTMLWebPackPlugin({
      template: "./src/index.html",
    }),
  ],

  module: {
    rules: [
      {
        test: /.js$/,
        exclude: /node_modules/,
        use: {
          loader: "babel-loader",
          options: {
            presets: ["@babel/preset-env", "@babel/preset-react"],
          },
        },
      },
    ],
  },
};

entry- Essentially tell webpack which file to use as as the root to create a dependency graph. used to resolve modules which are dependent on one another and also building the modules in order (For example build those modules first which are required as a dependency by other modules)
output - As webpack is a module bundler. It takes in a group files and outputs a smaller minified group of files. We need to specify the final output javascript file name and its path that will be generated by webpack
module - Informs webpack what kind of loader we'll be using. It holds the information on how the different kind of modules will be treated.
rules - Informs webpack that we'll be using 'BABEL' to transpile our js files.
test - Which files would be covered under this rule. It's stated by the regex /.js$/ i.e all files with extension js.
exclude - Excludes node_modules from transpilation process. If we don't exclude those, Otherwise it Makes the process slower and also we don't need to transpile those as they are mostly already minified. Only under very specific conditions we want to transpile some of the node_modules but not in this case.
use - Specifies the babel-loader' that would be used for transpiling.
options - Specifies the presets which would extend the loaders ability to intake JSX and ES6 syntax

👓 Current directory structure

└── root/
    ├── node_modules/
    ├── package.json
    ├── package-lock.json
    ├── webpack.config.js

✍️ Create the files required

Create index.js(root for webpack to create a dependency graph) in the src folder and add the contents.

import React from "react";
import ReactDOM from "react-dom";
// Get the component from the file to be rendered (Will be created later)
import App from './components/App'

// Get root id from index.html (will be created later)
ReactDOM.render(<App />, document.getElementById("root"));

Create a folder components inside src and a file App.js to store the component that will be rendered in root div

import React, { Component } from "react";

/*
Extending the Component class gives us access to its life-cycle method one of which is render
*/
class App extends Component {
    render() {
        return(
            <div>
                <h1>Hello world!</h1>
            </div>
        )  
    }
}

export default App;

Inside the src folder create 'index.html'

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
</head>
<body>

    <!-- Where are react component will be renderer -->
    <div id="root"></div>

</body>
</html>

👓 Current directory structure

└── root/
    ├── node_modules/
    ├── package.json
    ├── package-lock.json
    ├── webpack.config.js
    ├── src/
    │   ├── components/
    │   |    ├── App.js
    |   ├── index.html
    |   ├── index.js

➕ Add scripts to package.json

"start": "webpack-dev-server --mode development --open --hot"

we are using webpack-dev-server for live reload. It provides a fast in-memory access to the webpack assets to accomplish this.

Flags

--mode development - Enable production optimizations or development hints.
--hot - Enables Hot Module Replacement(HMR).It exchanges, adds, or removes modules while an application is running, without a full reload
--open - Open the application in a new tab

"build": "webpack --mode production"

It will create a production build for us to deploy. Bundle and minify all our js in bundle.js located on a folder dist.

The HTMLWebpackPlugin will inject our output bundle.js in index.html

Final content for `package.json`

{
  "name": "create-react-app",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "start": "webpack-dev-server --mode development --open --hot",
    "build": "webpack --mode production"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "react": "^18.2.0",
    "react-dom": "^18.2.0"
  },
  "devDependencies": {
    "@babel/core": "^7.24.4",
    "@babel/preset-env": "^7.24.4",
    "@babel/preset-react": "^7.24.1",
    "babel-loader": "^9.1.3",
    "html-webpack-plugin": "^5.6.0",
    "webpack": "^5.91.0",
    "webpack-cli": "^5.1.4",
    "webpack-dev-server": "^5.0.4"
  }
}

♾ Run the scripts

To start a development live reload server

npm run start

Logs

Output

Try it on your own

Make an edit to index.html and change its contents from "Hello World!" to "Hello Dev.to!". Save the file and see if the page gets updated as soon as you save your file. This is Hot Reload provided by the module webpack-dev-server

npm run build

It will create a dist production build folder with minified bundle.js generated by webpack and index.html (Already injected with bundle.js thanks to the module html-webpack-plugin)

👓 Current directory structure

└── root/
    ├── dist/
    |   ├── index.html
|   |   ├── bundle.js
    ├── node_modules/
    ├── package.json
    ├── package-lock.json
    ├── webpack.config.js
    ├── src/
    │   ├── components/
    │   |    ├── App.js
    |   ├── index.html
    |   ├── index.js

EXTRAS

Why use require("path") which is a Node function inside frontend development?

If you try to run const fs = require("fs") on browser it will throw an error. meaning its a Node enabled function.

Its a common practice in the development cycle. Whenever there is a need for local control(BUT ONLY DURING THE DEVELOPMENT PROCESS) for handling local files, paths, creating servers locally to enable faster development. We use local Node runtime environment(Which also uses JS as coding language).

Node version?

This tutorial was made on node version 20.12.2 LTS

Closing✌️

Thanks for reading it thus far. This is my first time publishing to dev.to. Got recommended this website by a fellow developer, Let's see how it goes.

About me

Socials 🆔

DEV Community: Bhavuk kalra

Creating my own programming language from scratch - Day 1

Why create this series?

Initial Exploration

Self study material

Started Reading the Book

Assignment

Summary of Day 1

TODO Day 2

Understanding Singleton Design Pattern with a Logger Example - Part 2

Pre-Requisites

threading vs multiprocessing in python

🧵 Threading in Python

What is it?

💡 How it works:

🧠 Key Concepts:

✅ Pros:

❌ Cons:

🔥 Multiprocessing in Python

What is it?

💡 How it works:

🧠 Best for:

✅ Pros

❌ Cons

Which one we would be using?

Why is it not thread safe?

🧪 How to Reproduce It

📄 Logger.py

📄 main.py

Output (and we got a race condition)

✅ How to Make It Thread-Safe

📄 logger.py

🧵 Thread 1 and Thread 2 Execution Flow

✅ How This Prevents a Race Condition:

Final output

One last optimization

🪄 Why this is better:

Closing 🚀

About me ✌️

Understanding Singleton Design Pattern with a Logger Example - Part 1

Why is a Logger a Singleton?

Project Overview

Project Structure

Boilerplate Code

Setting Up the Logger

📄 logger.py

Using the Logger in Different Files

📄 user1.py

📄 user2.py

Entry Point:

📄 main.py

Output

Logger Functionality 📝

Tracking Logger Instances for Debugging 🧐

How Will We Track Instances? 📊

Implementing Instance Tracking 🔍

Updating the Codebase 🛠️

📄 logger.py

📄 output

Converting to a Singleton Design Pattern 🏗️

Steps to Implement Singleton ✅

Implementation 🛠️

Making the constructor private 🔐

Using __new__ with Name Mangling

Understanding super(Logger, cls) 🔄

How super(Logger, cls).new(cls) Works ⚙️

📄 user1.py

📄 user2.py

🔍 Observe the Singleton in Action

🚫 What Happens if Someone Tries to Instantiate the Logger?

📄 user1.py

✅ First Step of the Singleton Pattern Completed!

⚠️ What’s the Next Challenge? (Hint: Multi-threading) 🧵

🧐 What’s the Problem?

🔒 Next Step: Making the Code Thread-Safe

About me ✌️

⚛️How to create a React Web Application without create-react-app CLI

❓What is create-react-app

ℹ️ Some Terminologies

🛠️ Tools used

`threading` vs `multiprocessing` in python

📄 `logger.py`

📄 `user1.py`

📄 `user2.py`

📄 `main.py`

`Output`

📄 `logger.py`

📄 `output`

Using `new` with Name Mangling

Understanding `super(Logger, cls)` 🔄

📄 `user1.py`

📄 `user2.py`

📄 `user1.py`

Contents of `package.json` After installing all modules.

Final content for `package.json`