Jerod Santo: Very cool. Well, we have to wrap here. Of course, listeners, all the links to all the things, ElderGuide and Elder.js, and any other links that Nick gives – I’m sure he’ll give us a bunch, because he’s the SEO guy… So we’ll link them up in the show notes for you guys to click through on.

Kbal, Amal, thanks so much for hanging out with us. I wanted to give a shout-out to a couple upcoming episodes. Kball’s doing a cool interview about JavaScript on WASM. WASM will be back. We have a show with Feross, we’re gonna dive into his Wormhole app, which is a really cool new project from Feross; we’ll dive deep into that. And we also have Kent C. Dodds coming soon to JS Party, talking advanced React concepts. So that’s just a few shows we have coming down the pipeline… So definitely subscribe if you haven’t, and do come and join is live, each and every Thursday at 1 PM US Eastern time, hang out in the JS Party channel of our chat, and party with us y’all, because it’s lots of fun as we record.

Nick, we really appreciate you coming on the show, we appreciate you kicking your impostor syndrome in the face… And open sourcing Elder and getting all the goods.

Jerod Santo: So you were trying to access it through K9s, which is a really cool CLI, an awesome terminal app for accessing all the information about your Kubernetes clusters. But it does not give you the ability to delete things, apparently.

Emma Wedekind: I don’t know if tools in the browser – so there are a couple different design tools that actually can spit out code, which is really nice. One is Abstract, and Abstract is essentially like GitHub Desktop; it’s a source control for your design files… And it’s cool, because you can actually grab all the CSS from these components right in the app.

Framer is another super-cool tool. It spits out React components… I was skeptical of it at first, and then I tried it, and I’m all about it now. It also makes it really easy to add interactions to these elements, like animations… So maybe if your designer is really keen on adding specific animations to your components, and maybe you’re not the best at CSS animations, you can work on these collaborative tools that generate code, and then you can take and obviously validate that it’s correct. So I don’t know about browser tooling, but there’s definitely design tools that can help facilitate that.

Another quick, interesting point I think Tony is trying to make - he’s talking about… I think he’s getting to “Do the component themselves in a component library have to worry about spacing in relation to other components, or should that be the responsibility of the components consuming them?”

[48:10] Here’s an example - let’s say I have a button, and it’s in a container. Does the button have margin on the outside, or does the container set padding in relation to the button? This is a very interesting idea, because I was having this conversation with someone at work the other day, about how – oh, you know who it was? Mark – I’m gonna butcher his last name; he’s from Australia. He just gave a talk at React Conf, I think…

Nick Nisi: So in 2011 I was working on an app – my first big challenge with Dojo was converting a 1.4 app to a 1.7 app, which meant completely changing over to AMD and learning that. I did that for a while at this startup; the CTO at that startup, John Christopher, he really was a big fan of Dojo, and dGrid was this other project that’s kind of a grid implementation that’s used in the Dojo ecosystem, and that was a really powerful tool for us in the app that we were building at the time.

Then it was from that dGrid project that I actually became familiar with SitePen and started looking to them as my next adventure in my career. I’ve been there pretty much ever since, so for about five years now, contributing to Dojo 1 and Dojo 2, and teaching workshops, and things like that. So I’ve been really happy to be a part of this community, and I think that there’s a lot fo really cool ideas that have been improved upon from Dojo 1.

One thing in particular is the Dijit system, with its declarative syntax for creating widgets that you can use, and having a whole lifecycle around that. That seems like it’s an earlier implementation of what Dylan was saying, like web components, or maybe even like React components. I think that it could maybe be seen as like a building block to get to where we are today, which is really cool.

Brian Ketelsen: OMG! I do. It’s a tiny one, but it packs a lot of punch. So, if you’ve used the terminal, like most of us have, and you’ve come across Powerline — you know that Powerline is a Python app that makes lots of cool things appear in your terminal and gives you information, contact-sensitive information, as you change around and execute commands. And Powerline is great, but it’s a little slow, and especially as you add more and more things to your command prompt. Well, someone, Just Janne on GitHub, ported Powerline to Go and it is stupid fast! So, I’ve added it to all of my machines in this last week and it just makes me brilliantly happy.

[00:44:03:20] Powerline – so it’s at github.com/justjanne/powerline-go. Crazy fast, and it’s written in Go, so you can extend it yourself.

Rachel Nabors: We’re leading to a very exciting place. One of the reasons why – I don’t know, I don’t think I could have gone in-house for anybody but the Edge team. It’s really changing the way the web is built. We’ve always thought of the web – well, excluding that bout of Flash fun that we had, we’ve always thought about the web as kind of a static document thing. Even HTML is a document; it’s in the tags, it’s right there, “document”. We think of it as kind of like a glorified microfiche, a way of storing words with the odd picture, maybe some audio or video here and there, but mostly we think of it as a way of storing words and arranging the words to make them look interesting.

We don’t really think about the web - or at least we didn’t until recently - as a user interface or an app, or something like a tool that we can use to do things. It’s been kind of interesting watching frameworks like React and Angular kind of turning the ship on that. I’ve been enjoying watching motion creeping in around the edges, and part of that is definitely due to native apps challenging the state of the web. You’ll hear it when you go to conferences like Chrome Dev Summit, about how the web has to stay competitive with native, so that it’s not completely abandoned and everyone isn’t just like turning on Facebook as soon as they turn their phones on, so that they’re actually going to Wikipedia, they’re actually going to your personal blog site, that they’re still accessing this non-walled garden, and this thicket of information out there where anybody can be an author and anybody can share things or design things or come up with some new invention.

[40:21] It all starts in the web before it goes native, and the web has to be able to compete… And let’s face it, native does some things better than the web does, for instance like going offline, having animated user interfaces. Animated user interfaces, by the way, are really good for users.

Erik St. Martin: I tried with Objective-C, I really did. [laughs] I tried the same thing, I tried to build an iPhone app… And I could, but I never felt like it clicked, like I really got the language. I didn’t spend a lot of time in it, but you said the enjoyment of working in a language… If you wanna get a project done, you either wanna work on something that you really enjoy the language or you’re interested in, you need a reason to learn a language, or you need to be able to have quick rewards - you really want the thing that you’re trying to build, and because you’re using that language, you can throw it together quickly.

I think it’s like Rails. I loved Rails, because it was like if I had a cool idea for a little app, I could throw it together in a weekend because of how proficient I could be in it. It didn’t even have to come down to how much I loved Ruby or Rails itself, it was just “I wanna see this idea come to fruition, and with Rails I can do it in a weekend.”

Maybe that’s the motivation for the desktop app, that I know if I wanna throw together something for my Mac, it would take me forever trying to get Objective-C down enough to do what I need it to.

Chris Krycho: I think the answer is yes. And one of the reasons that I’m more bullish on sticking with SemVer and putting tooling around it is because I did survey the rest of the world as it were when it comes to versioning, and there are a lot of approaches that just say “Ah, these problems with SemVer are fundamental. Scrap it.” One of them, SoloVer, is just have one version number - it’s 1, 2, 3, etc, just go up. And that has a certain appeal to it, but the actual fundamental issue there hasn’t changed. All it does is take the burden off of the maintainer of a library, and put it on all of the users. It says “Okay, now you’re responsible anytime any one of your dependencies changes, including transitively, anywhere in your dependency tree. So go read the release notes”, which tend to encode things like breaking changes in the release notes. Because again, communication problem, right? We want to know “What did this do?” Also, as an aside, all of those proposals include things like “Well, you can also stick like pre-release numbers on the end.” And I’m like “Hold on, hold on… It seems kind of like we’re backing our way back toward this whole SemVer thing now, aren’t we? Shouldn’t your pre-release just be another number?”

I think there is a sense in which there is a maybe fundamental local maximum. Maybe it’s local, but the hill’s so big that we’re not going to find a different path. I could be wrong about that. But when I go looking around, the things that seem like they might change the calculus here don’t so much eliminate the value of SemVer as they do build on it. So a good example here is what the Unison programming language does. Pretty small language, but it is aimed at industry. It’s not pure research. And they do something that’s really wacky, in the best way. You don’t store your code as plain text. Instead, they take advantage of the fact that they’re a pure functional programming language, with really well specified semantics, and they say “Okay, we can take your code, normalize it, hash it, and store the compiled output of it with a pointer to it”, which means a whole bunch of interesting things… But for the purposes of versioning means when I make it breaking change, the original version is still there, because that hashed, compiled version of it got committed to a database instead of to plain text. And that database version is what anybody who depends on it sees.

[00:34:06.12] So when I add a new parameter to my function, the consumers are still pointing to the old function, which means they can pull this update and say “Okay, I can progressively switch over to the new function signature, but I can do that at will, and the two can live next to each other”, and because it is a pure functional programming language with no side effects that aren’t managed off in the runtime, etc, etc. You know, leave all that aside. Suffice it to say because of that choice, they can just “ship a breaking change” without ever breaking anyone.

The reason you still want SemVer here though is because SemVer is a communication tool. And so SemVer lets you say, “Okay, there are these new features in the library. Here’s a bug fix. You’re going to want this one.” And even though that means you need to actually go update which compiled version of this function you’re pointing to, you’re getting data from that, and when you go to publish your library, you want to be able to use that information. Even knowing that it’s not going to break your users in the same way, it does let you then say “Oh, I didn’t actually mean to make a breaking change here. I wanted this to be compatible and to just keep working forward.”

So things like that, I think, are pointers in the right direction. There’s also a couple of papers out there from folks at the Nova University of Lisbon, who are asking “What happens if you bake versions as types into Java?” Java because it’s the kind of default language to do this kind of research on. Their proposal is very interesting from a type theoretic and versioning perspective, and would never get adopted in industry in a million years, because it’s just way too much boilerplate… But it does the same thing we’re talking about; it bakes this notion of backwards compatibility in, in a way that I think if you were going to actually ship something like that in an industrial programming language, you would actually want SemVer as basically how you do it. And their type system that they slap on top of Java, effectively encode SemVer with keywords. It’s upgrades, and replaces, and things like that.

So I think there’s work to be done here, but I don’t think it’s going to be in the near term, for one. So we’re going to need the tooling. And even if and when we see something like that type system on top of Java, or what Unison is doing, becoming more widespread, I think those kinds of things lower the risks in really interesting and important ways… But they would still really benefit from the kinds of tooling that we’re talking about. They also though highlight, I think, one of the things that’s easy to miss in these kinds of discussions, which is a lot of times people like me, who are type theory nerds, etc. like to go looking for that kind of a solution to a problem. It has two limitations. One is that’s never going to work for Ruby. I say “never”, but you could imagine a world in which type adoption for Ruby is at 100%, but that world seems very unlikely to me… Not least because a lot of people who love Ruby love it because it’s dynamically typed.

And second, doing all of those things purely at that, like “Let’s bake it into the type system level” has costs, because it turns out that itself then becomes a thing that you need to think about in terms of the versioning of your language. Because one of the things that shows up is that the more foundational, whatever your tool is - like, if you’re an app, and you just have consumers, it’s not that big of a deal. Your versioning is basically purely marketing. If you’re a library, you have a bunch of apps that use you and maybe some other libraries. If you’re a framework that everybody else builds on, how well you do this now affects everybody else in the entire ecosystem. If you’re a programming language, you’re kind of doing it at the maximum level, and you still have to communicate those versioning constraints to other people. And the more complicated your type system is, the harder it is to actually understand what the implications are for versioning.

[00:38:09.28] So the tendency that people like me have, to say “Ah, bake it into the types, and it’ll be rigorous and checked forever” can actually undermine your net goals here, because now you’ve made it harder to think about this fundamental communication problem.

Jerod Santo: They still are, and they have a couple things going on that were notable… One that just dropped yesterday, and I know that Nick was very excited about, because he put it in our chat and said “Let’s do a show.” So maybe a full show coming soon about this, is the React compiler, which is open source. This is a new, experimental compiler that the React team has open sourced to get early feedback from the community. What does it do? It’s a build time only tool that automatically optimizes your React app. It works with plain JavaScript, and understands the rules of React, so you don’t need to rewrite any code to use it. I mean, free code optimizations - why not, right?

Brigit Murtaugh: Yeah, that sounds good. So anyone listening, you can go to containers.dev in your browser, and you’re gonna see our overview spec site for the Dev Containers specification. And like Jerod was describing, dev containers - if you haven’t heard of them before - are this really awesome tool to help you get up and running with applications, or projects, or repos that you’re working on, without having to really download anything locally. And especially depending on your setup, maybe you need Docker locally, but you can also do other cloud-based environments, like GitHub Codespaces, like Jerod was describing, so that way you really don’t even have to download or run anything locally.

And essentially, there’s a couple of files that configure your dev container, and so that’s what was added to the Changelog’s repo. So there’s a devcontainer.json, which just describes the metadata about what should go into your container, and then you can also link out to a Docker file, which you may have heard of or be familiar with, if you’ve worked with containers at all, that can talk about some other things to install or set up for your environment.

And with devcontainer.json you can really extend it with what you want, specifically for a development environment.

[05:57] And so with containers in general, if you’ve heard of them or use them in other applications, you may think, “Okay, cool. That’s a way to standardize what my app has when it’s deployed, or when it’s off running in production.” But there’s a lot of other opportunities to standardize what your app is doing, or how you’re working on it earlier on, from when you’re developing it, to doing CI/CD, and testing. So then having a dev container now, which can have that same consistent tool set, and languages, whatever your app needs, from development all the way to production and testing, it really ensures that like I know how it’s running; when I’m testing it, I’m gonna get that same experience that’s deployed. Other teammates get that experience too, because it can all be checked directly into the source code, or the repo… And it tries to kind of take away some of the worries you may have, of like “Oh, Linux, or Docker containers seems hard or complex.” We really try to simplify some things with scripts, or other ways, that it’s “Hey, I can add this, and I can add really advanced functionality, but I don’t have to go learn everything about how to be a Linux scripting expert to get started.”

Daniel Thompson: Oh, gosh. Well, we’ve been working on it for just over three years now, since May… And it goes back to a different open source project that I was involved in. My friends and I, we were working on a project called Quasar, which is a Vue.js system for building websites and SPAs and SSR apps and Electron apps and Cordova apps. And I was always kind of interested in outreach and getting into other ecosystems, and I reached out to the wonderful people over at Purism.

[08:23] They make this PureOS open source-conform system. I mean, the company is following these ideas of open source, and the products are following these ideas… And I thought, “Well, hey, maybe I can stop over there and ask if it’s possible for us to figure out a way to work together and we start putting some of these Quasar apps on their app store. And they’re like “Oh, cool, that’s awesome. So how are they made?” And I was like “Well, you know, we use Vue.js and Electron” and they’re like “Whoa… We can’t. Here’s a long thread over at the FSF, and read through about un-Googled Chromium, and why some header files aren’t appropriate…” And I was like “Okay…” So three days later, and miles of threads later, it was kind of clear that what I thought open source was wasn’t always what open source really was. And just saying that something is open source and putting it on GitHub, doesn’t mean it really fulfills the needs of the FLOSS community, right? I guess the difference between free/libre open source software and open source software, and open core software - everyone’s kind of has these different feelings about how you enable other people to use your code. And at any rate, and as fate would have it kind of dejected, a couple of days later a really good friend said, “Hey, did you check out the WebView library?” And I was like, “Okay, well, fine. I’ll go look at it.” And this was like a combination of projects. There was a developer named ZSerge, who wrote a bunch of C and Objective-C bindings for the platform-specific web views on Windows, Mac, and Linux. And then we found a Rust port.

So we did a first practice, Lucas and, with Go. I think I did the first C example, and then Lucas did Go, and we’re both like “This isn’t really nice.” And then we found the Rust library. The Rust library kind of helped us, and allowed us to get to a kind of proof of concept really quickly. And what we were seeing was kind of this, like “Daniel?” Lucas said, “Is this right? The app is only two megabytes.” And we’ve been using Electron apps, and are used to things weighing 600-700 megabytes and then download. And okay, it was it was just a dot app. It wasn’t like all of the crazy MSI installers and DMGs. And don’t get me started on the Linuxes, but… It was kind of tangible and real. And we were both really new to Rust. Totally unaware of the complexities of the stuff we were getting ourselves into… And we had these proof of concepts, we got it working on Mac, and we got it working on Linux, and we got it working on Windows, and that’s kind of the time when I think we got slashdotted. No, we got hacker-newsed first. And it was kind of this almost raging, how dare you not ship Chromium?! And it was interesting, because it kind of gave us an uptick, and it gave us some visibility to the larger community… And then just one after the other, these amazing people joined us, who really believed in “Yeah, we can make it more energy-efficient, we can make it more secure, and we can really follow in these open source ideals and do our best and stay transparent and accountable.”

[12:27] And you know, things went pretty well. We got further and further, and then boom, COVID happened. And I think, for those of us who were around and active in software, and especially open source, it kind of got to be – I don’t know, I mean… I know personally I had just this crazy experience of not knowing when to stop, and that kind of led to this weird COVID burnout, and we’re all just like “Oh my gosh, alright, so the world’s ending, let’s go have a barbecue.” And you know, things kind of got back on track, and then the investors started ringing the doorbell, and the venture capitalists, who will remain unnamed… I don’t think there’s anything wrong with open source software becoming commercialized, but it scared me, because I’ve been working in open source projects for almost two decades, and I didn’t want this project to become corrupted by some kind of capital that starts dictating the direction it has to take. We kind of ghosted the first VCs to call us, and went into overdrive and registered Tauri as a program within the Commons Conservancy, which is a Dutch organization around NLnet, that really exists to support open source projects and protect them, and especially to protect the code and to protect the community. I mean, we’ve all heard of bus factor, but I think that the ability for money to corrupt ideas such that the original vision gets lost… I mean, I’m not saying that’s the kind of militarization of open source that I’m most worried about… But for our project, we really wanted to keep it in the hands of the community. And I think that that was really the right decision at the time, because as time went on, we got really close. We built our betas, and then we decided to get audited, which is a little silly… I mean, who are we are…? It’s just some friends and an open source project, and then we got some grant funding, and we took our donations together… And we had an external horizontal audit of all of the libraries, and a vertical audit of an example app… And I have to tell you, if you’ve never had your code audited, it can be scary, but I think what we all learn from the experience is that it’s really exciting when your presumptions are challenged, and you get to a point where you realize through the help of the external pen testers or auditors or code reviewers, or whatever it is you want to call them, that you can actually continue to make your thing better.

And we obviously published the finding after we did six months of work, rebuilding the parts that were problematic… And yeah, now here we are, a couple of weeks post 1.0 launch, and it’s so exciting to see the gravitas of the future in the team. Because you know, up till now, we – we do have a change log that we implemented in probably the first six months, so that we can maintain the history of what we’ve built… But now you have other concerns, like what parts do we have to audit next? And what is our release strategy going to be? How are we going to branch this? And it’s really exciting to see the working group come together.

Jerod Santo: There are definitely not as many people who are familiar with Elixir as they would be if it was a Ruby on Rails application, for example, or if it was a JavaScript SPA or something, with a Node backend… But I guess I don’t care all that much about those aspects. I feel like as we build out new areas – I’m not sure I’ve teased it on the show or not, but… I’ve teased it to you, Simey - I’m thinking about doing an API and a Changelog command line, so you can play our shows from your command line, and stuff. And I wouldn’t pick Elixir for those… And that is one of the reasons; I don’t think it’s the best tool for those particular jobs. Maybe for the API, if it’s just part of the app. But for the command line tool, in terms of distribution and stuff, I think Go is a great choice…

[01:08:10.22] And I think that as we have maybe smaller ancillary things, like our transcripts repo, if we had a command line repo that was its own separate project in Go - well, I could see more contributions coming into there, than whatever come against Changelog.com.

Hopefully we open up new opportunities as we move along. I definitely think Elixir as a dependency has probably limited, to a certain degree, outside contributors, but I think more so it’s the lack of vision and clear inroads to contributing that’s done it.

Lea Anthony: [36:06] So there’s basically two build modes. Well, it’s for two targets. There’s a desktop application target, so a packaged version, which has an icon, and is something you can double click and run… And the other one is kind of like your standard Go output, which is just a terminal app that you run. You’d mainly use that for development. Like a Windows, for instance - it’s good to run that in that mode, just so you can see the debug output, and all that kind of stuff.

But Wails does come with the ability to pack down to the package. So on Windows, that’s essentially – you know, it generates the manifest file, it generates a different range of icons, and you’d have different sizes into an icon file… And then it compiles that up into the .exe that you would expect from any other build tool.

For Mac it generates a .app directory structure, it creates the plist, it generates the icons… So it puts it together in a way that works on a Mac. So you don’t need to package [unintelligible 00:37:07.07]

Matthew Hodgson: Yeah. I mean, whenever anybody comes up with any protocol and very enthusiastically says “Ha-ha! We are creating the one true messaging app!”, we said “Oh… Okay, that’s cool. Good luck with that, and we’ll bridge.” [laughs]

Julia Grace: Yeah, absolutely. So we have over nine million weekly active users and over six million daily active users. There’s over two million paid users. What I think is super-cool… So of those paid users, the two million paid, 43% of Fortune 100 companies use Slack. So a lot of the companies that you think about - credit cards, Capital One - they’re running their business on Slack. Super-cool. TicketMaster, if you’re buying tickets on Slack. But also a lot of fascinating and exciting, like NASA - I have talked about that before - doing really cool stuff on top of Slack. And of course, there’s a lot of technology companies - the Paypals, the LinkedIns, Spotify, Pinterest… They’re all running their businesses on Slack.

[59:46] And not only do we have rapidly growing numbers of users, but I think the demands on the service in terms of “We can never go down” are really high. If you think about consumer internet businesses, for example Twitter (we talked about them earlier), or Facebook - when those services go down, of course that really sucks, and there’s clearly a loss for those companies in ad revenue. When Slack goes down, the people at Capital One can’t do their work, and that’s terrible. If TicketMaster goes down, then potentially they can’t process orders. So the reliability and scalability constraints are real, and I think that’s really exciting, because I think it means that we’ve built an incredible product, that people love and that people rely on every day to do their job, and ideally, we’re in the background… Like, we just work.

Segueing into – you had asked a few other numbers… When I first started using Slack, before I ever thought about working at the company, I had started a company and I installed all the engineering integrations on top of Slack. So I did GitHub, continuous integration, PagerDuty, we also use Zendesk for our customer support tickets… So we have a really active and vibrant developer community that builds on top of the APIs, so we’ve got something like 1,000 apps in our app directory. The app directory was actually the first big launch that I was part of at Slack, which was super cool, because you had to go search for apps, and that’s how in my early Slack days I found apps - I would do a google search; now you can search in the app directory.

This is just so cool, because I’ve built apps before I even joined the company; I built integrations, so I could send data, pipe data from our systems into Slack, so that if something was going wrong, I hooked up our error servers to Slack so that I could see the channel light up, versus waiting for the email or waiting for the page, because I was in Slack all the time…

There’s something like 155,000 of these weekly active developers building on Slack. So that’s a lot of people building on Slack, and I think that’s so cool, because they are building things that we never could have imagined, in a wonderful way.

Alex Sexton: It’s like an early adopter situation, in the sense that it’s early for Safari and late for Google, but I think for the web, still not a whole lot of people are doing this, but absolutely you should, if you can.

They also have a tool called the Lighthouse tool that will run over your app and give you your score against all this… So you can search for “Google Web Developer Lighthouse Progressive Web App” and I’m sure it will come up.

Jerod Santo: The 12-factor Agent

Dex Horthy, who has been hacking on AI agents for awhile, set out to answer the question:

What are the principles we can use to build LLM-powered software that is actually good enough to put in the hands of production customers?

What he came up with is 12 factors, in the spirit of The Twelve-Factor App:

1. Natural Language to Tool Calls
2. Own your prompts
3. Own your context window
4. Tools are just structured outputs
5. Unify execution state and business state
6. Launch/Pause/Resume with simple APIs
7. Contact humans with tool calls
8. Own your control flow
9. Compact Errors into Context Window
10. Small, Focused Agents
11. Trigger from anywhere, meet users where they are
12. Make your agent a stateless reducer

If those 12 bullet points are more confusing than enlightening, that’s because they’re just bullet points! Click through for the full explainers.

Jerod Santo: It’s now August: Turns out most programmer are unhappy. Llama 3.1 gives ChatGPT a run for its money. Scientists confirm flow state is a thing.

Coolest code: ChartDB. What’s cool about this open source, self-hostable web app is its instant schema import:

Run a single query to instantly retrieve your database schema as JSON. This makes it incredibly fast to visualize your database schema, whether for documentation, team discussions, or simply understanding your data better.

Best prose goes to Do quests, not goals. I love David Cain’s re-framing of short-term goals (which are uninspiring) into quests! “I’m on a side quest to fix my Vim config” is a lot more fun (slash impressive) than “I’ve been tweaking my Vim config the last 4 hours”

And my fav episode: Why we need Ladybird

Getting to interview defunkt (Chris Wanstrath) alongside Andreas Kling was the cherry on top of this delicious episode. We discuss what it’s going to take to get to alpha, the why behind Ladybird, avoiding incentives other than those of the users, their plans for incremental adoption of Swift as the successor language over C++, and of course what they hope Ladybird can achieve as a truly independent open source browser that’s for the people.

David Heinemeier Hansson: Yes. So we have two commercial products in the wild that use SQLite. They are of the single tenancy nature. So the one product is Campfire, a chat system like Slack, where you get the code, and you can install it and run it on your own server. We boiled it all down to like a one-command setup, so that you can run your own instance of this chat system. And it runs on a single machine, and it runs SQLite. And we did a bunch of performance testing to figure out “Where are the limits here?” And I think the top machine we used was something like - I want to say… Was it 30 cores, or 24 cores, or something like that? And that got us to 10,000 concurrent chatters that were all saying something once a second, or something… So we pushed it quite far; much further than almost anyone who was using a single tenancy application ever would, in this circumstance.

But now we’re getting curious. Of course, I’m getting curious. I’m like “Alright, it works for that case.” It works for the case where someone buys Campfire and installs it on their machine and they can run up to 10,000 chatters. That’s great. But we also make other SaaS products. Like, would it work for something like Basecamp? Would it work for Hey? Alright, maybe those are just beyond… But we’re working on two new products right now where we’re exploring exactly that question. How can SQLite work in a multi-tenancy setup? And there’s some real appetizing benefits as to why you would even attempt that. And one of them is isolation.

So when you run multi-tenancy in SQLite, where each individual customer has their own database - first of all, none of the data is touching. You’re never going to have “Oh, it bled into the other account.” Even though with modern development techniques that’s not the major thing. But what is a major thing is right now on any multi-tenancy app built on Postgres or MySQL exporting that data into a format where you could then import it again is not trivial at all. And a big part of that reason is that the primary keys - they’re all intermingled.

So I have 10,000 customers. They just get primary keys assigned off the basis of like an integer that’s incrementing. So the data doesn’t kind of go back in quite as neatly as necessarily it goes back out… But if SQLite has the entire dataset for one customer, you could literally give them the file. You’d be like “Hey, here’s the SQLite file that you’ve been building up on our service. Now it’s yours.” And then also, by the way, if you do a model like we’re exploring, where that data could then run on your own instance of the app that we’re building - that’s pretty freaking cool. Now you could run that data in a SaaS setup if you want that, and you could take the data straight out and run it on your own server, if you prefer to have it in your own sort of setup.

[00:58:04.25] I really like the sound of that. I really like the idea that some of the scaling challenges that multi-tenancy apps run into, they run into because the whole system just gets too large. You look at something like Basecamp, it’s just terabytes and terabytes of data, right? It’s actually not – it’s still a hard problem. How do you make a database fast when you have tables that are terabytes in size?

Jerod Santo: ChartDB is a web-based database diagramming editor

What’s cool about this open source, self-hostable web app is its instant schema import:

Run a single query to instantly retrieve your database schema as JSON. This makes it incredibly fast to visualize your database schema, whether for documentation, team discussions, or simply understanding your data better.

They give you a “magic query” that you take and run in your database (Postgres, MySQL, SQLite, etc.) and then paste the resulting JSON into ChartDB for it to visualize. From there you can use the interactive editor to fine-tune the schema. It also looks really nice. Image in your chapter data and the newsletter.

Jerod Santo: Being the measly podcasters… We just try to get a hold of the app owners and say “Hey, this is cool. You should try it.” And most of them ignore us. So Pocket Casts has been very receptive, it’s awesome now that we know you, Marco Arment at Overcast, he takes feedback and feature requests… He says no to lots of stuff… But then there’s the big apps that we just have no – we have a public email address that we can use. And so we don’t really have any chance influencing them. But I think as an app owner now, you’ve got a lot of cool power you can wield, for the better.

Zach Lloyd: That’s really cool. There’s probably other places in the app we could do that as well. I like that idea.

Jerod Santo: Right. So lots of cool stuff, like ground floor, for people who are like “This is a pretty neat tool.” What else is cool about it? And I guess before you answer that, it gives us breadth, right? So it says “From development to production.” So there’s the breadth of the tool. You’re gonna use this to dev, but you’re also gonna deploy production apps with this… But it doesn’t give the scale. You’ve mentioned prototypes, you’ve mentioned hackathons… If I’m reaching for a tool tomorrow to build a modern web app, what kind of web app would I use WMR? And maybe where does it stop scaling? Or does it stop scaling? Is there a complexity? Like, if I’m building a modern Gmail, would I maybe reach for something?

Elisha Goldstein, PhD: And I think an important thing – and prior to us getting on here, Mireille, we talked about this idea of the Why… We have these thing that we know; everyone who’s listening here sometimes knows what’s needed in their life to be more balanced, to be more grounded, to walk their days with more intention, with more of a sense of play, with more of a sense of lightness… They know what’s needed, but it’s really hard to put it into action. We know we need to exercise more maybe, or stretch our bodies more, or we know we need some stillness maybe in our lives, or not to eat to the bottom of that giant bag of potato chips.

But then the question is, if I’m gonna employ these things, these things of caring about myself more, of being more skillful, why am I doing it? And to ask ourselves that question, to pause long enough and say “You know what, I need to take some time to think about –” I always think about this in response to, by the way, our smartphones. There should be a driver’s test that’s given before people are given a smartphone, don’t you think? Let’s take a step back and say “Okay guys, pause and let’s see how are we using this thing in a way that’s gonna be skillful for us.”

But the question is Why? Why do I wanna employ these methods? Because otherwise, the brain is not gonna have a reason to actually do those things. If we’re gonna talk about mindfulness and meditation, you saw for the past ten years all over every magazine - Time Magazine, Newsweek, all of these; it’s been all over everything, and it’s had the greatest incline of research all over the United States and around the world… And the question is, if I wanna employ this - yeah, this sounds really cool. You found me on the Calm app, on Meditation Studio, InsightTimer, or whatever apps there are… Why would I wanna actually motivate, to take the time out of my seemingly busy life to pause and train my brain? What is it gonna give me? And I think it’s important to take that time out, to ask ourself that question. Our brain actually has a reason to make that choice, to do that thing.

Jen Looper: That’s incredible, and I think it’s huge for the learning, the people who are trying to build courseware and who are trying to teach, especially with IoT. We actually have an IoT component of Vue Vixens. I was partnering with Particle, they gave me some devices, and we did a cool, little workshop… You’re running a mobile app that can control your Particle device, and it’s all JavaScript. It’s incredible stuff, and I think it’s great for learning. People love that tangible feeling of “I made something light up with JavaScript”, that’s crazy!

Christopher Hiller: I’m not working in the web much anymore… But I do collect some numeric metrics, I do some automation stuff and have lots of numbers. There’s an app called Grafana, which basically is a tool for creating dashboards of numeric time series data and that sort of thing. I mean, it would seem to me that there has to be something out there that works kind of like Grafana, where they give you all these components and then all you have to do is plug in the data, and then the user can actually go in and design what widgets appear on the dashboard. You don’t have to actually – it’s not static. Maybe you could set up a default set of widgets that a new user would see, and then they can go and say “Oh, I’m gonna create my own.”
I’ve seen a lot of systems like that, I don’t know if there’s a good one that is kind of general purpose. Grafana can’t be used for something like this, simply because it only works with numbers pretty much, so it’s kind of awkward to do anything else.

Jerod Santo: Before we go, I wanna give a shout-out to another live streamer, one that we know quite well… At least we know him by his handle, which is joebew42 on Twitch. He’s been live streaming while he contributes to open source, and lately he’s actually been contributing to our website, which has been very cool.

Changelog.com is an open source Elixir app, and Joe has lovingly crafted a few features for us, including a JSON feed, which he just recently added… So it’s been very fun to watch him live stream as picks through mostly my code, and second-guesses all the things that I do. It’s very fun kind of meta, but he’s a great live streamer, so maybe I should open up a pull request on this list and get him added. Joe, thanks for streaming and thanks for contributing to our open source projects.