The Independent Developer Ecosystem

See what I did there?

I called it an “ecosystem”.

That’s so we don’t have to justify to the world why it needs yet another Javascript Framework.

Okay, in reality, it’s more than an application framework.

Aaand, I should still provide some justification for the project.

Mission Statement (short version)

FrontierJS seeks to provide the best developer experience for the privacy-focused, FOSS-oriented, self-starting soloprenuer.

FrontierJS will be the go-to standard for those brave solo JS devs looking for best practices and a consistent interface throughout all areas of work. Full statement here…

You in?

Look below, and tell me if this is already tackled by someone else. If so, let me know, maybe we can just use their stuff.

The Fronts

A Front is a space that we as developers have to spend time in. Sometimes we traverse them for hours when - with the right tools - could have been minutes. The most common Fronts we deal with are your OS, terminal, browser, and IDE.

Am I missing any major ones?

Let me know.

Our Tools

Direction

Building these tools for these fronts to maximize developer velocity is the goal of FrontierJS.

So, while an application framework (see below) helps accomplish that goal, it’s not the end of it.

Two big fronts to support are the browser and the terminal. These will be discussed more later.

The Application Framework

At the heart of it, any frontend application is built on top of these 3 key players:

The Builder (Vite)
The Interfacer (Svelte)
The Designer (UnoCSS)

For several scenarios, we could stop here and via a few configs and plugins

build these frontends:

Single Page Application (SPA)
Static Site
Browser Extensions
Embeddable Widgets
Mobile
Desktop

However, if we need a backend, we call on this guy:

The Server (FeathersJS)

And naturally, we might store stuff and want to interact with our data.

For that, we pull in:

The Inquirer (Prisma)

When things get this big, sometimes you end up working with 3rd-party tools. We integrate with the outside world via The Integrator: n8n.

But now, things might get outside of the static hosting world.

We can package up our projects with Docker and manage it all easily with:

The Manager (Caprover)

In the end, we might end up with a structure much like this one below:

What’s Cool About This

What’s really cool about this is the ability to work on multiple projects without losing flow. You can switch between a web app or browser extension or desktop app and infrastructure and dev flow will be closely the same.

Digging Deeper

Chain of Responsibility with data flow

Once you understand this, you simply hook into the chain and implement your code at the appropriate point.

What could a big Frontier project look like?

Click to find out!

Example of a frontend / backend with embeddable widgets

└── My Frontier Project
  ├── frontier.config.js
  ├── api
  │   ├── config
  │   ├── deploy
  │   ├── dist
  │   ├── public
  │   ├── src
  │   │   ├── core
  │   │   ├── middleware
  │   │   ├── models
  │   │   └── services
  │   └── test
  ├── db
  │   ├── backups
  │   └── prisma
  │       └── migrations
  ├── embeds
  │   ├── deploy
  │   ├── dist
  │   ├── src
  │   └── test
  ├── tests
  ├── web
  │   ├── config
  │   ├── deploy
  │   ├── dist
  │   ├── public
  │   ├── src
  │   │   ├── components
  │   │   ├── core
  │   │   ├── layouts
  │   │   ├── routes
  │   │   └── resources
  │   └── test
  └── wiki

Notice the consistency of some folders between all sub-projects:

├── config
├── deploy
├── dist
├── public
├── src
│   ├── core
└── test

Look at them in a different order and notice a nice development flow:

├── config (configure you're settings)
├── src (develop your project)
├── public (include an static assets)
├── test (test your code)
├── dist (build and get ready for distribution)
└── deploy (everything related to shipping the app)

Some Key Concepts

Everything has a Context, so we expose that and use it to our advantage
Hooks are good, but they’re GREAT in context. We use conventions of before and after a lot.

What else is out there and how does Frontier compare?

Frontier falls into the latest “trendy” stuff out there called “Fullstack JAMstack”.

	Frontier	Redwood	Blitz	Bison
Routing	Routify	Redwood Router	Next.js	Next.js
Frontend	Svelte	React	Next	Next
Not-an-ORM	Prisma	Prisma	Prisma	Prisma
Code Generation	Frontier CLI	Redwood CLI	Blitz CLI	Hygen
Styling	UnoCSS	Tailwind	Import CSS	Chakra UI
Forms	Frontier	React Hook Form	Vanilla JS/TS	React Hook Form
Testing	Jest / Vitest	Jest	Jest, RTL	Jest, RTL, Cypress
Deploy	Cloudflare / Caprover	Netlify	Vercel	Vercel
Backend	FeathersJS	N/A	N/A	N/A

Some others of note

Remix (React)
Gridsome (Vue)

You can research more at fsjam.org.

Status you ask?

Everything is very alpha…

If you are interested in being a part of it, check out the discord:

Sounds like a lot of work?

Yes, it is. The 2 mitigating factors to this are:

Rigid scope (only a specific toolset/tech stack can be supported)
Compounding interest (of best practices)

I’ll explain that more later, out on the frontier.

Frequently Asked Questions

We use Svelte, so why don’t we use SvelteKit?

SvelteKit (while awesome in it’s own right) is a framework that solves a specific goal, and is not generic enough for our purposes.

We are using Svelte for the dynamic interaction layer. If we need routing, we currently use Routify.

The Frontier Application seems a lot like RedwoodJS in ideas, why not use it instead?

There are a lot of similarities in ideas, however:

They are graphql focused, we are REST.
We have a Svelte-first mentality instead of React.
Philosophies and scope are different.
They are building a lot from scratch which they need to maintain, Frontier is more gluing core functionality together and only building out what is needed to adhere to the overarching principles above.