Slate and the Future
Tags: slate, slatedocs, node, eleventy
Published: 2020-06-23 10:36:10

---
title: Slate and the Future
published: true
description: The Slate v3 Technology Preview
tags: slate, slatedocs, nodejs, eleventy
cover_image: https://raw.githubusercontent.com/slatedocs/img/main/screenshot-slate.png
---
Two announcements today, first thanks to the hard work of my co-maintainers Matthew Peveler and Robert Lord, and many members of the Slate community, we are happy to present [Slate v2.7.0](https://github.com/slatedocs/slate/releases/tag/v2.7.0).

Secondly, we have something we'd like lots of feedback on.

The Slate v3 technology preview (in the `v3-tp0` branch) is a ground-up reworking of Slate using pure Node.js and the [eleventy](https://www.11ty.dev/) static-site-generator.

The Slate v3 technology preview uses the exact same CSS and client-side JavaScript (apart from a couple of compatibility tweaks) as Ruby Slate, so the output HTML should function exactly as in Ruby Slate.

[Ports of Slate](https://github.com/slatedocs/slate/wiki/Slate-Related-Tools) including to Node.js are nothing new and indeed my own [Shins](https://github.com/Mermade/shins) project has been tracking releases of Ruby Slate since late 2016, however, this technology preview is not based on Shins or any of the other outdated ports, and leverages `eleventy` to minimise the amount of custom code and dependencies required to build your documentation with Slate.

| Project | Top-Level Deps | Bundled JS Deps | Docker Image Size |
| --- | --- | --- | --- |
| Slate 2.7 | 8 | 5 | 482MB |
| Slate 3-tp0 | 9 | 2 | 176MB |
| Shins | 18 | 5 | 177MB |

The fact that three of our core client-side JS libraries can be included in the Node.js `package.json` dependencies makes the process of keeping them up to date much simpler. It also paves the way to potentially move the `lunr` search index generation to the server side, which would allow multi-page searches.

## The Future

It is important to be clear what the function of the technology preview is. It is primarily focused on getting feedback from the community. 

* We are **not** saying that Slate 2.7.0 will be the last release of Ruby Slate
* We are **not** saying that the next major version of Slate **will** be Node.js-based
* We are **not** saying that the next major version of Slate **will** be `eleventy`-based

We are saying that we recognise that the Ruby and `middleman` infrastructure used by Slate has historically caused the community, and maintainers, a good deal of headaches over the years.

We particularly want to hear your experiences of using the technology preview in these areas:

* Compatibility with Ruby Slate
* Any bugs found in building or the resultant HTML
* Operating system compatibility, particularly on Windows
* Should we symlink JS dependencies as now, or simply copy them?
* Should we mirror the Ruby Slate `source` directory structure or have a clean break?
* Ease of use
* Speed

In addition to the concrete areas above, we would welcome feedback on the adoption of `eleventy` itself; we note that the project is relatively young (circa two and a half years) and has not yet reached the milestone of a stable `v1.0.0` release. Also, `eleventy` has a fair number of [open issues](https://github.com/11ty/eleventy/issues) and this is with it using the [lodash style of issue management](https://twitter.com/samselikoff/status/991395669016436736) where enhancement requests and documentation change issues are closed, but still monitored. `eleventy` while not being one of the most well-known [static site generators](https://www.staticgen.com/), is actively maintained and it fits the requirements of supporting markdown and `ejs` templates while not including large unnecessary dependencies such as `React` or `Vue.js`, or being primarily focused on being a blog framework. We believe the Slate community could be beneficial to the `eleventy` community in terms of visibility and additional contributors. `eleventy` also has a well thought-out [plugin system](https://www.11ty.dev/docs/plugins/).

We know that the provided documentation is very bare-bones at the moment, but we would plan to copy over the remainder of the `README` and start the process of updating the Wiki if the technology preview warrants moving to the next phase.

One more thing to make clear, we **are** accepting Pull-Requests against the technology-preview branch, but these should be bug fixes and documentation improvements rather than new features at this stage.

Many thanks for reading, and we look forward to your feedback.