Steve and A.J. talk with Chris Mather, the creator of the Elements framework, a new monolith-style web framework for generating web apps. They discuss the reason for adding YAF (Yet Another Framework), the pieces that are used to build the framework, and how it all works together.

Panel

Guest

Sponsors

Links

Picks

Special Guest: Chris Mather.

Sponsored By:

STEVE_EDWARDS: Hello everybody and welcome to yet another exciting edition of JavaScript Jabber. I am Steve Edwards, your host with the Facebook radio and a voice for being a mime, but I am still your host. Today with me on our panel, we have AJ O'Neill. 

AJ_O’NEAL: Yo, yo, yo, coming at you live from the land of the snow. 

STEVE_EDWARDS: The snow, how much snow? A little bit of snow? A lot of snow? 

AJ_O’NEAL: Mmm, yeah, just a lot of little bits. 

STEVE_EDWARDS: That's little bits, yeah. We were supposedly supposed to get some here in the Valley floor in the Portland area, but it didn't happen to the disappointment of many. Anyway, our guest for today is one Chris Mather. How are you doing, Chris? 

CHRIS_MATHER: Great, I'm happy to be here. Thanks for having me. 

 

This episode is brought to you by Dexecure, a company that helps developers make websites load faster automatically. With DeckSecure, you no longer need to constantly chase new compression techniques. Let them do the work for you and focus on what you love doing, building products and features. Not only is DeckSecure easy to integrate, it makes your website 40% faster, increases website traffic, and better yet, your website running faster than your competitors. Visit decksecure.com slash JSJabber to learn more about how their products work.

 

STEVE_EDWARDS: Our pleasure, our pleasure. So to start out, why don't you give us a little background, who you are, why you're famous, your development history, so on and so forth. 

CHRIS_MATHER: Okay. I don't think I'm particularly famous. I guess I have a few claims to fame, but I started working in web a long time ago. Like when it first came out, when we would used to like figure out whether to develop for Internet Explorer versus Netscape, like that kind of time. I really, really love web development. I loved it from the very beginning. I just thought it seemed immediately obvious that this was a powerful platform. And when you build something for it, you have access to lots of users, you know, anywhere who can connect to it. And that was a very exciting idea to me. So I started doing web development and software development in general around like high school time. And then my first job, I was, I guess this is my claim to fame. I worked for the company that Edward Snowden worked at and it did similar work, but I didn't relocate to Moscow. I relocated to Silicon Valley. And instead of doing like 10 years of, I did that for about 10 years and then I came out, came out here. And so the next kind of stop along that path in Silicon Valley was I worked for a couple of companies, I ended up starting an education thing where I did. Math, computer science and web development videos. Uh, and I would publish them. I did that for about four years, learned a ton. It was really hardcore. It was really hard to do. Uh, anyone who's done content like you guys probably know, but that was like a subscription business. It was a nice small business, but very, very hard after four years of doing that. My wife was like ready to kill me. She was very supportive, but we were both like, okay, it's time to go work for a software company. And about that time, I started working on elements. It had been kind of a research project and then it evolved into a full blown web framework and build tooling. And instead of going to work for a big software company, I ended up going to... Some friends of mine started a company, a Y Combinator company, and they needed a CTO. So they asked me if I would do it. And at first I said, no, it's too risky. I have to go to the big mothership. That's the plan. And they, we ended up talking and continuing the conversation. Eventually I was like, you know, if you let me build elements here, then, then I'll do it. And they were like, no, no, that's, that's too risky. And I was like, yeah, but so was joining a startup. So we kind of went back and forth. Then eventually they agreed and I ended up building this web framework and, and build tooling while I was at this healthcare FinTech startup. So that's, I can tell you more about that, but that was its nexus. And then a couple of years after that, I left him, started elements as a full-time business. So Elements, by the way, is an app framework and build tool for TypeScript. I think it makes developing apps really fun again. It's kind of like the rails, I think, for the TypeScript and JavaScript community is my hope. 

STEVE_EDWARDS: Right, so Elements is what we are here to discuss today. So let's go back a little bit. When I was Googling you and on the internets, I noticed that you had done some classes like on Frontend Masters and other places on Meteor. So real quick, can you just talk about Meteor? We don't have to go into great detail and then about how maybe that give you a jumping point for Elements or any, any relation that they have between the two of them. 

AJ_O’NEAL: And Meteor is still a thing. 

STEVE_EDWARDS: Yes, very much so. 

CHRIS_MATHER: It is. Yeah. They sold it. The company behind Meteor sold it to Tiny Capital and they've been continuing to run it, but I haven't really been so involved with the community. So I'm not sure what's going on there, but yeah, Meteor definitely was influential. I think, you know, Elements is something that's been the culmination of my experience with web frameworks and the web since I started working in it. So Meteor wasn't the only influence, but certainly there was a lot of things that Meteor did that were, I thought were really cool. There's also a lot of things they did that I thought were awful, but, you know, so it goes. The thing that I really loved about it was the developer experience. They really, they really tried hard to make that everything from the very beginning to how you get going with the project and you could have something up and running very, very quickly. So that, so that, that, that kind of attention to the developer experience really caught my attention with Meteor. Some of the real-time features that they had were really cool too, and people latched onto that. There ended up being scalability problems with it, you know, over, over time. And there was some like pretty big missing features with Meteor right from the beginning, like a router, you know, and people were like, Hey, we're making web apps. They have URLs. And there was like no concept of URLs in Meteor. So there was some gaps in it, but I would say that Meteor was definitely an influence and it also helped me build my audience for my, for the education videos I was doing. So I did cover Meteor and the technology. And so I studied it quite a bit.

STEVE_EDWARDS: Okay, so there's Meteor. So why don't we start talking about elements? I guess my questions would be considering that there are, there's such a tiny amount of web frameworks and tools out there and you know, I can understand the need for just one more, uh, being facetious of course. So I guess what was your impetus for making elements and what needs do you see it being filled that aren't filled by the myriad of other web frameworks that are out there?

CHRIS_MATHER: Yeah. Well, I think, I think probably the best way to conceptualize this is to think about the timeline. This is kind of generally how I think about how we've evolved. So when we started off web development was, you know, in the beginning was kind of very simple, but then when we started trying to build apps, you know, back like with cold fusion and ASP.NET, there was some various frameworks that existed back then that people would use. And those were the ones that the government used a lot. And, you know, we got to this point where web development was this huge fiasco, right? Like any, anytime you want to do anything. You guys remember like enterprise Java beans and like crazy abstractions that and it was just nuts, right? Like, yeah, that's a great expression that I think encapsulates my feeling too. So, you know, if you want to do a hello world string, it's like, well, first grade, this Java being thing, you know, basically my way of saying it was, it was just insanity, right? It was very hard to get going. The learning curve was extremely steep. It's like you had to have a PhD in configuration to be able to even get a basic app going. 

AJ_O’NEAL: That's how I feel about React. 

CHRIS_MATHER: Yeah, well, you know, that's, that's where I'm getting at the arc of this, uh, this storyline for sure. So you think Rails came along somewhere along there. I became familiar with it a little after maybe 2007. And I think they started in maybe 2005, but I remember seeing that demo and it was like, wow, this is amazing. Like you can, you, you've got the whole thing, the full stack and you can get a basic blog going really, really quickly. 

STEVE_EDWARDS: And you know, I can remember going back to like ASP classic and PHP. You know, I first, I first, you know, like you, I started out straight basic HTML, I can still remember my first little family webpage on AT&B broadband space that they provided, you know, making multiple copies of photos and linking to them and all that kind of stuff. And then getting into PHP and making some websites that are insecure as hell. But you know, I communicated with the database, and then I displayed the data on a page and everybody was excited and happy. The irony, this is so funny, you know, some of that stuff, it's amazing how long some of that stuff exists. I was at a previous job, I was at this huge multinational billion dollar corporation. And part of my task was replacing a internal web tool that was built in ASP classic and a very old version of Microsoft SQL server. I mean, this was in 2017. 

CHRIS_MATHER: Okay. Sure. 

STEVE_EDWARDS: And the only reason they were getting rid of it was because Microsoft had no support for these anymore and it was held together by glue and paper clips.

CHRIS_MATHER: Yeah. Yeah. 

STEVE_EDWARDS: So some of that enterprise stuff was used for enterprise stuff that still went on for years, decades. 

CHRIS_MATHER: Well, it has so much staying power because it's hard to reason about these things after a while, right? I mean, there's just so much code and logic in there that it's almost faster just to redo it. But then, you know, oh goodness, there's going to be a million use cases that are embedded in this code that we forgot about. So we're going to redo the whole thing. It's going to cost a fortune. We're not going to have it we're going to miss like 20% of the use cases. So I think they have a way of sticking around for multiple decades. 

STEVE_EDWARDS: Right, so sorry to interrupt. So anyway, getting into elements then. 

CHRIS_MATHER: Yeah, sure. So yeah, it's a good blast from the past. It's interesting. It sounds like we have a lot of overlap there in our histories, but. So I thought Rails were really cool. I think that Ruby was a great language. I think people really love the language. It has some issues that come to you later, but I thought it was really kind of aesthetically, it was really pleasing to write code in in Ruby, and you could move really, really fast. So as a builder, it felt like you were making a lot of forward progress, right? You're working on a Rails app, you're constantly moving forward, and that's a very good feeling as a builder to not get held up by your tools. So fast forward a little bit to like around Meteor and React and some of the things that are going on maybe five to eight years later. Well, Node.js comes out, so that's one thing. Now all of a sudden we can have JavaScript on the server and end in the browser. And then we get which is, wasn't really a new concept, as you guys I'm sure know, but you know, back in the nineties, HyperCard had reactive user interfaces and this idea of an event loop which had been around for a while. But it was nice because suddenly we could build these user interfaces that automatically updated as a result of data changes rather than having to go and say, okay, now update this DOM element and this DOM element. And that, I think there was some magic in that. JavaScript then becomes this thing where you can get all this kind of really fancy user interfaces, you know, using React and using some of the front end technologies in JavaScript. But the overall app building experience, I feel like has gotten just so awful. This is to AJ's point. It feels like we're back in enterprise Java bean land where, you know, just to get it, there's so many, it's just buzzword bingo out there. And I don't want to be rude. And I love innovation. So let me caveat with that. I love experimentation. I think it's great. And I've done a good amount of open source and it's very nerve-wracking to put something out in the open and be criticized for it, right? But I very much like that people are doing that. But on the other hand, 

AJ_O’NEAL: Well, I want to say it's, you're doing a great job if you're gaining enough traction to get criticized. 

CHRIS_MATHER: Sure, sure. 

AJ_O’NEAL: I mean, like that's, getting criticized is a good first step to having something successful enough that anyone pays attention at all. 

CHRIS_MATHER: Yeah, that's true. That's true. Getting criticism is a signal, at least. But, you know, one of the things that's happened though, is that I think it's very hard to make sense of anything anymore. Like it kind of feels like we're so far away from the primitives and we're so far away. And those are good, some good primitives, you know, to work with, you know, we've got HTML, you've got CSS, you got to connect to a database, you got to get some data onto the front end. Like, how do we do this? It feels like you have to go get a master's degree in this to be able to get the darn thing running again, which is insane. So I started thinking about elements and first from the perspective of open source, let me tell you what I mean. So I think oftentimes open source, you pick a project to work on, right? And you kind of look at that ecosystem of projects and you don't want to overlap too much with what other people are doing. So you pick something kind of niche and you go and you just solve that. And it has a lot of appeal doing this, but what ends up happening is you have this sort of a lot of fragmentation and it's really hard to piece it all together. So it's kind of like, if you're the user of this, you're going to buy a car. You buy the car and it doesn't come with any wheels. And you're like, I can't drive the car. And they're like, yeah, but there's like 5,000 wheel providers, all you have to do is go find one. Don't worry, they're all good. Good luck. That's what it feels like to me to build a web app. So when I started building elements, I thought, okay, it needs to meet a couple of requirements. One is I'm not going to care about what exists. I know this is sacrilegious, but it is like, I'm going to focus only on what do we need to build an app and I'm going to do everything from that perspective. And then the second was it's got to be, the app development experience has to be very fast. It has to be good enough so that a startup or a single individual can do something really, really quickly, but it scales up to be an enterprise size bank application if it needs to be. Like at Lively, it was a HIPAA compliant, HIPAA compliant FinTech company where we started with two engineers within a couple of years, a hundred million dollars that had been processed through the system. We had lots and lots of users. It has to be, you know, we can't lose their money at all. We can't even lose a little bit of it. So it had to meet all those kinds of enterprisey requirements. And then there was a number of technical challenges as well. Like when you're building an app today, you have a server and you have the browser. And what a lot of the frameworks do is they separate those two to just make the problem go away because the build tools don't do a good job of dealing with both the server and the browser. So they say, well, you just have an API endpoint, a server, and then you have a separate thing as a browser. But when you're building an app, that like really slows you down. So what do the elements does is in the build tooling, it builds for both the server and the browser targets. And so that the two can work together really, really well. So elements has a couple of features that make development really fast. Like it has the rail scaffolding type of things that you'd expect. The build tooling is really, really fast. It's integrated very deeply with TypeScript. So TypeScript is our first class citizen from the beginning. You can still do your stuff in JavaScript if you want, and then just pick off the features that you want from TypeScript, but it's got really great support for TypeScript. The compiler messages are really clear. So as you're writing code and you save the file immediately, it's just, you're getting any errors, a red status that says error, green status that says okay, and the hot reloading in the browser is really good. So as you're developing, you're seeing the browser actually update live. And so that's the kind of, to give you a sense of it, the development experience developments that has been going on. I started it about five years ago, so it's been a pretty long project. So I'm excited to finally kind of get it out there. I did the opposite of what most people do. I didn't do it in the open. I kind of did it at a startup and now I'm bringing it out into the open. So we'll see how it goes. 

AJ_O’NEAL: So why use node rather than Dino if you're going to be doing, you know, TypeScript and you're trying to be modern and you're not, you know, trying to not necessarily be beholden to what's out there. I mean, it seems like Dino is just. It's a better platform. It's gotten strong leadership, uh, somebody who's making decisions on purpose rather than by committee and it's got, uh, some of the modules are not quite all the way up there, but mostly stuff that most people don't use, like the crypto module, for example, so why, why stick with the old guard when you could go full on with the new and, and honestly just better. 

CHRIS_MATHER: Yeah. There's a lot to like about, you know, I, I, um, It was a hard decision, I'll say that. So, and it's not a final decision. I mean, it's still something I could do in the future. The elements isn't totally tied to Node. Where it gets tied to Node is in the runtime libraries of the application framework. So for example, using the FS module of Node.js and things like that. The build tool itself could work with any framework. It just produces outputs, JSON files, JavaScript files, a build manifest, things like that. And that could theoretically work on any runtime. In fact, as a quick side, I had actually built my own runtime as one of the R and D parts of this project was to use VA separately and to build it from scratch all the way up. And I eventually abandoned that. No, I didn't abandon it. It was actually working. It was more of a marketing decision. And I just thought it's going to be a really hard sell to get people to, to like try this new runtime, but between Dino and, and am I pronouncing it right? I always feel like I'm pronouncing it incorrectly. 

AJ_O’NEAL: So, you know, some people pronounce it Dino, but they're wrong because it's Dino like the dinosaur. 

CHRIS_MATHER: Like the dinosaur. Perfect.

AJ_O’NEAL: I think Ryan Dahl himself pronounces it Deno, but again, you know, we all make mistakes. He's confused. 

CHRIS_MATHER: Okay. Well, you know, I, so I did some research on it and I spent a couple of days looking at it, I think it's really cool project. It ultimately came down to just install base and newness. And so it was, it was something where the runtime is, is something where. Unlike like with the build tool, I can write my own compilers. I can write my own graph algorithms. I can do all that kind of stuff to make all the tooling around the runtime really, really good. So I'm not going to go use some library to do some string manipulation, like that kind of stuff. And I'm not going to use the library to do ASD parsing, just do that from scratch. But when it comes to the runtime that people's apps are built on, Node.js just has a really large install base. So it came down to just kind of the safety of that. But you know, that could end up being the wrong decision. It could end up being that I support both over time. There's a lot of things I don't like about Node, that's for sure. 

AJ_O’NEAL: I don't know how much you've checked it out, but I'd say check out Dino because it so for every platform that's supported, it's very easy to make a Dino app that doesn't have any of the dependency hell that doesn't, I mean, it's just, it's just modern, you know? Like it, anyway, that's, that's maybe a different discussion, but I love to work with those guys. 

CHRIS_MATHER: I said, I'd love to work with those guys. You know, I'll check it out again. 

AJ_O’NEAL: Yeah. Cause I think like if I was going to build something new and I wanted it to be really easy for people to ha to handle and manage, I wouldn't go with node nodes, got all the security vulnerabilities with these NPM packages that are quasi monitored and, and just like, it just sucks when you, you have to download something that's already a hundred megabytes and then you have to end PM install and it's a thousand packages. And if you do something so streamlined with like what you're doing, I mean, if it, if, if I'm not doing what you're doing, but if I were doing what you're doing and I was starting from scratch and I was saying, okay, let's just make this clean and streamlined and simple. Dino seems like the choice to use because I don't remember what the command is, but it's, it's basically like Dino pack or Dino deploy. And then it gives you an executable for that platform. That's just like one binary file, double click it. And essentially what it is is just the Dino binary concatenated with a zip file and it knows it's binary size. So it knows that all the bytes afterwards are the zip file. It's like that type of thing. Um, but there's, there's stuff for node like that too. Anyway, I don't want to be real too much, but

CHRIS_MATHER: Yeah, no, totally. It's a great point. I'd love to look at it more. One of the points you touched on there was just some of the problems that you have with lots of packages. And, and so I think elements actually goes the long way towards, towards taking a stab at this. You know, so first the elements application framework has everything you need to build an app. The only, the, I really try to make it so that out of the box, the car has damn wheels, right? If you want to replace the database, you know, put the Postgres experience of, I'll use this as an example, the Postgres experience is I think really good. So it's, this is my, maybe contrary in opinion these days, but I think SQL is great. I actually think they did a good job with it for the most part. It's, it's got a lot of doodongles off it, but if you just stick to the basic algebraic sets, you can do an awful lot with data. So I went with Postgres on that on the backend for, for the database as the default, but so you get strongly typed SQL and you work with rows of data versus with models, uh, and that works really well for us at Lively, you know, a lot of times what we're trying to do is to get a list of data or trying to get a detailed view, that's often what we see, right in the web, but some people might want to use Mongo. They might want to use, you know, some other thing and that's fine. You can plug it in, but everything you need is at least the, there's good defaults that are there. The packages. So let me take a detour here. So the packages and like how you deal with performance in elements is like a really big deal. So elements apps are fast. They're really fast. One of the ways that it does that is when you install packages, you have to link them up so that they can actually, you know, go to the browser. So how you actually link them up is a big deal. Like how the strategy for doing that so the way that elements works is that all the packages get their own URL. And those URLs are all HTTP cached. So the caching elements is really good. And for any asset URL, it tells the browser, Hey, you can keep this guy for six months, don't even come back to the server. And the way it works is it has a version query parameter at the end of the URL. And that version parameters, the function of the contents of the build and all the dependencies of that, of that file. So if anything changes in it whatsoever, the version will change and the HTML file will now have a new asset URL and that busts the cache. So there's no weird cache busting that you have to do. And then on the HTML pages themselves, it uses eTags and HTTP headers as well to say, the browser has to go make one trip to the server and say, has this HTML page changed since the last time I looked at it? And if not, then I'll use the one I've got locally. Otherwise I'll get a new page. The build tool then, one more step in this, will automatically convert all the URLs. So like, let's say you have a URL to app images, bg.ping, you know, some kind of background image. It'll convert that URL to a cloud front URL automatically as a compile step. So what ends up happening is you have cloud front or whatever CDN you're using can host your assets. You have an origin server with all your routes. And once your assets get served, they pretty much just stay in the browser. So as you're navigating around in the browser, it's really, really fast. And the final point here is the router works in both the server and in the browser. So the pages are initially rendered on the server. And then once you get into the browser, you stay in the browser. And what it does is it just hot patches the head section with the resources required for that particular page. And it goes back and grabs those. So when you connect that together, the HTTP caching with a router that works in the server, in the browser and really fast rendering system, it's, it's this kind of magical experience. So that's my pitch for fast rendering for elements. And right now it's built with react by default, but I'm really looking forward to getting Vue.js in there. And maybe down the road, there's some R and D I've been doing on actually elements started as a UI language. So that's another, another thing. 

STEVE_EDWARDS: Okay. So as a front end person, let's go back to that real quick. You said it's built with react. So any of your front end, 

CHRIS_MATHER: you say it's built with react. I always find it strange, but we actually, it's a very small part of elements, right? Just does the rendering of the UIs, but react is the view rendering engine by default. 

STEVE_EDWARDS: Okay. That, that was what I was going to ask. 

CHRIS_MATHER: Yeah. 

AJ_O’NEAL: And so when you say react, I'm guessing you don't mean react in the way that most people mean it as in a huge system of thousands of dependencies, but like you're talking about like some core library that is fairly lightweight. 

CHRIS_MATHER: Yeah. You know, what, what you do is you, uh, it's just the react and JSX runtimes. So I know react has like its own community of all sorts of things you can latch onto, but what I'm interested in is the reactive user interfaces and nothing else. So you create a react component like you always have, you export it as the default from your page. The routing and elements is in code. So you write your route in code and you say this.render and you give it a path to a page, which is just a React component. And you returned some JSX scripts, you know, in the render function and it's just a regular React component. But you can imagine a Vue.js component would work well there as well. It's just a little bit of a Surface player to integrate it. 

STEVE_EDWARDS: Okay, so if I want to use elements to create my own, you know, super duper application. So the reading through the GitHub, read me, it looks like you can plug in various databases. Like I think the default is Postgres. You said that you can plug in other databases, which ones can be used? 

CHRIS_MATHER: Anything, anything you can install. I, I use Postgres personally, and that's what we've used at most companies that I've worked at, either Postgres or some version of some SQL variant. I've used Mongo as well. I happen to prefer SQL over Mongo or Postgres over Mongo. But you can plug in any server-side database framework you want. In an elements application, there's a main app index file, and that goes to the browser and on the server. And then there's a separate file called server.ts and you can put all server-only related things there. And there's one more construct I haven't talked about, which is services. I needed a name for it, so I call it services. Basically, what this is, is there's a folder in your app directory called services. Any functions that are exported from any file in that directory become like RPC functions that you can call over the wire. And these are only on the server. So the compile step will make sure that the browser call of that function becomes an RPC call automatically. And then on the server, that those service functions can interact with your database. So it's a nice kind of thin layer between the database and the calling, you know, view code. And you have session available in those services as well. So you can see whether the user is authenticated and all that kind of jazz that you would normally do. So that's kind of the basic default story. If you wanna create RESTful endpoints, or like, let's say you wanna hook up a GraphQL endpoint, you can do that too. I wouldn't start that way personally, but if somebody wants to do that, they can. 

STEVE_EDWARDS: Okay, so in terms of routing, let's go back to routing real quick. Yeah. Still trying to get my head around how the backend's working with the frontend here. I'm so used to working with frontend apps where I have some sort of RESTful API endpoint, and that's how I'm making my calls to wherever the backend, but this seems to be a little more seamless than that. So if I'm in my...You know, I'm in my react component or whatever my front end component. As I want to get data, I'm using RPCs that are generated by the backend. Is that correct? 

CHRIS_MATHER: Yeah. So if you want to do the default of what elements comes with, you just import a function and you call it just like you would call any function. And, and the only special thing is that you have to import functions from the services directory. So those are, those are called your services and, and you can think of them as like your backend endpoints. But rather than have to use some library to call them or like it should be call the function directly. Now, let's say you want to use a REST client instead. You can do that if you want. So in your React component, instead of just calling the function, importing and calling it, that's the easy path. But you can make a GET request or any REST request to the backend and that will work as well. The key thing with elements is that the view works on the server and it also works in the browser. So let's say you do a curl request or you go directly to the page for the first time or Google search engine goes and tries to hit your page that page is going to render with data and the data is going to be like serialized into the page so that once it gets to the browser, it just hydrates rather than like doing a whole re-render again. So the data works seamlessly on the server and the browser. And then once you get interested in the browser, like let's say you start clicking around links, you don't in elements need any special link tag or just use anchor tags, just like regular HTML. It intercepts the clicks and then it says, okay, you're trying to go to this page now. It'll hop past the sections that it needs to in the head and you just go there. And it's very, very, very awesome. I feel like I'm just kind of getting excited about my toy now. Sorry. I go off on these tangents. Just interrupt me if you need to. 

SSTEVE_EDWARDS: Yeah. I think, you know, for those that can't see him on video, his arms are going to be very tired by the time I get to the end of this podcast. 

CHRIS_MATHER: Yeah. I'm very excited by this. It's fun to work with elements. I've been having, I'm starting to actually use it now for, you know, my, my sites and I'm working on the boilerplate. I'm working. Your elements, the site itself is actually a video site. I'm going to publish video and contents to it. So I'm building a lot with elements on a daily basis and it's super fun. It reminds me of why I got into web development in the first place. 

AJ_O’NEAL: So I am not really familiar with react. I am, I am actually just learning it more in the style of needing to understand it, to understand the ecosystem and how to provide some leadership in area or in projects where react is being used. Um, cause I think that, uh, even I, the commercial that I am have to admit that at this point, uh, if I'm not doing that, then I'm lacking a skill that makes me less, less valuable. But anyway, I'm not super familiar with it, but what I would say is that Reacts so whereas say view an angular, much more of the declarative approach on the template side. Like you write a template that looks like a template react feels more. Like, or actually let me back up. I think I'm so with, with something like, let's say mustaches, like the quintessential view template system, it's, it's like the most basic that you can get. So with something like mustache or EJS, EJS is similar. When I put some data into a component or controller or whatever you want to call it. It's very clear. Like how it's going to loop over the data and produce the output. And I feel that way with Angular and view as well, or at least what they were when I used to use them, which granted was years ago, but with react, it looks very much like it's very imperative. Like you're writing code that is, you know, one function is going to return a thing and the other thing is going to return a thing. So it's not like you're looking at a sheet of, of template. It's like, you're looking at functions that are returning other functions that are building template. And so I see here, just looking at the docs, you've got this render function and you're passing in an object and you said that you're using react to pre-render that, and just because I am not familiar at all with server-side react to me, and that looks like just the way I do it with EJS or with mustache or with like a more, a more traditional style template system. How is that working with react, which like you, I mean, so far what I've learned is you call functions and it, and it generates components. So what is that render thing looking like if it's using react under the hood? 

CHRIS_MATHER: Yeah. So to kind of orient the audience, I I'm looking at least, and I think you might be looking at this as well. If you go to the github.com elements code for slash application, scroll down a little bit to the section on routing. 

AJ_O’NEAL: Yes.

CHRIS_MATHER: Yeah, there's a page router page and it's a product colon ID. So kind of a standard, you know, show route for some, some resource. Uh, and then the first thing that's happening, the first line there is that it's just calling this function, get product and passing the ID. That's an example of a service function that we've been talking about. And it awaits it. Uh, await is one of the things that really kills me about, uh, no JS by the way, but you, you await that the results of this, uh, you can get a product and then you set the product in the title and description meta, and then you, you tell elements, what React component or what page do you want to render? Just give it a project relative path to it. And you pass this initial data. So to your question, what's happening here is that, and this could be React, it could be EGS, it could be any user interface library is that we have some data initially. In React, they would call it initial props. But this is just initial data that we've got from the database that we want to populate the view with. That works here by when you create on the back end, if you were just to use the React. Sorry, I'm overloading the term back end. But if you were to just use the React APIs, sort of behind the scenes is a better way to say this. What we're doing is we're creating a new instance of the React component. And when you do that, you have the opportunity to pass initial properties. And that's what's happening here. You get those initial property values. And the magic with reactive engines, I think this is the main magic, if you were to abstract beyond the implementations and just look at what's special about Vue.js, React, any of these things, is that they're reactive. So As you're responding to events, a click event handler, for example, you can update the data and then the user interface will update to reflect that new. It's sort of like one level of indirection. But it turns out that working this way is kind of intuitive. Like if you change the data, now I want the screen to reflect the change. So you mentioned mustache, so you could imagine having a mustache data property in your thing that says product.name or something like that. And if that name changes, I just want the UI to update. 

AJ_O’NEAL: Yeah.

CHRIS_MATHER: That still works the same way here in react. So if you have an event handler, you just say this dot set on that react, and then the state will update. So the data here in your route is your initial data. 

AJ_O’NEAL: Okay. So are you telling me when I'm using the render function here and I've got the example is looks like a file path app pages product. So this, that product is my JSX file. That's my JSX component.

CHRIS_MATHER: Yeah. So that path there is going to be, it's kind of like a node path where it's actually a folder. So in AppPages product is a folder and inside the folder is three files. There's a index.tsx, that's going to be your React component. There's an index.css, that's going to be the CSS file for the component. So that's it. We'll come back to that again. Let me drop a bookmark though. CSS is a first-class citizen in elements. It works really, really well. It's one of my favorite things about it. 

AJ_O’NEAL: That's really weird for a backend-ish framework.

CHRIS_MATHER: Well, it's both, it's both. It's a, I think it's full stack. It's the legitimate full stack. 

AJ_O’NEAL: Yeah. It's just, I, no one would ever say CSS is a first-class citizen and express, right? So it's a new concept to me. Oh, but keep going. I wouldn't, 

CHRIS_MATHER: but yeah, we're building apps and CSS is a big part of building apps, you know, so it's got to be, it's got to work well, I think, in my opinion. 

AJ_O’NEAL: Well, yeah, yeah. I get, I get the whole, like you're looking, you're taking the more modern approach of, of components having a TSX file, a CSS file, and what's the other file that's in here? 

CHRIS_MATHER: A types file. And that you can use or not use, but the reason for the types file is if you want to strongly type your views, you can. And that makes it, I think if you're working with a team, and this actually comes back to an initial point, let me just go down this rabbit hole just for a second. 

AJ_O’NEAL: Sure. 

CHRIS_MATHER: I love Ruby. So Ruby, I think is a wonderful language. I think everyone should learn Ruby. But, and some people will kill me for this, but I do think it gets a bit hard to work in a big Ruby project if you have a really large team or even just a mid-sized team, it starts to get a bit unruly. You've got to have quite a few tests and things like that. And compiler can really help here if the tooling isn't outrageously slow and it doesn't get in your way. And we're working in TypeScript I found has been really helpful. You just sleep better at night. So like when I was the CTO of Lively, we had a team of, you know, a bunch of engineers. And before TypeScript, we were in JavaScript and we would get all these kind of runtime undefined values and things that would happen that would trip up the production system. And in TypeScript, most of those things tend to just go away because the compiler catches it and says, Hey, this is not the right value type for this thing. Well, 

AJ_O’NEAL: I think to that, to that point, I think that the JavaScript has, it was in the right space for what it was. 

CHRIS_MATHER: Wait, Ruby or JavaScript? Java

AJ_O’NEAL: Script. 

CHRIS_MATHER: Okay. 

AJ_O’NEAL: JavaScript. But the way that people use JavaScript today is not JavaScripty. And so when you're dealing with a lot of these things where it's not you're not scripting anymore. You're not, it's, it's not lightweight. It's, you know, things are a lot bigger. There are a lot, there's a lot more to them. And so I think that for the, if you're going to program in this, this style of, I think it makes sense to have something like TypeScript because you actually intended to have types the whole time. Like JavaScript is great for things where you're dealing with data that's untyped and you want to just much things together. Like I think that node is excellent for being able to patch together APIs because with APIs, you know, you often, sometimes a value is a string and other time it's well, hopefully it's always a string if it's a string, but you know, you, you end up in situations where maybe sometimes something's an array or sometimes it's a single problem. 

CHRIS_MATHER: Yeah, yeah, for sure. And you can make great APIs that way where you have different type to come in. I was very skeptical of TypeScript in the beginning, uh, because it, you know, reminds me of working in Java and just the kind of insanity of that, right? You had to create a factory to create a string, this kind of nonsense. And I think, yeah, I feel like in TypeScript, you can get pretty wild with it. Like if you really get into like the mathematical language, some people are really into that and I, you know, God bless them, but I use TypeScript, the main features of it. So, and I find that the in app development, and this is the big litmus test for me is does it make me more productive or not? Does it slow me down ultimately? Now it can slow me down if it has a team benefit and the team benefit is sufficient enough to justify the slowdown. But I'm very skeptical of this type of thing. So if it is in TypeScript, I was amazed if you have the right tooling, it not only doesn't slow you down, it speeds you up. I often use it as a checklist, especially if I'm really tired and I'm just working and I'm like, okay, is this going to am I done with my work yet? And it's done when the compiler, namely elements will actually give you a green okay status when you know you're, when you're done, you know, everything's okay. And that's actually most of the time it covers most of the things that you have to do, but I try not to overuse it. You know, you can get really crazy with it, but they did a really nice job with like having multiple types, for example, a value could be three or four different types of types and you can always default to any if you're not sure. And you can incrementally adopt it. So you can start with those words. If you have the right tool and you can incrementally adopt it. 

AJ_O’NEAL: No, no, I meant the part about the any.

CHRIS_MATHER: Oh yeah, yeah, yeah. Some people, I guess, 

AJ_O’NEAL: it's too bad. Amy's not here to beat you with the stick. 

CHRIS_MATHER: Oh, she doesn't like any. 

AJ_O’NEAL: Well, I, I've only heard bad things about any. 

CHRIS_MATHER: Well, it's the get out of jail free card. 

AJ_O’NEAL: Any, you know, I think it's more like the get in jail free card. That's the way I've heard it. 

CHRIS_MATHER: I see. Okay. 

 

Have you ever wondered if you could be offering a faster, less buggy experience for your customers? I mean, let's face it. The only way you're going to know that is by actually running it on production. So go figure it out, right? You run it on production, but you need something plugged in so that you can find out where those issues are, where it's slowing down, where it's having bugs. You just, you need something like that there. And Ray Gun is awesome at this. They just added the performance monitoring, which is really slick and it works like a breeze. I just, I love it. I love it. It's like, it's like you get the ray gun and you zap the bugs. It's anyway, definitely go check it out. It's going to save you a ton of time, a ton of money, a ton of sanity. I mean, let's face it, grepping through logs is no fun and having people not able to tell you that it's too slow because they got sidetracked into Twitter is also not fun. So go check out ray gun. They are definitely going to help you out. There are thousands of customer centric customer focused software companies who use Raygun every day to deliver great experiences for their customers. And if you go to Raygun and use our link, you can get a 14 day free trial. So you can go check that out at javascriptjabber.com slash raygun. 

 

CHRIS_MATHER: Yeah, I don't know where we started on this, but that was, so there's some things I think that the language, I, there's some things I don't like about the language that are certainly kind of hairy points, but I think overall, I like the language. Did the best I could with it with the, with the elements application framework. And I think the use, the user experience is pretty good for the app framework. You know, I tried to. To make it as polished as I could for the types of things that we want to do as app developers. 

AJ_O’NEAL: So I, I want to make sure the listeners know that I haven't sold my soul because I'm speaking positively about things like TypeScript and, you know, react to some, you have a reputation to maintain. Yeah. I have a reputation to maintain. So again, like I think what you're doing here is you're trying to create a system. You're not trying to subvert the existing system. You're trying to explore and to create a better system. And so, uh, that's, that's where, where my, I get upset when people are trying to, I guess it doesn't matter, but this, this is the kind of thing where it's like, if you're going to try something new, if you're going to explore, if you're going to really rethink it, you're not trying to tear down, you know, You're not trying to ruin something that works well for what it works well for. You're trying to explore a different area. And I think that it is good to look at the various technology options and whatnot. If you're, you know, if you accept that you're in a different space of working and that's, I mean, it very much sounds like the whole time you've been talking about this elements is it is a, it is in that space of something that is new and blossoming and not trying to fit. Not trying to shim over a previous mold. 

CHRIS_MATHER: Yeah. I'm glad you expounded. There was, there's a couple of dimensions of things that you mentioned there. Yeah. Subverting is an interesting word. It depends on what, what we're talking about, but you know, I think you're right ultimately that the thing with elements, like I think the first thing, the first topic that's interesting is when you're building something like this, you get one approach is like go into your basement and you come up with some like new paradigm, right? And you spend like 10 years there. And I'm not going to name any names, but there's at least one startup that did this, you know, the guy went off for like years and like he came out and it was like this totally different way of doing backend development. And this, and everyone was like, what are you talking about? What is this thing? Like this is not how we conceptualize building apps. So I don't think that's the right approach. I think that there's a, the other side of the spectrum, which is there's a lot of experimentation and there's all kinds of projects out there that you can kind of draw on. And I think that what I try to do is to solve the problems. And so like I have no problem reusing something or, or you know, bringing something in if it, if it solves the problem really well. And sometimes, you know, like for example, I told you with elements, uh, it started off as a UI language and it actually got all the way to implementation. So it has, uh, something, but I just ended up tabling it for now. 

AJ_O’NEAL: By the way, sorry, we're going on another tangent here for a second, but this will be quick. What do you mean? Uh, what did you call it? A UI language? 

CHRIS_MATHER: Yeah. So like a Vue JS or a react elements had one of those to start with. That's actually where it began, but I tabled it.

AJ_O’NEAL: Okay. Cause I was, when I think I didn't know what UI language meant and my first thought was Xcode cause that is like very much. Yeah. Go on. 

CHRIS_MATHER: Like a, like a superset of HTML, kind of like if you're going to do a Vue.js template, I think of that as the HTML language is, you know, maybe the term is, is overloaded a bit, but mostly that. I wasn't familiar with it anyway. So mostly the engine, you know, the reactive engine, there's certain things that react, for example, that annoy me. Uh, that think are like overly obtuse or complex. You know, particularly if you get into the whole React ecosystem, I think it's like pretty wild. I mean, if you're, if you're trying to get into this, you might start to think that you don't know what you're talking about, or this is way too complicated or whatever or not. I think that, that like React can be very confusing. And I think you, you brought up, you brought up a point earlier about kind of, if I could paraphrase for you, spaghetti code nature of it. 

AJ_O’NEAL: Oh, sorry. Say that again. 

CHRIS_MATHER: This kind of spaghetti code, like you can end up with like very complicated.

AJ_O’NEAL: Well, I think that it's true of anything. It's true of anything. Cause like you have a team and the team has a certain ethos and the team is successful executing on their ethos and building their products. And then because that team becomes successful at something, I mean, this, it was true of angular, this is true of react, this is true of lots of things. And then all of a sudden it becomes like, well, this is a magic bullet and everybody needs to do this. 

CHRIS_MATHER: Yeah. 

AJ_O’NEAL: But then a lot of people's brains don't work that way or a lot of teams don't function that way. And so they adopt a tool based on like the gods of the internet have blessed this. And then they don't actually follow the rules and the ethos. And so they end up like, I saw this a lot when I was working with a company that had decided to adopt Go, but everybody in the company hated Go. It was like a strategic decision to adopt Go. And so people wrote terrible go code and then they complained about how bad go was. And it was like, well, you didn't like it. You didn't choose it for the reasons that any one who built it would have chosen it and you did a really bad job. 

CHRIS_MATHER: Yeah. 

AJ_O’NEAL: So no wonder you hate what you've created. Right. And I think the same thing could be true of angular, could be true of react, could be true. A lot of things. If you, if you come into a system as an outsider and you don't get yourself acquainted with why the people built it and what it is supposed to be good for. And you just start, you know, hacking away. You're going to write really crappy React code that ends up being spaghetti code. 

CHRIS_MATHER: Well, yeah. And with, with React, well, your points resonate a lot with me, one, because elements, the core tooling is written in Go. So I've got a lot to say about that. But then I've also worked in TypeScript because all the application framework stuff is in TypeScript and all that packages are about 20 packages that comprise the ecosystem of the app framework. And that that's all TypeScript. I got to say, by the way, working in TypeScript is awesome. Like I love working in JavaScript at the app level. There's no way I would want to build an app in Go. To me, that would just be like a nightmare. But as a systems language, it's really good. It's got, you know, very good libraries. It's very black and white in terms of how they, you know, the APIs are very clear cut. Documentation is very good. So like as a systems and it compiles easily for Linux and for Mac and for windows and all that, so that, that part's really great. But I got to say, when I go from Go after a while of being in Go, going back up to the application land, it feels really nice. It's like a, it's refreshing. 

AJ_O’NEAL: What do you mean? What do you mean application land? 

CHRIS_MATHER: Like the application framework or even building applications on the application framework where I'm working in TypeScript. 

AJ_O’NEAL: So I'm going to try to clarify here. You mean when you're working in some sort of UI layer? 

CHRIS_MATHER: No, the whole app, like, you know, imagine working in a Rails app, but you're working in elements and you're working in TypeScript. I like the feeling of the code at the application layer. Whether it's front end or back end, doesn't matter. In, in Go, I feel like when I'm writing in the systems level, when I'm writing compilers or I'm working with graphs or whatever, like with the build tooling, I like Go because of it's very clear what's happening and it's very like, it's more rigid and the systems library support is, is really, really, really good. So I like it for that, but I guess I'm just trying to draw the distinction between the different use cases of the languages and connecting that to kind of your point about different languages for different things. And yeah, I think you were, you were basically saying that users have different skill sets, so you're making a slightly different point, but anyway. 

AJ_O’NEAL: Well, yeah, 

CHRIS_MATHER: I'm battling at this point. 

AJ_O’NEAL: No, it's, it's good. I mean, personally, I, I'd like, I like, I like when we go on tangents and, and, you know, learn things together. I don't quite understand what the distinction between the app, but I don't want to go into that for that. I, I kind of want to go back. So this, this all, if there was a thread that you need to finish up, finish it up by all means, but we started this, we were talking about the render function and how the TSX, the CSS, all that together. I do wanna get back to some of that and particularly what you meant about CSS being a first-class citizen was one of the things we were gonna go on before we went down like this rabbit hole of like one thing and then the other. So was there anything else we wanted to finish up on these branches we're on or can we move back to that piece again?

CHRIS_MATHER: Let's move back to that piece. By the way, this type of rabbit hole reflects the nature of development, right? It's like, what do they call it? Yak shaving, right? Before I get to the project, I got to get my VIM environment set up. Before I get my VIM environment set up, I've got to do this. So that's the nature of our conversation. 

AJ_O’NEAL: Yeah. Steve, did you have anything you want to, you want to help make sure that we don't leave in the dust while we've meandered here a bit? 

STEVE_EDWARDS: No, I think I answered. Well, think about it. So you had said, uh, one of the things you've mentioned earlier when we first started, when I was asking you about the front end, was that you would like to be able to incorporate view or some other framework in the beginning. So from the way you described it, it sounds like everything's written in a React. So that sounds like it would be a substantial effort to... 

CHRIS_MATHER: No, it's a very small effort. So React is a very small part of elements. I mean, I think React is honestly like a little overblown. Like people talk about it as if it's like some kind of application framework. It's really a UI engine and runtime. So you can think of it as like the way in Rails land, it would be like EJB. So you never say like Rails is written in EJB. That would be weird, right? Like it's, there's, it's just like one part of, of the whole, of all systems. So basically what elements requires of the, of a, of an engine is that it, there's like two or three functions of an API, like a wrapper, you know, that you'd have to implement. It has to be reactive. It has to be able to take some initial data to render. Those are the basic requirements.

AJ_O’NEAL: Yeah, I think, I think what you're saying, I mean, like me looking at things out there in the way that, that people are talking about it, I think you're talking about just the template system, which is literally react, but when people say react, they mean react, the template system react hooks reacts state management react forms, like, you know, they, when they say react, they mean the framework that is not necessarily the official single repository that is the React.js repository or whatever it is. I actually don't even know what the repository name is. But I think what you're, and the this.render, I think is very similar to the express version where I'm guessing that you can define a renderer for the whole system or maybe for just a route. 

CHRIS_MATHER: Yeah, exactly. 

AJ_O’NEAL: And then that renderer looks in the path. And based on what that renderer is, it's going to, it's still going to accept the same data, but what happens is different. Now, one thing I wasn't clear on while we're back on this was the, the page that is delivered, if I'm using the react renderer, does that mean that the page that's delivered is hydrated and live? Like I can start clicking around on it. 

CHRIS_MATHER: Yeah.

AJ_O’NEAL: So I don't have to do anything special. Like I render it with elements and I get a page that was rendered with React on the server side, but the JavaScript state is already hooked up on the client side that I can begin using it. 

CHRIS_MATHER: Yeah, exactly right. 

AJ_O’NEAL: That blows my mind. 

CHRIS_MATHER: I know, yeah, it was a really hard problem to solve and to do it elegantly, it took a while. So, and that is one of the requirements of the UI framework that you know, that you plug into elements is that it has to be able to support rendering to a string and it also has to be able to support rendering to the DOM. And then ideally it should also be reactive. So you know, one quick summary point on that though is like my, the way I value or look at UI engines is does the UI engine do a good job? And what does it mean to do a good job? One is that the initial render needs to be pretty fast. So obviously the initial render time needs to be linear and the constant factors for the, for the rendering needs to be as low as possible. Then on a re-render, it should also be obviously linear and it should also be as fast as possible. And third, it shouldn't make the user, the developer think too much about performance. So the ideal world is that they do the best they can. Right, so like if I update the data, that's my job. Now you take that and you render it as fast as you can. Whatever optimizations you need to do, make them. And if as the user, I need to sort of get around that and get sort of lower into the system, I can, but that shouldn't be the default. So I think React does an okay job of that, but there's room for improvement. I personally, aesthetically, I like the way Vue.js does the templates. I do like that separation of HTML and JavaScript. Maybe it's an aesthetic preference, I don't know, but I look forward to getting Vue.js baked into here as well. 

AJ_O’NEAL: Well, my experience has been back-end developers prefer Vue.js because I think it's more structured and more logical, and front-end developers prefer React, and I think that's because it's more magic. Like there's more things that just get done for you. And it's, I don't know if it's like, you're not supposed to try to learn how they work, but it certainly isn't obvious how they work. Whereas I think view an angular a little bit more, you know, if you want, if you're the type of mentality that you like to understand that there are wheels, that they're connected to an axle, that there's a drive shaft that's connected to an engine that takes fuel and be able to hold the model of this is a system that works for a purpose. I think that some of those others a little bit easier. If you're okay with just being like, okay, I'm getting in and I'm going to grab the steering wheel and as long as it goes, I don't care. I think that that's kind of more what react gears towards is if you start to look like, well, what's the steering wheel connected to, like, how do I, how do I dig in and like really figure out what I can do to, to modify this environment? I I get the sense that react is not really for that mindset. And I think that mindset, you know, it, the front end and back end mindsets, I think seem to, you know, it might be a 1% difference, right? It might be 51% of backend developers think this way and 49, a front end of apps or whatever, swap it. But I think there's some difference there where you see more backend developers gravitate towards what is. Easier cognitively to understand. And I think more front end developers tend towards what does a lot more for you without having to understand it and without necessarily having that drive to get in, to see where the pieces connect. 

CHRIS_MATHER: I see. Now that's interesting. 

AJ_O’NEAL: Being someone that is working on the backend with react. I'm very curious how you feel. Cause again, I'm just starting with it. And I'm starting with that perspective. Like I just said, where like, I like to know there's a wheel and an, and an axle and a drive shaft and all that, and know that all these pieces make sense and they can fit in my head. And I've not gotten to that point yet, but I would imagine you must have gotten to that point in order to be able to do the rendering the way that you're doing. So what, how do you feel about that? Can you hold it all in your head? Do you get what it's all doing now? 

CHRIS_MATHER: Yeah, for sure. You know, the best way to do it is, well, first that, you know, in the kind of ontology of things that are out there, you know, there's the kind of core react and understanding what that does. Uh, so the rendering algorithm and you know, it's open source, so you can go and study it and all that, but, and then there's all the things around it, right? Like for docs and various ways of doing state management. So I think at the core, the best way that, that I came to understand reactive rendering algorithms, just simply to write one and it is fairly complex. Um, but you know, once you go through that process, it's, it's, it's easier to grok what's happening in the various other things. So, you know, there's different parts of a UI engine. You know, I called an engine that means, in my mind, there's a language, typically a parser or compiler that has to parse either the Vue.js templates or in React the JSX, and then turn that into some runtime code. And then the runtime code has, at its core, across all these things, basically has a couple of functions it has to do. One is it needs to be able to render HTML to a string given some data, no different than EJB. Then the next thing it has to be able to do is to respond to events. So just like no different than any front end thing, like if you're using jQuery or something like that. And third, it needs to be able to update itself based on changes to data. So those kind of three major functions are consistent across all of these different things. I think in React, there's so much stuff that's kind of on, so if you really wanted to learn React, like I would just ignore everything except the part where you get a form rendered to the page, you submit the form, you respond to the event handler, and you do some things in the code and then you update the state of the form. And then you have like 99% of the core things. And I feel like a lot of everything else that's around that is people's opinions about how to manage state. And I think you can, let me summarize this way. I think you can experiment with that. There's nothing wrong with it, but it should be an experimentation based on your own needs of the time, like make it use case based. Like, okay, I want to do X. And so I'm going to learn different various ways to do X rather than, Oh my God, if I don't know how to do this, I'm not going to be employable. Or there must be some major thing that I'm like, I'm missing. Um, that that's kind of my philosophical view on, on like how to handle a big, large kind of react like ecosystem. Like learn the core is the main thing. Well, now I'll be killed a ceremoniously next for all these opinions. 

AJ_O’NEAL: Well, so for example, talking about reacts, there's react dot use effect.Right. 

CHRIS_MATHER: Yeah. 

AJ_O’NEAL: And you call that inside of another function and it has reference to scope that's in that function. And it is supposed to render based. Well, the way it was explained, which may not be, might, might have been sugar coating or something, but it was basically like, well, it just magically knows because it was called inside of this function that the state that it's managing is the state that belongs to this function. And that just sounds weird. Like there was no this, there was nothing that explicitly made it like it's tied to this specific component as opposed to running the use effect function on any component. Um, so there's, there was just some things like that where it's like, like it was difficult for me to follow where the, the pieces connect and that this would all be on the front end. This is not something you have to worry about the backend on the backend, it's just like the component, the initialized state, like you said, or initial props. I forget what it's called. Initial props, default values, like all that stuff. And you know, you're just recursively calling component functions with some value. Like, you know, what you're showing here, you've got your product, product object. And, you know, so it's just going down, down the hole and then it bubbles back up and you get your string or your DOM or or whatever, but there was some of those other things that would I imagine that if you have to get it connected on the front end, like that use effects stuff, it wouldn't make sense on the backend because the backend is not, once the page is string, it's center HTTP, it's done. 

CHRIS_MATHER: Yeah. 

AJ_O’NEAL: So that's where. 

CHRIS_MATHER: The use effect, like all that, I don't concern myself too much with that side of the React ecosystem. Although, you know, I familiarize myself with it, but I don't, I don't like worry about what's going on there. I feel like the main, the main thing for elements is that the server side and browser side render anything that's in the render path should work on the server and in the browser. If it's an event handler that it responds as a result of like a click or mouse move or something like that, that's only going to run in the browser. And that's fine. It shouldn't hose up the server at all. So I think mostly the use of fact and that kind of thing will work fine. And if there's any kind of client only that will be in response to an event. But yeah, everything else you said is right. You basically are producing a string by recursively traversing a tree. And when you're in the DOM, you're recursively traversing the tree and putting in DOM nodes. And then you can optimize in terms of, well, how fast can you hydrate a tree? Well, you can't do it any faster than linear time because you have to go through the tree. But there's various ways you can slow yourself down there. And so those are the areas for that I care about. If I, when I look at the UI engines, I look at how fast are you, how good are you at the core job? So rendering speed has to be very fast. It has to work on the server. It has to work in the browser. Hydration has to be very fast. And the API surface level for the user has to be very good and seamless. I think the React stuff, like when I was the CTO of Lively, I was constantly having to, the guys like, this is crazy. Rain it in. We need to be able to understand what this page does and be able to tie our minds from the route down to the data that's moving through the page. And that used to be fairly, fairly straightforward. So I find that with a lot of the, the React community, that it gets, it gets unreasonable. I feel as if it's not representative of how we worked on a really large project. 

AJ_O’NEAL: Okay. So we're, we're hitting up against time. So I got to wrap this up. There's one other question that I have. 

CHRIS_MATHER: Yeah. Assess stuff too. 

AJ_O’NEAL: Oh yeah. There was that too. 

CHRIS_MATHER: I can do that real fast though.

AJ_O’NEAL: Go ahead and do that real fast. And I'm going to ask this question. And if there's not time to answer it, then we'll just leave it to the ether and people will be disappointed and feel like they lack closure. 

CHRIS_MATHER: Yeah. 

AJ_O’NEAL: We'll have to have you back and they'll have to get a therapist until then. 

CHRIS_MATHER: CSS is great. I love CSS. I, well, okay. I thought it was a wrong way to start this. CSS has a lot of, a lot of pain points, but I think CSS is important. Let me rephrase. 

AJ_O’NEAL: CSS this is great. I mean, I lied. 

CHRIS_MATHER: It's actually quite painful, but you know, anyway. I wanted CSS to work really, really well. So one of the things that the build tool does is you can, you can declare a dependency on CSS using a triple slash comment. So rather than importing CSS or having to require a compile step or do something where you just, you just declare the dependency up at the top and what the build, and it doesn't affect the TypeScript at all because that's a comment. And what it does is it links together all the CSS you need for a particular page to render. So one of the main features of elements is that the page only gets the bundle that it needs for that page, not the whole, not a single page app. So you get the CSS and the JavaScript that you need for the particular URL that you're on and no more. And if you have CSS that's through and across the forest of components, it will link that together in a topologically ordered list of CSS. Post CSS is integrated too, so you can get Tailwind working. It all works really great. I love the CSS compiler experience. 

AJ_O’NEAL: But what's the trade-off of that? Because obviously people started bundling CSS in the way that they have because they wanted certain trade-offs. So what's the trade-off where it's like, no you should just have the CSS delivered with each page because this is better because why? 

CHRIS_MATHER: Well, you know, in CSS, oftentimes, I think you find that you have global, you have global styles that apply to really everything. And I think that's still the case here. So, but the way you think about it is you think about it as a tree where you start with your page. So you start with the TSX page or your view component, whatever the page is, and you import your CSS from that. Now that might pull in some global styles. And those global styles might pull in fonts, so they might pull in font colors, or sorry, yeah, colors, various variables, things like that. And they may be duplicated across different pages, but each page is sort of stands on its own. And that's really good for cacheability, for example. So if you go back to a page and the developers haven't updated the page, you really want the user to not have to come back to the server, you know, just to see, to get the same page they already have. 

AJ_O’NEAL: So it sounds like you're saying it's...For applications where it's more likely that the person is going to visit the same page and less likely that they're actually going to be browsing many different pages of the site, it makes more sense to just put the CSS on the page because the bundling the CSS caching is not actually effective in that case.

CHRIS_MATHER: I'm not sure. So the CSS itself is bundled into a URL and each page just has its own linked CSS file. So I don't think anything has really changed. I think it actually works well across all the app use cases, whether you're, you know. 

AJ_O’NEAL: So is there still a global CSS file that is its own individual file? 

CHRIS_MATHER: Yeah. You can organize the CSS files any way you want, but you import them as you need to use them. I think the main difference from like SCSS where you start with like a root of the tree and you just kind of declare like in one big file this way you invert that and you, you focus on the page that you're on and that page pulls in what it needs. 

AJ_O’NEAL: That sounds very go like to me. 

CHRIS_MATHER: Oh, really? 

AJ_O’NEAL: That philosophy. 

CHRIS_MATHER: It's very JavaScript like too, right? You require a module as you need it and then that module comes in. Sure. Yeah. What was your question? You had another thing you wanted to ask. 

AJ_O’NEAL: Okay. Yeah. So last thing, which we may not have time for which I actually don't know if I remember what it was. Uh oh. 

STEVE_EDWARDS: I'll ask you a question in the meantime here that I've stepping away from the technical stuff. You'd mentioned that if I understood correctly that elements is basically a business or organization. Yeah. I'm just curious to see what your business model is for something like this. I was curious to see how that works with open source software. 

CHRIS_MATHER: Yeah, well it's new. I'm gonna give it a go, no pun intended. And we'll try to try a model. My initial thinking on it, which is open to feedback from the alpha users, and that's my big ask. I would like, we're really crossing into beta. We're at alpha version 1.0.5 or something like that. So a lot of iteration this year, going into beta, looking for users to come and try this out and to build some apps with me. I'm going to be doing YouTube videos over the coming months where we're going to build stuff. The first one coming out is going to be how to build a passwordless authentication system. So look forward to that. But my initial thinking is to charge for the tooling. And I want users to be able to build, because that's where I see the value. So I want to align elements, the company with developer productivity and happiness. I could do deployment. That would be another way to do it. But I think I like the idea of the user being able to deploy anywhere they want and that this will work just as well on Amazon as it will with Google or on Digital Ocean or Linode or any of them. So the initial thought is to do tooling. I think the open source, the framework itself is open source. I think that's important if you're going to be working with code that you should be able to see it. And yeah, that's the basic model. It's pretty straightforward. You just charge per machine for the tooling with some kind of free trial to start. And the output of all the tooling is just standard stuff. So it's HTML, CSS, JavaScript, but the tooling itself has kind of some magic in it to make the developer experience really good. I tried to spew it out as quickly as I could. 

STEVE_EDWARDS: Hey, AJ did you remember your question? If not, I did remember my question. 

AJ_O’NEAL: I did. So it was this. We all want a WordPress killer. Cause WordPress, WordPress makes it really easy to have like a site that an end user can update, but it just, you know, it's got the security vulnerabilities. It's got the performance issues, which are sometimes solved if you do the caching correctly and, and just kind of thinking about like the reactive nature of this, this rendering process, or maybe, maybe what it could be. Do you think that elements would be a good tool to build a WordPress or Wikipedia killer that gives the same convenience, but maximizes on performance and simplicity? 

CHRIS_MATHER: Yeah, I think it's a great analogy and we'll see. I love the idea of building a, I think of it as like a Home Depot where you can go into Home Depot and there's lots of parts that you can use and you can build stuff. And this elements is the company for builders. I want to enable builders to build all sorts of things. So it might be something where you know, where someone would have gone in and used like a drag and drop thing. This makes it simple enough that they can get into the code and actually, you know, do it that way. I'm not sure, but I could see all sorts of building personal sites, building backend office services. And you know, that, like you said, having that rendering, the reactive UI work on the server and the browser and having it like a full stack framework to work with that makes it super simple. I'm hoping to enable a whole generation of new builders the same way that Rails did back in the late 2000s. 

AJ_O’NEAL: Cool beans. 

 

I remember working my tail off to become a senior developer. I read every book I could get my hands on. I went to any conference I could and watched the videos about the things that I thought I needed to learn. And eventually I got that senior developer job. And then I realized that the rest of my career looked just like where I was now. I mean, where was the rush I got from learning? What was I supposed to do to keep growing? And then I found it. I got the chance to mentor some developers. I started a podcast and helped many more developers. I did screencasts and helped even more developers. I kind of became a dev hero. And now I want to help you become one too. And if you're looking forward to something more than doing the same thing at a different job three years from now, then join the Dev Heroes Accelerator. I'll walk you through the process of building and growing a following and finding people that you can uniquely help as you build the next stage of your career. You can learn more at devheroesaccelerator.com.

 

STEVE_EDWARDS: Alrighty, so with that, let's move on to pics. And actually, Chris, we'll go with you first. I know you had an announcement to make. So why don't you tell us any pics and what your announcement is? 

CHRIS_MATHER: What's the pics are like pictures? 

STEVE_EDWARDS: I'm sorry. Yeah, pics are just anything you're interested in, you know, whether it's a movie could be a book, a TV show could be, you know, some new toy, you've got anything that that interests you maybe you obtained recently, or in your case, it could be your announcement. 

CHRIS_MATHER: Oh, my announcement? Is that I'm going to be a dad this summer, which I'm super excited about. 

STEVE_EDWARDS: Woo. 

CHRIS_MATHER: Yeah. I'm scared too, but I think I'm mostly excited. 

STEVE_EDWARDS: Be prepared for a lack of sleep. That's all I can say. 

CHRIS_MATHER: Yeah. 

AJ_O’NEAL: My advice to everybody who's a first time father, because now that I am somehow, I'm, I don't know, more aware of people that are whatever, but if you don't throw the child out the window within the first three months, you are a good dad.

CHRIS_MATHER: That's a pretty low bar. 

STEVE_EDWARDS: Yeah, I was gonna say that's a very low bar. 

AJ_O’NEAL: Well, Steve, having had three kids, really you think that's a low bar? I think that- 

CHRIS_MATHER: You're not a psychopath. You're a good dad. 

AJ_O’NEAL: Yeah. No, it's not about being a psychopath. It's hard. I mean, like, they scream and like the lack of sleep, it's really a two-person job. Like, I don't know how single parents do it. I certainly could not do it. I don't know how the single moms do it. Like, God bless them, God help them. But if you can manage not, nevermind. You know what, you'll see what it is and maybe you have an easy baby or maybe you don't, but if you know what I mean, then you'll know what I mean. I'll just leave it at that. 

CHRIS_MATHER: I agree with what you're saying. 

STEVE_EDWARDS: My first one slept through the night at about six weeks. My second one is about two or three months and my last one was a year. 

CHRIS_MATHER: Oh wow, quite a variability. 

STEVE_EDWARDS: Oh my gosh, he was the kind where he cry and you finally get him to sleep. And then as soon as you put it down, you just him just a bit and he's awake again. You know, my wife and I would be swapping off like, is it your night tonight? Or is that my night? You know, 

CHRIS_MATHER: apparently that's how I was. And I had, they used to call it colic, I guess, but it turns out it's just like indigestion or sorry, acid reflux or something like that. But I, apparently I cried for like, like the whole first year. So karma is probably coming my way. Right. 

STEVE_EDWARDS: Yeah. I had a coworker of mine, a buddy of mine, uh, years ago who told me with his first one. He was colicky too, and they had like a set driving route around town, around their house where that was the only way they could calm him down so they'd have to get in the car and put him in the car seat and drive. That's what it would take to calm him down. But anyway, that's awesome. That's awesome. 

CHRIS_MATHER: Thanks, guys. 

STEVE_EDWARDS: We definitely need more children in this world. I'll go next. I'm going to go with a blog post. It's considering what's going on currently as we're writing it as we are right now in late January, COVID-19 vaccines are rolling out in some places more smoothly than others, shall we say. But with the Moderna and Pfizer vaccines that have been put out there, there's been a lot of concerns raised regarding the speed at which they were created and other issues supposedly affecting fertility and so on and so forth. Anyway. This blog post is from an organization that I follow called Reasons to Believe, and it's called the COVID-19 Vaccines and God's Providence, but the vast majority of the host is written by a biochemist and he goes into great deal of detail regarding how the vaccine works. You've got how mRNA works, lots of pretty pictures and also some background on the history. And the gist of it is basically these vaccines were built on about 30 years worth of work. And it wasn't like we started from the ground up and we've got this new vaccine in 10 months. It's not how it was at all. It was literally decades of research to the point that once the genome of the virus was translated, we're able to able to take that signature and use it to generate a vaccine. But I'll put a link in the show notes, but really a really very detailed and interesting history and description of the COVID-19 vaccines. 

CHRIS_MATHER: That's super interesting. 

STEVE_EDWARDS: AJ, you're left. You're next. Shall we say you're left and you're next. 

AJ_O’NEAL: Yes, indeed. So first of all, I'm going to pick Ubiquity which is, or maybe it's Unifi. I always forget what the actual name of the company is because the products are either called Unifi or called Ubiquiti, but the website is ui.com. And they are the absolute best networking equipment that money can buy. But here's the kicker. It doesn't cost a lot of money. So basically, if y'all remember the Apple thunderbolt display that was like the deal of a lifetime. It was a $2,000 display that you could buy for a thousand as opposed to the VR display, which is a thousand dollar display that you can buy for six thousand dollars. But that's what UniFi products are like. They have their Edge Router X product is like $59. Their Wi-Fi access points are the kind of ones that you'd want in your home for surround Wi-Fi are 99 bucks apiece. They have really, really nice Ethernet cable that's super slim and slim lie. It's streamlined that is rated for power over ethernet. And it's like they're dollars, you know, they're like, like you're paying basically per foot and you're paying cheap. You know, you there's nothing you could not get better quality cable at a cheaper price is just not possible. And their POE adapters, like everything is so incredibly reasonably priced. Like all of their stuff competes with any other name brand, which, and they're actually really about networking. So their stuff is really, really good. It's not like Netgear where Netgear is a branding company that contracts manufacturing companies over in China to create stuff that Netgear didn't design that was designed by a third party. Like Unifi products are actually designed by Ubiquiti and Ubiquiti is the company name and Unifi is the primary product line for the wifi stuff anyway. So I am not sponsored by them. I just love their products and I'm always satisfied. I just upgraded to Wi-Fi 6 with their UniFi product. And unfortunately I had to buy a new POE adapter because their new access points are 48 volts rather than 24 volts. But I just, I love their stuff. I love how easy and simple it is to get set up. Some of it is a little bit more advanced than what you like. If you buy the edge router, the wizard for the edge router is not the same as the rigid, the wizard for the, you know, D-link night hawk or net gear night hawk, or whatever it is that you get from best buy. But when you get past the wizard, whenever you need to do anything that might be more than like the most basic thing, it's very easy to do. And the wizard, you probably will get it all right on the first try, but they use professional terminology for things rather than consumer terminology. And sometimes that's a little weird because instead of just making up a name and calling it something so they can put a TM by it, they actually call it the industry standard name, which again is sometimes things that we're not used to. So picking them. And then the other thing that I'm going to pick is there is a UHD friendly. Blu ray drive that I bought. It's a Libre drive, which basically means that. You can put firmware on it and it will behave like a raw blu-ray reader, which makes it good for archiving your movies. If you like to have high quality, I car kinds of your movies so that you can have the convenience of streaming through something like Plex without having the, you know, type of quality that you get from, you know, like Netflix, you get the full blu-ray quality anyway. That's what I, what I'm using it for. But, um, it's, it's the, the model number on it is the WH-16NS4-SVC-NS50, which that's a mouthful, but this exact drive is basically the best drive on the market, also happens to be the cheapest drive. And you do have to flash it with Windows. So you cannot flash it from a Mac. You'll have to go borrow a friend's Windows computer if you need to. And the adapter that you need, the USB adapter, most USB adapters are just for hard drives. They're not for optical drives, or they have quirks when working with optical drives. So the adapter is the Unitech Y 1099 new. And so if you're the type of person that wants nice, high quality contents from your, your Blu-ray collection or your 4k collection, then this would be the drive to get, you know, along with the normal make MKV and the link I put here is actually my review of it on Amazon that gives you all the specific details that you would need to know. If you want to flash it or make sure that you have the right version and whatnot so that it works perfectly for you without any hiccups. 

STEVE_EDWARDS: As Bill and Ted would say, excellent. So I believe that is it for our show today. We went a little long, but there's so much information. We had to squeeze it in and plus AJ likes to talk. So with that, we will end our episode of JavaScript Jabber. Thank you for joining us and we'll talk to you next time. 

CHRIS_MATHER: Thanks for having me.

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. To deliver your content fast with Cashfly, visit c-a-c-h-e-f-l-y dot com to learn more.