Modern frontend admin architecture, fewer browser dependencies, new asset pipeline, long term support for 2.0
A little over a year ago, Apostrophe 2.0 landed in the npm registry. As the first mature and complete open-source Node.js CMS with support for in-page content editing, Apostrophe is gaining lots of traction. It is currently being downloaded over ten thousand times a month. Since then we’ve updated our brand and marketing material, rolled out enterprise services, sponsored a conference, released Workflow and Headless modules, and launched over 80 Apostrophe-based projects. We also heard from the community.
One of the biggest points of feedback from our awesome community of developers is that extending the frontend UI of the admin interface is not as convenient as extending the CMS in general, and we want to address this. Moreover, we want a website built on Apostrophe to meet the highest standards for performance. To that end, we want to limit the resources being pushed to the browser for non-admin users. We have listened to this feedback and plan on making these changes in Apostrophe 3.0.
Though long-term support for Apostrophe 2.0 will run through at least the end of 2020, we’re excited to announce we have begun the 3.0 planning process!
The Goal: A modern, developer friendly admin frontend
Currently Apostrophe has a custom admin UI, built in an object-oriented paradigm with the jQuery, lodash and async libraries. While it has its perks and served us well during the period when a new frontend framework seemed to pop up every day, it’s one more thing for developers to learn. We’d like to see more contributions to Apostrophe’s admin UI from the community. So we’re planning to embrace a lightweight modern framework with wider developer acceptance, declarative rendering and a virtual DOM, such as React.js or Vue.js. We also plan to marry this framework to our current framework. This allows most admin UI continues to be provide automatically with no need for boilerplate code generations.
Where we are and what’s in scope
We’re just in preliminary stages of planning what the implementations of 3.0 will actually look like, but we have broken the scope into the following groups:
User Experience and Interface
Apostrophe’s interface and user experience flow is a constant iteration. There are flows that need reworking and interfaces that need a hard look from design. Adding functionality, condensing interface patterns, and changing workflows leads to a steady push-and-pull of the admin frontend. Last year we worked with experience designers to facilitate targeted testing with real-world Apostrophe clients and started cataloging these issues for future sprints.
Most of these improvements will be implemented even before 3.0. Rebuilding the frontend will allow us to individually evaluate interface elements, build a living pattern library, and organize CSS based on the ITCSS architecture. This leads to better standardization and compartmentalization of Apostrophe’s components to create a more resilient frontend.
Refactoring the Asset Pipeline
Apostrophe’s current built-in asset pipeline will be replaced with an implementation that integrates a widely used tool, such as Webpack or Gulp, while still addressing the need to support assets contributed by modules. Although generating assets with your own tools and pushing them to Apostrophe will still be supported, to improve our frontend admin code we will choose a new “house style” for asset builds that includes a CSS preprocessor, such as SASS rather than LESS, and the use of Babel. You will have the option of using it for your project-level assets as well.
Speaking of assets, while Apostrophe does distinguish between assets needed by admin users and assets needed by the public, we currently push too much stuff out to the public. 3.x will support pushing nothing at all to the public, other than what you choose to push at project level. This option is likely to appear even before 3.0 arrives.
Frontend Framework
As mentioned previously, we’re planning on introducing a lightweight frontend framework for rendering Apostrophe’s admin interface - like modals, editors and in-context admin chrome. The goal in using a framework is that Apostrophe components are easily written in a format familiar to a wider developer population while maintaining tightly encapsulated component format.
Vue.js and React.js quickly became the top contenders because of a combination of adoption, speed, and ease. While we are evaluating both, we’re currently leaning towards Vue.js. Both the internal Apostrophe team and our enterprise clients have been using Vue.js with success and it fits our criteria for a lightweight and straightforward framework. One of our technical challenges will be marrying Vue.js’s component architecture with Apostrophe’s functional object-oriented programming pattern, which affords us zero boilerplate code for subclassing and extending pieces on the frontend, unless custom functionality is required. This is a pattern Apostrophe has committed to and we still feel it is an excellent solution to our problem.
What we’re not going to do in 3.0
In 3.0, we’ll be avoiding significant backwards compatibility breaks for most server-side Apostrophe code, especially things you’re likely to be doing at project level. We may introduce some bc breaks where there is a clear win for everyone, particularly with regard to better support for promises and better performance. But you definitely won’t need to “start from scratch.”
Contribute and follow along
As we continue fleshing out a roadmap for Apostrophe 3.0, we’ll be looking to the community for input and insight. We’ll be asking specific technical and implementation questions in the Apostrophe: Forum and will be working on a high level 2018 roadmap.
Happy New Year from the ApostropheCMS team!
An update: our first Apostrophe 3.0 technical discussion
We’ve convened a discussion about the best way to handle events that affect many modules in the Apostrophe forum. Please swing by and participate!