DEV Community: Muhammed Metehan Yıldırım

A Deep Dive into Shadcn UI: Detailed Examples, Code Snippets, and Playgrounds

Muhammed Metehan Yıldırım — Fri, 24 Jul 2026 08:53:27 +0000

This is a long-form, hands-on guide covering installation, patterns, components, themes, real-world examples, and best practices with Shadcn UI. It includes code snippets and step-by-step instructions you can copy into your projects. For the official installation steps, especially the latest updates, please visit the official docs: https://ui.shadcn.com/docs/installation

What is Shadcn UI?
Why pick Shadcn UI?
Key features recap
Installation (Vite-focused + Next.js, Remix, Laravel notes)
Project scaffolding (Vite + TypeScript example)
Tailwind & theme configuration
Component patterns (Button, Input, Modal, Tabs, Dropdown, Tooltip, Card)
Forms and validation (React Hook Form + Zod)
Data tables (TanStack Table integration)
State management examples (Zustand, Redux)
Advanced layouts & dashboard patterns
Accessibility best practices (a11y)
Performance optimization (code-splitting, lazy loading, image handling)
Real-world examples
- Admin Dashboard (skeleton + components)
- Blog UI (article list, markdown preview)
- E-commerce product grid (search, filters, cart UI)
Testing & CI suggestions
Common pitfalls and how to avoid them
Playground and next steps
References & resources

1. What is Shadcn UI?

Shadcn UI is a component library built on React + Tailwind CSS. The big idea behind it is giving developers fully editable source components (not opaque compiled packages) so you have complete ownership. It's highly composable and intentionally minimal in terms of opinionated styles: Tailwind is the styling layer and the UI package gives you accessible primitives and well-structured components.

2. Why pick Shadcn UI?

Ownership: Components live in your repo as editable source files, so you can change anything.
Tiny surface area: No giant runtime; you add only what you need.
Tailwind-friendly: Use utility classes and design tokens as you like.
Accessible: Components aim to follow accessibility patterns.
Playful learning curve: Good docs and examples (including official playground).

3. Key features recap

Source-first components you can edit
Pre-built primitives (Button, Dialog, Tabs, Menu, etc.)
Integration-friendly with React libraries (React Hook Form, TanStack Table)
Theme-ready (Tailwind variables + CSS variables pattern)
Official examples & playgrounds:
- https://ui.shadcn.com/examples/dashboard
- https://ui.shadcn.com/examples/playground

4. Installation

Note: For the most current install steps, visit the official docs: https://ui.shadcn.com/docs/installation

Below we focus on Vite (React + TypeScript), followed by brief notes for Next.js, Remix, and Laravel setups.

4.1 Vite + React + TypeScript (recommended quick start)

# create a Vite + React + TS project
npm create vite@latest my-shadcn-app -- --template react-ts
cd my-shadcn-app
npm install

Install Tailwind and Shadcn dependencies:

npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init -p

# shadcn CLI (scaffolding tool)
npx shadcn@latest init

Tailwind config (tailwind.config.cjs or .js):

module.exports = {
  content: ["./index.html", "./src/**/*.{js,ts,jsx,tsx,mdx}"],
  theme: {
    extend: {},
  },
  plugins: [],
};

Add base Tailwind imports (e.g. src/index.css):

@tailwind base;
@tailwind components;
@tailwind utilities;

Run the dev server:

npm run dev

Now run the shadcn CLI to add components. For example:

npx shadcn@latest add button
npx shadcn@latest add dialog
npx shadcn@latest add input

The CLI will scaffold component source files (usually under src/components/ui or a path you configured).

4.2 Next.js (short notes)

If you're using Next.js, create an app with the App Router (recommended) or Pages Router. Install Tailwind and initialize shadcn similarly. Important points:

Add ./app/**/*.{js,ts,jsx,tsx,mdx} and ./components/**/*.{js,ts,jsx,tsx,mdx} to Tailwind content.
Use server components for layout and client components for interactive parts ("use client" at the top).

4.3 Remix & Laravel (brief)

Remix: Add Tailwind, make sure the tailwind.config includes app/**/* and routes/**/*. Use the shadcn CLI to scaffold components and import them into Remix routes.
Laravel (Blade / Inertia / Vite): If using Inertia + React, install Tailwind through Vite pipeline and scaffold shadcn components in resources/js (or your JS entry). Treat components as standard React components.

5. Project scaffolding: Vite + TypeScript example

A minimal vite.config.ts with path alias and React plugin:

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

export default defineConfig({
  plugins: [react()],
  resolve: {
    alias: {
      "@": path.resolve(__dirname, "./src"),
    },
  },
});

tsconfig.json snippet for paths:

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["./src/*"]
    }
  }
}

Project structure suggestion:

/src
  /components
    /ui        <-- shadcn components live here (editable)
  /lib
  /hooks
  /pages (or /routes)
  /styles
  main.tsx
  index.css

6. Tailwind & theme configuration

Shadcn UI leverages Tailwind. For theming, use CSS variables in :root and toggle class-based theme switching for dark mode.

tailwind.config.js (example with custom colors):

module.exports = {
  darkMode: "class",
  content: ["./src/**/*.{js,ts,jsx,tsx,mdx}"],
  theme: {
    extend: {
      colors: {
        primary: "var(--color-primary)",
        background: "var(--color-bg)",
      },
    },
  },
};

src/styles/theme.css (example variables):

:root {
  --color-primary: 0 120 220; /* use as rgb values for opacity control */
  --color-bg: 255 255 255;
  --radius: 8px;
}

.dark {
  --color-primary: 100 210 255;
  --color-bg: 17 24 39;
}

Using in Tailwind (example in component):

<div className="bg-[rgb(var(--color-bg)/1)] p-4 rounded-md">
  <button className="bg-[rgb(var(--color-primary)/1)] text-white px-4 py-2 rounded">
    Primary
  </button>
</div>

Add a small hook for toggling theme (useTheme.ts):

import { useEffect, useState } from "react";

export function useTheme() {
  const [isDark, setIsDark] = useState(() =>
    document.documentElement.classList.contains("dark")
  );

  useEffect(() => {
    if (isDark) document.documentElement.classList.add("dark");
    else document.documentElement.classList.remove("dark");
  }, [isDark]);

  return { isDark, setIsDark };
}

7. Component patterns and examples

Below are many example snippets that you can copy into src/components/ui (or where your shadcn CLI put components). These are illustrative; the shadcn CLI generates similar files with better defaults and accessibility baked in.

7.1 Button

// src/components/ui/button.tsx
import React from "react";

type ButtonProps = React.ButtonHTMLAttributes<HTMLButtonElement> & {
  variant?: "default" | "destructive" | "outline" | "ghost" | "link";
  size?: "sm" | "md" | "lg";
};

export const Button: React.FC<ButtonProps> = ({
  variant = "default",
  size = "md",
  className = "",
  children,
  ...props
}) => {
  const base =
    "inline-flex items-center justify-center rounded-md font-medium transition-colors focus:outline-none focus:ring-2 focus:ring-offset-2";
  const variants: Record<string, string> = {
    default: "bg-primary text-white hover:opacity-90",
    destructive: "bg-red-600 text-white",
    outline: "border border-gray-200",
    ghost: "bg-transparent",
    link: "underline text-blue-600",
  };
  const sizes: Record<string, string> = {
    sm: "px-2 py-1 text-sm",
    md: "px-4 py-2",
    lg: "px-6 py-3 text-lg",
  };
  return (
    <button
      className={`${base} ${variants[variant]} ${sizes[size]} ${className}`}
      {...props}
    >
      {children}
    </button>
  );
};

7.2 Input & Label

// src/components/ui/input.tsx
import React from "react";

export const Label: React.FC<React.LabelHTMLAttributes<HTMLLabelElement>> = ({
  children,
  className = "",
  ...props
}) => (
  <label
    className={`block text-sm font-medium text-gray-700 ${className}`}
    {...props}
  >
    {children}
  </label>
);

export const Input = React.forwardRef<
  HTMLInputElement,
  React.InputHTMLAttributes<HTMLInputElement>
>(({ className = "", ...props }, ref) => {
  return (
    <input
      ref={ref}
      className={`mt-1 block w-full rounded-md border-gray-300 shadow-sm focus:ring-1 focus:ring-primary ${className}`}
      {...props}
    />
  );
});
Input.displayName = "Input";

7.3 Dialog (Modal) pattern

// src/components/ui/dialog.tsx (simplified)
import React from "react";

export const Modal: React.FC<{
  open: boolean;
  onClose: () => void;
  children: any;
}> = ({ open, onClose, children }) => {
  if (!open) return null;
  return (
    <div className="fixed inset-0 z-50 flex items-center justify-center">
      <div className="absolute inset-0 bg-black/40" onClick={onClose} />
      <div className="relative bg-white dark:bg-gray-800 rounded-lg p-6 shadow-lg max-w-lg w-full">
        {children}
      </div>
    </div>
  );
};

7.4 Tabs

// src/components/ui/tabs.tsx (very small)
import React, { useState } from "react";

export function Tabs({
  tabs,
}: {
  tabs: { value: string; label: string; content: React.ReactNode }[];
}) {
  const [active, setActive] = useState(tabs[0]?.value);
  return (
    <div>
      <div className="flex space-x-2">
        {tabs.map((t) => (
          <button
            key={t.value}
            onClick={() => setActive(t.value)}
            className={`px-3 py-1 rounded ${
              active === t.value ? "bg-primary text-white" : "bg-gray-100"
            }`}
          >
            {t.label}
          </button>
        ))}
      </div>
      <div className="mt-4">
        {tabs.map(
          (t) => active === t.value && <div key={t.value}>{t.content}</div>
        )}
      </div>
    </div>
  );
}

7.5 Dropdown

// src/components/ui/dropdown.tsx
import React, { useState, useRef, useEffect } from "react";

export function Dropdown({
  trigger,
  children,
}: {
  trigger: React.ReactNode;
  children: React.ReactNode;
}) {
  const [open, setOpen] = useState(false);
  const ref = useRef<HTMLDivElement>(null);

  useEffect(() => {
    function onDoc(e: MouseEvent) {
      if (ref.current && !ref.current.contains(e.target as Node))
        setOpen(false);
    }
    document.addEventListener("mousedown", onDoc);
    return () => document.removeEventListener("mousedown", onDoc);
  }, []);

  return (
    <div className="relative inline-block" ref={ref}>
      <div onClick={() => setOpen((v) => !v)}>{trigger}</div>
      {open && (
        <div className="absolute mt-2 right-0 bg-white shadow rounded-md p-2">
          {children}
        </div>
      )}
    </div>
  );
}

7.6 Tooltip (lightweight)

// src/components/ui/tooltip.tsx
import React, { useState } from "react";

export function Tooltip({
  label,
  children,
}: {
  label: string;
  children: React.ReactNode;
}) {
  const [show, setShow] = useState(false);
  return (
    <div
      className="relative inline-block"
      onMouseEnter={() => setShow(true)}
      onMouseLeave={() => setShow(false)}
    >
      {children}
      {show && (
        <div className="absolute -top-8 left-1/2 -translate-x-1/2 bg-gray-900 text-white text-xs rounded px-2 py-1">
          {label}
        </div>
      )}
    </div>
  );
}

7.7 Card

// src/components/ui/card.tsx
export const Card = ({ children }: { children: React.ReactNode }) => (
  <div className="bg-white dark:bg-gray-800 rounded-lg shadow p-4">
    {children}
  </div>
);

8. Forms and Validation (React Hook Form + Zod)

A common stack is React Hook Form + Zod for schema validation. Below is a compact example.

// src/components/forms/AuthForm.tsx
import React from "react";
import { useForm } from "react-hook-form";
import { z } from "zod";
import { zodResolver } from "@hookform/resolvers/zod";
import { Input, Label, Button } from "@/components/ui"; // adjust import path

const schema = z.object({
  email: z.string().email(),
  password: z.string().min(6),
});

type FormData = z.infer<typeof schema>;

export default function AuthForm() {
  const {
    register,
    handleSubmit,
    formState: { errors },
  } = useForm<FormData>({ resolver: zodResolver(schema) });
  function onSubmit(data: FormData) {
    console.log(data);
  }

  return (
    <form onSubmit={handleSubmit(onSubmit)} className="space-y-4">
      <div>
        <Label htmlFor="email">Email</Label>
        <Input id="email" {...register("email")} />
        {errors.email && (
          <p className="text-red-500 text-sm">{errors.email.message}</p>
        )}
      </div>
      <div>
        <Label htmlFor="password">Password</Label>
        <Input id="password" type="password" {...register("password")} />
        {errors.password && (
          <p className="text-red-500 text-sm">{errors.password.message}</p>
        )}
      </div>
      <Button type="submit">Sign in</Button>
    </form>
  );
}

Tips:

Use aria-* attributes for better accessibility.
Hook form's register works well with custom input components (forward refs required).

9. Data Tables (TanStack Table integration)

TanStack Table is a go-to for flexible tables. Shadcn examples often show this integration.

// src/components/table/ExampleTable.tsx (simplified)
import React from "react";
import { useTable, Column } from "@tanstack/react-table";

type Person = { id: number; name: string; age: number };

const data: Person[] = [
  { id: 1, name: "Alice", age: 28 },
  { id: 2, name: "Bob", age: 34 },
];

const columns: Column<Person>[] = [
  { accessorKey: "id", header: "ID" },
  { accessorKey: "name", header: "Name" },
  { accessorKey: "age", header: "Age" },
];

export default function ExampleTable() {
  // Note: @tanstack/react-table v8 uses createColumnHelper etc. This is a simplified example.
  // In practice follow TanStack docs for advanced features.
  return (
    <table className="min-w-full divide-y divide-gray-200">
      <thead>
        <tr>
          <th>ID</th>
          <th>Name</th>
          <th>Age</th>
        </tr>
      </thead>
      <tbody>
        {data.map((r) => (
          <tr key={r.id}>
            <td>{r.id}</td>
            <td>{r.name}</td>
            <td>{r.age}</td>
          </tr>
        ))}
      </tbody>
    </table>
  );
}

Add filtering, sorting and pagination from TanStack docs. Combine with Shadcn UI controls for inputs, selects and pagination controls.

10. State Management Integration

10.1 Zustand (lightweight)

// src/store/useStore.ts
import create from "zustand";

type CartItem = { id: number; title: string; qty: number };
type State = { cart: CartItem[]; add: (item: CartItem) => void };

export const useStore = create<State>((set) => ({
  cart: [],
  add: (item) => set((state) => ({ cart: [...state.cart, item] })),
}));

Use in components:

const add = useStore((s) => s.add);
add({ id: 1, title: "Widget", qty: 1 });

10.2 Redux Toolkit (for large apps)

// store/cartSlice.ts
import { createSlice } from "@reduxjs/toolkit";

const cartSlice = createSlice({
  name: "cart",
  initialState: [] as any[],
  reducers: {
    add: (state, action) => {
      state.push(action.payload);
    },
  },
});

export const { add } = cartSlice.actions;
export default cartSlice.reducer;

Connect to UI through useDispatch and useSelector as usual.

11. Advanced layouts & dashboard patterns

A typical dashboard layout includes:

A left navigation (sidebar)
Top bar / header
Main content area with cards and data visualizations
Responsive collapse behavior for small screens

Example skeleton:

export function DashboardLayout({ children }: { children: React.ReactNode }) {
  return (
    <div className="min-h-screen flex">
      <aside className="w-64 bg-white dark:bg-gray-900 border-r p-4">
        {/* Sidebar contents: logo, nav items */}
      </aside>
      <div className="flex-1 flex flex-col">
        <header className="h-16 border-b p-4 flex items-center justify-between">
          {/* topbar */}
        </header>
        <main className="p-6">{children}</main>
      </div>
    </div>
  );
}

Combine with charts (Recharts, Chart.js, or Recharts) inside cards for analytics panels.

12. Accessibility (a11y) best practices

Shadcn components aim to follow accessible patterns, but you are still responsible for:

Keyboard navigation (tab order, focus management)
Proper ARIA roles and labels
Semantic HTML for forms and buttons
Color contrast (WCAG AA/AAA guidelines)
Screen reader testing (NVDA, VoiceOver)

Checklist:

Use aria-label or <label> for inputs.
Ensure modal traps focus and restores focus on close.
Provide skip-links for keyboard users.
Test color contrasts and don't rely on color alone for state.

13. Performance optimization

Tree-shaking: Import components directly from your local components/ui to avoid shipping unused code.
Lazy load: Use React.lazy and Suspense for heavy components (e.g., a large data table or charts).
Images: Use optimized images (next/image in Next.js or native loading="lazy" in img tags).
CSS: Keep Tailwind classes small per component and use Purge (content) to remove unused styles.
Avoid rerenders: Memoize heavy lists or tables with React.memo and useMemo for computed columns/rows.

Example lazy loading a chart:

const Chart = React.lazy(() => import("./charts/RevenueChart"));

function AnalyticsPanel() {
  return (
    <Suspense fallback={<div>Loading chart...</div>}>
      <Chart />
    </Suspense>
  );
}

14. Real-world examples

Below are condensed but practical examples. Each example gives you a skeleton and key components to expand.

14.1 Admin Dashboard (skeleton)

Key features:

Sidebar with navigation
Overview cards (metrics)
Activity feed
Data table for users

Skeleton components:

// src/pages/admin/index.tsx
export default function AdminPage() {
  return (
    <DashboardLayout>
      <div className="grid grid-cols-1 md:grid-cols-3 gap-4">
        <Card>Users: 1,234</Card>
        <Card>Active: 512</Card>
        <Card>Errors: 3</Card>
      </div>
      <div className="mt-6">
        <ExampleTable />
      </div>
    </DashboardLayout>
  );
}

14.2 Blog UI (skeleton)

Features:

Article list
Markdown rendering preview
Search and tags filter

Example:

// src/pages/blog/index.tsx
export default function BlogList({ posts }) {
  return (
    <div className="max-w-3xl mx-auto p-6">
      <div className="mb-6">
        <input
          placeholder="Search posts..."
          className="w-full rounded-md border p-2"
        />
      </div>
      <div className="space-y-4">
        {posts.map((p) => (
          <article key={p.slug} className="p-4 border rounded-md">
            <h2 className="text-xl font-semibold">{p.title}</h2>
            <p className="text-sm text-gray-600">{p.excerpt}</p>
            <div className="mt-2">
              <a href={`/blog/${p.slug}`} className="text-primary">
                Read more →
              </a>
            </div>
          </article>
        ))}
      </div>
    </div>
  );
}

14.3 E-commerce product grid (skeleton)

Features:

Product grid with responsive columns
Filters (category, price)
Add-to-cart UI (Zustand store)

Example grid:

// src/components/ProductCard.tsx
export function ProductCard({ product }) {
  return (
    <Card>
      <img
        src={product.image}
        alt={product.title}
        className="w-full h-48 object-cover rounded"
      />
      <h3 className="mt-2 font-semibold">{product.title}</h3>
      <p className="text-sm text-gray-600">{product.price}</p>
      <div className="mt-2">
        <Button onClick={() => addToCart(product)}>Add to cart</Button>
      </div>
    </Card>
  );
}

15. Testing & CI suggestions

Unit & integration: Use Jest + React Testing Library for component tests.
E2E: Cypress or Playwright for flows (login, add to cart).
Visual regression: Chromatic or Percy if visual changes matter.
CI: Run lint, tests and build on push/PR; use Vercel/Netlify for preview deployments.

16. Common pitfalls & how to avoid them

Over-adding utilities: Tailwind classes can get verbose, so create small component wrappers when repeated.
Global state misuse: Don't store UI-only ephemeral state in global stores.
Accessibility oversights: Test keyboard interactions, labels, modal focus-trapping.
Not optimizing images: Large images kill LCP; optimize and lazy load.
Forgetting to purge CSS: Ensure Tailwind purge/content settings are correct to keep CSS size low.

17. Playground, Examples and Next Steps

Try official playground and examples to explore components interactively:

Playground: https://ui.shadcn.com/examples/playground
Dashboard example: https://ui.shadcn.com/examples/dashboard
Official docs (installation): https://ui.shadcn.com/docs/installation

Next steps suggestions:

Scaffold a small app (Vite or Next.js).
Add a few Shadcn components via the CLI (npx shadcn add).
Build one of the real-world skeletons (admin / blog / ecommerce).
Iterate on theming and accessibility.

18. References & resources

Shadcn UI official: https://ui.shadcn.com
Shadcn UI playground & examples: https://ui.shadcn.com/examples
TanStack Table: https://tanstack.com/table
React Hook Form: https://react-hook-form.com
Zod: https://github.com/colinhacks/zod
Zustand: https://github.com/pmndrs/zustand
Redux Toolkit: https://redux-toolkit.js.org

Happy building! Now go try adding a component to a small project and see how quickly you can iterate!

Why Choose Native Languages Over Ionic / React Native?

Muhammed Metehan Yıldırım — Tue, 21 Jul 2026 12:13:55 +0000

One of the most common questions in mobile development: "Should I build one codebase for iOS and Android (Ionic / React Native), or build two native apps?"
Short answer: "It depends." But if you don't like short answers, let's dive deeper in a friendly, practical, and hands-on way.

Introduction: why this debate still matters
Quick summary: Native vs Cross-platform (Ionic / React Native)
Performance & resource usage (startup time, memory, animations)
User experience & platform fidelity (UI, accessibility, animations)
Hardware and platform API access (camera, sensors, SDKs)
Security, stability, and updates
Technical debt, maintenance, and long-term cost
When to choose native vs cross-platform: a practical decision tree
Conclusion: practical recommendations and a checklist

1) Why this debate is still alive

Devices, operating systems and user expectations evolve constantly. Cross-platform tools (Ionic, React Native, etc.) make life easier: faster prototypes, a single language and codebase, and lower initial cost. But real-world apps are rarely just "UI"; they often need low latency, deep hardware integration, complex animations, robust security, and low battery use. In these areas native languages still provide meaningful advantages.

2) Short and clear: Native vs Ionic vs React Native

Native (Kotlin/Java for Android, Swift/Obj-C for iOS): Compiled against the platform SDK; offers the best performance, full API access, and the most precise UX control.
React Native: Write in JS/TS and reuse many platform widgets, but communication between JS and native layers (the "bridge") can be a bottleneck for low-level or high-frequency tasks. With careful architecture, React Native apps can approach native performance for many use cases.
Ionic (WebView / Capacitor): Build with HTML/CSS/JS and render inside a webview. Great for rapid prototypes and web developers, but the webview adds overhead and limitations for heavy computations and native-like animations.

3) Performance & resource usage: why native often wins

Cold start time

Native apps compile ahead-of-time and don't need to initialize a whole web runtime or additional JS bridge layers at startup. Especially on lower-end devices, webview or JS runtime initialization can be noticeable. Native apps can deliver faster cold starts and smaller runtime overhead.

Animations & UI smoothness

Native UI toolkits and GPU pipelines (e.g., Android View/RenderThread, iOS Core Animation / Metal) are designed for smooth, low-latency animations. If the JS thread is busy or the bridge is saturated, React Native animations can stutter. Native development minimizes those risks and gives you more predictable rendering.

CPU & memory

Extra abstraction layers (webview or JS runtimes) typically increase memory footprint and CPU usage. For CPU-bound tasks such as real-time image processing, ML inference, AR, or complex game logic, native code tends to be more efficient and gives you finer control over performance.

4) User experience & platform fidelity

Users notice small hiccups. With native development you can:

Follow the platform's latest UI patterns and gesture behaviors precisely.
Provide the deepest accessibility support (VoiceOver / TalkBack) and the most polished interaction details.
Fine-tune edge-case behaviors and micro-interactions that make an app feel "native".

For brands where UX is a differentiator (banking, health, high-interaction social apps), this fidelity matters.

5) Hardware & platform API access

New device features and platform APIs (advanced camera capabilities, LiDAR, custom BLE profiles, vendor SDKs) typically appear first in the native SDKs. Accessing the newest APIs or building deep integrations is often simpler, more reliable, and better documented on the native side. Cross-platform frameworks provide plugins and bridges, but those plugins need to be developed, maintained, and kept up-to-date, which may introduce delay and extra maintenance effort.

6) Security & stability

Native apps align directly with the platform's security model (Keychain, Android Keystore, platform permissions), and they tend to have fewer extra abstraction layers that could introduce new attack surfaces. Cross-platform solutions add extra moving parts (webviews, native bridges, third-party plugins), so you must manage those layers carefully (dependency updates, plugin audits, content security policies, etc.) to maintain comparable security.

7) Technical debt, maintenance & long-term cost

A single codebase sounds ideal: fewer developers, faster MVP. However:

As platform-specific needs grow, cross-platform codebases can become littered with conditional logic and native modules.
The number of native bridge modules may increase, raising test complexity and integration effort.
Large OS updates or major upgrades to the framework can force time-consuming migrations.

With the right team and disciplined architecture, many of these costs can be controlled, but it's important to include them in long-term planning.

8) When to pick native (practical guide)

Prefer Native when:

App performance is critical (games, real-time image processing, AR/ML).
You need deep device integration (advanced camera features, sensors, proprietary SDKs).
UX polish, platform-accurate interactions, and accessibility are top priorities.
Security and regulatory constraints are strict (fintech, healthcare).

Prefer Ionic / React Native / Cross-platform when:

You need a fast MVP to validate product-market fit on both platforms.
The app is content-centric or CRUD-heavy (news, blogs, catalogs).
Your team consists mainly of web developers and native expertise is limited.
Project budget or time-to-market strongly favors a single codebase.

9) Quick decision checklist

Is the app CPU- or graphics-intensive? → Yes → Native.
Will you rely on the newest platform-specific APIs? → Yes → Native.
Do you need to launch quickly with limited native expertise? → Yes → Cross-platform.
Is long-term high-quality UX and low-latency behavior mandatory? → Yes → Native.

10) Practical tips if you choose cross-platform

Measure early: Profile on real devices: cold start, FPS, memory.
Minimize native bridge traffic: Keep critical paths in native modules if needed; only use the bridge for what's necessary.
Optimize bundles & lazy-load: Use code-splitting, lazy loading, Hermes (for RN), and webview optimizations.
Automate testing: Maintain an E2E matrix across devices and OS versions.
Plan for updates: Keep a proactive upgrade strategy for OS and framework versions and track plugin maintenance.

11) A short real-world example

Imagine a bank app: it needs high security, camera-based ID verification, complex animations and offline-safe transaction workflows. This scenario strongly favors native development for better security, performance, and a polished experience. Conversely, a news reader app can be launched faster and cheaper with Ionic or React Native and might meet user needs perfectly.

Conclusion (TL;DR)

Cross-platform tools (Ionic / React Native) give speed and a single codebase, great for rapid prototyping and content apps.
Native languages provide the best performance, deeper hardware access, and the most accurate platform UX. Choose them when performance, security, and long-term quality matter.
React Native can approach native performance with the right architecture, but the JS ⇄ native bridge and runtime constraints must be respected.
Ionic (webview) solutions require extra optimization but can be more than sufficient for many business apps.

StorMIC Setup Guide: Free Self-Hosted P2P Voice Chat With Zero Data Retention

Muhammed Metehan Yıldırım — Sun, 19 Jul 2026 16:07:07 +0000

This guide walks a regular user through two things: putting the StorMIC signaling server online for free, and pointing the StorMIC desktop app at it. You do not need to be a backend developer. If you can copy a URL and paste it into a text box, you can finish this in under ten minutes.

Repositories: StorMIC (desktop app) and StorMIC-Backend (signaling server)

What StorMIC actually is
Why it ships as two separate pieces
The real point: a communication channel that keeps nothing
What you need before you start
Step 1: Deploy the signaling server for free on Render.com
Step 2: Verify the server is alive
Step 3: Download the desktop app from Releases
Step 4: Connect the app to your server
Step 5: Create a channel and invite someone
Other hosting options (Heroku, VPS, PM2, local)
The free tier and the cold start problem
Troubleshooting common errors
What the server can and cannot see
FAQ

1. What StorMIC actually is

StorMIC is a desktop voice and chat application built with Electron. It does voice with push to talk or open mic, camera sharing, screen sharing at up to 1080p and 60 fps, text chat, and drag and drop file transfer. On the surface it looks like the tools you already use every day.

Underneath, it works in a fundamentally different way. Your audio, your video, your messages, and your files never touch a server. They travel directly from your computer to the other person's computer over WebRTC. The only server in the picture is a tiny WebSocket relay whose entire job is to introduce two people to each other, and then get out of the way.

That relay is called the signaling server, and it is the part you are going to host yourself. It is the reason this guide exists.

2. Why it ships as two separate pieces

Most chat applications hand you one installer and quietly point it at infrastructure owned by whoever wrote the app. You never see that infrastructure. You cannot inspect it, you cannot move it, and you have no way to confirm what it does with your traffic. You are trusting a promise.

StorMIC breaks that arrangement on purpose. The app and the server are two repositories because they are meant to be owned by two different people: I wrote the code, and you run the server. There is no shared StorMIC backend sitting somewhere with everyone's channels on it, because I deliberately did not build one. When you deploy the signaling server, the address it lives at belongs to you, the machine it runs on is billed to you, and the only people who can reach it are the ones you hand the URL to.

The desktop app is distributed through GitHub Releases as a plain installer, with no server address baked into it by default. That is also intentional. An installer that already knows where to phone home is an installer that made a decision on your behalf. This one asks you instead.

The result is a small amount of setup work that I am not going to pretend away. You trade five minutes of clicking for infrastructure that answers to you rather than to me. For a tool built around private conversation, that trade is the entire product.

3. The real point: a communication channel that keeps nothing

Both repositories state the same thing, and it is worth being precise about what it means in practice.

No message storage. No user accounts. No persistence of any kind.

The signaling server holds all of its state in memory. It knows which usernames are currently sitting in which channel, for exactly as long as they are sitting there. When the last member leaves a channel, the channel is deleted. There is no database attached to the server, because there is nothing to write to a database. The full dependency list is a single package, ws, for WebSocket support. No auth layer, no ORM, no analytics, no external services.

Here is what the traffic actually looks like:

Client A ──ws──► Server ──ws──► Client B
         join and signal relay only

Once WebRTC is established:
Client A ◄──────── WebRTC P2P ────────► Client B
         (audio, video, chat, files)

The server sees two things: a channel code and a username, plus the connection metadata (SDP offers and answers, ICE candidates) that two peers need in order to find a direct route to each other. It never sees a single word you type or a single second of what you say. Once the direct connection is up, the server's only remaining job is to notice when somebody joins or hangs up.

Chat messages travel over a WebRTC data channel. Files are chunked into 16 KB binary pieces and sent over that same direct channel. Your camera and screen go peer to peer as media tracks. None of it is routed through anything you would need to trust.

There is exactly one place where anything persists, and it is on your own machine: localStorage holds your preferences, your selected microphone and speakers, your last used username, and the signaling server URL you entered. Nothing leaves your computer to be remembered somewhere else.

This is what "a communication channel that keeps no data" means here. Not a policy. Not a setting you can toggle. There is no storage layer in the architecture to turn off.

4. What you need before you start

A GitHub account, free
A Render.com account, free, which you can create with your GitHub login
A Windows, macOS, or Linux desktop
One friend to talk to, since a voice channel with one person in it is a lonely test

You do not need Node.js, a credit card, a domain name, or a server of your own. Render handles all of that. Node.js only matters if you choose to run the server locally, which is covered later.

5. Step 1: Deploy the signaling server for free on Render.com

The backend repository already contains a render.yaml blueprint, so Render can configure the whole service by reading the repo. You will not be typing any commands.

5.1 Fork the backend repository

Open github.com/MMetehan/StorMIC-Backend and click Fork in the top right. This copies the repo into your own GitHub account. Render needs it under your account so it has permission to read and deploy it.

5.2 Create a Blueprint on Render

Sign in at render.com, using Sign in with GitHub if you want to skip a step
Click New in the top right, then choose Blueprint
Pick your forked StorMIC-Backend repository from the list
Render reads render.yaml and fills in the settings automatically. For reference, this is all it contains:

services:
  - type: web
    name: stormic-server
    runtime: node
    buildCommand: npm install
    startCommand: node index.js
    envVars:
      - key: NODE_ENV
        value: production

Leave the instance type on Free and click Apply

Render installs the single dependency and starts the server. This usually takes about a minute.

5.3 Copy your server URL

When the deploy finishes, Render shows a URL that looks like this:

https://stormic-server-abc1.onrender.com

That address is your server. Copy it and keep it somewhere handy. In the next steps you will convert https:// to wss://, since the app connects over a secure WebSocket rather than a web page:

wss://stormic-server-abc1.onrender.com

Same address, different protocol prefix. Render already gives you TLS on that domain, so wss:// works immediately with no certificate setup on your side.

6. Step 2: Verify the server is alive

Before touching the app, confirm the server is actually responding. Open the https:// version of your URL in a browser with /health on the end:

https://stormic-server-abc1.onrender.com/health

You should see the word ok. That endpoint returns 200 OK with the body ok, and it exists precisely so that platforms and uptime monitors can poll it. If you see ok, your server is running and you can move on.

If the page takes fifteen or twenty seconds on the first try, that is the free tier waking up, not a failure. Section 11 explains why.

7. Step 3: Download the desktop app from Releases

You are not building anything here. Go to the StorMIC releases page and grab the installer for your platform from the latest release, which at the time of writing is v2.4.1.

Each release publishes prebuilt binaries for Windows, macOS, and Linux under Assets. Expand that section and pick the file that matches your operating system, then install it the way you would install anything else.

A note for macOS and Windows users: StorMIC is an independent open source project without a paid code signing certificate, so your operating system may warn you that the developer is unidentified. On macOS you can right click the app and choose Open to get past Gatekeeper. On Windows you may need to click More info and then Run anyway on the SmartScreen prompt. If that makes you uncomfortable, the source is public and the build commands are in the repository, so you can compile it yourself and trust your own binary instead.

8. Step 4: Connect the app to your server

This is the step that ties the two halves together, and it is a single text field.

Launch StorMIC. Because no server URL is baked into the public builds, the app starts without a default and expects you to supply one. Open the Settings panel using the gear icon, find Signaling Server URL, and paste in your wss:// address:

wss://stormic-server-abc1.onrender.com

You can also set it from the channel screen's server configuration toggle before joining anything. Both paths write to the same place.

The URL is saved to localStorage, so you enter it once and the app remembers it on every future launch. For anyone curious about the internals, the app resolves the URL in this order:

localStorage, the URL you typed into the Settings panel, which overrides everything else
signal-url.js, a URL baked in at build time from a .env file, only present if you built the app yourself
process.env.STORMIC_SIGNAL_URL, a system environment variable for advanced setups
Empty, in which case the app waits for you to configure it in Settings

Downloaded releases land on option 4 and you move them to option 1. That is the whole flow.

Everyone who joins your channel needs the same URL in their copy of the app. Two people pointed at two different signaling servers cannot see each other, no matter how correct the channel code is. Send your friends the wss:// address along with the channel code.

9. Step 5: Create a channel and invite someone

Enter a username, which is remembered for next time
Create a channel with a code of your choosing, which is any string you and your friends agree on
Have your friend enter the same server URL, the same channel code, and a different username
Their client sends a join message, your server replies with the current peer list, and the two clients negotiate a direct WebRTC connection between themselves

From that moment on, your server is a bystander. Push to talk, screen share, drag a file into the chat window, and none of it goes anywhere near Render.

The channel exists only while somebody is in it. Close the app on both ends and the channel is gone from memory, with nothing left behind to delete.

Tip: Typing @ in the chat box brings up the participant list so you can mention someone directly.

10. Other hosting options

Render is the shortest path, but nothing about StorMIC requires it.

Run it on your own computer

Useful for testing, or for a LAN party where everyone is on the same network. You need Node.js 18 or newer:

git clone https://github.com/MMetehan/StorMIC-Backend
cd StorMIC-Backend
npm install
npm start          # production
npm run dev        # auto restart on file changes

The server listens on port 3000 by default. Override it with an environment variable:

PORT=8080 npm start

Then point the app at ws://localhost:3000. Note the single s: plain ws:// is fine on localhost, but not over the public internet.

Heroku

A Procfile is included:

heroku create your-app-name
git subtree push --prefix server heroku main

Then use wss://your-app-name.herokuapp.com as your URL.

Any VPS or cloud server

git clone https://github.com/MMetehan/StorMIC-Backend
cd StorMIC-Backend
npm install
PORT=3000 node index.js

Put a reverse proxy with a TLS certificate in front of it so clients get wss:// rather than ws://. Here is a working nginx configuration, with the WebSocket upgrade headers being the part people usually forget:

server {
    listen 443 ssl;
    server_name signal.yourdomain.com;

    ssl_certificate     /etc/letsencrypt/live/signal.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/signal.yourdomain.com/privkey.pem;

    location / {
        proxy_pass         http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection "upgrade";
        proxy_set_header   Host $host;
    }
}

Keep it running with PM2

On a VPS, a bare node index.js dies the moment you close your terminal. PM2 fixes that:

npm install -g pm2
pm2 start index.js --name stormic-server
pm2 save
pm2 startup        # restart automatically after a reboot

11. The free tier and the cold start problem

Render's free tier suspends your service after 15 minutes with no traffic. The next connection wakes it back up, which takes roughly 30 to 50 seconds.

In practice this means the first person to join after a quiet evening waits a bit. StorMIC absorbs this reasonably well because the client reconnects with exponential backoff, starting at 1.5 seconds and doubling up to a 30 second cap, so it keeps retrying while the service boots instead of throwing an error at you.

If the wait annoys you, there are three ways out. Upgrade to a paid Render instance and the service never sleeps. Or run the server on a VPS you already pay for. Or accept the cold start, since once the connection is established the server is irrelevant anyway and its sleep schedule stops mattering for the rest of the call.

I would not add a keep alive pinger just to game the free tier. If the project matters enough to you to keep a server warm around the clock, it probably deserves the few dollars a month.

12. Troubleshooting common errors

The server sends back exactly two error codes, and both are self explanatory once you know what they mean.

Error code	What happened	What to do
`CHANNEL_NOT_FOUND`	You tried to join a channel that does not exist	One person must create the channel first, and it disappears when the last member leaves
`USERNAME_TAKEN`	Somebody in that channel already has your name	Pick a different username

CHANNEL_NOT_FOUND catches people out most often, and it is a direct consequence of the no persistence design. Channels are not records in a database that sit there waiting for you. They exist only while somebody is inside. If everyone leaves and you try to rejoin the same code, you are creating it again, not returning to it.

Other things that go wrong:

The app cannot connect at all. Check that your URL starts with wss:// and not https:// or ws://. Then load /health in a browser to confirm the server is up. If it is a free Render instance, wait through the cold start and let the reconnect logic do its work.

You are in the channel but cannot see your friend. You are almost certainly on two different signaling servers. Compare the URL in both Settings panels character by character.

Voice connects but nobody hears you. That is a local media problem, not a server problem. Open Settings, confirm the right microphone is selected as your input device, and check whether push to talk is on with a key you have not pressed.

Everything worked yesterday and now it does not. If your Render service was redeployed it keeps the same URL, so that is rarely the cause. Check /health first, since it isolates a server problem from an app problem in about five seconds.

13. What the server can and cannot see

Worth stating plainly, because "peer to peer" gets used loosely enough that the word has lost most of its meaning.

Your signaling server sees:

The channel codes currently in use, in memory only, for as long as somebody is in them
The usernames currently connected to those channels
SDP and ICE metadata, which is the technical description of how two peers can reach each other, including IP address candidates

Your signaling server never sees:

Audio
Video or screen shares
Chat messages
Files
Anything at all after the direct connection is established

That IP address point deserves honesty rather than marketing. WebRTC works by having peers discover routes to each other, and those candidate addresses pass through the signaling server during the handshake. Peers also learn each other's addresses, because that is how a direct connection is a direct connection. StorMIC is built for talking with people you know, not for anonymity against people you do not. It hides your conversation from the infrastructure. It does not hide your existence from the person you called.

And since the server is yours, the party seeing that metadata is you.

14. FAQ

Do I have to run a server? Can I just use yours?
There is no "mine." No shared StorMIC backend exists, which is the point of the whole design. Deploying your own on the free tier takes about five minutes, and section 5 is the entire process.

Is it really free?
Yes, on Render's free tier, with the cold start caveat from section 11. The server's only dependency is ws, so there is no database bill and no third party service to subscribe to.

How many people fit in a channel?
StorMIC creates a peer connection to every other participant, so traffic grows with the square of the group size. It is built for small groups: a handful of friends rather than a hundred person town hall. Your upstream bandwidth is the practical ceiling, particularly with screen sharing on.

Can I share one server with my whole friend group?
Yes, and that is the expected setup. One person deploys, everyone else pastes the same wss:// URL into Settings. Anyone with the URL can create channels on it, so treat it as a group resource rather than a public one.

Does the app auto update?
No. New versions land on the releases page and you install them yourself.

Do I need to redeploy the server when the app updates?
Usually not. The signaling protocol is small and stable. If a release ever requires a server change, it will say so in the release notes.

Can I read the code?
Both repositories are MIT licensed and public. The client is roughly 1500 lines of vanilla JavaScript with no frameworks, and the server is small enough to read over a coffee. If you are going to trust software with your conversations, being able to read it is not a small feature.

DEV Community: Muhammed Metehan Yıldırım

A Deep Dive into Shadcn UI: Detailed Examples, Code Snippets, and Playgrounds

Table of Contents

1. What is Shadcn UI?

2. Why pick Shadcn UI?

3. Key features recap

4. Installation

4.1 Vite + React + TypeScript (recommended quick start)

4.2 Next.js (short notes)

4.3 Remix & Laravel (brief)

5. Project scaffolding: Vite + TypeScript example

6. Tailwind & theme configuration

7. Component patterns and examples

7.1 Button

7.2 Input & Label

7.3 Dialog (Modal) pattern

7.4 Tabs

7.5 Dropdown

7.6 Tooltip (lightweight)

7.7 Card

8. Forms and Validation (React Hook Form + Zod)

9. Data Tables (TanStack Table integration)

10. State Management Integration

10.1 Zustand (lightweight)

10.2 Redux Toolkit (for large apps)

11. Advanced layouts & dashboard patterns

12. Accessibility (a11y) best practices

13. Performance optimization

14. Real-world examples

14.1 Admin Dashboard (skeleton)

14.2 Blog UI (skeleton)

14.3 E-commerce product grid (skeleton)

15. Testing & CI suggestions

16. Common pitfalls & how to avoid them

17. Playground, Examples and Next Steps

18. References & resources

Why Choose Native Languages Over Ionic / React Native?

Table of Contents

1) Why this debate is still alive

2) Short and clear: Native vs Ionic vs React Native

3) Performance & resource usage: why native often wins

Cold start time

Animations & UI smoothness

CPU & memory

4) User experience & platform fidelity

5) Hardware & platform API access

6) Security & stability

7) Technical debt, maintenance & long-term cost

8) When to pick native (practical guide)

9) Quick decision checklist

10) Practical tips if you choose cross-platform

11) A short real-world example

Conclusion (TL;DR)

StorMIC Setup Guide: Free Self-Hosted P2P Voice Chat With Zero Data Retention

Table of Contents

1. What StorMIC actually is

2. Why it ships as two separate pieces

3. The real point: a communication channel that keeps nothing

4. What you need before you start

5. Step 1: Deploy the signaling server for free on Render.com

6. Step 2: Verify the server is alive

7. Step 3: Download the desktop app from Releases

8. Step 4: Connect the app to your server

9. Step 5: Create a channel and invite someone

10. Other hosting options

Run it on your own computer

Heroku

Any VPS or cloud server

Keep it running with PM2

11. The free tier and the cold start problem

12. Troubleshooting common errors

13. What the server can and cannot see

14. FAQ

References