Looking ahead to NodeBB v2.x
Wait! Don't get too excited!
There's a lot to figure out and a lot to actually do, so we're not in any position to state any timelines or make any promises1 just yet.
For what we can say, head on over to the bottom tl;dr section.
On the 7th of February, the NodeBB founders came together and thought critically about NodeBB's next steps. On this not-so-historic day (because regular conversations about our future should definitely happen!), we reflected on our work so far, and talked at a high level about what would/could come next.
We've often had customers and users ask us about our roadmap, but we honestly didn't have one that we willingly shared. Between Baris, Andrew, and myself, we had different goals, different priorities, and different visions of what NodeBB could be, and we were almost always constantly busy iterating on NodeBB to step back and ponder the future.
However, it's safe to say that for the past few years, we've strayed away from our beginning goal — to build forum software like it's meant to be. We've become a feature factory, shipping functionality2, but not spending the time to view NodeBB as a whole to consider our direction from a top-down perspective.
We decided we needed to step back and re-evaluate our work, achievements, and direction. NodeBB v1 has evolved into a project we're very proud of, but there is always room to grow, work to be done, and improvements to be made. We've spent 6½ years building what we have, but did we want to spend the next 6½ iterating on the same base?
Webpack, Bootstrap 4, and SCSS
We initially hitched our wagon to technologies popular in 2013: require.js, Bootstrap 2 (and later, 3), and LESS3.
The industry has evolved and moved on, but we've maintained our use of these tools because of inertia. Simply put – to change now would be a huge amount of work.
We also had a fair bit of decision paralysis – which technology gives us adequate future-proofing, and which ones are worth learning? Investing time and effort into a technology that would only be deprecated or put into maintenance shortly after would be demoralizing, to say the least!
The way NodeBB internals are built, to implement one technology would (or might) cause pain to our 3rd party plugin and theme developers. Did we want to do this multiple times as we iterated through breaking technologies? This easily caused our discussion about NodeBB v2 to snowball massively until we were looking at the daunting prospect of rewriting a huge amount of the codebase (i.e. Bootstrap 4 breaks every theme, so we might as well also implement SCSS. If we're going to ditch all our existing stylesheets, we may as well create a brand-new theme to go with it).
We've wanted to get rid of require.js for quite some time. There were always incompatibility issues with third-party libraries, and it did not play nice with our minifier4.
So, what to do?
Break everything at once, apparently. We decided we had to implement them all at once, and go through the pain of migration once.
Webpack
Baris is leading the charge to implement webpack as a module/dependency loader in an effort to improve our client-side minification/bundling efforts. Our current implementation often had us in dependency hell: one library loaded another, and so on, until the entire set of modules was loaded into memory!
We also hand-built our minifier (as was the style at the time), but the industry has matured since then and we have great new features like bundling, which we were interested in taking advantage of. Smarter dependency loading would reduce the client-side payload, and give us faster initial load times.
The second benefit is allowing us to finally write client-side code in CommonJS/ES6 style. We're hoping that implementing webpack properly will swiftly ease the many pain points we experienced with require.js.
Bootstrap 4
While Bootstrap 4 was released awhile ago, we've been hesitant to upgrade as it contains many breaking changes. Not only is it hard for us to upgrade, but it would instantly invalidate every theme and impair the interface of most plugins available today. We also wanted to re-evaluate the current method of making a custom theme – was forking Persona ideal? Is it necessary for a theme to contain every single template?
Enter nodebb-theme-palette
The Palette theme is intended to address these concerns:
- Minimal templating – some unnecessary templates have been moved to core so as to eliminate unnecessary duplication. For example, we found that most themes never touched the account edit/settings pages. Once moved to core, they would be a sensible default, yet still easily customizable if need be.
- Minimal styling – aside from the Bootstrap 4 base, individual pages in Palette should have minimal styling, if any. This should allow theme developers a solid base with which to build upon. The less time spent rebooting a theme back to a clean slate, the better!
SCSS
Relying on LESS was a gamble that we had taken. It was a decidedly good improvement on CSS, but the industry (and bootstrap) went with SCSS, and we intend to follow suit.
We would likely still allow usage of LESS in themes and plugins, but we're going to bite the bullet and dump almost all of our stylesheets and start over with a clean slate for Palette.
tl;dr – What does this mean for NodeBB v1.x and Persona?
We fully intend to continue development and issue bug fixes to the 1.x (and master) branches. For now, all of the v2.x work is contained in the webpack branch of core.
Timeline-wise, we can't even begin to speculate on how long this work would take.
This blog post serves as an introductory overview of what we intend to do. I'm hoping I'll be able to release periodic updates on our work, as I'm sure many of you will want to follow our progress closely :)
As we get closer to our goal (2.x), we will be releasing a series of migration guides to help you move to the new v2.x of NodeBB.
1 await nodebbv2plz(); :)
2 By and large, our philosophy is that we should always ship functionality in plugin format. We've seen much success (and by extension, achieved a fairly lean core) by doing so, and we have no plans on changing this strategy.
3 You'll notice I didn't include jQuery in this list. We definitely do want to replace jQuery with a lighter variant (maybe Zepto?), but we figured webpack, bootstrap, and SCSS were a big enough bite for now.
4 Most often, we'd have mismatched anonymous define() modules errors, because our implementation relied on modules being explicitly named. We'd also have platform-agnostic libraries plain refuse to work, again because of an incompatibility with how we configured require.js
Cover Photo by Simon Matzinger on Unsplash