Consider Vite

[v6ak]

Usage in dev

• HTML generation
• years.json generation
• CSV download
• SASS processing
• JS

Todo for production

• JS bundle size
• proper SSG
• CI
• relative paths

Checklist for production

• JS bundle size
• CSS file name
• HTML
• CSS
• JS
• CSV for 2015 (not critical for dev)
• years.json
• all paths are relative
• verify asset fingerprinting
• verify directory structure
• CI
• remove unneeded index.html

Depends on #56 (done).

[v6ak]

Static HTML

Probably feasible. In dev, we can use server-side rendering. For prod, we could somehow generate the files.

JS size

This is PITA:

• Vite requires ESM. (CommonJS might be supported via some plugin. However, with ESM, Scala.JS disables Google Closure Compiler, which causes much larger binaries (approx. 1.9MiB vs. 1MiB).
• Multiple modules (client + htmlgen) would be useful. But again, this disables Google Closure Compiler, even with CommonJS.
• Maybe we could somehow call google-closure-compiler ourselves, but this is probably not an easy task.

Using Vite just for dev (and maybe SASS)

Vite requires minimal code changes, so we could use Vite for dev and SBT-web for prod. (And probably get rid of Play framework.) This way, we would probably still want to use SASS compilation by Vite, because sbt-sass uses an outdates SASS compiler and because it seems to be easier to integrate it this way than the other way around.

[v6ak]

In order to share node_modules between scalajs-bundler and Vite, we could use NODE_PATH variable.

[v6ak]

JS size seems to be somehow manageable as long as I can use .withOptimizeBracketSelects(false) for basic linker.

[v6ak]

At this point, the feature/vite branch is somewhat useful. While I cannot build it, I can use it when developing (must faster turnaround) and then cherry-pick the commits to devel branch.

[v6ak]

When this is done, we can replace divisions in SCSS by math.div. Until then, we use an old SASS version, which doesn't allow to do that.