DEV Community: whaiman

Why Next.js Feels Like Flask, Rewritten in TypeScript

whaiman — Sun, 30 Aug 2026 10:59:04 +0000

I spent over a year writing backend code in Flask. When I started a new project, I decided to try Next.js. The first thing I noticed was déjà vu. This felt like Flask, rewritten in TypeScript with a newer take on rendering.

React itself works well for me - a tidy component library, nothing more. Next.js is what I fell for, the App Router most of all. The deeper I dig, the more it looks like a classic server-side framework, with extras Flask would never build on its own.

My Flask experience isn't from tutorials. I built FileServer on it (the project is moving to FastAPI now, since the old code stopped scaling). That work is what showed me how much these two tools overlap in concept.

Templating and layouts

In Flask with Jinja, you build a base.html with a {% block content %} block, and users.html extends that template. Header, footer, navigation - written once, not copied on every page.

Next.js does the same job with layout.tsx. You set it at the folder level, and every page inside wraps in it, no extra code needed. App Router lets you nest layouts at any depth - /admin gets its own layout on top of the shared one. Flask can do this too, through several levels of {% extends %}, but by hand it feels less clean.

Server rendering by default

My first guess: TSX is Jinja with a different syntax. Close, but not exact.

A component in Next.js defaults to a Server Component. It renders on the server, and the browser gets finished HTML, the same way it does after Jinja.

A component turns client-side only when you add 'use client' at the top of the file. That's the real parallel with Flask. Flask never gives you the choice - everything runs on the server. Next.js gives you the choice, and you can mix server markup with interactive pieces in the browser.

Data fetching

In Flask, you write the data-fetching logic right in the route, then pass it to the template:

@app.route('/users')
def users():
    users = db.get_all_users()
    return render_template('users.html', users=users)

In Next.js, Server Components let you do the same thing inside the component itself, with no extra API endpoint to build:

// app/users/page.tsx
export default async function UsersPage() {
  const users = await db.user.findMany();
  return <ul>{users.map(u => <li key={u.id}>{u.name}</li>)}</ul>;
}

It still feels like writing backend code.

Dynamic routes

Flask: @app.route('/user/<int:user_id>'), and user_id arrives in the function as an argument.

Next.js uses the same idea with square brackets in the folder name: app/user/[id]/page.tsx, and you pull it out as params.id. Different syntax, same idea - a piece of the URL becomes a variable.

Form handling

In Flask, you build a form, set method="POST", and catch the data on the backend through request.form.

Next.js added Server Actions. You write an async function on the server and attach it to the <form> tag with no extra wiring:

async function createUser(formData: FormData) {
  const name = formData.get('name');
  await db.user.create({ data: { name } });
}

<form action={createUser}>
  <input name="name" />
  <button type="submit">Create</button>
</form>

It's the same old POST request, packaged in newer syntax. You don't need a separate API route for simple mutations.

API and HTML in one app

A single Flask app holds /users, which renders HTML, next to /api/users, which runs jsonify(...) and returns plain JSON. One server, two kinds of response.

Next.js works the same way: app/users/page.tsx returns a JSX page, and the neighboring app/api/users/route.ts returns JSON. This is also how I plan to build the FastAPI backend for FileServer - API on one side, frontend on the other, an idea I picked up from the Flask version of the project.

Request lifecycle: middleware

Who sees a request before it reaches your code? In Flask, @app.before_request handles that - a function that runs before every route. Useful for checking auth or logging.

Next.js has middleware.ts at the project root for the same job. It catches the request before it reaches the page, and that's where you handle redirects or check a cookie. It matches before_request almost exactly.

Grouping routes

Next.js has Route Groups - a folder in parentheses like (auth) that groups routes logically without showing up in the URL.

Flask solves the same problem with Blueprints: move the auth routes into one blueprint, the admin routes into another, then register both on the main app. The mechanics differ, but the motivation matches - don't dump every route into one flat pile.

Caching and static files

In Flask, to keep from hitting the database on every request, you add a @cache.cached(timeout=50) decorator.

Next.js builds this into the core, under the name ISR (Incremental Static Regeneration). You export a config variable:

export const revalidate = 60;

Redirects and request context

In Flask, you use redirect(url_for('login')) to send a user elsewhere. For headers, you import the global request object.

In Next.js server code, you do the same thing through dedicated functions instead:

import { redirect } from 'next/navigation';
import { headers } from 'next/headers';

if (!session) redirect('/login');

const token = headers().get('Authorization');

The takeaway

People often file Next.js under "yet another SPA framework." Under the hood, App Router runs a solid server framework that does what Flask does, then lets you drop in client-side JavaScript exactly where you need it. If you know Flask well, Next.js won't take long to pick up. The concepts stay the same. Only the syntax changed.

Why the "AI" Badge Doesn't Matter and How to Restore Trust in Our Code

whaiman — Sun, 16 Aug 2026 12:01:43 +0000

Hello, DEV community! 👋

This is my first post here. I've been reading articles on this platform for a while, but a recent article by @pascal_cescato_692b7a8a20 - "The "AI" Badge Doesn't Measure What You Think It Does" - finally pushed me to join the conversation.

It touches on a topic that's been on my mind for a while: the "AI-generated" badge, which is being actively pushed across media platforms, doesn't actually tell us anything useful.

Whose thought is it anyway?

As Pascal brilliantly breaks down, we constantly conflate three fundamentally different ways of working:

Assisted. When the idea, structure, and artificial decisions belong entirely to the human. A model is used to rephrase, translate, fix regex, or pressure-test arguments.
Generated. A human gives a prompt, but the model produces the actual thought and text.
Produced. Automated pipelines generating content at an industrial scale without human oversight.

A binary badge (or statistical watermark) treats all three identically. An engineer who spends hours architecting a system, writing core logic, and using LLM to polish a comment or write boilerplate get shoved into the same bucket as an automated spam farm.
The real line of ownership isn't drawn by how much a model intervened, but by who kept their hand on the decisions. Who designed the solution? Who discarded the bad outputs? Who took responsibility for the final architecture?

Proof of work instead of broken labels

Detectors and badges look at the final shape of a file and guess its origin. But as Pascal proved by running his 2021 pre-LLM article through ZeroGPT (getting scores ranging from 97% to 8.6%), detectors merely chase stylistic neutrality, not actual origin.

We are seeing the exact same flaw happening in programming. Today, there are various code analyzers and enterprise tools designed to detect "AI-generated code". While writing software is fundamentally different from writing prose, the detection methodologies share the exact same underlying bias.

Just as text detectors flag well-structured, pedagogical paragraphs as "AI," code detectors often flag clean, canonical, and boilerplate code. If an engineer writes a textbook algorithm, strictly follows naming conventions, or implements standard design patterns, they risk being falsely flagged. The detector mistakes professional standardization for machine generation. It judges the final shape without knowing the process.

This exact problem led me to create dev-ledger - an open-source VS Code extension designed as a conceptual evolution of time-trackers like WakaTime.

But unlike traditional trackers that send your activity to a third-party server, dev-ledger is 100% local-first. All data collection and behavioral analysis happen directly on your machine - no APIs, no telemetry, no cloud. To guarantee the authenticity of your timeline, it secures your local event log with a cryptographic hash chain. It gives you a mathematically tamper-proof "Proof of Work" that you fully control, without sacrificing your privacy.

Instead of slapping a meaningless "100% Human" or "AI Generated" badge on a project, this approach shifts the focus back to transparency. By unobtrusively recording keystrokes, active editing time, and structural modifications, it documents the actual process - the iterations, the refactoring, and the human effort behind a codebase. It then converts this data into automated reports and visual SVGs for your README.md, backed by an integrity hash.

When someone looks at a repository equipped with this kind of timeline, they don't have to blindly trust a flawed detector or guess the code's origin based on its "final shape." They can actually see the chain of decisions and the problem-solving process that went into building it.
We probably can't stop platforms from implementing broken AI detectors or pushing binary badges. But as engineers, we can choose to shift the conversation back to what actually matters: the depth of our thought and the transparency of our work.

If you share this philosophy and want to secure the integrity of your own coding sessions, you can check out the source code and try the extension here:
👉 github.com/whaiman/dev-ledger

(Feedback, GitHub stars, and PRs are deeply appreciated!)

What Metrics Cannot Fix

Building a cryptographic ledger for development activity solves the technical problem of proving effort, but it doesn't fix the social one.
Having a verified hash chain won't stop a cynical reviewer on Reddit or Hacker News from glancing at a clean, well-structured repository and dismissing it as "LLM slop." Just as in writing, the technical demonstration and the social judgment are two completely different things. Often, the reflexive rejection of code as "AI-generated" has nothing to do with the code itself - it’s just a blunt reaction to the anxiety of our industry's current transition.

If badges can't measure origin, and enterprise code detectors can't measure thought, then the question in modern software engineering isn't "who typed this line?" but "who holds the steering wheel?"

Software architecture is fundamentally about making trade-offs, not just generating syntax. An LLM might help write a boilerplate function or figure out a tricky regex, but it doesn't conceptualize a local-first system. It doesn’t weigh the security implications of a cryptographic hash chain against a centralized database. The engineering intent - the real heavy lifting - remains entirely human.

When we reduce a developer's contribution to a binary label, we erase the unseen hours spent designing data models, debugging AI hallucinations, and rejecting bad abstractions. We erase the actual engineering.

Code analyzers and enterprise detectors will only ever scan the final repository. They parse the Abstract Syntax Tree (AST) looking for generic patterns, completely blind to the iterative struggle that brought that structure into existence. But true ownership of software isn't found in the finalized syntax. It lives in the problem-solving, the discarded ideas, and the chain of architectural choices that made that code necessary in the first place.