Rich: A newsroom is a fairly esoteric environment and a lot of ways, but I've found that if you can solve the development requirements of a newsroom, then you've actually solved a lot of development problems that are pretty much universal.
Andrew: Hello, welcome to the DevTools.fm podcast. This is a podcast about developer tools and the people who make them. I'm Andrew and this is my cohost Justin.
Justin: Hi everyone, our guest today is Rich Harris. Rich is, and correct me if I'm wrong, Rich and interactive journalists at the New York times who also somehow finds time to create high quality, tooling and frameworks like Svelte, Rollup, degit in your free time. And what free time you have a rich, is there anything else you'd like to tell our audience about yourself?
Rich: No. I prefer to cultivate an air of mystery... although I, I will correct your pronunciation. It's supposed to be Degit everyone gets that wrong. It's like you're removing the git parts from the git repo.
[00:01:03] Working at the Times
Justin: Cool. Rich, it's honestly such a pleasure. Always really enjoy talking with you. So just to start right off it's not an exaggeration to say that the projects that you've worked on have had a profound impact on the entire, front-end JavaScript ecosystem. How do you find time to invest in this deep work?
When you're you have a job that I'm assuming is quite timely and takes some intense concentration, then I know that you build tools that you use for that job. So how do you find that? Do you all this other stuff?
Rich: Firstly, you're very kind to say those nice things. The reality is I don't find nearly as much time as I would like, or as the projects need as anyone who pays close attention to the development on svelte and svelte kit can probably attest my track record of estimating when things are going to be done is less than stellar. But you're right that the job. Pretty deadline driven. It can be pretty intense at times. And I guess I try to strike a balance by carving out opportunities to work on these projects during work hours, to the extent that they're useful to the projects that I'm working on. And beyond that, it's the usual sort of evenings and weekends sacrifice that I just try to balance with having a normal life But it's tough there, there aren't in a thousand a day.
Justin: Yeah, I feel, yeah. Maybe for people who don't know about what you do. Could you explain more like what your role is at.
Rich: I can. So I'm on the graphics department at the times, which is a team of, I think, about 50 or so people who are all, some combination of journalists and designer and developer. In that mix, you also have people who specialize in things like cartography and the department. It does many things.
It responds to breaking news events that will quickly provide locator maps that tell you where a particular disaster is happening, or it will put together visual explainers of what we know about a current news event. But it will also do these deep dives into stories that are best told visually. Good example would be some of the work that my coworkers did around the Olympics. Doing these really detailed breakdowns with motion capture of how different athletes in different disciplines perfected their craft. And it really spans the gamut from quick, like two hour turnaround projects to these months, long, deep dives. For the last two years, I've mostly been working on our coronavirus tracker, which is a set of pages that show you where a coronavirus cases are in the U S and around the world. More recently I did some some Olympics coverage of my own and in the background I spent a lot of time thinking about our production workflows and how we can be more efficient in the creation of interactive graphics.
Andrew: So going off of that is that where all of your various frameworks spun out of? I don't think most people would hear your job title and what you do and go, "Oh yeah, he's going to create the competitor to Webpack." How did that come about?
Rich: It kind of did come out of the requirements of working in a newsroom. And so the thing that you're refering to roll up is something that I started while I was working at my previous job at the guardian. And it was essentially because the tools that were dominant at the time, just frankly, didn't do a great job of delivering efficient code. I think Browserify was the market leader at the time. And browser five was a revolution when it came out, it enabled things that previously weren't possible, but it had a cost to doing so. And the cost was paid in terms of extra bytes for your bundle and extra bytes for each module of your code base.
So if you are following best practices and writing modular code, then you paid a penalty for that. A few years ago, ES modules were starting to become a thing and it seemed like there was an opportunity to rethink how bundlers worked based on the new native module syntax that, that had just been Standardized or it was maybe in the process of becoming standardized. That was motivated very much by the fact that when you're writing code in a newsroom environment, you're writing apps that are going to sit on a page that you don't control. And your JavaScript is the last thing that gets to load. We've already got ads and analytics and reader's comments, and like all of these things that are contributing to the weight of the page. And the last thing that you want to have on top of that is for your code to be unnecessarily large and slow to execute. It was very much motivated by the needs of producing stuff that was as small as possible for that context.
Andrew: Yeah. I heard on another podcast where the naming came from and I find it like vastly interesting that you make something for a newspaper and chose to call it roll-up. So I just want to shout that out as some of the best naming I've seen.
Rich: Yeah, I went through a few different potential names but the sort of Image of paper boy standing on the street corner saying roll up. They were all about it. Just seemed to make sense.
Justin: So my partner works at the New York times on the engineering side. And I hear that there's a pretty fundamental divide between like engineering, generally New York times and the newsroom, the journalism side of the house. It's like they try to keep things pretty separated out purposefully.
So you've mentioned that you spent a lot of time thinking about like how to ship production assets as you're building these visual interactions, you and your team. Are there any, like tensions between you and the engineering organization that crops up given that you sort of like New York times broadly is like a react shop and you have different needs of course, but is that something crops up from time to time.
Rich: Not really no. That, that cultural divide does exist. It's a sort of industry wide thing. The newsroom tends to be distinct from the rest of the company largely to allow of, to prevent commercial pressures from leaking into how we think about coverage. I don't know that it's as sacrosanct as that, it. Sounds in the context of a newsroom versus engineering, but it does exist. And I think as a result of that, they've always been very careful to make sure that we have this sandpit in which we can do whatever we like. So when we're building interactive graphics that go in articles, we're not thinking about how it interacts with the react app that, and nytimes.com consists of. The idea is that in the future, we could completely. Rethink how and times is built and all of the content that we've written for it. We continue to work because we're not making any assumptions about the environment beyond this is a webpage or indeed an HTML document that is being viewed in the web view of a native app. So because of that, it's really not something that we generally think about at all. There are occasionally moments when like the abstraction leaks, like we've had problems in the past with. The hydration step, the react, hydration, step new king things that are already on the page. And so there are some pretty complex workarounds that allow the stuff that we've got on the page, not to get clobbered by the hydration. But by and large it's not something that we really think about.
Andrew: Speaking of the Olympics and all the different visualization work that you've done, what have you enjoyed building the most? I don't know the exhaustive list of what you've worked on, but can you point to one example that you found really enjoyable to build?
Rich: Yeah. The most recent project that I did is probably the most fun I've had for a long time. It was a project around the Olympics. Essentially the backstory here is that news organizations in the U S are not permitted to use any video footage from the games at all, because the rights are exclusively held by NBC. And yet we want to be able to tell people the results of the races, obviously, because people rely on news organizations like us to know who just won the hundred meters. And so we have a choice. We can either describe what happened or we can find a new way to show it. And what we settled on was a kind of a data visualization, which sort of looks like the races happening. In animated form in the context of a video that appears inside the tweet or inside an Instagram story. And so what we built was an app for generating these videos based on data that came from the live feed from the Olympics. So we would get this big blob of JSON and turn it into a video. Ideally in the space of five minutes or so we would have these videos ready to tweet out.
So almost real time we're showing what happened without being able to show what happened. And it was tremendous fun because the number of interesting engineering challenges that you have to solve to be able to do something like that is quite long. And we got to use some new toys, like we used FFMpeg WASM for the first time, which is a way of running FFmpeg to generate videos inside a browser, all client side, which means that you can see the progress of how your video is rendering. And then you can immediately hit a button and it gets sent to some backend somewhere and is ready for publication. Got to play a lot with three JS as well, which has tremendous fun. And just like all the design and animation questions that fall out of that. Like how do we make it look like these little miniature people are doing breaststroke versus butterfly and front crawl versus back crawl? It was great, yeah I had a blast
Andrew: so with a project like that, are there like super tight time constraints around it? Do you know for months? Yeah. We're going to be doing this Olympics thing and you prepare for it or it's like, well, limbics is two weeks out sprint. Sprint's time to go. Let's build it.
Rich: so events like the Olympics, like we obviously know that they're coming months in advance. And it's similar things like elections where they're on our calendar for... At the start of the year, we know that it's a thing that we're going to have to invest time. And inevitably we never start on these things until too late, because there's always stuff going on.
But in this case, I think we started about two and a half months before the Olympics. And we really got into gear like maybe a couple of weeks after that. So I think we spent maybe two very intense months preparing for that. And then the two weeks of the games themselves, obviously we were up at all hours of the day because everything's happening in Japanese time. So we're up at anti-social hours, like Manning the app that we've built and generating these videos and tweeting them out. So it didn't, it's not like it took us by surprise, but there's never as much time as you would like to have for things like these, even when you know that they're coming.
[00:11:40] Svelte
Justin: So, you and the folks who've been working on svelte, semi-recently I guess maybe has it been a few months now? Which is a replacement for Sapper, a static site generator plus I think like similar, if people are familiar with Next.js or Nuxt, it like fills a similar sort of space.
I had heard in places that you were using that at the times for some projects. Is that true? Have you been dogfooding that?
Rich: We've dog food at it extensively. The coronavirus tracker that I described earlier it's this page that has, or this app that has a page for. The U S and for every state in the U S for every county in the U S plus selected countries and a few other non geographical pages. And initially that was built with the same set of tools that we use for all of our other graphics.
When we decided that we wanted to start publishing those county pages, we just realized that we weren't going to be able to publish thousands of pages multiple times a day with new data. And I was having the, I was tasked. Figuring out how we were going to build this in a more scalable fashion at the time, it felt it was very early in its development, but it already seemed like the thing that met most of our requirements, it's able to function as a static site generator, which we need because we're generating HTML and then shoving it into a CMS.
Would we don't have any servers anywhere. A lot of the app was already built using svelte components, so we could reuse a lot of our existing. And know, so happens that there's a guy on the team who is building both the tracker and the framework. So if anything breaks, then we can just yell at him. So for all of these reasons we settled on svelte-kit, even though it was a pretty early project at that stage. Obviously, we ran into some teething problems as you would with any new project, but on the whole, it was a really good dog feeding experience. And the things that we learned building that fed back into the framework and made it more flexible and more open. We then reused it for the Olympics project that I just described, the app that generates those videos.
It is a svelte-kit app. Unbeknownst to me some coworkers elsewhere in the newsroom were building a separate Olympics app with svelte-kit. And I, found out well into the development of that when they ran into a couple of issues and sought help. But yes, I think those three apps, probably the only time that it's been used for anything so far at the times, but our experience has been fairly positive.
So hopefully we'll use it again for other things.
Andrew: svelte itself seen a lot of adoption at the times, or has it been mostly outside of your workplace where it's gained its most traction?
Rich: for a long time, it was very much outside. Know I, wasn't interested in proselytizing it and convincing people to stop using the tools that they were already familiar with. But it happened organically over time. People would start using it because like maybe we had worked together on a project and they'd become introduced to svelte that way or that. See me talking about it on Twitter and got curious. Yeah. Gradually it's become a fairly major part of how the graphics department works. And that's actually been really gratifying because the people I work with are journalists and journalists are by nature, very skeptical people generally.
Most people aren't writing JavaScript because they love it. They're writing JavaScript. Unfortunately, we need to write JavaScript to do the kind of work that we do. And so when people say, I hate learning new things, but I decided to learn this one new thing and I love it. That's really nice to hear. And so it is now pretty core too, how a lot of the work gets done. But it's by no means like mandated, there are plenty of people in the department who still haven't touchedit and probably never will will and that's totally fine. Everyone can use the tools that they're most comfortable with.
Justin: A lot of fun watching spelt grow the sort of recent, what was it stack overflow? Who does the normal, like web development server? Or not web development, but the big survey, so svelte's gaining a lot of traction, at least from reported results on that, which has to be also very gratifying.
Rich: it is, gratifying. The state of JS survey came out at the start of the year and spelt was listed as the framework that had the most satisfaction. And then the stack overflow thing was more recent and it had a similar finding. I do take those with a big grain of salt, honestly. Because the kind of people who respond to those surveys are far from necessarily representative of the developer population as a whole.
And you've also got to factor in the fact that the people who are using svelte at the moment are generally doing so because they're in a position to choose that tools. If it becomes more popular and. Companies are choosing to use svelte and then people who would not otherwise have chosen sell are being forced to work on it.
Then their satisfaction is probably not going to be as high. So yes, we are doing very well at the moment in terms of the surveys that people see on Twitter. But I'm trying to not let that go to our heads, to much.
Justin: Sure. Sure.
Andrew: So when you build these projects, do you intend for them to be used at the times, or are you just making them to scratch your own itch? And they just happen to catch fire in the wild?
Rich: I mean, it's always to scratch my own itch. It so happens that my itches are generally work related. I'm building stuff at work and the tool that I want doesn't yet exist. So, you know, roll up your sleeves. And what I've generally found is that a lot of other people are itchy in the same places that I am. So that sounded gross. A lot of people have the same needs that the, that we do and A newsroom is a fairly esoteric environment and a lot of ways, but I've found that if you can solve the development requirements of a newsroom, then you've actually solved a lot of development problems that are pretty much universal. Our feedback loops are very tight and our deadlines are very strict. And if you can create tools that succeed in that environment. The chances are it's gonna, it's going to succeed elsewhere. And I think we've seen that with with other things that are come out of newsrooms, like Django and underscore and D3 and backbone. These are all newsroom products that have since become widely adopted in the industry.
Andrew: Oh, wow. I didn't know. All those different tools had come out of newsrooms.
[00:18:16] Building the Future of Web
Andrew: Funding open source is hard and building a community is even harder with your most successful projects. How do you keep them going? Do you just like hope that your Twitter followers will be like, oh, this is awesome shit. And then start helping.
Or do you like look for funding
Rich: I always dread the funding question because I have so many conflicting feelings about funding and open source. And the truth is. We've just hidden from that whole question. Svelte those have an OpenCollective and lots of people generously donate to it. And like we've always talked about what that funding would enable us to do, but thus far, we've only really used that funding to meet the expenses of hosting the svelte website and things like that. The reality is the money doesn't translate directly into well-maintained projects. There's a lot more to it than that. And the people who work on svelte we're a pretty tight knit team. We all work on it because we enjoy the project. We enjoy the community, we enjoy each other's company. No one's working on it for money directly. And so we've always just been very uncomfortable whenever the subject. And I know we need to get over that and we need to figure out a way to translate people's generosity in terms of funding into a more regular release cadence. But so far that has alluded us. It has been a little bit better in the case of roll-up I'm not directly involved in violent maintenance anymore, but I'm still part of that world and the money that has gone into the role at open collective has directly funded a lot of the work that has kept that project going. That is, something that is really nice to see because roll-up continues to play a pretty big role in the ecosystem. Like a lot of people probably don't fully realize just how much stuff is built on top of roll-up. It's sort of the secret sauce behind a lot of different projects like Vite for example Vite is having a moment in the sun right now.
It's a wonderful tool. It's the thing that enables svelte-kit, but the thing underneath Vite is largely roll up. I don't know if that would be the case if we hadn't managed to get that, that funding. But to answer the question about whether that's something that I go into a project thinking about absolutely not.
And the least far-sighted person and opensource. I just. I have a thing that I want to make and I make it, and then I'm like, oh, maybe someone else would find this useful. I throw it off and GitHub. And then I realize a few months down the line that I've committed myself to maintaining this thing. And if I'm lucky, then the community will come along and help. And that has happened many times. And I'm always extremely grateful when that happens. But it's not because of any masterful planning or strategy on my part whatsoever. It's because we happen to be in a very generous and public spirited community.
Justin: Well, I've got a question for you then that might be hard to answer because I really am curious what you think about what comes after svelte kit or like what the sort of continuation of this ecosystem might look like. So there's a lot of efforts spent on making svelte like really solid and it's great.
It's a pretty amazing tool for building, especially interactive UI today. And then spelt kit is continuing to evolve. It's getting better. Also just very solid sort of platform for building sites is like, do you see anything else coming into this ecosystem to add to it, or is it just like the improvement of these tools?
Rich: The so much work to do on svelte-kit and svelte already. I'm hopeful that we're gonna be able to get a stable version of svelte-kit out fairly soon, but even after that, there's a bunch of things that we have in mind that will probably be post 1.0 and then svelte itself we have a pretty large backlog of issues at this point.
But even once we've got a better control of that. Once we get some breathing room after the launch has svelte kit, we have this very long wishlist and a very long roadmap of, what's going to be in svelte four and beyond. I don't want to talk about that stuff too much because I don't want to make promises that we end up not keeping or at least not keeping for awhile, but there's so much work.
That's going to keep us occupied that I'm not really thinking too deeply about what comes next. The one thing that I am quite excited about at the moment is spelt three, which is the library that we used on the Olympics project to render the little blue people that were running around our little Lego track. That was tremendous fun to build.
And I think it makes the process of working with 3d scenes much easier. It's is to three JS as svelte itself is to the DOM in a way. Yeah. I love working with three JS, but it's a lot easier if you have a component model around it. And so hopefully in the fairly near future, I'm going to be able to just get that over over the line and open source it at the moment.
It doesn't have any documentation. It doesn't have any tests, any of that stuff. But it is a functional library. And so it's things like that. I think it's fleshing out that ecosystem with all of the different component layers that you expect to find in a mature ecosystem. And we're getting there.
A lot of that stuff already exists, but there's always more to do. Our work is never finished.
Justin: Yeah, that's awesome. But even as early as svelte kit is it's already. Pretty solid. There's a lot of great ideas in there too. I particularly like, just like things like direct flags for turning on hydration or turning off hydration or pre rendering or not pre rendering. Server-side rendering, not server-side like that.
That kind of stuff is simple, but the touches like it's nice.
Rich: ah, that's good to hear. Thank you. We started that journey back in 2017 when we started building Sapper, which was our first attempt at a next JS for svelte. And we learnt a lot in the process of building that and that the environment. At the same time, this has been this big shift towards serverless environments and things like CloudFare workers and svelte-kit is really us saying it's more work to try and take Sapper and modernize it than it would be to just start again with with a new code base.
And it's, I think that decision has paid off. I think we've got something that people are really gonna enjoy once it goes stable.
Justin: There was a question that I had about svelte kit in particular, actually. And this is interesting language thing. So I svelte-kit when you use it for static site generation, it refers to it as pre rendering, which is typically in the times before, in the before times, that was like, what we called Hey, want a spa?
And we want to like, have some HTML on the page, like first. So there's a lot of pre rendering services out there that provided that The evolution of language is interesting. I think next year, as leads as has really shifted a lot of Mindshare and how they refer to static site generation versus I don't know, they have incremental regeneration and a bunch of other stuff.
How do you think about naming those sorts of features and like, how did that come out? Hey, we want to call this pre rendering, which it functionally is, but just curious.
Rich: Yeah it's a mishmash of looking around and seeing what other people have decided to call things and taking the best ideas and otherwise to sort of going with the dominant convention SSR versus SSD. Versus an SBA versus MPA, all of that stuff. It is needlessly confusing and we desperately need some better TLAs to describe this stuff, because even the fact that the SS in SSR and SSG don't mean the same thing. Like how is anyone supposed to come into this and make sense of it?
I got into a conversation recently on Twitter about the relative merits of multi page apps versus single page apps. And after a while, people who weren't close to the conversation, but were getting snippets of it out of context, thought that I was talking about something like a an spa from the early 2010s where you would start with a blank page and then everything gets rendered with JavaScript. And I don't think people are really doing that anymore, by and large, I know some people are, but no one's recommending that you build apps that way, but the conversations that we're having on taking into account the current state of the art and the current recommendations and how we build sites, and that is to the detriment of our collective progress because we get so hung up on the sort of tribalism of these different approaches. That we're unable to really get at the new ones of what techniques actually give users the best experience. And it's a shame because we're all trying to push in the same direction, but we're all talking past each other because of these stupid three-letter acronyms that don't make any sense. But I don't have a better one yet. I'm trying to think of some better acronyms that can more adequately describe what projects like svelte kit are trying to do, but it's a work in progress.
Andrew: Adding another acronym always helps.
Rich: yeah. It's that XKCD comic
the 14 existing standards. I dunno, maybe we just stop using acronyms. Maybe we just start saying what things actually are.
Justin: Yeah, Yeah. That's like what jumped out to me about the pre rendering? It's a small thing, but it's like, oh yeah, well...
Rich: yeah, I mean, we definitely bike shed at that one a little bit. The one that we haven't managed to figure out is the word context. Context is one of these words that comes up in development in so many different contexts. And it always means something subtly different. And it's a very useful word, but if you have too many different things that are called context, and they're not the exact same concept, then you're going to end up confusing people.
And so far, I think we have, I think we have maybe three different things that are called context in either svelte or svelte kit. And we need to get that down to 2 or 1. And so. Far, we haven't been able to naming stuff.
Andrew: Definitely I'm one of the hardest problems in programming right there!. So speaking of Twitter arguments I've seen you, I've seen you advocate for the web platform a lot of the time. What comes to mind is web components. I've seen you in many, a web components argument. But what part of the future of the web are you most excited about?
It might not be web components, but where do you see this all going?
Rich: It's definitely not where components I can tell you that. I wish I had a good answer for you that the truth is I'm not all that optimistic about the web. I'm actually quite fearful for the web's future. I think we have reached a point where the platforms complexity is getting out of hand. And the fact that the different browser vendors don't see eye to eye on a lot of these things. And there seems to be a lot of acrimony between the different browser vendors that is actively hampering harmonious standards work from proceeding is bad for all of us. And it's worse when you have commercial interests that are at odds with the needs of the web. I wrote recently about the, I don't know if you remember the alert debacle where Chrome removed alert and confirm and prompt from cross origin I frames, but also confirmed that they plan to do so for non cross origin, I frames they just want to remove those APIs from the web platform. I wrote about how I'm very concerned that The people who are deciding what form the web is going to take. Aren't necessarily the people who should be stewarding the platform. The web is something that belongs to all of us. And yet the only people who have any meaningful say over the direction that it evolves in are browser vendors. And realistically there's only two browser vendors that matter and those two vendors are at loggerheads. And so truthfully I'm a little despondent about about the future of the web. I hope that I'm unduly pessimistic. I hope that it's not as bad as I've feared but it's hard to see a really obvious path out of the mess that we've found ourselves in recently. I guess if I was a little less cynical. I would talk about web three being this shining beacon of hope. But for me, it's so difficult to separate all of these ideas about like privacy and decentralization and ownership of your data and all of these other things to separate that from the crypto bullshit Ponzi stuff is really difficult. And so even that, which, the web three stuff philosophically, it really speaks to me, but it seems to have been conflated with just, the worst thing that technology has delivered in the last several years. And I just don't see way out of it.
Andrew: Yeah. And it's unfortunate that crypto bros exists too. Cause it's just there's all this cool technology and decentralized identity and the metaverse are all super cool ideas that could make the web such a new and interesting place. But everybody's bogged down with the fact that, oh, this guy is trying to sell me some JPEGs and it's like, ah,
Rich: Yeah. Yeah. I guarantee that people are going to listen to this episode and yell at us on twitter. Precisely because conversation that we're having right now. And it's so, so done.
Justin: We welcome your comments.
Andrew: yeah. We post clips to a TikTok in our most our most viewed TikTok is where I said something about NFTs and like the amount of people that both call me stupid and are like, oh, this guy knows it and crypto is bullshit. Just inundated with those. So we'll get, probably get a few for this too.
Justin: How to start a flame war, step one.
Andrew: Yeah. You mentioned crypto.
Justin: Cool. Shall we go to tool tips?
[00:32:08] Tooltips
Andrew: The first tool tip I'm going to talk about is popper JS. I've used this little library countless times and just countless different components that I've had to create. What popper JS does is it does all that hairy math of calculating, where it should place a div in relation to another div when something happens.
So a common use case is a tool tip or a context menu, or anything about that. It's really nice. I just usually use the base library. I don't find the need for any of the library specific wrappers around it, but it's really good. At my old job at Intuit, we were starting to make our own popper JS, but then eventually realized there's just so many edge cases.
And so many things you'd want to make it, do that. We should just rely on what the communities come up with. And I can't recomme it enough.
Justin: Yep. It's pretty solid.
Rich: Yeah. And have you used it, but it looks cool.
Justin: There is this project called N API R S it is a rust bridge for node. Generally, if you want to write a native module To interact with the no JS app. You can do that using this specifically though this is a pull request to that repo it's 6 96. I saw it retweeted by Jared Palmer but it provides this macro that makes a memory mapping from JavaScript to rust, like pretty seamless. So previously you'd have a lot of boiler plate to say, Hey, I wanna write a function and rust and make it compatible with JavaScript. And you have to do a lot of type marshaling and a bunch of other stuff, but they're adding this macro that makes it trivial to do this cross definition authoring of rust code that you want to run from node. So, anyway if you're interested in rust if you're interested in writing native modules for node definitely take this library out once this once this PR lands, I imagine it'll change a lot for the better, which is pretty cool, especially giving now that I'm doing a lot of rust
Rich: I'm very upset because this is one less reason that I have for not learning rust.
I have to learn rust now!
Andrew: Yeah, everything's moving to rust. I just saw a tweet from Sebastian on Rome, and they're actually rewriting it all and rust... so they weren't lying. When they said Rome, wasn't built in a day. It's going to take a little bit longer now.
Justin: Yeah, it's interesting. I just, so I'm starting at a company called oxide on Monday and they are a rust shop entirely. So it is a foregone conclusion that I dive deeply into this world.
Andrew: Yeah, you got to put on your rustacian hat.
Justin: I think oxide is a play on that. Right?
Andrew: Oh, I don't. I'm not sure many people will get that reference.
Rich: Yeah. This tool has been around a little while. Actually, and I've been using it for a while, but. I don't think it gets enough love. It's essentially a to-do list, but a hierarchical to-do list it's called WorkFlowy and it allows you to structure your thoughts or your tasks and kind of the same way that you would fill in a Google doc.
But it's also very easy to convert that into the hierarchical list because tasks are inherently hierarchical and you can also add tags and things like that. It's just a really easy way to structure your thoughts without having the structure imposed upon you. And you can share a subtree of your task list with other people and you can work on it collaboratively, and I've just found it to be a really great product.
Justin: Yeah, workflowy is awesome. So it's an in inliner. And like each bullet point can be its own page. This is I think, a large inspiration for Rome research, which basically is WorkFlowy except you can do backlinks. I don't know if workflowy added that functionality, but I think that's basically the biggest difference between the two.
This is the back link. So Rome does other stuff like special embeds and stuff now.
Rich: Oh, that does make me want to try Rome, which I haven't.
Justin: Rome's really interesting. So I'm pretty interested in the tools for thought space, which this firmly falls into. But I used WorkFlowy many years ago and really enjoyed the process of doing so. And definitely when I started using Rome, this is exactly the thing I thought off.
It just felt exactly like WorkFlowy. So like when you hit Rome, you have a. Page for your current day and you could do like a workflow, like interface and every day that passes, you can scroll infinite, scroll through all your days of notes or whatever, but then you have this backlinking ability.
You don't do double square brackets and it automatically creates a link. And if you type in something that doesn't exist, it just creates a page for it. And you're like, hit it. And it goes to that page. And again, it's just a, it's also a bullet point, it's a WorkFlowy style document. All of these in liners are really good. There's a ton of them. There's another, open-source one called a log sec log seq, I think which is but research-esque but open source. Andrew and I use obsidian a lot, which is different. It's not an in liner, it's just a markdown tool, but as like backlinking, and you can do the hierarchical things with the bullet points.
It's different. But yeah, this is a fun space.
Andrew: Okay. My last tool tip for the day. The image is broken because it's not quite public yet. It's a reacts library that you're gonna look at it and go, why the hell would I want to do that?. It is called react-json-reconciler. And it's a reconciler for JSON and react.
What does that mean? It means that you can write react trees that serialized to JSON and then then you have JSON. You might ask yourself why the hell would I want to do that? So what we had at Intuit was a way for back-end devs to create whole entire flows out of JSON. And we had a front end library called the player that would play that JSON.
But one thing that we came to learn over the years of supporting it was that nobody likes to write a whole their stuff in JSON. Nobody wants to be a JSON developer. What this library allows you to do, and it's written by one of the guys that's still on that team at Intuit.
He was also on this podcast. Adam Dierkens.. It allows you to author that JSON just like you would react. So you can have a bunch of functional components that return this JSON reconciler JSX and then even use hooks for like state and effects. And then in the end, when you've rendered everything, you get the JSON that we then feed into the front end.
So you might look at it as read me and go, why the hell would I want that? Well, there's why the hell
Big shout out to that team. They have some big stuff coming out this year. And I think this is just the tip of it.
Justin: This reminds me, there was an article by this app called judo. It's their site as do dot.app. And I'll put the, I'll put the article in the show notes and they. Talk about this thing called server driven UI, which is highly confusing for what they really mean. They really mean just having JSON payloads that sort of drive native UI experiences.
So essentially during this but mostly I think targeting like mobile apps. So it's like you build out your sort of like components and your native components in your mobile apps and just like send it big chase on payloads and that like constructs the views and everything. I think Airbnb and Lyft and some others are doing this broadly.
So this would be an interesting way to, to build that sort of product experience. If you felt like getting pretty complicated and fancy.
Andrew: Yeah to make it maybe a more understandable example is if you've ever heard of the library, JSONette this would just be a way to render JSONette content like you would a normal react components.
Justin: JSONette had is now JSONelle after the original sort of creator of that just disappeared, not sure what happened to him or her.
Andrew: Sometimes maintenances is a little much. I can feel for that guy.
Justin: My last tool tip for the day is a state management library. I really don't like state management generally. It's like oftentimes the biggest source of complexity. Rich, I have to give you. And all this svelte folks, tremendous props for svelte store because it is in my mind, like the golden standard of doing state management.
It has an excellent story around that. I feel like VUE over the years has had a very consistent story around state management. React has always been like the wild west. You just got to figure shit out. It's been rare that I get in a react app and I'm like, oh wow. This is really well done.
I think you've done a great thing here. It's always like, holy shit. What happened anyway? This library is a tiny, tiny state management library called MUTEK. I think that's how it's pronounced. M U T I K a it's by Jerry Palmer. It's 496 bytes or something. Not counting the immer library, which it pulls in.
It actually uses an upcoming react API. Which currently it's called useMutableSource right now, but it's going to be changed to something else before react 18 releases, I believe. But it's trivial. There's literally one file to this. It's maybe 200 lines of source. Maybe not even
Andrew: 97 lines of source.
Justin: 97. Yeah, you can read it. You can understand it. It's just really, really nice. I was I've got a, I've got a terminal based solitary game. And I use that to play with a state management, like things and react. I used react ink to render it out. And I just really haven't found something that like just is nice and simple.
And then I ran across this and it's good. This isn't something that Jared's like doing a lot of active work on. I think this was mostly a proof of concept, but it's excellent. The API, the react API that this is built on the react team recently improving and they hope to ship that. And basically their hope is that any state management solutions that have external state, especially if you if you use streams or something, if the state lives globally and you can mutate it outside of your react app, they want you to use this new API to make it simpler to deal with edge cases around concurrent rendering and everything.
But evidently it's also a really good way to make a really simple state management API.
Rich: So the reason you said that this was based on immger which is a incredible tool. Is that the main difference between immer and this, that this is using that upcoming API?
Justin: So this uses immer
Rich: Oh, it actually uses immer, I see.
Justin: It does use immer yes. Yes. It's got a few influences for like it's API shape. Ultimately. You have a function called create store and you just pass it in initial state or whatever initial state of your store. And that gives you this object that you can reference globally, like anywhere you want.
And it has a, basically just this one has a few functions, but it has like this. You can do store dot mutate, and then just. Inside of that's like an immer produced function. So you can just mutate your state or whatever. And then it'll update the state of the world. And it has a few react hooks for integrating it with your with your app.
But it's enormously simple, and I am having a blast with it.
Andrew: If I'm not mistaken. This hook was also created to support things like Redux. So they've been working heavily with all of those people in the state management community to get this into a usable state. Cause I was looking at upgrading to react 17 for our electron app, but when you have thousands of lines of Redux code, that's a quite a big barrier.
So I'm excited to see those API is finally land so we can look at upgrading.
Justin: Yeah I have mixed feelings about. Reacts sort of evolution. They're solving the UI problems in a very sophisticated and very complex way. Because of that, they have to provide sort of APIs for libraries to do the sort of right thing with concurrent rendering and suspense and everything. it like Building things and user land to interact with react can be really, really hard. I don't really know how I feel about that broadly, but I am glad that they're doing the extra work to provide these APIs, to make it possible and give you a better sort of path forward. So I'm excited about that.
But I will say, rich, I do still appreciate your approach because ultimately moving a lot of this complexity out of runtime into a compiler, trying to simplify things where you can, I approve of that, which is no no dis on the react team or any of the amazing work that they've done, or anybody that uses react to
Rich: I think it speaks to the fact that there's room for both projects to coexist peacefully. They have very different philosophies in a lot of ways. And I will freely acknowledge that react is solving problems at the moment that svelte doesn't really have an opinion on because react is is being used to build facebook. Svelte it is not, they have encountered problems using react and they are coming up with some very clever solutions to those problems. And I think that the work they're doing is absolutely inspirational, but I also question the need for a lot of it and a lot of contexts. I think it's very important that people have alternatives to react that are a little bit easier to fit around. Where you don't need to use these fairly complex APIs. And so I think that there's going to be a lot of space for evolution in all of these projects for some time to come.
Andrew: Now for our most important tool tip of the day Rich's pasta maker.
Rich: Yeah. I might misunderstood w hat you meant when you said that I had suggest some tools that I'm excited about. As soon as I, as soon as we finished recording this podcast, we're going to go and make some fresh pasta. If you enjoy eating pasta, which I know a lot of people do just buy yourself a pasta maker. You will never eat box pasta ever again. It's it will change everything.
Andrew: Are you just talking about like the Rollie machine thing?
Rich: Yeah, I've got one of the, one of the very simple ones where it's got a vice and you affects it to a kitchen surface. And then you just feed though through it a few times until it flattens out and you've got this long remnant of pasta, and then you just put it through the second one that turns into fettuccine or whatever you want. It's very straightforward and actually kind of therapeutic. So I I recommend that for anyone who eats pasta.
Justin: Yeah, plus one.
Andrew: That's it for this week's episode of dev tools, FM. Thanks for coming on rich. This was a lot of fun.
Rich: Thanks for having me!
Justin: Yeah, I really appreciate it.
Andrew: Be sure to follow us on YouTube and wherever you consume your podcasts. Thanks for listening.