DEV Community: Afzal Imdad

Why I chose Zed over Visual Studio Code

Afzal Imdad — Fri, 26 Dec 2025 18:14:34 +0000

I often see mixed reviews about using Zed instead of Visual Studio Code . Some people are extremely enthusiastic about Zed’s speed, while others are dissatisfied because they don’t have the vast plugin ecosystem of VS Code.

In all of this, I would like to share my experience.

In the development world, choosing a code editor is an almost sacred decision, one of those personal preferences that can ignite endless arguments.

For years, Visual Studio Code has been my trusted companion, an undisputed behemoth offering almost unlimited flexibility and power. Yet, recently, I made a choice that might seem like a step backwards to some: I switched to Zed.

And I’ll explain why this decision, for me, was the most logical and productive.

When less is really more

In the past, my work focused primarily on web development with PHP, HTML, CSS, and MySQL, along with teaching. For this reason, I was always looking for tools that could be used on Mac, Windows, and Linux.

Today, more out of passion or the needs of some old clients, I occasionally update existing projects. I no longer need an arsenal of complex tools or features that extend to machine learning or desktop application development.

My primary need is just one: an agile, fast development environment that doesn’t get between me and the code.

Visual Studio Code, with its vast ecosystem of extensions, can do practically anything. But this incredible versatility is also its greatest burden.

Over time, I felt it becoming increasingly “large,” a transatlantic liner where all I needed was a fast motorboat to navigate my projects. Startup was no longer instantaneous, and resource consumption, though optimized, was taking its toll.

This is where Zed came into play.

The difference in performance was obvious from the first moment. Zed is incredibly lightweight and responsive. Opening files, global searches, and the overall fluidity of the interface gave me a sense of immediacy I’d forgotten.

A focused focus on my workflow

Zed’s philosophy seems almost tailored to my needs. Being a relatively new editor, it doesn’t claim to be a “jack of all trades.” Its feature set is essential, clean, and focused on what you really need to write code.

For my tech stack, this simplicity is a strength, not a weakness.

Of course, Zed’s maturity is still a work in progress. The plugin ecosystem, for example, isn’t even close to that of VS Code. I’d like the plugins for PHP, HTML, and CSS to be more complete and refined, perhaps with the same level of development found on Microsoft’s platform.

Become a member
But honestly, this isn’t a problem that’s holding me back. Zed is growing rapidly, and its community is active and promising. I’m confident that, with time, these shortcomings will be overcome.

Zed vs. VS Code: The Differences That Matter

Ignoring for a moment the features we now take for granted (such as debugging, Git integration, or AI assistance), I find these aspects particularly interesting:

Zed:

Speed

, Extremely fast and lightweight, thanks to the use of Rust and GPU rendering.
Minimalism: Clean, distraction-free interface designed for maximum focus on your code.
Collaboration: Natively integrated code sharing and collaborative editing capabi lities.

VS Code:

Flexibility: Highly customizable, although this can lead to a more chaotic environment.
Extensibility: Large and mature ecosystem, with thousands of extensions for almost every need imaginable.
Comprehensiveness: It is a tool that adapts to any language, framework or platform.

The choice of the editor is not a competition, but a question of context

We often fall into the trap of looking for the “best” editor. The truth is, none exists.

The choice should not be dictated only by speed, the beauty of the interface or the number of features, but by the specific use we make of it every day.

VS Code remains an extraordinary tool, and for many developers with different needs than mine, it’s undoubtedly the best choice. But for me, with my focus on web development with PHP, HTML, and CSS, Zed fits the bill perfectly.

It gives me exactly what I need, without frills and with a performance that allows me to focus only on what really matters: my idea and the code.

Conclusion

My switch to Zed is not a rejection of Visual Studio Code, but a conscious choice based on my work context.

Because the perfect editor doesn’t exist. However, there is the perfect editor for the job at hand. And for me, today, that editor is Zed.

Have you also made the switch to Zed or are you considering it? Share your experience in the comments, and if this article was helpful, please give it a thumbs up!

New JavaScript pipeline operator: Transform anything into a one-liner 😲

Afzal Imdad — Fri, 10 Jan 2025 23:51:39 +0000

With the pipeline operator you'll stop writing code like this:

And start writing code like this:

So refreshingly clean — and elegant! All those temporary variables are gone — not to mention the time it took to come up with those names and type them (not everyone types like The Flash, unfortunately).

You may have heard this partially true joke attributed to Phil Karlton: "There are only two hard things in computer science: cache invalidation and naming things".

Using the JavaScript pipeline operator clears out the clutter to boost readability and write data-transforming code (basically all code) in a more intuitive manner.

Verbosity should be avoided as much as possible, and this works so much better to compact code than reusing short-named variables:

Hopefully, almost no one codes like this on a regular basis. It's a pretty horrible technique when done in a large scale; a perfect example showing why we embrace immutability and type systems.

Unlike the pipeline operator, there's no certainty that the variable always contains the value you set at any given point; you'll need to climb up the scope to look for re-assignments. We could have used the _ at an earlier point in the code; the value it has at various points in the code is simply not guaranteed.

Now we're just using an underscore, so without checking out the right-hand side of those re-assignments you can't quickly know what the type of the variable is, unless you have a smart editor like VS Code (although I guess you could say that doesn't matter since they're supposed to be "temporary" — at least until they're not!).

All in all, poor readability. Fragile and Unstable. 5 times harder for someone new to understand. Also, some would say underscores are "ugly", especially in languages like JavaScript where they hardly show up.

Okay, so why don't we just avoid this infestation of temporary underscores, and nest them into one gigantic one-liner?

It's a mess. The underscore is gone, but who in the world can understand this at a glance? How easy is it to tell how the data flows throughout this code and make any necessary adjustments?

Understanding, at a glance — this is what we should strive for with every line of code we write.

The pipeline operator greatly outshines every other method, giving us both freedom from temporary variables and readability. It was designed for this.

Here the % only exists within this particular pipeline.

Method chaining?

Who hasn't used and combined heavily popular array methods like map, filter, and sort? Very hard to avoid in applications involving any form of list manipulation.

This is actually great. There aren't any temporary variables or unreadable nesting here either and we can easily follow the chain from start to finish.

The formatting lets us easily add more methods at any point in the chain; feature-packed editor like VS Code can easily swap the processing order of two methods, with the Ctrl + Up and Ctrl + Down shortcuts.

There's a reason why libraries like core http and jQuery are designed like this:

The problem with method chaining is that, we simply can't use it everywhere. If the class wasn't designed like that we're stuck and out in the cold.

It doesn't work very well with generator methods, async/await and function/method calls outside the object, like we saw here:

But all this and more work with the pipeline operator; even object literals and the async import function.

Could have been F# pipes

We would have been using the pipeline operator very similarly to F# pipes, with the above turning out like this instead:

There was an alternative design. But you can already see how this makes for an inferior alternative: Only single-function arguments are allowed and the operation is more verbose. Unless the operation is already a single-argument function call.

Its weird handling of async/await was also a key reason why it got rejected -- along with memory usage concerns. So, forget about F# pipes in JS!

Use the pipeline operator right now

Yes you can — with Babel.

Babel has a nice habit of implementing features before they're officially integrated in the language; it did this for top-level await, optional chaining, and many others. The pipeline operator couldn't be an exception.

Just use the @babel/plugin-proposal-pipeline-operator plugin and you're good to.

It's optional of course — but not for long.

Prettier the code formatter is already prepared.

Even though we can't say the same about VS Code or Node.js:

Right now there's even speculation that % won't be the final symbol passed around in the pipeline; let's watch and see how it all plays out.

Final thoughts

It's always great to see new and exciting features come to the language. With the JavaScript pipeline operator, you'll cleanse your code of temporary variables and cryptic nesting, greatly boosting code readability, efficiency, and quality.

Every Crazy Thing JavaScript Does

Just when you thought you knew all the quirks. Avoid painful bugs and save valuable time with Every Crazy Thing JavaScript Does, a captivating guide to the subtle caveats and lesser-known parts of JavaScript.

Get a free copy here today.

React 19 is here! Let's learn it!

Afzal Imdad — Thu, 24 Oct 2024 07:42:11 +0000

In February this year, React announced the release of version 19, finally updating a version number that had been static for two years (React 19 is Coming, What's New?). Andrew Clark, a member of the React team, confirmed that the new version would be released in March or April.

As they say, "deadlines are the first productivity driver." Here we are at the end of April, and the new version, 19.0.0-Beta, has just been released right on schedule.

Although it's only a Beta version, it has already generated considerable excitement within the community:

Dan commented: "they did what."
Andrew Clark commented: "React 19: Never forwardRef again."
Josh W. Comeau commented: "Lots of nice quality-of-life improvements here!"

The only disappointment is, as confirmed by React member Lauren, that the React Compiler has been delayed again. It was originally named "React Forget," a fitting title given its delays.

The features of the 19.0.0-Beta release include:

An Actions feature
Three new hooks
A new API
Simplified usage of ref and context
Various supportive updates and enhanced server-side capabilities

Let's delve into each of these.

Follow me:

Github: https://github.com/afzalimdad9
Medium: https://medium.com/@afzalimdad9

Actions

Actions are not a specific API but a general term for methods that simplify data handling in requests. A valid Actions setup should simplify asynchronous operations, allowing developers to focus more on business logic rather than state management.

Here's an example to illustrate the role of Actions. Suppose we have a form where users can update their name. Previously, we might use useState to manually manage form state, error state, and submission status. The code might look something like this:

function UpdateName() {
  const [name, setName] = useState("");
  const [error, setError] = useState(null);
  const [isPending, setIsPending] = useState(false);
  const handleSubmit = async () => {
    setIsPending(true);
    const error = await updateName(name);
    setIsPending(false);
    if (error) {
      setError(error);
      return;
    }
    redirect("/path");
  };
  return (
    <div>
      <input value={name} onChange={(event) => setName(event.target.value)} />
      <button onClick={handleSubmit} disabled={isPending}>
        Update
      </button>
      {error && <p>{error}</p>}
    </div>
  );
}

With React 19's Actions, this situation is optimized. We can now use the useTransition hook to handle form submissions, which automatically manages the pending state, making our code much cleaner:

function UpdateName() {
  const [name, setName] = useState("");
  const [error, setError] = useState(null);
  const [isPending, startTransition] = useTransition();
  const handleSubmit = async () => {
    startTransition(async () => {
      const error = await updateName(name);
      if (error) {
        setError(error);
        return;
      }
      redirect("/path");
    });
  };
  return (
    <div>
      <input value={name} onChange={(event) => setName(event.target.value)} />
      <button onClick={handleSubmit} disabled={isPending}>
        Update
      </button>
      {error && <p>{error}</p>}
    </div>
  );
}

In the handleSubmit function, the logic for the asynchronous request is encapsulated within the callback passed to startTransition. When startTransition is invoked, React immediately sets isPending to true, indicating that the transition (request) is underway. React then performs the startTransition callback asynchronously in the background. Once the request is complete, React automatically switches isPending back to false.

This functionality binds isPending to the disabled attribute of the submit button, so the button automatically becomes disabled during the request, preventing double submissions.

Summarizing React's conventions for Actions:

Naming Convention: Functions using asynchronous transitions can be referred to as "Actions."
Pending State: Actions automatically manage the pending state of data submissions. When a request is initiated, the pending state is automatically activated, and it resets once the final state updates. This ensures users receive feedback while data is submitted and the pending state is cleared after the request completes.
Optimistic Updates: Actions support optimistic updates, displaying the correct submission result to users while the request is pending. If the request ultimately fails, the optimistic update automatically reverts to its original state.
Error Handling: Actions include built-in error handling. When a request fails, you can use error boundaries to display error messages.
Form Support: elements now support passing functions to action and formAction attributes. By passing a function to the action attribute, you can handle form submissions with Actions, automatically resetting the form after submission. This simplifies the process of handling forms, making it more intuitive and efficient.

Three New Hooks

Why discuss Actions first? Because based on Actions, React 19 introduces three new hooks, each designed to simplify the complex handling of state by developers.

useOptimistic

The main purpose of useOptimistic is to allow us to assume success in asynchronous operations and update the state accordingly while waiting for the actual results.

Here's a basic usage example:

import { useOptimistic } from 'react';
function AppContainer() {
 const [optimisticState, addOptimistic] = useOptimistic(
 state,
 // updateFn
 (currentState, optimisticValue) => {
 // merge and return new state
 // with optimistic value
 }
 );
}

In this setup:

state: Initial state and the state returned when no operations are in progress.
updateFn(currentState, optimisticValue): A pure function that takes the current state and the optimistic value passed by addOptimistic, returning the merged optimistic state.
optimisticState: The optimistic state. If no operations are in progress, it equals state; otherwise, it equals the result of updateFn.
addOptimistic: A function for triggering optimistic updates, accepting an optimisticValue of any type and passing it to updateFn.

useOptimistic has a wide range of applications, such as form submissions, liking, bookmarking, deleting, and other scenarios that require immediate feedback.

Here's an example of optimistic updating for data deletion:

import React, { useState } from 'react';
import { useOptimistic } from 'react';
function AppContainer() {
    // Default data
  const [state, setState] = useState([
    { id: 1, name: 'Item 1' },
    { id: 2, name: 'Item 2' },
    { id: 3, name: 'Item 3' },
  ]);
    // Define the update function, which updates the state based on the current state and the optimistic value (the ID of the item to be deleted)
  const updateFn = (currentState, optimisticId) => {
    return currentState.filter(item => item.id !== optimisticId);
  };
  const [optimisticState, addOptimistic] = useOptimistic(state, updateFn);
    // Delete item
  const deleteItem = async (itemId) => {
    // Optimistically update the UI first
    addOptimistic(itemId);
    // Simulate API request delay
    setTimeout(() => {
      // Assume this is the API delete call, update the actual state after completion
      setItems(currentItems => currentItems.filter(item => item.id !== itemId));
    }, 2000);
  };
  return (
    <div>
      <h1>Optimistically Deleting Items</h1>
      <ul>
        {optimisticState.map(item => (
          <li key={item.id}>
            {item.name} <button onClick={() => deleteItem(item.id)}>Delete</button>
          </li>
        ))}
      </ul>
    </div>
  );
}
export default AppContainer;

useActionState

useActionState, formerly known as useFormState, has a new name in version 19, and its return parameters have changed (oddly, React has not yet updated the useActionState documentation, do they think developers don't read documentation? 🐶).

Here is the latest basic usage of useActionState:

const [state, action, pending] = useActionState(fn, initialState, permalink?);

The return parameters include:

state: Represents the current state. At the first render, it equals the initial state initialState. After an operation, it will be the most recent result.
action: This is a function used to perform operations. When this function is called, it will trigger the execution of fn and update the state.
pending: This is a new parameter, a boolean value indicating whether an operation is currently being performed. If an operation is in progress, it is true; otherwise, it is false.

The parameters are:

fn: This is a function that is triggered when the action is called, subsequently returning a new value.
initialState: This is the initial value, set to null if there is no initial value.
permalink: This is an optional string parameter, typically used in conjunction with server actions.

Here's an example of using useActionState with form action to implement name update functionality. If the update fails, an error
is displayed on the page; if successful, the page redirects to the updated page:

import { useActionState } from 'react';
function ChangeName({ name, setName }) {
  // Using useActionState to create a state associated with form operations
  const [error, submitAction, isPending] = useActionState(
    // First parameter: Form operation function
    async (previousState, formData) => {
      // Define the logic for form operations here
      // This function will be called upon form submission
      // It receives two parameters:
      // - previousState: The previous state, initially null, then the return value of the last operation
      // - formData: A form data object, can retrieve form fields using formData.get("name")
      const error = await updateName(formData.get("name"));
      // If there is an error during the operation, return the error message
      if (error) {
        return error;
      }
      // If the operation is successful, perform a redirection
      redirect("/path");
    }, 
    // Second parameter: Initial state, set here as null since the initial state is not crucial
    null
  }
  // Return the form along with related state and actions
  return (
    <form action={submitAction}>
      <input type="text" name="name" defaultValue={name} />
      <button type="submit" disabled={isPending}>
        Submit
      </button>
      {/* Display error messages if any */}
      {error && <p>{error}</p>}
    </form>
  );
}

useFormStatus

useFormStatus is used to retrieve status information about form submissions. Its basic usage is as follows:

const { pending, data, method, action } = useFormStatus();

Where:

pending: A boolean value indicating whether the parent <form> is currently submitting. If true, the form is in the process of being submitted; otherwise, it is false.
data: An object implementing the FormData interface, containing data from the parent <form> that is currently being submitted. If there is no ongoing submission or no parent <form>, it is null.
method: A string value indicating the HTTP method used by the parent <form>, which can be either get or post.
action: A reference to the function passed to the parent <form>'s action attribute. If there is no parent <form>, this property is null.

For example, developers can retrieve form status using useFormStatus in a form action:

import { useFormStatus } from "react-dom";
import action from './actions';
function Submit() {
  const status = useFormStatus();
  return <button disabled={status.pending}>Submit</button>
}
export default function App() {
  return (
    <form action={action}>
      <Submit />
    </form>
  );
}

This approach may feel both familiar and new. If it reminds you of context, you're on the right track. You can consider useFormStatus as a replacement for some of the capabilities of the context provider, but with a more streamlined syntax.

It's important to note two things about using useFormStatus:

The useFormStatus Hook must be called within components that are rendered inside a <form>.
useFormStatus only returns the status information of the parent <form>, not any other in the same component or its child components.

A New API - use

Previously categorized among hooks, the use has now been documented under APIs in React 19, thus becoming a new API.

use is used to read values from resources within a component, where the resource could be a Promise or a context.

Here's how it typically works:

import { use } from 'react';
function MessageComponent({ messagePromise }) {
  const message = use(messagePromise);
  const theme = use(ThemeContext);
  // …
}

use is mainly intended for higher-level frameworks like Next.js. For instance, it's recommended to use async…await instead of use if data fetching occurs in server components in Next.js. If fetching happens in client components, it's suggested to create a Promise in server components and pass it to client components as props.

use can also be used alongside Suspense boundaries. If a component calling use is wrapped in a Suspense boundary, the specified fallback will be displayed. Once the Promise resolves, the fallback is replaced by the returned data. If the Promise is rejected, the nearest error boundary's fallback will be displayed.

Simplified ref and context Usage

If you primarily utilize React's client-side capabilities, the changes discussed in this section will likely be of most interest to you.

Ref Discards forwardRef

Remember the dread of being dominated by forwardRef? With React 19, we can finally discard forwardRef. From now on, refs can be passed as props.

For example, suppose we have a functional component TextInput, a simple input box that accepts a placeholder attribute for placeholder text. Now, we want to obtain a reference to the input box in the parent component to focus on it when necessary. Here's how you could write it:

import React, { useRef } from 'react';
// Define a function component TextInput
function TextInput({ placeholder, ref }) {
  return <input placeholder={placeholder} ref={ref} />;
}
// Parent component
function ParentComponent() {
  // Create a ref to store the input box's reference
  const inputRef = useRef(null);
  // In some event handler, obtain the input box's reference and focus on it
  const focusInput = () => {
    inputRef.current.focus();
  };
  return (
    <div>
      {/* 
        Pass the inputRef to the TextInput component,
        allowing the ref to be used internally within the TextInput
      */}
      <TextInput placeholder="Enter your name" ref={inputRef} />
      <button onClick={focusInput}>Focus Input</button>
    </div>
  );
}
export default ParentComponent;

Isn't this mentally less burdensome than using forwardRef?

Context as Provider

Starting in React 19, developers can directly use <Context> as a provider, rather than using <Context.Provider>.

Suppose we have a ThemeContext used to manage theme information. In React 19, we can use <ThemeContext> as a provider like this:

import React, { createContext } from 'react';
// Create a theme context
const ThemeContext = createContext('');
// App component as the theme provider
function App({ children }) {
  return (
    <ThemeContext value="dark">
      {children}
    </ThemeContext>
  );
}

In the future, Context.Provider will be deprecated and removed.

Other Updates

This release also includes various supportive features and enhancements to server-side capabilities that are less commonly used in pure client-side React development, hence they are summarized briefly:

Server components and server actions are becoming stable features. These concepts are well-known to those familiar with Next.js/Remix but are not typically used by those who do not use these frameworks.
useDeferredValue has been updated to include a second parameter, optionally used to specify an initial value. The new usage of useDeferredValue is now: const value = useDeferredValue(deferredValue, initialValue?);
Support for writing document metadata directly in React code, i.e., writing <title>, <link>, and <meta> tags in page components will automatically add them to the application's <head>:

function BlogPost({post}) {
  return (
    <article>
      <h1>{post.title}</h1>
      <title>{post.title}</title>
      <meta name="author" content="Josh" />
      <link rel="author" href="<https://twitter.com/joshcstory/>" />
      <meta name="keywords" content={post.keywords} />
      <p>
        Eee equals em-see-squared...
      </p>
    </article>
  );
}

Support for writing stylesheets directly in React code, i.e., <link rel="stylesheet" href="…"> tags written in page components will automatically be added to the <head>.
Support for writing <script async="" src="…"> tags, which will also automatically be added to the <head>.
Support for preloading resources, which will also automatically be added to the <head>:

import { prefetchDNS, preconnect, preload, preinit } from 'react-dom'
function MyComponent() {
  preinit('https://.../path/to/some/script.js', {as: 'script' }) // loads and executes this script eagerly
  preload('https://.../path/to/font.woff', { as: 'font' }) // preloads this font
  preload('https://.../path/to/stylesheet.css', { as: 'style' }) // preloads this stylesheet
  prefetchDNS('https://...') // when you may not actually request anything from this host
  preconnect('https://...') // when you will request something but aren't sure what
}

Conclusion

To conclude, let me quote Huang Xuan: "Probably the single most critical principle I've learned from React is to be fearless in defining new conceptual abstractions and never compromise on the accuracy and composability of these definitions."

About Me

Full-stack engineer, Next.js open-source craftsman, AI advent proponent.

This year, I am committed to the development of open-source projects in the Next.js and Node.js domains and to sharing knowledge in these fields.

Follow me:

Github: https://github.com/afzalimdad9
Medium: https://medium.com/@afzalimdad9

Next-Auth in App Router of Next.js

Afzal Imdad — Tue, 20 Aug 2024 15:32:17 +0000

Next.js has recently released a stable version of App Router enriched with in-built support for layouts, templates, routing, loading, and error handling.

The current version of Next-Auth documentation is published with examples of the Page Router of Next.js. This document share approach to setting up Next.js with the Next-Auth App Router.

What is covered in this document?

Setup of Next.js app with app router.
Install Next-Auth.
Configuration of Github Provider.
Add Handler for Next-Auth
Sign in and Sign out using next-auth.
Use session in the Server Components
Use of session in the Client Components.

Set up the Next.js app with the App router.

Follow this document to create a basic next.js app with an app router.

Next.js app with App router.

Install Next-Auth

npm install next-auth

Configuration of Github Provider

Create a GitHub App first, providing you a client Id and Secret. Add a file auth.js in the lib folder.

Note: Generate a secret to add as NEXTAUTH_SECRET, it must be added in the auth options.

openssl rand -base64 32

// output
// mQ46qpFwfE1BHuqMC+qlm19qBAD9fVPgh28werwe3ASFlAfnKjM=

next. config.js

/** @type {import('next').NextConfig} */
const nextConfig = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'i.imgur.com',
      },
    ],
  },
  env: {
    GITHUB_APP_CLIENT_ID: '919b87qa4sdfs1qdc44f53baf9',
    GITHUB_APP_CLIENT_SECRET: '2aeq98df3f8cwqerc2d03a8360e993c115ba8d5f71de9',
    NEXTAUTH_SECRET: 'mQ46qpFwfE1BHuqMC+qlm19qBAD9fVPgh28werwe3ASFlAfnKjM=',
  },
};

module.exports = nextConfig;

import { NextAuthOptions } from 'next-auth';
import GithubProvider from 'next-auth/providers/github';
export const authOptions: NextAuthOptions = {
  // Secret for Next-auth, without this JWT encryption/decryption won't work
  secret: process.env.NEXTAUTH_SECRET,

  // Configure one or more authentication providers
  providers: [
    GithubProvider({
      clientId: process.env.GITHUB_APP_CLIENT_ID as string,
      clientSecret: process.env.GITHUB_APP_CLIENT_SECRET as string,
    }),
  ],
};

Add Handler for Next-Auth

Create a file route.js in the folder /app/auth/[…nextauth]

Next-Auth Handler

import NextAuth from 'next-auth';
import { authOptions } from '@/app/lib/auth';

const handler = NextAuth(authOptions);
export { handler as GET, handler as POST };

Sign in and Sign out using next-auth

All requests to any of these paths /api/auth/* (signIn, callback, signOut, etc.) will be handled by NextAuth.js.

Once you click the button, log in, and authorize the app, it will get a cookie in the session.

Next-Auth default Sign in page
After successful sign-in.

Next-Auth token

Sign Out

use this link /api/auth/signout to sign out.

Session in API routes.

API route handlers are considered server components. It can be a static or dynamic handler but these are always on the server side.

import { authOptions } from '@/app/lib/auth';
import { getServerSession } from 'next-auth';
import { NextResponse } from 'next/server';

export async function GET(request: Request) {
  const session = await getServerSession(authOptions);
  console.log(session);
  return NextResponse.json({
    id: 1,
  });
}

Output

{
  user: {
    name: 'Rohit Kumar Khatri',
    email: 'er.rohitkumar@outlook.com',
    image: 'https://avatars.githubusercontent.com/u/34018015?v=4'
  }
}

Session in Server Components

It is also similar in all server components. Use the same function as mentioned above.

await getServerSession(authOptions);

Session in Client Components

First, add Session Provider in the Root Layout

'use client';

import { SessionProvider } from 'next-auth/react';
import { ReactNode } from 'react';

export default function NextAuthProvider({
  children,
}: {
  children: ReactNode;
}) {
  return <SessionProvider>{children}</SessionProvider>;
}

import { useSelectedLayoutSegments } from 'next/navigation';
import './globals.css';
import { Inter } from 'next/font/google';
import Footer from '@/app/components/Footer';
import Navbar from '@/app/components/Navbar';
import NextAuthProvider from '@/app/context/NextAuthProvider';
import { ReactNode } from 'react';
const inter = Inter({ subsets: ['latin'] });

export default function RootLayout({ children }: { children: ReactNode }) {
  return (
    <html lang="en">
      <body className={`inter.className`}>
        <NextAuthProvider>
          <div className="w-10/12 m-auto text-center bg-white flex flex-col min-h-screen">
            <div>
              <Navbar />
            </div>
            <div className="grow">{children}</div>
            <Footer />
          </div>
        </NextAuthProvider>
      </body>
    </html>
  );
}

Now use session in any client component.

'use client';

import { useSession } from 'next-auth/react';

export default function ClientComponent() {
  const { data: session, status } = useSession();
  return (
    <div>
      ClientComponent {status}{' '}
      {status === 'authenticated' && session.user?.name}
    </div>
  );
}

Why NextJS Sucks

Afzal Imdad — Tue, 20 Aug 2024 13:44:54 +0000

I’ve used NextJS for static websites because the experience with amplify hosting is so insanely easy. The fact that I go on the AWS console and connect a github repo and it just works, and runs with lambda, and is super cheap (unless I get DDOS’d)… that’s just too good to say no to in some cases.

Even though server side rendering hasn’t been required in years in order for google to index and find your content, the developer experience for toy websites is too good to pass up.

But for a complex SaaS project, I see very few benefits and some serious downsides of NextJS.

NodeJS sucks for SSR

𝐑𝐞𝐚𝐜𝐭 𝐫𝐞𝐧𝐝𝐞𝐫𝐢𝐧𝐠 𝐨𝐧 𝐭𝐡𝐞 𝐬𝐞𝐫𝐯𝐞𝐫 𝐚𝐝𝐝𝐬 𝐚 𝐝𝐢𝐦𝐞𝐧𝐬𝐢𝐨𝐧 𝐨𝐟 𝐜𝐨𝐦𝐩𝐥𝐞𝐱𝐢𝐭𝐲 𝐭𝐨 𝐭𝐡𝐞 𝐚𝐩𝐩𝐥𝐢𝐜𝐚𝐭𝐢𝐨𝐧 𝐛𝐞𝐜𝐚𝐮𝐬𝐞 𝐲𝐨𝐮’𝐫𝐞 𝐦𝐚𝐤𝐢𝐧𝐠 𝐍𝐨𝐝𝐞𝐉𝐒 𝐝𝐨 𝐬𝐨𝐦𝐞𝐭𝐡𝐢𝐧𝐠 𝐢𝐭’𝐬 𝐫𝐞𝐚𝐥𝐥𝐲 𝐛𝐚𝐝 𝐚𝐭 𝐝𝐨𝐢𝐧𝐠.

NodeJs is single threaded. In the ideal case that it’s designed for, requests should be I/O bound. A complex page requiring much SSR will hamstring the ability to serve concurrent requests. Here is a talk by a former coworker of mine on his experience optimizing server side rendering through large demand spikes.

Now, of course, most apps (including yours) are not going to have the same kind of spikes that Walmart has on black Friday. But you always gotta think about what you’re gaining in exchange of what you're giving up. From what I recall, my friend’s Walmart situation ended up boiling down to NodeJS getting hung up on page rendering for too long, then the operating system’s http request queue would expand too large, because they weren’t configured for load shedding, and the servers would become unresponsive as described in that load shedding article.

The autoscaling infrastructure would come to the rescue and constantly spin up new servers, but they spent millions of dollars on that, and still experienced availability loss (users getting a broken experience and having to reload). In order to fix it my friend ended up basically having to inject setTimeouts all over the place when rendering the app.

Now of course there’s ways to avoid all of this such as static site pregeneration, or hosting on serverless. This is part of the reason why serverless is a popular choice for NextJS. But my favorite way of avoiding this particular bit of complexity is just not server-rendering react in nodejs.

Security takes a back seat to coolness

Many nextJS features require allowing the browser to inject inline scripts. Nextjs’s implementation of suspense, and also usage of the appDir feature (which you basically always use), using next/font, and anything you put in your rootLayout all gets injected into the app as inline scripts.

Open up any nextJS website and you'll see a bunch of inline scripts like the screenshot below, from one of my NextJS pages:

Those are a bunch of inline scripts. Inline scripts are bad, because the only actually reliable way to prevent reflected XSS attacks is with content security policy headers that prevent the execution of inline scripts. A strong CSP policy is the golden standard for XSS prevention. And the main thing you need to do from a CSP standpoint is to avoid inline scripts.

If you just instruct the browser to not execute inline scripts, stored XSS is impossible. But if you use any of the NextJS features that require inline scripts, you cannot have a CSP policy to forbid inline scripts. Because of that, you have to settle for something worse, which is allowing only inline scripts that match a certain nonce (computed randomly at load time).

In order to do that with nextJS, you have to write a significant amount of code and jump through hoops (see docs on how to do it if you want your head to spin). Fun side effect of this is, even if you put a CDN in front of your NextJS cluster, there won't be any edge location caching because the nonce has to be different for every session (if it's not, it defeats the purpose of the nonce and you might as well just allow inline scripts).

NextJS doesn’t respect your time

Their API is incredibly unstable and they break it all the time. Basically every 6 months. The upgrade from 13 to 14 was hard.

The hosting infrastructure is much worse

If you host a SPA with a CDN, you can serve 30 million customers a month for a few bucks. If you use NextJS instead, you have a couple of choices:

Go serverless and be vulnerable to insanely massive bills from a simple naive DDOS
Use ECS/EC2 and then have the potential to lose availability because you scale up too slow during a demand spike (related to point 1 above)
Both choices suck. Both choices will cost you a lot more.

In addition, you give up the globally distributed nature of a CDN, which caches files near your users. It also handles caching (based on e-tags) between your user and the edge location. It’s a LOT to give up and I’m convinced that many people who think this is a good idea just don’t know wtf a CDN even is, or all it does for you. They’re like the developer in the hero picture of this article.

Why NextJS Sucks

Afzal Imdad — Tue, 20 Aug 2024 13:44:54 +0000

Even though server side rendering hasn’t been required in years in order for google to index and find your content, the developer experience for toy websites is too good to pass up.

But for a complex SaaS project, I see very few benefits and some serious downsides of NextJS.

NodeJS sucks for SSR

Security takes a back seat to coolness

Open up any nextJS website and you'll see a bunch of inline scripts like the screenshot below, from one of my NextJS pages:

NextJS doesn’t respect your time

Their API is incredibly unstable and they break it all the time. Basically every 6 months. The upgrade from 13 to 14 was hard.

The hosting infrastructure is much worse

If you host a SPA with a CDN, you can serve 30 million customers a month for a few bucks. If you use NextJS instead, you have a couple of choices:

10 GitHub repositories to become a better JavaScript Developer

Afzal Imdad — Sun, 18 Aug 2024 13:36:00 +0000

With the introduction of libraries and Frameworks like ReactJS, VueJS, Angular, SvelteJS and much more and the runtime environments like Node.js and Deno the demand for JavaScript Developers has exploded. From seed startups to the big tech companies, everyone is using JavaScript in one or the other form.

Be it a library like ReactJS or complex Frameworks like Angular or runtime environments like Node.js and Deno. They all have one thing in common that they can be used to write JavaScript code in a more structured, robust and scalable manner which can be easy to maintain, debug and scale .

With that being said it becomes more important for you as a JavaScript Developer to level up your skills with the best practices and concepts regarding it.

In this post I've included 10 such GitHub repositories which will help you to become a better JavaScript Developer and will also help you to follow best practices, clear your concepts and write scalable and clean code.

1. JavaScript Style Guide

GitHub🌟: 111K+

This repository includes style guides for JavaScript, React, CSS-in-JavaScript,CSS & SaSS and Ruby. It is having the code snippets with good and bad practices followed the explanations and references which will help you to write more robust,clean and error free code.

2. Node Best Practices

GitHub🌟: 68K+

This repository is a summary and curation of the top-ranked content on Node.js best practices. It has the largest compilation and it is growing every week. Currently more than 80 best practices, style guides and architectural tips are presented.

3. [JavaScript Algorithms

](https://github.com/trekhleb/javascript-algorithms)
GitHub🌟: 113K+

This repository contains JavaScript based examples of many popular algorithms and data structures.
Each algorithm and data structure has its own separate README with related explanations and links for further reading (including ones to YouTube videos).

4. JavaScript Questions

GitHub🌟: 35K+

This repository contains a long list of (advanced) JavaScript questions along with their explanations and gets frequently updated.

5. 33 JS Concepts

GitHub🌟: 41K+

This repository is a collection of articles and books on the 33 JavaScript Concepts which every JavaScript Developer should know in order to have an in-depth knowledge of the language and its working.

6. Clean Code JavaScript

GitHub🌟: 53K+

This repository consists of the software engineering principles, from Robert C. Martin's book Clean Code, adapted for JavaScript. It's a guide for producing readable, reusable and refactorable software in JavaScript.

7. You Don't Know JS

GitHub🌟: 142K+

This is a series of books diving deep into the core mechanisms of the JavaScript language. The 2nd edition of the series is currently in progress, while the first edition is available here

8. Awesome JavaScript

GitHub🌟: 24K+

A collection of awesome browser-side JavaScript libraries and resources. This repository contains a list of variety of frameworks, template engines, articles and post, documentations, reactive & functional programming and much more which will increase your resourcefulness and might also help you to choose the tech stack for your next projects.

9. 30 seconds of Code

GitHub🌟: 79K+

This repository contains a huge collection of short JavaScript code snippets which can be super useful while working on your JavaScript projects thus increasing your efficiency and knowledge.

10. Project Guidelines

GitHub🌟: 24K+

This repository contains a set of best practices for JavaScript projects which will develop your skills to follow the best practices this skill is super useful and important for any developer and will definitely help you to stand apart from the other developers. Following the best practices in your JavaScript projects will definitely increase your chance of being accepted for a job position.

Bonus

Awesome Repos

Awesome Repos has a number of resourceful repositories packed in just one place. All you have to do is just visit this repository. The repository is still growing and welcomes PRs.

Awesome JavaScript Projects

If you are a beginner or new to JavaScript and want to improve your JavaScript skills by building projects then this repository can be super helpful for you. It contains a collection of projects written in vanilla JavaScript (with NO FRAMEWORKS & LIBRARIES INVOLVED).

Vote Of Thanks

Thank you so much for reading this post and I hope you find these repositories as useful as I do and will help you to become better JavaScript developer. Feel Free to give any suggestions and if you like my work you can follow me on medium

Integrating Capacitor with Next.js: A Step-by-Step Guide

Afzal Imdad — Sat, 27 Jul 2024 14:34:19 +0000

In this guide, we’ll walk through how to integrate Capacitor with a Next.js project to build cross-platform mobile apps. Capacitor is a powerful tool that helps turn web applications into native mobile experiences.

Prerequisites

Before you start, ensure you have the following installed:

Node.js and npm
Next.js
Android Studio (for Android development)
Xcode (for iOS development, macOS only)

Step 1: Set Up Next.js Project

First, set up your Next.js project if you haven’t already:

npx create-next-app@latest
cd your-next-app

Step 2: Install Capacitor

Next, install Capacitor core and CLI:

npm install @capacitor/core
npm install -D @capacitor/cli

Initialize Capacitor in your project

npx cap init

Follow the prompts to configure your app. For example:

appId: com.example.app
appName: example

Step 3: Configure Capacitor

Create or update the capacitor.config.ts file:

import type { CapacitorConfig } from '@capacitor/cli';
const config: CapacitorConfig = {
  appId: 'com.example.app',
  appName: 'example',
  webDir: 'out', // Ensure this matches your Next.js output directory
};
export default config;

Step 4: Install Platform Plugins

Install the Capacitor platform plugins for Android and iOS:

npm install @capacitor/android @capacitor/ios

Step 5: Add Platforms

Add the Android and iOS platforms to your project:

npx cap add android
npx cap add ios

Step 6: Configure Next.js for Static Export

Update your next.config.mjs to enable static exports and disable image optimization:

/** @type {import('next').NextConfig} */
const nextConfig = {
  reactStrictMode: true,
  images: {
    unoptimized: true,
  },
  output: 'export',
};
export default nextConfig;

Step 7: Build and Export Your Project

Build and export your Next.js project:

npm run build

After a successful build, if the folder and file structure looks like this, the specific file names do not matter. It means the build was successful

After a successful build, if the folder and file structure looks like this, the specific file names do not matter. It means the build was successful.

Step 8: Sync Capacitor

Sync the Capacitor configuration and assets:

npx cap sync

Step 9: Open and Run the Android Project

Open your Android project in Android Studio:

npx cap open android

Run your app on an Android device or emulator directly from Android Studio.

Step 10: Open and Run the iOS Project

For macOS users, open your iOS project in Xcode:

npx cap open ios

Run your app on an iOS device or simulator from Xcode.

Step 11:Generate Apk

Before generate apk file you must have to create keyStore:

keytool -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000
Enter keystore password: 123456
Enter key return password for : 123456
What is your first and last name?
What is the name of your organizational unit?
What is the name of your organization?
What is the name of your City or Locality?
What is the name of your State or Province?
What is the two-letter country code for this unit?
Is CN=your name, OU=your organizational unit, O=your organization, L=your city, ST=your state, C=your country correct?

Step 12:Change the file Directory

move my-release-key.keystore file into Android folder

npx cap build android --keystorepath my-release-key.keystore --keystorepass 123456 --keystorealias alias_name --keystorealiaspass 123456 --androidreleasetype APK

Step 13:Build Apk

npx cap build android

Step 14:Build Apk Directory

android>app>build>apk>release

10 Expert Performance Tips Every Senior JS React Developer Should Know

Afzal Imdad — Sat, 22 Jun 2024 18:17:46 +0000

Elevate your React development skills with 10 advanced performance tips tailored for senior JavaScript developers. Learn how to optimize your code and enhance the efficiency of your React applications. Master the techniques that will set you apart in the competitive world of web development.

1. Use useMemo for Expensive Calculations

When performing expensive calculations or data transformations, use the useMemo hook to memoize the result and prevent unnecessary re-calculations.

import React, { useMemo } from 'react';

const MyComponent = ({ data }) => {
  const transformedData = useMemo(() => {
    // Perform expensive data transformation here
    return data.map(item => item * 2);
  }, [data]);
  return (
    <div>
      {/* Use transformedData here */}
    </div>
  );
};

2. Use useCallback for Memoized Functions

When passing callback functions as props, use the useCallback hook to memoize the function and prevent unnecessary re-renders of child components.

import React, { useCallback } from 'react';

const ParentComponent = () => {
  const handleButtonClick = useCallback(() => {
    // Handle button click here
  }, []);
  return (
    <ChildComponent onClick={handleButtonClick} />
  );
};

3. Use React.memo for Performance Optimization

To optimize functional components, use the React.memo higher-order component to memoize the component and prevent re-rendering if the props haven't changed.

import React from 'react';

const MyComponent = React.memo(({ prop1, prop2 }) => {
  // Render component here
});

4. Use Virtualized Lists for Efficient Rendering

For long lists, use a virtualized list library like react-window or react-virtualized to only render visible items, thus improving rendering performance.

import React from 'react';
import { FixedSizeList } from 'react-window';

const MyListComponent = ({ data }) => {
  const renderRow = ({ index, style }) => {
    const item = data[index];
    return (
      <div style={style}>{item}</div>
    );
  };
  return (
    <FixedSizeList
      height={300}
      width={300}
      itemSize={50}
      itemCount={data.length}
    >
      {renderRow}
    </FixedSizeList>
  );
};

5. Use Code Splitting for Lazy Loading

Split your code into smaller chunks and load them lazily using dynamic imports and React's lazy and Suspense components. This improves initial load time and only loads necessary code when needed.

import React, { lazy, Suspense } from 'react';

const LazyComponent = lazy(() => import('./LazyComponent'));
const App = () => {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <LazyComponent />
    </Suspense>
  );
};

6. Use Memoization for Expensive Calculations

Memoization involves caching the results of expensive function calls and returning the cached result when the same inputs occur again, saving unnecessary computations.

const memoizedExpensiveFunction = useMemo(() => {
  // Expensive computation here
}, [input]);

7. Optimize Rendering with React.Fragment

When rendering multiple elements without a container element, use React.Fragment or the shorthand syntax <>...</> to avoid excess DOM nodes.

import React from 'react';

const MyComponent = () => {
  return (
    <>
      <div>Element 1</div>
      <div>Element 2</div>
    </>
  );
};

8. Use Function Components with Hooks

Use function components with hooks instead of class-based components as they offer simpler and more performant code.

import React, { useState } from 'react';

const MyComponent = () => {
  const [count, setCount] = useState(0);
  const handleIncrement = () => {
    setCount(count + 1);
  };
  return (
    <div>
      <button onClick={handleIncrement}>Increment</button>
      <p>Count: {count}</p>
    </div>
  );
};

9. Avoid Inline Function Definitions

Avoid defining functions inline within render methods as they create a new reference on each render, leading to unnecessary re-renders of child components.

import React, { useCallback } from 'react';
const ParentComponent = () => {
  const handleButtonClick = useCallback(() => {
    // Handle button click here
  }, []);
  return (
    <ChildComponent onClick={handleButtonClick} />
  );
};

10. Use `React.PureComponent` or `React.memo` for Performance Optimization

Use React.PureComponent or React.memo to prevent unnecessary re-rendering of components by performing shallow prop comparisons.

import React, { PureComponent } from 'react';
class MyComponent extends PureComponent {
  render() {
    // Render component here
  }
}
export default MyComponent;

These performance tips can help improve the efficiency and responsiveness of your ReactJS applications. Utilizing functional architecture, memoization, and code-splitting techniques can greatly enhance the overall performance of your React components.

Don't be shy to clap, consider clap if you find this useful. If you want you can clap multiple times also :P, just try :D

Thank you for reading until the end. Before you go:
Please consider clapping and following the writer! 👏

Cookie consent in NextJs

Afzal Imdad — Mon, 10 Jun 2024 04:27:39 +0000

This article discusses how to add cookie consent to a NextJs app using cookies-next package.

Install the required packages:

To install the package, type one of the following commands based on your package manager

For npm:

npm install cookies-next

For yarn:

yarn add cookies-next

Cookie consent implementation:

When there is no cookie present, the cookie consent popup should be shown.

cookies-next package has hasCookie, setCookie functions with which the cookies can be accessed and managed. Here is how its managed in a React component.

const [showConsent, setShowConsent] = React.useState(true);
React.useEffect(() => {
  setShowConsent(hasCookie("localConsent"));
}, []);
const acceptCookie = () => {
  setShowConsent(true);
  setCookie("localConsent", "true", {});
};

Here is a full example of how a cookie consent component works in Next.js. Add the component to your pages/index.js to be visible.

import React from "react";
import { hasCookie, setCookie } from "cookies-next";

const CookieConsent = (props) => {
  const [showConsent, setShowConsent] = React.useState(true);

  React.useEffect(() => {
    setShowConsent(hasCookie("localConsent"));
  }, []);

  const acceptCookie = () => {
    setShowConsent(true);
    setCookie("localConsent", "true", {});
  };

  if (showConsent) {
    return null;
  }

  return (
    <div className="fixed inset-0 bg-slate-700 bg-opacity-70">
      <div className="fixed bottom-0 left-0 right-0 flex items-center justify-between px-4 py-8 bg-gray-100">
        <span className="text-dark text-base mr-16">
          This website uses cookies to improve user experience. By using our website you consent to all cookies in accordance with our Cookie Policy.
        </span>
        <button className="bg-green-500 py-2 px-8 rounded text-white" onClick={() => acceptCookie()}>
          Accept
        </button>
      </div>
    </div>
  );
};

export default CookieConsent;

Note: The above example uses tailwindcss. To know more, refer here

Be Amazed!

Hooray! We have successfully added cookie consent in Next.js.

Stop Using TypeScript Interfaces

Afzal Imdad — Sun, 09 Jun 2024 07:40:26 +0000

Why You Should Use Types Instead

Join our Vibrant Discord Community for exclusive information and insightful discussions

Types and Interfaces are profound features used inside every TypeScript program.

However, since types and interfaces are quite similar in function, it begs the question: Which is better?

Today, we will evaluate types and interfaces, then reach a conclusion as to why you should use types over interfaces in most scenarios.

So without further ado… Lets dive right in.

So What Are The Differences?

Let’s analyze this Person type and interface definition:

type Person = {
  name: string
  age: number
}
interface Person {
  name: string
  age: number
}

It is clear types and interfaces have similar syntax, with the key difference being that the type uses = to define the shape of an object unlike the interface.

However, there is much more to it than this.

Let’s dig deeper to explore and evaluate types and interfaces together.

Extensibility

In terms of extensibility, many argue interfaces are obvious winners since interfaces may extend other interfaces using extends.

// Extensibility Example
interface Person extends Job {
  name: string
  age: number
}
interface Job {
  job: string
}
// Properties of Person & Job used.
const person: Person = {
  name: "John",
  age: 25,
  job: "Full-Stack Web Developer",
}

Here the Person interface extends Job, and as a result the properties of the Job interface merge into Person.

On the other hand, types also offer extensibility by leveraging the union | or intersection & operators to merge existing types.

Interfaces cannot express this behavior directly.

// ✅ Works 
type Person = {
  name: string
  age: number
} & { job: string }
// ❌ Does not work 
interface Person {
  name: string
  age: number
} & { job: string }

Implementation

Interfaces in TypeScript are compatible with Object Oriented Programming (OOP) like in other languages, e.g. Java or C#.

This means interfaces can be implemented in classes using implements.

Let’s now define Person as a class, and implement a new interface called Work and satisfy the contract between them.

// Implementation Example
interface Work {
  doWork: () => void
}
class Person implements Work {
  name: string
  age: number
  constructor(name: string, age: number) {
    this.name = name
    this.age = age
  }
  // doWork method implemented to satisfy the `Work` interface.
  doWork() {
    console.log("Working...")
  }
}
const person = new Person("John", 25)
person.doWork()

Therefore if you use OOP frequently, interfaces will be more applicable than types, as types cannot be directly implemented by classes.

Performance

When it comes to performance, we are talking about the performance of “type-checking” done by the TypeScript compiler, which decreases exponentially as your codebase increases in size.

This is why we benchmark which of types or interfaces are superior in terms of type-checking performance.

Here is a video where Matt Pocock explains the differences between types and interfaces, and why there is actually ZERO difference in type-checking performance between types and interfaces.

Types vs Interfaces: 0 Performance Difference

Why Interfaces Could be Harmful

Interfaces in TypeScript have a unique feature called Declaration Merging.

Declaration merging is when the TypeScript compiler merges two or more interfaces with identical names into one.

// Initial Person Interface
interface Person {
  name: string
  age: number
}
// Refining the Person interface using "Declaration Merging"
interface Person {
  gender: string
}
// Using the "Merged" interface to define a new "person"
const person: Person = { name: "John", age: 25, gender: "Male" }

On the one hand, this feature allows for convenient refinement and extension of existing interfaces without changing other dependencies.

Here is an example of me re-declaring the @auth/core/types module and refining the Session interface.

Refining the @auth/core interface

This is an example of declaration merging because I refine the original interface with a new id: string attribute.

This is a justifiable use case for interfaces because it allows developers to extend library interfaces with ease.

Types do not permit this since they are immutable after creation.

On the other hand, declaration merging can have detrimental and surprising effects on your codebase for these two main reasons:

Order of Precedence: Later declarations always take precedence of prior ones. If not careful, this could lead to unexpected issues when declaration merging occurs in many parts of your program.
Unsafe Merging with Classes: Since the TypeScript compiler doesn’t check for property initialization, this could lead to unexpected runtime errors.
Types do not have this problem, and hence are more straightforward and safe to use as a result.

Conclusion

Unless specific interface behaviour is necessary, e.g. extensible refinement or implementation using OOP, your best bet is to stick with types.

Types are flexible, straightforward, and avoid pitfalls associated with declaration merging.

Types are also identical in performance compared to interfaces, providing you another reason to select types over interfaces in your codebase.

CSS Art: June

Afzal Imdad — Sat, 08 Jun 2024 04:52:22 +0000

This is a submission for Frontend Challenge v24.04.17, CSS Art: June.

Inspiration

For this CSS Art project themed around June, I focused on representing the vibrant and sunny aspects of the month, particularly the summer solstice. June is often associated with clear blue skies, warm sunshine, and blooming nature. This piece aims to capture the essence of summer with a bright, cheerful scene.

Demo

You can view the live demo and edit the code on Codepen

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>CSS Art - June</title>
<style>
  body {
    margin: 0;
    height: 100vh;
    display: flex;
    justify-content: center;
    align-items: center;
    background: linear-gradient(to top, #87CEEB, #ffffff);
  }
  .scene {
    position: relative;
    width: 300px;
    height: 300px;
  }
  .sun {
    position: absolute;
    top: 20px;
    left: 50%;
    transform: translateX(-50%);
    width: 100px;
    height: 100px;
    background: radial-gradient(circle, #FFD700, #FFA500);
    border-radius: 50%;
  }
  .grass {
    position: absolute;
    bottom: 0;
    width: 100%;
    height: 100px;
    background: linear-gradient(to top, #32CD32, #7CFC00);
    border-top-left-radius: 50%;
    border-top-right-radius: 50%;
  }
  .flower {
    position: absolute;
    width: 20px;
    height: 20px;
    background: pink;
    border-radius: 50%;
    box-shadow: 0 0 0 10px white, 0 0 0 20px pink;
  }
  .flower:nth-child(2) {
    top: 220px;
    left: 50px;
  }
  .flower:nth-child(3) {
    top: 200px;
    left: 150px;
  }
  .flower:nth-child(4) {
    top: 230px;
    left: 250px;
  }
  .butterfly {
    position: absolute;
    width: 20px;
    height: 20px;
    background: orange;
    border-radius: 50%;
    box-shadow: 10px 10px 0 orange, -10px 10px 0 orange;
  }
  .butterfly:nth-child(5) {
    top: 50px;
    left: 100px;
  }
  .butterfly:nth-child(6) {
    top: 80px;
    left: 200px;
  }
</style>
</head>
<body>
  <div class="scene">
    <div class="sun"></div>
    <div class="grass"></div>
    <div class="flower"></div>
    <div class="flower"></div>
    <div class="flower"></div>
    <div class="butterfly"></div>
    <div class="butterfly"></div>
  </div>
</body>
</html>

Journey

The process of creating this CSS Art was a delightful experience. I started by brainstorming the key elements that symbolize June: the sun, clear skies, green grass, flowers, and butterflies. Using pure CSS, I experimented with gradients, positioning, and box shadows to bring these elements to life.

Key Learnings:

Gradients and Positioning: Learned to effectively use gradients for the background and different elements.
Box Shadows: Used box shadows creatively to simulate petals and butterfly wings.

Positioning: Improved my understanding of absolute positioning for placing elements precisely.

What I'm Proud Of:

I am particularly proud of how the sun and the overall scene came together, creating a warm and inviting representation of June. The butterflies add a dynamic touch, making the scene feel more alive.

Future Improvements:

I hope to further refine my skills by adding more complex animations and interactivity to future CSS Art projects, such as making the butterflies flutter or adding a gentle sway to the flowers.

Thank you for considering my submission!