CatalogJS & Boxel Design System
A progress update: What’s happening in 2020
Milestones we reached in the first half of 2020
New Cardstack Hub
In March, we merged the new version of the Cardstack Hub — our decentralized application server, which implements Card Schema V2 — with the main Cardstack Builder codebase. Read all about the new hub in this article.
Internal beta version of the builder
In April, we completed the internal beta version of the Cardstack Builder. In case you missed it, here’s the demo that gives you a walkthrough of our unique card building tool.
New Cardstack website
We also launched a revamped website, which conveys our product orientation in a more user-friendly way. Check it out yourself to learn all about our product and technology, as well as our design & development studio.
What we are working on right now
In Q2 of this year, we conducted two tracks of development in parallel, which we continue to work on in Q3. We are proceeding full-steam ahead with the necessary design and development to realize these pieces of technology, which we need in order to create an open network:
- Boxel: our design system for card-based UI templates and functional composition
- CatalogJS: the underlying build and software distribution system that will lead to the Card Catalog
Boxel and CatalogJS, combined with the Card.Space hosting service — which has been in testing since earlier this year — will enable us to launch a developer-oriented card-hosting service to start, and a user-oriented Cardstack Builder service to follow.
Boxel Design System
The Boxel Design System is our way of generating sophisticated user interfaces that will hook directly into Cardstack’s full-stack runtime. They can be composed without a significant amount of programming, as it is our ultimate goal to make the entire UI assembly process no-code.
In the last few months, we built upon the forms that can be created in the Cardstack Builder. We extended the system significantly to include:
- collections management — which allows you to display, filter, and sort large collections of cards in grids, lists, and tables
- embedded cards — which allows you to nest cards inside each other
- assets — which allows you to use cards as media assets or financial assets
- threads — which is the basic workflow system to move cards from one realm to another
These components are integrated with the Boxel Motion Engine, which facilitates the smooth animation of cards, as you navigate through them and move them between realms. This is part of the broader design system we continue to work on, as we create additional components like:
- the action system — which allows you to chain cards together, creating multi-step action flows that require multiple screens to be completed
- revision control — which allows you to compare and review assets in your realm, seeing the differences (e.g. changes made to fields and data) between two cards of the same type across a timeline
- the reuse of card templates — which facilitates software development and deployment workflows, as CatalogJS contains more developer-oriented fields, like module names or GitHub URLs
Once the initial set of Boxel components is completed, we aim to document and wrap them up as part of a full design system catalog. Developers and users will be able to assemble those components into full-featured cards, which become useful apps that can be connected with each other to create a real syndication network.
CatalogJS
As we were designing the Card Catalog in the last few months, we realized that the capability of real-time modification and deployment of software (which Chris Tse outlined in his talk on the “Evolution of Software Distribution”) is not only valuable to Cardstack, but to the broader JavaScript ecosystem as well. Therefore, we decided to extract the applicable pieces of the Card Catalog — which can be applied to other JavaScript projects — and split up the “Card Catalog” into two parts:
- a broadly useful JavaScript service called “CatalogJS”
- a more UI-specific experience called “Card Catalog”
CatalogJS enables us to launch a developer-focused, decentralized module registry as a use case ahead of launching a decentralized SaaS platform for users. This module registry will share the same hosting infrastructure as the user-facing variant of the catalog. It will allow developers to prepare their libraries, frameworks, and applications for this type of flexible, composable software distribution using the Card.Space infrastructure.
In order to support the broader set of libraries that is in use in the JavaScript ecosystem, we are developing a third-party recipe system. By providing an additional recipe in an open-source way, we allow existing JavaScript modules like React, which are not designed for CatalogJS, to be adapted to fit our module delivery system. Our team will develop a set of recipes for common libraries, while inviting the JavaScript community to develop recipes for less popular packages in the npm registry. This recipe system is similar to the already existing Cardstack Hub plugin system, as it allows us to tap into preexisting code in the open-source ecosystem just like the plugin system allows us to tap into the smart contract universe — by using an adaptor pattern to make external software behave as if it had been designed the Cardstack way all along. Anybody can write an adaptor and open-source it for others to use or keep it as a proprietary advantage.
Research & Development for CatalogJS
Currently, the R&D phase revolves around allowing cards — which are built to run on Cardstack — to use the full range of JavaScript modules and libraries that already exist in the JavaScript/Node.js/npm ecosystem, so that cards can take advantage of all those functionalities or capabilities.
More specifically:
- We are working to ensure that all the features you will need to run a Cardstack application are packaged as npm modules and then delivered through a cloud-based Content Distribution Network (CDN).
- We are working towards being able to build the CatalogJS application and runtime on top of the CatalogJS codebase and build pipeline. This will allow us to quickly iterate on new features for the CatalogJS codebase in the same immediate, latency-free way that we want to extend to all JavaScript and/or card developers. The CatalogJS architecture allows you to make changes to any code or configuration on the fly in the browser, without writing any command lines on your computer and waiting for a long build pipeline to run.
- We have completed a round of refactoring to allow for optimized assembly of third-party packages. These can be CDN-hosted and composed efficiently in the browser, without a large overhead, compared to creating a full parse tree or loading each module individually. Our architecture enables us to strike a balance between loading modules dynamically (without bundling) and the efficiency of pre-analyzing and partially bundling modules ahead of time.
- We are working on the developer onboarding workflow. This allows developers to pair the CatalogJS runtime with their desktop editor (such as Visual Studio Code) through a process similar to pairing Bluetooth devices and Airplay mirroring. This ensures a proper set of security and trust relationships, which enables us to do automatic code pushes once those trusted channels are established.
Ultimately, CatalogJS will become the underlying infrastructure to develop all the software that will be included in the Card Catalog. The Card Catalog itself will only be a UI layer for exploiting and selecting cards, which are just modules in the CatalogJS universe.
CatalogJS will support both no-code and real-code use cases, with one common compiler architecture and runtime. We are building the Cardstack Builder — our no-code application building platform — on top of the real coding infrastructure, which brings two benefits:
- Users who use no-code tools can invite developers to extend their applications, making them more scalable and integrating them with existing systems.
- Developers can use prebuilt components (that have already been published to a familiar registry like npm) to accelerate their progress towards the first version of their app, which they can test with users.
Recently, Chris Tse recorded a talk on the paradigm behind CatalogJS: Software-as-a-Tool, as opposed to the more conventional Software-as-a-Service. Many of the concepts he presented, such as leveraging existing package repositories like npm, while providing an additional layer of usability and composability, are being implemented in code as we develop the deployment strategy.
You can find the CatalogJS project (our core build infrastructure) in a public GitHub repository called “Catalog-Experiment”. Our first public beta will be about CatalogJS, as that is the foundation of the module system needed for both the Cardstack Builder and the Card Catalog.
Making cards move via CatalogJS, Boxel, and the Cardstack Hub
As Chris Tse recently explained in a tweet, the main challenge of the Cardstack platform is to make cards move — across organizations, nodes, apps, sites, hosts, stores, libraries, and more.
A card is a bundle of data, logic, and UI. Thus, in order to move a card, we need to move all three layers of the stack simultaneously. That is why our work on the Cardstack Hub (data), CatalogJS (logic), and Boxel (UI) is so essential.
The goal is to combine these layers in a seamless way, ensuring that everything (data, logic, and UI) is moved at the same time when a card is dragged into another space. The final assembly, just like making a great car, is about hiding the technical parts and letting the user interact with the card through a singular experience.
Use Cases
Use cases validate our approach and provide real-world feedback on our architecture and design. We make sure that the Cardstack technology can generate applications that are indistinguishable from regular SaaS software, while being underpinned by a much more decentralized set of protocols.
As a way to ensure that our building blocks are solving real business use cases, we continuously apply the Boxel components and the data model (enabled by the Cardstack Hub) to various POCs and usage scenarios. Such a proof of concept shows that cards stored in multiple hubs can move between these hubs, modeling different transactional or business process workflows.
Some of these workflows are part of our media registry use case. We have designed and developed about 75% of the design components and front-end UI code we need to build a blockchain-backed media registry, the back-end of which is already in production. This registry handles data, files, forms, tables, grids, dates, tags, cross references, and much more.
Yet, these UI components and workflow modules can fulfill most business application use cases, including e-commerce transactions and decentralized peer-to-peer trading. The same Card UI system that supports transfers of music catalogs between labels also supports purchases of home improvement products between businesses and clients.
All these use cases share the same design system as well as the same underlying front-end and back-end architecture; they are essentially different configurations of the Cardstack Hub. Our aim is that all these use cases can be configured in a no-code way, using the Cardstack Builder interface without any developer involvement. At this stage of the project, we feel confident that we have built a general-purpose platform, which enables developers and users to make some of the same apps and use cases we have been custom-building with our vertical-industry partners.
We will circulate click-throughs of some multi-hub interactions as examples of the user experience that is enabled by the Boxel Design System, as we transition from the UX layer to a full-stack implementation, using the latest Cardstack Hub.
Our long-term goals & expectations
As long as the tools in the experience layer are not built in a way that makes the system decentralized and cooperative, blockchain/DLT networks will never become tactile and real for regular business users. That is why we are not working on a one-off user interface for a protocol, but creating a composable set of Web development and deployment tools, so as to bridge the gap between the users’ needs and the promise of crypto/blockchain networks.
We are building a channel between the Web, Software-as-a-Service, consumer apps, and the blockchain ecosystem.
Once this system works for both developers and users, we expect many crypto projects and new blockchain networks (Layer 1 or Layer 2) to connect to Cardstack through a plugin, accessing our UI components, search and indexing functions, data composition and processing tools, and user delivery channels (desktop or mobile) — in order to accelerate their use cases, without having to do all the work the Cardstack team has done in the last few years.
Additionally, users who want to access the value and reward of the blockchain ecosystem need a platform that is connected to blockchain systems, but that can synthesize data in a user-friendly way. Cardstack is an important tool that provides a shortcut to a great user experience. We want new users, who are looking for software-based solutions, to see a decentralized and cooperative model that is good for business, cost-efficient, and easy to use.
We are continuously making progress towards our roadmap, the specifics of which we have outlined above. But the real milestones will be reached when regular users can assemble Cardstack apps without involving a developer. In terms of composable architecture, we have already surpassed platforms like Notion, Airtable, and Webflow. Now, it is about packaging all the parts into a user-facing product and inspiring the world’s makers — developers, designers, and creators — to leave their mark on the Cardstack platform; so they can be the ones to build the apps or dApps that challenge the titans of Silicon Valley.
Our focus on getting through the tech stack as precisely and expediently as possible will allow us to switch our focus to market adoption and partnerships, once the platform is fully built and used by more and more users every day. We are anxious to get this platform in the hands of many users. But we have to build a strong foundation first, to ensure that we can support all the use cases that will be discovered when the next phase of crypto/blockchain growth arrives. When that growth arrives, we want users to be able to construct their business networks using our no-code tool, then extend it with real code — and integrate it with the systems that run their world.
Learn More
- Software Through the Ages: A product in the past, a service in the present, a tool in the future
- Composable Monetization Techniques for Creative Content: What are the future building blocks for the world’s creators?
- Rebooting the World after the Global Shutdown: How will evolving human psychology affect the way we rebuild our physical and digital habitats?
- Cardstack.com
To get all our latest updates, star Cardstack on GitHub and join our Discord channel or our Telegram group and announcement channel.
