Nitro core principles

[pi0]

As we are expanding the community, I thought to write down some of the core concepts behind Nitro (many of which are shared with unjs).

Note

Please assume these notes are an unstructured draft from my random thoughts. Eventually, we need to tidy up, and document these concepts in a better place, but it's better to start writing something than nothing!

Agnostic at all costs

Nitro’s core concept is that it is designed to be agnostic in terms of choices. Not only at the beginning when users are getting started, but at any point, they should be able to choose or change their previous decisions with no pain.

We’ve built abstraction layers like unjs/unstorage, unjs/crossws, unjs/db0, and unjs/h3, which 1) do not favor any platform and 2) offer freedom of choice at any time. Building these abstraction layers wasn’t easy. We spent months on R&D to create solutions that are abstract and extendable to new options.

Nitro does not highlight or favor any vendor but is committed to supporting as many deployment solutions with same DX.

Deployment via presets only

Nitro officially supports deployment providers via built-in presets only. Presets can be as simple as a metadata file extending another with no changes to functionality, but they allow forward compatibility of Nitro deployments and are an essential part of the support process.

We do not embrace custom (vendor) CLIs and boilerplates for this, as they lead to vendor lock-in and outdated setup. Nitro’s (or wrapper frameworks like Nuxt’s) CLI is acceptable.

Hackable, but we won’t encourage it

Abstractions can sometimes lead to limited possibilities, and what’s the point of freedom if people can’t do what they want?

Today, Nitro has dozens of customization options and a programmatic API that allow users to modify any aspect of it. If something isn’t customizable, it’s an area for improvement.

However, hacking Nitro and using it in ways it wasn’t intended can be dangerous for end users and lead to a fragile ecosystem. It could make any single decision or change in Nitro almost impossible (to not break such usages), and we don’t want that.

To protect (end) users and the ecosystem, we never officially encourage using advanced internal APIs or using Nitro in unintended ways. This power should be given only to end users which full acknowledgment of what they are doing, not to intermediate frameworks or vendors.

Nitro is not here to compete but to benefit everyone

Nitro is a meta toolkit for building agnostic servers with JavaScript. Our mission is to provide a modern experience for building full-stack server applications. Instead of competing with X, we should focus on achieving the best X+Nitro integration.

Nitro is not perfect, of course, and there’s plenty of room to improve its flexibility and integration compatibility.

Nitro is not XYZ

Nitro maintains its own roadmap and core values that aren’t always directly comparable to any other project.

Features are not implemented in Nitro for feature parity only but rather based on actual merits and how they align with Nitro’s core values (and the ecosystem + users).

Sometimes it takes longer to also implement things in Nitro, considering we have to think about wider and longer term support for them.

Embrace standards (when available)

Javascript (as a whole) is far from a point that everyone agrees one one thing. However there are standard workgroups that are working hard to unify the web.

We embrace web standards, workgroups such as WinterCG and popular runtimes such as Node.js, Deno and Bun convention and standards as soon as they are widely accepted across ecosystem and try not to create double standards.

Conventions in case of lacking standard (like crossws) and in case of lack of a standard with best DX (like ofetch) are needed but we try to keep these kind of conventions as limited as possible and planning to reduce depending on opinionated conventions (like auto-imports)

...Nitro should be inclusive

While we have all these strict standards, I want for community to be included and heard. Therefore why we are expanding the community.

[oscarcao]

This looks like principles and not values.