Note

These are unedited stream-of-conciousness notes from reviewing the frameworks.

Web tech and frameworks

CSS frameworks

These are the more popular ones, but definitely not an exhaustive list in any way:

  • Bootstrap

    Uses the Grunt build system, available via Node.

    Provides a pretty large library of components. Can used CSS-only, if you don't use any of the components that require an accompanying JS library.

  • Semantic UI

    Philosophy is that you add a bunch of "semantic" classes to your HTML elements and these then get themed.

    Has a pretty large library of UI components.

    It uses the Gulp build tool to compile the themes. The project (theme) gets compiled into minified JS and CSS files, which can simply be included in the HTML file.

    The compiled CSS and JS are ~1MB in size though and we'd have to ship in the Documenter.jl repository, since I don't think we want a NodeJS dependency on core Documenter.

    In principle, we could create our own CDN as a GitHub page where we host the JS and CSS for each Documenter version. But this might be a bit brittle.

    Depends on jQuery, which is fine since we already depend on it ourselves.

  • Pure.css

    Very easy to include it seems. Just load the CSS files.

    It seems that it only provides its default theme. And if you want, you can then customize it, of course. But does not seem to provide a systematic way to create themes?

    Overall, it does not look like it provides that many features, so a more feature-rich framework might be better.

  • Foundation

    Based on scanning through its docs, it just felt a bit too "heavy". Hence I did not really give it too much additional thought.

Full JS frameworks

A different class of frameworks which involve compiling the site into a production version with (usually) NodeJS. Examples:

I am discarding these outright, since these are too heavy. It is not clear how you could easily integrate them with Documenter build pipeline. Minimally, it would add NodeJS and a ton of related dependencies.

Sometimes there even is no real output HTML, but the DOM is dynamically generated with JS (when the production website is loaded into the user's browser that is).

They are probably very well suited for writing and managing large web applications. But Documenter's HTML front-end is not that — it's really just a single small HTML document.

Bundlers

Bundlers compile source files (HTML templates, SASS files etc.) into final set of production-ready HTML / CSS / JS files. While Documenter itself shouldn't depend on a dependency like this, it could we something we could consider for DocumenterTools when building a template.

Web Components

One idea is to have a docstring component as a Web Components. But actually, you can't globally theme it then it seems, since the web-components are meant to be self-contained. So it does not actually make sense to wrap core components in Web Components.

Using Web Components would also mean that the documentation pages would be relying on page elements that are generate dynamically with JS, using a relatively new API. So it might lead to compatibility problems.