Tag: web-development

🗄️ Browser Storage Mechanisms Explained (with Vue.js Examples)

Modern web applications often need to store data on the client side – whether it’s user preferences, form progress, or temporary UI state.
Browsers provide built-in storage mechanisms that help developers do exactly that, without hitting the backend every time.

In this post, we’ll cover:

  • What browser storage is
  • localStorage vs sessionStorage
  • Basic JavaScript examples
  • Vue.js usage patterns
  • When to use (and not use) each
  • Why developers rely on browser storage
  • Comparison with React and Angular

🌐 What Is Browser Storage?

Browser storage allows web applications to store key–value data directly in the user’s browser.

Key characteristics:

  • Data is stored client-side
  • Data is stored as strings
  • Accessible via JavaScript
  • Faster than server round-trips

The most common browser storage mechanisms are:

  • localStorage
  • sessionStorage

(Both are part of the Web Storage API)

📦 localStorage

What is localStorage?

localStorage stores data persistently in the browser.

  • Survives page reloads
  • Survives browser restarts
  • Shared across all tabs of the same origin
  • Cleared only manually or via code

Basic JavaScript Example

// Save data
localStorage.setItem('theme', 'dark')
// Read data
const theme = localStorage.getItem('theme')
// Remove data
localStorage.removeItem('theme')

Vue.js Example

export default {
  data() {
    return {
      theme: localStorage.getItem('theme') || 'light'
    }
  },
  watch: {
    theme(newValue) {
      localStorage.setItem('theme', newValue)
    }
  }
}

When to Use localStorage

  • User preferences (theme, language)
  • Remembered UI settings
  • Non-sensitive data that should persist
  • Cross-tab shared state

When NOT to Use localStorage

  • Authentication tokens (use httpOnly cookies)
  • Sensitive personal data
  • Temporary flows (signup, checkout steps)

⏳ sessionStorage

What is sessionStorage?

sessionStorage stores data only for the lifetime of a browser tab.

  • Cleared when the tab is closed
  • Not shared across tabs
  • Survives page refresh
  • Scoped per tab/window

Basic JavaScript Example

// Save data
sessionStorage.setItem('step', '2')
// Read data
const step = sessionStorage.getItem('step')
// Remove data
sessionStorage.removeItem('step')

Vue.js Example (Signup Flow)

export default {
  data() {
    return {
      postalCode: sessionStorage.getItem('postalCode') || ''
    }
  },
  methods: {
    savePostalCode() {
      sessionStorage.setItem('postalCode', this.postalCode)
    }
  }
}

When to Use sessionStorage

  • Multi-step forms
  • Signup / onboarding flows
  • Temporary UI state
  • One-time user journeys

When NOT to Use sessionStorage

  • Long-term preferences
  • Data needed across tabs
  • Anything that must survive browser close

⚖️ localStorage vs sessionStorage

FeaturelocalStoragesessionStorage
LifetimePersistentUntil tab closes
ScopeAll tabsSingle tab
Shared across tabs✅ Yes❌ No
Survives reload✅ Yes✅ Yes
Use casePreferencesTemporary flows
Storage size~5–10MB~5MB

🤔 Why Web Developers Use Browser Storage

Developers use browser storage because it:

  • Improves performance
  • Reduces API calls
  • Remembers user intent
  • Simplifies UI state management
  • Works instantly (no async fetch)

Browser storage is often used as a support layer, not a replacement for backend storage.

⚠️ Security Considerations

Important points to remember:

  • ❌ Data is NOT encrypted
  • ❌ Accessible via JavaScript
  • ❌ Vulnerable to XSS attacks

Never store:

  • Passwords
  • JWTs
  • Payment data
  • Sensitive personal information

⚛️ Comparison with React and Angular

Browser storage usage is framework-agnostic.

Vue.js

sessionStorage.setItem('key', value)

React

useEffect(() => {
  localStorage.setItem('key', value)
}, [value])

Angular

localStorage.setItem('key', value)

All frameworks rely on the same Web Storage API
The difference lies in state management patterns, not storage itself.

Best Practices

  • Store only strings (use JSON.stringify)
  • Always handle null values
  • Clean up storage after flows
  • Wrap storage logic in utilities or composables
  • Never trust browser-stored data blindly

Final Thoughts

  • localStorage → persistent, shared, preference-based
  • sessionStorage → temporary, per-tab, flow-based
  • Vue, React, and Angular all use the same browser API
  • Use browser storage wisely — as a helper, not a database

Used correctly, browser storage can make your frontend faster, smarter, and more user-friendly.

Happy web development!

The Evolution of Asset 📑 Management in Web and Ruby on Rails

Understanding Middleware in Rails

When a client request comes into a Rails application, it doesn’t always go directly to the MVC (Model-View-Controller) layer. Instead, it might first pass through middleware, which handles tasks such as authentication, logging, and static asset management.

Rails uses middleware like ActionDispatch::Static to efficiently serve static assets before they even reach the main application.

ActionDispatch::Static Documentation

“This middleware serves static files from disk, if available. If no file is found, it hands off to the main app.”

Where Are Static Files Stored?

Rails stores static assets in the public/ directory, and ActionDispatch::Static ensures these are served efficiently without hitting the Rails stack.

Core Components of Ruby on Rails – A reminder

To understand asset management evolution, let’s quickly revisit Rails’ core components:

  • ActiveRecord: Object-relational mapping (ORM) system for database interactions.
  • Action Pack: Handles the controller and view layers.
  • Active Support: A collection of utility classes and standard library extensions.
  • Action Mailer: A framework for designing email services.

The Role of Browsers in Asset Management

Web browsers cache static assets to improve performance. The caching strategy varies based on asset types:

  • Images: Rarely change, so they are aggressively cached.
  • JavaScript and CSS files: Frequently updated, requiring cache-busting mechanisms.

The Era of Sprockets

Historically, Rails used Sprockets as its default asset pipeline. Sprockets provided:

  • Conversion of CoffeeScript to JavaScript and SCSS to CSS.
  • Minification and bundling of assets into fewer files.
  • Digest-based caching to ensure updated assets were fetched when changed.

The Rise of JavaScript & The Shift Towards Webpack

The release of ES6 (2015-2016) was a turning point for JavaScript, fueling the rise of Single Page Applications (SPAs). This marked a shift from traditional asset management:

  • Sprockets was effective but became complex and difficult to configure for modern JS frameworks.
  • Projects started including package.json at the root, indicating JavaScript dependency management.
  • Webpack emerged as the go-to tool for handling JavaScript, offering features like tree-shaking, hot module replacement, and modern JavaScript syntax support.

The Landscape in 2024: A More Simplified Approach

Recent advancements in web technology have drastically simplified asset management:

  1. ES6 Native Support in All Major Browsers
    • No need for transpilation of modern JavaScript.
  2. CSS Advancements
    • Features like variables and nesting eliminate the need for preprocessors like SASS.
  3. HTTP/2 and Multiplexing
    • Enables parallel loading of multiple assets over a single connection, reducing dependency on bundling strategies.

Enter Propshaft: The Modern Asset Pipeline

Propshaft is the new asset management solution introduced in Rails, replacing Sprockets for simpler and faster asset handling. Key benefits include:

  • Digest-based file stamping for effective cache busting.
  • Direct and predictable mapping of assets without complex processing.
  • Better integration with HTTP/2 for efficient asset delivery.

Rails 8 Precompile Uses Propshaft

What is Precompile? A Reminder

Precompilation hashes all file names and places them in the public/ folder, making them accessible to the public.

Propshaft improves upon this by creating a manifest file that maps the original filename as a key and the hashed filename as a value. This significantly enhances the developer experience in Rails.

Propshaft ultimately moves asset management in Rails to the next level, making it more efficient and streamlined.

The Future of Asset Management in Rails

With advancements like native ES6 support and CSS improvements, Rails continues evolving to embrace simpler, more efficient asset management strategies. Propshaft, combined with modern browser capabilities, makes asset handling seamless and more performance-oriented.

As the web progresses, we can expect further simplifications in asset pipelines, making Rails applications faster and easier to maintain.

Stay tuned for more innovations in the Rails ecosystem!

Happy Rails Coding! 🚀