A Swift DSL for type-safe, extensible, and transformable HTML documents.
The popular choice for rendering HTML in Swift these days is to use templating languages, but they expose your application to runtime errors and invalid HTML. Our library prevents these runtime issues at compile-time by embedding HTML directly into Swiftâs powerful type system.
HTML documents can be created in a tree-like fashion, much like you might create a nested JSON document:
import Html
let document: Node = .document(
.html(
.body(
.h1("Welcome!"),
.p("Youâve found our site!")
)
)
)Underneath the hood these tag functions html, body, h1, etc., are just creating and nesting instances of a Node type, which is a simple Swift enum. Because Node is just a simple Swift type, we can transform it in all kinds of interesting ways. For a silly example, what if we wanted to remove all instances of exclamation marks from our document?
func unexclaim(_ node: Node) -> Node {
switch node {
case .comment:
// Don't need to transform HTML comments
return node
case .doctype:
// Don't need to transform doctypes
return node
case let .element(tag, attrs, children):
// Recursively transform all of the children of an element
return .element(tag, attrs, children.map(unexclaim))
case let .fragment(children):
// Recursively transform all of the children of a fragment
return .fragment(children.map(unexclaim))
case let .raw(string), .text(string):
// Transform text nodes by replacing exclamation marks with periods.
return string.replacingOccurrences(of: "!", with: ".")
}
}
unexclaim(document) // NodeOnce your document is created you can render it using the render function:
render(document)
// <!doctype html><html><body><h1>Welcome!</h1><p>Youâve found our site!</p></body></html>And of course you can first run the document through the unexlaim transformation, and then render it:
render(unexclaim(document))
// <!doctype html><html><body><h1>Welcome.</h1><p>Youâve found our site.</p></body></html>Now the document is very stern and serious đ.
Because we are embedding our DSL in Swift we can take advantage of some advanced Swift features to add an extra layer of safety when constructing HTML documents. For a simple example, we can strengthen many HTML APIs to force their true types rather than just relying on strings.
let imgTag = Node.img(attributes: [.src("cat.jpg"), .width(400), .height(300)])
render(imgTag)
// <img src="cat.jpg" width="400" height="300">Here the src attribute takes a string, but width and height take integers, as itâs invalid to put anything else in those attributes.
For a more advanced example, <li> tags can only be placed inside <ol> and <ul> tags, and we can represent this fact so that itâs impossible to construct an invalid document:
let listTag = Node.ul(
.li("Cat"),
.li("Dog"),
.li("Rabbit")
) // â
Compiles!
render(listTag)
// <ul><li>Cat</li><li>Dog</li><li>Rabbit</li></ul>
Node.div(
.li("Cat"),
.li("Dog"),
.li("Rabbit")
) // đ Compile errorThe core of the library is a single enum with 6 cases:
public enum Node {
case comment(String)
case doctype(String)
indirect case element(String, [(key: String, value: String?)], Node)
indirect case fragment([Node])
case raw(String)
case text(String)
}This type allows you to express every HTML document that can ever exist. However, using this type directly can be a little unwieldy, so we provide a bunch of helper functions for constructing every element and attribute from the entire HTML spec in a type-safe manner:
// Not using helper functions
Node.element("html", [], [
.element("body", [], [
.element("p", [], [.text("Youâve found our site!")])
])
])
// versus
// Using helper functions
Node.html(
.body(
.h1("Welcome!"),
.p("Youâve found our site!")
)
)This makes the âSwiftificationâ of an HTML document looks very similar to the original document.
Yes! We even provide plug-in libraries that reduce the friction of using this library with Kitura and Vapor. Find out more information at the following repos:
Templating languages are popular and easy to get started with, but they have many drawbacks:
-
Stringy APIs: Templating languages are always stringly typed because you provide your template as a big ole string, and then at runtime the values are interpolated and logic is executed. This means things we take for granted in Swift, like the compiler catching typos and type mismatches, will go unnoticed until you run the code.
-
Incomplete language: Templating languages are just that: programming languages. That means you should expect from these languages all of the niceties you get from other fully-fledged languages like Swift. That includes syntax highlighting, IDE autocompletion, static analysis, refactoring tools, breakpoints, debugger, and a whole slew of features that make Swift powerful like let-bindings, conditionals, loops and more. However, the reality is that no templating language supports all of these features.
-
Rigid: Templating languages are rigid in that they do not allow the types of compositions and transformations we are used to performing on data structures in Swift. It is not possible to succinctly traverse over the documents you build, and inspect or transform the nodes you visit. This capability has many applications, such as being able to pretty print or minify your HTML output, or writing a transformation that allows you to inline a CSS stylesheet into an HTML node. There are entire worlds closed off to you due to how templating languages work.
The DSL in this library fixes all of these problems, and opens up doors that are completely closed to templating languages.
There are a few reasons you might want to still use a templating language:
-
A designer delivers a large HTML document to you and all you want to do is hook in a little bit of value interpolation or logic. In this case you can simply copy and paste that HTML into your template, add a few interpolation tokens, and you're well on your way to having a full page served from your web application.
-
You need to render non-HTML documents. The beauty of templating languages is that it outputs straight to plain text, and so it can model any type of document, whether it be HTML, markdown, XML, RSS, ATOM, LaTeX, and more.
-
Creating very large documents in a single expression can cause compile times to go up, whereas templates are not compiled by Swift and so do not influence compile times. Luckily this isn't a problem too often because it is very easy to break up a document into as many small pieces as you want, which will probably lead to more reusable code in the long run.
If you do decide that a templating language better suites your needs, then you should consider HypertextLiteral, which gives you template-like capabilities but in a safer manner.
If you use Carthage, you can add the following dependency to your Cartfile:
github "pointfreeco/swift-html" ~> 0.3If your project uses CocoaPods, just add the following to your Podfile:
pod 'Html', '~> 0.3'
# SnapshotTesting helpers
pod 'HtmlSnapshotTesting', '~> 0.3'If you want to use swift-html in a project that uses SwiftPM, it's as simple as adding a dependencies clause to your Package.swift:
dependencies: [
.package(url: "https://github.com/pointfreeco/swift-html.git", from: "0.3.0")
]From there you can add Html or HtmlSnapshotTesting as target dependencies.
Submodule, clone, or download swift-html, and drag Html.xcodeproj into your project.
These concepts (and more) are explored thoroughly in a series of episodes on Point-Free, a video series exploring functional programming and Swift hosted by Brandon Williams and Stephen Celis.
The ideas for this library were explored in the following episodes:
- Episode 26: Domain Specific Languages: Part 1
- Episode 27: Domain Specific Languages: Part 2
- Episode 28: An HTML DSL
- Episode 29: đ DSLs vs. Templating Languages
All modules are released under the MIT license. See LICENSE for details.