Staart — a starter library for node.js projects with user accounts

Over the last months I’ve been developing an extensible user accounts system for node called Ooth. It builds on Passport.js strategies for authentication, and handles the persistence and management of user identities. It also features some helper libraries for react and next.js.

What was missing was the UI side of it. Ooth has been designed to make the development of an accounts UI quite easy, but people needed at least a starting example. This is where Staart comes in. Staart is a library of simple react components that can help you getting started very quickly with a project that has an accounts UI. Think about things like register/login pages, forgot-password, reset-password, verify-email and so on.

The scope of this library is to get started quickly with a project. Over time you will probably implement your own accounts UI, possibly while still using Ooth in the background. Having these components as a base will make it easy for you to switch.

Check out an example staart project here: http://staart.nmr.io/.

The GitHub repo is here: https://github.com/nmaro/staart.

The Staart Philosophy

More than anything else, Staart is a vision. Right now, Staart and Ooth feature exactly the requirements I needed for my personal projects (Mongo, React, Bootstrap, next.js). But none of these aspects is integral part of the Staart philosophy. The project will have to grow and generalize from here, hopefully with a community of people who share the same philosophy. Allow me to elaborate.

The fundamental problem

The fundamental problem is what led to the “JavaScript fatigue” cries: in a world of ever-accelerating innovation, staying up-to-date, evaluating, picking technologies and gluing them together is going to take up more and more of our time.

Frameworks aren’t the solution

The year of JavaScript fatigue hit me full-on while I was in the midst of a Meteor project. I started not liking certain architectural decisions they made and tried to move away from it. This proved impossible without giving away the parts I liked. That’s when I said “never again a framework” and started looking for another solution.

Maybe I wasn’t completely fair to all frameworks out there. I now would say that a framework is evil to the degree that it couples technological decisions without allowing you to decouple them. When technologies are coupled you are forced in an all-or-nothing decision, which destroys agility and the possibility of incremental improvements.

In my opinion, anyway, every framework has a certain degree of coupling, otherwise you would just call it a library.

Boilerplates aren’t the solution either

Let’s face it: over time, every single web engineer on the planet is going to create their own boilerplate and put it on GitHub. And that’s OK. What’s not OK is to believe they are going to be maintaining them. Or using them for more than a few projects, before they all start diverging.

And that’s the problem with boilerplates. You cloned your boilerplate once, and after the first commit to the new code base it’s already obsolete. A few weeks later, the optimizations and abstractions you should have put into the boilerplate are scattered across your projects, where you happened to use them.

The only way boilerplates can work is by hiding their design decisions as much and as long as possible from you. See for example create-react-app, an interesting hybrid: at the beginning it’s a framework that keeps a bunch of coupled technical decisions from you, and then when you “eject” (and you hope you never will need to) you get a boilerplate, meaning you are on your own.

What about code generators?

From what I see, code generators are bad for the same reason boilerplates are. They help you get started, and then you are on your own. And code generators get maintained even less, because who feels like writing code that generates code additionally to writing the code?

So, what is the solution?

Libraries, Libraries, Libraries.

This might sound trivial, but yes, libraries are the solution. Simple, tiny, pretty little libraries, that do one thing and do it well. And with one thing I mean they either:

1. Do a thing, or
2. Glue two other things together.

That’s it. That’s all we need. In an ideal world, a boilerplate would just be:

import website from 'website-of-a-certain-kind'
const config = {} // Fill in your business logic
website(config);

Then one day, you decide that you want to change some backend logic beyond what you can do via configuration. You check out the code of the ‘website-of-a-certain-kind’ package:

import backend from 'backend-of-a-certain-kind'
import frontend from 'frontend-of-a-certain-kind'
export (config) => { backend(config); frontend(config); }

You copy/paste the code into your project and import backend-of-another-kind instead.

Of course I’m being hyperbolic, but you see what I mean: good libraries have the best of both worlds:

1. They take difficult decisions for you
2. You aren’t left on your own — as they improve, your projects that rely on them improve
3. If they couple multiple difficult decisions, they do so by using other libraries that you can easily use directly and replace in case you ever need to do so

Back to Staart

While Staart now is an early prototype that takes some strong decisions (Bootstrap, Next.js…), I encourage you to try it out. If you don’t like a part of it, I’ll make an effort to split these decisions into multiple libraries that you can pick and choose to get exactly what you need, with minimal boilerplate.

Maybe it won’t be Staart that provides the perfect way to make websites. But one thing is sure: you won’t be stuck for months with it if you decide to move on, and there might be a chance you’ll keep some parts for years, because, hey, they do one thing and do it well.

Again, check out an example staart project here: http://staart.nmr.io/.

And the GitHub repo is here: https://github.com/nmaro/staart.

Follow me

My aim is to design a system that allows you to realize a simple (business) idea within day. Over months and years these are the technological decisions I have taken:

1. node.js server — because of code sharing between back- and frontend
2. react.js components — because it’s a functional way to define a virtual representation of your UI
3. next.js — because of the genius idea of starting the component lifecycle on the server and continuing it on the client, thus abstracting away most of the client/server distinction when designing your UI (only possible thanks to points 1 and 2) — also read why I don’t consider next.js as a framework
4. Ooth — because it’s the only extensible user accounts system for node
5. GraphQL — because it is a typed data layer that decouples front- and backend on the data side
6. Staart — because it puts all these things together, and it’s not a framework and not a boilerplate

If you want to read more web engineering articles, subscribe to my publication The Ideal System. You can also support my open source work on Patreon.