How to make a great framework better? - Svelte 5 with Rich Harris

the web is not in great health a lot of things that we use in the digital world on a day-to-day basis are just broken the web is a lot of time much worse in terms of user experience and reliability and all of these things and I want to do my bit to try and reverse that Trend you know a lot of people candidly just don't have time for the front end Industries oh which which Library am I supposed to use for State Management no it's a it should be built in what makes a web framework not just good bu

t great and how does spelt rank consistently highest in developer satisfaction surveys and what will future versions of spelt bring to the web I sat down with the creator of spelt Rich Harris in his Brooklyn apartment to discuss the magic of spelt the current state of the web and how we can move things forward with the right approach Rich thanks for having us thanks for coming by you Sav me a Subway trip by coming here perfect uh so what problem does spelt solve uh spel solves the like so the fu

ndamental problem is that web development is is too hard and spel is an attempt to make it a little bit easier uh to make it a little bit more tractable for a wider group of people to build Rich interactive web applications uh it falls into this category of things called a front-end framework similar to projects like react and View and angle and all of these other things takes a slightly different tack but that is essentially what it does it allows you to build your application out of declarativ

e components and then it turns it into something that the browser understands and allows you to build interactive uis without having to do all of the plumbing of manipulating the Dom yourself you've described it as a uh a web framework as a framework without the framework and as a language like why is that important and and what do you mean by that yeah the the definitions and the way that we talk about it have definitely evolved over the years the the framework without a framework um descriptio

n was when felt first came out the idea was like can we just do away with all of the Machinery that is included as part of the framework when it runs in the browser can we take your input and just sort of compile it down to to the underlying instructions to to the browser and sort of dissolve away all of the scaffolding and so that's what framework without the framework means in reality of course there is a little bit of infrastructure that needs to be there for any of this to work um but essent

ially what it's getting at is this idea that the code that you write and the code that actually runs in the browser they're not the same thing there is a transformation that takes place in at build time so that the application that you actually ship to users is more efficient it's smaller than it needs to be otherwise it's um it's better at at updating the Dom um in a very efficient way um and it it does all this without you needing to think deeply about how to optimize your application it does

it for you so spel in addition to being a framework is is a language it is a language for describing user interfaces when you build a spelt application you're doing it in a spelt file as opposed to in ajs or. TS file um and that is the fundamental difference what do you see as the difference between a JavaScript framework and a web framework yeah it's a subtle distinction I guess the the reason that we call it a web framework as opposed to a JavaScript framework um it's kind of twofold firstly s

pel is an HTML Centric language you know what we've found over the years is that HTML is actually a really good language for describing user interfaces there's something about the nature of those angle brackets that people just really get like you're describing the structure of something in a way that intuitively makes a lot of sense and what we've seen is the JavaScript Centric Frameworks like react to be a great example in order to make that style of development appealing they've had to create

things like jsx so that it feels like you're writing h spel doesn't do that it's it says HTML is actually a really good starting point we just need to make HTML an interactive language and so that is what spelt is it adds interactivity to HTML the other reason that we call it a web framework and not a JavaScript framework is that anytime you build a web app you're going to have to think about styling that is one of the fundamental problems that you are going to have to solve and a JavaScript Ce

ntric framework typically just doesn't have any opinion on this but spelt does if you write a spelt file then you can include your CSS directly inside that component and it will only apply to that component and then your bill tool will you know extract it out and chunk it up and like do all of the optimization stuff that you shouldn't need to care about but you are describing the Styles at the same time as you're describing the markup of your component and the behavior of your component and a lo

t of Frameworks just sort of leave that as a you know exercise left to the reader type thing and and that's not what spels philosophy is spels philosophy is you're building a web app here's how you build a web app and we're going to give you the tools that you need to do that we're not going to just throw our hands up and say ah someone else solved this problem and you haven't seen like because of that you haven't seen the same kind of like explosion around like CSS and JS Solutions like react h

as where there's a thousand different choices to go with but you just kind of use what's built into the framework that's felt exactly I mean you can use all of those CSS and JS things with felt and people sometimes do I I recently have discovered the Dr tailwind and I yeah that's that's a bit different it's a little bit different yeah I mean for a long time I was a real Tailwind skeptic but like it's one of those things where if you start using it you're like okay I get it you wrap your head aro

und it yeah um and so I'm I'm much more Pro Tailwind now having used it than I was as someone who just looked at tail and was like yeah but that's different from like a styled component emotion kind of thing all those things um they I mean you're absolutely right these these came out of uh just a a Gap in the market essentially like reacted created space for these things to emerge and that is both a strength and a weakness in my view um it's a strength because if you leave space for Innovation a

nd then you let the community come up with these Solutions then you will often come up with some really good Solutions but it's also a weakness because like number one people starting to use that framework they immediately run into this decision fatigue like oh which is the best one and like a lot of people um just don't have the time and inclination to really do a deep study of which of these options is most suitable so they'll do whatever is currently most popular like people are talking about

Twitter or whatever change it next year and then change it next year but in the meantime like they they are they are stuck with a solution that may not be the best one and the other thing is if you're building something in a more integrated fashion like if you as the the framework team are taking on this problem then typically you can come up with a much more op optimal solution you know we have seen with some of the CSS and JS Solutions like a lot of them especially the early ones they just we

ren't very good they brought some nice developer ergonomics but they resulted in some really bad performance characteristics and that is not a problem that fault users have ever had like we haven't had this thing where you know you use a thing and then two years later everyone's like you fool why are you using that thing because we took it upon ourselves to think about that problem on behalf of the people using the framework and you know opinions can differ about the relative merits of leaving s

pace for Innovation versus providing people with the tools that they need to do their jobs out of the box but my instinct it definitely leans more towards the you know this is a problem that someone has to solve and it may as well be us rather than all of the people who are going to use the framework what was the initial problem that made you want to write the first lines of spel the it was more a sense of Shame than anything if I'm honest spel is is not my first front end framework um years and

years and years ago I started a project called ractive which was one of the like early 2010s era of of Frameworks like back when people were using backbone angular just come onto the scene react did not yet exist when I started building ractive um Ned View and it was essentially uh you know one of the template based solutions to the problem of describing interactive user interfaces and at the time it was like pretty novel you know had some some good ideas and it it gained some some usage um I I

think uh Delta Airlines used it at one point um I remember discovering that Playboy TV uh were were one of our users like they they raed great user experiences famously exactly um so it did get used although not particularly widely and that's probably for the best um it's you know like uh anyone's first attempt at a major open source project I made a ton of mistakes in in building that and so even though we had a pretty tight little Community around it and and people enjoyed using it it had som

e pretty serious flaws particularly in terms of um performance and the the amount of JavaScript that it would add to your application um and at the time I was working in the news industry where these things are very important typically if you're building interactive um applications that are embedded inside news articles which was my job at the time um you need to worry about performance and you need to worry about the amount of JavaScript that you're sending because you're already on a page with

analytics and ads and like all of this other stuff and so like you've really got to like try and minimize the amount of damage that you're doing and and reactive was doing quite a bit of damage I I came to realize um and so the initial impetus for spelt was like can I atone for my sins by making uh something like reactive but which is much faster and which involves much less JavaScript and at the time I was you know I've been building um a module bundler called rollup for a couple of years and

I've been dabbling with the at the time it was popular to build um es6 to es5 Transformers and so I'd built one of those and so like I felt like I had a pretty good understanding of how you know the compiler World operates like you take some input and you you turn it into an abstract syntax tree and then that's what rollup and5 Transformers so I was in that kind of head so between these two things I was like maybe maybe there's a way to solve the the frontend framework problem by using compiler

techniques instead of thinking about like how can we have the most efficient framework runtime what if we just reposition the idea of a framework as instead of being some code that runs it's like it's just a way of structuring your code it's just a way of thinking about how you architect your application and as part of your build process all of that just kind of melts away and so it it began really as a as a kind of experiment in whether that was feasible whether that would work um and because o

f ractive it it there was sort of a ready-made Community who is ready to to come and help with that project uh and that's how that's how it got it start seven and a bit years ago wow yeah so you were already in that like compiler mindset you were kind of a hammer seeing everything as a nail and thats why you were look at UI framewor aone you were just like compilers like let's just yeah I mean I I don't think that we were the only people thinking in these terms but I think we took that idea much

further than anyone else like people were definitely thinking oh you know I I have some jsx and these bits never change maybe I can hoist that to the top of my module and then I can make the the diffing process more efficient and angular had a concept of ahead of time compilation which um you know it wasn't as Extreme as felt just completely turning it into you know direct Dom manipulation code still like this intermediate representation but it's the same process of trying to do more work at bu

ild time so that you can do less work at runtime in the same way that you know it's beneficial for the framework team to take on problems that the user base is going to have to solve eventually it's better if when you're building the application once you're doing work that then doesn't have to happen by each of the users who download the app and run it in the browser so you mentioned that ractive rollup and spelt were all created in news rooms uh when you were solving problems kind of on the gro

und there does it help to innovate when you have those on the ground problems and you still feel like you have those uh I I definitely think that it helps when you're trying to come up with these Solutions like the phrase uh constraints be read creativity or whatever the the phrase is um like there is a a threshold that you have to meet when you're building something that is going to be used in in that environment where you know the the page where you're deploying your app to is like a hostile e

nvironment and so you know you you need to you need to De cleare a certain bar but also like you're working in an environment where you have very tight deadlines that are non-negotiable because it's the news and and so you can't have situations where like oh I I need to fix this bundler configuration issue or like oh I need to spend four hours optimizing this thing because the like the naive way of doing it happens to be slow because of how the framework is architected or something like that so

there are definitely these these these challenges that you just have to face when you're in that situation and what I think we've learned over the years is that if you can do that if you can meet the bar of being being able to create something very quickly in a very like time crunched environment that is still going to work effectively on you know people's mobile devices and so on then you've probably done something that is going to work in a lot more cases as well and so initially people looked

at that Heritage and they were like oh so okay so it it's useful for building these very small self-contained things but like it probably doesn't scale to real World apps and whatever um and it turns out that's just not true if you can make web development simpler for the simple cases then like in most you've also made it simpler for the hard cases um and so I think you know that the success of spel to the extent that it has been a success outside of new news rooms is Testament to the fact that

if you start with these hard problems then you're also solving the same problems that everyone faces outside that environment do you you still see some of that Newsroom DNA ins spelt uh yes um there definitely is some um I think part of that is in the things that we prioritize as a framework which includes things like um you know Transitions and and animations and things like because you know very often when I was building these things you know I'm building explanatory Graphics that need to wal

k you through um a a process of some sort and very often that will involve transitioning from one state to another and and typically Frameworks just kind of don't solve that for you um but for me I felt it was important that transitioning between states is actually a first class responsibility of the framework and so there are there are elements like that which definitely hint at its News Room Origins but I think also just the fact that spel is or at least tries to be a very easy framework to wo

rk with because a lot of the people who do the job that I was doing in newsrooms um they're not programmers for the love of JavaScript right they're programmers because that is the most effective way to to do the job of telling the story that they need to tell um and so you know a lot of people candidly just don't have time for the front-end industry is we don't want we don't want to spend time thinking about configuration and optimization more complexity in order to yeah yeah like oh which whic

h Library am I supposed to use for State Management no it's a it should be built in like I just want to get the thing and start using it immediately and not have to be burdened by these dozens of micro decisions that that candidly some Frameworks do uh do make you solve um and that I think is is sort of a a core tenant of spelts philosophy um today still and it's one of the things that I think our users appreciate so you don't have like time for bike shedding when the deadline's tonight right ye

ah right if there is a a sensible decision and you know sometimes there need to be Escape hatches sometimes we need to say okay if you're going to you have some very specific requirements that aren't part of what we anticipated then like sure here's the Escape patch go nuts but for for most of the time for most of the user base like you can just use the stuff that's built in do you have like an internal metric for when you roll your own package versus when you use uh some other tool that already

exists like what's that bar for you uh it's not something that I I don't know if I could like quantify it um I suspect I I personally am a little bit quicker to to roll my own than um than a lot of people I I really en appreciate knowing exactly how the sausage is made um and you know very often if I'll use a dependency for something and and it feels like it's what I want but then you know down the road I I find myself fighting with it and I've had that experience enough that I I tend to I I th

ink I recognized the signs that oh this is going to be annoying to to Future me so I'm just going to take on the burden now and just build something myself also it's just kind of fun to make stuff yeah and so there are a few examples in inside spelt for a very long time um we used a a a library called CSS tree for paing CSS inside spel components and in spel 5 we've we've got rid of that in favor of our own CSS paa okay because it turns out that for what spell needs like we don't need to have Ri

ch detailed information about like oh this this string represents this kind of color with these values like we don't care about that we just need to be able to identify the the selectors inside your CSS and things like that so we can build a much much simpler version of the thing that that otherwise like you're installing something from npm it needs to be able to support a much wider array of use cases and so if you have a narrow use case and all of the things that are out there just by virtue o

f the fact that they are libraries support a much wider array of use cases then it's very often the case that you can make something that's much more tightly focused and much more appropriate for your task um there are other examples we have um our own as traversal um Library we have a we use a thing called zimma frame which we built Force felt 5 um we have our own code generation Library um it's called ES app which is like yes but also pass backwards uh because you take an as and then you gener

ate code instead of having a code and then taking generating an as and so yeah so we have all of these little utilities which are technically independent projects um but they are handrolled solutions to problems that we faced while building spelt and you know for us they are better than the solutions that you can find out there on the internet so yeah I I don't know the I could say there's an internal metric exactly um but as soon as I get the spidey sense that we can we can do better it's an in

tuitive thing then we we just go ahead and and and we do it it seems like signals is the current idea that Frameworks like solid spell view angular are all adopting what do you find compelling about signals that you want to bring that to spel yeah so the you use the word current um which would kind of suggest that this is a a phase that that the community is is going through and maybe there's going to be a new thing but I I'm actually not sure that's the case I think that this is more a converge

nce like over time we've experimented with a bunch of different ways of of handling reactivity and side components and what we've learned is the the signal approach is is basically the the right one um people talk about there's this meme about how you you know nature evolved crabs or craba likee forms in multi mle species it's PR called cariz and the same thing is happening in the JavaScript framework world with with signals um and it's I don't think it's a bad I think this is genuinely the righ

t way to think about um how you you know have some change in state represented in a change on the page and it's not like a new thing we've been doing this for a very long time I think knockout probably deserves the most credit for being the framework that that popularized this idea in like I think it was 2008 when it came out um but over recent years it's definitely the work of solid and it's Creator Ryan carard who like have evangelized this this idea and really made people understand the benef

its and those benefits are essentially that you get um a really easy to reason about fine grained reactive system and what I mean by that is you can have a component that references a whole bunch of different pieces of state and maybe it contains components inside it with their own State and and all of that and in the in the world that react popularized where you have this thing called the virtual Dom and when you have a state change inside a component what happens is that function reruns and th

en you compare the old with the new and then you you change out the bits that change like that involves a a fairly course grained approach to updating your page and it's not so much the diffing the the before and after is expensive as that you need to keep rerunning all this code and it's very easy for for performance issues to creep in over time the signal approach is I think a lot simpler instead you generate these components once and then all of the the holes in the component where the state

is uh exists those things are the bits that update when the values change got it and so instead of rendering entire component or you know in the worst case an entire application um you really are making these very targeted updates to the things that have changed and different Frameworks have tried to solve this in different ways over the years you know spelt had a sort of hybrid approach where it was it was a topdown system like react but with um like instead of diffing the the jsx it it would i

t would diff the data that was coming into the component and it would it would maintain knowledge of which thing had change so that we could early out if you know you have a an if block that references some state that we know didn't change then we just don't check it at all like so do were these optimizations to make spelt three and four fine grained is um but spelt 5 is truly fine grained because it adopts the same signal idea that is now so prevalent in in other Frameworks what we do different

ly is um around the ergonomics of using signals up until this point Frameworks that use signals have had to sort of present you with this layer on top of your your data um which is I think a little bit awkward like you can't just reference your data directly you need to either call a function or you need to access some property of a of a proxy or something like that and it kind of really gets in the way of just thinking about the stuff inside your app in in terms of the raw data but because we'r

e a compiler we can have the best of both world we can give you that nice uh direct uh interface to your data but also have all of the reactive magic um that allows things to update in this very seamless and fine grained way um so that's that's the benefit for us and you know we haven't shipped it yet this is you know the in development spel 5 but from what we've seen so far we get really good results like it is incredibly fast on all of the benchmarks we do really well um scores well in terms o

f memory usage in terms of component Creation in terms of updates like all of these things um it turns out it's just a very very good way to think about managing state to the extent that there is now a a cross framework group of people who are looking at how we can add signals to the language itself um to JavaScript yeah it's so I I I don't think I'm I'm revealing any like Secret um no no this is a this is an effort that I think some people are broadly aware of um because all of these different

Frameworks are essentially Reinventing the same Primitives from first principles um does this idea that it would be better if this existed in the language itself in some form as you said like with CSS and spelt solving there if just JavaScript solved it for all the Frameworks and then they could solve it for all the users exactly okay and you know once once you've once you've solved all of those common problems then you can focus on the things that differentiate the Frameworks you know you can d

ifferentiate on like user experience and developer experience and the feature set that you include in the framework and all those things rather than everyone spending a lot of time trying to make sure that their signal implementation is like as good as the next person yeah you recently announced uh spel 5 and runes can you talk about runes what are those yeah runes are a signal to the spel compiler that something is is happening um in spel three and and four we would kind of infer your intent fr

om how you do it in your code if you had let count equals zero and then inside a increment function you had count plus equals 1 and you were referencing that count somewhere inside your template then we would say oh this count variable this is a piece of State this is a reactive piece of state that when it changes we need to update something and so the compiler would instrument the assignment when you do count plus equals one it would also call a function that said to to spel oh hey this compone

nt needs to update and by the way inside this component the thing that has changed is the count and so that's how we got that pseudo grained reactivity um and that feels like pretty nice and and ergonomic but it means that you're restricted to having that reactivity at the top level of your components right you're not going to start creating state in inside let declarations generally um and so immediately we have this sort of you know you work inside do spelt files and you're in this sort of mag

ical reactive land and it feels really nice but then if you have some logic that exists in a Javascript file you don't get to benefit from any of that and so we had this second way of thinking about state which we call stores so inside components you use component State outside components or if you need to share something between components then you use this whole other system of of managing State and we really wanted to get away from that we wanted to have a way that you could say inside an arb

itrary function oh this is a piece of state and beyond that this is derived from these other pieces of state and we also wanted to have a way of saying this code should run whenever any of the things ref inside it changed and typically these are referred to as effects in Signal based systems and also non signal based systems like react has use effect and and so on and so we spent a very long time thinking how can we solve all of these problems that we want to solve we want to have you know signa

l-based fine grained reactivity we want to have the really smooth developer ergonomics you know want to do count plus equals one you don't want to do set count count Pern plus one or count do Value Plus equals one like that sucks and um and we also want to be able to have a single unified model both in your spel components and in modules that are shared between Spell components and after trying some outrageous number of of design ideas like I think we tried 50 or so different ideas um we eventua

lly settled upon runes as the ideal way to communicate to the compiler that you're creating a piece of state and what a rune is when you're using it it just looks like a function call so instead of doing let count equals z you'll do let count equals dollar State Pern z um and as far as like typescript is concerned that's just the identity function the thing that you get as a result of that is just zero um so it it's still typed as number and you can still do count plus equals one but we have com

municated to the compiler that this thing should be treated as reactive state so when it goes through the compilation process what's left is let count equals Source zero and then subsequently every reference to that piece of of State instead of referencing count it'll do get count um which extracts the value from the signal but also says whatever is currently running is a dependency of this signal so when it changes that code will need to rerun and so that means things inside your template um bu

t also the effects that you describe um those become the dependencies of of that signal and the reason that um that runes made so much sense is that because they just look like function calls syntactically you have a lot of flexibility about where you use them um and as I mentioned typescript understands perfectly well what's going on and so a lot of the other things that we tried didn't satisfy all of those different criteria but but runes work really nicely and they're not functions that you i

mport from a library like you're not importing the dollar State Rune from spelt it is just a part of the language so like you shouldn't think of them as function calls even though they look like function calls it's more like the you familiar with the the dynamic import construct um also looks like a function but it's not a function the dynamic import is a special piece of syntax um and runes are the same thing they are a framework specific piece of syntax that essentially makes reactivity a part

of the language that you're writing when you build a felt application and you can use these State derived effect and a couple of others inside your spelt components but also inside any file that has a dot. JS or dosel dots extension so instead of having your component State over here and your stores over here we can start to use a consistent um way of describing State inside your applications and it we've tried it in a bunch of different context and it feels really nice that's awesome so that d

ots .js file is essentially a Javascript file but it's one that the compiler flags and goes aha I need to do something here exactly so you get all of the benefits of writing JavaScript or typescript um like all of your existing tooling works it works fine with your type Checker and like your your editor that like we don't have to invent a new file extension that has like syntax highlighting requ all of that um no we just get to reuse everything but just by adding that do. JS to the file extensio

n we're saying to the compiler oh hey you want to check this file too cool um and it and it impr practice that that works really nicely because we are essentially we are creating a new language this is not JavaScript or typescript anymore this is a superet of JavaScript and typescript um and so like initially we thought about just doing that in every day snts file like we would just everything would go through the spell compiler um but like that's that's kind of naughty because in the same way t

hat dots is a language for describing um user interfaces. JS andelt dots it's a language for describing reactivity okay and so that that is how we think about it we are bringing this concept which all Frameworks need to have some version of everyone has to solve this problem somehow and we are saying it's part of the language um and in our in our experience that is just a much more natural way than having some framework specific API for doing count plus equals one so sp's pretty different from r

eaction view in a few ways but I think most notably is that it's compiled as you talked about can you talk about why that matters so much it it matters a lot less now than it did when spel first came out and if if I'm honest I think we should probably update the blur on our website because it's candidly a little bit out of date you know Vue has a compiler step now which does a lot of the same work that the spel compiler does um react to uh you know the react team has been working on on a comp pi

ler for a long time react forget um and a lot of these ideas have have sort of seeped into other Frameworks in the same way that we have borrowed ideas from from those other Frameworks um but the essential difference is that like if you can do work at build time that you then don't have to do at runtime that is going to deliver a better user experience generally speaking um and so spel kind of began as an experiment in how far you can push that idea of doing the work ahead of time um and it turn

s out there are limits to what you can do with that idea because the compiler needs to understand your code without running it process called Static analysis okay and there are limits to what you can do with static analysis like everyone's heard of the halting problem you know can you look at a piece of code and determine whether or not it will run to completion or not like it's a turns out that's an impossible problem to solve with static analysis alone and we run into some version of of that h

alting problem in Sp three and and spel 4 um around like understanding what the dependencies of a particular piece of of code are and so to us the the compiler difference the idea of starting from this mindset of we're a compiler um like we can we can do things that you can't do if you're just writing JavaScript it essentially expands the solution space in in which we operate um so things like spel FES runes are a like they're a thing that you can do if you're a compiler and you absolutely canno

t do if your starting point is that you're just writing JavaScript or JavaScript plus jsx um and so that's I think the essential difference it's not so much that your capabilities change it's that the way that you can express ideas in uh when you're describing a user interface um you have the opportunity to to to do things in a much more natural and concise way because you've shed yourself of this constraint that this has to be JavaScript um and that's that's borne fruit in in a lot of different

ways and and the essential outcome is that when you're writing a spell component it is typically a lot smaller than the equivalent react component or the equivalent view component um because like we don't have have those constraints um you know off the Cur like typically if I'm converting between a react and and a spell component the spell component is like 30 to 40% smaller and when you can do that when you can have that much less code inside your application the evidence suggests that your ap

plication will be more stable it'll have fewer bugs because the number of bugs increases super linearly with the size of of of a code base and so there are just all of these benefits that flow from that mindset you can write less code you can um do various optimizations that would be impossible if you were just interpreting the code at run time and at least for for my taste you can write things in a in a more natural and expressive way than if you don't have a compiler unlike other Frameworks sp

elt has a backend framework that's built by the same team yourself and I'm I'm assuming the same contributors or like very largely there's different people have different focuses but it it's the same team working on both things yeah got it um how does that uh affect what you can do how like like it it just feels so different from like the react core team and the next core team kind of being separate um yeah what what does that unlock for you I think it gives us better visibility into the problem

s that we're we're trying to solve okay um and I I think that a similar kind of thing is happening to an extent with react and next because like a lot of like there is a lot of overlap now a lot of the react core team actually now work at Vel I shouldn't say a lot a few people who are on the react core team work at Vel and are directly involved in in next and having the same people think holistically about like the the full spectrum of of the problem is really beneficial and we have found that t

o be the case as well like we're able to think I just think a little bit further than we otherwise could about whether a particular design idea makes sense like if we're building something into spelt is this something that is going to make sense to a user of spelt kit um or like is spel kit having to do a lot of work that should actually be part of the framework itself and I think the result is that everything just feels a little bit more cohesive and seamless than if you had two distinct teams

who like you might have really good communication with each other and might have the best intentions of staying aligned but but there's just like a a fundamental barrier if if the ideas are in separate brains yeah um when they're in the same brain then like there is no higher bandwidth communication than like a brain to itself if that makes sense and so uh I I think that um maintaining spelt kit alongside spelt has made spelt a better framework and I think maintaining spel alongside spel kit has

made spel kit a better framework um it's important to us that the two things remain separate okay there are lots of people who for whatever reason cannot use spel kit but they still want to use spelt and that use case is always going to be supported and like we're very happy for other Frameworks to be built on top of felt like Astro is a great example of of a framework that is not built on top of spelt but you can use spelt with Astro and a lot of people do that and really enjoy it and that's t

hat's exactly the outcome that we want but you know we want to have the best possible endtoend experience for developing websites and the only way that you can do that in my view is if you're thinking about the problem from both ends so that's what we try and do how do you like what's the line for you uh determining spelt and spelt kit like like a feature falls on this side of the fence or that side of the fence like what's your mental model for them so the the way that we'll often describe it i

s spelt is a component framework and spelt kit is an app framework okay um it's slightly unhelpful that the word framework is in involved in both like sometimes people will use words like Library instead and the the semantic Contours get a little bit fuzzy but essentially if it's to do with describing an isolated chunk of of of UI then that is spell if it's to do with server side rendering build tooling uh code splitting deployment routing like all of that stuff then that is the application fram

ework um component framework is probably a little bit outdated now that we're adding um stuff to spelt JS and spelt TS files in the form of runes in spelt 5 um maybe we need to come up with some better terminology that better articulates the distinction but um essentially spel is the thing that you use if you want to build a standalone piece of user interface and spel kit is a thing that you use if you want to build an application out of those standard Standalone pieces of user interface so what

other improvements or changes are coming with spel 5 ah wow so many um I'm very excited about spel 5 I think it gets rid of a lot of the pain points of spel 3 and four and I I don't want to be too negative about spel 3 and four because like a lot of people use them and and they love them seem to like it they they do seem to like it but it's and they're wrong yes it's it's actually really kind of frustrating to see people talking about talking about spel 3 and four when we know that spel is goin

g to be so much better and like just like I almost don't want to recommend that people use spel until we bring out spel 5 because stop I know it's it's it's difficult um so we got a lot of things right with spel 3 and like spel 4 was really just a it's the same thing it's just a we just got rid of some some some junk but it's basically the same same framework same design we got a lot of things right um but there are some things that candidly we we didn't get right um you know there are limits to

what you can do with static analysis and people have encountered those limits um for example um statements that Rerun when State changes we put those behind this syntactical construct called a reactive statement which you used a a dollar label so dollar colon and then you know sum equals a plus b and that will just recompute and another A or B change and people really love that and it's part of the language is clever solution part langage like it's it's it's a pretty good hack but the way that

that works is the compiler looks at that statement and is like oh so we're assigning to this thing so that becomes reactive State and on the right hand side of the equal sign we've got an an A and A B so I'm going to the code that I generate will will update when either A or B change well what if a and b aren't referenced directly in the statement they're referenced inside a function call yeah well at that point the compiler can't see it anymore and so that no longer works and there are other qu

irks that come from that static analysis driven approach to to describing these reactive dependency graphs that just don't really work and there are some other quirks so because everything is based on assignment by which I mean it will instrument anytime it sees an assignment expression like you know count equals count plus one or count plus equals 1 those are both assignment Expressions it will instrument that and that works most of the time but if you have an array and you push an item to that

array nothing will happen so we need we need to tell the comp exactly so you'll have you know to-dos do push and then some data and then immediately below that in spel fre and four you have to do to-dos equals to-dos to signal to the compiler that it needs to update to-dos well that's that's crazy right that doesn't make any sense at all that is just an abstraction league and in spel 5 that's no longer the case because when you create create your to-do State using The State Room it will actuall

y turn that into a proxy or a set of nested proxies so that we can analyze the um the sets to the the children of that so in spel 5 you can do to-dos do push and it just works and not only that but when you reference that further down and you know you bind an in a checkbox input to the to-do DOD property you toggle that and it will just up date that to do whereas in spel 3 and four because of this static analysis driven approach the best that we can do is say oh something inside to do has change

d and so we've just got to like check the entire thing got and it can do that relatively efficiently like it caches individual like snapshots of state so that it's not doing unnecessary Dum manipulation but we still have to to check a whole bunch of different things and that's no longer the case in spel 5 so ergonomically it's better per performance- Wise It's better and it's just a more consistent and easier to reason about system and yet that's not even the stuff that I'm most excited about be

cause the so we we have we have ideas for the world that spell five will enable Okay that I kind of don't really want to talk about because they might not work like we might try and build it Like H okay no we thought we could do that and it turns out that we can't but um when when you're building on on top of this this sort of the word that I'm going to use is is immutable and that's a little bit confusing in this context because like I I just talked about how you can toggle the to-do DOD thing

and like that doesn't sound very immutable but yeah underlying that is um is a system where uh you're not actually toggling a property you're you're essentially running some some code all of that data is immutable in the sense that matters and when you have immutable data structures you can start to do some really interesting things that up till now have been Out Of Reach and so that is some territory that we're very excited to explore post 5.0 Okay and like a 5.2 is what we're talking about see

52 not not not like a six is what I mean that the the goal is is to um is to start building some of our like our our Dream framework constructs um on top of the the five foundation and then like in six maybe like we can we can shed some of the um some of the stuff that supports the old way of doing things um and we also have some big ideas about uh more effective Primitives for doing um Motion in inside uh components and there's just a whole bunch of things like that that that I I need to reall

y try and and not get carried away with because we need to ship 5.0 and if we spend all of our time daydreaming about what we can do later then we we'll never ship anything but like there's a there's a long-term vision for spelt and spelt kit that spel 5 is kind of the the beginning of okay um we have we have some pretty exciting plans so you just released smel to yesterday as as of this recording um what can you tell us about it what's different what isn't uh mostly it's the same um we were deb

ating whether to do a major felt kit release or not at all um the impetus really was that V5 came out and V5 had some some breaking changes and it's it's just difficult to support multiple um major versions of your dependencies and so we saw other projects that were updating to V5 and like it would be easier to do a major so that we can drop support for for V4 okay um and once we decided that that was what we were going to do we were like all right well when do we do this and Ben mccan um one of

the called maintainers of spel Kit pointed out that the one-year anniversary of the launch of spel Kit one was going to be the 14th of December and so we thought it would be poetic to just like do spel kit to then and initially we thought there's really not a lot of work to do here there's just updating to V5 and maybe there's like a couple of things that we want to get in there as well um so this should be easy and then as we started going through the issue tracker and looking at the things th

at we had made mental notes of saying oh we kind of got this slightly wrong in spel kit one so we should change that for spel kit 2 um we ended up with this pretty sizable list of of changes to mostly these are just like very minor things that most users either haven't encountered or or will be able to update very quickly or in many cases we can even automate it yeah um but it it it ended up being a lot more work than than I thought it was going to be um just while I'm here it's get a little of

these a few of these tickets and yeah so it's a fairly Sleepless week but we we did it we we got spel kit out and um for the most part it is just a drop in replacement for for spel Kit one um there are breaking changes that's the reason that it is a major version um and so we you know we definitely encourage people to to update to the latest version of one first addressing the deprecation warnings and then go through the migration script to update to spel kit to um there are some new features th

e big new feature that we added in spel kit to is something called shallow rooting and what shallow roting is is a way of associating some arbitrary state with a history entry so the canonical use case that I'll give you is that of a a modal dialog box um often like you'll something and well Instagram is is another use case that is solved by this but this is like something pops up that you need to confirm or deny or whatever it is um and my instinct whenever I I see one of those things on my pho

ne is like oh I don't want this I want to dismiss this so I'll use the swipe gesture to to go back but if that model is associated with some component State like show model equals true then when I do that I'm navigating back through the history stat and I'll go to a completely different page which is not what I want so my my instincts as a user have just ruined the flow of the application what you want to do instead is associate that modal state with history so when you open the model you have u

sed the history push State API to add that state to your application and then when you swipe back you are just going back and undoing that state change and until spelt get to that was really difficult to do but now it's incredibly easy um you just import the push State helper from uh app navigation um and you can push arbitrary State and it will it will just get bound to this this globally available store that you can um you can use anywhere in your app and it's a very kind of nice idiomatic way

to solve that problem in a way that um prevents that you know swipe back go to a different page problem that people encounter but you mentioned the Instagram navigation pattern as well uh where if you're on a um on a page that has like a bunch of different photos and you tap on one of the thumbnails you you get a detail view in a popup right instead of being taken to the photo page um opinions differ about whether that's a good pattern or not I think it's quite nice I think it it like feels ver

y seamless and smooth um keeps you in context but also gives you the information that you're looking for um and that too is a really difficult thing to implement unless the framework supports it somehow and so with shallow rting you can solve both of those problems and like I'm really curious to see what people end up using it for it's kind of a power tool um and it's not something that you should use for like the bulk of interactions inside your application but it's for when you need it it's it

's really useful um there a few other little improvements here and there um uh invalidation of uh load functions in a spelit app is now um more granular if you're changing um query parameters uh one of the the spel ambassadors Paulo um implemented this this feature cuz he needed it and and it's really cool like you can change the the the I don't know some query parameter that is not uh a contributor to the your data loading process and and we don't need to rerun it anymore nice okay and so like

just little improvements like that that mount up to an overall more solid and more polished framework um but which should hopefully feel very familiar to use the spel kit one so what are your goals for a spel kit and spelt in the next few years is it around like market share uh adoption uh the framework size or complexity uh so adoption of market share is is we we care about it to the extent that it is an indicator of whether people enjoy using the framework or not it is not a goal in and of its

elf it's something that I mean I suppose I do need to be mindful of it because Vel is paying me a salary to to work on this framework and that only makes sense if the user base is growing yeah exactly um so we do we do care about adoption but it is not our primary focus and you know if it was then we would probably make different design decisions we would we would do the things that our users were yelling most loudly for as opposed to the things that we believe is the best long-term bet for the

health of the framework and the people who use it really what what we want out of the project is we we want to do our bit to try and crisis is is a bit of a a melodramatic word word but the web is not in great health candidly um the software industry is also not in that great health like a lot of things that we use in the digital world on a day-to-day basis are just broken yeah right I I use you know apps and devices over the course of the day and like very often I'm just flabbergasted at how ba

d they are like I I try and watch TV and and the my chome Casas thing like it'll take five seconds to respond like people just aren't building good software at the moment and it's very frustrating because so much of our of our world is mediated through digital technology that is you know poorly implemented and and and and buggy and all of these other things and I really love the web and I care about the web and I think that you know it is such an important technology that we need to preserve and

like as bad as as native apps are a lot of the time I think the web is a lot of time much worse in terms of user experience and reliability and all of these things and I want to do my bit to try and reverse that Trend I want to make it um easier for more people to build robust web applications that are fast and reliable um codebases that are easy to maintain so that we don't have this this descent into bit rot and and bugginess and that's the stuff that I care about that is the reason that I'm

invested in spel and spel kit um is because I want the web to be a reliable platform for people building complicated apps and I want as many people as possible to be to be a part of that like I I don't think that front endend development should be The Preserve of like the this sort of priesthood of of people who are able to deal with all of these Arcane framework Concepts and this like proliferating set of platform apis like it should be much easier to build good robust software than it is today

and that is that is why these projects exist that is why I am still motivated to work on them after working on spel for seven years um and if we if we increase adop option and market share as a result of those then that's that's great but you know it's not our main focus so it's more of a mantra than a metric would you say like it's more about like like like a holistic kind of like I want to achieve this with the framework rather than what are the numbers at exactly we um to the extent that I I

can talk about the team having a particular culture I I think it's true I think that there is a shared culture on the spel team um we are pretty suspicious of metrics in general like a lot of benchmarks are kind of nonsense when you actually look into them and a lot of the things that web developers fixate on like Lighthouse scores and core web vitals like these are useful diagnostic tools but they are terrible metrics because they are so easy to game and because the the results that you get va

ry so widely based on the problem that you're solving as opposed to the tools that you use to solve it with um and so we we we disre we don't disregard metrics we pay attention to metrics but we never let them control our decision- making we think that's a really unhealthy thing that unfortunately is is quite prevalent in our industry um and and we we resist that we are thinking as far as possible in terms of first principles and like a a long-term vision of the way that things should be instead

of focusing on on numbers yeah it makes sense cuz just thinking back after you said that I don't see a lot of numbers around spel kit you kind of you you frame it as like you know a simple framework or like you'll talk about it more in the experience less so than the like 10 times faster than yeah something else because that those numbers never exist outside of of a context a vacuum yeah people will often talk about things like Lighthouse scores which is like a reasonable way to measure the fir

st load experience but tells you nothing about the experience of actually using an application once it's loaded and so there's just these huge blind spots in the ways that we talk about these things today um that I we could maybe we could solve them with more measurements but I don't think we can I think we need to solve them with a a focus on just like paying attention to the things that we're building and and thinking deeply about what a user actually wants to experience as opposed to what the

se numbers are trying to tell us um so yeah we are we are a very qualitative and judgment driven framework in 2015 you made rollup right and then around like 2018 you handed it off to a maintainer uh then Evan U comes along grabs rollup and Es build and builds V from from that essentially and then then you come back and you build spel kit on top of v as essentially a v plugin is is is that accurate it is plug yeah how does it feel to kind of have like your old work kind of come back as foundatio

n for what you're building these days is that yeah like how's that feel I mean it it feels it feels nice to know that this this thing that has so taken over web development V has has so completely taken over um the way that people build front end projects these days um it feels good to know that I I can claim like a a tiny share of the credit in that V has four packages or or like four main dependencies it's es build it's rollup uh it's post CSS I think and like one more for um handling file man

agement so like it's yeah I'm I'm not saying you built V but at least it's it's it's kind of a substantial part of what makes VTech yeah I mean I I I'm not trying to FY the truth is yes I started roll up but most of the credit for rollup does not belong to me it belongs to Lucas who's been maintaining that not single-handedly but he's been doing the Lion Share of the work for for many years and it is a much better project in his hands than it ever was in mine um but yeah I I it is nice it does f

eel good to know that that thing that I did back in 2015 to scratch my own personal itch which was you know at the time the options were basically browserify or webpack and both of them had some very high costs for the work that we were doing um um again like in in news rooms we're trying to minimize our bundle size as far as possible and the bunders at the time were pretty inefficient about how they bundle stuff and and and with the Advent of JavaScript native modules um I saw an opportunity to

to do things in a much more optimal fashion and and so like it was born out of this scratch my own itch take advantage of of this change in the landscape um and just like throw it over the wall and see if other people find a use for this too and and people did and it is it's always surprising to me to see uh which things land and gain an audience and which things just just don't and roll up just happened to be this thing that served a need that existed at the time and has just kind of become th

is thing and and and it always reminds me that if you have a problem it's very possible that other people have the same problem and so like just just share your work and just see what becomes of it and that's just a really great thing about about our industry is that you can do that like we have this open source culture um and I I I appreciate the fact that I am now one of the beneficiaries of of past me's decision to do that and I I encourage people to do the same thing like you you never know

how useful something is going to be until you just add it to the commons so you joined versel about two years ago um what has changed since you've gone full-time uh and like can you like walk me through like a brief like day in the life of Rich Harris are you uh kind of off on your own working on spelt and spel kit with the spelt team are you in lots of versel meetings kind of working on marketing strategy there like what are you doing uh so it's been transformative for for the project I I don't

know that we would have managed to get spel Kit done without having full-time Engineers working on it um it's so for for people who are using spel and spel kit it has been a a very positive change um in terms of like what our day-to-day looks like so there's there's three of us now who work at sful time on Simon myself Simon and Dominic doic cool um and we pretty much just work on on spelt and spel kit obviously being at a company like Vel um means that there's a lot of cross-pollination with p

eople working on other problems like we you know we talk to the next team from time to time um and we you know we share notes on things but uh you know to a very large extent we are um focusing just on on the open source project which is really great like we get these long uninterrupted periods in which we're able to Think Through um problems in a way that wouldn't be possible if we were still doing it on like a evenings and weekends volunteer basis um and so it it's been it's been a very positi

ve change for the framework it's also been a very positive change for me because prior to joining Vel I was doing a more than full-time job at the New York Times and then I was like trying to to contribute to this project in my my free time and like I don't have a lot of free time and so it meant that the velocity was was kind of reduced and it also just meant that I don't want to say that I I resented working on on the project because I absolutely didn't it was like a you know it's always been

a hobby and a passion but it's hard to justify spending serious chunks of time when you're also trying to have a life outside work and so my my work life balance is still not great I probably spend more time working in front of my laptop than I should but it's infinitely better than it was before um so it's been a been a win or round and hopefully it's been a win for Vel too having um having the team that builds felt like as as part of the as part of the crew um because you know a lot of the cel

l customers use spelt and spelt kit and it's it's nice for those people to have kind of like a a a direct line to us when they need it but also like the reassurance that um that there is a a long-term support for the thing that they're building their business on top of the official documentation and tutorials and everything of spelt and spel kit are honestly like no other framework that at least I've learned um like you have examples on there that save me from like 80% of my Google searches the

tutorial takes you through like step by step in an interactive way uh teaching you both spelt and spelt kit what is your philosophy around educating developers does when someone is new to a project there is a barrier that they've got to overcome and they maybe they're interested and motivated in learning how to use your thing but the chances are they're just like mildly curious and if the first thing that they have to do is clone a g repo or install some CLI or whatever it is or like read some d

ocumentation and then like try and apply it to to their own situation you've already lost you've already failed um and I I really believe that the the way to do this is is to make it interactive and to involve people in a way that has zero friction and I learned this from knockout okay back in the day had this maybe it wasn't the first of its kind but it was the first example that I saw of of a a front end library that gave you an interactive web-based tutorial where you didn't need to install a

nything you could just start going through this tutorial in a web browser and it was great it was so cool and so when we launched felt initially we had uh a similar thing where you um you have these interactive tutorials that you know you go through these self-contained steps like you're not building a whole application you're just doing a self-contained exercise so you don't need to maintain context over a long period of time and you learn one concept and there's like 300 words that you read an

d like a tiny bit of code that you add it's oh I understand that concept now and just like pedagogically that is a much better way to to to get Concepts into a person's brain when we came out with spel kit we had a bit of a problem though because the old spel tutorial was based on this sort of rubbe Goldberg system of like we had this web worker where we would run roll up inside a web worker and the spel plugin was was part of that system and every time you typed a keystroke we would send the up

dated set of files to that web worker and it would compile your app and that would appear on the right hand side that's great for spelt as a standal l thing but you cannot teach a full stack framework like spel kit in that manner because you need a server and you need a server running inside a web browser like how the hell do you do that at the time that we were thinking about this um we had seen some really interesting work come out of Stack Blitz um stack Blitz is one of these companies that t

hat gives you like an in browser IDE and they developed a technology called web containers and web containers is super cool it's basically node compil to WM running inside a service worker inside your browser it's like crazy mad science stuff and we saw this and we were like yo we could use this to build an interactive spel kit tutorial that runs inside the web browser and so we started talking to the stack blit people and we worked really closely with them over a long period of time and said lo

ok this is what we want to do your technology seems like the solution and they were like great this is like a perfect test use case we're going to support you in every way that we can cool and so we had this really productive partnership where we used their technology and like helped dog food it and and refine it and now when you go to learn. spelt dodev you are running spel kit you're running V like on a node server inside your browser and it means that we can we can teach you all of the concep

ts that go into spell kit all of the like the server side rendering and like all of these things the data loading all of that stuff it just works inside this self-contained context and people don't need to install anything they can just go to this website and start learning and like even for me like I I forget sometimes what the apis look like or I need to refresh my memory and I don't need to like I can just go to this tutorial or if I you know I need to explain something to someone I can just

send them this link and so it's been hugely beneficial um and you know massive kulos to to stack Blitz for for creating this technology and and doing it in such a way that such things are possible and exactly what we hoped would happen is starting to happen angular now has a tutorial very similar [Music] Sim and so I I I hope that this is just the new Norm for how we teach these Concepts like don't make me jump through hoops just let me learn the thing without having to learn all the things I ne

ed in order to learn the thing um and it's it's it's been honestly great it's been very well received um it doesn't work on iPhones at at the moment because we get out of memory errors and I'm not sure how we're going to fix that but uh for most people most of the time it's like a like a really a really cool solution um and I I encourage everyone out there to steal that idea uh it turns out it works pretty well yeah it's great yeah just for like beginners getting stuff running in the terminal ca

n be a hassle right so like if they can just just do it right in the browser uh that's such a a great way for them to learn and to pick up something new so that's fantastic and also make it um make it disposable like if I if I'm following the tutorial and I get a a little bit lost or confused then like don't put me in a situation where I now have something that's slightly incorrect committed to my repo on my just reload the page and you get a blank slate and because they're all short and self-co

ntained like you it doesn't like you can do that you don't you make a mistake five steps ago and you don't even know you did snowballs ex exactly so learn do. Dev sort of encapsulates our philosophy on on pedagogy on like how how you teach these things I actually did a whole talk on this a couple of years ago in Amsterdam um describing like you know is what you can learn from um from the best teachers like what are the one of the lessons that the best teachers can teach us about the best way to

teach people and and we try to apply those in in lefelt dodev um and you know I'm sure there are there are lots of ways in which it could be improved but I'm I'm really happy with how that tend out it's a good step in the right direction I mean I think it's part of why sevelt is consistently rated among the best user experiences on surveys like you're just pretty much always like one or two um do you have like some Secret Sauce other than the tutorials for like like how do you know that um a cer

tain change you put in is just going to be like delightful for users yeah like how how have you maintained that status of a super delightful framework year after year uh I I think there's a couple of things number one is is stay dumb like I you know a lot of a lot of programmers are kind of drawn to complexity have like this kind of sick sadistic relationship with with complexity it's like oh if it's complex then that that means that I'm smart I'm smart or if it's complex then it must be better

than than the simple thing and that's that's not generally true I consider myself a fairly unsophisticated programmer like if I see something that's complex I I just I just knpe out like my brain just doesn't deal well with complexity and so if something starts to get to be like like spidey sense like ah we shouldn't put this in um and I I think that is a sentiment that is shared by other people on this SP team as well um and and the other is like have the gumption to say no to your user base um

frequently because people will often come to you with very reasonable feature request and they'll say wouldn't it be great if the framework could do this like I have this use case and it would be solved by doing this and I I definitely when I was starting out in open source had the Instinct of saying oh yeah I mean that's totally reasonable we should we should do that but the cumulative effect of saying yes to all of these disperate feature requests is that you end up with this sort of Frankens

tein of of like you call it scenario solving or it's like if everyone's throwing toppings on a pizza it starts to get a little weird yes exactly toing on a Petra is a a really good metaphor actually um and over time like I I personally and I think as a team we've got much better at saying you know what I understand why this is important to you but I don't think that as adding this is going to be good for the long-term health of the framework we're just going to like let this seep for a while and

we're going to look at all of the other issues that people are facing and if you do that and if you're patient then very often what you'll find mind is that you come up with a solution that solves multiple use cases at once and and and you do that by just taking a step back and saying what is the what is the deeper problem there don't attack the symptoms attack the cause and like that's really what spel 5 is all about it's like we have spent the last four years looking at these symptoms and thi

nking you know what is the underlying cause and now we're we're fixing the underlying causes and like that's not a thing that you can easily replicate it's not like a piece of advice that that you can give to other open source maintainers but the muscle that you need to develop in order to get to that that place is saying no and it's difficult and it's uncomfortable and like often people be like well I'm not I'm not going to use this thing I'm going to go and use some other thing and that's hard

like oh no I I really care about that person he was but that is the thing that you have to do um in order to have like a long-term hesive Vision that survives you know multiple generations of users because users come and go and that and that's fine um some will stick around for the Long Haul but like ultimately you know people will fixate on very specific minor use cases and over the long term that's not the way to design a framework do you remember any of the names that you almost used instead

of spell like is there like a napkin around your apartment somewhere with all the name ideas jotted on it like framed no there there's there's no I remember the naming session I don't remember the names so this was like a long time ago and we're in the offices at the guardian where I worked at the time and I was like yo I built this this this thing like here's what it does uh I need to come with a name that is available on mpm first of all um but also has all of the right connotations and we sp

ent a lot of time thinking of different could have been white boarded all these that's taken um and like one of the criter I wanted a single syllable word and I I don't remember what the other ideas were but I remember that it was my friend Keenan Davis he has the credit for coming up with the name spel just like threw it out there and free merch for life felt really good immediately like yes that's it I didn't realize at the time that a lot of people don't believe spel is an actual word particu

larly nonnative English speakers but also a lot of native English speakers are like they think that we just made it up and we didn't it is a real word with real connotations it means live and athletic and graceful and all these things that we want to to convey when we're talking about the framework um but people think that it's just like a thing that we made up and and and it's not um so yeah I I wish I could remember maybe uh maybe there was some some gold in there but spel is what we landed on

and I think it's held up pretty well yeah like we we have a we have a brand that I think is pretty well known at this point and and it it all starts with a good name yeah and a good logo good solid color why is is there no spelt kit logo though like you have the same s right M we we do yeah we um that is part of our desire to make the two things feel okay like two halves of the same hole that can be used independently uh I mean you can't use Sal kit without spelt but you can use SP without spel

t kit um and we thought that if we had a separate logo for one thing like designing a good logo is really tough yeah um but for another it's it's just nice if the two things really do feel harmonious and connected and that is that is that is why we did that all right rich thank you so much for having me uh talking with you was fantastic uh I learned a lot and yeah this is a great time yeah thank you this is fun