Imba: a full-stack language that compiles to JavaScript and owns the DOM

The problem Imba targets: markup, logic and styles living in separate files

Most web stacks split a single screen across a component file, a stylesheet and sometimes a template. Imba folds all three into one file by making DOM nodes a language construct. The README describes it as "a friendly full-stack programming language for the web that compiles to performant JavaScript" with "language-level support for defining, extending, subclassing, instantiating and rendering DOM nodes."

The audience is narrow and identifiable. The README states that Imba powers both the frontend and the backend of Scrimba.com, replacing Vue or React on the client and running on Node with npm packages on the server. So the intended user is a team building a Node-backed web application from scratch, comfortable with a syntax that is neither JavaScript nor JSX, and willing to accept early-stage tooling. If you are adding one widget to an existing React application, the language boundary costs more than it returns.

How Imba compiles: tags, scoped CSS and esbuild in one pipeline

The mechanism is a compiler plus a bundler. You write .imba files; the imba command compiles and bundles them. The README says the built-in bundler is based on esbuild and that imports of stylesheets, images, TypeScript, HTML and workers need no configuration. It also claims bundling happens on demand with no meaningful difference between production and development mode, and that the command provides automatic reloading of both server and client.

Three constructs carry most of the weight. tag declares a component, and the README's login-form example subclasses form with tag login-form < form. css blocks can be global, file-scoped, component-scoped or inline, with modifiers such as @hover, @lg, @landscape and @dark, and Tailwind-inspired shorthands like pos:relative d:block bg:blue5. Mounting is explicit: imba.mount <login-form[pos:abs d:grid ja:center]>. On the server the same language drives Express handlers, and the README shows res.send html.body returning imported HTML.

The trade-off is that this is a compiler-owned pipeline. There is no documented path in the README for dropping Imba into an existing Webpack or Vite configuration; the project ships a separate vite-plugin-imba package, but the README does not explain when to choose it over the imba command.

Installing Imba and mounting a first component

The README points to the playground at imba.io/try for a browser trial and to the official guide at imba.io for setup. It does not print an npm install command, so the package name is the one shown on the npm badge and in the repository: imba. A minimal project therefore starts with an npm init and the imba package, then an .imba entry file.

npm init -y
npm install imba

After that, create an app.imba file. The README's login-form example is the shortest complete component it gives: a tag that subclasses form, two bound inputs and a submit handler, followed by a mount call.

tag login-form < form
	<self @submit.prevent=api.login(name,secret)>
		<input.username type='text' bind=name>
		<input.password type='password' bind=secret>
		<button> "Login as {name}"

imba.mount <login-form>

The README states that running your app with the imba command bundles and compiles Imba alongside TypeScript, CSS and other file types, with automatic reloading. What you should see is the form rendered on the page, the button label updating as you type into the username field because of bind=name, and the browser reloading when you save the file. The README does not document the exact dev-server flags or the default port, so check the guide before scripting anything around it.

Where Imba is the wrong tool: tooling maturity and an untyped escape hatch

The README is direct about its weakest area. Under typing and tooling it says the tooling is implemented as a TypeScript server plugin, gives intellisense, diagnostics and cross-file refactorings that also work with js/ts files, and then states: "Like the language, the tooling is still in alpha, but improving every day." That sentence should drive the adoption decision more than any syntax sample.

A second limitation is the release cadence visible in the repository. The most recent published tags are [email protected] on 2022-10-24, [email protected] on 2022-10-19 and v0.9.1 on 2022-10-13. The repository itself was last pushed on 2026-09-16, so work continues, but the tagged releases are old relative to that push. Anyone pinning a version needs to check what their package manager actually resolves rather than assuming a recent tag exists.

Finally, Imba is a poor fit when interoperability is the main requirement. The README describes importing TypeScript and JS/TS files in the same project, but it does not describe rendering Imba components inside a React tree or the reverse. Treat the language boundary as a one-way door for the parts of the app you convert.

Imba compared with Svelte and Vue single-file components

The nearest comparison is Svelte. Both compile components ahead of time instead of shipping a runtime that diffs a virtual DOM, and both let you keep markup, logic and styles in one file. The difference in approach is where the language boundary sits. Svelte keeps JavaScript as the scripting language and adds template syntax on top; Imba invents the scripting language too, so loops, conditionals, imports and Express handlers are written in Imba. That buys the compactness visible in the README's examples, where a tag, its scoped css and its mount call fit in a handful of lines, but it costs you the ability to paste a JavaScript snippet into a component unchanged.

Vue single-file components land on the other side again: template, script and style are separate blocks in one file, and the script block is ordinary JavaScript or TypeScript. If your team's existing knowledge is JavaScript and you mainly want co-location, Vue or Svelte gives you that without a new grammar. Imba is the choice when you want the grammar itself to be shorter and you accept that editor support is alpha.

Maintenance, releases and the MIT licence

Maintenance signals are mixed and worth reading carefully. The repository is not archived, and its last push was on 2026-09-16. The release list, however, stops at [email protected] on 2022-10-24. The monorepo root package.json is private and declares workspaces for packages/imba-language-core, packages/imba-language-server, packages/imba-typescript-plugin, packages/vscode-imba-next and packages/create-imba, with a release script that runs lerna publish. So the publishing machinery exists, but the visible tags do not show recent use of it.

Upgrade cost is tied to the compiler. Because Imba owns the build, a compiler change can affect tags, css scoping and imports at once; there is no documented rollback procedure in the README, so keep the compiler version pinned and read the release notes before moving.

The licence is MIT, per the LICENSE file and the npm badge, with copyright held by Sindre Aarsaether from 2015 to the present. MIT is permissive and places few obligations on how you ship compiled output, but this is a description of the licence text, not legal advice; have your own counsel review anything that matters to your organisation.

Editorial conclusion

Adopt Imba if you are starting a new Node-backed web app, your team accepts a small language with alpha-grade tooling, and you want tags, scoped CSS and a bundler in one command. Do not adopt it if you need a typed, stable editor experience today, or if you must keep an existing React or Vue codebase unchanged. Before committing, run the imba dev server on one real route, check that your editor loads the TypeScript plugin from packages/imba-typescript-plugin, and confirm which release tag your package manager resolves, since the newest published tags in the repository are [email protected] from 2022-10-24.

Frequently asked questions

Official sources

1. imba/imba on GitHub
2. License: MIT
3. Project website
4. README
5. Releases