Elements with Chris Mather

Episode Description

Chris Mather introduces Elements, a full-stack TypeScript app framework and build tool he spent years developing behind closed doors at a healthcare fintech startup.

Episode Summary

Chris Mather joins the show to discuss Elements, an ambitious app framework and build tool for TypeScript that he designed over several years while serving as CTO of a YC-backed healthcare fintech company. Rather than assembling existing open-source libraries, Chris built most of the stack himself—including a Go-powered build tool, a package manager, and a forthcoming UI language—driven by the philosophy that developer experience should be the North Star. He traces his journey from government programming and a stint at Microsoft through Silicon Valley startups and a four-year detour making educational content, explaining how each experience shaped his approach. The conversation covers how Elements combines server-side and client-side rendering to deliver fast initial loads and seamless in-browser navigation, how service functions replace traditional API layers with simple importable functions, and why Chris favors raw SQL and Postgres over ORMs. He draws lessons from Meteor's mistakes around ecosystem compatibility and from Rails' famous simplicity demo, arguing that a framework should ship with batteries included—routing, authentication, database tooling—so developers aren't hunting for wheels to put on their car. The episode closes with the origin of the name Elements, inspired by Euclid's foundational mathematical text, and an invitation for developers to try the alpha at Elements.dev.

Chapters

00:00:00 - Meet Chris Mather and the Origins of Elements

The episode opens with Anthony Campolo explaining how Elements landed on the show's radar through a Discord recommendation and a JavaScript Jabber appearance. Chris introduces himself as a lifelong builder whose career started in U.S. government programming during high school, passed through Microsoft and intelligence contracting, and eventually led to Silicon Valley startups and a CTO role at a YC-backed healthcare fintech company.

Chris describes the unusual path that led to Elements: after years of sketching out grammars, UI concepts, and language designs in notebooks, he negotiated with his startup cofounders to let him build Elements as the foundation for their HIPAA-compliant platform handling over $100 million in transactions. That real-world pressure cooker, he explains, battle-tested the framework in ways a side project never could, though he acknowledges it was grueling work he wouldn't repeat.

00:07:23 - What Makes Development Fun Again

Anthony highlights the tagline that Elements makes developing apps fun again, and Chris unpacks what that means. He argues that software development is inherently enjoyable when the feedback loop between imagining something and seeing it come together is tight, but that modern tooling buries developers in yak-shaving—days of environment setup, dependency wrangling, and configuration before any real building happens.

Chris connects this to broader problems in open source: while the movement democratized access to tools that once cost tens of thousands of dollars, it also created a chaotic landscape of competing libraries, marketing buzzwords, and fragmented choices. This frustration drove him to build the entire stack—package manager, build tool, and UI language—rather than slot into one narrow niche, using developer ease as his guiding principle even when that meant taking on a multi-year project.

00:12:10 - Build Versus Buy and the Elements Architecture

The conversation turns to Chris's philosophy on building from scratch versus using existing tools. He pushes back against the stigma of reinventing the wheel, explaining that he starts with a generative process and only reaches for existing solutions when they genuinely fit. React made the cut because of TypeScript integration and community adoption, but the build tooling had to be written from the ground up in Go to achieve the performance and deep integration Elements requires.

Chris details how Elements compiles separate bundles for server and browser from a single codebase, automatically converts service function imports into RPC calls, and achieves build times measured in milliseconds where Webpack takes tens of seconds. He contrasts this with esbuild, noting that while esbuild is fast, its scope is narrow—it doesn't handle TypeScript compilation, server targets, or the transforms Elements performs automatically.

00:17:29 - Developer Experience and Framework Philosophy

Chris explains that his API design philosophy centers on building for himself: if he's having a good time using the framework, it's working. He walks through hot reloading that updates the browser almost instantly without full page refreshes, in-memory server module caching, and HTTP caching strategies that deliver near-static-site performance from a dynamic app without requiring pre-compilation.

He draws lessons from Meteor and Rails, praising Meteor's developer experience while criticizing its closed ecosystem and missing router—comparing it to buying a car with no wheels. Elements ships with routing, authentication, session management, and database tooling out of the box, taking an Express-like approach to routing where URLs map to functions that render pages, keeping the mental model simple and explicit rather than relying on filesystem-based magic.

00:23:25 - Server-Side Rendering, Client-Side Rendering, and Deployment

Christopher Burns asks whether Elements is server-side or client-side rendered, prompting Chris to trace the history from original server-side rendering through the single-page app era and back again. He explains that Elements does both: initial requests are server-rendered for SEO and fast first paint, then the app transitions to client-side navigation, hot-loading only the assets needed for each page using a build manifest and aggressive HTTP caching with cache-busting version tags.

On deployment, Chris describes a deliberately unopinionated approach—Elements apps are standard Node processes that can run anywhere, from a single server to a load-balanced cluster on AWS. He envisions an eventual deploy command that works with any SSH-based provider rather than locking users into a proprietary hosting platform, emphasizing that Elements focuses on tooling and productivity while letting developers choose their own infrastructure.

00:33:19 - Databases, SQL, and the Case Against ORMs

The discussion shifts to data, where Chris makes a passionate case for writing raw SQL and using Postgres. He explains the Elements migration system as ordered, optionally atomic units of SQL change, rejecting ORMs on the grounds that they constrain developers in unnatural ways—particularly around joins, which are fundamental to relational data work. He argues that SQL is a well-designed language for algebraic set operations and that developers should stop being afraid of it.

Chris also addresses why he moved away from document databases like MongoDB, noting that while they initially simplify data modeling, they lead to duplicated data and management headaches at scale. He stresses that Elements is flexible enough to plug in alternative tools like Prisma, but the opinionated defaults—Postgres, typed SQL rows, integrated migrations—are designed to get developers productive immediately without debating URL schemes or ORM configurations.

00:39:03 - The Name, Euclid, and Where to Find Elements

Christopher Burns asks about the name, and Chris reveals it comes not from HTML elements or the periodic table but from Euclid's Elements, the ancient Greek mathematical text considered one of the first axiomatic reasoning systems. He describes how the book builds proofs from simple axioms into increasingly complex theorems, drawing a direct parallel to software development where small functions compose into larger abstractions.

The episode wraps with a lighthearted exchange about coffee consumption and speaking speed before Chris directs listeners to Elements.dev, the project's GitHub repositories, and its Discord community. He notes that Elements is in alpha—version 110 at the time of recording—with a new reactive HTML UI language coming in weeks, and encourages developers to download it, experiment, and join the conversation.

Transcript

00:00:00 - Chris Mather

I think this is recording. I think there's an 80% or 90% chance it's recording.

00:00:16 - Anthony Campolo

Chris Mather, welcome to the show.

00:00:18 - Chris Mather

Thank you. Thanks for having me.

00:00:19 - Anthony Campolo

You got onto our radar in a very random way. Someone popped into the FSJam Discord and said, "Hey, have you heard of this Elements thing? Is this FSJam?" I started listening to the podcast recording you did for JavaScript Jabber, which we'll link to. I was listening to it and thought, okay, within the first five minutes you've mentioned Meteor, ColdFusion, and the original Ruby on Rails demo.

This sounds like Jam to me. We've talked about ColdFusion on half our episodes at this point. So we're coming from the same world here, I think. Why don't we first get a little bit of your background, who you are, and what Elements is?

00:01:07 - Chris Mather

My background is fundamentally, I'm a software developer, a builder, and an engineer. I started my career a very long time ago, back when the web was really becoming a thing, and I did that in the United States government. I started working for the government when I was in high school, a sophomore. That was kind of my entrance into professional programming.

I did a brief stint at Microsoft, but then I ended up going back to the government. I guess that's my claim to fame, working for the Snowden contractor, but I didn't do anything crazy. I just did that gig for a while. Eventually I made my way out to Silicon Valley. I've taken on various roles at startups, but I've always had an affinity for programming, and that's what I really like to do. My last gig before Elements, I was the CTO of a YC company.

It was a healthcare fintech company. Backing up a little bit, about six or seven years before that, I was working for a high-growth startup that we ended up selling. The owner sold it. I was just an employee. Then I went to work for the company that acquired us for a little while, and I just couldn't deal with it any longer. I did that for about a year or two, and then I left.

I did the opposite of high-growth startup stuff for about four years. I made education videos where I taught basic mathematics and computer science. I would publish that on the internet and charge people for it. It was a very content-heavy, creative kind of business and an incredibly difficult business. I learned a lot by doing it and it was a great creative outlet, but extremely exhausting.

I'm sure you can resonate with this if you're doing podcasts or any kind of media or content. It's a lot of brainwave activity every week and it can get exhausting. So my wife and I talked about it and it was like, "Have you seen what these tech companies are paying? Facebook and Google and whatever. You need to knock off this crap and go get one of these jobs." She was very supportive. This was kind of our collective conscious talking.

So I started loosely flirting with the interview process of those companies. One day I went down to Facebook and sat in their area for a while to get a sense of it. I just hated it, honestly. I was like, I don't want to do this. It feels like I'm going to be plugged in like cattle into this where they just take your brain. That's probably not accurate, but that's what it felt like.

00:03:34 - Anthony Campolo

So imagine the Matrix, right? Everyone waking up out of the plug in their neck.

00:03:39 - Chris Mather

Yeah. Something felt off about it. Who knows? I'm sure it's great to work there.

About that time, a friend of mine reached out and said they were looking for a CTO to join their YC company. These are two business guys. It wasn't like a tech company in the sense of building DevTools or something, so I wasn't very bullish on it. I politely said no, but they ended up going to YC. They raised money. They built an initial prototype, and they hired a couple engineers. They came back and said, "Okay, it's very serious. Now we need a CTO."

I had been working on Elements for a couple of years, like the designs for it and stuff. I had notebooks filled with it. I had all the concepts. I had grammars drawn out for the language and the UI. There were a bunch of other things, but I hadn't actually written a full prototype yet. I thought this would be a good opportunity to do that.

I've been building web apps since I was a kid, but it's nice to have a North Star when you work on something, something to guide the use cases. Otherwise it's very easy to go off. I might do something in compiler theory for six months or something that's interesting, but at the end of the day, I don't have a thing that works for users.

So I took the job under the condition that I could build Elements there and that their platform would run on Elements. Of course they said no, this is too risky. I said, well, so is being a CTO of a startup. We went back and forth, and finally they said, okay, fine, you can do it. So I built Elements there.

00:04:58 - Anthony Campolo

Timeline-wise, when is this happening?

00:05:02 - Chris Mather

What year are we in? I've been in the Matrix for a while. It was 2017, 2018, something like that.

00:05:12 - Anthony Campolo

That's interesting to draw out here, which is that this isn't a framework you just kind of showed up with and were like, "Hey, I've got this new framework I'm working on." This is something you've actually been working on for a long time in the background and is now being revealed to the world. It's not something you're starting and putting out there, it's something that's almost finished that is now being put out to the world.

00:05:35 - Chris Mather

Yeah, that's right. It's a very nonstandard open-source path. Like you said, I built it behind closed doors, which is good and bad. It's good because it runs a system that has over $100 million flowing through it. It's a HIPAA-compliant healthcare app, fintech app at that. So we're doing banking transactions. It's very serious. We couldn't lose anybody's money, not even just a tiny bit. No money permitted to be lost.

We really had to treat it seriously. Security was a major concern. There are all these little details, like when you're in a HIPAA-compliant app, you can't have unencrypted data just flowing around Amazon's network, for example. You've got to terminate SSL at the application nodes. Little things like that.

I think that really battle-tested Elements. It created Elements in an incubator where we said, let's just build the hardest damn thing we can. I'm glad I did it, but I wouldn't do it again. It was very difficult. That's where Elements came from.

I quit my job at Lively. It got to a point where the engineering team started to grow, 20-something engineers, and the CEO said, "You've got to decide: do you want to do the Elements stuff or do you want to run the engineering team?" It wasn't 100% clear, but I thought about it for about ten minutes and then said, I want to do Elements. So I quit.

I worked on Elements for about another six months by myself. I pulled my head up and thought, I wasn't sure whether I was going to bootstrap it or not. At that point, I hadn't open-sourced anything yet, but I basically had the prototype working.

Then I decided it's a software company. I'm going to probably need to hire some people. It's pretty serious. It's a very foundational piece of software. I better go raise some money. So I did the fundraising process. I did that two Christmases ago. And here we are.

00:07:23 - Anthony Campolo

Awesome. You have defined Elements as an app framework and a build tool. I'd like to get into the distinction between those two things. But what you also said when you were defining this on JavaScript Jabber was that it's an app framework and a build tool for TypeScript that makes developing apps fun again. I thought that was such a good pitch and really resonated with me.

As someone who has gotten into some other full-stack frameworks, and you kind of call them app frameworks, it is fun. The excitement you get when you talk about this project is one of the things that really draws me to it. So what is it that makes it more fun than the development you were doing before?

00:08:11 - Chris Mather

First of all, development is fun when it's done right. It's a pretty awesome job. It can also be a total nightmare depending on the place you're at and the type of work you're doing. It's extremes. It can either be the worst possible job or it could be the best job. But software development, innately, I think, is fun when you're in the process of building something.

I think it's because you have some concept of something you want to make. Maybe it's a business process you want to make more efficient, or it's a website you want to throw together. Whatever it is, when you start to do it and you see your work come together, that's a very exciting thing. I think that's a fun feedback loop to be hooked up with.

What makes it nightmarish is, and I think this is probably true for a lot of developers, there are so many roadblocks beyond just the building part and learning the languages. It's a lot of tooling roadblocks. It's constantly one thing after the next. Nothing works. It takes three days to get up and running. Have you ever heard the term yak shaving? It's a lot of yak shaving.

You're doing this depth-first search through getting your Vim set up and getting your environment and getting things to install. Before you know it, you haven't built a damn thing.

In the context of open source, open source is great in many ways and it's terrible in some other ways. It's great in that there's a proliferation of ideas and people are creating. I think that's wonderful. I think there's some really great projects out there.

Back when I was younger, before Bill Gates was saving lives, he was murdering people in back alleys and not allowing his competitors to even get off the ground. That's how old I am. It was very hard to get access to software back then. If you wanted to get a database, you had to deal with a Microsoft salesperson or Oracle.

00:10:04 - Anthony Campolo

Right.

00:10:05 - Chris Mather

Minimum price $20,000 or whatever. That's why when MySQL became available, it was such a big deal. You just download this thing. This is what everybody uses now.

The idea of opening up access to people to be able to create is something that's very interesting to me, and I think open source really espouses that ideal. The bad part is that it's very disorganized and there's lots of stuff out there, and it's hard to figure out what to use and what's good and what's not. There's also a lot of nonsense in terms of marketing buzzwords, and people have to sort out what this thing is. Every day seems to be some new buzzword. It's as if we've reinvented computer science and mathematics each year, when the reality is that most of these concepts haven't changed at all since the 90s.

I think the big thing behind Elements and where that ties in is I said, okay, I want to do something a little weird here, and I know I'm going to get my butt kicked a little bit for doing it. Normally you slot in, you write a Hacker News post that's like, "Okay, I just want to be clear with everyone. I'm doing the smallest possible thing I can to fit into this very specific niche of the ecosystem. Please don't hurt me." I went in and I'm like, I'm going to do the whole damn thing, every aspect.

The North Star for me is, is it easier for the user or not? That means I'm going to have to write a package manager, a build tool, and the UI language. It's a big project. A couple of years for sure. Anyway, let me pause, but that's the gist of it.

00:11:29 - Anthony Campolo

Totally. There's a lot of stuff to dig into there. One thing I did notice right away, as you were saying, you've written most of this stack yourself. You weren't really taking a bunch of different pieces off the shelf and combining them together, which is most of the frameworks we talk about on this show. Things like Redwood and Blitz, that is their approach. They found a bunch of different libraries, curated them, and put them all together.

Whereas you're taking this approach that's much more like Aldo. I really want you to meet Aldo. He's on the Redwood team, and he's the type of person who would say, yeah, spending six months writing a compiler is fun. There aren't a lot of people who share that opinion, but you do.

00:12:10 - Chris Mather

That sounds like we'd have some good hikes together.

00:12:13 - Anthony Campolo

Yeah, exactly. How do you think about build versus buy? In open source, it wouldn't necessarily be buy, but is there anything you would take off the shelf, or do you really think you would just write everything from scratch because that's how you approach things?

00:12:27 - Chris Mather

I think any developer will relate to the idea that this is always an existential crisis. Do you use something that exists or do you reinvent the wheel? I'll answer your question directly, but let me back up and talk about some of the context and the feelings around this.

There's a lot of stigma against building things from scratch. There's stigma in the workplace. There's stigma even in open source. "This has been done a million times. Why would you waste your time?" Before you know it, you're not permitted to do anything except learn the latest buzzwords. I remember having a distinct rejection of this idea. I just got angry with it and said, okay, I'm going to go through my own process.

That's just something I learned. I'll go through a generative process first. If there's something good out there, then I'll use it. I don't have any particular problem with using other people's stuff. An example of that is React. The first version of Elements started as a UI language. It started as reactive HTML. That's one of the coolest problems. But I put that away and went with React because the TypeScript compiler already works with React. A lot of people are already using React, so I started with that. Although now, in a couple of weeks, we'll have Elements reactive HTML as well. That's an example of where if people are using it and it works, then it's fine.

In other areas of the stack, like the build tooling, there's just no way to do what Elements does with Webpack. It's simply impossible without basically rewriting core parts of it.

That's not even getting to the performance issues it has. There's nothing out there faster than Elements other than maybe esbuild. esbuild is close, although it's still not as fast, but it's very narrow in its scope of responsibility. It'd be like if Elements just does linking, then yeah, it's going to be the same benchmark and actually much less time. But it's fast. If something takes 30 seconds in Webpack, it's going to take like 100 milliseconds in Elements or esbuild.

00:14:31 - Anthony Campolo

You actually said on your website that Elements apps are the fastest apps on the planet.

00:14:39 - Chris Mather

It's probably my investors telling me to be boastful. It's not my nature, though.

00:14:43 - Anthony Campolo

You don't strike me as someone who throws out statements like that without at least something to back it up. You said you had to rewrite the build tool from scratch, and you're not using esbuild, but are you writing it in some sort of systems-level language? What is underpinning your build tooling?

00:15:04 - Chris Mather

All the infrastructure tooling, build, package management, all that is Go. That's the same as esbuild. Some of the techniques esbuild uses are similar. We can go to any level of depth if you want, but Elements does do some things differently. It is ultimately faster in an apples-to-apples comparison, but it does a lot more, so to actually do a comparison you have to be careful.

esbuild doesn't even touch TypeScript. It'll emit TypeScript to JavaScript, but it doesn't compile or anything. It just punts on that problem. That's where it's thin. Elements is actually very integrated. Elements does server and browser automatically. It's not like a one JavaScript file single-page app that doesn't deal with the server at all. It handles both targets.

When you're compiling, you're compiling one file for the server and one for the browser. It's doing transforms. For example, in Elements you can just import a service function and call it.

That's how you deal with it. You can do RESTful API. You can do GraphQL if you want. Any of that's fine. But if you're starting from scratch and you're just doing it the Elements way, you create these functions called service functions. It's in a file in the services directory. You can export functions and import and call them like you would any function. No special syntax or anything like that. The build tool takes care of converting all that to RPC. Those are just some examples of some extras that it has to do.

00:16:23 - Anthony Campolo

What you're saying right there about importing your services and calling those functions directly into your database, that's kind of how Blitz is set up. If you were to build out with a whole GraphQL API, then you'd be getting closer to Redwood territory.

What I really liked watching some of your tutorials and videos is that the code you write in Elements is very familiar. Everything I saw you were writing, even though it didn't necessarily map directly to any specific framework, all just looked like the type of code I'd been writing. It's very Express-like, and obviously it's React and TypeScript. So it's got all these familiar pieces that have been remixed into this new package.

That's what I really enjoyed about it at first glance. Nothing looked too crazy or out of the ordinary. How do you think about the API and the actual code you're writing and how you thought about that?

00:17:29 - Chris Mather

First, Anthony, I appreciate the compliment. Thank you, and the analysis. My general philosophy on what features go in and what the surface area looks like for the Elements code you interact with, particularly the framework parts of it, and more generally the overall development experience, is that in a sense I'm building for myself.

When I'm working on an app, I know I'm successful in the framework and the build tooling when I'm having a good time building something with it. That means it has to be really fast. The hot reloading has to be almost instant. There's a lot of work that went into that.

For example, as you're working in Elements and you update the HTML or CSS or the service functions, anything in the stack, the browser is updating almost so fast you can't even see it. It's very quick. There's no full process restart. On the server it's all in memory. The module cache tree is refreshed hot in memory. The browser doesn't refresh either. It just hot-patches the head section with all the latest new assets.

Combining that with the HTTP caching, what you end up with is a very fast loading experience, very fast hot reloading. All of that works really great with CDNs as well.

As a quick pitch for Elements, you don't have to compromise between building an app and building a static site. If you're doing a marketing site, you could build a static site and get a little bit more performance out of just serving it off the CDN, but with Elements, you kind of get the best possible performance you can get for an app.

On the previous point about whether it's the fastest in the world, it's certainly the fastest development experience. I'm fairly confident in that, but it depends. I hesitate with benchmarks because you have to do an apples-to-apples comparison to be fair. I don't like to be too hyperbolic, but on the other hand, there is something to just coming out and being like, look, it's fast. We've been working on this for a long time.

But the more important thing than the raw benchmarks is the overall developer experience. Meteor was a great example of a pretty good developer experience. They made a lot of mistakes. They didn't have anything with the ecosystem. It was their own thing. I learned from that. You can't just build your own package system that doesn't have any of the things that people use and expect them all to migrate over to your system, especially when your thing is crappier. If you're going to replace something, it has to be better than what exists.

The other problem they had was they didn't have a router. It'd be like if you went to buy a car and you show up and you're like, okay, I want to drive the car. That's my goal. They're like, well, we're going to give you the car, but it doesn't come with any wheels. So what you're going to have to do is go find some wheels for the car. You're like, what do you mean it doesn't have any wheels? How am I going to drive it?

They're like, well, there's 5,000 wheel providers all throughout California and you just go pick one. They all have pluses and minuses, and good luck with it. That's kind of what it feels like when you're building an app.

Coming back to the final point, philosophy-wise, I don't want to make something that's so far off from what people do that they have to learn a brand new paradigm. We've got some pretty good paradigm primitives here. We have HTML. It's been a long-time standard. It's taught everywhere. We've got great documentation for it. HTML is here to stay. CSS, same thing. It's been around for a while and it does all these cool things. You just have to learn some idiosyncrasies. They're languages.

I would love to build my own language. The UI language is about as far as I'm going to go with that. Building a TypeScript-style language would be fun for me, but I don't think that's a great strategy for a startup. That generally takes decades to get right.

I started this project with a utilitarian perspective: make it a smooth developer experience, do the things you need to build an app, cut out all the bullshit that doesn't matter, but try to stay with mainstream technologies. For the language, let a big company do it.

That made TypeScript a natural choice. If you're working in Lively or an enterprise situation or anywhere there's a big app, having typing and TypeScript is really useful. As a CTO, it would help me sleep better at night. Otherwise we had all kinds of issues in production. We actually had it as JavaScript before we switched, and it was a nightmare.

Last point: routing and things like that. If another framework like Express had a nice idea, I'm happy to take it. For things that are not good, I'd get rid of them. Routing is one of those. In Next.js, for example, it's sort of magical. That doesn't work in my opinion. Most of the time you want routing in code because you want to do some things. You want to do authentication, get some data, set meta tags, title, whatever.

So routing in Elements is very Express-like. You render a page that also allows you to set the data for a particular page. It's cognitively easy to follow. You start with a URL. You work your way to the function. From the function you work your way to the view. All of that is a fine way to build. Feels like I've been talking for a while, but maybe I addressed your point and a couple others as well.

00:22:29 - Anthony Campolo

We got a lot of stuff to spin around here. You got anything to jump in here with, Bernzy?

00:22:34 - Christopher Burns

I've been listening. I've been quickly browsing, having a look deeper now that I've got some context, because I looked at it straight away and was like, "Oh, they're doing some abstractions on some other things," without looking too deeply. But now that you've said you've built everything yourself, my mind goes, oh yeah, you can see that. Obviously not TypeScript and things like that, but you can tell.

I was just looking at the starter template that was on GitHub, and it looks like a really good cross between Express and React. It then gives me additional questions like, is this server-side rendered? Is this client-side rendered? It's very different based on how some of the wrappers are made.

00:23:25 - Chris Mather

That's a great question. It turns out it's also a very hard problem. I think it gets at one of the core paradigm shifts over the past couple of years.

When I was young, everything was server-side rendered. We already invented server-side rendering many years ago. You don't get any credit for this. We already had it. Then we went to browser-side rendering, and then we went back and treated it like a new invention. But no, we had it.

Server-side rendering has a lot of benefits because when you render a page, you're already on the server and you have access to things on the server. It's an easy mental model to some degree. You have to learn the HTTP back and forth and all that, but once you learn that, most people wouldn't say Rails is impossible to use, at least for the basic use cases.

One of the things that made it so popular was DHH's demo video where you can make a blog in two minutes, and it was astounding. I remember seeing this. I was like, oh my goodness, this is amazing. It's got the whole thing, the database, and there's nice command-line tooling. It doesn't appear to get in your way. He had a dogmatic ethos that was exciting, at least for a little while.

Then all of a sudden you have something like React, and there were some precursors to React. They weren't the first to come up with this. Certainly HyperCard and some of the software tooling that was available to us a long time ago were really the first to come up with this. But the idea of reactive rendering, which is that you design your HTML or your view as essentially states, various states of the user interface, and it responds to data automatically, turns out to be a pretty good way to do user interfaces.

So now if you look at Lively, you've got this very complex user interface. There's all sorts of things going on. You click a thing, graphs are updating on the right-hand side, and so on. People want that. They expect that kind of user interface. But to get that with Rails is a huge pain. You've got spaghetti code and some kind of bizarre thing where they're sending HTML over the wire, and maybe it works. I'm probably being hyperbolic, but the point is it's hard to get both of these right.

So you end up either with a single-page app that has really cool user interfaces, or you end up with the server-side app that's probably a little easier to manage but not as great of a user experience.

Elements combines those two. You specify the route. Basically, the primitive of the router is the URL maps to a function. You can do some stuff in the function and then you render a page. The abstraction is it's going to take care of everything for you after that.

You tell us what page you want to render in response to this URL, and what Elements is going to do is say, okay, you get server-side rendering. Don't worry, we've got you covered. We invented this in the 90s.

Then you're also going to get client-side rendering. Once the app is loaded in the browser, it stays in the browser. As you navigate around the app, it's going to hot load the head section with the scripts and CSS and other resources you need for that particular page. You can also prefetch because the same manifest that's used for the router to run in the browser can be used to prefetch all the assets.

There's something the build tool produces called a build JSON or build JS, and it has all the bundles for each page, including the code and style assets required for each URL.

You combine that with HTTP caching, which is to say the server says, "Hey browser, you can keep this JavaScript asset for six months. You don't even have to come back and ask for it. Just keep it. If we have a new one, we'll give it a new version tag so it gets a new URL." That's how we do cache busting.

You combine all that together and what you get is server-side rendering, which is great for SEO and initial load times. You can have data on the server as well, so you don't get this blank page. Once it's in the browser, the user experience is very fast. You just stay in the browser. The HTTP caching means that the initial load and the subsequent loads are extremely fast, and it works with CDNs as well out of the box.

So you get the best of both worlds in building an app, and you get the performance benefits of using CDNs and caching strategies without having to statically pre-compile your site every time you add a piece of data.

00:27:19 - Christopher Burns

That sounds great when you say best of both worlds, but my next question is the blockbuster. Where do you host an Elements app? Do you host it on PM2, Docker, or lambdas, for example?

00:27:33 - Chris Mather

Probably not lambdas, although we'll see. There might be a path for that. Service functions in Elements are one of the nicest simple abstractions in that it's just calling functions. If you're just calling functions, that doesn't seem too far off in the universe of lambda functions. But there's some trickiness there in terms of state and session.

In the service functions in Elements, user authorization and authentication is there for you. You can say, "This session," and you can check whether the user is logged in or not. Throw an error even down the wire to say the user is not logged in. Authorization, session, authentication is nicely integrated in Elements. You can build all sorts of things on top of it in terms of roles and stuff like that. But the core primitives are very easy to work with.

I don't know how all that would work with lambda functions. I haven't looked into it yet. In terms of deployment, we don't have an automatic deployment story right now for Elements. I would like to put an Elements deploy command in at some point, but the vision for that will not be, and I'm not making promises, but as I can conceive of it today, I don't think it'll be deployed to Elements servers on some custom thing.

One of the things I like about Elements is I want to focus on tooling. I want to focus on making developers really productive. The output of that, just like you would take the output of Adobe Photoshop, would be a PNG or a JPEG or whatever, and you could do whatever you want with that. You can put it onto Amazon, you can put it onto Heroku, you can put it onto Vercel, you can put it on any one of the deployment providers. But the Elements app itself will work with any CDN that's out there because it automatically changes the URLs all throughout the app.

You just provide one configuration variable that says, what's your CDN URL? It takes care of everything else automatically. I could see users deploying to Amazon.

A very simple deployment topology would look something like this: you have your app servers. You start off with maybe one and it's just a Node process. Elements apps are just Node processes. If you want to get a little bit bigger and you connect that to your Postgres backend, or if you want to abstract it out to maybe a GraphQL or something else you've got going on, that's fine too. You want to scale? Copy it. It's a very simple scalability pattern. You copy the application server. Now you have two. Now you need a load balancer. You can use ELB for that if you want, or you can use nginx or whatever you want to put in front of it.

So in conclusion, I could foresee an Elements deploy command that basically lets you work with Amazon or any SSH-based deployment provider. Then I say let the user choose what they want to deploy on.

00:30:01 - Christopher Burns

That sounds pretty good.

00:30:03 - Chris Mather

Okay, good. That's the first feedback I've gotten on this, so it's nice to see another human telling me what they think.

00:30:08 - Christopher Burns

I build my own startup. I'm obviously the CTO, but more of a CEO technical lead, so understanding how everything works and how it can work efficiently is so important in more entrepreneurial-sized companies. A single developer working on an application is totally different from an entrepreneur working on an application. Totally different.

The single developer's mind goes, I'm going to be the only developer that ever works on this. An entrepreneur is probably going to be, what's the fastest way I can hack this out the door to sell it to Facebook? I think your ideas are really sound, and the tutorials on your website are really cool. They're like quick videos. I suggest listeners go watch the quick videos because even the TypeScript one is great to explain how TypeScript works in Elements. It's really good.

00:31:09 - Chris Mather

Thank you. We've got some work to do on documentation, and I had to take a detour to work on the UI language, but I'll be back at evangelism and documentation and onboarding and all that. I figured at least I should get a couple videos out there so people can get a sense of what it is.

Commenting quickly on your point about the roles when you start a project, I think there's a crucially important point. To expand on it a bit, I told my investors this the other day: choosing your framework or the technologies you use at the start of a project is like choosing a marriage partner. Everyone kind of knows if you make a mistake, you're screwed. You've got to be very careful. Maybe people overthink it now, but I won't take the analogy too far. The point is you can make choices today that are going to be awesome or hurt you sometime in five years.

With technology, you know it's going to hurt you in one way or another. The Holy Grail is if you can somehow create something where people can move very fast, because in the beginning you have to iterate. If you're a single developer or you're a business person, you've got to see results.

As an entrepreneur, like a machine learning classifying algorithm or something like that, it's the iteration speed and the speed at which you're learning from what you put out that matters. If it takes you 25 minutes to do a Java build to see your change, this is a nightmare.

But you need to combine that with something that in five to ten years is going to scale out to a very large engineering team. I think the Elements primitives allow for that. That was something I had in mind from the very beginning: just do it this way.

It's very simple. You can build things very quickly and as you add more and more people, it's still going to be okay. An example of that is service functions. Just create more functions. It's fine. The security model for the functions is very simple, very easy.

You can do RESTful routes if you want, but I know that with engineering teams I've worked with, that creates an opportunity to have debates about what the URL scheme is going to be and all that kind of stuff. We're just calling functions. This is simple. We don't have to argue about this. If you change a function name, it changes everywhere. No problem.

Anyway, I talk too much sometimes, but I wanted to wrap a little bit on your point about teams.

00:33:19 - Christopher Burns

The thing is, and I think it's really funny to think about sometimes, you think big company has bought X and then you think, why hasn't it changed in two years? It's because they've reprogrammed it completely. Cool.

00:33:36 - Anthony Campolo

I want to hit on a couple more technical things before we close out here. We've talked about the front end as TypeScript and React. We've talked a little bit about the server side and how you think about service functions. But I'd like to talk a little bit about the database. You are a Postgres fan, which is nice. Got lots of Postgres fans here.

When I was watching your tutorial, you have migrations, and it seems to me like your concept of migration is a way to just inline SQL. Is that accurate? Is there any sort of abstraction you've created to handle migrations, or is it just really easy to throw SQL wherever you need it in your project?

00:34:18 - Chris Mather

There's a couple concepts in that line of inquiry. Let's start with migration. What does a migration system have to do? A migration system has to take a unit of change to the database and run those units in an order and atomically. If you want it to be atomic, meaning they all succeed or they all fail, that's often the requirement. Sometimes we want to override that. If you have one migration that takes two hours, you might want to just let a couple of them run, and if the final one fails, it's fine. You don't have to roll the whole thing back. Also, running things atomically can lock up the database for too long and things like that. But in general, that's what we want.

00:35:00 - Anthony Campolo

It's the A in ACID.

00:35:02 - Chris Mather

Yeah. The SQL in the migrations is the specification of the migration. There are a number of things we can do. We can use an ORM. I'm not a fan of ORMs, so that's a broader philosophical discussion. I've used them. I've used all of them. I finally concluded that we need to stop being afraid of SQL. It's not so bad. It's actually pretty useful if you get used to it and you stay away from some of the nastier things you can do. It's a really great way to deal with algebraic sets.

If you go back and read the original paper from the 70s, it's pretty straightforward. It's basically just a bunch of Venn diagrams, and it's someone thinking about, okay, if you have to deal with data, normalization of the data often becomes a default thing you want to do because you don't want duplicate data everywhere and have to maintain different data everywhere.

But then we have to bring it back together. How do we do that? They designed a language to do it. I think SQL is actually fairly good at it. The problem with SQL is it becomes hard to read after a while. You should see some of the queries we have at Lively, the fintech healthcare thing where we're moving hundreds of millions of dollars around. It's pretty gnarly. I would expect that no one going in there is going to be able to reason about it.

This is going to be a heretical thing to say, but I think it's okay as long as it's contained and the inputs and outputs are understood. It's almost easier just to redo it if there has to be some crazy new thing. Our brains are naturally okay doing and generating, but trying to understand something that somebody has done is very difficult, whether it's SQL or an ORM or anything like that.

So what ends up happening with ORMs is they constrain us in weird ways. Doing a join with an ORM is a nightmare, and that's one of the biggest things we want to be able to do with SQL data.

So what are the migrations? I just let you write SQL, and the philosophical idea here is just stop worrying so much. SQL is wonderful. Your life is going to be fine. Do SQL. This is what we do. In the government and top secret projects, all SQL. Fine. Stop worrying. Biggest databases ever created? It's fine. It works great. ORMs tend to get in your way, in my opinion.

The philosophy on databases in Elements is strongly typed SQL rows or not. If you don't want to use TypeScript, you don't. You can leave it untyped. But it's a nice pattern because when you load a page, you often want to pull data from different tables. You want some kind of list or a detail view, and it changes depending on the page.

So an ORM has never made much sense to me because it's like strongly typing to the table, but that's almost never what we want. We almost always want things from multiple tables and to bring it together into some kind of strongly typed structure. I went down the rabbit hole of existential crisis with Mongo and those types of things, and I finally concluded that the document orientation solves this problem, sort of. But as your thing gets bigger and you have more data, you realize you have duplicate data everywhere and it becomes hard to manage. So you end up being, in my opinion, kind of screwed.

Long story short, I like Postgres. I like relational databases like Postgres because it's easy to get and it's free. If you're starting today as a startup, I would highly recommend you go with Postgres. I don't have as much of an opinion on all the GraphQL stuff, but that's my opinion on databases.

One last point: if you want to plug in something different with Elements, I wanted to make that super simple, including a migration framework. If you have your own, or you want to plug one into the Elements command-line tool, I've made that fairly simple. I wanted to make sure all batteries are included so people can be productive. You don't want to not have a router to build a web app, and doing database stuff is what you need if you're going to build an app, right?

00:38:29 - Anthony Campolo

Yeah. If you could plug in Prisma to Elements, I think you might get a little more pickup from our crowd, but that'll be for another time to discuss.

00:38:39 - Chris Mather

They can plug it in. The main opinionated part of Elements, the main thing that really can't change, is the routing and the server, the RPC mechanism. Those are the core things. Database, you can plug in whatever you want. I think there's an easy path that's going to be what I would do. But if you want to plug in Prisma and you're used to using that and you're productive in it, by all means.

00:38:59 - Anthony Campolo

You also want to hit on something, Bernzy, before we start closing out here?

00:39:03 - Christopher Burns

Why did you pick Elements as the name?

00:39:06 - Chris Mather

Thank you. You're asking all these wonderful questions. Very few people ask me about the name, and the name actually has a bunch of overloaded definitions. The first thing people think of is probably HTML elements. That's wrong, but it's a pretty good guess.

00:39:20 - Anthony Campolo

I would think scientific elements actually, especially with the React atom model.

00:39:26 - Chris Mather

That's what my designers thought, so they created a periodic table as the first logo for Elements. That's the second best guess. It's neither of those things, but all good guesses.

The real term comes from a book, the first kind of canonical mathematical textbook in the world that we're aware of. Euclid's Elements, if you guys are familiar with this book.

00:39:53 - Anthony Campolo

No, not really.

00:39:55 - Chris Mather

Okay, I'll tell you a little bit about it. You should all go buy this book. Euclid is a guy who lived about 3,500 years ago, although it's not clear he was a guy at all. It's possible that it was a collection of mathematicians. It may have been an individual. He was Greek at this time period, and he amassed a collection of all the knowledge of mathematics in the world and put it into a book. The book is called Euclid's Elements.

What's interesting about Euclid's Elements is it's basically a foundational text. It's what all future mathematics derives from. I think, and I could be wrong in my history here, it's one of the first examples of an axiomatic reasoning system. In the very beginning of the book, there are like seven books inside of it. It starts with some basic geometry, and then it works its way up through number theory and more advanced geometry and so on.

It's a proof-based book. In the beginning, there's a list of axioms. Axioms are primitives that we can all agree on. What is a line? What does it mean to draw a thing between two points?

The cool thing about Elements is that it has you construct the proofs, and they're not boring. It's not like school where you just learn some bullshit. The first proof is amazing. You construct this thing out of nothing and they teach you how to construct it. You make this unbelievable shape that you didn't think was possible. They teach you how to do that. That's called the construction.

Then you prove certain properties about it, and that's the formalism. You learn how to construct a cool thing and then you learn properties about it. The book proceeds like that and it all builds up. The proofs are based on these axioms. You build up a proof based on a bunch of axioms, and then you can build up higher-level proofs based on those proofs.

That is basically how mathematics works. It sounds awfully like making a computer program, doesn't it? You start off with smaller functions, you build up higher abstractions of those functions, and before you know it, you've created this monster of a thing and you're debating things that no one can tell whether it's true or not anymore. But anyway, that's where the name comes from.

00:42:02 - Christopher Burns

I guess my final question: do you drink coffee or do you inject it?

00:42:08 - Chris Mather

You're commenting on my hyperness or how much you've seen me drinking this?

00:42:12 - Christopher Burns

How fast do you talk? I thought I talked fast.

00:42:18 - Chris Mather

I drink an inordinate amount of coffee. It's the only thing I do. I don't drink any alcohol. I don't do any drugs, but I do coffee. That's the thing. The reason I don't do any of those things isn't because I'm self-righteous or anything like this. It's just because I'm too bonkers to begin with. You inject something like that into me and I'm totally a loon.

Coffee first thing in the morning, I get up, and it's the most wonderful way to start the day. Then I keep drinking it until I'm bordering on out of control. That's when I know it's time to stop.

00:42:48 - Christopher Burns

I'm the same, but I go from coffee to Coke.

00:42:55 - Chris Mather

Oh, no.

00:42:56 - Christopher Burns

Well, Coca-Cola or Pepsi. I know it's really bad.

00:42:59 - Chris Mather

Coke is delicious.

00:43:00 - Christopher Burns

Or tea. Just have a cuppa. Have a cuppa. British accent for you.

00:43:07 - Chris Mather

You're British. Yeah.

00:43:08 - Christopher Burns

Tea, and then the cycle repeats. Then you go, I've had enough of tea, so you're like, now drink loads of coffee.

00:43:15 - Chris Mather

You got to game the system a little bit. Your body is tricky. It starts to learn what you're doing and then you have to fake it.

00:43:21 - Anthony Campolo

That's funny. I was actually going to make a joke about how fast you were talking in your videos as well. Like, are you just mainlining some speed before you hit the record button or what's the deal there? But yeah, thanks for sharing the story of the name there.

For anyone who isn't familiar with Euclid's Elements, Abraham Lincoln said that taught him the art of reason and logic. When he would, in his spare time, try to expand his mind, he would read Euclid's Elements. So it's well known for being, as you say, a paradigm of logic and reasoning. It's a really cool influence. I really like that name. That's awesome.

00:44:05 - Chris Mather

It had a major influence on me, the book.

00:44:07 - Anthony Campolo

Cool. We're about at the end of our time here. Really enjoyed talking to you, Chris. Really enjoyed getting to learn about your project and what you've got going on here. Why don't you share with our listeners where they can find you, where they can find Elements, and what they could do to get involved?

00:44:23 - Chris Mather

Sure. First, I really appreciate you all having me on. It's a pleasure to speak with you, and I had a lot of fun. I wish your business the best of luck and congratulations on the fundraise. I was looking at your website this morning, and it looks like you've got a lot of cool things going on. It has all the hallmarks of an exciting new business. I wish you all the best, and if there are ways we can work together, by all means, let's figure out something.

With all that said, users should go to Elements.dev. I have the most unsearchable name. That's the bad part about Elements. You can't find it because trying to get Google to show Elements is impossible, so you have to memorize it. It's Elements.dev. Just go there. From there you can find the GitHub projects. There's a lot of open-source stuff.

You can go look at the application framework and other things, and then pop into the Discord and say hello. I wish more people would come into the Discord and chat with me. I'd like to talk to people. That's the first thing you can do. Just come in, say hello, learn a bit about the project, ask any questions. There's no dumb questions. Just come in there and say whatever's on your mind and be social. That's the best thing you can do right now.

Elements is free. It's an alpha. We're on alpha 110 at this point, so there's a lot of iteration. Download it, play with it, try out building an app. There's a new UI language coming out in a couple of weeks that I think is really exciting, so I'm looking forward to that. But yeah, Elements.dev, that's the website. Just go there and you can find everything after that.

00:45:50 - Christopher Burns

Thank you. It's really cool what you're doing and I wish more people would support you and get it to be big.

00:45:59 - Chris Mather

Thank you.

00:46:00 - Christopher Burns

We don't need one more opinionated tech stack that's just rebundling everything else. We need unique IPs.

00:46:12 - Chris Mather

Well, good. I'm glad I have a champion out there in the wild. Nice to talk to you both and I hope you have a nice day.