Why Mastro?
Most JavaScript frameworks were designed to solve problems that no longer exist.
- SPAs have peaked. Browsers now have MPA view transistions.
- Native CSS can now replace much of SCSS. Component-scoping works natively.
- Node.js supports TypeScript type stripping and file watching out of the box.
- With ES modules in all browsers, bundling shouldn’t be the default anymore.
Instead of starting with a client-side framework like React, and being forced to add more complex tooling with every release, Mastro was designed from the ground up server-first. Its core design principle is that everything is a route.
Mastro is for people who…
care about their users
…and value accessible websites that load fast – even on low-end phones and slow networks.
care about the web
…and understand it as its own medium.
- A webpage is not a printed page with fixed dimensions.
- Mastro is designed to work with the grain of the web. Write semantic HTML, and progressively enhance it with beautiful CSS and interactive JavaScript.
- Mastro is primarily designed for content-driven websites, and not for apps that download megabytes of client-side code and reimplement basic browser functionality.
care about simple and pragmatic technology
- Instead of towers of leaky abstractions, Mastro gives you direct access to the underlying platform: the browser and your JavaScript runtime.
- No magic: simple things should be simple, and complex things possible.
- Mastro grows with you: it is a beginner-friendly static site generator, but can morph into an unopinionated full-stack framework running database-driven REST APIs and rich client-side interactivity.
- Explicit separation of server and client-side. Code and secrets that were intended to stay on the server shouldn’t accidentally end up in the client bundle.
- Everything is a route – Mastro provides a uniform interface for all content types: HTML, JSON, XML, binary, whatever. Instead of being abstracted away, the full power of the HTTP protocol is at your disposal through the standard Request/Response API.
care about their dependencies
- Mastro will never take on VC-money and there will be no eventual enshittification.
- Mastro’s implementation is low-maintenance and so small that you can read it in an hour or two. Should you ever outgrow it, you can simply fork it and adjust things to your needs.
- Mastro is modular. If you prefer e.g. another templating engine, use that instead.
- Mastro has a tiny API-surface, which is already very stable. Once we hit v1.0, the public API will get frozen, so that projects that depend on Mastro aren’t stuck on an update-treadmill.
- Additional packages in the
@mastronamespace may have higher rates of change, and we invite the community to create additional packages on top of the standard Request/Response-API.
Why Mastro instead of…
Next.js
Next.js creates bloated SPAs: every feature you add increases the amount of JS your users have to download. Running your code on the server, then running it again on the client, also adds a lot of complexity.
Astro
Astro was a big inspiration for Mastro (the name originated from “minimal Astro”). But Astro currently has 246 dependencies weighing 87 MB. Astro is also heavily coupled to its bundler, which makes some simple things surprisingly complex.
11ty
Eleventy has a lot of options around static site generation, but it doesn’t run as a server. It is not TypeScript-first, and currently still has 116 dependencies weighing 14 MB.
Hono
Hono is almost as minimal as Mastro. But it is more backend focused (e.g. it doesn’t come with a file-based router).