Kevin: Welcome to Svelte Radio.

Kevin: Hello everyone, welcome back to another episode of Svelte Radio.

Kevin: We're kind of doing this often nowadays, I feel like.

Kevin: I'm joined by my two co-hosts, Anthony, Brittany.

Kevin: Hello.

Speaker 2: Hello.

Kevin: Hey.

Kevin: And today we have another special guest with us.

Kevin: Ken, hello.

Ken: Hey, great to be here.

Kevin: Yeah, nice to have you.

Kevin: It's great seeing you all again.

Kevin: And Ken, we met the first time at Svelte Summit when you did a very, very fun talk there.

Kevin: But we'll get back.

Kevin: We'll get into that later.

Kevin: But yeah, maybe before we get into who Ken is and what he's done in terms of Svelte, maybe we can talk about the latest Svelte feature that dropped yesterday.

Kevin: Type, context, anyone excited?

Kevin: No?

Kevin: Very excited.

Kevin: Very excited?

Kevin: I think it's a

Brittney: very exciting.

Brittney: I should really pay more attention.

Kevin: I think it's a small

Brittney: feature.

Speaker 2: You need

Ken: like a little bell to ring or something.

Ken: I'm sure there's

Brittney: a notification I could get.

Brittney: I just...

Antony: I'm sure it's an announcements channel, isn't it?

Antony: But the thing is, if you say typed, I'm like, oh, that sounds great, but I can't use it because we don't use TypeScript.

Brittney: Oh, I use TypeScript.

Antony: Yeah, we don't. We don't use it.

Antony: I'm excited for you.

Brittney: Is

Kevin: that why Beyond crashes all the time?

Kevin: No, I'm kidding.

Brittney: I don't want to use JS doc, but it's just painful to write.

Brittney: It's not nice like TypeScript.

Brittney: Brittany,

Kevin: you're just going to have the LLM write it for you.

Brittney: Write TypeScript

Speaker 2: and then

Kevin: convert it to JS doc.

Brittney: I guess Claude is going to have to learn JS doc.

Kevin: I'm sure

Brittney: he really does.

Ken: Yeah.

Ken: I think TypeContext is like one of those, it's just like a tiny little nugget of goodness, right?

Ken: It kind of takes something you otherwise had to use to do a little bit more effort yourself, and it just gives you a nice little shrink-wrapped, easy, quick way to do it that's like now the standard, which

Speaker 2: does mean I have

Ken: to go back and change code in a few places.

Ken: But I don't use context a ton, but it's a nice little feature.

Kevin: Yeah, same.

Kevin: Are you in a sauna, Kev?

Kevin: I am in a sauna, yeah.

Kevin: That's why they live in Sweden,

Antony: everyone lives in a sauna.

Kevin: No, I actually moved to like a timber wooden house.

Kevin: so it's very cozy that is called all the

walls look like this and it's has like a grass roof as well wow yeah if you want if you want to have like a new extension all you do is go outside

Antony: and chop a tree down and just like layer it

Kevin: up build

Brittney: a

Speaker 2: tree house on

Brittney: top

Kevin: of the house i mean i could do it but i probably shouldn't the roots

Speaker 2: would come down into

Brittney: your actual house yeah i

Speaker 2: mean i'm actually

Kevin: at the moment i'm actually having trouble with like i don't know the the english word for the for the specific tree but there's like seeds from the tree landing on the grass roof and and

Speaker 2: there are actual

Kevin: roots so i have to go up there and like pull out

Speaker 2: this like tiny trees

Kevin: it's only like i think like

Ken: they're only like this big so it's not that i think you just need some baby goats living up there and then it'd be fine

Kevin: you know i've actually thought about it oh

Antony: my

Ken: god seriously they built

Antony: some houses opposite me and and i said look you should have grass roofs because it would look way better so they came and they just put these weird plants in the roof and like they've got grass roofs technically but it's like a load of plants and

Kevin: trays

Antony: on mounts on the roof it's very strange

Kevin: yeah that's that's cheating

Antony: i don't know if you

Kevin: listen

Brittney: to spelt radio often but we often

Kevin: go on these tangents of like just nonsense.

Kevin: You know, I think we'll keep this in.

Kevin: We start talking about typed context

Brittney: and

Kevin: we're on the last point.

Kevin: Yeah.

Brittney: Baby goats.

Kevin: Yeah, yeah.

Kevin: All right, let's get back

Speaker 2: into

Kevin: Svelte.

Kevin: So maybe, Ken, maybe, why don't you tell us a bit about yourself?

Kevin: Who are you?

Kevin: Why are you using Svelte?

Ken: Sure.

Ken: So I've been doing software development for a little too long for me to say out loud.

Ken: I really kind of have a bit of a unique career trajectory, very non-linear.

Ken: So I've worked almost equal amount of time in my career in user experience, product management, product development, and in actual software engineering roles.

Ken: And I guess I'm weird.

Ken: I like all three.

Ken: I guess for me, the unifying principle is just creating software for humans.

Ken: And over the years, I've tended to be very front-end focused when I've been doing development.

Ken: So I've worked with a lot of different front-end frameworks, tools, could go back to the day when we had zero of those on the front-end.

Ken: But so I was always looking for the perfect, or at least closest to perfect framework that just felt right.

Ken: And I remember many years ago when I first discovered, and it was in the early days of it, Ruby on Rails.

Ken: And it was a pretty major innovation and improvement in front-end development.

Ken: Less on the actual browser JavaScript side, but in terms of just how to build a large-scale front-end application.

Ken: And it just made it easy and felt right.

Ken: But I'd moved much more to focusing on leveraging tools that gave you the power of the browser.

Ken: And none of them felt great to me until I landed on Svelte.

Ken: And it just clicked.

Ken: It felt right.

Ken: It felt like the API design, the thoughtfulness that went into how it was designed, the design side of my brain, the UX side of my brain, it just made a lot of sense.

Ken: So I haven't gone back to anything else since.

Antony: You've triggered something in my mind that you say you build software for humans.

Antony: And it's occurred to me that actually there's two disciplines.

Antony: One is building software for humans.

Antony: One is building software for machines.

Speaker 2: All

Antony: this kind of ESP development stuff that I kind of get myself into nowadays, it's not for humans at all.

Antony: It's for controlling machines.

Antony: And it's like trying to find what is a machine's UX, right?

Antony: Or

Speaker 2: not UX because

Antony: a U doesn't work, but

Speaker 2: MX.

Speaker 2: I

Antony: don't know.

Antony: It's a very different world.

Antony: And you wouldn't even dream of Svelte or anything like that because it's not necessary.

Antony: But it's really, yeah, it's become like

Kevin: one of the esoteric

Antony: thoughts in my head.

Kevin: So it sounds a bit like the question then is like, how do you design an API for a machine?

Kevin: Exactly.

Antony: Yeah. How does the protocol differ? Because an API is still kind of for humans because devs can interact with it.

Antony: But with machines, you might use something like just like, what's it called? Modbus, which I've been trying to figure out recently.

Antony: Modbus just being like packets of bits and you basically send certain bits and you can.

Antony: It's like industrial control systems, so you can set registers, like values of things, so that the circuit board knows what its limits are, what to go to, what to be set to, what speed to be and stuff.

Antony: And they all use Modbus, like Solar System used Modbus.

Antony: My Spark cover that I've been trying to fix recently uses Modbus.

Antony: They all have these little programmer interface, but it's nothing to do with humans.

Antony: You have a device that the human uses that then talks this language to them.

Ken: But you did just say a device the human uses, right?

Ken: So even when you're

Speaker 2: working on that

Ken: stuff, that's like a level

Speaker 2: removed and

Ken: you're designing something for another machine to interact with, even if you're doing context and prompt engineering, let's say, for example, it's a machine on the other end of that.

Speaker 2: But it's your end goal.

Ken: Yeah, your end goal still needs to be the human that's going to ultimately use that, whether that's the end user or like if you're designing APIs and you know other developer humans need to be able to comprehend them.

Ken: Right.

Ken: So it's easy to forget that, especially if you're not like focused on front end.

Ken: you get a layer or two removed.

Ken: But

Antony: I think it's super

Ken: important to always keep in mind.

Antony: It is, but I mean, like this is the thing.

Antony: So in that example you gave there, the human layer is the front end and the API and the context and stuff.

Antony: And the machine layer is the MTP, I guess, right?

Antony: So translating it from what you're doing, your job really is to work on the UI that talks to the thing that then talks to the MTP and the MTP talks to the service.

Antony: So it's still that same sort of thing.

Antony: But yeah, it's true because ultimately there's always an end user.

Speaker 2: I'm the one pushing

Antony: buttons on a control system, even though there's a language inside and a protocol happening there inside.

Ken: And when we write code, we tend to initially think that we're writing it for the compiler or the

Speaker 2: interpreter,

Ken: but we're really writing it for our future self a month later

Speaker 2: that's going

Ken: to have to read it or for the other devs on our team.

Ken: So it's easy to write code that a compiler or interpreter understands

Speaker 2: relatively.

Speaker 2: In a

Antony: 4GL.

Ken: Right.

Antony: We have these 4GLs, and when my dad programmed, he used to use like a 1GL.

Antony: I don't know. He used to push stuff onto a stack.

Kevin: Yeah.

Kevin: Not

Antony: what we do at all.

Antony: Well,

Kevin: yeah.

Kevin: You mentioned Svelte.

Kevin: Curious how that happened.

Kevin: Did he?

Kevin: Right,

Speaker 2: on the Svelte

Kevin: radio.

Speaker 2: But

Kevin: I was just going to ask, you said you found Svelte and you liked it, and that must have been Svelte 3?

Kevin: Or did you get in even earlier than that?

Ken: It was Svelte 3, yeah.

Ken: So, I don't know, should I give you my Svelte origin story?

Kevin: I mean, sure.

Ken: I'll try to keep it short.

Ken: So, it was probably four and a half plus years ago.

Ken: I was working on a couple of startup ideas.

Ken: I had started my own consulting company to both just do software consulting, but also to sort of explore some bootstraps, startup ideas.

Ken: And I was using what seemed like a common sense thing to use at the time, like Next and React.

Ken: And one of the ideas I was working on was pretty graphically intensive, not in terms of super high performance needs, but just in terms of a lot of user interaction, a lot to the user experience.

Ken: And I just felt like I was constantly doing battle with React and just the leaky abstractions of the virtual DOM and the synthetic event system.

Ken: And, you know, it was just frustrating and painful.

Ken: And I did run into some performance issues.

Ken: And so I was at least very primed to look for something else.

Ken: And React just never felt great to me from an API perspective either.

Ken: I appreciated, like, the philosophy behind the reactivity and declarative approach to development.

Ken: But the API just felt wrong.

Ken: And I stumbled at some point in my feed on this video called Rethinking Reactivity.

Speaker 2: Ah, the classic.

Ken: Exactly.

Ken: So honestly, by the end of that video, I was mostly hooked.

Ken: And then by the end of like 15 minutes into this tutorial, which was also just designed so well, like from an end user experience of just so like if your first experience with a framework is the way that it presents itself to you and the sort of getting started aspect of it.

Ken: is such a positive experience, that's going to also sort of hook you. So those things hooked me in. I decided I was going to spend like a day or two to see how far I could get to migrating the app I was working on over from Next and React to SvelteKit Svelte. This was early SvelteKit. It was post-Sapper, but zero dot something SvelteKit. And it really took me barely any time because it's pretty easy to migrate routes and pages and components from one to the other.

Ken: And it was so much easier, better performance, so much less doing battle with, you know, leaky abstractions that I was hooked and have never looked back.

Kevin: Nice. Nice. I feel like this is how almost everyone gets into self.

Brittney: I was

Kevin: going to

Speaker 2: say that

Kevin: earlier. I'm like, this is

Brittney: like the same origin story we hear from almost everyone.

Brittney: And that

Speaker 2: rethinking

Brittney: reactivity should just be like our slogan or something.

Brittney: Like it should just be up on the website for all time.

Brittney: Cause it, I

Speaker 2: feel like it still

Brittney: applies, even though that was talking about Svelte 3 at the time, right?

Brittney: Like we're always rethinking reactivity and how we can do it better.

Brittney: And now with runes and.

Speaker 2: Yeah.

Speaker 2: Speaking of

Kevin: runes, what do you think about Svelte 5?

Kevin: That was a big change for most of us that use Svelte 3, right?

Ken: Yeah.

Ken: For me, it makes a lot of sense.

Ken: I think, first of all, I place a high amount of faith in Rich and the core team, right?

Ken: Like when somebody's proven that they get it in terms of the API design over and over again, and that they value the same things that you value in a framework, you start to put a lot of trust in them.

Ken: And I am the front end lead on a pretty substantial sized code base that's SvelteKit and Svelte.

Ken: And so I've run into a lot of the pain points that they talked about when they talked about the rationale behind runes and Svelte 5.

Ken: I know some people, if you've only worked with maybe, you know, smaller, less complex code bases, you may not have experienced some of those pain points, but I had.

Ken: And so it didn't take me long to say like, okay, I can see why this makes sense.

Ken: I can see why it adds a teeny bit of friction in some scenarios, but that friction is well worth it for the benefits that you get.

Ken: And so pretty shortly after Svelte 5 was production, you know, started migrating our app.

Ken: And it's also nice how you can do that incrementally.

Kevin: That makes sense. Makes sense. So what kind of, what kind of application are you working on? Where do you get to, to use all this front end magic?

Ken: Goodness. Yeah. Yeah. So for my day job, I work with pretty small early stage decentralized finance, DeFi crypto startup called Trading Strategy.

Ken: So we're at tradingstrategy.ai if anybody wants to check it out.

Ken: So I spend most of my time in the front end and the SvelteKit layers, a little bit of time on some of our Python backends.

Ken: But yeah, really just sort of building out all of the features and experiences for end users.

Ken: And we're basically building like a two-sided marketplace where sort of quant or algorithmic strategy developers in the crypto and DeFi space can build algorithmic trading strategies that sort of just are always on and running and looking for opportunities for trading different tokens and coins in the world of DeFi.

Ken: And then investors can essentially invest in those almost like a hedge fund, deposit into it and let that trading happen in the background for them and take advantage of the smarts of some of these quant developers.

Antony: Is this like a robotic fund manager?

Ken: A robotic fund manager?

Ken: I mean, in a way, I mean, it's the idea of algorithmic trading has been around for a long time in traditional finance, especially in some cases like high speed algorithmic trading.

Ken: You can't really do high speed trading that well in in blockchain DeFi at this point.

Ken: So our strategies tend to run on like a, you know, every hour, every four hour type trading cycle.

Ken: But yeah, they're looking at basically technical indicators of, and every strategy is going to have its own sort of logic or sort of alpha for how it's trying to win in the market, right?

Ken: But it's going to have a bunch of essentially rules and algorithms that it's using to decide when it's good to trade what and look for some way to get an upside.

Ken: And then that allows, like any investor can put some crypto, some like USDC or something like that into a vault.

Ken: And it would be just like putting money into a fund in a traditional finance world.

Ken: And then usually that strategy developer would take some type of performance fee as what they've done.

Antony: Like a hedge fund.

Ken: Yeah.

Antony: Who makes the algorithms?

Antony: Who decides, like, not makes them, but who decides what the trading strategy will be?

Ken: yeah any anybody in theory right now it's people that work for our company or people that we're partnering with as sort of early adopters on that side of the marketplace to to help them you know there's a lot of people that have done this type of like quant algorithmic trading work in the traditional finance world or even in the centralized exchange centralized finance world of crypto we're trying to bring it to decentralized finance and so obviously one of our targets for that side are that have this experience maybe in other domains like traditional finance and to help them bring those talents and skills over to decentralized finance

Kevin: oh and what about like in terms of issues when you've been building this like do you can you remember any particular like thing that was particularly hard to build or that that was like oof this is a tough front end problem to solve

Ken: Yeah, I think probably some of the bigger challenges I've run into is finding the best libraries or frameworks to use for financial charts. Think about time series charts, and especially if you've ever seen candlestick charts, they look like little candles, red and green to show if it's for that time period up or down.

Ken: And you want those to be like very dynamic and interactive, right?

Ken: You want to be able to sort of zoom in and out and pan left and right.

Ken: And you want it to essentially be like infinitely scrollable.

Ken: So if you're like going back in time, but you don't want to fetch all the data when you first load it up, but you want that data to kind of come in quickly as you sort of scroll back or forward.

Ken: If you change timeframes, then you're like fetching new data.

Ken: How are you caching that?

Ken: So if you switch back to a different timeframe, you don't necessarily always have to refresh.

Ken: there haven't been great solutions that are sort of Svelte native for that. I've experimented with a lot of options, including just using like D3 for the sort of mathy logic side of it, and then using just Svelte and SVG for the actual drawing of chart elements. I don't think it's a great fit to use like D3's sort of rendering APIs, but just use Svelte for that side. I've experimented with that and I've experimented with a bunch of different charting libraries.

Ken: Some of the ones that are, you know, sort of Svelte native are coming along to the point where they could work for that, say like layer chart, especially because it has canvas, which could be needed in this scenario.

Ken: You have

Kevin: too many SVG

Ken: elements.

Ken: You start to run into some performance issues.

Kevin: I was going to say, no, I was just going to say like the amount of information and the amount of DOM elements you would have to put into to make it look as it should is like ginormous potentially.

Kevin: I think I've seen, I think there is a library that is pretty much just like a canvas thing and it just even renders text and like, but this, I think this library was more for like trading, actually trading stuff, like buying and selling and stuff.

Ken: Right.

Ken: I

Kevin: can't remember the name of it.

Ken: Where we landed after some experimentation was using TradingView, LightweightCharts, open source library. And TradingView is probably the most popular like charting framework that's used in the world of trading in general. And they publish like a bigger sort of more comprehensive version of their library that I think is proprietary license, but they have this open source lightweight charts. And that was enough for our current use cases. So it's just sort of a vanilla JS library that's imperative. And so I had to wrap that with like a declarative Svelte API, you know, using like effects. And so there's some challenges there, right? Like you can sometimes get into reactivity bugs when we were migrating from like certain of those components from Svelte 4 to Svelte 5, even though it's supposed to be like Svelte 5 should be backward compatible. I actually had some like reactivity bugs there with like when actions would re-execute based on the update call, stuff like that. So I had to, you know, get down into the weeds a little bit, maybe spend a day or two sort of debugging and figuring out the right solution.

Ken: But in the end, you know, if you were to go to our site, pop a little search term up in the upper right corner, like, I don't know, ETH for Ethereum, you know, pick a trading pair and look at it.

Ken: You'll see those charts rendering and you can sort of scroll back and forth or switch timeframes.

Ken: And they're very performant and it's worked out really well.

Ken: And it's pretty easy to plug vanilla JavaScript libraries into Svelte, which is one of the things I love about it.

Brittney: For sure.

Brittney: I love that too.

Brittney: Like I'm migrating an old plugin app.

Brittney: I think that was probably Svelte 3 originally, but they were able to get it to Svelte 4 just because it was minor changes.

Brittney: And then now it's got like these old map plugins and like all these kinds of old JavaScript APIs that I can just easily pull over and not have to worry about while I'm migrating.

Brittney: So nice.

Kevin: Before we started recording, You mentioned a library called Svelte FSM, and you did like a lightning talk at Svelte Summit way back.

Kevin: Well,

Ken: way back.

Kevin: A couple of years ago,

I guess.

Kevin: Several.

Ken: Early on in my Svelte career.

Kevin: Yeah.

Kevin: So what is that?

Kevin: And are you using it for this trading kind of thing as well?

Ken: Yeah.

Ken: Yeah.

Ken: I use it pretty actively in our trading strategy application.

Ken: I developed that, you know, as sort of part of that same origin story that I shared earlier when I, after I'd migrated that application over to Svelte, I was working on some things that just required a lot of complex, like state transition management and rules about, you know, when you could move something from one state to another.

Ken: And it just felt like something where a finite state machine was like the right abstraction to use and the right, you know, sort of model to use to control that.

Ken: And I think this is true potentially for a lot of different complex UI elements.

Ken: And so I wanted to pull a state machine in as a way to control that.

Ken: And I looked at what was available in the JavaScript world.

Ken: And this didn't have to be in any way like Svelte native.

Ken: It's really just a little sort of bundle of logic.

Ken: But if you look at obviously the popular one in the JavaScript world is X state.

Ken: And just like trying to pull in, again, this is maybe three, four years ago, maybe they've done some optimization work.

Ken: But just trying to pull in the most minimal version of X state at the time was like 30 kilobytes.

Ken: And the API itself is also pretty heavy, pretty complex.

Ken: You need like four levels of nesting just to sort of have the minimal state machine.

Speaker 2: And it

Ken: just didn't feel right, especially for like, I just needed something that could control a given spelt component.

Ken: I didn't need a big, deep, hierarchical state machine to control all of the state of my application or something.

Ken: I'm not really a big fan of that pattern.

Kevin: xstate feels kind of more like a thing for like i i always thought about it as you would use xstate to handle like the application

Ken: because right like redux or going from different views

Kevin: to and stuff like that and then kind of

Ken: tie it all together and

Kevin: it's just i went to like a workshop for X-State with Matt Pocock a while back.

Kevin: And it's really cool, but it's just very complicated.

Ken: Yeah, it's very much the kitchen sink approach to everything you could imagine that finite state charts, even sort of a more complex variant of finite state machines can do.

Ken: So I wanted something simple.

Ken: I wanted something that was sort of the bare bones, basic aspects of a finite state machine, you know, actions, transitions, you know, specified states and guards and things like that.

Ken: And so I just tried to think of like, I looked to see if there was something else.

Ken: I didn't find anything else I liked.

Ken: And so I just started to work on something.

Ken: And the more mature it got, the more I felt like this is something I could, you know, publish open source.

Ken: And then the opportunity to publish the request for proposals for that particular Svelte Summit, which was just virtual only, were coming out.

Ken: And I was like, okay, I'll throw this out in the mix.

Ken: But yeah, I came up with something that was like one kilobyte minified and that had just like the simplest possible API.

Ken: So for example, like calling an action.

Ken: So once you instantiated a state machine, which was just a function FSM that you imported, calling an action on it was just calling dot whatever your action was.

Ken: So if you have a light switch, which is sort of the simplest, hello world finite state machine or a switch that can toggle as your action.

Ken: If your name of your state machine is called switch, you would just call switch.toggle, right?

Ken: And so it's using proxies to take whatever it's receiving as a method call name and then looking to see whatever state your state machine is in.

Ken: Is there a matching action, which could just be a transition?

Ken: So it could just be a static property that has a new state it's transitioning to, or it could be a function that optionally returns a transition value for a new state.

Ken: And so I just tried to come up with the simplest possible API, something that would feel very natural in Svelte.

Ken: And it implemented the store contract.

Ken: So it would act as a store.

Ken: You could use the dollar sign syntax on it.

Ken: So I'm still using that today, even in our Svelte 5 app, even though it might feel more natural to start to use more like a runes style, like reactive class

Kevin: -based machine.

Kevin: Are we going to release a new version?

Ken: Yeah, I thought about it.

Ken: I didn't have a ton of time.

Ken: And someone else went and did that for me.

Ken: So if you look at the runes collection of open source tools, which are great, I think it was Edan Gazet, who's part of GitHub Next, sort of took Svelte FSM and reworked it for Svelte 5.

Ken: So there's a finite state machine sort of component that's part of Runes.

Ken: I actually used that in my Svelte MDR talk and the application I built for that.

Ken: So it works great.

Ken: It's as similar as possible as probably if you could make the API.

Ken: In some ways, I like the Svelte 4 API for that particular, for stores a little bit better in that scenario.

Ken: But yeah, that's probably what I would use today if I was starting something new.

Antony: I will say if you were to have used X-State, you wouldn't be the first person to use X-State with Svelte in some quite intense

Speaker 2: applications.

Antony: My friend who probably listens to this podcast, hello Mike, but he wrote his application purely in Svelte

Speaker 2: and X-State.

Antony: He didn't use anything relating to Svelte stores or page transmissions, anything.

Antony: It's all he just used X-State

Speaker 2: for every single action

Antony: within the system.

Antony: I mean, he had great success, but he likes to build quite

Speaker 2: complex things.

Antony: So he's got a brain the size of a small planet.

Antony: So I think that, you know, he's the kind of person who keeps it on his head.

Antony: I was just like, yeah, that would probably blow my mind and I would probably melt or something.

Antony: I don't know what happened.

Antony: But yeah, egg state can work, but I like the fact you build your own.

Antony: I think that's really They can play

Ken: really nice together. There's no reason you can't do it. I think as Kev was saying earlier, like that would maybe make more sense if you were using it to manage like overall application state.

Ken: whereas I'm using state machines just to in a very like fine-grained way to manage the state of a single component right and that's where it felt heavy and a little like too much both in terms of build size but also even the API but and to me like a website itself is a state machine right like each page is a single state that you can be in only one at a time and you have transitions between pages and stealth kit is essentially my my finance state machine management sort of system for that overall website state machine, right?

Ken: Your routes and your links and your go-tos, that really manages your states and transitions of the overall application.

Ken: So I don't feel like I need a big, heavy sort of state management system for that.

Ken: I have it in a way that makes a lot of sense to me, which is SvelteKit, and then I just use SvelteFSM or something like it for, like, fine-grained state management.

Kevin: Nice.

Kevin: Makes sense.

Kevin: So I was going to say last time I saw you, I was in a storage room and inflating helium balloons, but that was not the last time I saw you.

Kevin: But it would have been funny if it was the last time I saw you.

Kevin: That would be great, yeah.

Kevin: So let's talk about inflating balloons, or maybe not balloons, but let's talk about your Svelte Summit talk.

Kevin: What was the title of it?

Kevin: Yeah, it was Macro Data Refinement

Ken: with Svelte.

Ken: Yeah, some people may immediately understand what that means.

Ken: And for the rest of the world, it's like, oh, you're using Svelte for some kind of data-oriented solutions?

Ken: But Macro Data Refinement, MDR, is a function and a job within the show severance for some of the severed, any employees who work at Lumen.

Ken: And there's a really distinctive, unique sort of user experience that plays a prominent role within that show.

Ken: The MDR interface, microdata refinement interface, where you have these refiners sitting in front of a little like old school looking like set from the 70s kind of terminal and, you know, sort of identifying groups of numbers and categorizing them into these different buckets.

Ken: And yeah, I gave my Svelte MDR talk in character as a software employee who works for the fictitious company Lumen and why we chose Svelte as our framework for building the Svelte MDR interface.

Kevin: Absolutely amazing talk.

Kevin: And you really went all in on like all the props on everything, which is kind of hilarious.

Kevin: You printed Rich Harris' face on balloons?

Speaker 2: Yeah, that was next

Kevin: level.

Kevin: If people have seen Rich Harris' profile picture on Blue Sky, that's the balloon, right?

Kevin: If I remember correctly.

Kevin: I also 3D

Ken: printed, of

Kevin: course, on the podcast.

Ken: On the podcast, you can't see this, but I 3D printed the board speaker.

Ken: If you have watched Severance, you know what the board is.

Ken: But yeah, the balloons were probably the hardest prop to acquire.

Ken: The speaker was some effort as well.

Ken: I have name tags lying around here somewhere, like the Lumen style, you know, sort of badges and security badges.

Ken: So I did go all in.

Ken: Go ahead, Dan.

Antony: Josh, did you actually design the model for the 3D print?

Antony: I

Ken: found it online, downloaded it.

Antony: I literally printed it

Ken: for free at my local library.

Antony: Nice.

Antony: I was going to say, I think I came home from your talk and I was trying to look for the model on Fangs or whatever site I was using.

Antony: Because I

Ken: wanted to have that.

Ken: I can try to find it and send it to you if you want it.

Antony: You should send it.

Antony: Yeah, send it to me.

Ken: But yeah, once I had the idea for the talk, it was getting to the point where it was like, I don't know, a day or two before the close for the request for proposals for talks.

Ken: And I knew I wanted to propose one because, hey, free ticket to

Speaker 2: Barcelona and getting to hang out with

Ken: everybody.

Ken: And I was actually at Svelte Summit in Stockholm as well.

Ken: And just the chance to get the band back together, be back together with everyone.

Ken: I was super excited about it.

Ken: And there's a good chance that my employer would have paid for me to go.

Ken: They did back when I went to Stockholm.

Ken: But if I can go, it's a different experience, right, to have a chance to get a talk.

Ken: Yeah, just brainstorming different ideas.

Ken: And it was right around the time that season two of Severance, like the first couple of episodes had dropped.

Ken: And I was already like super into it again.

Ken: you know season

Speaker 2: one yeah

Ken: so i don't know at some point the idea popped into my head and i'd seen somebody else had created a react version of the mdr interface i was like i could do this but so much better and felt um and from a performance and just you know like even implementation details perspective so i got inspired and submitted the talk thought maybe there's a 10 chance it gets accepted but then it did and so then my my brain started kind of going in terms of all the different ways you could lean into being fully in character with it so

Kevin: i mean it was great like

Brittney: it was a really fun talk and

Kevin: for for those that haven't seen it like even just like the you have you have like the the pixel art that they kind of used in one of the episodes like you had that with rich hairs in it instead of of the other

Brittney: characters right

Kevin: it's super fun and

Brittney: there's a lot of like easter eggs and like just fun little things especially if you had seen the show but even if you hadn't it was still entertaining and you even convinced me to become an innie at the end that's

Ken: right well you helped with my britney you helped with my intro right and and uh

Brittney: yeah i had

Ken: some like intro music that came from one of the episodes of the show there a who song and then kev you mentioned this earlier but uh man thank you so much for your help. Like I needed somebody to help me inflate balloons with Rich Harris's face on them and, you know,

Speaker 2: tie little ribbons on them

Ken: and essentially make it a bouquet. And yeah, the only, I think the only people that were in on this, like the balloons part and sort of some of the, like the details of, of how all in I had gone were basically Brittany and Kev, the two of you guys. So thank you for, you know, both helping out, but also keeping it under wraps. And it was a lot of fun

Brittney: yeah we had to convince rich to come out there even though he was trying to finish writing his talk as per usual his

Ken: talk was his talk was right after mine

Brittney: and so yeah for

Ken: him to have attended you know that doesn't always happen right um that the pictures that you referenced britney i spent a lot of time wrangling with mid-journey um and like using a lot of like fine-grained like prompting details with mid journey, like giving it, um, style references and character references, um, and trying to come up with those images. And I think at least one of those I finished at like midnight the night before my talk was like, it'd be really fun if I had this picture of Rich Harris eating a pizza roll, but like actually like Kira Egan eating a pizza roll. Right. So, um, yeah, it was fun.

Ken: Yeah.

Kevin: So in terms of the actual application that you had to write, like the macro data refinement,

Speaker 2: was

Kevin: it tough to write?

Kevin: How did you? So let's try to explain what it looks like to the listener. It's like a bunch of numbers and you're supposed to like.

Ken: The

Kevin: numbers can be kind

Ken: of scary, right?

Kevin: So the numbers are

Ken: moving. The numbers are like moving around. They're in this, they're in this just like Cartesian coordinate grid on the screen, right?

Ken: And, but they're moving around in different, like each number has got its own little bit of different motion to it. And you're supposed to, the refiners are supposed to be looking for like a group of numbers that feels a little scary, right? And then they sort of put a little boundary or fence around those numbers and then they click on a bin and there's like five bins on the bottom And the numbers sort of animate into one of those bins.

Ken: And eventually they finish refining a particular file.

Ken: They don't have any idea what it's for, what it means.

Ken: They speculate a little bit, right?

Ken: So it was actually pretty complex to build.

Ken: I mean, I did have some reference implementations to look at, but I did roll like every bit of code for it from scratch because I knew I would be using some like different approaches than what I saw in like the React version or some of the other versions that I'd seen out there.

Ken: But I just kind of tried to build it organically and let the design emerge as I did it.

Ken: But some of the specific animations were a little bit tricky to find the right solution for.

Ken: And some of the state management holistically.

Ken: You don't want to...

Ken: There's different interactions you can do, like using your cursor to select a group of numbers, and then you hit a button, And those numbers start to like move into a bin.

Ken: You don't want to then simultaneously be able to select a new group of numbers while the interaction from the first one is completing.

Ken: Right. So you want to really like prevent, you know, weird race conditions and stuff like that.

Ken: So that's where using a state machine library actually helped a lot is that like the overall interactions you can do depend on what current state your application is in.

Ken: And so that controls sort of the conditions around you can interact in different ways.

Kevin: Yeah, I mean, I was blown away by the whole talk.

Kevin: If you haven't seen it on YouTube, you should definitely go and watch it.

Kevin: Like, I don't think anyone didn't enjoy it.

Kevin: At least felt like everybody loved

Ken: it.

Ken: It seemed like people that knew severance maybe probably enjoyed it the most, but there were

Speaker 2: plenty of people

Ken: that didn't know severance who later told me, I've now watched severance because of your talk.

Ken: So that felt gratifying as well.

Ken: I feel like Apple owes me some kickbacks

Speaker 2: as like a marketer for Apple.

Ken: I will say I read a blog post at one point that said like, hey, a really good like conference talk, tech conference talk, needs to like inform, educate, and entertain.

Ken: And so I was thinking about that.

Ken: And as somebody who's spent a lot of time in my career in user experience, I was thinking about every member of the audience is an end user of this talk.

Ken: And so how am I designing an experience for them that's going to sort of satisfy what they're going to want out of a talk?

Ken: And so I just try to put myself into the posture of the position of the end user.

Ken: That was my guiding principle as I worked on it.

Antony: so just the application that you wrote is it online for our viewers

Ken: it is

Antony: let's add a link to that

Ken: yeah you can put that in the notes I can say it out loud now if you want to it's just mdr.kentropic.com kentropic is like my blue sky handle and my handle in some other places the code is up on github just under kencoons is my github username So I have it as one of my pinned repos there.

Ken: So it should be pretty easy to find and you can throw that in the notes.

Kevin: Will do.

Kevin: Great.

Kevin: Excellent.

Kevin: Anything else about the talk that you think we should talk about from like a Svelte perspective?

Kevin: That maybe something that we, as the viewers of the talk or the audience didn't notice, but that you like spent a lot of time on that was hard to do or?

Kevin: The minutiae.

Kevin: Yeah.

Kevin: Minutiae.

Kevin: How do you say that word?

Kevin: Like you did, I

Ken: guess.

Ken: Yeah, I mean.

Kevin: And I'm not sure.

Ken: You know, Brittany mentioned some of the pictures and some of the sort of style of artwork and sort of working with Majorney to try to come up with that stuff was definitely like took more time than you might guess.

Ken: You know, getting the code.

Ken: I wanted the code to be something that would be instructive and even like not just instructive at a code level, but sort of the why of animation and the importance of animation and transitions within any front-end app.

Ken: So, you know, when I was thinking about the educate aspect, I actually probably spent just as much time talking about like the user experience of thinking about the fourth dimension, the time dimension in your applications where we often think of like mostly two dimensions, sometimes a little bit of a third dimension, but we often forget about that time dimension of transitions and animation.

Ken: So I wanted to think a lot about that as part of the educate aspect.

Ken: And then I would say something that took a lot of sort of call it mental and emotional energy is just getting fully into character.

Ken: Right. Like, I think I did a pretty good job.

Ken: You guys can be the judge of like truly staying fully in character for the whole talk.

Ken: And so

Brittney: you're shaking our heads just for clarity.

Brittney: Kevin and

Speaker 2: Anthony are

Brittney: all shaking our heads yes,

Ken: but he

Brittney: did do a very good job.

Ken: So that probably over the course of months as I worked on the talk and just like background processing, you know, I'm just sort of thinking about what would somebody who's an actual Lumen employee, like how would they talk?

Ken: What would they say?

Ken: How would they represent Lumen?

Ken: How would they represent their work?

Ken: And so, you know, they're sort of always in the background and always like jotting down notes of like you know different ideas of how to how to be fully in character i think in some ways my platonic ideal of somebody who like goes all in on a talk is is bert who's

Speaker 2: given you

Ken: know talks at several and so admiring sort of bert's ability to sort of just go all in i sort of took that as inspiration for going all in on my talk so

Kevin: yeah yeah bert bert's talks are are crazy in a different way very good like yeah they

Antony: almost feel they almost feel scrappy but they're not scrappy they're just kind of they're very well

Kevin: planned just the

Antony: whole the whole aesthetic of his talks right which is quite insane no you

Kevin: i think you did play the character really nicely like it it was very very well done for sure

Speaker 2: all right um

Kevin: any any other questions for for ken before we get on to the the spicy section of the podcast as i sometimes call it i see them yeah all

Ken: right one thing i'll got to mention earlier when we were chatting before but yeah recently so somebody that i met in barcelona um was a guy named mike rourke who was also giving a talk called svelte in orbit awesome talk you should check that out as well and uh so we're chatting on the first day of the conference i saw him sitting across the table at like the speaker's dinner but didn't get a chance to meet him we're chatting and he's like where are you from i'm like oh yeah chicago area oh where you know and i describe where i'm from and he lives like a couple kilometers away from me wow Right. So, you know, we never, we meet, we meet in Barcelona. Right.

Ken: And so I

Speaker 2: mentioned

Ken: at the top, at the conference, I've been thinking about starting up a local chapter of Salt Society.

Ken: He's like, we should do it.

Ken: Took us a couple of months after we were, you know, back in the area here, but we have gotten that going. So anybody who's anywhere close to Chicago, Brittany, you're not that far away. You should come

Brittney: visit us sometime.

Brittney: I was going to say I should drive like the three

Ken: hours

Kevin: there for one

Brittney: of them.

Brittney: Like it's not going to be a monthly thing for me.

Brittney: Oh, it's not.

Kevin: Brittany, you're not too far away.

Kevin: Three hours?

Kevin: Three

Brittney: hours.

Brittney: Three hours.

Brittney: It's all relative.

Brittney: Can't you get a train?

Brittney: It's

Ken: all relative.

Kevin: Just

Brittney: get a train.

Speaker 2: Still three hours.

Speaker 2: Three hours.

Ken: The train takes

Brittney: like seven hours to

get there.

Brittney: Our

Kevin: trains are horrible.

Ken: Our trains are pretty slow.

Ken: I know.

Ken: Well,

Kevin: yeah, you mentioned Svelte Chicago here, and I think you've already had the first one, right?

Ken: We've had two, and our next one's coming up in like 10 days or so, yeah.

Kevin: Yeah.

Kevin: Exciting.

Kevin: Are you getting a lot of good people showing

Ken: up?

Ken: We're having about like 12 to 15 so far,

Kevin: which for a brand

Speaker 2: new stalled

Ken: meetup, you know, sort of a little more niche audience is pretty good.

Ken: And it's a great group, and we've had a lot of fun.

Ken: And we're trying to keep it a little bit organic, a little bit like not totally overstructured, you know.

Kevin: Oh, that's good.

Kevin: I'm messaging

Brittney: the details, and I will try to make one.

Kevin: When is the next one?

Kevin: Tuesday, October 28th is what it says here.

Kevin: Yeah, okay.

Kevin: So then probably people will have heard about it on the podcast and they

Ken: just go

Kevin: show up.

Kevin: Hopefully.

Kevin: All right, cool.

Kevin: Unpopular opinions?

Kevin: Who has one?

Kevin: I have one.

Kevin: You always have one, Anthony.

Kevin: Tell us.

Antony: Okay, so my unpopular opinion this time is, it's a techie one, but testing, right?

Antony: So optimize tests for isolation first, and then speed second, because people make the mistake.

Antony: I mean, tests should run quickly, right?

Antony: That's what I said, become a burden.

Antony: But we had a test that were like four minutes, and we were trying to figure out how to speed them up, because four minutes is a long time when you're trying to just check in and stuff.

Antony: And one of the suggestions, or some of the suggestions that came up, were around, like, why am I using before each for every single test?

Antony: Every single, I only allow one expectation per test, So you can't expect multiple things.

Antony: And every test has a before, like every group of tests has a before each that runs every single test.

Antony: And it inserts it from the database, clears out the database, does all sorts of stuff, create indexes if you need to, et cetera.

Antony: And one of the suggestions was that we used before because then we set the data once and we run all the iterations, run all the tests, sorry.

Antony: That to me introduces risk because it's not impossible to mutate data.

Antony: I mean, maybe it's not controversial, but it is depending on how you approach testing is if every single expectation is running complete isolation with no ability for any other party outside thing as a factor to influence the data you put in and the data you were expecting then you will have confidence that your tests actually work otherwise you get pollution left right and center and your tests don't run and i think and there was no penalty by the way this wasn't but there is absolutely, in my mind, it's a better approach to have slightly slower tests and take that penalty to get that isolation.

Kevin: Yeah, I

Antony: think I agree.

Kevin: This makes me think of this idea I read somewhere about using SQLite for testing.

Kevin: Like if you're, so let's say you're using, I don't know what you're using, Superbase or Postgres, whatever, right?

Kevin: Like, if you can somehow manage to write your...

Kevin: I guess if you're using an ORM, you could kind of do this.

Kevin: Like, if you could use SQLite locally when testing, that would kind of mitigate some stuff.

Kevin: Yeah, absolutely.

Kevin: But then, like, there's differences between Postgres and SQLite, so you'd have to...

Antony: There are, and that's always a risk, right?

Antony: But if you talk about unit tests there, and maybe, you know, when you run it on your CI, you can use the real thing, right?

Antony: So you can just iron out those very, very small edge cases.

Antony: We use Mongo as our main database, and there is an in-memory version of Mongo, which is very quick, but it is enterprise only.

Antony: I'm not going to pay a huge fee to

Speaker 2: use Mongo

Antony: to get that.

Speaker 2: And I

Antony: almost don't like Mongo for this reason.

Antony: Their local testing story is kind of always an afterthought compared to their main performance story.

Antony: Search indexes are an absolute nightmare to use locally.

Antony: so much checking that indexes are working, run up to sync and all that kind of stuff because ultimately it's been done brilliant, Atlas Search works really well, but it's an afterthought and you can't really test it locally with any sort of reliability.

Antony: And it's the same with this enterprise.

Antony: Why is Mongo Memory Enterprise?

Antony: That makes no sense.

Speaker 2: What enterprise would use it in memory?

Antony: Well, exactly, right?

Antony: So the thing for me is, you know, I do like mostly, I like Mongo.

Antony: Their local testing store needs some work.

Antony: But I would say that the good thing about it is it's so quick, actually, that, you know, we have nearly 9,000 tests, most of which write for database.

Antony: And I'll tell you what, they run, in now, we've gotten down to, on an M4, half a minute

Speaker 2: to

Antony: run 9,000 tests.

Speaker 2: Oh, wow.

Antony: And these are all clearing databases, inserting database data.

Antony: This is not a problem.

Antony: Like, it's not an issue, but I think it'd be even quicker with Mongo memory.

Antony: There's also, what's it called, NEDB, which is the local open source equivalent to Mongo, but it doesn't implement any of the new API stuff.

Antony: It's kind of an abandoned project.

Antony: So we used to use that, but our usage is too complicated now.

Ken: Yeah, when I worked in Rails years ago, we would run all the unit tests against SQLite.

Ken: And of course, with the active record form layer, that was pretty straightforward.

Ken: I think that was even like the default.

Ken: Yeah, yeah.

Kevin: Nice.

Kevin: This reminds me, I should probably write a bunch of tests for the new Spout Society website.

Speaker 2: Anyway.

Kevin: Good reminder.

Kevin: Yeah.

Kevin: All right.

Kevin: Does anyone else have an unpopular opinion that they want to share?

Ken: I've got one.

Ken: I'm going to take some inspiration from Anthony from a couple of weeks ago, Spelt Radio, where he, you know, went just a little, you know, into sort of politics and into the deep end.

Ken: So I'm going to say unpopular opinion, at least in the U.S. and some other Western countries these days, is that authoritarianism is bad, would

Speaker 2: be my unpopular opinion.

Ken: Now, I know, like, a lot of us might say, well, we agree with that, right?

Ken: Obviously, not all voters seem to agree with that here and in some places.

Ken: But I think sometimes we have to look not just at the authoritarianism we see in others, but actually look at ourselves or look at the communities that we're a part of.

Ken: Because even if you don't have a lot of power, I think authoritarianism is a little bit about how you wield the power you have.

Ken: Are you using it in a coercive or domineering way or using your power to try to, you know, bring about good for those who have less power?

Ken: So and I think we will ultimately really only defeat authoritarianism, not with its own, you know, like not by turning authoritarianism on itself or else, you know, that sort of that forms us into a certain kind of person.

Ken: If we wield power that way, even if we think we're doing it for the right reasons.

Ken: So that's my unpopular opinion.

Antony: It's interesting because, again, you've caused a thought in my head, and that is that the biggest complaint now from people in the UK is socialism is authoritarianism.

Antony: Socialism is somehow being controlled by people who are a government.

Antony: And actually, the people who are propelling that opinion are people who have the opposite opinions, but want almost dictatorship.

Antony: and therefore that becomes like people who want authoritarianism telling you that authoritarianism is bad i think that's how it works out i'm not completely sure yeah

Kevin: yeah i haven't figured out but it's it's interesting yeah i was gonna mention that even even just you you you said like you have to look at yourself in or like how do you wield power and that comes up a whole lot on the Svelte Discord.

Kevin: Like, how do you moderate

Speaker 2: something?

Kevin: Because that's, I mean, it's not really

Speaker 2: one person doing it, right?

Speaker 2: Yeah,

Kevin: right, right.

Kevin: It just made me think of that.

Kevin: And it's tough.

Kevin: Like, it's tough.

Kevin: I can't imagine how hard...

Kevin: But it has to be

Brittney: done for the greater

Kevin: good

Speaker 2: of

Brittney: the community.

Kevin: So it is a very

Brittney: similar parallel to, like,

Speaker 2: there

Brittney: are good things about big government.

Kevin: there are bad things about the government it depends on what you're dealing with yeah I'm just very happy I'm not a politician Kev is big government

Antony: Kev is wealth government but the thing is here right is that also you know on the wealth discord the biggest problem is not necessarily that we have rules and we have to enforce them because that's kind of a given like

Speaker 2: you have to

Antony: do that but I think the problem with it is is that everybody reacts differently to

Speaker 2: authorities and so

Antony: you have to have an approach that works well at least for the majority of people because you don't want to get into like a fracas you know you want to say to somebody this is these are the rules how it works we

Speaker 2: have rules

Antony: you're here on the basis of the rules and and you know obey or leave and to some people that will just get the right wrong way yeah they will they will get riled up and they'll make the thing worse before you can solve it and the solution is blocking them

Ken: And you're always going

Antony: to have that.

Ken: Rules create a set of boundary conditions, right?

Ken: They sort of create a baseline.

Ken: Yes.

Ken: But you're not going to get good behavior just by saying, well, I followed the rules, right?

Ken: There's a lot more that goes into actually like constructive, positive types of engagement.

Ken: But at least they give you like, right, here's a baseline set of boundary conditions.

Ken: But I think you're going to get better behavior often than through like example, right?

Ken: through demonstrating good behavior and then through not being overly, like, domineering in the way that you would moderate in that kind of a context, right?

Ken: Trying to de-escalate if there's a situation, right?

Ken: Not, like, just pulling out the rule book and saying you violated rule 37.D4, you're

Kevin: out of here, I ban you, you know, but

Ken: trying to, like, calm

Kevin: things down, you know?

Kevin: Yeah, I mean, at some point,

Ken: you end up there.

Kevin: People also respond better if you give them a reason.

Kevin: That's the issue, right?

Kevin: That's not easy.

Kevin: All right.

Kevin: Brittany, do you have an unpopular opinion?

Brittney: Not that I can think of right now.

Kevin: Yeah, me neither.

Kevin: Let's go to the fun section of the last part of the episode.

Antony: That was the fun part.

Kevin: All right.

Kevin: I have a pick.

Kevin: So I have recently switched browsers.

Kevin: Yeah, you heard it here first.

Kevin: I quit Safari.

Kevin: I've been using Safari for probably close to three or four years now, full time.

Kevin: Yeah.

Kevin: Not joking.

Kevin: I love it.

Kevin: Safari is great.

Kevin: But I've switched to one called Zen, which is like a Firefox-based browser.

Brittney: Oh, interesting.

Kevin: Yeah.

Kevin: And I've been having the greatest time surfing the

Brittney: web.

Brittney: What is that built on?

Brittney: Spider Monkey?

Brittney: Is that the

Kevin: Firefox one?

Kevin: I love that name yeah it's fun it has all these cool features like yesterday I realized I can do command space or sorry command T and that's usually in most browsers that's just open a new

Speaker 2: tab

Brittney: but

Kevin: in Xen it opens this small panel where you just type the URL so it's kind of like if you've used Spotlight on Mac like command space or whatever you

Brittney: activate

Kevin: So it's kind of like that.

Kevin: And then you can do Command K, and that's searching.

Kevin: So you just search.

Kevin: That's so fun.

Brittney: Oh, that is nice.

Antony: So nice.

Antony: So I thought we were done with controversial opinions that Safari is good and now

Speaker 2: you use Firefox.

Speaker 2: I've had that unpopular

Kevin: opinion on the podcast, I think.

Antony: I do like Firefox.

Antony: I do, I do.

Antony: I like Firefox.

Antony: I use it.

Antony: I've

Brittney: switched mostly to Chrome.

Brittney: I don't know.

Brittney: My last job, I had something where it was not working very well and Firefox and I finally switched now that they have better grid tools.

Brittney: But yeah, I still like Firefox.

Antony: I mean, yeah, it's dominating.

Antony: Chrome is always going to dominate because Google backing it right on Firefox and Mozilla.

Antony: They're not dominating, right?

Antony: There's one other feature

Kevin: that I want to mention as well that I also found.

Kevin: It's like split web views.

Kevin: So you can have one tab, but it has

Speaker 2: two websites.

Kevin: So I can have, for example, Blue Sky on the left side, and then I'll have Twitter or Rex or whatever on the other side.

Kevin: And then you can get both sides of the political

Speaker 2: spectrum,

Kevin: can't you?

Brittney: Pretty much.

Kevin: I promise it was not just an example.

Brittney: You could do that with rectangle and just separating your windows too.

Kevin: Yeah, but it's like...

Kevin: That's true.

Kevin: Sometimes when you're browsing the web, you want to view two websites at the same time.

Kevin: So why not make it so that when you click the tab, both websites show up?

Kevin: If you have it in two windows, you have to click both tabs if you want to get back to that

Ken: kind of state.

Ken: I was looking for that feature recently when I was trying to do a demo.

Ken: And I wanted just one window sort of shared live on the Zoom or whatever.

Ken: But I wanted to show sort of two views side by side.

Ken: That

Brittney: just gave me an idea.

Brittney: That actually sounds really nice for when you're migrating something or comparing something from a Figma design to your actual design and just splitting it in one window.

Brittney: All right.

Ken: All right.

Ken: I like your pick.

Ken: Gave me an idea, too.

Ken: Yeah, I'm going to try it out.

Ken: Why not?

Ken: Gave me an idea, too.

Ken: How about this?

Antony: Three windows in

Brittney: one time.

Brittney: I'm worried about that.

Brittney: I mean, it can't

Antony: do that as well.

Brittney: honestly mozilla has been following falling a little behind with things

Speaker 2: since like

Brittney: the layoffs what like two or three years ago

Speaker 2: but

Brittney: so i worry a little bit about something built on that at this point but

Kevin: i i have some great news for you though if you feel like you could use the the edge browser that also has this feature apparently oh

Brittney: and it's based on pro.com right can you use edge on mac I think so

Antony: yeah and Linux oh yeah I think it runs on Linux oh interesting

Brittney: okay yeah I don't know give

SoundRouse

Antony: a try first because they realize they realize that Windows is losing popularity I love tab

Brittney: groups and I'm addicted to tab groups

Antony: now

Brittney: in Chrome so I just have like everything grouped together and collapse them when I'm not using them and it's really nice I'm going to

Ken: try again I guess that

Brittney: can be my pick because I don't I didn't really think about a pick

Ken: I'm going to try Zen because I also use Zed as an editor that's not my pick so

Kevin: Zen, Zed,

Ken: I don't know it's going to go together

Kevin: I do as well and you can

Ken: validate with Zod

Kevin: I also use Zod I never realized my

Ken: company is actually called Zenthropic I mean

Kevin: you have to use the Zen

Ken: browser yeah try it

Kevin: quadrangle Is your pick set then?

Ken: I have a completely non-technical pick.

Ken: All right.

Ken: Go for it.

Ken: Which is rock climbing.

Ken: I started getting into it a couple years ago.

Ken: And I just want to recommend anybody should try it out.

Ken: Maybe it's not going to be for everyone, of course.

Ken: But, I mean, it's just a great activity.

Ken: Like, it's a full body workout.

Ken: It's social.

Ken: It's mental challenges.

Ken: So I actually find it to be sort of a kind of therapy, right?

Ken: Like, I don't know if you've ever heard of, I think it's Brene Brown, like growth mindset versus fixed

Brittney: mindset.

Brittney: I love Brene Brown.

Brittney: The

Ken: idea of like

Brittney: failure isn't

Ken: really failure.

Ken: It's, you know, just sort of a step on the path of learning and growth.

Ken: And, you know, that's something I think I've struggled with at times in my life.

Ken: And when you go to the gym and you're rock climbing, like you can't do it without being in a growth mindset because people are watching you fail constantly.

Ken: And you just have to start to like reframe failure is just sort of a step in the path of part of your experience and your growth.

Ken: And so I'm super into it.

Ken: I'm actually leaving this afternoon to go down to the Red River Gorge, Kentucky for a climbing weekend.

Ken: Got a bunch of new friends as a result of climbing.

Ken: It's awesome.

Ken: So check it out.

Ken: Be safe.

Ken: Thanks.

Ken: I'll try.

Antony: But you're talking about climbing as in with ropes and stuff, right?

Antony: Not bouldering.

Antony: I do both.

Antony: Yeah, I like bouldering.

Ken: I like

Antony: top

Ken: rope and lead climbing on ropes.

Ken: Sport climbing is sort of the version of doing that outside, but not what they call trad or traditional climbing where you need to put in your own cams and stuff.

Ken: That's a little more dangerous.

Ken: It may be a

Speaker 2: little bit of my pay

Ken: grade.

Ken: But yeah, it's very fun.

Ken: Cool.

Ken: Nice.

Ken: Yeah, I love bowling.

Ken: I love bowling.

Antony: All right.

Antony: Anthony?

Antony: Right.

Antony: My pick is technical again.

Antony: Ha ha.

Antony: my picnical pic, I don't know what I'm talking about anymore, is N8N.

Kevin: Ah, right.

Antony: So N8N is a tool.

Antony: It's a lot like Zapier, but way cheaper because it can be free because open source.

Antony: It's a lot like Make, which I learned about recently.

Antony: Make is kind of like Zapier and Make are no-code automation tools.

Antony: N8N is no and low-code automation tools.

Antony: So it has integrations for everything you could possibly imagine, even things like linear, which I didn't think in any other parking was used.

Antony: But basically, it allows you to drag and drop items, objects, integrations, drag and drop the fields from within them into transformers, whatever you want to do.

Antony: So you can basically take input from something, a webhook or a query it runs, whatever, transform into something else and pop it out to some other thing.

Antony: You can use it to control your home with Home Assistant.

Antony: you can use it to like we do send things to slack and discord and whatever else um you can use it to automate email systems automate reports whatever you want to do you can do anything that's all you want to do with it but the reason i like it is one because it's a lot cheaper than the other two um and two because it's no it's low code as well so you can have you can go right well this integration doesn't work doesn't have what i want i'm going to break out i'm going to go into um into low code mode and i can use javascript python whatever we do to integrate with something else that it doesn't know about or something it doesn't know about, just integrate more raw with it.

Antony: And it's just, since I've installed it, I've thought, you know what, there's so much I can do with this that will save a load of dev time, building integrations to scratch ourselves, trying to figure out where to host them, how to run them, how to optimize their hosting so that it costs a fortune.

Antony: This kind of runs and does it all for you.

Antony: So I'm pretty excited about NA10.

Antony: I've done a couple of things in it.

Antony: I have this thing where if you email any name at a certain address, which I won't mention what domain it is because it will get spammed probably um anything in that address will go into our slack into a like a channel called inbound email and it will basically allow you to test more easily because you can use this address um when you're testing your software without having to have multiple different email accounts or or whatever else so it's kind of it's great for that sort of thing that was daddy he took me a few minutes from knowing nothing about it um but I've got lots more plans in respect to that sending out reports to people how their profitability is doing how much money we made in Stripe the other day that that sort of thing is it's pretty cool and it's dead easy to use I really like it

Kevin: nice I was gonna say I've been looking at these uh kinds of solutions recently like uh N8M is self-hostable as well right I don't know if you've mentioned that yeah

Antony: yeah yes exactly so it can be free I've

Kevin: been looking at one called active pieces, which is also supposed to both active pieces.

Speaker 2: But

Kevin: it's more for building agents.

Kevin: AI agents.

Kevin: I don't look too much into NADM, but I assume it's maybe geared a bit more towards using LLMs.

Kevin: Maybe categorizing stuff

Speaker 2: so you get

Kevin: emails into an inbox and then, I don't know, it kind of puts categories or labels on something.

Kevin: I don't know.

Kevin: I'm just going to start using it, so we'll see.

Kevin: All right.

Kevin: I think we did it.

Kevin: We did a whole episode.

Kevin: Crazy.

Kevin: Even with you being in the bar.

Kevin: You would have thought you'd be

Speaker 2: blackout drunk at this point.

Kevin: But yeah, all right.

Kevin: Thank you, Ken, for coming on and joining

Ken: us and talking

Kevin: about everything.

Ken: Thanks for having me.

Ken: This was a lot of fun.

Kevin: Yeah.

Kevin: And we will...

Speaker 2: Thank you.

Speaker 2: Thank you to everyone who's listening.

Speaker 2: and we will talk to you next week.

Speaker 2: Yeah.

Speaker 2: Bye

Brittney: -bye.

Brittney: Cheers.

Brittney: Cheers.

Speaker 2: Bye.

Brittney: Bye-bye.