Site looks correct...

docs/01-installation/directory.conf

@@ -0,0 +1 @@
+laika.title = "Setup & Configuration"

docs/installation/_index.md → docs/01-installation/quickstart.md

@@ -1,8 +1,4 @@
-+++
-title = "Setup & Configuration"
-menuTitle = "Installation"
-weight = 1
-+++
+# Installation
 
 ## Quick Setup with Giter8
 

docs/guides/bundling.md → docs/02-guides/bundling.md

@@ -1,7 +1,4 @@
----
-title: "Building & Bundling"
-menuTitle: "Bundling"
----
+# Building & Bundling
 
 The JavaScript community don't like to use the word 'compiler', but tools that gather, parse, and link source files into deployable 'bundles' are an essential part of modern web app development.
 

docs/guides/cmd.md → docs/02-guides/cmd.md

@@ -1,9 +1,4 @@
----
-title: "Commands & Effects"
-menuTitle: "Commands"
----
-
-## Commands
+# Commands & Effects
 
 Using Tyrian, you can get a long way with nothing more than a model, a view, and some messages being pumped around their endless one-way circuit.
 
@@ -18,7 +13,7 @@ These kinds of actions are called 'side-effects', and are an extremely popular t
 
 Luckily, Tyrian has a pretty elegant solution for this.
 
-### Monadic effect handling
+## Monadic effect handling
 
 > You can skip this bit of context if you like. This section has a bit of jargon in it for those who care about such things, but it's really not important if you just want to know how to use commands.
 
@@ -30,7 +25,7 @@ This is _exactly_ what a command (`Cmd`) does. While commands themselves are onl
 
 So far, this is sounding like effect handling as usual. But no. Primarily because you rarely actually see the underlying effect type.
 
-### Making things happen
+## Making things happen
 
 Commands take the form `Cmd[IO, Msg]` (`IO` is used for illustrative purposes) which is to say that they represent some sort of side effect that can produce a message to be cleanly fed back into your single page application's `updateModel` function.
 

docs/02-guides/directory.conf

@@ -0,0 +1 @@
+laika.title = "Guides"

docs/guides/goodies.md → docs/02-guides/goodies.md

@@ -1,7 +1,4 @@
----
-title: "Built-in Goodies"
-menuTitle: "Goodies"
----
+# "Built-in Goodies"
 
 Tyrian comes with a number of handy functions built-in that you can make use of and explore:
 

docs/guides/guided-tour.md → docs/02-guides/guided-tour.md

@@ -1,7 +1,4 @@
----
-title: "A Guided Example"
-menuTitle: "Guided Example"
----
+# Guided Example
 
 The normal use case for Tyrian is to build a Single Page App/Application (SPA). You can also use Tyrian for Server-side Rendering (SSR), but this page will focus on SPAs.
 

docs/guides/html.md → docs/02-guides/html.md

@@ -1,7 +1,4 @@
----
-title: "Rendering HTML"
-menuTitle: "Rendering HTML"
----
+# Rendering HTML
 
 ## HTML syntax
 

docs/guides/networking.md → docs/02-guides/networking.md

@@ -1,6 +1,4 @@
----
-title: "Networking"
----
+# Networking
 
 Out of the box, Tyrian supports two flavors of networking, [HTTP and Web Sockets](https://github.com/PurpleKingdomGames/tyrian/tree/main/examples), and we have examples you can run of both. Please see the instructions in the README file.
 

docs/guides/routing.md → docs/02-guides/routing.md

@@ -1,9 +1,4 @@
----
-title: "Frontend Routing"
-menuTitle: "Frontend Routing"
----
-
-## Frontend Routing
+# Frontend Routing
 
 All Tyrian apps need to implement a routing function:
 

docs/guides/ssr.md → docs/02-guides/ssr.md

@@ -1,9 +1,6 @@
----
-title: "Server-side Rendering (SSR)"
-menuTitle: "Server-side Rendering"
----
+# Server-side Rendering
 
-## What is server-side rendering?
+## What is server-side rendering? (SSR)
 
 These days, a normal straight-forward relationship between a frontend client and some sort of backend service, is that the client makes an HTTP request to the service, and receives some data back that it uses to render a page/view for the user. But it wasn't always so!
 

docs/guides/subs.md → docs/02-guides/subs.md

@@ -1,8 +1,6 @@
----
-title: "Subscriptions"
----
+# Subscriptions
 
-## Subscriptions: A notification of change
+## A notification of change
 
 Subscriptions (`Sub`s) are used to observe something that changes over time, and to emit discrete messages when something happens.
 

docs/guides/tyrian-indigo-bridge.md → docs/02-guides/tyrian-indigo-bridge.md

@@ -1,7 +1,4 @@
----
-title: "Tyrian-Indigo Bridge"
-menuTitle: "Tyrian + Indigo "
----
+# Tyrian-Indigo Bridge
 
 What if you wanted to make a web game (or an Electron desktop game - why not!), where the main game window was rendered in WebGL, but the UI elements were all in lovely, responsive, scalable HTML5?
 

docs/03-architecture/directory.conf

@@ -0,0 +1 @@
+laika.title = "Architecture"

docs/03-architecture/the-elm-architecture.md

@@ -0,0 +1,25 @@
+# The Elm Architecture
+
+Tyrian provides a runtime environment for executing applications that was originally designed according to the [Elm architecture](https://guide.elm-lang.org/architecture/).
+
+Elm is the name of a language and an ecosystem, but it's architecture has become more widely known as the 'TEA Pattern' (_(**T**)he (**E**)lm (**A**)rchitecture_) and has influenced many GUI/UI libraries and implementations beyond the world of functional programming.
+
+## The TEA pattern
+
+The TEA Pattern is about:
+
+1. Immutable data.
+2. Pure functions.
+3. Uni-directional data flow.
+4. Strictly ordered events and updates.
+
+This gives you a system that is very easy to reason about, since the data cannot (or is unlikely to) be subject to hard-to-test race conditions or side effects, and everything happens in a predictable order.
+
+The purity of the system, the way that the state is held apart from the processing and rendering functions, also allows for easy testing without the need for complex mocking.
+
+In essence:
+
+- The state of the application is modeled by an immutable `Model`.
+- Events that change the state of the application are modeled by an immutable `Msg` type.
+- State transitions are implemented by a `(Msg, Model) => Model` function.
+- Finally, a `Model => Html[Msg]` function defines how to render the state of the application in HTML.

docs/architecture/_index.md → docs/03-architecture/tyrian-and-indigo.md

@@ -1,58 +1,4 @@
-+++
-title = "Architecture & Patterns"
-menuTitle = "Architecture"
-weight = 2
-+++
-
-## The Elm Architecture
-
-Tyrian provides a runtime environment for executing applications that was originally designed according to the [Elm architecture](https://guide.elm-lang.org/architecture/).
-
-Elm is the name of a language and an ecosystem, but it's architecture has become more widely known as the 'TEA Pattern' (_(**T**)he (**E**)lm (**A**)rchitecture_) and has influenced many GUI/UI libraries and implementations beyond the world of functional programming.
-
-### The TEA pattern
-
-The TEA Pattern is about:
-
-1. Immutable data.
-2. Pure functions.
-3. Uni-directional data flow.
-4. Strictly ordered events and updates.
-
-This gives you a system that is very easy to reason about, since the data cannot (or is unlikely to) be subject to hard-to-test race conditions or side effects, and everything happens in a predictable order.
-
-The purity of the system, the way that the state is held apart from the processing and rendering functions, also allows for easy testing without the need for complex mocking.
-
-In essence:
-
-- The state of the application is modeled by an immutable `Model`.
-- Events that change the state of the application are modeled by an immutable `Msg` type.
-- State transitions are implemented by a `(Msg, Model) => Model` function.
-- Finally, a `Model => Html[Msg]` function defines how to render the state of the application in HTML.
-
-## Tyrian vs Elm
-
-As you might expect, Elm is a far richer offering that Tyrian is now, and in all likelihood ever will be. It's been around a lot longer, and there are a lot more people working on and with Elm every day feeding into it's design.
-
-Having said that: While Elm's architecture has taken on a life of it's own and influenced the state of the art of functional (and even non-FP!) UI programming, Elm itself has remained somewhat niche.
-
-People tend to love Elm ...or hate it. A lot of that reaction can be attributed to the fact that Elm is a very opinionated language, and you either like that or you do not.
-
-What Elm's opinionated stance buys you is an ecosystem where if your code compiles, it works! And that is an amazing thing! In the cost/benefit analysis: The benefit is an incredibly robust web development experience, at the cost of literally not being able to do anything that is not permitted (because it would break the robustness guarantees of the ecosystem).
-
-Tyrian takes the glorious essence of Elm's architecture, but removes almost all of the opinions ...and with it of course, almost all of the safety nets!
-
-- Want to break up your code into lots of files and classes? Carry on.
-- Want to use refined types? Ok then.
-- Want to use Typeclasses? No problem.
-- Want to bring in a heavyweight FP library? Sure thing.
-- Want to talk to JavaScript directly over an FFI? Go nuts.
-- Want to do a non-exhaustive match? I mean, you can but...
-- Want to throw a massive exception? ...erm ...sure...
-
-Be safe out there folks! 😀
-
-## Tyrian & Indigo
+# Tyrian & Indigo
 
 Tyrian and [Indigo](https://indigoengine.io/) are siblings and both follow an interpretation of the TEA Pattern, but they grew up at different times under different influences, and so they are not exactly the same in their design.
 

docs/03-architecture/tyrian-vs-elm.md

@@ -0,0 +1,21 @@
+# Tyrian vs Elm
+
+As you might expect, Elm is a far richer offering that Tyrian is now, and in all likelihood ever will be. It's been around a lot longer, and there are a lot more people working on and with Elm every day feeding into it's design.
+
+Having said that: While Elm's architecture has taken on a life of it's own and influenced the state of the art of functional (and even non-FP!) UI programming, Elm itself has remained somewhat niche.
+
+People tend to love Elm ...or hate it. A lot of that reaction can be attributed to the fact that Elm is a very opinionated language, and you either like that or you do not.
+
+What Elm's opinionated stance buys you is an ecosystem where if your code compiles, it works! And that is an amazing thing! In the cost/benefit analysis: The benefit is an incredibly robust web development experience, at the cost of literally not being able to do anything that is not permitted (because it would break the robustness guarantees of the ecosystem).
+
+Tyrian takes the glorious essence of Elm's architecture, but removes almost all of the opinions ...and with it of course, almost all of the safety nets!
+
+- Want to break up your code into lots of files and classes? Carry on.
+- Want to use refined types? Ok then.
+- Want to use Typeclasses? No problem.
+- Want to bring in a heavyweight FP library? Sure thing.
+- Want to talk to JavaScript directly over an FFI? Go nuts.
+- Want to do a non-exhaustive match? I mean, you can but...
+- Want to throw a massive exception? ...erm ...sure...
+
+Be safe out there folks! 😀

docs/04-examples/directory.conf

@@ -0,0 +1 @@
+laika.title = "Examples"

docs/examples/_index.md → docs/04-examples/examples.md

@@ -1,9 +1,3 @@
-+++
-title = "Examples"
-menuTitle = "Examples"
-weight = 3
-+++
-
-## Examples
+# Examples
 
 We have a number of examples to help you get started with Tyrian, instructions on how to run them can be found in the [README file under the examples folder in the repo](https://github.com/PurpleKingdomGames/tyrian/tree/main/examples).

docs/05-information/directory.conf

@@ -0,0 +1 @@
+laika.title = "Information & Trivia"

docs/05-information/discussion.md

@@ -0,0 +1,17 @@
+# Discussion
+
+If you're new to the territory, we highly recommend [this thoughtful blog post](https://dev.to/raquo/my-four-year-quest-for-perfect-scala-js-ui-development-b9a) by [Laminar](https://laminar.dev/)'s author, Nikita Gazarov.
+
+There is a point in that post where Nikita says the following:
+
+> (..) and having now walked the path myself I finally understood exactly what that reason was: functional reactive programming (FRP) and virtual DOM don't mix!
+> 
+> Virtual DOM and FRP solve the exact same problem – efficiently keeping the rendered DOM in sync with application state – but they approach it from entirely opposite directions (..)
+
+Quite right too. It's an important fork in the road. One direction takes you to FRP (and Laminar or [Calico](https://www.armanbilge.com/calico/)), the other to Virtual DOM like Tyrian and Elm. Both are equally valid choices with quite subtle trade-offs.
+
+Broadly the argument for FRP is speed, as updates are minimal and precise. The argument for Virtual DOM is that it's easier to test and reason about.
+
+However, You don't have to look hard to find counter arguments to both positions: Elm is blazing fast, and Laminar has solved the classic diamond problem. ...but that's the general argument.
+
+In the end, it's mostly personal preference.

docs/05-information/provenance.md

@@ -0,0 +1,17 @@
+# Provenance & Thanks
+
+Tyrian was originally a fork of [Scalm](https://github.com/julienrf/scalm) by [Julien Richard-Foy](https://github.com/julienrf).
+
+Scalm was the Scala.js library I'd been looking for but found too late - and it's great fun! In my opinion it was simply ahead of its time, and alas the original authors and contributors had moved on to pastures new long before it was brought to my attention.
+
+Scalm was forked and re-released under a new name and license (with the original authors blessing), partly because I wanted to take it in my own direction without corrupting the original work, and partly ...because I just wasn't sure how to pronounce Scalm! (I did ask.)
+
+Scalm/Tyrian and [Indigo](https://github.com/PurpleKingdomGames/indigo) (which I also look after) are kindred spirits, in that they both follow the TEA pattern (The Elm Architecture), which is the only frontend architecture pattern I'm interested in these days.
+
+I hope to use Tyrian to complement Indigo, and so have brought it in under the same organisation.
+
+Tyrian is Scalm with the cobwebs blown off. All it's libraries are up to date, I've started expanding the API, and it will only ever be released against Scala 3 (and beyond!).
+
+With huge thanks to the original authors,
+
+Dave, 5th June 2021

docs/05-information/tyrian-purple.md

@@ -0,0 +1,7 @@
+# Tyrian Purple
+
+> "It took tens of thousands of desiccated hypobranchial glands, wrenched from the calcified coils of spiny murex sea snails before being dried and boiled, to colour even a single small swatch of fabric, whose fibres, long after staining, retained the stench of the invertebrate's marine excretions. Unlike other textile colours, whose lustre faded rapidly, Tyrian purple ... only intensified with weathering and wear – a miraculous quality that commanded an exorbitant price, exceeding the pigment's weight in precious metals." ~ [BBC](https://www.bbc.com/culture/article/20180801-tyrian-purple-the-regal-colour-taken-from-mollusc-mucus)
+
+So it's a purple dye that smells of where it came from and gets richer over time with use.
+
+Perfect.

docs/README.md

@@ -0,0 +1,37 @@
+# Tyrian
+
+Tyrian is an Elm-inspired, purely functional UI library for Scala 3.
+
+Its purpose is to make building interactive websites in Scala 3 fun! Tyrian allows you to describe web pages and complex interactions in a way that is elegant, easy to read and easy to reason about.
+
+Tyrian is not designed to work alone, the intention is that you will use it alongside a web bundler to look after things like your media assets and stylesheets. (All our examples use [Parcel](https://parceljs.org/).)
+
+## Tyrian 💜's Indigo
+
+Tyrian is by the maintainers of [Indigo](https://indigoengine.io/), a Scala 3 game engine. As such, Indigo web games are first class citizens in Tyrian, allowing easy embedding and seamless communication between their respective event/messaging systems.
+
+## When should I consider using Tyrian?
+
+Tyrian is designed for building SPAs (Single Page Applications): Web pages with lots of interactive elements.
+
+One use case we're particularly excited about is augmenting Indigo games with rich HTML UI elements.
+
+You can also use Tyrian to do Server-side Rendering (SSR) in conjunction with your favorite Scala HTTP framework in place of, say, a templating library.
+
+## What should I avoid using Tyrian for?
+
+Tyrian is not a great candidate for static websites - like this one! - where the content is there to be read, not interacted / played / engaged with.
+
+## Why shouldn't I just use some Scala.js-React-based-thingy instead?
+
+You can! Quite frankly, you probably should!
+
+In fact there are a good number of Scala.js alternatives to Tyrian, such as [Outwatch](https://github.com/outwatch/outwatch), [scalajs-react](https://github.com/japgolly/scalajs-react), [Slinky](https://slinky.dev/), and [Laminar](https://laminar.dev/) to name a few.
+
+React in particular is an industry standard framework these days, and so there are lots and lots of resources out there to help you use it. In that regard at least, React (via Slinky or scalajs-react) is probably a good choice for beginners.
+
+Functional programmers may be more into something like Laminar, which is based on Functional Reactive Programming (FRP). Laminar looks to be well made and well maintained, and there are some great talks out there about it.
+
+Tyrian works fundamentally differently to those other frameworks. In the authors very opinionated opinion: The Elm Architecture upon which it is based, is the most productive, fun, and _sane_ frontend architectural approach there is.
+
+This library exists because we don't want to work any other way. We encourage you to try a few different approaches and decide what works best for you. 😊