Skip to content


How I Brought the Power of CSS to Elixir

Avatar photo

Very Engineering Team

April 14, 2020
4 min read

Since it was first announced, Scenic has piqued the interest of the Elixir community. A native UI library written in Elixir with only one dependency – OpenGl – is such an exciting project that has captivated me. I have never considered myself a UI engineer, but Scenic approached UIs in such an “Elixir way” that I could not help myself.

When I dove in, my lack of experience writing Genservers was quickly realized, and at the same time, it finally made sense. So I started using text() an button() to render these things on a page.

Scenic is that easy. Give a button a size, color, and text, and there you have it.

Well, mostly.

First, to have to tell Scenic where to render your component. This is where we use Translate. (This is the actual {x, y} where you desire the component to render.)

So, now you have a button with size, color, text, and translate. This is where things can start to get hairy.

Let’s Talk About CSS

Seriously, let’s talk about it. As a web developer, I don’t know how to imagine the web without CSS, especially when it comes to layouts. Layouts are hard to get right even with all of the CSS tooling.

Over the last two years, I have spent an exceptional amount of time thinking about CSS and how it works. While I was not a great UI engineer, I know that CSS is powerful, albeit complex. But I needed to know how it worked. At its most basic, CSS is simple and straightforward – right?

Or is it? Is it simple, or have we just accepted the complexity?

Okay, now that I hopefully have you thinking existentially about CSS, let’s hop back to Scenic. “Translates,” again, are the way you put things on a screen with Scenic. As Scenic is not the web, it does not have CSS, therefore, placing things on a screen comes down to {x, y}. But I as a web dev want those to be programmatic. I really do not want to think about where every element goes on a screen. (That involves basic arithmetic, and I was told there would not be any math.)

I like to try to write things iteratively, so to start, I just want to put a thing up here, or over there. So, I guess I want CSS?

Well, I want some concepts of CSS, but do I actually want CSS? I definitely do not want the baggage, but I do want simple and familiar.

Thinking About Layouts

One night, as I was working on margins/padding and trying to remember which one does which, I called up a coworker to talk about it, as well to discuss some other ideas. As I was describing how I thought I needed to implement lots of these specific CSS features, we started discussing really what layouts are and what they set out to accomplish.

I do not believe we resolved the margin vs, padding question, but it did get me thinking. I sat with a notebook and just wrote out “Layouts,” then stared.

Eventually, more words appeared on the page:

Layouts programmatically put things somewhere.”

I went further to define “somewhere” as the top, bottom, left, right, and center. This seemed as simple as I could make it.

So, Scenic, in my opinion, could really use a layout engine. I mean…  how hard can that be?

What does a layout engine need to do? Position things. What are the possible positions? Top, bottom, left, right, center. That’s it. All we need to know now is the perspective of those positions.

That’s really it, right? Layouts are so easy! Okay, so what more might be nice? Columns? That gives us a good place to start.

Creating a Layout Library for Scenic

The above is the story of how I decided to create Layout-O-Matic, a layout library for Scenic. It incorporates both simple grids as well as complex. As my experience is specifically in web, I took all of my learnings from that domain. Ultimately, I set out to provide the most intuitive and simple API to help you “layout” your Scenic apps. The lessons learned here in API design deserve another post on how we can all be better.

The Layout-O-Matic has lots of sharp edges, but it is a starting point that took me on an engineering journey that resulted in confidence as a developer and a deeper knowledge of programming.

While I hope the library will be used, I, more importantly, hope it starts some conversations around how the community wants to use Scenic and how we want layouts to work. Do we want to start over? Will we suffer adoption if our API is not familiar? Do we want to adapt known and familiar APIs, or will we end up unhappy with continuing a pattern of frustration with the way things are?

Whatever we choose, it is exciting to have a framework like Scenic to get us thinking about the basics in all-new ways.

Looking for a development team that likes to dive deep into questions like these? Tell us about your project today