DEV Community: Courage Labhani Paul

I Built the Same App 5 Ways: Cursor vs Claude Code vs Windsurf vs Replit Agent vs GitHub Copilot (2026 Showdown)

Courage Labhani Paul — Thu, 26 Feb 2026 12:27:46 +0000

Everyone has opinions about AI coding tools. Very few have data.

I got tired of the "Cursor is best" / "No, Claude Code is best" / "Actually Windsurf..." debates, so I did something stupid: I built the exact same application five times, with five different tools, and measured everything.

Here's what I learned.

The Experiment

The App: A task management dashboard with:

User authentication (email/password + OAuth)
CRUD operations for tasks
Real-time updates
Team collaboration features
Mobile-responsive UI
Basic analytics dashboard

The Stack: Next.js 14, TypeScript, Prisma, PostgreSQL, Tailwind CSS

The Rules:

Same spec document for all tools
Same 8-hour time limit
Same starting point (empty directory)
No manual coding except for config files
All prompting done in natural language

What I Measured:

Time to working MVP
Lines of code generated
TypeScript errors on first compile
Runtime bugs found in testing
Code quality score (SonarQube)
Security vulnerabilities (Snyk)

Let's get into it.

Tool #1: Cursor (Composer Mode)

Version tested: Cursor 0.43 with Claude 3.5 Sonnet

Cursor has been the darling of AI coding for the past year, and for good reason. Composer mode, where it can edit multiple files simultaneously is genuinely magical when it works.

The Build Experience

I started with: "Create a Next.js 14 task management app with authentication, real-time updates, and team collaboration."

Cursor's first response? A complete project scaffold with:

App Router structure
Prisma schema
Auth setup (NextAuth)
Basic CRUD API routes
A surprisingly nice UI

Time to first working page: 12 minutes

I was impressed. Then I started testing.

Where It Shined

UI generation: Cursor produced the best-looking interface of all five tools. The Tailwind usage was clean and consistent.
File coordination: When I asked for a new feature, it correctly updated the schema, API routes, and frontend together.
Error recovery: When I pointed out bugs, it usually fixed them on the first try.

Where It Struggled

Authentication edge cases: The initial OAuth setup worked, but session handling had gaps. Tokens weren't refreshing correctly.
Real-time features: It defaulted to polling instead of WebSockets, even when I specifically asked for real-time.
Database migrations: Generated migrations that worked locally but failed in production due to column ordering issues.

The Numbers

Metric	Result
Time to MVP	4h 23m
Lines of Code	3,847
TypeScript Errors (first compile)	12
Runtime Bugs Found	8
SonarQube Score	B (74/100)
Security Issues	3 (1 high, 2 medium)

The high-severity security issue: An exposed API route that didn't check authentication. Oops.

Tool #2: Claude Code (CLI)

Version tested: Claude Code 1.0.23 with Claude 3.5 Sonnet

Claude Code is Anthropic's terminal-based coding agent. It's less visual than Cursor but more autonomous, you can tell it to "build X" and walk away.

The Build Experience

Same starting prompt. Very different approach.

Claude Code asked clarifying questions first:

"Should I use the App Router or Pages Router?"
"Do you want email/password auth, OAuth, or both?"
"Real-time via WebSockets or Server-Sent Events?"

This took an extra 10 minutes upfront but saved me hours later.

Time to first working page: 27 minutes

Slower start, but the foundation was solid.

Where It Shined

Architecture: Claude Code's generated code was the most maintainable of all five. Clear separation of concerns, consistent patterns.
Error handling: It actually included try/catch blocks and meaningful error messages. Revolutionary, I know.
Documentation: It generated JSDoc comments and a README without being asked.

Where It Struggled

UI polish: The interface was functional but ugly. Tailwind usage was inconsistent.
Speed: Being terminal-based, the feedback loop was slower. No instant previews.
Complex refactors: When I asked it to restructure the authentication system, it got confused about which files it had already modified.

The Numbers

Metric	Result
Time to MVP	5h 12m
Lines of Code	4,231
TypeScript Errors (first compile)	4
Runtime Bugs Found	5
SonarQube Score	A (86/100)
Security Issues	1 (medium)

Highest code quality of the bunch. Slowest to pretty, though.

Tool #3: Windsurf (by Codeium)

Version tested: Windsurf 1.2.1

Windsurf markets itself as having "flows" persistent context that remembers your entire project history. In theory, this solves the "AI forgets what it did yesterday" problem.

The Build Experience

Windsurf's onboarding was slick. It analyzed my project type and suggested a tech stack before I asked.

The "flow" concept worked... sometimes. When I asked for a feature, it referenced code it had written earlier. When I asked to modify that feature, it often forgot the context entirely.

Time to first working page: 18 minutes

Where It Shined

Speed: Windsurf was the fastest at generating initial code. The autocomplete is snappy.
Explanations: Every code block came with comments explaining what it did and why.
IDE integration: The VS Code-like interface felt familiar and polished.

Where It Struggled

Consistency: The "flows" weren't as persistent as advertised. After ~30 minutes of work, it started contradicting itself.
Complex logic: Business logic for team permissions was a mess. It generated five different permission-checking approaches across the codebase.
Testing: When I asked for tests, it generated tests for the wrong components.

The Numbers

Metric	Result
Time to MVP	3h 58m
Lines of Code	3,612
TypeScript Errors (first compile)	18
Runtime Bugs Found	11
SonarQube Score	C (62/100)
Security Issues	4 (2 high, 2 medium)

Fastest to "working," but "working" is generous here. The security issues included hardcoded API keys in the frontend. 😬

Tool #4: Replit Agent

Version tested: Replit Agent (December 2025)

Replit Agent is different. It's not just a coding assistant, it's an autonomous agent that deploys your app too. Tell it what you want, and it builds, tests, and ships.

The Build Experience

The promise: "Describe your app, then go get coffee."

The reality: "Describe your app, watch it work for 20 minutes, realize it went down the wrong path, start over."

Replit Agent made bold decisions without asking. It chose a completely different database (MongoDB instead of PostgreSQL), implemented auth differently than I specified, and styled everything with its own CSS instead of Tailwind.

Time to first working page: 34 minutes

But it was deployed and live. That's something.

Where It Shined

End-to-end: No other tool gave me a deployed, publicly accessible app this fast.
Infrastructure: Database provisioning, environment variables, deployment all handled automatically.
Iteration speed: Once it understood the project, small changes were instant.

Where It Struggled

Control: I felt like a passenger. When it made wrong decisions, correcting them was harder than starting fresh.
Performance: The generated code was not optimized. Pages that should load in 200ms took 2+ seconds.
Vendor lock-in: The generated code was tightly coupled to Replit's infrastructure. Moving it elsewhere would require significant refactoring.

The Numbers

Metric	Result
Time to MVP	4h 47m
Lines of Code	2,891
TypeScript Errors (first compile)	7
Runtime Bugs Found	9
SonarQube Score	C (58/100)
Security Issues	2 (1 high, 1 medium)

Best for prototypes you'll throw away. Worst for production code you'll maintain.

Tool #5: GitHub Copilot (Agent Mode)

Version tested: Copilot Agent in VS Code (January 2026)

GitHub Copilot has been around longest, but Agent Mode, where it can execute multi-step plans is relatively new.

The Build Experience

Copilot Agent felt like the most "professional" option. Less magic, more predictable. It generated code incrementally, asking for confirmation at each step.

Time to first working page: 22 minutes

Where It Shined

Predictability: I always knew what it was doing and why. No surprises.
Integration: GitHub integration was seamless. It understood my existing workflow.
Testing: Generated the most comprehensive test suite of all five tools.

Where It Struggled

Ambition: It was conservative. Features I got in one prompt with other tools took 3-4 with Copilot.
Modern patterns: It defaulted to older Next.js patterns. Took explicit prompting to use App Router features.
Speed: The slowest at raw code generation. It thinks before it types.

The Numbers

Metric	Result
Time to MVP	5h 56m
Lines of Code	4,456
TypeScript Errors (first compile)	2
Runtime Bugs Found	4
SonarQube Score	A (89/100)
Security Issues	0

Slowest to MVP. Best quality. Zero security issues.

The Final Comparison

Tool	Time to MVP	Code Quality	Bugs	Security Issues	Best For
Cursor	4h 23m	B (74)	8	3	Fast iteration, nice UI
Claude Code	5h 12m	A (86)	5	1	Maintainable production code
Windsurf	3h 58m	C (62)	11	4	Quick prototypes
Replit Agent	4h 47m	C (58)	9	2	Deployed demos
GitHub Copilot	5h 56m	A (89)	4	0	Production-ready enterprise code

My Honest Recommendations

For Side Projects & Experiments

Winner: Cursor

The UI generation is unmatched. The speed is great. The code quality issues don't matter if you're building something to learn or demo.

For Production Code You'll Maintain

Winner: GitHub Copilot (Agent Mode)

Yes, it's slower. Yes, it's less flashy. But zero security issues and the highest code quality score mean fewer 3 AM debugging sessions.

Runner-up: Claude Code

If you can live with the terminal interface, Claude Code's architectural decisions are consistently excellent. The code reads like a senior developer wrote it.

For Rapid Prototyping

Winner: Windsurf

If you need something to show investors tomorrow and don't care about technical debt, Windsurf will get you there fastest.

For Non-Developers / "Vibe Coding"

Winner: Replit Agent

If you genuinely don't want to touch code and just want a deployed app, Replit Agent is the only tool that delivers end-to-end without you opening a terminal.

What I'd Actually Use

Here's my honest setup going into 2026:

GitHub Copilot for production work at my day job
Cursor for side projects and UI-heavy features
Claude Code for complex refactoring and architectural decisions

I don't use a single tool for everything. The best results come from knowing each tool's strengths and picking accordingly.

The Uncomfortable Truth

All five tools produced code with bugs. All of them made architectural decisions I wouldn't have made. All of them required human review and correction.

The hype says AI coding tools will replace developers. The reality is they make experienced developers faster and inexperienced developers dangerous.

These tools are productivity multipliers, not productivity replacements. A 10x engineer with AI becomes a 20x engineer. A 0.1x engineer with AI is still 0.1x, just with more code to debug.

Choose your tools wisely. And always, always review what they generate.

Which AI coding tool are you using? Did these results surprise you? Let me know in the comments.

The Vibe Coding Hangover Is Real: What Nobody Tells You About AI-Generated Code in Production

Courage Labhani Paul — Thu, 08 Jan 2026 09:39:34 +0000

Last month, a startup founder sent me their codebase for review. "Built in a weekend with Cursor," he said proudly. "Ready for our Series A demo."

I opened the repo. Thirty seconds later, I closed Slack and poured myself a drink.

The code worked. That wasn't the problem. The problem was that it worked for now held together by duct tape, prayers, and whatever hallucination Claude had that Tuesday afternoon.

This is the vibe coding hangover. And if you've shipped AI-generated code to production this year, you might already be feeling it.

What Is Vibe Coding, Really?

The term exploded in early 2025 after Andrej Karpathy tweeted about "fully giving in to the vibes" and "forgetting that the code even exists."

Collins Dictionary just named it their 2025 Word of the Year.

And now 84% of developers are using AI coding tools daily.

But here's what nobody talks about: there are actually two definitions of vibe coding floating around, and conflating them is causing chaos.

Definition 1: The Meme
"I don't read the code. I just accept what the AI gives me and move on."

Definition 2: The Reality

"I use AI to generate boilerplate faster, but I still review everything and understand what's happening."

Most of the horror stories come from Definition 1. Most of the productivity gains come from Definition 2.

The problem? Everyone thinks they're doing Definition 2.

The 5 Patterns I See in Every Vibe-Coded Disaster

After reviewing 15+ vibe-coded projects this year, from weekend hacks to funded startups, I've identified the recurring nightmares.

1. The "It Works On My Machine" Illusion

AI is exceptionally good at solving the happy path. Ask Claude to build a login form, and you'll get a beautiful login form that works perfectly when users enter valid emails and correct passwords.

Ask what happens when:

Someone pastes 50,000 characters into the email field
The database connection times out mid-authentication
A user double-clicks the submit button
The session expires between form load and submission

Crickets.

I reviewed a payment processing flow last month. The AI-generated code handled successful payments flawlessly. Failed payments? The error handling was literally:

} catch (error) {
  console.log("Something went wrong");
}

That was it. In a payment system. Handling real money.

2. The Architectural Amnesia

Here's the dirty secret: AI doesn't remember your architecture.

Every prompt is a fresh start. So when you ask for Feature A on Monday, then Feature B on Tuesday, then Feature C on Wednesday, you get three features that each make perfect sense in isolation and absolute chaos when combined.

I've seen:

Three different state management approaches in one React app
Database queries that bypass the ORM you set up specifically for security
Authentication logic duplicated (differently) in 7 places
API endpoints that return data in 4 different formats

The AI solves each problem optimally for that problem. It has no concept of "we decided to do it this way for a reason."

3. The Security Time Bomb

This one keeps me up at night.

A Swedish vibe coding platform called Lovable had a security audit earlier this year. Out of 1,645 applications built with the tool, 170 had vulnerabilities that would expose user data to anyone who looked.

That's a 10% critical failure rate. On apps that founders thought were production-ready.

The patterns I see constantly:

// AI-generated "authentication"
const isAdmin = req.query.admin === 'true';

// AI-generated "database query"
const user = await db.query(`SELECT * FROM users WHERE id = ${userId}`);

// AI-generated "file upload"
const filename = req.file.originalname;
fs.writeFileSync(`./uploads/${filename}`, req.file.buffer);

Each of these is a security 101 failure. SQL injection. Path traversal. Privilege escalation via query parameter.

But they work! They pass manual testing! The demo looks great!

Until someone actually tries to exploit them.

4. The Debugging Nightmare

A developer who reviewed a vibe-coded app told me: "Debugging AI-generated code is harder than writing it manually."

Why? Because when you write code, you build a mental model of how it works. You know why that variable is named tempBuffer. You remember that edge case you handled on line 47.

With vibe-coded projects, you're debugging someone else's code except that "someone else" doesn't exist. There's no one to ask, "why did you do it this way?" The AI that wrote it has no memory of the conversation.

I spent 6 hours last month hunting a bug in a vibe-coded codebase. The issue? Two functions with nearly identical names (processUserData and processUserInfo) that did completely different things. One was called in production. The other was the one that actually worked correctly.

The AI had generated both at different times, solving the same problem differently, and the developer never noticed.

5. The Spaghetti Avalanche

Every AI coding tool has a different "style." Some prefer functional approaches. Some love classes. Some generate comments, some don't. Some use async/await, some use .then() chains.

When you vibe code over weeks or months, you end up with a codebase that looks like it was written by a team of 50 developers who never talked to each other, because that's essentially what happened.

I reviewed a Next.js app where:

Some API routes used the App Router patterns
Some used Pages Router patterns
Some were raw Express middleware somehow shoved into both
The data fetching used SWR, React Query, AND raw fetch in different components

Each piece worked. Together, they were unmaintainable.

The Numbers Don't Lie

Let's talk about what the research actually shows.

The Productivity Myth:

Yes, AI-assisted coding can cut development time by 25-50% in controlled studies. But Google's DORA research found that in real-world enterprise settings, teams using AI assistants heavily actually showed slower delivery times once you factor in debugging and rework.

The Quality Gap:

Microsoft and IBM both estimate that ~20-30% of their code is now AI-generated. But IBM's CEO specifically said that's where the percentage will stay because the maintenance burden of AI code makes higher percentages unsustainable.

The $1.5 Trillion Problem:

Industry analysts are projecting $1.5 trillion in accumulated technical debt from AI-generated code by 2027. That's not a typo. Trillion, with a T.

So What Actually Works?

I'm not anti-AI coding. I use Cursor and Claude Code daily. But I use them very differently than the "vibe coding" meme suggests.

The "AI Conductor" Approach

Think of yourself as an orchestra conductor, not a passenger.

What AI should do:

Generate boilerplate you'd write anyway
Suggest approaches you can evaluate
Write tests for logic you understand
Explain code you're reviewing
Refactor working code to be cleaner

What AI should NOT do:

Make architectural decisions
Handle security-critical paths without review
Generate code you can't explain
Write business logic you haven't specified precisely

The 30-Second Rule

Before accepting any AI-generated code, I ask myself: "Could I explain what this does to a junior developer in 30 seconds?"

If the answer is no, I don't merge it. Period.

This single rule has saved me from probably 80% of the bugs I would have shipped otherwise.

The Review Ritual

Every piece of AI-generated code gets:

A read-through - Do I understand every line?
An edge case check - What happens with null/undefined/empty/huge inputs?
A security glance - Is this handling user input safely?
An architecture fit - Does this match how we do things in this codebase?

It takes 5 minutes. It's saved me hundreds of hours of debugging.

The Real Talk About Junior Developers

This is where I get controversial.

The vibe coding explosion is going to hurt junior developers more than anyone. Here's why:

When senior developers use AI, they're outsourcing typing, not thinking. They know what good code looks like. They can evaluate AI output against years of pattern recognition.

When junior developers use AI, they're outsourcing learning. They're skipping the part where you understand why things work. And that creates a skills gap that widens every day.

I've interviewed junior developers this year who could "build anything with AI" but couldn't explain how a for loop works. They could prompt their way to a working app but couldn't debug it when something broke.

That's not preparation for a career. That's preparation for obsolescence.

My advice to new developers: Learn the fundamentals first. Use AI as a tool, not a crutch. The developers who will thrive in 2026 and beyond are the ones who understand enough to know when the AI is wrong.

The Bottom Line

Vibe coding isn't inherently good or bad. It's a tool, and like all tools, the outcome depends on who's wielding it.

If you're an experienced developer using AI to accelerate work you understand deeply...great. You're probably more productive than ever.

If you're shipping AI-generated code you don't fully understand to production, you're building on sand. The hangover is coming. It might be next week. It might be next year. But it's coming.

The question isn't whether AI changes how we code. It already has.

The question is whether you're using it as a power tool or as an excuse to skip the hard parts.

Choose wisely.

What's been your experience with AI-generated code in production? Have you hit the vibe coding hangover yet? Drop your horror stories (or success stories) in the comments.

SvelteKit vs Next.js in 2026: Why the Underdog is Winning (A Developer’s Deep Dive)

Courage Labhani Paul — Mon, 15 Dec 2025 16:02:48 +0000

Why This Comparison Matters in 2026

In 2023, Next.js dominated the full-stack framework space. But in 2026, SvelteKit is quietly revolutionizing how we build for the web and most developers aren’t even talking about it.

I spent 3 months rebuilding the same SaaS app in both frameworks. The results? SvelteKit wasn’t just faster, it was a game-changer. Here’s why.

🚀 Performance: SvelteKit Leaves Next.js in the Dust

I ran real-world tests on a production app with 50+ routes, auth, and live updates. Here’s the data:

Metric	SvelteKit	Next.js (App Router)
Time to Interactive	1.2s	2.8s
Bundle Size	42KB (gzipped)	120KB (gzipped)
Server Load (RPS)	1,200 req/sec	850 req/sec

Why the huge difference?
SvelteKit compiles to vanilla JS at build time, eliminating React’s runtime overhead. Next.js, even with React Server Components, still ships a heavier bundle.

"But what about Next.js’s Edge Runtime?"
It’s fast, but SvelteKit does the same with half the config.

🛠️ Developer Experience: Simplicity vs. Flexibility

✅ SvelteKit’s Superpowers:

No useEffect Hell: Reactivity is built-in. Just use $: and you’re done.
Intuitive Data Loading: +page.server.js is actually simple. No getServerSideProps vs getStaticProps confusion.
Zero Boilerplate: No next.config.js, no _app.js. Just drop files and go.

⚖️ Next.js’s Strengths:

Massive Ecosystem: Plugins for auth, analytics, and more.
Enterprise Adoption: More jobs, more stability.

Verdict: If you value speed and simplicity, SvelteKit wins. If you need plug-and-play solutions, Next.js is still king.

💼 Job Market: SvelteKit is the Hidden Gem

I analyzed 10,000 job postings (via LinkedIn and Web3.Career) for "SvelteKit" vs "Next.js" in 2026:

Framework	Job Postings	Avg. Salary (USD)	Remote Roles (%)
Next.js	8,200	$120K	65%
SvelteKit	1,800	$135K	80%

Key Insight:

Next.js dominates in big tech (FAANG, scaling startups).
SvelteKit is the secret weapon of indie hackers and high-paying remote gigs.

"But 1,800 jobs vs 8,200? That’s not even close!"
Wrong. SvelteKit’s job growth is 300% YoY. Next.js? 12%. The tide is turning.

🔮 The Future: Who’s Betting on What?

SvelteKit’s Roadmap (2026-2027):

Native Web Components: Ship frameworks as standards-compliant elements.
AI-Powered Compilation: Auto-optimize your code.
Edge-First Deployments: Zero-config deployments anywhere.

Next.js’s Counterplay:

React Forget: Compile-time optimizations to close the gap.
Turbopack Stability: If it delivers, Next.js could reclaim its throne.

Prediction: By 2027, SvelteKit will power 30% of new projects (up from 5% today).

🎯 Final Verdict: Should You Switch?

✅ Choose SvelteKit if:

You hate complexity and want to ship fast.
You’re building high-performance apps (dashboards, real-time tools).
You want to stand out in interviews.

✅ Stick with Next.js if:

You need job security (more opportunities).
You’re in enterprise or legacy React codebases.

💡 Pro Tip:

Learn both. The best developers are framework-agnostic. Spend 20% of your time experimenting with SvelteKit, it’ll make you a better React dev too.

🗣️ Your Turn: Let’s Debate!

I want to hear from you:

Have you tried SvelteKit? What was your experience?
Do you think Next.js can catch up, or is SvelteKit the future?
What’s holding you back from switching?

Drop a comment below,let’s discuss!

Cloudflare Down: The Single Point of Failure That Crippled X and ChatGPT, Exposing a CDN Vulnerability

Courage Labhani Paul — Tue, 18 Nov 2025 14:12:36 +0000

Introduction: The Immediate Crisis and The Tell-Tale Error

Today, the digital world received a chilling notification. Attempting to log into services like X (formerly Twitter) or OpenAI's ChatGPT yielded an obscure, yet critical, message: "Please unblock challenges.cloudflare.com to proceed."

This was not an instruction; it was a symptom. Within minutes, it became clear that this specific error was the digital fingerprint of a massive, global Cloudflare infrastructure failure. The service designed to be the internet's shield and speed optimizer became its single, catastrophic point of failure.

🕵️‍♂️ Under the Hood: The challenges.cloudflare.com Breakdown

For the average user, the error is confusing. For developers, it's a terrifying diagnosis.

The domain challenges.cloudflare.com is where Cloudflare runs its highly tuned automated security checks—its Web Application Firewall (WAF) challenge—to distinguish human traffic from bot traffic.

The Failure Mechanism:

Step 1: Your request hits the Cloudflare network.
Step 2: Cloudflare's WAF triggers a JavaScript challenge (challenges.cloudflare.com).
Step 3: During the global "internal service degradation," Cloudflare’s core infrastructure failed to process its own validation logic.
The Result: The system was stuck in a paradoxical loop: It required validation, but its own validation mechanism was offline. This generated the error message, essentially asking users to unblock a system that was internally blocked, leading to the widespread 500 Internal Server Errors that crippled two of the world’s most highly trafficked sites.

🛠️ The Developer's Dilemma: Centralization vs. Resilience

This incident is more than just breaking news; it’s a required syllabus update for any developer building in the Next.js, Svelte, or modern full-stack ecosystem. It highlights the critical, often overlooked, trade-off between performance centralization and resilience.

The Single Point of Failure (SPOF) Tax

Our push toward optimizing applications with services like Cloudflare Workers, Edge Functions, and global CDNs—designed to be performant—has inadvertently concentrated massive risk.

Questions for the Post-Outage Dev Cycle:

If your primary Next.js or Nuxt.js deployment relies heavily on a single provider for its Edge layer, what is your fallback?
Should we start implementing multi-CDN strategies as a standard for all high-traffic applications?
How can we design applications to gracefully degrade when security layers (like the WAF challenge) fail, rather than presenting a complete blackout?

📈 Moving Beyond the Fix: Architectural Mandates for 2026

The immediate fix is on Cloudflare's engineers. The long-term architectural fix is on us. As we look ahead to 2026, resilience cannot be an afterthought; it must be a mandated feature.

Three Non-Negotiable Resilience Strategies:

Separate DNS from CDN: Maintain your DNS registrar and settings with a provider distinct from your primary CDN. If one fails, you can quickly pivot traffic using the other.
Health Checks & Multi-Provider Failover: Implement continuous health checks on the CDN layer. Architect your CI/CD pipeline to automatically update DNS records to a secondary CDN (e.g., AWS CloudFront, Akamai) when the primary fails for more than a defined threshold.
Client-Side Graceful Degradation: Use service workers or client-side caching to ensure that in the event of a total network failure, users are presented with cached content or a custom, helpful error screen, rather than the confusing, generic error messages we saw today.

The challenges.cloudflare.com error will be fixed soon, but the vulnerability it revealed will linger until we architect it out of existence.

What are the inherent risks developers are taking when heavily relying on Edge Compute for critical business logic? Share your thoughts below!

🦇 Haunted Pixels: A Cinematic Halloween Landing Page

Courage Labhani Paul — Thu, 06 Nov 2025 11:23:57 +0000

This is a submission for Frontend Challenge - Halloween Edition, Perfect Landing

🎃 What I Built

Haunted Pixels is a fully interactive Halloween landing page. Part art installation, part frontend engineering showcase.

Built with React + TypeScript + Tailwind, it merges atmospheric design with smooth interactivity to create a living, breathing haunted world inside the browser.
Every layer from the fog and lightning to the crawling spiders is modular and reactive.

✨ Core Features

🧱 Component-based horror system — Each visual effect (bats, spiders, lightning, glitch, etc.) is an independent React component.
🕸 Dynamic Floating Entities — Animated bats and spiders drift across the viewport in organic motion loops.
💀 Cinematic Parallax + Glitch FX — Multi-depth background and screen distortions amplify immersion.
💡 Responsive & Accessible — Smooth scroll, keyboard focus, and semantic alt tags on all visual elements.
⏰ Animated Header — Real-time spooky clock, glowing logo, and smooth transitions on scroll.
🔊 Ambient Creepy Audio — Subtle sound layers that adapt with movement and hover.

👻 Demo

🌐 Live Demo: https://couragecodejourney.github.io/haunted-pixels-perfect/
📦 Source: GitHub Repository

🧩 Technical Breakdown

The landing page is built with:

React + TypeScript for maintainable and modular UI.
Tailwind CSS for scalable, token-driven theming (custom HSL palette for Halloween tones).
Vite for lightning-fast builds and GitHub Pages deployment.
Custom Animation System: Defined in index.css using CSS keyframes for ghost-float, blood-drip, bat-fly, and screen-shake.

Component Example – Floating Entities

const [entities, setEntities] = useState<Entity[]>([]);
useEffect(() => {
  const types = ["bat", "bat", "bat", "spider", "spider", "spider", "spider"];
  setEntities(types.map((type, i) => ({
    id: i,
    top: Math.random() * 100,
    left: Math.random() * 100,
    size: 80 + Math.random() * 80,
    type,
  })));
}, []);

Each entity is independently animated, creating believable random movement without heavy libraries.

🕯 Journey

I wanted to push beyond typical Halloween themes not just spooky visuals, but a haunted atmosphere that feels alive.

I experimented with layering depth and rhythm: subtle motion, ambient flickers, and light-to-dark transitions that react to scroll and hover.

The hardest challenge was balancing performance and cinematic animation, ensuring the multiple background and entity layers ran smoothly on mobile while retaining visual fidelity.

I also implemented a minimal design system via HSL tokens, so colors, shadows, and glows could be tuned across all components consistently.

In the end, Haunted Pixels became more than a landing page, it’s a technical mood piece that fuses frontend fundamentals with Halloween storytelling.

🦇 “Enter if you dare.”

CSS Nightmares: Building a Haunted Scene That Actually Creeped Me Out

Courage Labhani Paul — Mon, 03 Nov 2025 12:59:12 +0000

This is a submission for Frontend Challenge - Halloween Edition, CSS Art.

Inspiration

You know that feeling when you're watching a horror movie and everything seems just a little too quiet? That moment right before something jumps out? That's what I wanted to capture. I've always loved haunted houses and the creepy-crawly feeling of Halloween night, so I decided to pour all those spooky vibes into one terrifying CSS scene. The blood moon watching over everything, the spiders that seem to move when you're not looking directly at them, the ghosts that float just at the edge of your vision - it's all the stuff that made me sleep with the lights on as a kid!

Demo

See the horror come alive: Live Demo Here

Code & Resources

Source Code:
CourageCodeJourney / halloween-css-art-submission

Pure CSS Halloween Art — a haunted night scene built entirely with HTML and CSS animations.
🕸️halloween-css-art-submission

Pure CSS Halloween Art — a haunted night scene built entirely with HTML and CSS animations.

📂 Project Structure
halloween-css-art/ │ ├── index.html # Main HTML file that loads the CSS and displays the scene └── halloween.css # All the styling and animations (core of the art)
🧱 File Breakdown

index.html
- Contains the root structure of the Halloween scene.
- Each <div> represents an object or animated element in the scene — e.g.
  
  .blood-moon → glowing red moon
  
  .haunted-house → central building with windows and doors
  
  .spider, .ghost, .pumpkin, .skeleton, etc. → animated elements
- The file only references one stylesheet:
  
  <link rel="stylesheet" href="halloween.css" />
halloween.css
- Defines all visual elements and animations for the scene.
- Key techniques:
  
  Positioning: Absolute layout to place each object precisely
  
  Gradients: Used to paint every shape (no images used)
  
  Animations: Controlled via @keyframes for motion…
View on GitHub
Built with: Pure HTML & CSS (no JavaScript!)
License: MIT

Journey

Oh man, where do I even start? This project was equal parts "wow this is so cool!" and "why did I think this was a good idea?!"

The good, the bad, and the downright spooky:

I'll be honest - I almost gave up on the spiders. Getting those legs to wiggle naturally using just CSS transforms was driving me crazy! I must have rewritten those keyframes a dozen times. There was this one night I was working late, and the combination of the dark room and my own creepy creation actually made me jump when the lightning effect fired unexpectedly.

What surprised me:

How much you can do with just ::before and ::after pseudo-elements (my HTML file is surprisingly clean!)
The blood moon's pulsing effect turned out way creepier than I expected
Those little demon eyes that blink randomly? They started as an afterthought but became one of my favorite details

The "aha!" moments:

Realizing I could use CSS variables for the spider leg angles
Figuring out how to make the ghosts look like they're floating unevenly
Discovering that subtle glitch effect that makes the whole scene feel unstable

What I'd do differently next time:
I'd probably start with a better organization system for all those animations! My CSS file got pretty wild there for a while. Also, I learned the hard way that too many drop-shadows can really slow things down.

This project reminded me why I fell in love with CSS in the first place - it's like digital witchcraft. You're just typing these incantations and suddenly things move, glow, and come to life. Even after all the frustration, there's nothing quite like watching your creation breathe for the first time.

Now if you'll excuse me, I need to go watch some cartoons to get these creepy vibes out of my system! 🎃👻

My First Merge Almost Gave Me a Panic Attack: A Hacktoberfest Maintainer's Story

Courage Labhani Paul — Thu, 30 Oct 2025 17:10:39 +0000

This is a submission for the 2025 Hacktoberfest Writing Challenge: Maintainer Spotlight

My hands were actually shaking.

I was staring at my first-ever pull request as a maintainer. Some stranger on the internet had found my little side project and wanted to contribute code.

My brain was screaming: "You're not a real maintainer! You just built a glowing dot that spins! What if you break their code? What if you mess this up?"

I'd created this project during one of those 2 AM coding sessions where everything feels either brilliant or completely insane. The idea was simple: what if Hacktoberfest looked less like a list of numbers and more like a galaxy?

So I pushed a single HTML file with one glowing circle, added a "good first issue" tag because that's what you're supposed to do, and went to bed fully expecting exactly zero people to ever see it.

And now... someone was here. With actual code.

I took a deep breath, clicked "Merge," and...

It worked.

That mix of terror and excitement? That's where our galaxy actually began.

Then Things Got Real

That first merge was like opening a floodgate. People started actually contributing to my little project.

Sai was first - he added these beautiful shooting stars that made our static galaxy feel alive. Suddenly we had comets streaking across the screen.

Then Mohit messaged me: "Hey, I added a little astronaut floating around your galaxy!"

I opened his PR and there it was - this tiny astronaut slowly orbiting through our digital space. That little astronaut hit me different - it represented all of us floating into the open source universe.

But the real "oh wow" moment came when Praful submitted a massive PR that added:

Orbiting satellites with blinking lights
A warp speed effect when you click the main repo
"Code rain" that falls from contributor avatars
Enhanced tooltips and animations

I looked at the "Files changed" tab and my jaw dropped. This wasn't my little weekend project anymore - it was becoming something real.

The Day Everything Broke

Here's the part nobody tells you about being a maintainer: sometimes you have to un-merge someone's hard work.

PR #8 added background music. I merged it. Then realized it was causing issues with other features. I had to run git revert - the scariest command in Git. It feels like you're deleting someone's contribution.

Then came the merge conflict from hell. Praful's massive PR #15 collided with my local changes, turning our index.html into a 1,400-line sea of <<<<<<< HEAD and >>>>>>> pr-15.

For two hours, my terminal looked like this:

CONFLICT (content): Merge conflict in index.html
Auto-merging index.html failed
git merge --abort
git reset --hard origin/main

Pure panic. I finally fixed it, but learned the real lesson: being a maintainer isn't about Git wizardry -it's about communication. A simple "Hey, can you pull the latest changes first?" would have saved me two hours of sweating.

What I Actually Do as a Maintainer

Turns out, maintaining an open source project has very little to do with writing brilliant code and everything to do with being a good host.

You're basically running a digital potluck. Everyone brings something different, and your job is to:

Make sure they feel welcome
Help their contribution fit with everything else
Say "thank you" for every single PR, even the tiny ones
Keep the lights on for the next person

Every "Looks great, merging!" comment matters. Every quick review might be what keeps someone coding when they're about to give up.

Our Galaxy Today

That single glowing dot I started with? Here's what the community built:

200+ twinkling stars with different animations
Floating asteroids and nebula clouds
An orbiting astronaut and satellites
Shooting stars and comets
Interactive features like warp speed and code rain
Music toggle (we got it working!)
Animated stats that count up

It's a living, breathing piece of art built by 7+ contributors from around the world.

Want to Add Your Star?

We've still got plenty of space (pun intended) for more contributors:

Issue #19: Help refactor our massive HTML file into separate CSS/JS files
Issue #16: Fix mobile responsiveness (it gets squished on phones)
Issue #6: Fix typos or add comments (perfect first PR!)
Or come up with your own idea!

Check out our open issues - there's something for every skill level.

The Real Magic

My first Hacktoberfest, I was too nervous to contribute. I thought my small fixes didn't matter.

This project proved me wrong.

Hacktoberfest Code Galaxy isn't just a visualization - it's proof that every contribution matters.

It's Sai's comets lighting up the sky.
It's Mohit's astronaut exploring new frontiers.

It's Praful's satellites orbiting the repo.
It's every person who showed up and said "Hey, can I help?"

We're not just writing code - we're building a constellation of collaboration. And that's way cooler than any single line of code I could write alone.

Special thanks to Sai, Mohit, Praful, and everyone who added their star to our galaxy 🌟

P.S. I want to sincerely apologize for the quality of the images. I tried multiple ways to enhance them, but they didn't come out as clear as I'd hoped. Thank you for bearing with me, I hope you were still able to see all the cool features the community built!

Repo: github.com/CourageCodeJourney/hacktoberfest-code-galaxy

Live Demo: couragecodejourney.github.io/hacktoberfest-code-galaxy

Passwordless SSH Setup in 5 Minutes (The Right Way in 2025)

Courage Labhani Paul — Tue, 21 Oct 2025 12:18:36 +0000

ssh gideon@192.168.1.10
gideon@192.168.1.10’s password:
(...typing...)
Permission denied, please try again.
(...louder typing...)
Permission denied, please try again.
(...SIGH...)

You know that moment.
You’re ready to deploy, in your zone, and SSH decides to make you type a 14-character password from memory. Twice. Maybe three times if your pinky slips.

It’s 2025. We can do better.

In this quick guide, we’re going to set up passwordless SSH the right way using modern cryptography, secure defaults, and a workflow that’s actually worth your muscle memory.

🧠 Why “Passwordless” Isn’t Really Passwordless

Let’s clear something up.
“Passwordless” is catchy, but what we’re actually setting up is key-based authentication.

Here’s how it works:

🔐 id_ed25519 → your private key (never leaves your local machine)
🔓 id_ed25519.pub → your public key (lives on the server)

The private key is your secret signature. The public key is the lock it fits into. Together, they create a secure, unguessable login handshake with no password guessing or brute forcing.

⚙️ Step 1: Generate Your Modern SSH Key

Forget RSA, it’s 2025. The gold standard now is ED25519, which is faster, smaller, and more secure.

On your local machine, run:

ssh-keygen -t ed25519 -C "your_email@example.com"

You’ll be asked two things:

Where to save the key: Press Enter for default (~/.ssh/id_ed25519)
Passphrase: Yes, you should use one.

💡 Think of your passphrase as a password for your key, not for the server.
If your laptop gets stolen, your private key is useless without it.

This gives you a key pair in ~/.ssh/:

id_ed25519      # private
id_ed25519.pub  # public

🔁 Step 2: Copy Your Key to the Server

The easy way (and the correct one) is:

ssh-copy-id user@your_server_ip

You’ll enter your password one last time, and the command takes care of everything — creating ~/.ssh, setting permissions, and adding your public key to authorized_keys.

If `ssh-copy-id` Isn’t Installed (Manual Method)

Run this instead:

cat ~/.ssh/id_ed25519.pub | ssh user@your_server_ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

This manually sets up your public key on the remote server with proper permissions.
Not as elegant, but bulletproof.

🪄 Step 3: The Moment of Truth

Now, log in again:

ssh user@your_server_ip

If you didn’t use a passphrase, boom, you’re in instantly.
If you did, you’ll see:

Enter passphrase for key '/home/you/.ssh/id_ed25519':

Type it once, and you’re in securely.
That’s progress.

🧠 Step 4: Go Fully Passwordless with `ssh-agent`

You might be thinking,

“Wait… didn’t I just replace one password with another?”

Here’s the fix: use an SSH agent to remember your key for your whole session.

Start the agent:

eval "$(ssh-agent -s)"

Then add your key:

ssh-add ~/.ssh/id_ed25519

Enter your passphrase once, and that’s it.
Now you can SSH into your servers all day, password-free.

✅ Pro tip: add this to your .bashrc or .zshrc:
eval "$(ssh-agent -s)" > /dev/null
ssh-add ~/.ssh/id_ed25519
So your session auto-loads your key each login.

🔒 Step 5: Lock It Down — Disable Password Logins

Your key works. You’re fast.
Now let’s make it secure.

Log into your server (using your key), then edit SSH’s config:

sudo nano /etc/ssh/sshd_config

Find:

PasswordAuthentication yes

Change to:

PasswordAuthentication no

Also, set:

PermitRootLogin no

Then restart SSH:

sudo systemctl restart sshd

⚠️ IMPORTANT: Before restarting SSH, open a second terminal and confirm your key login works.
If you lock yourself out, you’ll need physical server access or console recovery.

🧾 Quick Reference

Task	Command
Generate Key	`ssh-keygen -t ed25519 -C "email@example.com"`
Copy Key	`ssh-copy-id user@server`
Start Agent	`eval "$(ssh-agent -s)"`
Add Key	`ssh-add ~/.ssh/id_ed25519`
Disable Passwords	Edit `/etc/ssh/sshd_config`

✅ Security Checklist

[x] SSH key authentication enabled
[x] Password login disabled
[x] Root login disabled
[x] SSH agent configured
[x] Keys backed up securely

🧩 FAQs

Q: Does this work on Ubuntu, CentOS, and macOS?
A: Yes, the commands are the same. Just ensure the openssh-server package is installed on Linux.

Q: What’s the difference between password and key authentication?
A: Passwords can be guessed. Keys can’t. They use asymmetric cryptography, which is exponentially more secure.

Q: Can I use the same key for multiple servers?
A: Yes, and you should. Just copy your .pub key to each one.

🎯 The Payoff

Next time you type:

ssh user@server

and it just works, no password, no delay, that’s freedom.

You’ve traded frustration for flow.
You’ve replaced brute force with elegance.
And you’ve taken one big step toward a cleaner, more secure workflow.

💬 What’s Your SSH Pro Tip?

Do you use a ~/.ssh/config file? Maybe multiplexing or ControlMaster connections?
Drop your favorite SSH trick in the comments — I’ll feature the best ones in the follow-up: “Advanced SSH Hardening for 2025.”

Stop Using `useEffect` for Data Fetching in React. Here’s a Better Way

Courage Labhani Paul — Wed, 08 Oct 2025 09:03:16 +0000

If you've been a React developer for more than a week, you've almost certainly written the following pattern (or a variation of it) countless times:

import React, { useState, useEffect } from 'react';

function MyComponent() {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    let isMounted = true; // For cleanup race conditions

    async function fetchData() {
      try {
        const response = await fetch('/api/my-resource');
        if (!response.ok) {
          throw new Error(`HTTP error! status: ${response.status}`);
        }
        const result = await response.json();
        if (isMounted) {
          setData(result);
        }
      } catch (e) {
        if (isMounted) {
          setError(e);
        }
      } finally {
        if (isMounted) {
          setLoading(false);
        }
      }
    }

    fetchData();

    return () => {
      isMounted = false; // Cleanup
    };
  }, []); // Oh, the dependency array...
  // What goes here? An empty array? What if my API needs a prop?

  if (loading) return <p>Loading data...</p>;
  if (error) return <p>Error: {error.message}</p>;

  return (
    <div>
      <h1>My Data:</h1>
      <pre>{JSON.stringify(data, null, 2)}</pre>
    </div>
  );
}

export default MyComponent;

This boilerplate code is ubiquitous in React applications. It's how we've been taught to handle side effects, including data fetching, since the introduction of Hooks.

But here's the uncomfortable truth: Using useEffect for data fetching in React components is often an anti-pattern.

It leads to common bugs, unnecessary complexity, and a less performant user experience. In modern React development, dedicated data fetching libraries offer a vastly superior approach.

The Problem with useEffect for Data Fetching

While useEffect is powerful and essential for many side effects (like synchronizing with external APIs, logging, or manually manipulating the DOM), it was never designed to be a data fetching solution. When you force it into this role, you inherit a host of issues:

Race Conditions and Stale Closures (The isMounted Nightmare)

If your component unmounts before your asynchronous fetch request resolves, trying to update state on an unmounted component can lead to errors and memory leaks. The isMounted flag is a common workaround, but it's boilerplate you shouldn't have to write for every fetch.
Manual Caching, Revalidation, and Deduplication

useEffect doesn't inherently cache your data. If the user navigates away and then back to a page, or if multiple components request the same data, useEffect will trigger redundant fetches. You end up implementing your own caching layer, which is notoriously difficult to get right.
Global State Management (Loading/Error States)

Managing loading and error states for every single fetch request across your application quickly becomes verbose and inconsistent. You often need to lift these states up or pass them down, creating prop drilling or context hell.
Re-fetching on Focus, Network Reconnection, etc.

Real-world applications need to intelligently re-fetch data. If the user's internet connection drops and then comes back, or if they switch browser tabs and return, your data might be stale. useEffect offers no built-in solution for these common UX requirements.
Strict Mode Double Invocation

In React's Strict Mode (which you should absolutely be using in development), useEffect runs twice on mount to help you catch bugs related to improper cleanup. While this is great for ensuring proper side effect management, it can lead to frustrating double fetches if not handled carefully, making your development experience slower.

These aren't theoretical problems; they are everyday struggles for React developers.

The Better Way: Dedicated Data Fetching Libraries

The React ecosystem has evolved, and specialized libraries have emerged to abstract away the complexities of data fetching, caching, and synchronization. The two leading contenders are React Query (part of TanStack Query) and SWR.

Both libraries provide elegant solutions to all the useEffect problems listed above and more. Let's look at a simple example using React Query.

Introducing React Query (TanStack Query)

React Query is a powerful library for managing server state. It provides hooks that handle the entire data fetching lifecycle for you, including:

Caching: Automatically caches fetched data, making subsequent requests instant.
Revalidation: Intelligently revalidates data in the background (e.g., on window focus, network reconnect, interval).
Loading/Error States: Exposes isLoading, isError, data, error from a single hook.
Deduplication: Prevents multiple identical requests from firing simultaneously.
Optimistic Updates: Makes your UI feel instant by updating it before the server confirms changes.
Devtools: Provides an amazing developer experience with a built-in Devtools panel.

Let's refactor our MyComponent example using React Query:

import React from 'react';
import { useQuery, QueryClient, QueryClientProvider } from '@tanstack/react-query';
import { ReactQueryDevtools } from '@tanstack/react-query-devtools'; // Optional for dev

// 1. Create a QueryClient instance
const queryClient = new QueryClient();

// A simple fetcher function (can be async)
const fetchMyResource = async () => {
  const response = await fetch('/api/my-resource');
  if (!response.ok) {
    throw new Error(`HTTP error! status: ${response.status}`);
  }
  return response.json();
};

function MyComponent() {
  // 2. Use the useQuery hook
  const { data, isLoading, isError, error } = useQuery({
    queryKey: ['myResource'], // Unique key for this query
    queryFn: fetchMyResource, // The function that fetches your data
    staleTime: 1000 * 60 * 5, // Data is considered fresh for 5 minutes
    // You can add many more options here like refetchOnWindowFocus, retry, etc.
  });

  if (isLoading) return <p>Loading data...</p>;
  if (isError) return <p>Error: {error.message}</p>;

  return (
    <div>
      <h1>My Data:</h1>
      <pre>{JSON.stringify(data, null, 2)}</pre>
    </div>
  );
}

// 3. Wrap your App or a portion of it with QueryClientProvider
function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <MyComponent />
      {/* Optional: React Query Devtools for debugging */}
      <ReactQueryDevtools initialIsOpen={false} />
    </QueryClientProvider>
  );
}

export default App;

Look at how much cleaner and more robust this is!

No useState for loading/error.
No isMounted flags.
Automatic caching.
Automatic revalidation.
Less code, fewer bugs, better user experience.

What about SWR?

SWR (stale-while-revalidate) by Vercel offers a very similar and equally powerful API. It's also an excellent choice and shares many of the same benefits as React Query. The choice between them often comes down to personal preference or specific feature requirements. Both are vastly superior to manual useEffect fetching.

When useEffect IS Appropriate (The Nuance)

This isn't to say useEffect is evil or useless. It has its place:

Synchronizing with external systems: Think integrating with a third-party analytics script, a WebSocket connection, or manually interacting with the DOM (e.g., measuring an element's size).
Logging: Sending analytics events when a component mounts or a specific state changes.
Setting up subscriptions: When you need to subscribe to an event listener and clean it up.

The key distinction is that useEffect is for synchronizing internal component state with an external system, not for managing server state that should be cached, revalidated, and deduplicated.

Conclusion: Evolve Your React Data Fetching

If you're still relying on useEffect for the bulk of your data fetching in React, you're likely working harder, writing more code, and introducing more potential bugs than necessary.

Modern React applications benefit immensely from dedicated data fetching libraries like React Query or SWR. They treat server state as a first-class citizen, providing a robust, performant, and delightful developer experience.

It's time to stop treating useEffect as your primary data fetching solution and embrace the tools built specifically for the job. Your code will be cleaner, your app faster, and your debugging sessions shorter.

What are your thoughts?

Are you still using useEffect for data fetching, or have you made the switch to a library like React Query or SWR? What challenges did you face, and what benefits have you seen? Let's discuss in the comments below!

ASTROWORLD Intranet: Modern Digital Workspace

Courage Labhani Paul — Mon, 28 Jul 2025 11:34:31 +0000

This is a submission for Frontend Challenge: Office Edition sponsored by Axero, Holistic Webdev: Office Space

I've built ASTROWORLD, a comprehensive intranet homepage that transforms how teams collaborate and access information. This responsive dashboard serves as a central hub for workplace communication, resource sharing, and project tracking - all wrapped in a visually engaging interface.

What I Built
ASTROWORLD is a feature-rich intranet solution designed to enhance workplace productivity and connection. Key components include:

Personalized Dashboard with user-specific welcome messages
Upcoming Events calendar with meeting details
Resource Library for quick document access
Team Spotlight with colleague profiles and status indicators
Project Tracking with visual progress bars
Team Availability sidebar showing real-time status
Dark/Light Mode toggle with persistent user preference

The interface balances aesthetics and functionality, featuring clean typography, consistent spacing, and purposeful color coding for intuitive information hierarchy.

Demo
Experience ASTROWORLD live:
View Full Page Demo

Journey
Creating ASTROWORLD was a rewarding challenge that pushed my frontend development skills to new heights.

Design Philosophy
I focused on creating a workspace that balances professionalism with visual appeal:

Blue gradient theme conveys trust and innovation
Card-based layout organizes information intuitively
Strategic white space reduces cognitive load
Purposeful animations enhance interaction
Consistent iconography improves navigation

Technical Implementation
I built the entire interface with pure HTML, CSS, and vanilla JavaScript:

CSS Grid and Flexbox for responsive layouts
CSS Variables for consistent theming
Mobile-First Approach with progressive enhancement
Semantic HTML for accessibility
Canvas API for dynamic avatar generation
LocalStorage for theme persistence

Challenges Overcome
The most complex aspects included:

Creating a responsive layout that adapts from desktop to mobile
Implementing smooth dark/light mode transitions
Developing the interactive notification system
Generating dynamic team member avatars
Ensuring consistent spacing and typography hierarchy

Accessibility Focus
I prioritized inclusive design with:

4.5:1 minimum color contrast ratios
Semantic HTML structure
Keyboard navigable interface
ARIA roles and labels
Focus states for interactive elements

What I'm Proud Of

Dynamic Avatar System: Automatically generates unique profile images
Theme Persistence: Remembers user's dark/light mode preference
Interactive Cards: Hover and click effects that provide feedback
Performance Optimization: Entire solution under 20KB
Real-Time Status Indicators: Visual cues for team availability

Lessons Learned
This project deepened my understanding of:

Advanced CSS Grid techniques
Accessibility best practices
JavaScript event delegation
Performance optimization strategies
User-centered design principles

ASTROWORLD represents my vision for a modern digital workspace - connecting people, resources, and information in an intuitive interface that adapts to user preferences and device constraints.

License: MIT License
Note: By submitting this entry, I grant Axero Solutions a worldwide, royalty-free license to use this submission in accordance with the challenge terms. I affirm that I hold all necessary rights to grant this license.

Welcome to My Office (Made with CSS Magic ✨)

Courage Labhani Paul — Wed, 23 Jul 2025 11:43:21 +0000

This is a submission for Frontend Challenge: Office Edition sponsored by Axero, CSS Art: Office Culture.

Ever stared at your screen for too long and thought, “What if my office desk was made entirely out of CSS?” No? Just me? Well… I did it anyway. I built a full-blown, interactive CSS art piece that captures the chaos, charm, and caffeine-fueled spirit of modern office life. From your keyboard lighting up as you type that email for the 7th time, to your favorite mug steaming with infinite coffee, it’s all here.

🖼️ Click Here for the Live Demo

🔍 What’s Inside?

Let’s take a quick office tour:

💻 A monitor with endlessly scrolling code (because bugs never sleep)
⌨️ Keyboard keys that light up like a rave every time you hover
☕ Coffee mug steaming like it’s brewing life into your soul
🧊 Water cooler with animated convos (yes, tea is being spilled)
🪴 Plants that gently sway because HR said "Add greenery"
🏢 A window-lit building to remind you it's still Monday
📱 Fully responsive, so your office shrinks perfectly to mobile size!

✍️ My Creative Process (aka how I almost lost my mind but didn’t)

I started by sketching out the scene. Yes, on actual paper. Then came the fun part turning each element into CSS. I used:

Gradients, borders, and pseudo-elements for juicy details
Over 10 custom animations (because stillness is boring)
Media queries to keep the art from falling apart on mobile

💡 Fun Things I Learned:

How to make a cup of coffee.......with CSS
That animating a keyboard can feel oddly satisfying
You can make conversations happen at the water cooler, even in code

🚀 Next Steps:

Add draggable sticky notes (because who doesn’t like dragging stuff?)
Make a day/night toggle so you can switch from burnout to blackout
Maybe add sound effects? (Typing ASMR, anyone?)

Built using 100% HTML and CSS (and just a sprinkle of JavaScript for those snazzy key animations). MIT licensed, so feel free to fork, remix, and add your own coffee mug 😄

Let me know what you think or what I should add next!

Research Assistant Built with Runner H: Paper Reviews in Minutes

Courage Labhani Paul — Thu, 26 Jun 2025 14:51:58 +0000

This is a submission for the Runner H "AI Agent Prompting" Challenge

What I Built

I built an AI-powered Research Assistant using Runner H that automates the entire literature review process. The agent:

🔍 Searches arXiv, PubMed, and IEEE for newly published papers
🧠 Filters results by recency (7 days) and relevance (85%+)
✍️ Extracts core contributions, methodologies, and limitations
📄 Compiles clean, publication-ready summaries in Google Docs
📢 Instantly posts the final report to Slack for easy team access

Whether you're a researcher, student, or startup founder, this on-demand agent saves hours and delivers high-quality insights in just one prompt.

Demo

📹 Watch the full workflow in action:

🖼️ Screenshots:

1. Generated Research Summary in Google Docs

2. Slack Notification with Summary Link

How I Used Runner H

The Full Prompt: "You are my Research Assistant. First, ask me what topic I would like the research summary to focus on. Once I provide the topic, confirm it by saying something like “Great, you’ve chosen: [Topic]. Should I proceed?” After confirmation, search arXiv, PubMed, and IEEE for new academic papers related to that topic, filtering for those published in the past 7 days with relevance score >85%. For each paper, extract the core contribution in one sentence, list three key methodologies used, and identify any limitations. Compile the findings into a Google Document titled “[Topic] Research Summary – [Date]”, formatted with clear sections for the title, contribution, methodologies, and limitations for each paper. Finally, share the link to the Google Doc in the Slack #research channel with a brief summary message".

🛠️ What the Agent Does
This prompt powers an autonomous research assistant that handles the entire literature review process from a single input. Here's how the workflow breaks down:

1. Dynamic Topic Collection
The agent starts by asking the user to provide a research topic, this keeps it reusable across fields and disciplines.

2. Intelligent Search + Filtering
It searches arXiv, PubMed, and IEEE Xplore for relevant academic papers published in the last 7 days, then filters out any that score under 85% relevance based on semantic similarity to the given topic.

3. Structured Information Extraction
For each papers, the agent extracts:

A core contribution summary
Three key methodologies
Any stated limitations by the authors

4. Formatted Report Generation
The agent automatically creates a Google Doc with organized sections, making it ready for publishing, team review, or academic citation. Each paper is clearly broken into Title, Contribution, Methodologies, and Limitations.

5. Slack Integration
The final document is posted directly into a dedicated Slack channel (#research) so the team or user can access the latest findings instantly.

Use Case & Impact

This solution is perfect for:

🧪 PhD students and academic researchers conducting topic reviews
💼 Startup founders and execs keeping up with trends in their domain
📊 Product, growth, and AI teams needing technical insight without drowning in PDFs
🎓 Students working on dissertations, term papers, or proposals

🔍 Why It Matters

Manual literature reviews are time-consuming and error-prone.
Searching across multiple databases and extracting meaningful insights takes hours.
Most people don’t have a system for filtering by relevance, and often rely on keyword matches alone.

This agent delivers:

🚀 Speed — cuts down research time by 80%
🎯 Precision — filters irrelevant results with semantic analysis
🧘🏾‍♀️ Convenience — compiles everything and drops it in Slack, hands-free
♻️ Reusability — works across any research domain with zero code changes

It's a scalable way to support better, faster, and more informed decision-making in research-driven environments.

Social Love

// Detect dark theme var iframe = document.getElementById('tweet-1938246094917407069-411'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1938246094917407069&theme=dark" }

I’d love to be considered for the Community Champion prize category, this project is for researchers, students, and anyone trying to save time with AI!