What’s Next for Vulcan.js
Preparing for the next evolution in the framework’s life
I grew up watching Dragon Ball Z, and one of the most common tropes was the bad guy’s “final form” moment.
After a tough battle, our heroes were beaten and bruised but had finally gotten the enemy on the ropes. These courageous warriors were almost ready to land the final blow, when the enemy suddenly declared that this wasn’t even their final form, and then launched into a lengthy transformation process that refilled their energy and left them even stronger than before.
Why the bad guy didn’t just walk around in that final form in the first place, or why the heroes never though of just knocking them out during the transformation phase, was never quite explained.
But all this to say that Vulcan, too, is going through its own lengthy transformation phase that will hopefully make it more powerful than ever!
Vulcan.js + Next.js
Next.js is a React framework that originally started out dedicated to solving the server-side rendering question, but has since added many features and expanded its scope to basically becoming one of the best ways of serving any kind of React app, from SPAs to SSR’d apps to static sites.
Some of the advantages that Next.js offers over Meteor include:
- First-class support for SSR.
- Support for static export, including only making parts of your app static.
- A focus on speed, performance, etc.
- More compatible with the rest of the JavaScript ecosystem.
- A more dynamic community with more momentum.
Our goal over the next year or so is to progressively adopt it as the new home for Vulcan.
An Even More Modular Architecture
We’ve decided to take advantage of the occasion to drastically rethink how the various pieces that make up Vulcan fit together.
Currently, Vulcan is a bit of an all-or-nothing proposition. To get any real benefit out of using it, you really need to adopt the entire stack, from the GraphQL API generation all the way to the front-end form components.
This doesn’t mean breaking the framework apart is impossible, but it’s just not currently what it’s designed for.
We want to change this by making the Next.js version of Vulcan much more modular. For example, imagine separate packages for handling schemas, generating the GraphQL API, and handling forms, all of which can be used independently. This means you could use:
- The
schemapackage and thegraphqlpackage, to generate a GraphQL back-end. - The
schemapackage and theformpackage, to build a non-GraphQL app. - Only the
starterpackage, to build a completely custom app that can still leverage other, smaller Vulcan packages like error or event tracking.
So instead of building a monolithic framework that is hard to adopt, the idea is to build out an ecosystem of Lego bricks that still fit together perfectly.
Roadmap
This is a very ambitious vision, so we’ve broken it down into three general phases (after all, the final boss’ transformations can never have too many phases!).
Phase 1: Starter
We will release a pure Next.js starter project that does not have any direct link with Vulcan, as a way to establish a starting point as well as gain a foothold within the Next.js community.
Phase 2: Vulcan Compatibility
In phase 2, we will progressively add utilities that make it easier to use a Next.js app built with the Phase 1 starter as a front-end for a separate Vulcan app. This could mean facilitating things like user accounts, forms, data loading, etc.
Phase 3: VulcanNext
Finally, phase 3 will be reached once we have ported over all current Vulcan features to the Next.js project. At that point, you should (ideally) be able to get by with only the Next.js app, and we will then deprecate the current, Meteor-based version of Vulcan.
The Current (Meteor) Vulcan
If you’re a user of the current, Meteor-based version of Vulcan, you might understandably wonder what this all means for you. But you don’t have to worry, as we’ve specifically designed our roadmap to make the eventual transition completely optional.
First, I (Sacha) will keep working on the Meteor version of Vulcan, while Eric takes the lead on the Next version. I actively maintain two production Vulcan apps (ZensHome and Sidebar), so I wouldn’t be able to abandon the current version of Vulcan even if I wanted to.
Also, for the immediate future the whole idea is to make it easier to keep your Meteor app and augment it by adding a Next.js front-end, not replace it. And even once we eventually reach phase 3, there will be nothing preventing you from keeping the same two-apps architecture.
Finally, it goes without saying that we’ll try to keep the internal Vulcan APIs unchanged. After all we’ve spent years refining the way Vulcan works, so it wouldn’t make sense to change it now!
What You Can Do Today
If you’d like to help wih this vision, here’s what you can do.
- Try out the current Vulcan Next Starter project.
- Try out the brand new Vulcan v1.16 (and check out the “New Best Practices” section of that post).
- Come discuss this post in our Slack chatroom!
I’m personally very excited about this evolution for Vulcan, and I feel it might be the big break we need to finally give the project its chance. I know it’s going to take a lot of work, but if watching hundreds (thousands?) of hours of anime has taught me one thing, it’s that anything is possible if you believe in yourself!
