The Renaissance of Meteor.js

I first used Meteor to ship products when it was quite new, nearly 10 years ago. It was groundbreaking back then: fullstack javascript development, soft realtime data layer by default, single-page-application focus that could directly produce android-/iOs-apps as a byproduct. It empowered developers (like me) to ship real, working products within minutes. Even things like user accounts and all that ceremony was directly built-in.

The downsides back then

While I used the framework with great success in the past, not everything was perfect, far from it.

• server-side-rendering (SSR) was based on spinning up a PhantomJS browser process, which is not only fragile but also very heavy on resource usage
• Coffeescript was all the rage (I still love the syntax/elegance of writing it, but reading code from someone else is quite a pain at times)
• The template engine was Blaze/Spacebars and... has not aged very well and probably looks very quirky to current frontend developers
• MongoDB had it's fair share of security issues and other problems in the past
• Meteor itself has some pitfalls when it comes to scalability
• The company behind meteor decided to pivot into developing Apollo
• critical members members left the community (example: Arunoda)

And of course, while I progressed in the career ladder, there was less demand to ship things instantly but increasingly topics like scaling existing things or mentoring other developers or playing office politics. Several years I didn't even read anything related to meteor. Until last year when I decided to build things by myself again, to be prepared to enter more fast-paced job opportunities.

Using it today

Oh boy, how things have changed over the years! Part of it is stabilization in the framework itself, but IMO the bigger part is the rapid advancement of the javascript ecosystem itself.

• There are now several frontend SPA frameworks to choose from as the "view" layer
• depending on the framework, server-side-rendering is now possible natively
• MongoDB is quite a good database nowadays (depending on the usecases of course)
• development of the framework itself picked up steam again after an acquisition in 2019
• There is an excellent meteor hosting provider "Galaxy" with a free tier + great autoscaling for professional tiers as well as integrated application monitoring designed especially for meteor (formerly known as "kadira", now "Meteor APM")
• all the early features are still there (integrated user accounts, pub-sub-datalayer, ...)
• no webpack configs to mangle, meteor works out-of-the-box with its integrated build tool

But the biggest realization I had is, that actually none of the other popular (ie: known to me) web frameworks offer such a polished fullstack development experience. After all these years of "rapid progress". I would like to show you what I mean.

Experiences: Getting Started

Assuming you have any version of node.js installed, all that is needed is a short: npm install -g meteor. After that, creating a new preconfigured project is simply meteor create my_app_name --typescript, whrer the last part automatically generates a meteor app using react and typescript (my preference).

Seems boring, but the fact that this is all, it works as one would imagine and no further nitpicking about supplemental libraries/tools is required is awesome in node.js land!

Experiences: Advanced Frontend Stuff

If you develop something that might require some kind of content/marketing, chances are high that you will need server-side-rendering (SSR). If you use react, and probably also react-router, all you need is meteor-react-router-ssr. It will leverage good ol' tricks like fast-render under the hood and also does proper rehydration on the client out-of-the-box.

Another goodie is that react itself moved towards pure functional components and hooks. After a bit of initial learning, this is actually a great simplification of frontend-development: you have some functions that render data, and you have some (reactive) functions that handle data. While developing with useEffect is an awesome experience, it is very hard to accomplish SSR with it. This problem is basically solved when you use meteor for your backend data needs, see my grimoire spell for an example. In short: useTracker is executed properly during SSR, so nothing to do here.

A nice bonus is that meteor will also detect if you do dynamic imports and will automatically perform code splitting while bundling your code. So if you have something like bootstrap for your B2C frontend routes and Foundation for your B2B frontend routes, just a splitting at the router level will produce/load separate bundles with no further config required.

Experiences: Advanced Backend Stuff

The most important thing here is the same as it was always with meteor: actually there is not much backend code at all. Again, see my grimoire spell for an example. Basically you define the shape of your data and decide how you want to publish it (all, subset, user-only, ...), everything else is taken care of.

In fact, most code in a meteor app is isomorphic, running as-is within client and server contexts. Even the MongoDB database exists mirrored in the client known as minimongo, so any code that touches the database is immediately simulated in the client as well as on your backend. This means two things: the Frontend can update instantly ("optimistic UI") and the backend does have the final word (rolling back the frontend changes if needed).

The only "real" backend code is stuff you really don't want to expose to users, like external data access/credentials, server-only methods, stuff like that. This amounts to just a tiny percentage of the overall code base in my experience.

Experiences: Deployment

If you just want to try things out, you can launch a small app immediately with meteor deploy <yourapp>.meteorapp.com --free --mongo for free.

If you want/need a more beefy setup, have a look at Galaxy itself, servers start at $9/month. It is not particulary cheap, but fairly simple to have the topic "deployment/hosting" dealt with start-to-finish, including goodies like automatic SSL and integrated application monitoring.

If you are like me and like your apps LEAN, then you can go with a $5 droplet from digital ocean and leverage Meteor Up. It takes less than 30 minutes from reading the docs to having deployment finished, and supports multiple setups (like X app servers, Y MongoDB instances, ...). In my case, the absolutely minimal deployment complexity is enough, running everything including the database on a single cheap server is sufficient, and it works quite well.

IF any one of my products does require scaling some day, it is fairly easy to extract the mongoDB content and reimport it into a dedicated cluster, but this will be migration work I'd be happy to do (since this means having traction and $$$).

Experiences: Ecosystem

You have NPM at your fingertips, additionally there is atmosphere for dedicated meteor packages. While there are many outdated things, quite a bunch of packages work wurprisingly well today, even if they haven't been updated since like 5 years.

Bonuspoints if you know Rust: generating WASM is quite easy today, and nodejs as well as browsers are really good at running it. So basically many "native" things (inluding much stuff from crates.io) can be leveraged, too.

Since the frontend world seems to settle on React.js as the "winner", tons of packages/plugins are available, too.

Current Shortcomings

To be fair, not everything is sunshine and rainbows in meteor land right now.

• Apple M1 processors are not yet supported, I have to use a Rosetta Terminal
• Probably related to this, meteor run ios doesn't work on my M1 machine currently
• node-fibers is incompatible with nodejs >= 16, so there might be a breaking change in the future, probably using async/await in places where it isn't needed right now
• The meteor galaxy hosting requires you to bring your own MongoDB provider. While this isn't too big an issue technically, the mental overhead for me is too big. When I pay a premium for "fully integrated hosting" I expect this included.
• Some stuff is not typed, so some module declarations might be needed to keep the typescript transpiler happy

But to be fair, none of these points bother me too much right now. The development experience is awesome and deployment is solved for me using meteor up and a $5 droplet.

Closing Thoughts

I really think that meteor deserves much more attention than it has today. Especially small teams or solopreneurs could benefit greatly from the ability to "just ship features" and most projects won't even remotely require the scalability of FAANG companies.

But I also think that it is hard to explain the pure joy of the lightweight development cycle if you haven't experienced it. And of course there are developers out there that were burned from early times and/or the drama in-between. But think about it: how much time would you need with your current tech stack to ship a fully working (nontrivial) MVP, including CI/CD and SSR and user account management?

I just tested it, with 3x two hours during my last vacation until I registered my new property in the google search console. Six hours in total from idea to production.