Boomla is a web development platform. Below you can find its most important features.

Boomla focuses on two audiences: developers and non-developers. It is ready for developers, not yet for non-developers. The main incomplete feature being the nocode editor (coming soon).

This overview is currently written for technical people.

Boomla is statically typed. It is necessary to:

Boomla has native storage integration. Storing persistent values is just like storing in-memory values.

The integrated storage doubles as both a filesystem and database. It supports large objects and hierachies as usual in a filesystem, while also supporting structured data and ACID transactions as typical in databases. We call it the Boomla Filesystem.

Boomla is a server-side rendered, full-stack programming language. It eliminates the distinction between client and server code. For example, if you add an onClick handler to a button in your rendering logic, the callback will fire on the server, not the client.

Boomla views are reactive. State is stored on the Boomla Filesystem. During rendering, filesystem access is recorded and automatically watched. Clients subscribe to reactive updates via websocket.

The Boomla language has native support for xml expressions similar to JSX in React. The programming model is much simpler than that of React, it feels more like using PHP.

In-memory values have value semantics. This means that variables are independent: writing one variable won't affect any other.

Stored values have reference semantics.

Similar to how programming languages support composition in code, Boomla supports composition on the filesystem. Instead of moving around code, you can move around files.

This is an entirely new approach to organizing your codebase.

Files may store self-contained, stateful components. Making a copy of such a component will result in both having independent storage. This massively reduces the overhead of developing stateful components where a traditional approach would include modifying the database schema.

Boomla has a built-in web design language called Turbo CSS.

Installed packages do not just reference their dependencies, they contain them. This helps avoiding dependency conflicts.

Boomla has integrated version control. Every change to the filesystem will create a new snapshot. You have undo/redo available. You can create snapshots and branches. Branches are accessible simultaneously under different sub-domains.

Boomla has deduplicated storage. Storing the same data 2x (or 1000x) will only use storage space 1x. That's particularly important as every change creates a new version of the project. It's also crucial for creating development branches, and installing packages with lots of shared, transitive dependencies.

Database latency is the typical reason why web apps tend to be slow. Due to the tight integration between runtime and storage, Boomla has zero-latency data access. This makes Boomla really fast.

In a traditional setup, the application server and the database server are separate services. As traffic grows, more application servers are added, which talk to the same database server (or a few). This way, every single database query has to wait for its turn. If your application server makes 100 queries, this means queing 100 times. With moderate-to-high server load, this may easily be 10ms per query, or 1s for 100 queries. And that's not even doing anything. Just waiting.

In Boomla, each application server works with its own local database snapshot. This means that requests only queue 1x.