Brian: PodRocket is sponsored by LogRocket, a front end monitoring and product analytics solution, which is to say, it's not really sponsored by anyone. It's sponsored by us LogRocket, and we're giving it away for free. The podcast is free. The product is not free. There's a free trial. We could split hairs about whether or not that's free to you, but anyway, that's it. There are no more ads. If you're interested and you want us to know that you came from the podcast, please go to LogRocket.com/PodRocket. If you don't care, LogRocket.com works just fine. Thanks. Brian: Welcome to our first ever founder Friday. The founder of Friday episodes are a little bit different from our normal episodes. The idea is that we will feature founders of either startups or dev tool projects, and just kind of learn a little bit more about what they're up to. On this episode, Ben talks with Chris Mather, founder of Elements, which is a new full-stack JavaScript framework. They also discussed Chris's journey from CTO to founder, as well as what Chris is excited for in 2021. Let's go. Ben: Hey Chris, how are you doing? Chris Mather: Great. Super excited to be here. Ben: Maybe you could tell our audience a bit about what is Elements. Chris Mather: Yeah. Elements, it's really two things. It's an app framework that's been open sourced so you can go check that out on GitHub and it's build tooling, tooling really in general, the build tool is the biggest part of it, but there's also a package installer and a couple other things. The idea is to make it much easier for people to be able to build web applications that are modern on the server and in the browser. Ben: Got it. Maybe you could elaborate a little more because there are a number of frameworks out there and there are certainly a number of build tools out there. We've spoken actually on the podcast recently with Brandon Bayer of Blitz, which is another framework. We've spoken with Fred Schott of Snowpack, which is kind of more in the build tooling. Maybe you could kind of give us a bit more color there. How does this fit into the ecosystem? What does it replace? What does it build off of, et cetera? Chris Mather: Yeah. Starting a business in this area, it's not well advised. There's so many things to pick from, but maybe it would be helpful just to tell my story of where this came from and that'll kind of lay the context for it and I can fill in those holes with specific features. Ben: Yeah, that'd be great. Chris Mather: I started building for the web back a really long time ago when it first came out. Through Netscape, that was my introduction. I was enamored by it because it was obviously immediately evident that this was going to be incredibly powerful that anyone in the world get to your app through this distribution mechanism. I was very excited to be able to build things. The first job I ended up taking was actually for the same company that Edward Snowden worked at. Chris Mather: This is my claim to fame, I guess, but I worked for a defense contractor and I got my top secret clearance and I worked for the government on secret things. I started that in high school and actually worked through after college. I did that and I spent the next basically 20 years fighting with dev tools, with terrible dev tooling. Dev tooling has always had a special place in my heart. I like being a builder. I like the idea of building tools for people, for craftspeople. It's such a challenging thing to do. It's algorithmically challenging. You have to understand data structures and algorithms and systems engineering. I just like that type of work. But anyway, after the government, I got a little crazy working there after a while and I was ready to try something different. I came out to Silicon Valley. Chris Mather: I ended up working for a couple of startups. Then after that, I did my own small business where I taught mathematics and computer science online. Kind of Khan Academy style videos that people would watch. Then after that, I took a CTO job at a healthcare FinTech company out here. Elements has sort of been in the works for, the ideas for it about 10 years ago. But I really started writing the first lines of code when I was the CTO of this FinTech healthcare company. Maybe this will sound mean, but it seems to me like when I look at the JavaScript ecosystem today, and this is from the perspective of a developer, but also as the CTO, it feels like a lot of buzzword bingo out there right now. Back in the nineties, there was this thing called the enterprise JavaBean. Do you guys remember this? Ben: Beans and all that terminology. Right. Chris Mather: It was this bizarre abstraction and you weren't really sure what it was, but everything you have to do is an enterprise JavaBean. If you want to say hello world, you should probably start with an enterprise JavaBean and figure it out. To me, when I look at the ecosystem today, God forbid, you're coming out of school. You're looking at everything that's out there and it just looks totally crazy because it is. I think there's gatekeepers of the buzzwords. I think that making sense of all this is nuts. From the perspective of a CTO at a company where we have to build a real app, this is a bank. We built a bank at Lively where we processed over a hundred million dollars in transactions that went through the system. Lots and lots of customers. We couldn't lose their money. Any of it. You couldn't even lose a little bit of their money. That's how serious this was. Chris Mather: When you're doing something serious like that versus exploration, which is also great, but when you're building it out, you've got to be able to debug it in production. You've got to be able to handle support calls that come in at three o'clock in the morning and be able to get to resolution within a couple of minutes. If you've got nine or 10 microservices up and running and this crazy architecture that sounds good but you actually have to run a business off it, good luck. That's kind of the philosophy. I think the backdrop of which, where Elements came from, which is that I wanted to build an app framework and build tooling that was insanely awesome to use for developers. The developer experience has to be like really, really good. The app framework has to be able to run a HIPAA compliant bank. Chris Mather: My North star was how do you build and run something like that. As a quick sort of addendum, the built tooling itself is very fast. It's going to be faster than we'll see, I'm sure people will hold my feet to the fire, but it should be faster than any JavaScript based web build tool because it's written in Go. It's multi threaded and there's lots of heavy duty algorithms in there to make it super fast. We spend multiple years of R&D on it. There's lots and lots of code in there and it's extremely fast. The hot reloading experience of Elements is like mind blowing. It's really fun to build in elements. Both Lively's built on it. The Element site itself is essentially a video content platform is built on top of it and building this for myself. Anyway, I'll stop talking, but that's my quick background of the whole thing. Ben: That's really interesting. I'm curious, correct me if I'm wrong, but since you originally started writing code for Elements when you were at Lively. Chris Mather: Yeah. Ben: There's certainly been a lot of innovation in both the framework space and the build tool space. Frameworks, I think of like Next.js. Maybe we could start there. How does Elements on the framework side compare to Next.js. When might you advise someone to choose one or the other? Chris Mather: I think the way to start is to start with what does the framework have to do? This really governs what kind of build tooling you need. The build tool is satisfying the requirements of the app that you're building. It doesn't matter what database you're using. It doesn't matter exactly how you communicate from the browser to the server. At the very basic, what you have to do is routing. You have to be able to render a page. This has gotten extraordinarily complicated. It shouldn't be, but what you need to do is you need to have a very fast router and the router needs to be able to map a URL to a function that runs, and that renders a React component or renders a Vue.js component or whatever your view at rendering is. Chris Mather: Now, this has been the same for ages, right? I guess server-side rendering has been reinvented this decade, but we used to do that back in the nineties, server-side rendering. Then we went to browser rendering, and now we seem to be going sort of back and forth. The big difference now is that you need to be able to do both. There's quite a few benefits to being able to render in the browser. I think reactive programming in general has been the big innovation of the past decade, which is that you can create these really amazing user interfaces. Our signup flow for Lively was very interactive as you're dragging progress bars and various things that the user would have to fill out. The user interface is updating in real time. That's the expected user experience for the user. If you have to go back to the server in order to get the new UI to update is too slow. Chris Mather: Making all that work harmoniously so that you can get server rendering, browser rendering, and then being able to say cache HTTP assets and URL so that you get a very fast loading experience. That's kind of the basics that you need. When you add on top of that data, you need to be able to get data from the server to the browser. There's a number of ways to do that. Elements is somewhat opinionated. If you're starting from scratch, you should probably just do the Elements way. But if you're using GreSQL or Rest APIs that'll work too. But what I have my team do when we were at Lively, I just asked them to call functions. Elements just allows you to call a function, any function on the server. The only special thing is that it goes in the services directory, and it has to be exported. But that way they're not worrying about RESTful route schemes and things like that. Chris Mather: It's just, you call a function, pass the parameters, and you get a return result. The only special thing that the service functions get is they get access to the session. A session can be authenticated, or it can be an anonymous session, but you often need access to that to be able to tell whether a user has access to data or they have the authorization to the data. Elements makes your working with data really super simple. One of the things I really love about it on the backend is it embraces Postgres fully. You can use any database you want. I've got a special place in my heart for Postgres. I like SQL. It's my dirty secret. I think SQL is great. They did it right in the seventies and I think we should use it. I think that what we should do is we should strongly type it and we should stick to the basics, not get too crazy with it, but it's really great for taking data in separate tables, bringing the data together for a particular view. Typically you have a list or some form or detailed view you want to show. SQL is a great way to do that. Chris Mather: If you want to use Mongo or something else, be my guest, it'll work fine. But if you want to use SQL, the way Elements works out of the boxes, it has strongly typed Postgres. You can work with strongly typed rows. You can send the rows right over the wire. It's got all kinds of aggregation functions built in to make it super easy. The North star for me in summary is the app development experience from the database down to the client. I want that to be really, really good. Now, obviously the build tool has to be really good to support that because there's a lot of features that were baked into the build tool to make, for example, server and browser rendering work, it parses out the render calls automatically. Chris Mather: It figures out what your bundle split points should be. You don't have to configure it at all. There's no configuration at all. It just works. It has to do a lot of work like it has to compile for the server and it has to compile for the browser. Both of those targets. If you use webpack out of the box, you're not getting server, you're just getting a single page app. The problem with that is that, well, we want to use TypeScript. We want to use TypeScript on the browser and in the server. We don't want a single page app. If you're Lively, I mean, that's 200,000 lines of code and 900 plus views. You're going to get a big, giant bundle. It's going to be 20, 30 megabytes. If you're at the airport, it might not even load. Chris Mather: We would get support requests. We were on webpack, we moved off of webpack and that was one of the first problems that build tool had to solve. It had to automatically split the application by routes. Now Next.js does it by folder. I don't agree with this approach. I don't think it's a good way to do it. I think route should be in code because in code you want to be able to grab data, you want to apply authorization rules. You want to set meta-tags, there's different things you want to do. The route function that Next.js doesn't really make it easy to do. I would say if you're on Next.js, just move to Elements. Most of your code will stay the same. It's going to be React. Most of your code is probably at Lively, at least 70, 80% of the application is React code. Then a lot of the rest of it is just database code. Then that middle piece with the routing, that could take one of your developers two days to migrate that over. Ben: Yeah. That was going to be my next question. What is the gradual adoption story for a app that's already in existence, but it sounds like it's pretty straightforward since it's, as you said, mostly focusing kind of on the API layer code. But then I guess from a build tool perspective, if you're already using webpack and maybe you've done some amount of configuration to your webpack first out of the box configuration, what's the migration process there on the build side? Chris Mather: Yeah. This is still definitely in experimentation mode. What I'm really looking forward to is to working with people and trying things out and seeing how this goes. I can tell you what my conception of it is today, which is that the build tool can be used by itself. It's just a build tool after all, it's a complicated set of software. It produces an output that is a Node.js application and a browser bundle, a set of browser bundles. It doesn't require that the Elements application framework be there. The inverse is not true. The Elements application framework does require the build tool because there's features that are built into it that the application framework takes advantage of. That didn't exist in the open source ecosystem when I started this and it still doesn't today. Chris Mather: If you want to try the build tool on an existing project, I would love to hear from people who want to give that a go and just to see how it works for them. Depending upon how you've configured webpack, I think most of the main use cases are handled, but ebpack does have quite a few gnarly cases that it supports. We'll have to see what importing CSS and things like that, that people might run into. On the application framework itself, the main migration path, there is the routes. Once you do that, you can choose to bring on other parts of Elements. For example, the RPC framework is just simply calling functions on the server. You might choose to do that, or you might have one Restful GraphQL endpoint doing server side HTTP routes in Elements is super easy. You can have a server side routes only, but by default, the routes run in both places, the server and the browser. It's the only framework actually out there that just totally supports both right out of the box. There's no separate GitHub project that you have for your client app and a separate one for the servers is one thing. I guess that's the opposite of JAMstack. It's easy stack we should call it or something like this. Ben: I like to take a step back now and hear a bit more about your founder journey. You talked a bit about how this project came out of your work at Lively and you started basically solving your own problem you had building a full stack application. What has it been like going full time working on this project? Tell us about maybe some of your plans for the future as well. Chris Mather: Well, like I said, a little bit while ago, I think at my core, I'm a builder and I really like building tools. I just find it exciting. It's challenging. It's hard. It's a hard business to be in, right? You couldn't find a more difficult customer than developers and I love that challenge. The idea of building tools for craftspeople is very exciting to me. I take this very personally. One of the things I like to do for fun, I fly aircraft. If you go into a hangar and you look at the mechanics who are working on these aircraft, literally your life depends on the fact that they have good tools, they're highly trained professionals. They're not going to work with crappy tools. With web apps perhaps people's lives aren't literally depending on it, but certainly people are building their businesses on this. There's a lot of business activity, economics that depend on these things working. Chris Mather: To me, it's very important that developers are going to work and they feel happy about the tools that they're using. This is something that is personally important to me. My founder story is, I can rewind to not all the way back to the government work, but to Lively. I joined Lively, it was interesting. I was teaching and I was doing these online courses, which was super fun, but very exhausting. What happened was, you guys know, producing these podcasts or producing any kind of creative content, it's very tiring. At the end of the week, you're just exhausted and then to have to do it again. I did that for four years. I was trying to figure out, you know, different, clever ways to explain concepts and to teach algorithms. Chris Mather: It was a lot of fun. It was very hard on my family and I. Eventually it got to point a where it was like, it's time to go get a job where I'm not in charge. About at that point my friend reached out and he said, "Hey, we started this company." He was one of the founders. I was not a founder of Lively. They brought me on afterwards. He said, "We need a CTO." I said, "Yeah, I don't think so. I think I just want to go be like a drone for a couple of years." He said, "Come on this is serious." They went to Y Combinator, they got funding. They built an initial prototype. They were getting pretty far. I said, "Okay, well, I've been working on this thing called Elements and it's still a prototype, but this would be a great way to really put it to the test and make sure that ... " Chris Mather: I love research-y things. I love research and compilers, compiler theory, graph theory, things like that, are my research interests, but to build a framework that actually works for industrial strength applications, you have to have some North star, some kind of compass. This was the gnarliest compass I could think of was to be at a YC startup with a gun to my head. They're like, "Okay, you have three days to do the build tool." At first they said, "No." They said it's too risky. I said, "So is being a CTO of a startup." We went back and forth and eventually they said, "Okay, you can build it here." I ended up doing that and it was very hard, extremely hard. It was probably one of the hardest couple of years of my life in terms of work. Chris Mather: I was coding a crazy amount and the team was actually growing as well. The engineering team got quite large for a startup. I mean, it was two people and then all of a sudden it was 20 people. A couple of years went by, it was running on Elements and they said, "Okay, you've got to decide now, do you want to run this team? Or do you want to do Elements?" I chose Elements. Then I left and I went heads down for the next six months. That year I wrote 450,000 lines of code, which I didn't even believe at first. I just had to look at the number and it was like, and I actually tore a muscle that year. Actually, possibly in my shoulder. I was getting up at 6:00 AM. I was working till midnight. It was insane. That brought me up to last December and I picked my head up and I decided, "Okay, what am I going to do next?" That's when I started the fundraising process. Ben: Just curious, did you tear the muscle writing code or something unrelated? Chris Mather: I did, I was literally writing and I've got a crazy set up. You can't see it here, but I had like a special keyboard because I get RSI. I have one of those kineses keyboard. That helps a little bit, but I just got, if you do a repetitive motion enough, you can get these tiny little muscle movements and eventually you get a little tear and it was very painful. I'm like, a geeky athlete or something. Ben: Yeah, no, I think there's definitely not enough attention, a whole separate topic, but there's not enough attention to physical health paid for developers and any folks that are sitting at the computer all day. I think a lot of us working from home for the past year or so are starting to feel that. I certainly am. I just got a standing desk. Chris Mather: Take it very seriously, man. It's incredibly serious. You get to a point where you start to wonder whether it's reversible and that's terrifying. Get a proper keyboard, learn how to do the right setup for sure. Ben: I would be curious a bit about, you mentioned raising some money and as I understand it, you just recently did your public launch of Elements. I know in developer tools, a lot of what investors are looking for is growth metrics and users and open-source stars and you didn't have those things. I'm curious, what was your pitch to investors and how difficult did you find the process was to raise money? Chris Mather: I'll just tell the story from the beginning, it's not that long, hopefully. I raised money last year and I was actually pretty mixed on whether ... To give everyone context, I raised a few million dollars. This is the first time announcing it. So I guess here you go, this is the announcement. Ben: Congrats. Chris Mather: You heard it first on this podcast folks. But that was actually last year. I raised the money and then I just went heads down again for another year. It was very anticlimactic, but I've already worked on Elements by the time I started that fundraising process. Like I said, that year, I had written an enormous amount of code. It was working and I was very mixed about whether to raise money at all. I had this idea in my head that we have some savings. I want us to potentially bootstrap it. I wanted to build a long-term company that our grandkids will know about. Not something that is this chaos. Chris Mather: At least my idea of it was like creating this chaotic thing where we're constantly trying to hit impossible metrics. I came up last December and I thought, I'm building a real ... This is a software company that is pretty foundational in terms of the tooling and the app framework. I want companies to build on this. By the way, if you're a founder and you're starting a company, you should definitely build on top of Elements. That's my pitch to you definitely start on Elements. There's no better option. It'll change your life, do it immediately. But anyway, I decided that I did not want to start that process with a weak balance sheet. Chris Mather: I didn't want to have to go week to week, wondering whether we're going to make it. For me, the big pull for raising money is I want to be able to find good people, great computer scientists to work on this and pay them well to do great work. I think that's important. There's a lot of pathological outcomes that can come from raising money. We have to worry about that as well. I've always thought it was a little weird, honestly, you raise money and it's like, when you get a mortgage for a house or something, you just get it. You don't go out and have like a party. I mean, you might celebrate that you have a house. You have a house that you can raise a family or whatever you want to do in the house, but we don't celebrate the mortgage process. Chris Mather: But for whatever reason in startups, this ingredient is something that we look at as the end result. Anyway, I started in Silicon Valley because that was where my network was. Honestly, that didn't go terribly well. I started giving these demos and I did not know the right buzzwords, I guess, to say. I had a number of very unproductive meetings. Then I went to New York and I met these guys. As soon as I got into the meeting, it was honestly a fluke. It was an introduction from a friend of mine in New York. He said, "You should go meet these guys." The level of questions they were asking were good. They were coming from engineering backgrounds. One of the partners had worked for Bill Gates at Microsoft, had a PhD in electrical engineering. They're not necessarily familiar with this technology, but they knew to ask certain things. Chris Mather: It was a very productive meeting and I felt very energized. I remember walking out of that meeting and I already met with a ton of people prior to that. I was like, "These are the guys." I'm not meeting with anyone else. That whole thing from start to end took three weeks, which I'm told is fast but I don't have any comparables. I don't know. There was a bunch of emails. I didn't have a deck. I had a demo. I went in, I told my life story and I said, "Okay, it's done. Here it is. Do you want to see it?" We built an app together in real time. Then the rest of the process became a Dropbox paper. That was important to me because I wanted to collaborate with them rather than just giving a one dimensional presentation. Chris Mather: I didn't talk to anyone else. I brought a few other individuals into the round and these individuals are people I know who can give advice or are in the industry and know a little bit about it or people, there's one or two people that asked if they could get in. That was it. Then after I raised the money, I went heads down again for like another year. It was exciting to see the balance go up for like a day or two. Then after that, I went right back to work and I finished the product. It's just sort of a soft launch. It's available if people want to download it and try it out. Then this year we'll be fine tuning that and bringing together a core team. Ben: In terms of like growing the user base, what are your plans to build adoption? I mean, that's one of the biggest hurdles is to kind of achieve the, not necessarily hockey stick, but some amount of consistent user growth and getting companies to build on the platform. How are you thinking through that part of things? Chris Mather: Yeah, for sure. You had mentioned something else important earlier about GitHub stars and kind of how does open source play into this? This is a little bit of a weird project because it didn't start in open source. It actually started as a foundation to a business. In other words, we built our healthcare bank on it, and then now it's becoming an open source project later. It's a very mature, I guess, open source project, but without the stars yet. I've done a decent amount of open source work. I've had an open source project that was, back when Meteor was the thing I built the router for Meteor. That became a popular open source project. One of the things I learned about open source is that I think open source great. Make no mistake about it. I think open source is wonderful. Chris Mather: I remember back before we had open source and things were worse. I love that about it. I love that there's an open development model where you can interact with your users and they can open tickets. I think all that's great. I think building a product in the open is almost impossible. Your head space gets so filled with random things. This might be like an old metaphor that won't work for the audience. I don't know. Did you guys watch the Simpsons? Ben: Of course. Chris Mather: There was a Simpsons episode where they ask Homer to design a car. Do you guys remember there's the Homer car? Ben: No, no. Chris Mather: He keeps talking about like how bad things are and how he could do it better. They said, "Okay, you can design the car." He comes up with all these features that he wants, and it's a bazillion features. Before you know it, there's dongles hanging off the car every which way. He finally presents his final design and it's this ridiculous looking car that's terrible. It barely operates, nothing fits with anything else. I think that's what you end up with if you're not careful if you designed by committee. Designing by committee is something that I did not want to do. It's designed by thoughtfulness and by use case and having a North star, that's an actual application that we're building. When I started raising money, there was not an open source project to look at. I think the fact that I had been been around the block for so long was enough and the algorithms and structures and stuff that's in this are very heavy, very complicated. They saw all that working and it was like, okay. Probably being a CTO helped. Chris Mather: Then it was just conversations. You meet people and you interact with them and you kind of get a sense of, okay, is person jerking me around or does this seem right? But our plan for growth, what does that look like? First of all, it looks impossible from the vantage point today, it looks like there's so much stuff out there that this just simply won't work, but we'll see. I have another announcement. We'll start with that. This is the first time anyone's hearing it. I'm making it public, June 21st, I'm going to be a dad. Ben: Oh, congrats. That's huge. Chris Mather: Thank you. Very excited about this. I have a boy coming, hopefully, hopefully in the sense that nothing bad happens. That'll be in June. From now until June, what I'm going to do is I'm going to make lots and lots of videos. Every morning I'm going to get up and we're going to work through building various parts of an app, starting with something like login. How do you have a login that doesn't have any passwords? Just using email? That's going to be the first one that comes out. Then I'm going to walk, talk through how the various parts of Elements are made. How do you make a router? A really fast router, the fastest rider out there? How do you do it? What are the different parts of the build tool? What does it have to do? I'm going to kind of use that teaching experience that I had from before this, to go through the various parts of Elements. I'm hoping that that can help build some traction. The main hypothesis is that if you make this clear and you make it easier for people to make apps, that that will be enough because right now I think that when you go, it's like buying a car. Right now what the ecosystem wants of you is you go to buy the car and the car doesn't come with any wheels. Chris Mather: You're like, okay, I want to drive the car. That's my goal. Okay. You can get the car here, but it doesn't come with wheels, but I can't drive the car without the wheels. What do I have to do? They're like, "There's 5,000 wheel providers that are strewn all around California, and you need to go and figure out which one you want." That's the equivalent of what it's like to build an app today. I'm hoping that Elements is a solid platform for people to build their businesses on. I think it's the best modern web framework that exists out there out of all of them today. The fact that it combines the build tooling and everything with it, I think it makes for a great development experience. Unlike Meteor and some of the ones that came before this, it is totally compatible with Node. Chris Mather: It's not like a custom ecosystem, right? It's the tooling around it. The output on this build is a Node app, and you can run it like any node app. That's hopefully the difference that Elements makes. The application framework, I think it's important to open source that. There's some that have come out that are closed source. That was a decision I made early on that any code that gets integrated into your app, you should be able to see that code. The Elements application framework, it's not like the MIT license. There's some restrictions on it. Amazon can't go and create a service around it, but it's pretty open. You can look at the code, you can go see how it's made. Then some of the tooling will remain closed source for now. That might change later, but that's the model that I've got going. Chris Mather: One last thing. The business plan is to charge for the tooling. That's my current plan. That could change based on the alpha users and feedback. But my philosophy on that is that businesses should charge for the thing that they value and those incentives should be aligned. To me, what's important is the developer experience. That's the main thing. I don't want the company, our company to be focused on developer experience and selling ads or something weird on the side. It should be you're charging for that main thing. The most likely outcome here in the next couple of months is we'll charge for the tooling. Ben: It's interesting to hear the thought process. It sounds like a lot of these things are still being formed. The plan is still being made, but I mean, that's the cool thing about an early stage company. It'll be very exciting to follow along as you make the videos and you launch and undoubtedly will have a lot of success. Chris Mather: Thanks, Ben. Ben: I'm excited to cheer from the sidelines, I guess finally, for folks that want to get started, Elements.dev is the website. Anything else people should check out if they want to learn more? Chris Mather: Yeah. Start Elements.dev. That's the homepage. That'll give you a quick synopsis of the project. Again, in summary, this is an app framework for TypeScript. It's designed for TypeScript specifically. JavaScript will work too, but TypeScript integration, there's been quite a bit of work that's gone into making it really integrated with TypeScript. One last thing on that point, IES build for example, will link, but it won't do TypeScript compiling. It just ditches that part. This is all totally integrated. It'll compile, link, all those things. It works with TypeScript right out of the box. It's an app framework for TypeScript and a build tooling for TypeScript. You'll see all that summary on the homepage. Then the open source project for the app framework is linked on the homepage as well. You'll see that rather than memorize the GitHub project, just go to Elements.dev and click the link there. Chris Mather: To install it, it's got a little bit of a unique install process. I should probably explain that to users so they don't get scared. You put in an email address and it's not because I want to sell your email address to advertisers. It's because you have to install a binary. Elements is a binary and there's two builds one for Mac and one for Linux. I couldn't put it up on NPM. The installer actually installs based on the type of machine you have. The way that we do it is you put your email address in and then you get an email that has an installed link, that's custom for you. When you click the link, you'll get a script that you put into your terminal and you can install it from that. Then all the application packages and all that come like regular NPM packages. Ben: Got it. Finally, outside of Elements, what are you most excited about for the year ahead in the world of developer tooling? Chris Mather: I think what's the exciting app framework type thing is that we've seen a movement all the way to the client side. That came with it with some really great benefits, which was better user experience, JavaScript, nicely integrated. The developer user doesn't have to think as much about the divide between client server and all that. Or if you're doing a JAMstack, it's very clearly defined that it's separate. But that came with its own set of headaches, big bundle sizes. You don't get server-side rendering right out of the box. That becomes a new thing. I think one of the interesting things now is that we need apps that can just do both and the developer doesn't have to think about it. You get a server and you get a browser. I know server less is a big popular thing now, but I got to tell you, from the CTO perspective, or if you're a new entrepreneur or you're building an app, you have a server. You almost always do, and you have some functionality that you're going to have on the server. I think making that really easy for businesses and developers is the most important goal that I have. Ben: Cool. Well, Chris, thank you so much for coming on the podcast. To everyone out there, definitely go check out Elements and until next time. Chris Mather: Yeah. It's great to be on the show, Ben, I really appreciate you guys having me on. Brian: Hey, it's Brian again. It turns out that running a podcast is maybe harder than we thought. I kind of want to hear from you, I'm genuinely interested in your feedback. We have to think about new topics, new guests. We have to find them and don't get me wrong. We can do it, but it's a lot easier if everyone else who's listening helps. If you'd like to suggest the topic or volunteer to be on PodRocket, we'd like to hear from you. You can do that by going to PodRocket.LogRocket.com/contact-us. The hyphen is next to the delete key, if you're curious. If all of that is too long, you can just email me directly. Brian@LogRocket.com. That'd be great. Also if you're feeling magnanimous, be sure to like and subscribe to PodRocket. Thank you.