Forem: Abhinav Sharma

Mastering Ownership in Rust: How Variables Define Memory Safety

Abhinav Sharma — Sat, 22 Nov 2025 14:33:35 +0000

As a frontend developer, I’ve spent most of my time working with JavaScript and TypeScript—where variables are flexible, memory management is automatic, and “undefined” is just part of life. But when I started exploring Rust, I quickly realised how different the concept of a variable can be when memory safety is a core design principle rather than an afterthought.

In JavaScript, declaring a variable with let or const feels simple: you store a value, reuse it, and rely on the garbage collector to clean things up later. Rust, on the other hand, challenges this comfort zone. Every variable in Rust is tied to a set of strict yet elegant rules — about ownership, borrowing, and lifetimes — that ensure memory is handled safely and predictably without a garbage collector.

At first, Rust’s compiler felt overly strict. It refused to let me do things JavaScript would easily allow. But the more I coded, the more I realised these “restrictions” are actually guarantees — preventing entire classes of runtime errors before the program even runs. In this article, I’ll share what I learned while transitioning from JavaScript’s flexible variable system to Rust’s ownership-driven model, and how it reshaped the way I think about data, memory, and safety in programming.

Types of Memory in Rust

*Before understanding how ownership works, it’s important to know *where Rust stores data. Like most systems programming languages, Rust primarily uses two types of memory: the **stack and the heap. Each has different characteristics and plays a key role in how Rust manages data safely without a garbage collector.

1. Stack Memory

The stack is a region of memory that stores data in a Last-In, First-Out (LIFO) manner.

It’s fast, predictable, and automatically cleaned up when a variable goes out of scope.

Data stored on the stack must have a fixed size known at compile time.
Primitive types like integers, floats, and booleans are stored here.

Function calls and local variables are also managed in the stack.

fn add(a: i32, b: i32) -> i32 {
    let sum = a + b;  // stored in stack frame of `add`
    sum
}

fn main() {
    let x = 10;       // stored in stack frame of `main`
    let y = 20;       // stored in stack frame of `main`
    let result = add(x, y);  // `add` frame pushed onto stack
    println!("{}", result);
}

2. Heap Memory

The heap is where data of unknown or dynamic size lives.

It’s more flexible but slightly slower to access compared to the stack.

Used for values whose size can change or isn’t known at compile time.
Data is allocated using pointers, and ownership determines who’s responsible for freeing it.
Common examples include String and Vec.

fn main() {
    let s = String::from("Rust");
}

Ownership Rules:

Rust's ownership system is built on three fundamental rules that the compiler enforces at compile time:

The Three Rules

Each value in Rust has a single owner
There can only be one owner at a time
When the owner goes out of scope, the value is dropped

Borrowing & References:

What Is Ownership?

Ownership defines who is responsible for a piece of data and when that data will be freed from memory.

fn main() {
    let s1 = String::from("Rust");
    let s2 = s1;          // ownership moved
    println!("{}", s1);   // ❌ ERROR: s1 no longer owns the data
}

📌 Ownership transfers responsibility for the value.

What Is Borrowing?

Borrowing lets you use a value without taking ownership.

This is done through references (&T or &mut T).

fn main() {
    let s = String::from("Rust");
    print_string(&s);     // borrow instead of move
    println!("{}", s);    // ✔ s is still valid
}

fn print_string(text: &String) {
    println!("{}", text);
}

📌 Borrowing allows access but does not transfer responsibility.

Practical Examples:

// *********=> INTEGER, STRING, TUPLE, VECTOR, FUNCTION, OWNERSHIP, BORROWINGA

fn main() {
    // *********=> INTEGER (Copy type, lives on stack)
    let mut num: u8 = 5;
    // let num = 5; // Rust can infer the type for simple numeric values
    println!("value stored in num: {}", num);
    num = 2; // to make a variable mutable, add `mut` in front of the name
    println!("value stored in num: {}", num);

    // *********=> STRING (heap-allocated)
    // let string_literals: &str = "HELLO WORLD"; // &str = string slice (string literal)
    let string = String::from("HELLO WORLD"); // heap-allocated growable string
    println!("string: {}", string);

    // *********=> TUPLE
    let emp_info: (&str, u8) = ("Ramesh", 50);
    let (emp_name, emp_age) = emp_info;
    println!("Employee name: {}, age: {}", emp_name, emp_age);
    // let emp_name = emp_info.0;
    // let emp_age = emp_info.1;

    // *********=> FUNCTION CALLING (Copy types)
    let num1: u8 = 10;
    let num2: u8 = 20;

    let result: u8 = print_value(num1, num2);
    println!("result: {}", result);
    // num1 and num2 are still valid here because u8 implements Copy.

    // *********=> OWNERSHIP BASICS
    ownership_func();
    ownership_func2();

    // *********=> ARRAYS AND VECTORS
    array_fn();
    vector_fn();

    // *********=> SHADOWING
    shadowing();
}

// add parameter type int,string
fn print_value(num1: u8, num2: u8) -> u8 {
    num1 + num2
}

// *********=> OWNERSHIP: SCOPE

// global scope
const GLOBAL_CONST: u8 = 5; // const requires type annotation and should be UPPERCASE

fn ownership_func() {
    println!("GLOBAL_CONST: {}", GLOBAL_CONST);

    // function scope
    let outside_variable = 5;

    // block scope
    {
        let inside_variable = 5;
        println!("INSIDE VARIABLE: {}", inside_variable);
    }

    // inside_variable is not accessible here
    println!("OUTSIDE VARIABLE: {}", outside_variable);
}

fn ownership_func2() {
    // This works because integers are Copy types (stack-allocated, small, trivial)
    let a = 5;
    let b = a; // a is copied
    println!("a: {}, b: {}", a, b);

    // For heap types like String, ownership is moved, not copied by default
    let str1: String = String::from("HELLO"); // str1 owns "HELLO"
    let str2 = str1; // ownership moved from str1 to str2

    // println!("{}", str1); // ❌ error: str1 is no longer valid here
    println!("str2: {}", str2);

    let x: String = String::from("HELLO BYE");
    // transfer ownership of x into function new_ownership_func
    new_ownership_func(x);
    // println!("{}", x); // ❌ error: x was moved
}

fn new_ownership_func(item: String) {
    println!("item (taken by ownership): {}", item);

    let mut s: String = String::from("beyeyyeee"); // s owns this String

    // Borrowing mutable reference to s
    let len: usize = new_ownership_func2(&mut s); // passing &mut s (borrow, not move)
    println!("VALUE of s: '{}', len before push: {}", s, len);

    // *********=> REFERENCE RULES

    let mut s1: String = String::from("Hello");

    {
        // First mutable borrow in this inner scope
        let w1 = &mut s1;
        w1.push_str(" World");
        println!("w1 = {}", w1);
    } // w1 goes out of scope here, so we can borrow mutably again

    {
        // Second mutable borrow in a separate scope
        let w2 = &mut s1;
        w2.push_str(" Again");
        println!("w2 = {}", w2);
    } // w2 goes out of scope

    println!("Final s1: {}", s1);

    // You cannot have two active &mut references at the same time.
    // This would be an error:
    //
    // let r1 = &mut s1;
    // let r2 = &mut s1; // ❌ cannot borrow `s1` as mutable more than once at a time
}

fn new_ownership_func2(item: &mut String) -> usize {
    let length = item.len();
    item.push_str("dsvndfvdv"); // modify through mutable reference
    new_main();
    length
}

fn new_main() {
    // *********=> REFERENCE AND DEREFERENCE
    let mut x = 5;
    x = x + 1;

    let y = &mut x; // y is a mutable reference to x
    *y = *y + 1;    // use * to dereference and modify the underlying value

    println!("y (mutable ref to x): {}", y);
}

fn array_fn() {
    // *********=> ARRAY
    // fixed-size, same-type, lives on the stack
    let mut arr: [&str; 3] = ["HELLO", "BYE", "CODER"];

    // Here arr is copied into arr1 (arrays of Copy types are Copy up to a certain size)
    write_mut_fn(arr);
    // Here we pass a mutable reference to the original arr
    write_ref_fn(&mut arr);

    println!("arr in array_fn (after write_ref_fn): {:?}", arr);
}

fn write_mut_fn(mut arr1: [&str; 3]) {
    // arr1 is a copy of arr and is local to this function
    arr1[0] = "FELLOW";
    println!("arr1 in write_mut_fn: {:?}", arr1);
}

fn write_ref_fn(arr2: &mut [&str; 3]) {
    // We are modifying the original arr via mutable reference
    arr2[0] = "FELLOW2";
    println!("arr2 in write_ref_fn: {:?}", arr2);
}

fn vector_fn() {
    // *********=> VECTOR (heap-allocated growable array)
    let mut v: Vec<i32> = vec![1, 2, 3, 4, 5];

    // Pass a mutable reference to the vector (no clone, no move of ownership)
    write_vector_mut_fn(&mut v);
    println!("v after write_vector_mut_fn: {:?}", v);
}

fn write_vector_mut_fn(v: &mut Vec<i32>) {
    v.push(99);
    println!("v inside write_vector_mut_fn: {:?}", v);
}

fn shadowing() {
    // *********=> SHADOWING
    let x = 5;
    println!("value of x: {}", x);
    let x = 10; // shadows previous x
    println!("value of x after shadowing: {}", x);
}

Mastering Micro Frontend: A Modular Approach to Scalable Web Applications

Abhinav Sharma — Sun, 01 Dec 2024 08:57:50 +0000

What are Micro Frontends?

Micro Frontend is an architectural style where a frontend application is divided into smaller, independently developed and deployable units called "micro frontends." Each unit represents a specific feature or domain and can be owned by separate teams. This approach extends the concept of microservices from the backend to the front end, enabling large-scale web applications to be built, scaled, and maintained more efficiently.

How to Determine Which Applications Require Micro Frontends

Application Complexity - The large, monolithic front end causes slow builds, difficult maintenance, and frequent regressions or bugs during updates.
Technology Diversity - Teams can use different frameworks or tools for specific features. For example, you can leverage Vue’s simplicity for form handling, Svelte’s performance for small components, and React’s rich ecosystem for the main application.
Deployment Challenges - Long release cycles due to dependency on the entire app.

Key Principles of Micro Frontend Architecture

Independence - Each micro frontend should be independently deployable and developed, meaning teams can work on different parts of the app without being blocked by other teams.
Technology Agnosticism - Different micro frontends can use different technologies (e.g., React, Vue, Angular, or even plain JavaScript). Teams are free to choose the best tool for their feature’s needs.
Modularity and Reusability - Micro frontends should be designed as independent, reusable modules. These modules can be integrated into the main application without disturbing other parts of the system.
Clear Communication and Contracts - Micro frontends must communicate clearly with each other using well-defined APIs and data contracts, typically through events, shared services, or state management systems.

Benefits of Micro frontend

Independent Development and Deployment- Teams can work and deploy their features independently, speeding up release cycles.
Technology Flexibility - Teams can choose the best technology for their module, enabling innovation and flexibility.
Scalability - Allows organizations to scale development by enabling more teams to work on different parts of the app without causing bottlenecks.
Better Code Maintainability - Smaller, focused codebases are easier to maintain, debug, and refactor.
Increased Team Autonomy - Teams have full ownership of their micro frontend, which enables faster decision-making and development.
Enhanced User Experience - Specialized, optimized modules improve the user interface, making it more efficient and tailored.
Faster Time-to-Market - Features can be developed and released quickly without waiting for the entire app to be ready.
Decentralized Deployment and Rollbacks - Micro frontends can be deployed separately, and specific modules can be rolled back without affecting the whole app.
Improved Testability - Each micro frontend is isolated, making it easier to write focused unit and integration tests.
Easier Upgrades and Migrations - Allows gradual upgrades and migrations of individual modules, minimizing disruptions to the overall system.

Disadvantages of Micro Frontends

Increased Complexity - Managing multiple micro frontends with different technologies and deployment pipelines adds complexity to the overall system, especially in terms of integration and coordination.
Performance Overhead - Micro frontends often require additional resources for loading and communication between different parts of the application, potentially leading to performance issues like slower load times or excessive network requests.
Cross-Micro Frontend Communication - Sharing state or communication between micro frontends can be challenging and may require complex solutions like event buses, APIs, or shared libraries, which can introduce bugs and maintenance challenges.
Debugging Complexity - Debugging issues in a system with many micro frontends can be more challenging, especially when trying to identify which micro frontend is causing a problem within the larger application.

How to Overcome Micro Frontend Challenges

Increased Complexity - Use a container framework and clear architectural guidelines to simplify integration and team workflows. Example: use Webpack Module Federation to handle shared dependencies like React, enabling seamless integration of micro frontends.
Performance Overhead - Implement lazy loading, shared dependencies, and caching to optimize load times and reduce resource usage. Example: only load the dashboard micro frontend when a user logs in and navigates to it, while sharing common libraries like Lodash through CDN caching to avoid multiple downloads.
Cross-Micro Frontend Communication - Use event-driven communication or centralized APIs to enable seamless data exchange between micro frontends. Example: Implement an Event Bus using RxJS to notify the search micro frontend when the user adds an item to the cart micro frontend, ensuring state synchronization.
Debugging Complexity - Set up centralised logging and monitoring tools like Sentry or ELK Stack to trace and resolve issues efficiently. Example: Use Sentry to capture errors from all micro frontends. So developers can easily identify which micro frontend caused the issue.

Different Approaches to Implement Micro Frontends

Module Federation (Webpack 5/Vite) - This method lets different parts of your app share code with each other while the app is running. It’s useful because you can load only the parts you need, without having to rebuild everything.

// Container webpack.config.js
new ModuleFederationPlugin({
  name: 'container',
  remotes: {
    products: 'products@http://localhost:3001/remoteEntry.js',
    cart: 'cart@http://localhost:3002/remoteEntry.js'
  }
});

// Container App
const ProductApp = lazy(() => import('products/ProductApp'));

Web Components - Web Components are custom HTML elements that can work across different frameworks (like React, Vue, or Angular). They’re great because you can reuse the same component anywhere, no matter what technology the app is built with.

class ProductList extends HTMLElement {
  connectedCallback() {
    this.innerHTML = `<div>Product List</div>`;
  }
}
customElements.define('product-list', ProductList);

// Usage
<product-list></product-list>

iFrame Based - This approach involves embedding different apps inside an <iframe>. Each app runs separately in its own little "box", which means they stay independent from the rest of the page. It’s useful for keeping things isolated but can have performance downsides.

<div id="container">
  <iframe src="http://products.domain.com"></iframe>
  <iframe src="http://cart.domain.com"></iframe>
</div>

Server-Side Composition - The server builds the app by combining different parts of your micro frontends and sends the final page to the user. It’s good for apps that don’t need too much dynamic content and want to load quickly.

// Server code
app.get('/', async (req, res) => {
  const header = await fetch('header-service');
  const products = await fetch('product-service');
  const html = `
    ${header}
    ${products}
  `;
  res.send(html);
});

Edge-Side Composition - Similar to server-side composition, but the content is assembled closer to the user, at the edge of the network. This makes the app load faster because the content doesn’t have to travel as far.

// Edge worker
addEventListener('fetch', event => {
  const products = fetch('products-service');
  const cart = fetch('cart-service');
  const html = combineResponses([products, cart]);
  return new Response(html);
});

App Shell Model - The app loads a basic layout (like the header and footer) first, then fetches the content afterward. This helps make the app feel faster since users see something right away while the rest of the app loads in the background.

// Shell application
class AppShell {
  async loadMicroFrontend(name) {
    const module = await import(`/mfe/${name}/entry.js`);
    return module.mount('#container');
  }
}

Build-Time Integration (NPM Packages) - With this method, you bundle all your micro frontends together at build time into a single app. It’s a simple approach, but not ideal if you want to update content dynamically without rebuilding the whole app.

// package.json
{
  "dependencies": {
    "@custom/product-app": "^1.0.0",
    "@custom/cart-app": "^1.0.0"
  }
}

// App.js
import ProductApp from '@company/product-app';
import CartApp from '@company/cart-app';

function App() {
  return (
    <div>
      <ProductApp />
      <CartApp />
    </div>
  );
}

Conclusion

Micro frontends provide a powerful way to scale and manage large web applications by breaking them down into smaller, independent, and manageable units. By enabling teams to work autonomously on different parts of the application, adopting the right architecture and tools, and allowing flexibility in technology choices, micro frontends can significantly improve development speed, maintainability, and scalability. However, challenges such as complexity, performance overhead, and cross-micro frontend communication must be addressed with careful planning and the use of best practices.

By choosing the right approach—whether through Module Federation, Web Components, iFrames, or server-side composition—you can tailor your solution to meet the specific needs of your application and teams. Overall, micro frontends offer a promising solution for modern, large-scale frontend architectures, fostering collaboration and efficiency across teams while delivering a smoother user experience.

Vite vs. Webpack: Which One Is Right for Your Project?

Abhinav Sharma — Sun, 03 Nov 2024 18:42:25 +0000

As web applications grow, so does the need for faster and more efficient development tools. For years, Webpack has been the go-to bundler, powering complex apps with its strong features and extensive plugin options. However, Vite has recently become a popular, faster alternative, designed to create a smoother, more modern development experience.

Whether you're starting a new single-page app or trying to speed up an existing project, picking the right tool can make a big difference in your productivity, build times, and project performance. In this article, we'll break down the main differences between Vite and Webpack, looking at their strengths, weaknesses, and best use cases to help you decide which one fits your needs.

Let’s evaluate them based on the following criteria:

1. Performance

Test Environment

Node.js: v22.x
Hardware: 8GB RAM, Macbook M3
Project Type: React application
Dependencies: React, React-DOM, and some essential libraries

1.1 Development Speed and HMR

This analysis compares development performance between Webpack and Vite across different project sizes, focusing on startup times, Hot Module Replacement (HMR), and memory usage.

Small Project (<10 files)

Feature	Vite	Webpack
Dev Server Start	131ms	960ms
HMR Speed	<50ms	100-500ms
Memory Usage (Dev)	30MB	103MB

Medium Project (50 files)

Feature	Vite	Webpack
Dev Server Start	139ms	1382ms
HMR Speed	<50ms	100-500ms
Memory Usage (Dev)	36MB	168MB

Large Project (100 files)

Feature	Vite	Webpack
Dev Server Start	161ms	1886ms
HMR Speed	<50ms	100-500ms
Memory Usage (Dev)	42MB	243MB

This graph represents the Dev Server Start speed(ms) when the number of files increases.

Key Findings

Dev Server Start Time
- Vite is significantly faster across all project sizes.
- Remains quick even as a project grows (131ms → 161ms).
- Webpack shows a dramatic slowdown with scale (960ms → 1886ms).
Hot Module Replacement (HMR)
- Vite maintains a consistent <50ms refresh speed.
- Webpack is 2-10x slower at 100-500ms.
- Vite's speed advantage remains constant regardless of project size.
Memory Usage
- Vite is much more memory efficient.
- Small project: Vite uses 71% less memory (30MB vs 103MB).
- Large project: Vite uses 83% less memory (42MB vs 243MB).
- Webpack's memory usage grows more aggressively with project size.
Scalability
- Vite shows minimal performance degradation as projects grow.
- Webpack performance worsens significantly with larger projects.
- The gap between tools widens as project size increases.

2. Build Speed (Minified Build)

Small Project (<10 files)

Feature	Vite	Webpack
Build Time	242ms	1166ms
Build Size	142KB	156KB

Medium Project (50 files)

Feature	Vite	Webpack
Build Time	363ms	1936ms
Build Size	360.77KB	373KB

Large Project (100 files)

Feature	Vite	Webpack
Build Time	521ms	2942ms
Build Size	614KB	659KB

This graph represents the Build Time speed(ms) when the number of files increases.

This graph represents Build Size(KB) when the number of files increases.

Key Findings

Speed: Vite shows a consistent speed advantage across all project sizes, achieving build times that are 5x to 6x faster than Webpack.
Size: Vite consistently delivers smaller build sizes than Webpack across project sizes. This efficiency grows with project complexity, especially evident in larger builds where Vite’s output is nearly 45 KB smaller than Webpack’s.

2. Configuration

Vite Basic Configuration

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

// Vite configuration with dev server setup
export default defineConfig({
  plugins: [react()],
});

Webpack Basic Configuration

const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
  mode: 'development',   // Sets Webpack to development mode
  entry: './src/index.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'bundle.js',
  },
  module: {
    rules: [
      { test: /\.jsx?$/, exclude: /node_modules/, use: 'babel-loader' },  // For JavaScript/React
      { test: /\.css$/, use: ['style-loader', 'css-loader'] },  // For CSS
    ],
  },
  plugins: [
    new HtmlWebpackPlugin({ template: './src/index.html' }),   // Generates an HTML file with the bundle
  ],
  devServer: {
    port: 3000,    // Dev server port
    open: true,    // Opens browser on server start
    hot: true,     // Enables Hot Module Replacement (HMR)
  },
};

Vite: Configuration is very minimal, mainly requiring plugins if necessary (like @vitejs/plugin-react for React). The dev server setup (server) and build settings are straightforward with Vite’s opinionated defaults.
Webpack: Requires additional configuration for entry, output, and plugins (e.g., HtmlWebpackPlugin). Basic functionality for JavaScript and CSS requires specific loaders (babel-loader and css-loader).

Advance Configuration

Feature	Webpack Support	Vite Support
Custom Bundle Splitting	✅ Extensive control with `splitChunks`	✅ Limited through `manualChunks` in Rollup. While you can configure code splitting, it lacks Webpack’s depth.
Dynamic Import Controls	✅ Naming, prefetch, preload	⚠️ Limited control. Vite supports basic dynamic imports, but lacks advanced prefetch and preload capabilities.
Custom Output Structure	✅ Fully customizable file paths	⚠️ Basic customization. Vite allows basic output customization through `build.rollupOptions.output`, but doesn’t offer the level of path control Webpack provides.
CSS & JS Minification Options	✅ Advanced minifiers available, like Terser and CssMinimizerPlugin	⚠️ Limited to `esbuild` for JS. Vite relies on `esbuild` for JavaScript minification, which is faster but less configurable.
Multi HTML & Entry Points	✅ Supports multiple entries with `HtmlWebpackPlugin`	⚠️ Limited through `rollupOptions.input`. Vite can handle multiple entry points but lacks dedicated plugins for HTML generation and configuration.
Server-Side Rendering (SSR)	⚠️ Requires additional configuration	✅ Native support. Vite includes built-in SSR capabilities, making it easier to set up and integrate than Webpack.
Advanced Caching Options	✅ Filesystem cache	⚠️ Basic cache mechanism. Vite provides a simple caching mechanism aimed at fast development, but lacks Webpack’s granular, long-term caching options.
Tree Shaking w/ Side Effects	✅ Supports `sideEffects` flag for more effective tree shaking	✅ Basic support. Vite performs tree shaking through Rollup but doesn’t support the `sideEffects` flag for further optimization.
Advanced CSS Loading	✅ Extensive support via `css-loader`, `style-loader`, and other plugins	⚠️ Limited in comparison. Vite handles CSS modules out of the box, but lacks Webpack’s extensive configuration for loaders and plugins.
Dev Proxy for APIs	✅ Advanced proxy setup through `devServer.proxy` configuration	✅ Basic proxy support. Both tools support API proxies, but Webpack’s `devServer.proxy` offers more customization options.

3. Legacy Browser Support

Webpack is highly configurable, making it suitable for projects that require compatibility with both modern and legacy browsers. It can support almost any browser version with proper configuration.
Vite is optimized for modern development environments, focusing on browsers that support ES modules. For legacy browser support, Vite relies on the @vitejs/plugin-legacy plugin, which introduces some complexity and performance trade-offs.

Feature	Webpack Support	Vite Support
Default Compatibility	Modern and legacy (with configuration)	Modern browsers only
IE11 Support	Yes (via Babel/Polyfills)	Limited (requires `@vitejs/plugin-legacy`)
ES Modules	Optional (can target ES5)	Required for development and default for builds
Transpilation Options	Full control with Babel/TypeScript	Limited control, based on `esbuild`
Polyfills	Easily added with Babel and core-js	Basic polyfills with `plugin-legacy`
Build Performance	Slower when targeting legacy browsers	Faster for modern builds, slower with legacy

Conclusion

Webpack is more feature-rich and flexible, particularly for large, complex projects requiring fine-grained control over build output, caching, and asset management. Vite, however, is focused on speed and simplicity, making it ideal for modern, smaller projects and fast development cycles. The choice largely depends on project needs and complexity: Webpack’s configurability suits complex setups, while Vite's speed suits smaller, modular, and ES module-first projects.