DEV Community: Eren Sümer

I got tired of explaining what "make it look better" means to Claude, so I built Form & Force

Eren Sümer — Tue, 03 Nov 2026 19:54:20 +0000

I've been using Claude Code quite heavily for frontend projects. It's genuinely impressive how much you can get done with it, but there's one particular part of the process that has always been frustrating for me.

Design.

Not getting a page to render. Not connecting components or setting up the application. I'm talking about the actual decisions behind a good interface.

Typography, composition, visual hierarchy, interaction design, motion, little details that make a website feel considered rather than assembled.

I kept running into the same situation.

I'd ask Claude to build something, get a perfectly functional result, and then spend the next hour explaining why it felt generic. The usual layouts would appear, familiar gradients would show up, and animations would be added without really contributing anything to the experience.

I'd ask for something more original, and get a slightly different version of the same thing.

At some point I realized that I was trying to solve a workflow problem with more prompting.

That's where Form & Force started.

GitHub: https://github.com/erenthedeveloper0/form-and-force

The idea behind it

I didn't want to create another prompt collection that tells Claude to use better typography, add some interesting animations and make everything feel premium.

I wanted to give it an actual process to follow.

Form & Force is an open-source Agent Skill and Claude Code plugin focused on frontend design, creative direction and motion engineering.

It covers everything from marketing websites and portfolios to SaaS applications, dashboards, e-commerce, editorial experiences and design systems.

The interesting part is how it approaches the work.

1. Understand the project before touching it

This is something I consider particularly important when working with existing repositories.

An agent shouldn't immediately start replacing components just because it has a different idea.

Form & Force begins by inspecting the repository, its architecture, dependencies, existing components and current implementation.

It also considers the actual product, its audience and the user journeys involved.

The idea is to make decisions based on what already exists rather than treating every project as a blank canvas.

2. Come up with an actual creative direction

Before implementation, the skill explores three different creative directions.

These aren't supposed to be three variations of the same layout with different color palettes.

They should have different visual ideas, compositions and design approaches.

The directions are evaluated, one is selected, and that direction becomes the basis for the design system.

This includes things like:

Typography and type hierarchy
Layout and composition
Colors, materials and visual texture
Component behavior
Motion principles
Interaction patterns

I wanted the design to have a reason behind it instead of being a collection of trendy UI decisions.

3. The anti-slop component atlas

This is one of the parts I've spent quite a bit of time on.

I put together a component atlas covering 180 components across 12 families.

It looks at common interface patterns, explains where they tend to become generic, and explores stronger alternatives when the project calls for them.

Something worth mentioning: the intention isn't to ban familiar components.

A navbar is still a navbar. A pricing section doesn't have to become some experimental piece of art.

Sometimes the conventional solution is exactly the right one.

The important distinction is whether a component is there because it serves the product or because the model has seen the same pattern thousands of times.

4. Motion should have a purpose

I also wanted motion design to be treated as part of the design process, not something added at the very end.

The skill includes guidance for animation identity, hierarchy, choreography and signature moments.

It covers implementation approaches involving CSS, WAAPI, View Transitions, GSAP, Lenis, Motion and Three.js.

That doesn't mean every project needs a cinematic preloader or a page full of scroll-triggered animations.

A subtle transition can be much more effective than a complicated animation that interrupts the experience.

5. Actually inspect what was built

I didn't want the workflow to end with Claude saying that everything looks great.

There are several bundled scripts for inspecting and checking the resulting work:

inspect_repo.mjs for repository inspection.
slop_scan.mjs for static interface-pattern checks.
audit_page.mjs for rendered browser auditing through Playwright.
contact_sheet.mjs for generating visual contact sheets.

The browser audit can also cover keyboard navigation and reduced-motion behavior.

There are additional references for accessibility, responsive design, performance, security and implementation.

The scripts can be used independently of the skill, too.

For example:

node skills/form-and-force/scripts/inspect_repo.mjs ./my-project

node skills/form-and-force/scripts/slop_scan.mjs ./my-project --strict

The static scanner doesn't require an API key or paid model call. The rendered audit requires Playwright and Chromium.

Try it

Form & Force is MIT-licensed and open source.

Install it through Claude Code:

claude plugin marketplace add erenthedeveloper0/form-and-force

claude plugin install form-and-force@form-and-force

Once installed, you can invoke it directly:

/form-and-force:form-and-force

Or simply describe the frontend work you're doing and let Claude load the skill when relevant.

There's also a standalone Agent Skill package available through the Skills Registry.

Repository: https://github.com/erenthedeveloper0/form-and-force

A few things I'm not claiming

I want to be honest about where the project currently stands.

I haven't run the paid behavioral evaluations yet, so I don't have measured evidence that Form & Force produces better outcomes than Claude without the skill.

The static scanners and browser audits are heuristic checks, not proof that a website is accessible or performs well in production.

I think this distinction matters, especially when building tools intended to improve AI-generated work.

I'd rather have people understand what the project currently does than make exaggerated claims about it.

Where I'd like to take it

There's still a lot I'd like to explore.

I'm particularly interested in making the evaluation of generated interfaces more reproducible. We can talk about visual quality all day, but figuring out how to evaluate it consistently is a much harder problem.

I'd also like to keep improving how creative direction translates into actual implementation, especially for more unusual projects where conventional frontend patterns aren't necessarily appropriate.

For now, I'd love to get more developers using it and hear what breaks, what feels unnecessary, and what could be better.

If you work with Claude Code or build agent skills yourself, I'm particularly interested in your thoughts.

What do you think is the biggest weakness of AI-generated frontend design right now: the creative decisions, the implementation, or the way we evaluate the final result?

Thanks for reading!

— Eren

I'm Building zen.js: A Compiler-First Web Framework for Node.js

Eren Sümer — Fri, 16 Oct 2026 19:46:34 +0000

I've been building zen.js, an open-source, compiler-first web framework for Node.js, and I want to share the idea behind it.

The question that started this project was simple:

What if a web framework compiled your application before the first request instead of repeatedly interpreting its structure at runtime?

Not a new wrapper around an existing framework. Not another routing library with a different API. A different way to think about how a Node.js framework should work.

GitHub: https://github.com/erenthedeveloper0/zen

The idea behind zen.js

Most web frameworks let you define routes, middleware, validation, and response handling through familiar abstractions. Those abstractions make applications easier to build, but they also give the framework information about your application that can potentially be resolved before requests arrive.

zen.js explores what happens when we do more of that work at startup.

The central idea is:

A web framework is a compiler with an HTTP server attached.

In zen.js, application registration acts as the input. At startup, the framework builds a frozen application graph and compiles route-specific request pipelines from it.

Conceptually, a request follows this path:

Route → Parameters → Middleware → Validation → Handler → Serialization → Response

The important distinction is that the framework doesn't need to repeatedly interpret the same higher-level application structure to execute that path.

Stages a route doesn't use can be absent from the generated code rather than sitting in a pipeline waiting to be skipped.

This isn't a native-code compiler. It's about compiling framework metadata into the JavaScript that executes your application's request path.

What does it look like to use?

I wanted the basic API to feel familiar rather than forcing developers to learn an entirely new way of building servers.

Here's a minimal example:

import { zen } from "@erenthedeveloper0/zen";

const app = zen();

app.get("/", () => "Hello world");

await app.listen(3000);

Install the current alpha:

npm install @erenthedeveloper0/zen@alpha

Two basic concepts get you started: register a handler with app.METHOD(path, handler), and return the response from that handler.

The interesting part isn't the number of lines in this example. It's what happens to the application definition after registration.

1. Compile the request path, not just the route table

Routing is only one part of a request.

Middleware ordering, validation, hooks, response serialization, and the request context all affect execution. zen.js attempts to resolve as much of that structure as possible during startup.

That also opens the door to better diagnostics.

For example, conflicting or ambiguous routes can be rejected at boot instead of letting registration order silently determine which route wins. The framework can explain a resolved route's execution chain, and its request-inspection tools can show which steps ran and how they behaved.

The generated code is inspectable, too. I want the architecture to be something developers can examine and challenge, not a black box hidden behind a performance claim.

2. Let schemas define the contract

The second major idea is that a schema should be more than a validation step.

In zen.js, the same contract can drive:

Input validation and handler types.
Response serialization and filtering.
OpenAPI document generation.

For example, when a route declares a response schema, the generated serializer can exclude fields that aren't part of that schema.

That matters for more than performance. An application might return a database record containing internal fields that should never reach a client. The response contract should define what's allowed on the wire.

The goal is to keep the implementation, type system, serialized response, and API documentation aligned instead of maintaining several separate versions of the same contract.

zen.js supports the Standard Schema ecosystem, so libraries such as Zod, Valibot, and ArkType can be used without framework-specific adapters.

3. Make correctness visible

Performance is one motivation, but I don't want the project to be only about throughput.

I'm also interested in making framework behavior easier to understand and verify.

Some examples of what's implemented today include:

Boot-time route conflict analysis with detailed diagnostics.
Compiled middleware and lifecycle hooks.
Schema-driven response serialization.
OpenAPI 3.1 generation from the application graph.
Request deadlines, health checks, and readiness handling.
Request-inspection tools and application graph fingerprints.

These features are part of a broader attempt to make framework behavior explicit, inspectable, and testable.

The architecture is ambitious, and having a detailed architecture document doesn't mean every planned subsystem is already implemented. I'm trying to keep that distinction clear as the project evolves.

What about performance?

I don't want to claim that zen.js is the fastest Node.js framework.

The repository includes benchmarks comparing workloads against other frameworks and Node's HTTP server, along with the measurement methodology and limitations. The results vary by workload, and the project still has room to improve.

The point of the compiler-first approach is to make runtime work more deliberate. Benchmarks are one way to evaluate whether that design delivers practical benefits; they aren't a substitute for understanding the trade-offs.

I'd rather publish measurements that can be reproduced and criticized than lead with a headline number that hides the details.

Where the project stands

zen.js is currently at 0.2.0-alpha.

The current implementation is a working vertical slice, but the project is not production-ready. The API can change before 1.0, and some parts of the broader architecture are still unimplemented.

It currently targets Node.js 22.6 or newer, with TypeScript 5.0 or newer when using TypeScript. The core package has zero runtime dependencies.

I'm sharing it at this stage because architecture is easier to challenge while a project is still evolving than after its decisions have become difficult to change.

I'd genuinely appreciate your feedback

I'm particularly interested in hearing from developers who have worked on Node.js frameworks, routers, compilers, TypeScript-heavy backends, or API tooling.

A few things I'd like to understand:

Is compiling the application graph at startup a useful architectural direction, or am I moving complexity from runtime into boot?
Which framework abstractions do you think can be eliminated or simplified through compilation?
Where would you expect this design to become difficult to maintain?
What benchmarks, edge cases, or real-world workloads should I investigate next?

You don't need to adopt zen.js or agree with the approach. A thoughtful architectural criticism is just as useful as a feature request.

Explore zen.js

GitHub: https://github.com/erenthedeveloper0/zen

Architecture: https://github.com/erenthedeveloper0/zen/blob/main/ARCHITECTURE.md

Benchmarks: https://github.com/erenthedeveloper0/zen/tree/main/benchmarks

Changelog: https://github.com/erenthedeveloper0/zen/blob/main/CHANGELOG.md

If the idea interests you, I'd appreciate a look at the code, an issue describing a potential weakness, or a discussion about the architecture.

I'm building zen.js in the open, and feedback from people who understand these systems can help me make better decisions before the project reaches 1.0.