In 1995, you created index.html, wrote

Hello

, uploaded it to a server, and it worked. The feedback loop was measured in seconds. A twelve-year-old could build a website in an afternoon. The entire web was built by people who were not professional programmers -- they were teachers, students, hobbyists, small business owners who needed a presence on this new thing called the internet.

In 2024, creating the equivalent of that hello world requires installing Node.js, initializing a project, installing React, ReactDOM, Vite, TypeScript, type definitions, Tailwind, PostCSS, Autoprefixer, ESLint, Prettier, and then creating a dozen configuration files before writing a single line of application code. The dependency count approaches 2,000 packages. The disk footprint exceeds 1.5 gigabytes. The time to first render is measured in hours.

FLIN exists because we believe this trajectory is not inevitable. It is a choice the industry made, and it is a choice we can unmake. Not by going backward to the limitations of 1995, but by going forward -- building a language that delivers the simplicity of that era with the full power of 2026: a compiler, a virtual machine, an embedded database, reactive UI, and an HTTP server. All behind a single file.

This article tells the story of that vision: where it came from, what it looks like in practice, and why the complexity of modern web development is not a natural law.

The Complexity Explosion: A Timeline

To understand FLIN's reason for existence, you need to see how we got here. The numbers are not exaggerated -- they are conservative.

Year    Files for "Hello World"    Dependencies    Config Files    Disk Space
----    -----------------------    ------------    ------------    ----------
1995    1 (index.html)             0               0               3 KB
2005    3 (HTML/CSS/JS)            0               0               15 KB
2010    10 + jQuery                5               1               500 KB
2015    50 + Gulp                  200             5               80 MB
2020    500 + Webpack              1,000           10              500 MB
2024    50,000+                    2,000           15+             1.5 GB

Each step in this progression was rational in isolation. jQuery solved cross-browser compatibility. Gulp solved build automation. Webpack solved module bundling. React solved UI state management. TypeScript solved type safety. Tailwind solved CSS utility classes. Each tool addressed a real problem.

But the aggregate effect is that the tools meant to help us have become the problem. A modern developer spends more time configuring tools than writing application code. The learning curve, once measured in days, now takes months. And in emerging markets -- where internet is slow, data is expensive, and power is unreliable -- downloading 1.5 GB of node_modules is not an inconvenience. It is a barrier to entry.

The Observation That Started FLIN

FLIN was born from a simple observation: most web applications do the same five things.

1. Display data to the user. 2. React to user input. 3. Save data to a database. 4. Query data from a database. 5. Handle HTTP requests.

Five things. And yet, to do these five things in 2024, you need React for the first, a state management library for the second, Prisma or TypeORM for the third and fourth, Express or Fastify for the fifth, plus TypeScript, Vite, ESLint, Prettier, Tailwind, and a dozen configuration files to wire them all together.

The question that launched FLIN was: what if a single tool did all five things natively?

Not a framework. Not a library. Not a "batteries-included" toolkit that still requires npm and Node.js under the hood. A programming language. One where reactivity, persistence, queries, and HTTP handling are built into the syntax itself, the way arithmetic and string operations are built into every language.

What FLIN Looks Like: The Simplest App

Here is a complete, working FLIN application. Not a toy. Not a "hello world" that leaves out the hard parts. A functional counter with a button that increments a number and displays it:

count = 0

{count} ```

Two lines of logic. One line of view. Save it as app.flin. Run flin dev. The browser opens. You click the button. The number goes up. There is no import statement, no configuration file, no build step, no package manager, no framework initialization.

Compare this with the React equivalent:

import { useState } from 'react';

export default function Counter() { const [count, setCount] = useState(0); return ( setCount(count + 1)}> {count} ); } ```

The React version requires understanding imports, the useState hook, arrow functions, JSX syntax, and the concept of a default export. The FLIN version requires understanding variables and HTML. A twelve-year-old who knows what means can read the FLIN code and understand what it does in thirty seconds.

This is not a superficial difference. It is the difference between a language designed for developers who already understand programming, and a language designed for humans who want to build things.

What FLIN Looks Like: A Real Application

The counter is simple on purpose. Here is something real: a complete todo application with persistent storage, filtering, and CRUD operations.

todos = []
filter = "all"
newTodo = ""

entity Todo { title: text done: bool = false created: time = now }

filtered = match filter { "all" -> Todo.all "active" -> Todo.where(done == false) "completed" -> Todo.where(done == true) }

My Todos

All Active Done

{for todo in filtered}

{/for}