Forem: Pritam Patil

Introducing the `Temporal` Object: A Game-Changer for JavaScript Date Handling

Pritam Patil — Thu, 12 Mar 2026 07:09:05 +0000

In the ever-evolving world of JavaScript, the Temporal object is a new and exciting addition that promises to revolutionize the way we handle dates and times.

While the Date object has been a staple for many years, it has several limitations and inconsistencies that can lead to bugs and confusion. The Temporal object aims to address these issues by providing a more robust and accurate way to work with temporal data.

What is the `Temporal` Object?

The Temporal object is a new JavaScript API introduced in the ECMAScript 2023 proposal. It is designed to offer a more precise and flexible way to work with dates and times, addressing common issues such as leap seconds, time zone differences, and calendar inconsistencies. The Temporal object includes several sub-objects like Temporal.PlainDate, Temporal.PlainTime, and Temporal.ZonedDateTime, which provide more granular control over date and time operations.

Issues with Existing `Date` Object

The Date object in JavaScript has been a source of frustration for developers due to its limitations and inconsistencies. Some of the key issues include:

1. Leap Seconds

The Date object does not account for leap seconds, which can lead to inaccuracies in time calculations.
Leap seconds are added by certain organizations to keep Coordinated Universal Time (UTC) in sync with Earth's rotation.

2. Time Zone Handling

The Date object is timezone-agnostic, meaning it doesn't natively support time zone conversions.
This can lead to issues when working with dates and times across different time zones, especially during daylight saving time transitions.

3. Calendar Inconsistencies

The Date object uses the Gregorian calendar, but it doesn't provide easy ways to work with other calendars like the Hijri or Chinese calendars.
This can be problematic for applications that need to handle dates in non-Gregorian calendars.

4. Complexity in Operations

Operations like date arithmetic, comparing dates, and formatting can be complex and error-prone with the Date object.
This complexity can lead to bugs and inconsistencies in date-related logic.

5. Lack of Granularity

The Date object represents a point in time as a floating-point number, which can lose precision for very long periods.
This can be problematic for applications that require high-precision date and time calculations.

What Does the `Temporal` Object Solve?

The Temporal object addresses these issues by providing a more precise and flexible way to handle dates and times. Here are some of the key benefits:

1. Leap Second Support

The Temporal object accounts for leap seconds, ensuring accurate time calculations.
This is particularly important for applications that need to maintain precise time synchronization.

2. Time Zone Support

The Temporal object includes support for time zones and can handle daylight saving time transitions.
This makes it easier to work with dates and times across different regions.

3. Calendar Flexibility

The Temporal object allows working with different calendars, providing a more comprehensive solution for applications that need to handle non-Gregorian calendars.
This flexibility can be crucial for applications serving diverse user bases or historical data.

4. Simplified Date Arithmetic

The Temporal object provides a simpler and more reliable way to perform date arithmetic, such as adding or subtracting time periods.
This can reduce the complexity and potential for bugs in date-related logic.

5. High Precision

The Temporal object provides higher precision for date and time calculations, ensuring accuracy for long periods.
This is particularly useful for applications that require precise date and time tracking.

Migrating to the `Temporal` Object

While the Temporal object is still in the proposal stage, it's important to start planning a migration strategy. Here are some steps you can take to prepare:

1. Evaluate Your Needs

Determine whether your application would benefit from the Temporal object's features.
Assess the current usage of the Date object in your codebase and identify areas that could be improved.

2. Use Polyfills and Libraries

While the Temporal object is not yet part of the standard, you can use polyfills or libraries like temporal.js to start working with the Temporal API today.
These tools can help you start integrating the Temporal object into your codebase without waiting for full browser support.

3. Refactor Your Code

Identify and refactor parts of your code that could benefit from the Temporal object.
Start by converting simple date operations and gradually move to more complex date handling.

4. Test Thoroughly

Write extensive tests to ensure that your refactored code works as expected.
Use test cases that cover edge cases and potential bugs to catch any issues early.

5. Monitor Browser Support

Keep an eye on browser support for the Temporal object.
Use tools like Can I Use to monitor when full support is available.

6. Document Your Changes

Document the changes you make to your codebase, including the reasons for the refactoring and any potential issues.
This documentation will be valuable for future maintenance and for other developers working on the project.

Conclusion

The Temporal object is a significant step forward in JavaScript's date and time handling capabilities. While it is still in the proposal stage, its potential benefits make it
worth considering for applications that require high precision and accuracy in date and time calculations.
By planning a strategic migration, you can take advantage of these new features and improve the reliability and performance of your applications.

Stay tuned for updates on the Temporal object and its integration into the JavaScript standard. Happy coding!

React 2026: Why the All-Client SPA Is Becoming Legacy Code

Pritam Patil — Tue, 20 Jan 2026 04:03:27 +0000

If you’re still building React apps that ship everything to the client, you’re building for 2019, not 2029.

Let me explain why the single-page application (SPA) as we know it is entering its legacy phase — and what’s replacing it.

The SPA Trade-Off That’s No Longer Worth It

For years, we accepted a fundamental trade-off:

Rich interactivity came at the cost of JavaScript bloat.

We shipped entire frameworks to the browser so users could click between routes without full page reloads. We accepted:

100-500KB JavaScript bundles before our actual code
Client-side data fetching waterfalls
The dreaded loading-spinner-everywhere experience
Hydration overhead that blocked interactivity

This made sense when the alternative was jQuery spaghetti or full server roundtrips. But in 2026, we have a better option.

The Hybrid Architecture: Server Components + Client Components

React Server Components (RSCs) aren’t just another feature—they’re a fundamental architectural shift. Here’s the new mental model:

Server Components: The Foundation

Run once on the server during render
Can directly access databases, APIs, filesystems
Zero JavaScript shipped to the client
Perfect for: data fetching, static content, layouts, non-interactive UI

// This component NEVER ships to the browser
// It runs safely on your server, fetching fresh data each request
async function ProductDetails({ productId }) {
  const product = await db.products.findUnique({ 
    where: { id: productId } 
  });

  return (
    <div>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      {/* Price is static content - stays on server */}
      <PriceDisplay price={product.price} />
      {/* AddToCartButton IS interactive - becomes client component */}
      <AddToCartButton productId={product.id} />
    </div>
  );
}

Client Components: The Interactive Islands

Marked with use client
Handle user interactions, state, effects
Only shipped where needed
Perfect for: forms, buttons, animations, real-time updates

The key insight? Most of your app isn't interactive.
Your navigation, footer, hero section, product descriptions, blog content—these don't need React state or effects. They just need to render.

The 2026 Stack: A Concrete Example

Let's walk through what a modern e-commerce page looks like:

// 2024 Approach (SPA)
function ProductPage() {
  const [product, setProduct] = useState(null);
  const [reviews, setReviews] = useState([]);

  useEffect(() => {
    // Two client-side fetches = double latency
    fetchProduct().then(setProduct);
    fetchReviews().then(setReviews);
  }, []);

  if (!product) return <Spinner />;

  return (
    <>
      <ProductDetails product={product} /> {/* Has price, description */}
      <ReviewsList reviews={reviews} />    {/* Static content */}
      <AddToCart product={product} />      {/* Interactive */}
      <RelatedProducts />                  {/* More fetches... */}
    </>
  );
}
// Bundle: ~150KB React + 50KB app code = 200KB to customer

// 2026 Approach (Hybrid)
// Server Component (runs on server, zero JS to browser)
async function ProductPage({ productId }) {
  const [product, reviews, related] = await Promise.all([
    db.products.findUnique({ where: { id: productId }}),
    db.reviews.findMany({ where: { productId }}),
    getRelatedProducts(productId)
  ]);

  return (
    <>
      {/* Static content rendered to HTML on server */}
      <ProductDetails product={product} />
      <ReviewsList reviews={reviews} />

      {/* Only these interactive bits become client JS */}
      <AddToCart product={product} />      {/* ~3KB */}
      <ProductRecommendations products={related} /> {/* ~5KB */}
    </>
  );
}
// Bundle: ~8KB of interactive JS only

Impact: The user sees content immediately. JavaScript loads in the background for the "Add to Cart" button. No spinners. No hydration blocking.

Why This Is Inevitable

1. Performance Expectations Have Changed

Users expect pages to load in < 2 seconds on mobile. Core Web Vitals are now Google ranking factors. The 200KB SPA can't compete with 8KB of progressive hydration.

2. The Economics Make Sense

Bandwidth costs drop when you ship less JavaScript
CPU usage drops when you don't hydrate entire trees
Developer time drops when you don't manage client-side data fetching

3. The Frameworks Are All Moving This Way

Next.js App Router (RSC-first)
Remix with React 19
Gatsby moving to partial hydration
Astro proving islands architecture works at scale

When every major framework converges on an architecture, it's not a trend—it's the future.

What "Legacy" Means in Practice

Your existing SPA isn't suddenly obsolete tomorrow. But "legacy" in 2026 means:

New features are built with hybrid architecture
Performance-critical pages get incremental migration
New hires learn RSC patterns first
Tooling and libraries prioritize RSC compatibility

It's the same transition we saw with:

Class components → Hooks (2019)
REST → GraphQL (2017)
jQuery → React (2015)

The old way still works, but the momentum has shifted.

The Skills That Will Matter in 2026

As we transition, these skills become valuable:

Architecture Design Knowing what should be server vs client

// Good 2026 thinking:
"This product grid needs sorting? Client component."
"This blog post content? Server component."
"This header with search? Split: static HTML + client search logic."

Data Flow Understanding Server Components pass data to Client Components via serializable props

// Server Component
<ClientComponent 
  data={product}  // ✅ Serializable
  onAction={handleAction}  // ❌ Functions won't work
/>

Performance Optimization
Not just "make it fast," but "ship less, compute server-side, hydrate minimally"
Security Awareness
Understanding what code runs where, and keeping secrets on the server

The Migration Path: Start Today

You don't need to rewrite your app. Start with the 80/20 rule:

Identify non-interactive pages (About, Blog, Documentation)
Convert them to Server Components
Extract interactive pieces as Client Components
Measure the bundle reduction

A typical migration yields:

40-70% JavaScript reduction
30-50% faster Largest Contentful Paint
Simpler data fetching code

The Counterarguments (And Why They're Fading)

"But we need SSR for SEO!"
Server Components give you SSR automatically, plus zero-client-JS for static parts.

"Our users need full offline support!"
Service Workers + Client Components for critical paths still work. Most apps don't need full offline.

"This locks us into a framework!"
True, but you were already locked into React. The framework just provides the server runtime.

Looking Ahead: What Comes After Hybrid?

If hybrid architecture is 2026, what's 2028?

AI-generated component splits
Tools that automatically optimize server/client boundaries
Predictive prefetching
Server Components that know what you'll click next
Edge Components
Running React Components on CDNs for 10ms global latency
WebAssembly integration
Heavy computations running safely on client via WASM, not JavaScript

Conclusion: The Writing Is on the Bundle

The metrics don't lie:

Airbnb reduced JavaScript by 40% with RSCs
Vercel's dashboard saw 60% faster interactions
Developers report simpler data fetching code

The all-client SPA served us well for a decade. But in technology, a decade is an eternity.

The future isn't "less JavaScript"—it's smarter JavaScript. Shipping only what's needed, when it's needed, to whom it's needed.

Your next project shouldn't be a SPA. It should be a strategically split application that respects both your users' bandwidth and your developers' sanity.

The transition has already started. The question isn't whether you'll adopt hybrid architecture, but how gracefully you'll make the shift.

Are you building with Server Components yet? What's been your biggest challenge or insight? Share in the comments—I read every one.

12 CSS Best Practices by Twitter

Pritam Patil — Sun, 20 Jun 2021 18:31:15 +0000

When grouping selectors, keep individual selectors to a single line.
Don't prefix property values with a leading zero.
Lowercase all hex values and use shorthand hex values whenever possible.
Avoid specifying units for zero values.
Related property declarations should be grouped together following the order: position, box-model, typography, visual. misc.
Don't use !important - It is a last resort generally and only use when you need to override something and there is no other way. Instead increase the specificity of the selector.
When a rule set includes only one declaration, consider removing line breaks for readability and faster editing.
Limit shorthand declaration usage to instances where you must explicitly set all available values.
Ensure your code is descriptive, well commented and approachable by others. Great code comments convey context and/or purpose.
Class names:
a. Keep them lowercase and use dashes to separate words
b. Avoid excessive shorthand notation. (.btn is fine, .s is not)
c. Use meaningful names: use structural or purposeful names over presentation.
d. Prefix classes based on the closest parent or base class.
Selectors:
a. Use classes over generic element tag for optimum rendering performance.
b. Avoid using several attribute selectors (e.g. [class^="..."]) on commonly occurring components. Browser performance is known to be impacted by these.
c. Keep selectors short and strive to limit the number of elements in each selector to three names over presentational.
Place media queries as close to their relevant rule sets whenever possible.

...

Follow me on twitter or Github.

How to test your UI without resizing browser

Pritam Patil — Wed, 16 Jun 2021 15:00:01 +0000

The Problem

When working on UI layouts, for testing responsiveness - you may be used to either:

DevTools with custom viewport sizes
Or some extension e.g. Window Resizer
Or resize the browser window itself

The problem with above approaches is you would be testing with fixed window sizes.

The solution

Enter css property resize

The property accepts 4 different values:

both - resized both horizontally and vertically
horizontal - resize it in the horizontal direction
vertical - resize it in the *vertical direction
none - no user-controllable method for resizing it.

The rules to use resize:

NO inline elements

overflow is NOT visible

Say you have code that has items wrapped in a flex container:

  <ul class="items">
    <li> item </li>
    <li> lorem ipsum dorem </li>
    <li> Lorem ipsum dolor sit amet </li>
    <li> consectetur adipiscing elit, sed do eiusmod tempor incididun </li>
  </ul>

.items {
  display: flex;
  flex-flow: row wrap;
  justify-content: space-evenly;
}

li {
  border: 1px solid;
  padding: 10px;
}

To use resize, you'll wrap the ul with style as:

.container {
  display: block;
  overflow: auto;
  resize: both;
}

<div class="container">
  <li> item </li>
    <li> lorem ipsum dorem </li>
    <li> Lorem ipsum dolor sit amet </li>
    <li> consectetur adipiscing elit, sed do eiusmod tempor incididun </li>
</ul>

With this, you can test the responsiveness easily:

Codepen for a demo is available here

...