Yukihiro Matsumoto: You know I am pretty happy about working with Ruby. You know, it’s a good language - sure, I say that. It’s quite challenging, we have to solve many technical challenges, and that is quite amusing for us as programmers. So we are pretty happy about working with Ruby,but sometimes we feel frustrated to keep compatibility. We have millions of Ruby programmers out there, so if we make any incompatible change, that would break so many Ruby programs. So due to - I don’t like that word - social responsibility, we are very conservative to make incompatible change. In recent years the keeping of compatibility was our primary goal of the design and enhancement of the Ruby programs. So those compatibility things sometimes hinder us to make progress. In that way I sometimes envy the other programming languages, namely minor programming languages. They can make big changes very easily.

Adam Stacoviak: [12:01] This is interesting about Apple - they wanna be a privacy-focused company, as a brand… But it requires, in their case, the way they deliver products, particular hardware, and in this case technological breakthroughs, in this kind of device, to have that many chips and that much smarts behind a smartphone. Without this technology enhancement, they couldn’t be - well, I’m sure they could be, but they would just be a little further behind - the company they wanna be. So on the iPhone, on the iPad - each was there. Now, what I didn’t hear was how that affects Apple TV… Because I’m not sure what Apple TV has for machine learning, or this other stuff; so it wasn’t a case played there, but they mentioned of the Apple Arcade, where… Hey, I just wrote “privacy” again, and I’m like “No… Hey, this is the third time we’re hearing about privacy.” Third new thing, third time they mention privacy as a feature… You know, you’re just seeing this marriage of a company’s desire, and it requires hard work, it requires technology advancements, it requires a particular perspective when it comes to respecting your customer, too.

Johannes Schickling: So the way how I’m starting to think about scenarios like those is similar to how we’re using Git. I think we’re thinking less about Git as an API endpoint that you correspond with, but you’re thinking about Git as a semantic protocol that you use in a very specific environment, in this case how you evolve your code repository in a semantic way. And I think the same analogy could have also hold true for your scenario.

[00:39:47.06] So obviously, this would have taken quite a bit more effort to define and develop this, and so on, and build SDKs for the various target platforms etc. But I think from a mental model perspective, there’s nothing inherent that this needs to be an API. I think the synchronization mechanism still holds true to this, and this is where Git is sort of a very commonly-used synchronization mechanism. And I would like for apps to embrace the sort of “more Git, less APIs” mindset, where often that can be more declarative, instead of APIs often being very hand-wavy in an imperative way. But yeah, it will take time to get things off the ground there, and kudos to you again for just putting in so much effort in the pioneering work that you’ve done over the years, and particularly also targeting the web.

I think the web is both like a blessing and a curse. It is a blessing that it can already do all of those things that it’s possible with right now, the ubiquitous distribution you’re getting with the web etc, but it also lags behind in terms of capabilities that we’ve already had for decades on more native platforms. I’m very bullish on the web even catching up with those native capabilities. I just want to add a few points on what you’ve mentioned before in regards to file system support etc.

So you’ve mentioned OPFS as this origin private file system, which I think by definition is non-accessible to the user. I think the current way how it works for example in Chrome is there is actually some folder somewhere, I guess under application support or library somewhere on macOS or in different places where you can actually see the real files, but this might just be an implementation detail. It’s not meant to be user-accessible. However, also in Chrome there is a – I’m not sure whether it’s even [unintelligible 00:41:50.11] but there’s a separate API with mostly the same API surface, where it lets a user actually mount a real file or a real folder system from their actual hard drive into the web app, and you can read and write from it. So with that you get real files in your app, and those files don’t go away if something happens to the web app, unless the web app decides to delete it. But this way we’re already taking another big step towards native capability apps, at least in Chrome for now. I’m not sure what the current status with other platforms, with other browsers… But stuff like that gives me a lot of hope. If I’m now wearing my application developer hat for Overtone, what I’ll probably do is like I love those capabilities, and I’ll embrace them for the given browsers. So I’ll probably say like “Hey, if you want to use the web version and not the desktop version, and if you want to have the most advanced experience, then please use Chrome, use Arc etc.” And if you use another browser, then I’ll diffuse the capabilities a little bit, and hopefully in two years Safari and other browsers have caught up.

So I’m more long-term minded on this, and I don’t look at a feature and say “If I can’t have it on all platforms, I’m not having it at all. I’m rather like opting into features, progressively enhancement way, step by step.”

Simon Willison: So this is the thing that everybody wants. Every company, every open source project, everyone wants a language model trained on their own documentation. And it feels like “Oh, that sounds like it would be really difficult”, or you’d have to fine-tune a new model on top of the older documentation. It turns out you don’t need to do that at all, but there’s a really cheap trick… And the cheap trick is that somebody asks a question, and basically, you search your docs with further terms in that question, you glue together four or five paragraphs from the search results, you splat those into a prompt with the users question at the end… So you basically say, “Hey, ChatGPT, given these three paragraphs of text and the question “How do I configure a Docker Compose container for this project?”, answer the question, and that’s it. And that works astonishingly well, given that it’s basically just a really cheap hack.

There’s an enhancement to that, where rather than using regular search, it uses embeddings search, which is a way of doing semantic searches. So you can take the user’s question and plot it in a 1,500-dimensional space against the previously plotted documents, and then find the stuff that’s semantically closest to it. So even if none of the keywords match, it should still catch the documentation that’s talking about the sort of higher-level concept they’re talking about.

But yeah, it’s actually not hard to build this. I built a version of this against my blog back in January, using like some custom SQL functions and things. And then Langchain is a Python open source project that has – this is one of the dozens of sort of patterns that are baked into it. So it’s very easy to point Langchain at the documentation and get a bot working that way. There’s a ChatGPT plugin that they built, that OpenAI released, that does this trick as well.

So it almost – it feels like building a chatbot against your own private documentation, which last week there were a dozen startups who this was going to be their entire product, today it’s like a commodity; it’s easy to get this thing up and running.

Deepthi Sigireddi: [laughs] Okay. So a few things stand out. Vitess has backup restore functionality. For any database, you need that, and specifically in the case of Vitess, if you want to add more replicas, you will restore from a backup, and then catch up to the current primary, and then you are ready to serve.

So Vitess had its own way of doing backups, which was basically “Shut down the MySQL, copy everything over, and then restart it.” A number of members of the community wanted extra backup support; they wanted to be able to use Xtrabackup to take backups, so that they don’t have to bring down the MySQL. Because with extra backup, you can take backups on a running instance. So that was my first major enhancement to Vitess, and that’s why I remember it so clearly. And this was actually sponsored by Slack, but I ended up being the person doing the work.

And then, once we did that we also did a feature where you could do point in time recovery. So let’s say somebody did something bad, lost some data, you want to go back to a good, known time. You want to be able to go backwards in time. Most of the time this is for the purpose of 4 and 6. You wanna go back and say “Okay, what happened, what was the state of the data at the time” or whatever. But point in time recovery was something else where – I didn’t do all of the work, but myself and another engineer together did that.

And then, health check. So in Vitess there is a component called health check. So what we are doing is that if you look at the Vitess architecture, there’s a metadata store, a TopoServer which stores the list of all the tablets. But you don’t rely on that when you are serving queries. So you have the proxy layer called VTGate, which receives the MySQL connections and queries, and sends them to the tablets. But it needs to know what is the primary for a given shard. And the way it keeps track of that is that it establishes connections to all the tablets and it receives periodical checks.

So this health check code was actually very complex, and we would get bug reports, and they were very obscure, very hard to track down… They would only happen under certain conditions, because mostly they were race conditions, or issues with locking, and stuff like that.

So I ended up rewriting all of that, and that is one of the hardest software projects I’ve done in my life, because that code was very complex; it was almost impossible to understand what it was doing at a core level. So Sugu sat down and told me what it should do. He said “Don’t think about what the code looks like right now. I’ll tell you what it should do, and then you can implement that.”

It was so difficult that parts of it were done by three people together. So we would get onto a Zoom call or some sort of a video call, and screenshare, and start looking at the code together and start writing code together. So the health-check rewrite was a big deal. And what that enabled us to do was to support replica transactions.

Prior to rewriting the healthcheck we did not have a way to do read-only transactions on replicas. You could do read transactions on the primary, but there were some users who said “We basically want a snapshot when we begin the transaction. We don’t wanna see the commits that happen while we are reading data. So we really want to do a “Begin, read, read, read, read, read, and end.” So replica transactions was something that we were able to do because we rewrote the health-checks. So these are some things that I can remember.

Kent C. Dodds: Yeah, yeah. So we don’t run it necessarily as a single request. I mean, on a client transition I think we do… But we run them all in parallel. So every one of your route modules can export a loader, and when a user navigates to a different page, or if they just land on a page, then we run everything in parallel. So you cannot access your parent loader data, because if we allowed you to do that, then we would run into this data cascade, which is not good at all.

So yeah, every single loader runs in parallel. We do not have this problem… And I guess I’ll fill in the silence and talk about forms. [laughs] So loading data is an interesting thing, but making changes to data is what really makes the difference between a website and a web app. I mean, the distinction between a website and a web app is kind of silly anyway, but a lot of people will, I guess, say that; I don’t know, I don’t care what the difference is. You can build web apps with Remix, you can build websites… I don’t care. But mutating data is often the missing piece in most frameworks. Most frameworks are like, “Yeah, okay, we have a really nice API for loading the data. Oh, but you’re gonna change something? You’re on your own. You’ve gotta figure out how to update the data when you make a change”, or whatever. So we’ll bring in these different libraries that know nothing about your routes, and you have to wire everything together.

So Remix says “No. That’s a very important part of the web. Since Web 1.0 we had forms for mutating data, and we’re gonna do that again.” So Remix gives you a really nice API for data mutations that is just a form. And when you load data, you use your loader; when you mutate data, it uses your action. So you have this form, it automatically posts to the route that you’re currently on, and so just like with the loader, when you’re writing your component, you’re like “Oh, I need more data. I’ll just scroll up the file to my loader, make some changes on the server-side”, and then boom, I can use it. If you’re writing a form, you can just scroll up to your action function, and now you can handle what happens when a user submits a form. And this, again, only runs on the server, so you can do all your validation logic there, and whatever; you can share validation logic if you want to… So if you wanna run some validation logic on the client, you just literally take the validation logic, put it in the function and use it in both places. Like, in the same file. So it’s pretty straightforward to do that.

[40:07] And then you can, again, use your private keys, connect to databases, whatever, because it’s just on the server… But then to take it even further, Remix kind of takes cues from Web 1.0, where if a user submits a form twice in a row - so like they hit Submit, and then they… You know, we’re checking off a to-do list, or whatever; check, check, check… What the web browser does before we bring in any JavaScript, the web browser will say “Forum submission is a navigation, so we’re gonna go and we’re gonna wait for the server to respond”, and then the user says “Go again” - they actually cancel that request. So they ignore whatever response that was, and they’ll send a new one. And boom-boom-boom, you can send and cancel. And Remix does exactly this same thing.

And also, when the server finally does respond, the browser is going to render whatever HTML the server responded with, or if the server is doing things right, they’re gonna redirect the user somewhere else, so they can go and get that. So what that effectively is - we say hey, all of the data on the page is completely up to date, because we just barely got it all from the server. Remix does the same thing. By default, when you make a mutation, Remix says “Who knows what changed on the server?” Nobody knows. Not even the developer sometimes. “So we’re just gonna go refetch everything.” So what this means is by default you never have to think about keeping state up to date. You don’t have to worry about application state at all. That’s why I said you don’t need Redux, or anything like that, because as soon as the user makes a mutation, Remix will go ahead and update all of the state that’s on the page.

Now, of course, you can optimize that. There might be some unnecessary data fetching happening. But the default is correct. And I think that is really, really powerful. And on top of that, because we build web apps, not every single mutation is a navigation necessarily, so we have really nice APIs for non-navigation mutations, but they operate in effectively the same way. So this drastically simplifies a lot of what most people are building on the web these days when it comes to mutations. And even people who used to write web apps like 6-7 years ago are singing the praises of like “Oh my gosh, this feels just like it did before.” And then the people who are building modern websites, or who – sorry, I should say that differently. The people who have just started learning building websites in the modern world are like “Wow, this is a totally new approach. Using a form instead of a button with an on click? Wow, that is interesting.” But it all works really well… And on top of that, it also works even before the JavaScript has finished loading. So we load it faster, and if the user happens to start using your app before it’s finished loading, it actually still works. So progressive enhancement is coming back. We’re making a come-back with progressive enhancement. This is really a big win for the web. So… That’s exciting for me.

Phil Hawksworth: Yeah, and I absolutely think there are… But that moment of authenticating - that’s the perfect place to start to think about using JavaScript and APIs. And again, there are these services now that we don’t have to roll our own; there are identity services, authentication providers that you can use, with things like JavaScript web tokens, and different authentication methods that can then unlock either access to routes to things that have been pre-generated - that’s a common path… Because sometimes you and I might visit a URL and after authenticating get things that are personalized just to us. And maybe those have been generated at request time, or embellished at request time through some kind of progressive enhancement.

But you might equally find that you and I might visit the same URL, which is private, and maybe has targeted content for us after we’ve logged in, rather than very individual content… So in that case you can start segmenting the content, pre-generating that, and then all you’re doing - and I should be careful saying “all you’re doing” and using words like “just”… But what’s happening there is you’re doing the authentication that then allows people access to the URLs which would be pre-generated for them.

Johnny Boursiquot: I do like to group them together, and for all the reasons the two of you have mentioned. One thing that I’ve started thinking about is – I’m a big fan of using the standard library for most things… And even when I had to sort of jump through a couple of hoops here and there, in small applications, to do my own URL parsing, to extract variables or values or something like that, I’d opt for using the standard library… Even if I had to jump through those hoops, as opposed to using a framework like the popular ones, a Cheese, or a Gin, or whatever that is popular these days.

Obviously, with the introduction of sort of the more robust routing library enhancements to the HTTP package from - I think 1.22? Or was it 1.21? Now I’m pretty happy about that, I’m pretty stoked. I can still stick to the standard library without having to bring in those additional frameworks.

But those additional frameworks did sort of do the right thing, so to speak, by allowing you to sort of define all your routes in one place. You set up all your middleware in one place. They sort of encourage you in that direction, because it does make sense to have all the routing and all the middleware logic grouped together like this. It does make sense.

Cory LaViska: That’s actually not the full quote. That’s a paraphrasing of it. But the point is, we are in a better position to do the hard stuff one time, and let the users do the easy stuff. So we’ll handle all that. If you want to do it with CDN - fine. We can offer that. If you want to do it with a bundler, fine. We’ll offer that, too. Our build step handles that, so you can choose to either have a build step or to not have a build step. So like I said, best of both worlds. We want to accommodate everybody. We don’t want to say “Hey, we only offer a CDN. You’re stuck with that. Just use that.” No, because there’s some good tooling enhancements that can come when you import an NPN module, and you get Typescript, and you get all these cool things… We have a custom element manifest file that you can get in there and link it up to VS Code, that you get autocomplete as you start typing in tags… So there’s a lot of cool stuff that we do. You don’t necessarily get that over the CDN, but it’s there if you choose to go a little bit further.

Kris Moore: That’s something people have been waiting for for a while. We got that in. That’s really kind of that last feature parity thing we needed for the majority of Core users who are kind of waiting to move to Scale. So that’s in, that’s great. The SMB side… So if you’re an SMB user, that’s been beefed up. Significant performance enhancements for that. Multi channels supported… And some of my favorite new functionality is you have things like auditing built in. So now TrueNAS can keep audit logs of your SMB user accesses, audit logs of user interface accesses… You can also see SMB session information now, so you can log in and see in real time who’s connected to what, and what sessions are running, and all that good stuff. That’s very, very nice.

Let’s see, on the other side here… A lot of improvements on the backend, kind of sub ZFS performance things, block cloning is enabled… Again, that’s that in-line dedupe. So if you’re copying a file - you’re an old school ZFS guy, so you know… If you copied files between datasets before, it actually had to make a copy of the file to move it over, and that took time, right? Well, with block cloning now - again, it’s just making pointers. So you don’t actually have to sit and wait for that 500-gig file to copy between a dataset. It’s just instant like that. So… Very nice. And you get the dedupe benefits, because you’re not storing a second copy of all those blocks. So that’s a cool feature that’s going to be in Dragonfish.

[01:24:20.03] A lot of little new UI improvements as well… There’s a fantastic reporting feedback button up at the top, where you can with a click bring it up and submit as a screenshot of what you’re seeing on your screen, along with a debug. So if you do run into a problem, we can hopefully triage it and fix it just that much faster now. That’s really an amazing little feature.

And then just the usual assortment of scattered performance things. The Linux Kernel 6.6, for people who are curious - we try and follow the latest LTS kernels from upstream Linux. So if you’re building newer hardware systems, that’ll be a much-needed improvement for a lot of folks… But yeah, that’s some of the major things, and we’re excited to get that into people’s hands. The beta is out now when we’re recording this; I’m not sure when it’ll air, but on Tuesday –

Nadia Odunayo: And there’s two in this. One point is to say “We haven’t yet done this transition that I believe will accelerate the adoption of Plus.” So I feel the reason why the adoption of Plus – right now what you see people saying is “I don’t even need to get Plus, because the free product does everything I want, and it’s this grab bag of features that adds little enhancements to a whole range of features”, of which most people are not interested in all of them. And so what I’m curious to see is when we transition it to - you can literally create your own charts, you can create your own… Let’s see what adoption looks like them.

But we also have another revenue stream, which is giveaways. So publishers and authors pay to list competitions for their books on the app. And we’ve got two tiers there. We’ve got a standard tier and a premium tier. And with the premium tier, your book is on the homepage, and there’s a link – everywhere your book shows up, there’s a clear, gold link of like [unintelligible 00:59:28.29] and things like that; there’s extra features. You can get a custom notification, so you can – because you would have like tens of thousands of entries, so when the giveaway ends, your personalized message gets sent to all of those entries… And essentially, this is a win-win-win, because it’s a win for the publishers and authors, because they essentially have a way to advertise their books to our community, millions of users… It’s a win for the users, because to them it’s not really ads, it’s a chance to win free books. And then it’s a win for us, because it’s another revenue stream. And right now we’re getting more revenue from Plus, but I do see a world where, depending on how it goes, the giveaways overtakes that. We’ll have to see; it’s hard to tell right now. But we do have that other revenue stream, which is our kind of b2b kind of –

Kevin Ball: Yeah, so Kyle asked two questions that are related. The first one I think we’ve covered a fair amount, but it says “Has the scope of support and lifetime of the project positioned Node to be slower to iterate in terms of performance enhancements?” Which I think we’ve already answered. Yes, kind of. But the follow-up question to that that he has is “Is there any way to keep pace?” which I think would be interesting to dig into. And then there’s also a secondary question around kind of does splintering in usage hurt the community, or does it help, because you have this kind of lifting of all boats, people trying different things and iterating differently?

Joe Davidson: Yeah, it helps with adoption, doesn’t it? …to explain to people how to use it. I guess one of the enhancements to that in the future is going to be to actually dogfood Templ, and use it to hopefully generate the docs… Because ironically, at the moment, I think it’s using a React-based documentation engine, Docusaurus.

Amal Hussein: Astro 10.0… The SSR enhancements are also very exciting. I thought this was really cool, because it kind of also touches performance improvements as well… So they’ve added support for per-route code splitting, which for multi-page app is huge, and very exciting. So you’re getting to kind of dynamically send stuff up, and kind of improve your performance as a result of that… That’s huge. Less bytes over the wire, all good stuff. And then they have edge middleware, so you can now bundle your middleware for deployment on the edge, which I think is interesting… I’d love to – I don’t know if you all have examples of when or why people would be doing that kind of stuff. I personally don’t, so I’m eager to hear any thoughts that you have on that.

[12:16] And lastly, they have support for host customization, which I thought was also very, very exciting, because you basically – it’s similar to kind of the per-route code splitting. You’re able to kind of send a dynamic or bundle up based on if you’re using an AWS… Like, depending on where you’re rendering and what you’re rendering platform is, and as well as your compute engine. It’s very, very cool.

Natalie Pistunovich: And jumping to the answer. The Go community is considered a strength for the language for several reasons. 1) Active and supportive community. The Go community is known for being welcoming, friendly and supportive, which encourages developers to learn and adopt the language. This creates a positive environment for newcomers and experienced developers alike to ask questions or knowledge and collaborate on projects. 2) Open source contributions. Go has a large growing ecosystem of open source libraries, tools, frameworks thanks to the active involvement of the community. This allows developers to find and use third-party solutions for common tasks, which can significantly speed up development and improve code quality. 3) Community-driven improvements. The Go language and its standard library continues to evolve and improve, with many changes and enhancements driven by the feedback and contributions from the community, to ensure that the language remains up to date and well-suited to the needs of the modern software development. 4) Conferences and meetups. The Go community organizes conferences and meetups around the world, providing opportunities for developers to learn from and network with Go developers and Go enthusiasts. These events help spread knowledge, promote best practices, and foster connections within the community. 5) Online resources. There is an abundance of online resources available to help developers learn Go and get the most of the language. These resources include official documentation, blog posts, tutorials, videos and online courses, many of which are created and maintained by the community. 6) Strong focus on simplicity and readability. The Go community emphasizes the importance of writing clear, maintainable code. This shared mindset helps foster a culture of collaboration and code sharing as developers can more easily understand and contribute to each other’s work. Overall, the Go community’s commitment to collaboration, support and continuous improvements has played a significant role in the language success, making it an appealing choice for developers worldwide.

Amal Hussein: [40:13] [laughs] Okay, so first of all - wow, a lot to unpack there. So let’s just take it from the top. Document versioning - so that’s huge. When I heard about that, I was like “Oh, my God.” Like, wow… Talk about solving a really big pain point for maintainers. This is something where – unfortunately, it’s one of those things where it’s felt by the maintainer community, not so much the broader developer community… But it is a real problem. Maintaining versions of your documentation within the same repo, getting the npm publish to show that correctly, yadda-yadda-yadda, for every major version patch and minor version of whatever that you’re supporting - it’s like a huge undertaking to keep those docks in sync as well. So first of all, amazing, amazing feature.

And then like the translations piece that you’re talking about - the internationalization support. So that’s not necessarily new, but it seems like you have some enhancements that you’ve made to the core functionality in v2 - that itself is huge, too. Being able to kind of – I love this idea of “What are all the things that you need to do to maintain documentation sites?” You need to maintain it in different versions, you need to possibly get it translated, people are gonna want to search it, so you have the search functionality as well… So it’s like all of these things that everybody’s doing manually in different ways, and poorly, you all have kind of abstracted and created these clean interfaces for the community to leverage, especially the maintainer community, because these are the folks that are doing the heroes work already… So anything we can do to make their lives easier is just a huge win. I’m so glad to hear about all the success and adoption. Looking at the website today, I’m seeing Mark Erickson, our beloved Mark Erickson talking about this, [unintelligible 00:42:01.07] from the Angular community, Supabase, Kent C. Dodds, you name it. All these people. Debbie O’Brien… So lots of folks kind of singing praises for this project… So kudos. Pretty good stuff. So what’s the feedback that you’ve been getting about v2, in terms of kind of missing functionality, or things that could be improved? Can we talk about the part of the retro that’s like what to improve?

Adolfo García Veytia: It’s a really wonderful process. So the way Kubernetes works is contributors merge their code into the main Kubernetes space. So release managers, going through the process, making sure some of those changes get cherry-picked back to the branches where they’re needed. And when we’ve got batch releases for the old branches, that release manager goes and cuts that thing.

Releasing a new Kubernetes minor version, like 1.24 now - it’s a huge endeavor, comprised of several teams that go together and do things like the release notes, [50:58] enhancements, ensure bug triage is finished by that time, documentation, communications, the blogs… And there’s a release lead that coordinates all of this. The release team is comprised of around 30-35 people who rotate every cycle. Right now, by the time this episode airs, the survey to be a part of the release team should be out; so if people are interested, they can apply there.

It’s really competitive. Of all the names that apply, only around 13% get chosen. We of course encourage the leads to balance their team, and distribute it across the globe, across gender… All of that, to get a team as diverse as we can. That’s on the human side.

On the technical side - just a super-quick rundown is we build the project, stage all of the artifacts, do end-to-end verification of everything that’s out there, and then we run our release process that puts it out to the registries, to the bucket where you can download your Kubectl and all of the binaries… And now we also added the security artifacts around them, like [unintelligible 00:52:10.24]

Mohammed S. Al Sahaf: For the shell actor there are a few enhancements that I’ve been working on locally. I know there are certain areas or gaps in the implementation that I have picked up on – that I’ve fixed locally, and I haven’t pushed yet… Because C is in the way. So the shell needs a lot of enhancements. There are a lot of actors that could be implemented. Perhaps proxy… I don’t know. It takes a bit of creativity. Shell and static response were the least creative things, and they were probably the mostly used actors or expected functionalities out there… And this is why I went with them.

Chris Ferdinandi: Yeah, this was a huge part of our conversation last time. React isn’t inherently bad; it solves a very legitimate problem that the developers at Facebook have. But for 99% of us, we are not building things that are anywhere near Facebook’s size, scale, needs. And so we’re using a tool that was built to solve a specific problem that doesn’t necessarily match up with ours. State-based UI - problem; state-based UI at that level of scale, with all these other kind of moving parts and needs, usually not so much. The Pareto principle is a really good way to kind of frame that.

So I find that exciting. I’m really glad to see people kind of taking this concept and saying, “What can we strip out of here and still maintain kind of the kernel of what made this so good?” But there’s another trend that I actually think is even more exciting, and that’s the rise of precompilers.

So a few years ago, Rich Harris, who works over at New York Times, realized that state-based reactivity can be a good thing; handling it all with a mountain of client side JavaScript is not. And I will send you a video - his kind of initial talk on this that we can link to in the show notes if you want. But he ended up creating a tool called Svelte, which we talked about a little bit last time.

And the way Svelte works is it gives you a similar-ish authoring experience to something you might get with like Vue or React; it lets you create reactive, state-based components. But instead of shipping them as-is to the browser and then letting the browser kind of run all that stuff in real time, it runs a compiler that spits out plain old HTML, some Vanilla JavaScript, and that’s about it. The Vanilla.js does the same kinds of manual DOM manipulations that you would do if you weren’t using a framework. So rather than doing DOM diffing live in the browser, the compiler figures out what needs to change when different things happen… Alright, let’s spit out just a little bit of JavaScript to do just those things. And, “Oh, this HTML never changes? Let’s just spit that out, like, hard-coded into the HTML file already, so it doesn’t have to get rendered with JavaScript.”

And in my opinion, this kind of thing gives you the best of both worlds. You can write state based UI if that’s your thing, but you get to serve an old school DOM manipulation experience to the users, that’s actually in many cases faster and more performant for them.

Rich also started working on this thing called SvelteKit, which is an extension to Svelte that adds routing, and some really, really smart progressive enhancements, so that if the JavaScript fails, you can fall back to some server-side stuff. He did a talk on this last week, the week before, at the time of our recording, on a new term he coined “transitional apps” that kind of bridged this gap between single-page apps and multi-page apps. And I’ll share link to that with you as well, Kevin, just because I think it’s really, really interesting.

Amal Hussein: And I think for me, going back to our earlier discussion around what makes a world-class team, or a world-class software project - for me in 2020 or 2021 it’s software that’s progressive; truly, truly progressive at its core… Which means that you are handling for different capabilities on different devices within one codebase… So that you are able to do progressive enhancements and progressive – what’s the opposite of enhancement? Dehancement? I don’t know, I’m trying to think of the–

Amal Hussein: Yeah, Flexbox Froggy is crazy, so we’ll link that. An hour of your time and you will have demystified years of “How do I move things to the left…?”

Alright, so the third pro tip is a really good one. It’s a browser extension called Refined GitHub. It’s just essentially a layer on top of the GitHub UI that really just makes the experience a lot better. Everything from being able to shut off comments when you’re doing a review, when you’re just like “I don’t wanna see anyone else’s comments.” Just a better organization of repos… So many nice enhancements that aren’t available on regular GitHub… And it’s open source, publicly maintained, so pretty secure. I’d recommend that, and we’ll link that in the show notes… So you can thank me for making your GitHub experiences better, for free.

Feross Aboukhadijeh: So I’m gonna start at the absolute lowest level. So we’re gonna go all the way down the stack to IP, or the internet protocol. I’m sure most people have heard of an IP address; that’s the level we’re gonna be operating on here for the beginning of my explanation. So what is IP? IP is basically a way where you can take a message, a packet of data, and it’s kind of like an envelope - you can sort of stamp a destination on the outside of the envelope and say to your router “Hey, please try to deliver this to this IP address.” And every computer on the network, every device on the network is assigned an IP address, and the internet as a whole sort of just tries its best to route these little packets of information to the correct destination based on the IP address.

Okay, so that’s the lowest layer. Then on top of that there’s two main protocols that people have sort of added on top, which are called TCP and UDP. TCP is the more common of the two, and it gives you a bunch of nice reliability enhancements on top of IP. So you can sort of, as an application, say “I wanna send this giant chunk of data, in fact too big to actually fit in a single envelope”, and your operating system will split that data up into little individual packets of information and send that across the internet… But it will do a bunch of nice things like stamp little numbers sequences onto each of those, so that the recipient can assemble them in the right order.

Chris Benson: Totally, I got it. I’m good. We’re there to support you. I’m there for you. But yeah, with this new architecture it’s much more performant, but they’ve actually cut the number of GPUs in the server back down to 8 from 16… But it has the enhancements that we just talked about, that are at the processor level architecturally.

Chris Benson: Yeah, I know that one of the topics you and I like to talk about a lot are transformers, for instance… And I’ve noticed – just a few weeks ago I was talking to some folks, and you’ll see these large transformer models come out, and then these follow-ups that are huge performance enhancements… And they may reduce the size of the model, but you end up getting a dramatically faster training based on these optimizations… And I think when you counter that with the fact that we’re seeing GPU, TPU and other hardware architectures really accelerating… You’ve got cloud options, you have options for being able to maybe have a GPU right on your desktop that you’re working, or whatever… And I think the combination of that has made a huge difference in accessibility for people to be able to actually do these.

Dan Guido: Yeah. Just throw it out. There’s absolutely no reason to maintain this. You just destroy the server and you start it up again, and the new version will have any enhancements that we made.