DEV Community: Royshell

I got tired of ugly websites. So I built a tool to fix them (and yes it has AI)

Royshell — Thu, 12 Mar 2026 23:15:34 +0000

We've all been there.

It's 11pm. You're reading an article. The background is blinding white. The font is tiny. There are three cookie banners, a chat bubble, a newsletter popup, and somehow also an ad shaped like a button that says "CONGRATULATIONS."

I got fed up. So I built Polish ✦ 🇵🇱 - a Chrome side panel that lets you restyle any website, instantly, without touching the code.

For the record: I am Polish (well at least, I hold a Polish citzenship). The name was inevitable. I had no choice.

I also have some accessibility background, which means I've spent a lot of time thinking about how people actually read and interact with the web — and how badly most websites fail at it. Polish is partly a product of that frustration. Readable fonts, better contrast, focus mode that strips the noise — these aren't just nice-to-haves. For a lot of people, they make the difference between being able to use a site or not.

What it does

You open the panel, you click a few things, and the page transforms in front of you. No settings menus. No extensions with 47 permissions you don't understand. Just: make this look better.

One-Click Polish gives you five toggles:

Dark Mode
More Contrast
Focus Mode ← this one removes ads, cookie banners, sidebars, popups, and chat widgets. It's kind of life-changing.
Extra Spacing
Readable fonts

Theme Presets are full-page visual vibes — Miami Vice, Cyber Mode, Night Owl, Newspaper, Clean Reader. Yes, Miami Vice is a legitimate reading mode.

Fine-Tune lets you adjust font size, heading scale, colors, and font family if you're the kind of person who has opinions about typography. (You're a developer. You do.)

AI Style is the fun one. You type something like "make this look like a retro terminal" or "luxury magazine, serif fonts, warm tones" and it generates a full CSS style for the page. Powered by Llama via Groq, running server-side so you don't need an API key.

The stack

Vue 3 + TypeScript + Vite
Tailwind CSS v4
Pinia
Chrome Extension Manifest v3
Groq / Llama proxy (separate repo)

It was a genuinely fun project to build. Chrome extensions have their own weird rules — no cross-origin fetch from the side panel, service workers instead of background pages, scripting permissions that require jumping through hoops. Worth the pain.

It's open source. Come break things with me.

The project is early. It works, it's useful, but there's a lot of room to grow:

More theme presets
Shareable styles
Better per-site memory
Whatever you think would be cool

If any of that sounds interesting, the repo is here:
👉 github.com/Royshell/polish

Stars are appreciated. PRs are more appreciated. Opinions in the comments are fine too.

Now if you'll excuse me, I have some websites to fix.

I Built a Production-Ready AI Agent with NestJS and React (and You Can Steal It)

Royshell — Sun, 01 Feb 2026 16:18:48 +0000

TL;DR

Building an AI agent in 2026 is way less scary than it sounds.

Most of the time, it’s just clean backend architecture + smart API calls to LLMs.

I built a production-ready boilerplate using NestJS + React that gives you a working AI agent (with streaming chat UI) in under a minute.

👉 Steal the code here:

https://github.com/Royshell/ai-agent-nest-react-boilerplate

Fork it. Copy it. Rip it apart. That’s what it’s for.

“AI Agents” Sound Big. The Reality Is Smaller (and Better)

If you hang around developer Twitter or LinkedIn long enough, “AI agents” start to feel like this massive, abstract thing:

autonomous reasoning
tool orchestration
memory systems
workflows and planners

And sure — those things exist.

But here’s the reality for most real-world AI apps:

An AI agent is just an application that calls an LLM API in a structured way.

You don’t need to understand transformers.

You don’t need to train models.

You don’t need a PhD.

You need:

an API key
a backend endpoint
a clean way to stream responses
a UI to display them

That’s it.

The Basic AI Agent Flow (No Magic)

Almost every modern AI app follows the same steps:

Sign up to an LLM provider (Gemini, OpenAI, Claude, etc.)
Generate an API key
Store it in your backend .env
Create an endpoint that sends prompts to the LLM
Stream tokens back to the client
Render them in the UI

Different providers, same idea.

HTTP + JSON + streaming.

This boilerplate focuses on getting that flow right, cleanly and predictably.

Why NestJS for the Backend?

I wanted a backend that feels:

production-ready
readable
easy to extend later

NestJS gives you:

clear module boundaries
dependency injection
controllers vs services separation
structure without over-engineering

In this project, the backend is built in a module-driven design.

There’s a dedicated module responsible for AI / LLM interaction — not scattered logic inside random controllers.

Example: Chat Endpoint (Complete & Simplified)

Below is a fully copyable, simplified version of the chat endpoint.

import { Body, Controller, Post, Res } from '@nestjs/common';
import { Response } from 'express';
import { AgentService } from './agent.service';
import { ChatDto } from './dto/chat.dto';

@Controller('chat')
export class ChatController {
  constructor(private readonly agentService: AgentService) {}

  @Post()
  async chat(@Body() dto: ChatDto, @Res() res: Response) {
    // The controller stays thin and boring on purpose
    return this.agentService.streamChat(dto, res);
  }
}

The controller does almost nothing — by design.

All the interesting logic lives inside the agent service, which:

talks to the LLM provider
handles streaming
stays isolated from HTTP concerns

That separation is intentional and makes the system easy to extend later.

“But This Is Just a Chatbot…”

Yes.

And that’s the point.

A chatbot is the simplest possible AI agent:

input → reasoning → output

Once you have that working:

the controller can accept any input (not just chat messages)
the agent can call tools
the agent can fetch data
the agent can write to databases

The UI might stay a chat, but the backend can evolve into:

internal assistants
workflow agents
data-aware tools
system controllers

The chat is just the interface, not the limitation.

LLM Providers Are Swappable by Design

The main branch uses Google Gemini because:

the free tier is usable
the API is simple
no credit card required to start

But the architecture doesn’t care.

Each provider lives in its own branch:

openai
anthropic
ollama (local models)

Same agent interface.

Different implementations.

No vendor lock-in.

MCP, Tools, and Databases (What’s Next)

Once you have:

a clean agent layer
a predictable API boundary

You can start connecting real capabilities.

The next step in this project is adding MCP (Model Context Protocol) placeholders.

That opens the door to:

external tools
databases
internal APIs
contextual data sources

Think:

querying a database
calling internal services
reading documents
executing structured actions

The current version doesn’t implement MCP yet — but the architecture is ready for it.

The Frontend: Simple, Modern, and Boring (In a Good Way)

The frontend is built with React + Vite, following modern best practices:

small, focused components
custom hooks for logic
streaming message rendering
clean separation between UI and data fetching

There’s:

a chat component
hooks that manage streaming state
minimal styling (on purpose)

It’s not a design system.

It’s a starting point.

Replace it. Restyle it. Or keep it.

This Is a Boilerplate, Not a Framework

That distinction matters.

You’re encouraged to:

copy files
delete parts
rewrite logic
break conventions

This repo is opinionated enough to be useful — but loose enough to disappear once you’ve taken what you need.

Community First

Seriously:

steal the code
fork it
open PRs
suggest changes
build weird stuff with it

If it saves you a few hours of setup — it did its job.

Final Thoughts

AI agents aren’t magic.

They’re software systems that talk to APIs.

If you can build a backend endpoint and a frontend UI, you can build an AI agent.

Hopefully, this boilerplate helps you skip the boring parts and get straight to building something interesting.

Happy hacking 🚀

And yes — please steal it.

Why I Chose Vue Over React in 2025 (Or: How I Survived 15+ Years of Frontend Without Losing My Mind)

Royshell — Sun, 30 Nov 2025 13:26:46 +0000

I’ve been writing frontend for more than 15 years.
Yes, I was there before it was cool.
Before the hype.
Before performance budgets.
Before every job interview opened with the terrifying question:

"So… what do you know about the rules of hooks?"

Let’s just say this:
If I had one dollar for every time an interviewer asked me about useEffect dependencies, I’d be writing this article from a vineyard in Burgundy.

I Started Back When jQuery, Backbone and Angular.js Ruled the Earth

I’ve worked with the first versions of Angular, early React builds, and even Backbone
(yes, I was there from the beginning, when dinosaurs still roamed the DOM).

I watched these frameworks grow, evolve, mutate and sometimes…
get tangled in their own abstractions.

For many years, React was my favorite.
It was clean. It was minimal. It made sense.
You had render, you had props, you had state — and life was good.

And then… Hooks arrived.

Hooks: The Moment React Started Feeling Less Like React

Look, I’m not saying hooks are bad.
They’re powerful, flexible and elegant when used correctly.

But let’s be honest:

With hooks, React stopped being the small, friendly library I loved
and turned into something more like a university course in lifecycle philosophy.

Suddenly you need to understand:

Why you can’t call hooks inside an if
Why the dependency array includes things you don’t even use
Why missing one dependency triggers a warning longer than your CV
Why your component renders 3 times before saying hello
Why writing a simple effect feels like disarming a bomb

React stayed great - but it definitely stopped being simple.

Still, I’ll give React the credit it deserves:
If your project includes mobile, React Native is a monster of an ecosystem.
In that scenario, React still wins.

But then something happened.

A New Project: No Mobile, No SSR Drama, Just Lots of UI and Fast Iterations

I got a project with no mobile requirements.
Just a lot of UI work, many interactions, rapid iteration, and a client who loves changing requirements every two days.

The priorities were:

Velocity
Simplicity
Flexibility

and also - a codebase that wouldn't fight back.

So I decided to revisit something I hadn’t touched for a while.

And that’s how I rediscovered Vue.

People say Vue has a low learning curve.

Honestly?
If you’ve used Angular and React for years, the learning curve of Vue is not low.

It’s nonexistent.

You open a file, write:

<template>
  <button @click="increment">Clicked: {{ counter }}</button>
</template>

<script setup>
import { ref } from 'vue';

const counter = ref(0);
const increment = () => counter.value++;
</script>

And everything works.
No rules of hooks.
No dependency arrays.
No guessing games.
Just… reactivity.

And that’s the funny part:

Vue is truly reactive.

React, despite its name, is basically a smart re-rendering engine
that we wrapped with conventions and patterns over the years.

Vue’s approach is simpler:

you update a ref =>

Vue updates the DOM =>

you move on with your life.

Try explaining this to someone who spent years debugging useEffect loops.

Vue in a Client Project: This Is Where the Magic Happened

My project required a lot:

dashboards, AI agent interactions, real time-ish UI updates, changing specs from the founders, demo after demo after demo.

Vue made it ridiculously easy to: ship features fast, react to last-minute changes, keep code readable, avoid pointless abstractions, and maintain a clean mental model.

One example: working with the element.

In React, you often need: useRef, useEffect, cleanup functions, conditional renders,and then you must pray that the timing is right.

In Vue:

<template>
  <canvas ref="canvas"></canvas>
</template>
<script setup>
import { onMounted, ref } from 'vue';

const canvas = ref(null);

onMounted(() => {
  const ctx = canvas.value.getContext('2d');
  ctx.fillStyle = 'purple';
  ctx.fillRect(20, 20, 100, 100);
})
</script>

Done.
No lifecycle puzzles.
No cryptic hook behavior.
Just drawing.

My clients loved the speed.
I loved the sanity.
Everyone won.

So Why Did Vue Win for Me in 2025?
1) Because I want to write real code, not fight the framework

Vue gives me that.

2) Because true reactivity beats hook gymnastics

No dependency arrays.
No "why did this effect run again?" moments.

3) Because working with clients demands velocity

Vue is insanely fast for development.

4) Because when mobile isn't involved, React loses its main strategic advantage

No React Native?
Then Vue shines.

5) Because Vue feels like a modern framework built for humans

It has strong opinions, but not too many.
It has magic, but not too much.
It feels natural.

After 15+ years of frontend across Backbone, Angular, React and everything in between,
Vue in 2025 feels like the tool I always wanted but only recently discovered.

React will always have a place in my toolbox.
But in projects focused on UI interactions, speed and clarity,
Vue is my choice moving forward