r/AIClaudeCode

▲ 8 r/AIClaudeCode+5 crossposts

IP Linux: I built a browser-based desktop environment with React, Vite and local-first apps

I built a browser-based desktop environment with React, Vite and local-first apps

I have been working on a project called IP Linux: a browser-based desktop environment that runs as a static web app.

Live site: https://ip-os-linux.vercel.app/
GitHub: https://github.com/ikerperez12/IP-OS-LINUX

It is not a real Linux distribution, and it does not run native binaries. The idea is different: I wanted to explore how far a polished desktop-like experience can go inside a normal browser tab.

The result is a small web OS-style environment with:

  • A splash / entry screen
  • A desktop with icons, folders and widgets
  • A top panel with system controls
  • A dock and app launcher
  • Resizable and draggable windows
  • Virtual workspaces
  • Snap assist
  • A global search / Spotlight-style command palette
  • Local-first apps
  • Reactive wallpapers
  • Glass UI and visual effects
  • A public GitHub repo and Vercel deployment

Why I built it

Most web demos are landing pages, dashboards or small single-purpose apps. I wanted to build something that feels more like an environment.

I was interested in questions like:

  • Can a web app feel physical and desktop-like?
  • How should windows behave inside a browser viewport?
  • How do you organize many small apps without making the UI messy?
  • How far can local-first storage go before a backend is actually needed?
  • How do you publish a visual project publicly without exposing secrets or overcomplicating the stack?

IP Linux became a way to test all of that in one project.

What is inside

The app includes a catalog of built-in apps and tools: Files, Terminal, Browser, Settings, App Store, Music Player, Matrix Rain, games, developer tools, productivity apps and visual utilities.

The apps are loaded lazily, so the initial shell does not need to download every app upfront. The virtual file system and user preferences are stored locally in the visitor's browser with IndexedDB/localStorage. There is no backend, no account system and no required environment variables for the public release.

What I focused on

The main focus was the shell experience:

  • Window resizing and dragging
  • Dock behavior
  • Desktop icon grid
  • App launcher workflow
  • Keyboard shortcuts that do not interfere with inputs or the terminal
  • Responsive behavior for compact viewports
  • Wallpaper rendering that respects reduced motion and tab visibility
  • Public-safe security posture
  • A README that presents the project like a real product

There were also a few important constraints. For example, a full YouTube page cannot be embedded in an iframe because YouTube blocks that for security reasons. So IP Linux includes a YouTube Lite / embed-aware fallback instead of pretending that every website can load inside the internal browser.

Stack

The project is built with:

  • React
  • TypeScript
  • Vite
  • Tailwind CSS
  • Radix UI primitives
  • Lucide / React Icons
  • DOMPurify
  • IndexedDB via idb-keyval
  • Vercel static hosting
  • Vercel Web Analytics

The repo also includes a public release setup:

  • README with screenshots and GIF
  • MIT license
  • SECURITY.md
  • Vercel config
  • Security headers
  • Robots and sitemap
  • Manifest
  • GitHub Actions CI for audit, lint and build

What I learned

The biggest lesson was that a desktop UI is mostly about small interaction details.

A window that opens slightly too small feels broken.
A dock icon that scales inside a clipped container feels wrong.
Desktop icons that can overlap make the whole shell feel unfinished.
Keyboard shortcuts that steal Tab from the terminal are frustrating immediately.

Fixing those details made the project feel much more real than adding another decorative effect.

I also learned that public release work matters. A project can look good locally but still feel unfinished if the repo has a generic README, no security notes, no screenshots, no CI and no clear deploy story.

Feedback welcome

I am sharing it because I think browser-based desktop interfaces are a fun area for frontend experimentation.

I would especially appreciate feedback on:

  • Window management
  • Desktop organization
  • Accessibility
  • Performance
  • App ideas
  • Whether the repo presentation is useful for other developers

Live: https://ip-os-linux.vercel.app/
Code: https://github.com/ikerperez12/IP-OS-LINUX

u/Time-Willingness-360 — 7 days ago
▲ 32 r/AIClaudeCode+13 crossposts

I built a visual frontend asset library so I can stop losing my own UI snippets

As a web developer, I often build or collect small frontend assets that are useful later: buttons, gradients, loaders, hover effects, CTAs, footers, bento grids, layout fragments and product UI patterns.

The problem is that these assets usually end up scattered across old projects, screenshots, notes, CodePens, local folders or random files. When I need one, I know I already made something similar, but finding it takes too long.

So I built UI IP Toolkit: a static visual catalog for fast access to my copy-ready frontend assets.

Live site: https://ui-ip-toolkit.vercel.app/ GitHub: https://github.com/ikerperez12/UI-IP-Toolkit-v4.0

What it is

UI IP Toolkit is a public, static frontend asset library. It is designed to be browsed visually, not as a package install.

It includes sections for:

  • Buttons and interaction states
  • Gradients and color systems
  • Loading patterns
  • Text effects
  • Hover treatments
  • Glass surfaces
  • CTAs and pricing blocks
  • Footers
  • Bento grids
  • Navigation patterns
  • 404 and recovery pages
  • Product UI patterns
  • Layout fragments and reusable CSS utilities

Every card is meant to be practical: open the site, scan visually, copy the snippet, adapt it, and move on.

Why I made it static

I wanted the toolkit to be simple, fast and easy to publish:

  • No backend
  • No runtime framework dependency
  • No account required
  • No build step needed for browsing
  • Self-hosted fonts and assets
  • Deployed as a static site on Vercel

The goal was not to create a huge npm package or a rigid design system. I wanted a personal working library that feels visual and fast enough to use during real frontend work.

The main use case

When I am building a new page or feature, I can open the toolkit and quickly find a starting point:

  • Need a loader? Go to Loading States.
  • Need a CTA? Open CTA Blocks or Purchase CTAs.
  • Need a footer? Open Footer Systems.
  • Need a visual layout idea? Open Bento Systems.
  • Need a small CSS utility? Open the utilities section.

It is basically a visual memory layer for reusable frontend work.

Tech stack

The project is intentionally simple:

  • HTML
  • CSS
  • Vanilla JavaScript
  • Local fonts
  • Local media assets
  • Vercel static hosting

The repository is public here:

https://github.com/ikerperez12/UI-IP-Toolkit-v4.0

The live version is here:

https://ui-ip-toolkit.vercel.app/

What I learned

The biggest improvement was not adding more components. It was making the catalog easier to navigate.

Once the toolkit had many sections, a long top nav became useless. I replaced it with a compact section menu grouped by category. That made the site feel much more like a real working tool instead of a long landing page.

I also learned that previews matter a lot. If every card looks too similar, the library feels bigger than it is useful. So I spent time making the previews more varied and more realistic while keeping the site lightweight.

Feedback welcome

I am sharing this because I think other frontend developers might have the same problem: useful assets scattered everywhere, but no quick visual way to reuse them.

Would you use a personal visual asset catalog like this in your own workflow? And what sections would you add next?

Live site: https://ui-ip-toolkit.vercel.app/ GitHub: https://github.com/ikerperez12/UI-IP-Toolkit-v4.0

u/Time-Willingness-360 — 12 days ago