Last modified by Manuel Leduc on 2024/02/01 17:31


The goal of this document is to gather related technologies for different areas of Cristal in order to make sure we do the best long term choices for the development of it


There are some strong reasons to use Typescript instead of Javascript in order to have compile time verification of the code.

In the prototype being worked on, Typescript has been experimented successfully with tsc and vue-tsc. The support of typescript by vue is nice. The vitejs tool worked well with typescript. The editor used is VSCodium which is displaying all code errors properly and the development productivity is quite high.

Typescript has strong advantages of favoring "api-based" development.

Frameworks & Front-end Technologies

The goal is to list the best front-end frameworks, whether it is the core framework or frameworks on top of it.

We are looking for a front-end Framework that is serverless (Cristal should work as a standalone tool with "traditional" rest backends).

We have some initial preference with VueJS which we have used for LiveData.

TODO: listing frameworks built on top of VueJS

Web Components frameworks / libraries

Also looking at: See

Other frameworks

  • React
  • AngularJS

In the prototype being worked on, Vue3 is being used and allowed to build a "skin" system. It also allowed to "abstract" the design system (see below). Integration with Typescript is working well. Vue has support to consume web components.

One aspect to check are the complexities around upgrades. LiveData is still in Vue2. As time passes, new breaking version of frameworks will happen and it will be difficult to support extensions build on an older version of a framework with a new version of it being used in the core application. It risks breaking compatibility and require to "upgrade" all extensions at the same time.

About Web Components

Ideally we prefer standards. And therefore the Web components standards is very interesting.

Now as stated on the Vue page on web components, web components do not provide all the features that a framework like Vue provides

There is indeed a certain level of feature overlap between Custom Elements and Vue Components: they both allow us to define reusable components with data passing, event emitting, and lifecycle management. However, Web Components APIs are relatively low-level and bare-bones. To build an actual application, we need quite a few additional capabilities which the platform does not cover:

  • A declarative and efficient templating system;
  • A reactive state management system that facilitates cross-component logic extraction and reuse;
  • A performant way to render the components on the server and hydrate them on the client (SSR), which is important for SEO and Web Vitals metrics such as LCP. Native custom elements SSR typically involves simulating the DOM in Node.js and then serializing the mutated DOM, while Vue SSR compiles into string concatenation whenever possible, which is much more efficient.

Vue's component model is designed with these needs in mind as a coherent system.


One approach could be to choose a framework build on top of web components ()  . We would need to research more these frameworks, which would still be "non standard" as the features describe before are not existing in standards.

Another approach would be to be more independent from a framework like Vue by using webcomponents as the basis components for the design system. Vue is compatible with Web Components both for using them and providing our components as Web Components.

For that we need to research web components UI libraries:

Since Vue supports providing our components as Web Components, we should definitively look at providing part of our UI as Web Components as a way to embed in other application. We'll have to see how that allows for tight integration in other applications. This is something we should prototype early. Vue mentions on their web site that the "cost of the vue library" would be 14k (to verify as the library is 80k but after compilation it could be lower). This seems to be negligible compared to all the other code that we will need to provide wiki functionalities or even our UI library.

Design Systems & Component Libraries

Design Systems & Components Libraries

Vue 3

Documentation Generation

Options API vs Composition API


Code Style and Linting

Code Style and Linting


In the prototype being worked on, nothing special has been made yet. It will be very important to set accessibility coding rules early in the project and include testing tools right away.

Packaging and Module Bundling Tools

Article about standard Modules

Module Bundler

In the prototype being worked on, initially webpack was used, then rollup to use vitejs (which uses esbuild for compiling). In case of using native Javascript Modules for the development and the delivery, webpack is not the tool to use, as webpack is made to actually do the opposite. ViteJS is much more used by the Vue community (built by them) and in the end was much simpler to put in place. Integration with typescript worked well.

Package Manager

Package Manager

Dependency Injection & Extension Manager

Dependency Injection & Extension Manager

Editor Technologies

No experiment yet in the prototype on a "new editor". However it was possible in the prototype to load the XWiki editor in an IFRAME with all features of the editor available. This could help give us time to build a new editor.


TODO: list APIs of products we could integrate with


TODO: testing tools

Get Connected