A long long time ago, web development was pretty much a single discipline where any developer would work throughout their stack. Most would be armed with a backend language or framework, HTML and CSS, with a sprinkle of JavaScript.

Then the demands for richer and richer user interactions in web applications pushed us in a very different direction. Front-end development became its own discipline and a bunch of new technologies emerged.

The front-end framework overload

On a semi-regular schedule, backend specialists would read news about the latest and greatest frontend framework / metaframework / library and increasingly channel their inner Brenda from Bristol shouting "You're joking! Not another one!"

Something broke in the community of folks that have long identified as full-stack web developers, and the quest for a different model started. The mission: find a technology based on a single programming language to drive the backend business logic and frontend user interaction.

The pendulum shifts again

After some toying with isomorphic apps, two paradigms emerged that allow full-stack developers to take back control of their stacks:

1. React everywhere, such as Next.js and Remix
2. Backend-driven frontend, such as Phoenix LiveView (LiveView) and htmx

Enter LiveView

LiveView is built on top of the Phoenix web framework, and leverages some interesting features of Elixir — the language it's written in — along with Erlang and its virtual machine, the BEAM. Its model inspired similar frameworks: HotWire in the Ruby/Rails world, LiveWire in PHP and Laravel.

Some big users of LiveView are cars.com and Fly.io (who as of October 2024 employs Chris McCord, the author of Phoenix and LiveView).

How does LiveView work

Let's have a look at what happens when a user hits a LiveView enabled page.

You can follow along and admire my web design skills by having a look at a very simple example app I wrote and its source code.

Check it out

Step 1: Initial render

The first request-response cycle is the same you'd encounter with any classic web framework. The user asks for an HTTP resource, the server stitches together some HTML and ships it back to the browser.

This enables the page to be fully rendered no matter what comes next, which has nice properties for search engines (and any other manner of dodgy crawler… I'm looking at you, LLMs trainer bots) and can enable some basic usage even on bad network or low bandwidth conditions. Y’know, progressive enhancement.

The dynamic content gets handled in the same way by both the initial render and the LiveView first render:

<div>
  Count: <%= @count %>
</div>

Source

In the Phoenix parlance, @count is called an "assign". It gets calculated in the mount function and injected in the template:

def mount(_params, _session, socket) do
  {:ok, socket |> assign(:count, 0)}
end

Source

In this case, count is the integer 0, but assigns can be any valid data structure: a list, a map, a struct… The sky’s the limit. Well, the sky, and your server’s RAM.

Step 2: The View becomes Live

The page that gets delivered has a sprinkle of JS: most importantly, it carries the code to request a WebSocket connection to the server. The HTML gets re-rendered and a "process" — such as a lightweight thread — starts on the server to store the current state of the view the user is engaging with. For all intents and purposes, the app is now stateful.

Depending on the complexity of such processes, Elixir can handle a lot of them on a single machine, fairly efficiently. It takes a lot of beating before the user experience is actually degradated thanks to the BEAM’s scheduler.

Step 3: The reactive cycle begins

How does the app becomes interactive? By providing bindings on the page. For example, a DOM element with the phx-click="increment" HTML attribute informs the small JavaScript library to push the increment event up the WebSocket whenever it's clicked.

<div>
  <button type="button" phx-click="increment">+</button>

  <button type="button" phx-click="decrement">-</button>
</div>

Source

The LiveView then handles the event, and adds 1 to the count.

def handle_event("increment", _, socket) do
  count = socket.assigns[:count]

  {:noreply, socket |> assign(:count, count + 1)}
end

Source

If the state causes the rendering to change — which will happen in this case as the assign @count will change — the LiveView process pushes the relevant, minimal diffs back to the browser via the WebSocket. Here's an example from the network inspector:

up:
["4","13","lv:phx-F_lyW6ngKkiixRwB","event",{"type":"click","event":"increment","value":{"value":""}}]

down:
["4","13","lv:phx-F_lyW6ngKkiixRwB","phx_reply",{"status":"ok","response":{"diff":{"1":{"0":"1"}}}}]

In this case {"diff":{"1":{"0":"1"}}} tells the client JavaScript library to replace the slot 0 (the <%= @count %> tag we saw above) with just the content 1. Obviously more complex apps will pass more complex diffs, but the basics are the same.

The JavaScript library then updates the DOM, and now we're ready for the next event to trigger.

What else does it do

On-browser commands

LiveView.JS module allows you to write simple but extensive browser-based CSS manipulations without the need of a roundtrip over the web socket. Hiding and showing DOM elements or toggling classes is trivial and can be still controlled without writing a single line of JavaScript.

A lot of heavy lifting for you

Think of a React app: you need to stitch your frontend and backend together with a bunch of things to make it work, like auth, an API layer, a separate build pipeline, ideally some tests. LiveView takes away all the glue work, and you can focus on delivering features instead.

Session tracking across the cluster

One of the most interesting aspects of using the BEAM, is that you can cluster all your servers together and allow module calls across them. This is referred in the community as Distributed Erlang. If you do build such cluster, and a user's session gets lost and then reconnected with a different server, the new server can fetch the state from the previous one.

Wrapping up

LiveView can empower developers to create rich apps by focusing on a single programming language and a single framework (or a framework and a half, more realistically, if we count both Phoenix and LiveView). With LiveView, you can cut down on a lot of glue work, and it supports progressive enhancement where useful: if you need a non-JavaScript fallback, you can build a non-LiveView, traditional View-Controller route in Phoenix.

It’s not all unicorns and flowers though. While LiveView's approach works for the vast majority of simple apps, something like Google Maps is too complex for it to handle. Similarly, offline support is out of the question. Lastly, LiveView is extremely niche compared to React; the resources available are proportionally scarce.

A glimpse of simplicity

I hope this gave you an overview on what happens in some dark corners of the web that aren’t following the herd that brought us the current set of mainstream unwieldy technologies. I’m increasingly optimistic about the direction web frameworks are taking in terms of productivity and I’m excited about the industry adoption of these new patterns.

I’m not going to spend ages explaining what Markdown is or how it works because there’s already great resources for that. Instead, I’m going to break down the most important aspects of Markdown with quick and easy snippets so you can start composing great content!

Headings

Markdown enables you to to compose HTML heading elements by using a # character as a prefix. All you need to remember is that the number of #’s as a prefix represents the heading level.

For example, if you want a <h1> element, you add one #:

# I am a heading level 1

If you want a <h3> element, you add three #’s:

### I am a heading level 3 

See the Pen Markdown headings by Andy Bell (@piccalilli) on CodePen.

Paragraphs

To create a <p> — which is a paragraph element — add a new line between sections of text. Make sure you press Enter without holding down the shift key.

This is a paragraph of text which can contain as many words as you like.

This is another paragraph of text, seperated with a new line. You don’t have to do anything else other than create a new line between paragraphs. 

See the Pen Markdown paragraphs by Andy Bell (@piccalilli) on CodePen.

Bold text

To make text bold, wrap it in ** characters on each side of the text like so:

This is some text with **a section of bold content**. 

See the Pen Markdown bold text by Andy Bell (@piccalilli) on CodePen.

Italic/emphasised text

This is very similar to making text bold. Instead of two * characters, you only use one for italic/emphasised text.

This is some text with a *section of italic text*.

This is some text with a _section of italic text_.

See the Pen Markdown italic text by Andy Bell (@piccalilli) on CodePen.

Strikethrough/deleted text

To apply a strikethrough to your text, Markdown allows you to generate a <del> tag by wrapping it in ~~, like so:

A paragraph with some ~~strikethrough text~~.

See the Pen Markdown strikethrough/deleted text by Andy Bell (@piccalilli) on CodePen.

Links

To apply a link, wrap the text in square brackets. That’s starting with an [ character and finishing with a ] character. This should then be immediately followed with the URL you want to link to in parentheses — also known as round brackets ().

For example, let’s say I want to create a link to the BBC:

[The BBC](https://www.bbc.co.uk/) is a public service broadcaster in the UK. 

Markdown can also automatically wrap URLs in links for you too. Say for example, you wanted to write https://www.bbc.co.uk that links to https://www.bbc.co.uk, wrap the link in an opening < and closing > like so:

Visit <https://www.bbc.co.uk> for more info.

See the Pen Markdown links by Andy Bell (@piccalilli) on CodePen.

Images

Embedding an image with an <img> element is very similar to links. The only difference is the square brackets contain the alternative text and the parentheses contains a URL to the image. You also need to add a ! character as a prefix to the square brackets:

![A 'subscribe' button appears to sit on top of an email input which has a placeholder value of 'name@example.com'. The form is labelled 'Enter your email to sign up for our newsletter'](https://piccalil.b-cdn.net/images/blog/floating-signup-form-pattern.jpg)

See the Pen Markdown images by Andy Bell (@piccalilli) on CodePen.

Blockquotes

For every line of your blockquote (<blockquote>) — including new lines — use a > character as the prefix.

For example, this is a one line blockquote:

> This is a one line quote

And this is multiple lines:

> This is a quote that is broken into multiple lines 
> 
> Notice how the line above is just a > character. This allows the Markdown processor to put both lines of the quote in the same `<blockquote>` element

See the Pen Markdown blockquotes by Andy Bell (@piccalilli) on CodePen.

Horizontal rule

You can apply a horizontal rule with three asterisks (***), three hashes (---) or three underscores (___).

See the Pen Markdown horizontal rule by Andy Bell (@piccalilli) on CodePen.

Inline code

You might have noticed in the blockquotes example we were using the ` character. Wrapping text in these characters renders them in a <code> element.

If you want space between elements in CSS, use the `margin` property.

See the Pen Markdown inline code by Andy Bell (@piccalilli) on CodePen.

Code blocks

You can also generate multiline code blocks by adding ``` on the line before your text and ``` on the line after your text like so:

```
Some preformatted text. 

On multiple lines.
```

See the Pen Markdown code blocks by Andy Bell (@piccalilli) on CodePen.

```html

```

```css

```

Lists

You can compose ordered (<ol>) and unordered lists (<ul>) with Markdown.

If you want to compose an ordered list, start each line with a number, followed by a dot, like so:

1. I am list item one
2. I am list item two
3. I am list item three
4. I am list item four

You can also use the same number each time:

1. I am list item one
1. I am list item two
1. I am list item three
1. I am list item four

To generate an ordered list, start each line with a -:

- I am list item one
- I am list item two
- I am list item three
- I am list item four

Lastly, you can nest list items like so:

- I am list item one
  - I am another list inside list item one
- I am list item two
  1. I am an ordered list, nested in an unordered list
  1. Notice how I can still use 1. on every item too
- I am list item three
- I am list item four

See the Pen Markdown lists by Andy Bell (@piccalilli) on CodePen.

HTML elements are supported too

Lastly, you can write good ol’ fashioned HTML in Markdown! For example, you could compose a table with Markdown, but maintaining that would be a nightmare.

An easier way is to render a HTML table element instead:

## A level 2 heading 

Some paragraph text with *emphasis* and **bold**. 

<table>
  <thead>
    <tr>
      <th>Month</th>
      <th>Savings</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>January</td>
      <td>$250</td>
    </tr>
    <tr>
      <td>February</td>
      <td>$80</td>
    </tr>
    <tr>
      <td>March</td>
      <td>$420</td>
    </tr>
  </tbody>
</table>

See the Pen Markdown HTML elements by Andy Bell (@piccalilli) on CodePen.

<p>If I add **bold text, it will not work**.</p>

Wrapping up

We’ve only just scratched the surface with Markdown here, but that level of knowledge should support the vast majority of people wanting to work with Markdown in their content.

Learning Markdown has so many benefits too. It’ll make you more efficient in Notion, Slack and Trello to name just a few services that support Markdown syntax.

You can go much deeper by reading up on the following links, but if you’ve been sent this link as a quick reference, just keep enjoying the simple — yet powerful — benefits of Markdown!

Further reading

• Extended Markdown syntax
• MDX. MDX powers this and all posts on Piccalilli!
• Mastering Markdown. A free 10 part video course by Wes Bos.
• A comparison of syntax extensions in Markdown flavors
• A more comprehensive guide

Playground

Thanks to our friends at CodePen — who's pen editor supports markdown — here's a handy, editable playground that you can practice what you’ve learned in this guide.

See the Pen Markdown playground by Andy Bell (@piccalilli) on CodePen.

Design tokens, explained by the creator

I always reference this quote by Jina, who created design tokens, while they were working on the legendary Lightning Design System:

“Design Tokens are the visual atoms of the design system – specifically, they are named entities that store visual design attributes. We use them in place of hard–coded values in order to maintain a scalable and consistent visual system.”

It was Jina’s work on this that enabled me to communicate to the team I was in at the time about how I wanted to work on our multi-platform system. I called it a “style guide” at the time—thanks to my background in more traditional print design—but Design System with Design Tokens made much more sense.

Design tokens, explained by me

Let’s say your company has a website, an iPhone app and several printed brochures of information. For everything brand-related you use a style guide—that’s pretty darn standard, but that style guide is often a PDF with loads of information that doesn’t mean much to a developer.

That style guide will contain information such as brand colours, typography and how to use the logo—to name just a few examples—but getting that information to technical people who are not well versed in reading style guides could be very risky.

This is where design tokens become really useful because in essence, they are centralised data—almost like a database of design values—that could be consumed by anything that understands a standard, like JSON.

Here, let me show you how design tokens can look when they are in a standard data format, JSON:

{
  "colors": {
    "dark": "#121111",
    "light": "#f8f8f8",
    "primary": "#fdd110",
    "secondary": "#ea1c5c",
    "secondary-shade": "#da0044",
    "tertiary": "#55dde0"
  },
  "fonts": {
    "base": "Helvetica Neue",
    "serif": "Georgia"
  },
  "sizes": {
    "300": 10,
    "400": 16,
    "500": 20,
    "600": 25,
    "700": 31,
    "800": 39,
    "900": 48
  }
}

Here, the design tokens reference colours, fonts and a size scale. The colours are hex values and the size scale refers to pixel values.

This data would need to be translated per platform. For example: for print, you might need to translate those pixels into points and the hex values to CMYK values. For web, you would probably want to change the pixels to responsive units, like rems or ems, but that’s cool because there’s plenty of tools to do those sorts of translations. The important thing is that we have a centralised structure of definitions that can be used, cross-platform.

Here’s an example of the output if that JSON is converted into Sass:

$colors: (
  'dark': #121111,
  'light': #f8f8f8,
  'primary': #fdd110,
  'secondary': #ea1c5c,
  'secondary-shade': #da0044,
  'tertiary': #55dde0
);

$fonts: (
  'base': '"Helvetica Neue"',
  'serif': 'Georgia'
);

$size-scale: (
  '300': 0.63rem,
  '400': 1rem,
  '500': 1.25rem,
  '600': 1.56rem,
  '700': 1.94rem,
  '800': 2.44rem,
  '900': 3rem
);

Maintaining tokens

We’ve had a look at what the output of design tokens can be, but how are they maintained? As with anything in design and tech: it depends.

Tools such as Figma and Sketch offer a few options when it comes to design tokens. With Figma, there’s plugins such as Figgo which help convert static design tokens into more useful data that developers can use.

With Sketch, you can use plugins such as the handily named, Design Tokens Plugin.

More technical tools include Theo, by the Salesforce team, which is a popular choice amongst large design systems. There’s also tools such as Style Dictionary, which again, suits larger systems. Heck, you can even maintain design tokens with a handy Google Sheet and Theo.

There’s promising looking tools such as Arcade by the fine folks (and design systems experts) at SuperFriendly, too.

It would also be daft of me to not feature my own tools, Gorko and Goron which turn design token data into CSS and/or SCSS.

Wrapping up

I hope this quick explainer of what design tokens are helps you to understand them more.

I’d also urge you to read this article on CSS-Tricks, look through this speaker deck by Stu Robson and finally, watch this video with the creator of design tokens themselves, Jina, and a colleague.

Until next time, Take it easy 👋