Technologies

Last modified by Ludovic Dubost on 2023/09/23 11:27

Introduction

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

Language

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 (Wiki 3.0 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: https://www.webcomponents.org/ See https://vuejs.org/guide/extras/web-components.html

Other frameworks

  • React
    • Nextjs.org
  • 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

Here are some design system

CSS UI / Vue Frameworks

  • vuetify
  • bootstrap 4 (bootstrap vue)
  • bootstrap 5 (bootstrap vue next)
  • tailwindcss (radix vue)
  • foundation (does not seem to have vue integration)

In the prototype being worked on, an API has been created to abstract the design system and therefore create the "X design system" which would proxy the favored design system and also allow to create multiple implementation of the design system. In the prototype 3 base components (x-alert, x-btn, x-card) have been used with an implementation with implementation in Vuetify and in DSFR. The result is interesting.

Accessibility

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

https://philipwalton.com/articles/using-native-javascript-modules-in-production-today/

Module Bundler

Package Manager

  • npm (both nodejs and individual modules) -> corresponds to maven in the java world

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.

Dependency Injection & Extension Manager

Dependency Injections Frameworks

Quite interesting article about dependency injection in Javascript: https://snyk.io/blog/dependency-injection-in-javascript/

Vue has dependency injection between the Vue modules using the "provide", "inject" functions.

Some frameworks to investigate:

injection-js

InversifyJS (most stars  tested successfully)

TSyringe

In the prototype being worked on, inversify has been used successfully. There are some concerns that the project is not very active. The other frameworks should be tested also.

The inversify library has been succesfully used in combination with dynamic loading of extensions and also with static building which makes debugging easier.

Dynamic loading

Different systems support dynamic loading of javascript code. The question will be how to package more than one JS file.

There are multiple popular package managers which have features for dynamic loading but there are some difficulties to overcome, in particular concerning shared libraries.

Webpack module federation

It seems possible to bundle multiple apps as webpack packages which can load each other. This could be a good way to dynamically load modules from a configuration. Our modules could contain components implementing specific APIs.

Plugin systems

Extensions build with Standard Javascript modules

By using vitejs (or rollup) it is possible to build standard javascript modules.

These modules can be loaded dynamically as extensions and provide components to inversify allow to extend the features.

Static bundling can also been turned on to bundle some of the external modules in the main package.

In the prototype being worked on, extensions have been packaged as "standard JS Modules" with an entry point loading components using inversify.

Circular dependencies between extensions has not been experimented. To keep things simple, key APIs have been moved to an "api" module loaded first by all extensions.

The approach is compatible with VSCodium seeing the dependencies between the code (using a mono-repository).

Editor Technologies

Block Editors

Notion competitors

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.

APIs

TODO: list APIs of products we could integrate with

Testing

TODO: testing tools

Tools for the Project

TODO: build and testing tools

  • webpack
  • rollup
  • esbuild
  • vitejs
  • npm
Tags:
    

About

About

Support

Platform

User Guide

Admin Guide

Developer Guide

Projects

XWiki

Extensions

Other

Contribute

Status

Practices

Under the Hood

Get Involved

Get Connected