DEV Community: Hello

Ai Coding with EkkoJS

Hello — Wed, 24 Jun 2026 04:10:44 +0000

Vibe Coding Is Not the Problem. Guessing Is.

Link	Description
EkkoJS	The main website for EkkoJS
Rune	Dedicated documenattion for Rune
Asgard	Dedicated documentation and example for Asgard

If you are tired of hearing that vibe coding is not secure, that you will never ship anything viable, or that AI-assisted development can only produce toys, EkkoJS was built for you.

EkkoJS exists for builders who have taste, motivation, methodology, and loop sensitivity. It is for people who know what they want to build, but do not want to waste half their energy fighting setup, fragmented tooling, outdated documentation, and hallucinated APIs.

EkkoJS is a JavaScript and TypeScript runtime built from the ground up for the AI coding era.

Its core idea is simple:

A runtime should be able to teach any capable AI coding model how to use it, without prior training.

No fine-tuning.
No prior model knowledge.
No guessing.
No fake APIs invented because the model saw something similar in another framework.

With EkkoJS, the runtime itself becomes part of the development loop.

The Real Problem With Vibe Coding

The problem is not that people use AI to code.

The problem is that AI often codes against incomplete, outdated, or missing context.

When a model does not know a runtime, a framework, or a library deeply enough, it starts to approximate. It mixes patterns. It borrows APIs from other ecosystems. It produces code that looks correct, but does not actually run.

That is where the risk begins.

Not in the idea of AI-assisted coding itself, but in the gap between the model's memory and the real tool in front of you.

EkkoJS attacks that gap directly.

EkkoJS Is AI-Self-Sufficient

EkkoJS comes with integrated live runtime guidance.

Through:

ekko doc --llm

a capable AI coding model can extend its working context with accurate, current, runtime-aware information.

That includes documentation, architecture, usage examples, API behavior, and smart error guidance designed to explain how to fix problems instead of letting the model guess.

The result is a tighter loop:

The model asks the runtime how it works.
The runtime provides accurate guidance.
The model writes code using the real installed version.
Errors become explainable instead of mysterious.
Iteration becomes faster and cheaper.

This is what I call Zero-Shot Runtime Coding:

Any capable AI can code with EkkoJS without prior training by following live runtime guidance from the runtime itself.

But Is a Vibe-Coded Web App Secure?

A random vibe-coded web app with no framework discipline, no access control, no middleware, no permission model, and no structure can absolutely become insecure.

That is not a reason to reject AI-assisted coding.

That is a reason to give the AI a better runtime.

With EkkoJS, full-stack web development is not left as an empty playground where every project starts by assembling random packages.

EkkoJS ships with Rune, a full-stack web framework built into the runtime.

Rune gives you, out of the box:

SSR on first load, so SEO is preserved.
Client-side navigation after hydration, so the app feels fast.
File-based routing.
API routes in the same process.
SSR cache and invalidation.
SEO helpers.
Secure-by-default runtime permissions.
A clean full-stack mental model.

Instead of starting from nothing, your AI assistant starts from a runtime that already has structure.

That matters.

Security is not magic. But better defaults reduce the surface for mistakes.

Built-In Security Foundations

EkkoJS is designed to reduce dependency chaos and give developers safer primitives earlier in the project.

For web apps and services, EkkoJS includes familiar backend capabilities such as:

HTTP routing.
CORS middleware.
Secure headers through Helmet-style middleware.
Rate limiting.
Compression.
Runtime permissions.
Testing.
Native I/O APIs.
Database access through one ORM.

Rune also follows a deny-by-default permission approach: the app only touches files, hosts, and environment variables that you explicitly grant.

That is important for AI-assisted coding because the model should not just be able to write code quickly.

It should be guided into writing code inside boundaries.

One ORM, Multiple Databases

Most developers do not want to rewrite their application because the storage choice changes.

EkkoJS includes an ORM designed to reduce the frontier between SQL and NoSQL usage.

The goal is simple: write your application logic once, then target different database drivers with minimal friction.

EkkoJS ORM supports:

SQLite
PostgreSQL
MySQL
Microsoft SQL Server
MongoDB

This means a project can start simple, grow naturally, and avoid turning every database decision into a full rewrite.

For AI-assisted development, this is even more important.

The less fragmented the backend surface is, the less opportunity there is for the model to mix incompatible patterns.

Asgard: A Real React Component Suite

A full-stack framework is not enough if every UI still starts from scratch.

EkkoJS also comes with Asgard, the official React component suite for Rune applications.

Asgard is not just a few buttons.

It includes:

Inputs and forms.
Pickers.
Data display.
Feedback and overlays.
Navigation and chrome.
Layout components.
Docking and IDE-style workspaces.
Theme support.
Accessibility foundations.
Server-rendered components that hydrate cleanly.

This matters because many applications do not fail because the developer cannot write a button.

They fail because building a coherent UI system takes time, discipline, and consistency.

Asgard gives the AI and the developer a shared design surface from the start.

What Can You Build With EkkoJS?

EkkoJS is not limited to one kind of project.

It is a runtime for modern JavaScript and TypeScript development, with zero configuration and direct TypeScript execution.

You can build:

Web Client Apps

For interactive frontends where the browser experience matters.

Full-Stack Web Apps

With Rune, you get fast first render, SEO-friendly HTML, then client-side navigation after hydration.

APIs and Backend Services

With built-in routing, middleware, permissions, native APIs, testing, and database access.

CLI Tools

For rich developer tools, automation scripts, internal workflows, and project utilities.

TUI Applications

For terminal-first experiences with real UX ambition, the kind of interfaces developers now expect from tools like coding agents, assistants, and modern terminal workflows.

Native Desktop GUI Applications

EkkoJS can target native desktop-style applications with system windows, menus, and system tray integration.

One runtime.
One language family.
One mental model.

JavaScript and TypeScript, Out of the Box

EkkoJS does not ask developers to learn an exotic language before they can build.

It uses the standards people already know:

JavaScript
TypeScript
ESM modules

TypeScript runs directly.

No build ritual before you can start.

No configuration wall before your first useful result.

Just write, run, iterate.

Why This Matters for Non-Deep-Technical Builders

Not everyone building software wants to spend their life buried under tooling complexity.

Some people have product taste.
Some have business intuition.
Some understand user pain.
Some are motivated enough to iterate every day.

They do not need a runtime that makes them feel stupid before they even start.

They need a runtime that lowers the entry barrier without hiding the truth.

EkkoJS gives them a faster path:

The runtime is documented for humans and AI.
The model can access live guidance.
The stack is integrated.
The defaults are stronger.
The feedback loop is shorter.
Token consumption can drop because the model does not need to rediscover or guess everything.
The developer spends more time shaping the product and less time fighting boilerplate.

This is not about replacing engineering judgment.

It is about giving builders a better floor.

Vibe Coding Needs Better Infrastructure

The future of AI-assisted development will not be won by saying:

Never use AI to code.

It will be won by building tools where AI can code responsibly.

That means:

Better runtime guidance.
Better defaults.
Better security boundaries.
Better documentation.
Better error feedback.
Better full-stack integration.
Better primitives for real applications.

EkkoJS is my answer to that.

A runtime that can guide the model.
A framework that can structure the app.
A component suite that can shape the UI.
An ORM that can simplify persistence.
A permission model that can define boundaries.
A JavaScript and TypeScript experience that starts fast.

EkkoJS Is Built for Builders

EkkoJS is free because the goal is bigger than selling access to another tool.

The goal is to lower the entry barrier of coding.
The goal is to make AI-assisted development less fragile.

The goal is to help capable builders move from idea to working software with fewer artificial walls.

If you have motivation, taste, discipline, and the will to iterate, you should not be blocked by boilerplate, tooling fragmentation, or a model guessing APIs from memory.

You should be able to build.
That is why EkkoJS exists.

Closing Thought

Vibe coding is not automatically insecure.
Unguided coding is more dangerous than having ideas.

EkkoJS is built around a different belief:

The best AI coding experience is not a model that pretends to know everything.
It is a runtime that can teach the model exactly what it needs to know.

That is the future EkkoJS is betting on.

Write once.
Resonate everywhere.

Link	Description
EkkoJS	The main website for EkkoJS
Rune	Dedicated documenattion for Rune
Asgard	Dedicated documentation and example for Asgard

EkkoJS, the new challenger

Hello — Thu, 18 Jun 2026 17:24:54 +0000

Somewhere between the third config file and the second build step, I stopped having fun.

It crept up on me slowly. The work I actually wanted to do, writing code that solves a problem, kept getting pushed further and further behind the work of getting ready to write that code. Scaffolding, configuring, wiring tools together, then maintaining all of it. I have been writing JavaScript since 1999, so I had collected a lot of opinions about what was wrong and very little to show for them.

So I built the runtime I always wanted to use. Three years ago I took the decision to start, in 2024 I sealed the name and took the domain, and now, in the middle of 2026, EkkoJS is finally here, at ekkojs.com.

A fresh start

If I am going to build a new runtime, then I am going to start fresh. No dragging the past along just to make a few people feel at home on day one. Every decision below is one I made on purpose, knowing it would cost me some compatibility, because the whole point was to stop paying for the old mistakes.

Bye bye CommonJS

The future is modular, so let's cut the bridge with the past. EkkoJS is, and stays, ESM only. No compromise.

Yes, that alone walks away from the CommonJS world, and from the easy interop everyone else keeps alive. I am fine with that. The two module systems were never meant to live together. CommonJS loads synchronously, ESM loads asynchronously, and that single difference is why every runtime that supports both ends up with a pile of special cases to paper over the seam.

I did not want that pile. One way in, one way out. A static import, top to bottom.

import { readText } from "ekko:fs";        // built-in module, ekko: prefix
import { connect } from "ekko:db/orm";      // built-in, sub-path
import { Button } from "@ekko/asgard";      // a package from the store
import { formatUser } from "./lib/user";    // local file, extensionless

// No require(), no module.exports, no __dirname. There is nothing else to learn.
export function greet(name: string) {
  return `Hello, ${name}`;
}

Imports are always extensionless. Whether the file is .js, .ts, .jsx, .tsx or .mjs, you import it by name and the runtime resolves the rest. The runtime enforces it at build time, so writing the extension is an error. One rule, no exceptions, nothing to argue about in a review.

And when you genuinely need to load something at runtime, dynamic import() is there too, same rules, same resolution.

// load it only when you actually need it
const { runMigration } = await import("./db/migrate");

Bye bye node_modules

Here is the one most people will trip over, so let me be direct. EkkoJS does not have a node_modules. Dependencies do not get copied into your project folder, ever.

When you add a package, it goes into a single local store on your machine, one copy per version, shared by every project that asks for it.

ekko add @ekko/asgard          # resolves, downloads, installs into the store
ekko add @ekko/asgard@1.0.0    # a specific version
ekko add --build some-tool     # a build-only dependency

Your project keeps a short list of what it depends on in ekko.json, and the exact versions are pinned in ekko.lock. That is it. No folder with thousands of nested directories, no copy of the same library sitting in fifteen different projects, no waiting for the disk to finish writing a small country's worth of files before you can start.

The mental model is simple. Your project declares what it needs. The store holds the bytes. The same version is installed once and reused everywhere, instead of being copied so many times the folder grows its own gravity.

TypeScript is a first class citizen

TypeScript is a first class citizen here, treated exactly like JavaScript, with no configuration needed.

There is no tsconfig.json to write, no compiler to install, no build step to wire up before you can run a single line. You point EkkoJS at a .ts file and it runs.

ekko run main.ts
ekko run main        # the extension is optional, same as everywhere else

You can mix .ts and .js in the same project without thinking about it, because imports are extensionless and the runtime resolves the right file for you. Types are there while you write, and they get out of the way when you run.

We never had to configure JavaScript to make it run. With EkkoJS, you do not configure TypeScript either. It just runs.

More than a runtime

A runtime that only runs scripts gets dull fast. What I wanted was a single tool that could build the things I actually build, without dragging in a different stack for each one.

So EkkoJS ships the targets out of the box, all from the same runtime, the same language, and the same store:

Libraries. Write a package, pack it into a single file, share it. The thing you build is the thing other projects depend on.
Web, full stack. React on the front, a real backend behind it, SEO handled. This is Rune, and it gets its own section below.
CLI. Real command line tools, with argument parsing, options and colored output, in a handful of lines.
TUI. Rich terminal applications with panels, layouts and live updates.
Desktop. Native desktop applications, with no Electron and no rebuilding all your native dependencies just to ship a window.

All of this comes from the runtime itself, not from a pile of third party packages glued together and prayed over. One install, and you can reach for any of these the moment you need it.

One file to ship: the .ekl

When a project is ready to leave your machine, you pack it.

ekko pack
# → my-project-1.0.0.any.any.ekl

That single .ekl file is the whole project: your transpiled sources, the native libraries it needs, the assets it reads, and the ekko.json and ekko.lock so it resolves its dependencies exactly the way it did on your disk. Everything is compressed per entry, checksummed with SHA-256, and optionally signed with ECDSA. One file to ship, one file to run, and a dist folder you never have to babysit.

A runnable project starts straight from the archive, with no extraction step:

ekko run --ekl my-app.ekl --allow=all

An .ekl is more than something you publish to a registry. Anything you can run in EkkoJS runs from one just as well, a CLI tool, a server, a full Rune site, all from that single file.

The .ekl is the filesystem

Which leads to the part I find elegant. When an app runs from its .ekl, the archive becomes its filesystem.

Every ekko:fs read resolves against an in-memory virtual filesystem built from everything you packed. Reads look in that VFS first and only fall back to the real disk if the path was not packed. So the app always finds its own bundled assets, wherever you copied the file, and reading its own resources needs no fs permission, because it is reading itself, not the host's disk.

Writes are the mirror image. They always go to the real filesystem, rooted next to the archive, so the app can read its sealed contents and still write where it is allowed to. The bundle stays read-only and honest, and the host stays in control of what gets touched.

A rich standard library

Like any runtime worth using, EkkoJS ships a deep standard library, so you can start building immediately instead of shopping for a dependency every time you need to hash a string or open a socket. Every module lives behind the ekko: prefix, and every one of them answers to the permission system.

Here is the surface, grouped by what you would reach for.

System and I/O

Module	What it gives you
`ekko:fs`	File system access, synchronous and CWD-relative
`ekko:fs/path`	Path building and normalization, cross-platform
`ekko:net`	Raw TCP and UDP sockets and DNS, client and server
`ekko:process`	Spawn child processes, read env, args, signals, exit codes
`ekko:ffi`	Call into native C-ABI libraries directly from JS or TS

Data, text and time

Module	What it gives you
`ekko:crypto`	Hashing, AES and RSA encryption, key derivation, ECDSA signatures, secure random
`ekko:compress`	Compression and decompression, gzip, deflate and brotli
`ekko:datetime`	Dates, durations and timezones with real IANA support
`ekko:image`	Image decoding, encoding, resizing and transformation
`ekko:text/json`	JSON parsing and serialization beyond the built-in `JSON`
`ekko:text/encoding`	Base64, hex and UTF-8 encoders and decoders
`ekko:text/regex`	Regular-expression helpers

Databases

Module	What it gives you
`ekko:db`	Low-level access across SQLite, Postgres, MySQL, SQL Server and Mongo
`ekko:db/orm`	A typed query builder over the same drivers, swap the driver without rewriting your queries

Web and real time

Module	What it gives you
`ekko:web`	HTTP and WebSocket server with security middleware built in
`ekko:web/validate`	Schema validation for bodies, params and queries
`ekko:web/graphql`	A GraphQL server that plugs into `ekko:web`
`ekko:web/realtime`	Real-time channels and rooms over WebSocket

Auth and access control

Module	What it gives you
`ekko:auth`	Sessions, JWT and password hashing
`ekko:auth/rbac`	Role-based access control, roles, permissions and policy checks

Full stack (Rune)

Module	What it gives you
`ekko:rune`	The full-stack framework, `createApp`, pages and middleware
`ekko:rune/router`	SSR-first then client-side routing, `Link` and `useRouter`
`ekko:rune/mimir`	Mimir, the cross-frontier state management
`ekko:rune/seo`	SEO helpers, canonical URLs, sitemap and robots
`ekko:ssr`	The standalone server-side rendering engine
`ekko:ssr/css`	Scoped Sass and CSS modules for server rendering

Application targets

Module	What it gives you
`ekko:app/cli`	CLI framework, command parser, colored output and prompts
`ekko:app/tui`	TUI framework for rich terminal applications
`ekko:app/gui`	GUI framework for native desktop applications

Jobs, logging and testing

Module	What it gives you
`ekko:job/cron`	Cron-style scheduled jobs
`ekko:job/queue`	Background job queues with retries
`ekko:log`	Structured logging with levels and formats
`ekko:test`	The built-in test runner, `describe`, `test`, `expect`, mocks and coverage
`ekko:test/assert`	A standalone assertion library

On top of all of these sits the global Ekko namespace for the runtime itself, with Ekko.spawn, Ekko.parallel and Ekko.Channel for threading, plus Ekko.args and Ekko.env.

Native code, the easy way

Calling into a native library should be boring, so in EkkoJS it is. You point ekko:ffi at a shared library, declare the functions you want with their argument and return types, and call them like any other function.

import { dlopen, types } from "ekko:ffi";

// The C math library has a different name on each OS, so pick it from Ekko.platform.
const MATH = { win32: "msvcrt.dll", darwin: "libSystem.B.dylib" }[Ekko.platform] ?? "libm.so.6";

const libm = dlopen(MATH, {
  sqrt: { args: [types.f64], returns: types.f64 },
  pow:  { args: [types.f64, types.f64], returns: types.f64 },
});

console.log(libm.sqrt(144));   // 12
console.log(libm.pow(2, 10));  // 1024
libm.close();

That is the whole ceremony. The runtime handles the conversions across the boundary, numbers, strings, buffers and pointers, and FFI still answers to the permission system, so a package can call its own bundled binary while anything external stays behind a deliberate, named grant.

And here is where it pays off on the desktop. Anyone who has built a desktop app on the usual stack knows the native rebuild dance, where the moment Node and Electron disagree on an ABI you are recompiling native modules and praying. EkkoJS ships its own native layer and packs the right binary straight into your .ekl, so the desktop app carries the native code it needs and runs. No rebuild step, no version roulette between two runtimes that were never quite in sync.

Testing is part of the deal

If I want everything I need out of the box, then testing has to be in the box too. Fully. So EkkoJS ships a complete test framework and a coverage reporter inside the runtime, with nothing to install and nothing to configure.

The API is the one you already know. describe, test, expect, plus mocks when you need them.

// math.test.ts
import { describe, test, expect } from "ekko:test";

describe("addition", () => {
  test("adds two numbers", () => {
    expect(1 + 1).toBe(2);
  });

  // async tests are awaited for you
  test("resolves a value", async () => {
    expect(await Promise.resolve(42)).toBe(42);
  });
});

Name your files *.test.ts and run them. The runner discovers them on its own, needs no permissions, and exits non-zero when something fails, so it drops straight into CI without ceremony.

ekko test                  # discover and run every *.test.ts
ekko test math.test.ts     # run a single file
ekko test --coverage       # collect a coverage report while you are at it

Coverage is built in the same way. One flag produces an lcov report and an HTML view you can open in a browser, for both JavaScript and TypeScript, with no extra tooling to bolt on.

Security first, deny by default

A program in EkkoJS starts with nothing. No file system, no network, no environment, no process spawning, no crypto, no FFI. The first time the code reaches for a native capability it was not granted, it gets a PermissionError and stops.

You decide what it can touch, with one flag.

ekko run app.ts                          # no grants, native calls throw
ekko run --allow=fs,net,crypto app.ts    # grant whole categories
ekko run --allow=all app.ts              # grant everything, for when you are just hacking

While you are building, --allow=all keeps you out of your own way. When you ship, you grant exactly what the code needs, and you can scope each grant down to a path, a host or a single variable.

ekko run --allow=fs:./data/** app.ts            # the file system, but only under ./data
ekko run --allow=net:api.example.com app.ts     # the network, but only to one host
ekko run --allow=env:DATABASE_URL app.ts        # one environment variable, nothing else

The path checks resolve symlinks before they decide, so a link inside an allowed folder that points somewhere it should not goes nowhere. A ./data/link aimed at /etc/passwd is denied even with fs:./data/**.

You can also write the grants once in ekko.json so you never retype a flag, and the CLI still wins when you need to override:

{
  "permissions": {
    "fs": true,
    "net": true,
    "env": ["DATABASE_URL", "API_KEY"]
  }
}

The doctrine behind it is simple. Developer tools like ekko test and ekko dev run with full trust, because that is your machine and your code. Shipped code, run with ekko run, gets the smallest set of capabilities that lets it do its job. The runtime makes the safe path the easy one, so locking things down is the default rather than the heroic afterthought.

Rune, the full stack framework

We have all lived this one. You build a slick client-side app, everything is fast and smooth, and then someone asks the obvious question: how does Google see it? So you bolt on server-side rendering, and suddenly every navigation is a round trip to the server, and the snappy app you were proud of feels like it is wading through mud. You traded performance for SEO, and nobody is happy.

Or the other classic. The app is gorgeous and client-side first, and then a user presses F5 halfway through a flow and the whole thing forgets who it is. Empty screen, lost context, back to the start. One tap of the refresh key and your app has amnesia.

Rune is my answer to both. You can see it at rune.ekkojs.com.

The philosophy fits in one line: server-rendered on the first load, fully client side after. The first paint comes from the server, so any URL you land on is real and indexable, which keeps SEO happy. From there you are a single-page app, navigation stays on the client, and nothing does a useless round trip just to redraw a page. You get the SEO without paying for it in performance.

A page is a React component, plus an optional ssr() that runs on the server for that first load and feeds the metadata.

// pages/index.tsx
// ssr() runs on the server, on first load only, and sets the page metadata,
// so the URL is fully indexable before any JavaScript runs.
export function ssr() {
  return { title: "Home, EkkoJS", description: "Server-rendered, then client side." };
}

// After that first paint, this is a normal React app, navigation stays on the client.
export default function Home() {
  return <h1>Hello from Rune</h1>;
}

And the refresh problem? Rune ships Mimir, a state library that lives across the frontier. The same state flows out of the server render, into the client, and keeps going there, surviving a refresh. So F5 stops being the button that wipes your app's memory.

That is the whole idea. SEO without sacrificing performance, and a client-side app that does not panic the moment someone reaches for refresh.

Asgard, the component suite

A framework is more pleasant when you are not drawing every button from scratch, so EkkoJS has an official component suite, Asgard.

It is a batteries-included React component library made for Rune apps. Buttons, text fields, selects and switches, date and color pickers, data tables, tree views, alerts, toasts, tooltips and drawers, a real layout engine, and an IDE-grade docking system for the kind of app that has panels you drag and split. The components render on the server with Rune and hydrate cleanly on the client, so they fit the SSR-first model without a fight.

You add it like any other package and wrap your app in a theme.

import { ThemeProvider, Button } from "@ekko/asgard";
import { themes } from "@ekko/asgard/theme";

export default function App() {
  return (
    <ThemeProvider theme={themes.nord}>
      <Button variant="filled">Get started</Button>
    </ThemeProvider>
  );
}

Theming runs deep. There are 27 built-in palettes, Nord, Dracula, Tokyo Night, Catppuccin and more, or you bring your own, and a bridge that re-themes your own SCSS the moment you switch. Keyboard navigation, focus management and ARIA roles come built in, so accessibility is the starting point rather than a later cleanup.

Bifrost, the registry

A package format is only half the story. The other half is somewhere to send it, so EkkoJS has its own registry, Bifrost.

The flow is the one you would expect. You pack your project into a single .ekl, you log in once, and you publish.

ekko login                  # stores a token in ~/.ekko/config.json
ekko publish --dry-run      # see exactly what would be uploaded, no surprises
ekko publish                # pack and push to Bifrost

On the other side, installing it is the same one command as any other dependency, and it lands in the shared store rather than in a folder inside the project.

ekko add @me/app

Every package is versioned, and if you have a signing key it is signed with ECDSA on the way up, so what you publish is what people install, provably. The same crypto runs in the CLI and in the registry, one implementation on both ends, so there is no seam where a signature means one thing here and another thing there.

Visibility is yours to set in ekko.json, public or private, and the registry checks quota and validity before a single byte is uploaded. You always know what is going out before it goes.

Zero-shot runtime coding

I can already hear the objection. "A brand new runtime in 2026? My AI assistant has never heard of it. I will be flying blind, autocompleting into the void, fighting a model that keeps trying to write me a package.json."

It is a fair fear. It is also the first thing I solved.

The entire documentation ships inside the binary. ekko doc browses it right in your terminal, across three topics: the runtime, the Asgard components, and the Rune framework. You list a topic's pages, then open any one of them.

ekko doc js                 # list the runtime's pages, each one numbered
ekko doc js 007             # open a page (here, Permissions)
ekko doc js 007 --llm       # the same page as raw markdown, written for a machine

That last flag is the one that matters for tooling. --llm prints the page as clean markdown, so an AI assistant can list the pages and pull whichever ones it needs, on demand, as plain text.

Drop the flag and you get the same page rendered for a human, formatted right there in the terminal, with headings, tables and syntax-highlighted code. And if you would rather read and explore than type page numbers, -i opens a full interactive browser, a split-pane TUI you navigate with the keyboard.

ekko doc js 007             # human-friendly, rendered in the terminal
ekko doc js -i              # full interactive TUI, browse the whole topic

No fine-tuning, no prior training, no waiting for the next model to maybe learn about EkkoJS. Any capable AI can read the live, exact documentation for the version you are actually running, and code against it from a standing start. Point your assistant at ekko doc and it learns the runtime as well as the docs do, today, not whenever a training cut-off catches up.

So the runtime being new stops being a problem and starts being the point. It documents itself, for you and for the machine sitting next to you, and the guidance is always current because it comes from the same binary that runs your code.

Where it stands

Let me be honest about the stage we are at. EkkoJS is a technology preview until October. Breaking changes are already on the roadmap, on purpose, because I would rather get the design right in the open than freeze the wrong decisions early.

So here is my ask. Test it. Build something real with it. Push on it and tell me where it hurts. But please, do not ship it to production yet. That day is coming, and this is not it.

Stay tuned. A lot of articles and tutorials are on the way, and I will be walking through every part of this in more depth. This was the overview. The rest is coming.

Try it

Installing is a single command, and that command is the whole toolchain. It runs your code, manages your packages, runs your tests, and builds your projects.

# macOS / Linux
curl -fsSL https://ekkojs.com/install.sh | sh

# Windows (PowerShell)
irm https://ekkojs.com/install.ps1 | iex

Then write your first line.

// main.ts
console.log("Hello, EkkoJS!");

ekko run main.ts

That is it. No tsconfig, no bundler, no folder full of dependencies. If you have read this far, the best thing you can do is install it, build something small, and tell me what you think. EkkoJS is born from the Norwegian word for echo, so write once, and let it resonate.

Enjoy using it.

Francois, creator of EkkoJS.