Note to self: never get stuck with a framework again

or the long road in and out of Meteor

We have to face it: JavaScript fatigue is here to stay.

This problem isn’t just related to web development, it’s reflective of a deeper issue. This is best described by Kevin Kelly in his awesome book The Inevitable:

In this era of “becoming,” everyone becomes a newbie. Worse, we will be newbies forever. That should keep us humble.
That bears repeating. All of us — every one of us — will be endless newbies in the future simply trying to keep up.
Endless Newbie is the new default for everyone, no matter your age or experience.
Now we know: We are, and will remain, perpetual newbies.

Frameworks vs. boilerplates

What does this mean for us (web) developers? That in the coming years we will be doing a lot of the following:

• Evaluating, comparing and choosing technologies
• Gluing technologies together
• Replacing technologies

Please note how all these are meta-concerns. Already now, apart from our project’s core competency, a lot of our effort isn’t about solving problems, but about managing solutions.

That’s why we need environments like node that support modules/libraries and package managers. We don’t even have to talk about that. That now is a given. Our problems are a higher level: given the abundance of choices, what do we pick and how do we glue it all together, how do we keep up?

There are two types of tools that help us with these tasks: frameworks and boilerplates. Both allow you to get started with a working project, all the important bits glued together. In particular, if these tools are opinionated, they relieve us from a lot of the aforementioned work of researching, choosing and piecing together.

Yet they do so in a completely different way: frameworks hide the glue between the technologies (a.k.a they are magic), and boilerplates don’t. Only with a boilerplate you own the project, that is no matter how opinionated the initial choice was, there is no buy in, you aren’t stuck with any of it, you can always swap any of its pieces with something better.

In and out (?) of Meteor

Over a year ago I started my project with a web development framework: Meteor. Meteor has some really awesome innovations going on. And some serious magic. Even though Meteor is built on top of node, you didn’t have to know anything about node to create a full-fledged web application (I didn’t). But about half a year ago, to rely on the broader community, they started supporting npm packages (which is a good thing), and the whole abstraction layer on top of node has been gradually breaking down.

Since then the plan has been to transition Meteor to NPM, but progress has been very slow: half a year later AFAIK no packages have been transitioned. This latency is in part due to meteor’s core team focusing heavily on the GraphQL-technology Apollo, which, ironically, is a set of pure NPM libraries, without any tight meteor integration.

But another reason is the entanglement of the technologies within the meteor project. The first package to be transitioned is likely going to be Tracker, Meteor’s reactive library (we might see a breakthrough soon). This had to wait for the separation of Blaze, their in-house UI library. If this seems unrelated it’s because it shouldn’t be, and is a further point against the monolithic architecture suggested by a framework.

Because of the above developments, I’ve been trying to rely less and less on meteor packages and functionalities, but I’m not there yet. I’m still missing:

• A good accounts module (I’m not just talking about authentication) that doesn’t rely on a specific UI.
• A good reactive, isomorphic data layer. You know, the kind of technology that allows you to forget about the server, even when it comes to writing data and reacting to changes in the database.

This speaks both to the skills of the meteor folks, whose innovations have been hard to replicate, as to the flaws of the framework model. Had they developed these libraries for the general node community from the start, all of this wouldn’t have been an issue. Now me and many others can’t just move on and keep the good pieces. I either have to accept all of their stack or reject the meteor brand completely — which is kind of heartbreaking.

The temptation of magic

Meanwhile, new, shiny, magic, mind-blowing frameworks are popping up. See for example next.js. And the initial temptation is to ask: “will it work for my use case?”. Will it work for technology X?

But then, thinking about it, no. No. I won’t go there. That piece of innovation, hidden behind the next command, could have gone into a few libraries, a NPM package I would be able to replace in a year or two, when super-company X comes out with super-approach Y to rule them all.

I’m going to invest in plain node, and in a good project-starting boilerplate. No boilerplate I know of has everything set up ideally yet. Who knows, maybe that’s what Meteor will be in the future, after its full transition to npm: a very good boilerplate and some enlightened libraries and tools. For now I’m going to keep a closer eye on mern and this effort to replicate meteor accounts as a node library.

Meanwhile, I’ll stick to my half-meteor, half-node project, because hey, it works, and the show must go on.

Update: I believe I’ve been unfair to the next.js project, see an update here.

Update 2: I created a node.js (next.js) starter library that features a full accounts system, called Staart. Check it out live here!