Page MenuHomeSoftware Heritage

Web App: Improve frontend development workflow
Closed, MigratedEdits Locked

Description

Currently, the management of static assets (JavaScript, CSS, web fonts, ...) for the frontend part of swh-web
is not really optimal and quite chaotic as:

  • we rely on multiple CDN to retrieve dependencies like JQuery or Bootstrap
  • a lot of JavaScript code is located in script tags in Django templates
  • all custom stylesheets are located in a single CSS file

This lack of modular organization complicates the frontend development and its maintenance
as the application grows.

So I think it is time to improve the frontend development workflow before pushing new features
to swh-web. Today classical approach is to put a static asset pipeline in place through the use of
a module bundler tool. The idea is to organize frontend development into logical modules,
builds a dependency graph that includes every module the swh-web application needs,
and then packages all of those modules into one or more bundles.

To my knowledge, the best tool out there to improve frontend development is webpack.
It is highly maintained, allows to handle a lot of asset types, is easily extensible through its plugin system but
also highly configurable. Webpack also speeds up development through its hot reload feature (no need to refresh the
browser anymore when modifying js or css) and can generate production bundles with dead code elimination and
assets mignification. Last but not least, it can also be used in conjunction with Django through django-webpack-loader.

Migrating frontend development to webpack will induce the following changes:

  • All needed assets will be retrieved through npm for a better dependencies management
  • Javascript code and stylesheets written so far for swh-web will be reorganized into logical modules
  • Those modules will be compiled into bundles by webpack and loaded by client browsers when required

As a consequence, node.js will be a requirement in the swh-web development environment (but not on
the production one as the assets will be generated a priori and stored in a dedicated folder of the swh-web
source tree).

That task is there to track the progress of setting up a webpack workflow for swh-web.