FeatureBoard with Jake Ginnivan
Jake Ginnivan discusses building news platforms with CDNs, his feature toggling product Feature Board, and TypeScript tooling in the Jamstack ecosystem.
Episode Description
Jake Ginnivan discusses building news platforms with CDNs, his feature toggling product Feature Board, and TypeScript tooling in the Jamstack ecosystem.
Episode Summary
Jake Ginnivan joins the show to share his experience building a large-scale digital news platform in Australia, where his team created their own server-side rendering infrastructure predating tools like Next.js and Remix. He explains how they handled challenges like AMP support through multiple render targets and achieved high CDN cache hit rates in the 90s, effectively getting the same benefits as static sites while serving millions of articles on demand. The conversation then shifts to Feature Board, Jake's SaaS product for managing feature toggles, which takes a novel approach by targeting audience categories (like user plans or roles) rather than individual users. This design choice means Feature Board doesn't need to store any user PII and works naturally with CDN caching, since audience segments become part of the cache key instead of user IDs. Jake walks through the SDK architecture across JavaScript, Node, and React, and explains how Feature Board separates the concern of mapping users to groups from the concern of serving feature values. The discussion wraps with thoughts on TypeScript adoption, the challenge of maintaining type definitions, and tooling like TSX and tsup that simplify the developer experience around CommonJS and ESM transitions.
Chapters
00:00:00 - Building a News Platform Before Jamstack Frameworks Existed
Jake Ginnivan introduces himself and his background transitioning from .NET line-of-business applications to building a digital platform for an Australian news organization. He describes how the move to media forced him to learn about CDNs, cost control, and serving anonymous traffic at scale, challenges that naturally led to Jamstack-like approaches before the term was widely used.
The conversation touches on how news organizations operate differently from startups and agencies, often relying on bespoke CMSs and proprietary content pipelines rather than off-the-shelf solutions like Contentful. Jake explains how his team built Project Watchtower, their own server-side rendering framework similar to what Remix later became, including custom data-loading middleware that walked a JSON-defined page structure to prefetch data before rendering.
00:03:04 - AMP Support, Server-Side Rendering, and CDN Caching Strategies
Jake details how his team handled AMP by creating multiple render targets within their React-based infrastructure, allowing components to output web, AMP, or RSS versions depending on context. This approach let them maintain shared page structures while swapping in platform-specific component implementations as needed, avoiding a full rebuild for each target.
The discussion evolves into whether server-side rendered content served through CDNs qualifies as Jamstack. Jake argues that as long as the CDN handles the majority of requests with high cache hit rates, the user experience mirrors that of static sites. He contrasts this with tools like Gatsby, which require rebuilding all pages, a non-starter when you have a long tail of millions of news articles where only a fraction receives regular traffic.
00:08:44 - Feature Board's Approach to Feature Toggles and Audience Targeting
Christopher introduces the topic of feature toggles, noting how something that seems like a simple boolean quickly becomes a complex management problem. Jake explains the origin of Feature Board, which grew from his frustration with A/B testing in CDN-heavy environments where user-specific logic conflicts with caching. Traditional feature toggle services hash user IDs to assign buckets, but this approach breaks down when CDN caching is critical.
Feature Board's key innovation is targeting audience categories like plans, roles, or traffic sources rather than individual users. By making these broad segments part of the cache key instead of user IDs, the system preserves CDN efficiency while still delivering personalized feature values. Jake describes how this separation means Feature Board never needs to handle PII, as all user identity stays within the customer's own systems.
00:16:33 - SDK Architecture and Separating User Mapping from Feature Values
Christopher and Anthony dig into how Feature Board connects users to audience buckets in practice. Jake clarifies that the application itself, not Feature Board, is responsible for knowing who the user is and what plan they're on. He uses Auth0 as an example, where plan changes are pushed into user metadata and appear as JWT claims that can be extracted at the CDN layer.
The hosts explore the SDK structure across JavaScript, Node, and React. Jake explains that the Node SDK connects to Feature Board's service to fetch toggle configurations, then calculates values inline for a given audience set without additional API calls. The client and server share the same TypeScript interface, with the React SDK adding hooks on top. This design keeps the feature evaluation fast and decoupled from network requests during user interactions.
00:24:42 - TypeScript Tooling, Type Authorship, and the Future of Feature Board
The conversation shifts to TypeScript, where Jake shares his experience rewriting types for Glamorous 11, which cut compile times in half. He advocates for running the TypeScript compiler in watch mode separately from the rest of the toolchain, since modern tools like esbuild and Vite strip types without checking them, and type checking fundamentally conflicts with single-file transformation pipelines.
The group discusses whether library authors should maintain their own types or rely on DefinitelyTyped, with Jake noting that DefinitelyTyped works better when maintainers aren't deeply invested in the TypeScript ecosystem. The episode closes with Jake sharing his roadmap for Feature Board: he's seeking roughly a dozen early adopters willing to try the product's audience-based approach and provide feedback as it moves beyond beta. The final timestamp is 00:31:43.
Transcript
00:00:00 - Jake Ginnivan
Yeah, I'm happy to just crack on.
00:00:12 - Christopher Burns
Welcome to the show. Jake, you are the creator of Feature Board, a SaaS app to help you manage your feature toggles. I am super interested to find out more. How are you?
00:00:25 - Jake Ginnivan
Yeah, really good. Looking forward to chatting about Feature Board and just Jamstack in general. It's a pretty interesting area, and I've spent a fair bit of the last couple of years solving a lot of the same problems.
00:00:35 - Christopher Burns
When you say you've been in the industry for a few years in Jamstack, I feel like you'll probably have hit all the same pain points as me. Like Gatsby 2 is awesome, Gatsby is terrible, Next.js is awesome. It's just all awesome.
00:00:49 - Jake Ginnivan
I have been at a news organization, Australian news, for the last couple of years, building their digital online platform. We started that about five years ago, and that was all server side rendered using CDNs and a lot of the same approaches, and none of those things existed. So we built our own.
00:01:08 - Anthony Campolo
Jamstack is almost a force of nature. Whether you realize it's a thing or not, you kind of end up falling into it. I'm curious, what was the origin of you trying out these techniques, how you kind of found your way to them?
00:01:22 - Jake Ginnivan
I got started more in a .NET space building line of business applications. So the move across to a media company was quite a big jump. I think the problems you solve are quite different. Rather than having an application that is very interactive and has no need for highly available, distributed CDNs or anything like that, a news site needs to be hit by a lot of people. It's mostly anonymous traffic. It needs to be fast. In more recent times, Core Web Vitals and that sort of stuff is making these approaches really important. But I think it was just a move into media that really forced me to learn about CDNs and how to offload as much of your traffic away from your origin servers to control costs and improve performance as you possibly can.
00:02:12 - Christopher Burns
One of the big things that I wonder, and I think you can definitely provide a unique take for the podcast, is did you ever have to handle AMP in your Jamstack? Because if you worked at a news organization, I bet you did.
00:02:27 - Jake Ginnivan
We had to ship AMP, and the way we solved it was multiple render targets for our server side render, so it could render all of the same components. And then, as you hit something that needed to be specific, like an image component for AMP, it would render the AMP version of that component. That way we could keep a lot of the same structure and things that were the same across web and AMP without having to completely rebuild it. Once again, that's another thing that's a moving target, because the ranking used to be that you just wouldn't get your news content surfaced if you weren't on AMP, but that's changing a little bit.
00:03:04 - Christopher Burns
The news tab that was like, here's all the latest articles. What framework did you use while you were there? Because AMP is one of these really interesting ones where Gatsby half supports it. Next.js says they fully support it, and I've not really seen many companies actually adopt AMP unless they're enterprise, if you know what I mean. It's like the top of the 5%.
00:03:29 - Jake Ginnivan
Yeah, I guess it's probably worth taking a step back and explaining what we did. There's a project that we released called Project Watchtower. I wouldn't recommend picking it up, but it was kind of our version of Next, or I think the closest thing to our infrastructure was probably Remix about a year ago. Quite similar approaches to the direction that they were taking React Router and that sort of stuff. We then created some server-side rendering middleware for all of our React apps. The way we approached it is you just have an Express app and we can render the different routes on the server. We didn't have libraries like React Query and Next with all of its getStaticProps-style data APIs, so we built our own. Our initial implementations just did multiple render passes. So you could do a render of the entire application, it would trigger all of the data loads, and then once all the data was loaded, it would rerender the application with all of the data, and then it could return that to the user.
[00:04:29] It's not very efficient. So we were looking for similar sorts of optimizations that a lot of the other frameworks do, where they walk the React tree and kind of pull things out, or do top-level routing and data loading. What we settled on was building a library that allows us to define the page structure of our applications as JSON, and that gave us the ability to introduce middleware against our React components. So we had a data-loading middleware. Because it was a JSON structure, we could walk it, find any components that were registered in that page that needed data loaded, and then we could load all of that data and provide it to the page before rendering. But because we'd built all of that, AMP was pretty simple in terms of React. We just have a context which has your render target, and then have a component that has props for web and AMP. Then we have a couple of other ones like RSS, and then you just provide the various implementations of that component.
00:05:29 - Christopher Burns
One of the biggest things I think of quite often is if you spend your whole life working in agencies or startups, you tend to forget that when you get to this really high end, say, news organizations and you think, how do they run? Most of them have either a bespoke CMS or use this obscure CMS that the biggest organizations in the world are using, but nobody else knows how they all connect. You don't tend to use Contentful just off the shelf. Solutions are very specific. And I think the biggest thing that I want to ask about this all is, so as it's all server side rendered, is that Jam in your eyes?
00:06:07 - Jake Ginnivan
Ha. Good question. This is up for debate at the moment, isn't it? There's a few bits to that. We'll tackle the CMS one for news orgs because you're 100% right. Places like The Washington Post are building their own CMS for news organizations that have all of that stuff in it, as was coming from the print system. So we got zip files with a proprietary XML, and that was the start of our ingestion pipeline. And then we decode that and end up storing it in the database.
But getting to the Jamstack side of things, the thing about Jamstack is you're trying to leverage the CDN to serve content to users really, really quick with server side rendering. As long as you're caching and you have the ability to cache the majority of requests, you get the same experience as static websites. What makes it really challenging is you've got a trade-off, especially with tools like Gatsby around. You have to rebuild all of the pages. And when I left recently, we'd got to the point that we were doing continuous deployment to production on news sites that had like millions of hits a day, and the team could just merge a pull request and it went out.
[00:07:13] And that was just happening a couple of times an hour. There's no way you could get that when you've got a long tail of 2.5 million news articles or something. Most users, we're not going to serve a lot of that tail. It's very, very infrequent. But the highly available stuff like the home page or news articles that have been shared on social media, they have heaps and heaps of hits in a very short amount of time, and so they immediately get cached from the CDN and our cache hit rate can be in the high 90s and gives you all of the same benefits that serving from static files in the CDN can give you. It's just all generated on demand and cached for the user. So yes.
00:07:53 - Anthony Campolo
Well, we were kind of messaging back and forth. You mentioned that you're using an Eleventy plugin. So at what point did you start utilizing Eleventy for this stuff?
00:08:03 - Jake Ginnivan
This flips over to what I've been doing with Feature Board, and the news site is one side of it. And then you've got your marketing sites for your SaaS products. In general, it's expensive to have servers. There's a heap of infrastructure. You've got to monitor it, that sort of thing. So if you don't need all of that infrastructure and server-side rendering, it's a heap of complexity you can get rid of. So for something like a marketing site, you absolutely don't want to be running all of that infrastructure. You'd want to be generating everything statically at build time. That takes next to no time, and then you're deploying it and serving it from the CDN. We were using Eleventy for Feature Board to generate the static website. And then it's just got a CDN configured, so that's all served from the CDN. So it's nice and quick.
00:08:44 - Christopher Burns
Let's get into Feature Board. It's a hot topic area. And when I say hot topic, I think it's one of these unique companies that you think, I have a problem and I need a solution. And you think it's just going to be a boolean. It's just a boolean in the server. How hard can it be? And then you start digging and digging and it's like, yeah, this is going to be really hard. It's a boolean to me. But then if my business guy wants to swap some things around, how's he going to do it? And then you get into this management and then, oh, you need to find the user, then toggle their toggles, and you don't want to give them database access because they could do some damage. So it's like, how do you do all these things? And I find the same thing with webhooks, feature toggles, even dark mode. Sometimes you think it's such an easy solution to just be like, that's a line of code.
[00:09:36] It's just a pit of how do you manage this properly to make sure only the right users are getting the right things. Your product is currently in early access, so I would love to hear more about how you fix that solution, or have the golden path to that solution, and how you expect to be different from potentially other ones. So basically, it's your feature pitch time.
00:10:02 - Jake Ginnivan
Excellent. So to get started, I think feature toggles just in general are horribly underused. The number of times in my consulting background you'd go in and there is a system that does role-based access security, so admins can use this feature, or even just, I have this third-party integration, we've got a bit of config that turns that on and off. There's so many ways to do feature toggling. And I think if you look at it, there are so many categories of patterns we see in our software that really, if you look at it, it is a feature toggle. It's just the thing that changes is where the thing you're switching on comes from.
In terms of the problem space, where I started down this path was, once again, looking at media and trying to do some sort of A/B testing. It's quite challenging when you want to serve different things to different users and not impact your cache rate on your CDN horribly. Products like Netlify, they do A/B testing by your branch. So if you've got a static website, you kind of branch off and then you have your master or main, and then you have your test branch and you can do a percentage traffic split between those two.
[00:11:17] That works really well. But if you want to use another product, it becomes really hard because the way it works is you configure that you want to do a percentage rollout, but how do you allocate 50% of traffic to each of the variants of the toggle? It's actually quite an interesting problem space. So the way pretty much all of the products out there solve it is you have the user ID, and in the SDK they will hash the user ID to give it a common distribution. So let's say we hash the user ID and now I've got a number between 1 and 100 that will give me 100 buckets. And so the percentage split is if it's less than or equal to 50, it goes into bucket A. If it's more than that, it goes into bucket B. And so all of that's happening in the SDK. Try and put that in the context of Jamstack. Where do you put that logic? The only place you can kind of do that is in Cloudflare Workers or Lambda at Edge or something like that.
[00:12:19] And if those all have to be connected and making API calls to the feature toggling service, it becomes quite a delay on every request that's before your CDN. So you're kind of losing a lot of the value. That's kind of the background of the problem space, is I kind of want to do A/B testing and feature toggling with the CDN in place. That's where me and my brother took a fresh look. When we took a fresh look at the problem, the realization we came to is that the user, being the thing you configure against, is part of the problem that impacts how we can leverage CDNs. The way Feature Board approaches it is rather than targeting users and having a rules engine, you define the kind of audience categories that you are interested in. So that could be roles, admin, writer, reader, support for SaaS products. That could be your plan. So I've got a small plan, a medium plan, a large plan. If it's a media site, you might be interested in where the traffic comes from.
[00:13:21] Did it come from Facebook? Did it come from Google? Did it come from these various different sources? If you're an airline, there's another one like your membership level. So they're kind of like the things that you're interested in. If you boil down your users to groups or categories that you're interested in, and those audiences become part of the cache key rather than the user itself, suddenly you have a feature toggling solution that works much, much better with the Jamstack style of things.
00:13:51 - Anthony Campolo
This kind of gets into the perennial problem with the Jamstack, I think, which is just like user management itself. And it sounds like what you're saying is you are almost skipping over authentication itself and going straight to permissions and authorization. You're not really concerned with who this user is so much as what category of user this is.
00:14:12 - Jake Ginnivan
I think that's a really good way of looking at it. So you've got your authentication, then you've got your authorization. And we separate those two things into: this is who this person is, and this is what this person can do. Often in the auth world, you've got your access tokens or your ID tokens which have those different parts of the user's whole view in them. The approach that I'm taking is I don't need to know who the person is. All I need to know is what are the broad categories. And the cool thing is, if you go back to the auth solutions, you can extract claims out of a JWT in your CDN quite easily, so you can calculate which audiences the user is in based on the claims in their JWT, and then that can be included in the cache key. So you now don't need to dilute your cache key nearly as much as what you would need to if, say, the user was part of that cache key. It also means that your origin doesn't need to deal with all of the PII or complexity around it.
[00:15:12] That just allows you to scale a lot easier.
00:15:15 - Anthony Campolo
So you don't need to actually store the user's data anywhere.
00:15:18 - Jake Ginnivan
You mean Feature Board?
00:15:19 - Anthony Campolo
Yeah, because what you're saying is that you don't have to deal with PII. So the user's data is not actually being stored anywhere. It's just being matched to categorize them. But it's like throwing it out at the end of the day.
00:15:30 - Jake Ginnivan
Yeah. And all of who that user is stays in the customer's system. Feature Board doesn't have to worry about it. And so if you then want to do A/B testing, it's not something I've built into the product yet, but it's something that becomes quite easy because you can just hash the user ID in your Lambda at Edge, create your group or your segmentations, and then put that as part of the audience, like test group one, test group two. And then a feature can target values to an audience. I want you to be able to access this feature as a large plan user. You just configure that feature to target that particular audience with that value, and you can hopefully scale your system a lot more. Start using CDNs and not just marketing websites and that sort of stuff, and start blurring the lines of what Jamstack is. I think when you're starting to get into application logic and stuff, that's probably blurring it a little bit more. It's not quite there, but still taking the same ideas and the same goals, I suppose, and applying it to a broader context.
00:16:33 - Christopher Burns
I actually have some big questions to ask you. Now we've just defined that we're defining buckets, as you said, paid plan, airline miles, whatever. How do you put a user in a bucket? That's my first question. Is it a call that you do once, or when you need to change some buckets? If you're not defining the user, how do you know and how does, say, Everfund find that user? How do we connect them to things together, if that makes sense?
00:17:06 - Jake Ginnivan
The basic approach is I don't, or your feature toggling system doesn't, need to know about the user at all. Your application already knows who the user is and what plan they're on. The way I've solved it in Feature Board is I'm using Auth0 for my auth. When the plan changes, I push that into the user metadata in Auth0, so it ends up in their claims. So I always know I can look at the user statically. I've got the token and I can see that these are the organizations they're a member of, this is the plan for each of them, and this is their role in each of those organizations. And then I can pass that through to Feature Board. Your application already, however you manage that sort of information, as long as it can access it, it can put it in.
00:17:54 - Christopher Burns
Feature Board currently is much more of a firewall tool, you could say, than a tool that would define the permissions and then read them to the firewall and then allow them through it. In terms of users, as you said about changing user plans, someone's still going to have to code that in. When I think on another service, you would then tell that directly to the platform because the platform knows who the user is. So they have a context.
00:18:23 - Jake Ginnivan
Let's take the plans. The goal of it is to be able to hand away from the developers the responsibility of managing the plans. Let's take a scenario where I've got the limit of the number of projects the small one can have. One project, medium is three, large is five, and then some particular enterprises are paying for more. In Feature Board, you configure the large plan and you target the individual features. So for the max number of projects, you have the default value, which could be one, and then you add audience exceptions or targeting to that feature. So the medium plan has three. And so when I request, I use the SDK and say, what's the maximum number of projects that I can use? Feature Board will just return you a number based on the audiences that you've given it. So it does allow the marketing team to control the plans, but it just removes the individual user targeting. It's targeting the attributes of the user instead.
00:19:26 - Christopher Burns
It seems like if we take the highest level, it's asking a different question. You could say that others will ask, is this user authenticated to do X? But what you're asking is, is this role authenticated to do X?
00:19:42 - Jake Ginnivan
At the end of the day, it's still a user. The end result is the same. A user has an X number of claims and then I can infer the roles, and then I only give the roles to Feature Board and it gives me the values back. In my mind, another way to explain it is a lot of the existing projects conflate that mapping between what I care about the user and what value the user should be served. They conflate those two concerns together. All I've done is separate them. In the example of roles and permissions, you've got a claim in a lot of other products. I would just configure the fact that this claim serves this value. I've just separated that out. Your application logic has to have a look at its environment, build that set of audiences, and then Feature Board works on the audience. I've just split two problems apart and focused on it individually, and that kind of opens up a bunch of caching and other interesting scenarios that I think reduces the overhead for end users, like particularly salespeople and non-technical people using feature toggling products just in general.
[00:20:52] I find developers love them, but they don't get used to their fullest abilities just because they have a lot of overhead. And the other side of it that I've decided to simplify is removing the ability to configure features per environment. A feature is available or not for an environment, you can't do any more configuration for an environment. And when you use the SDK, you get a value and you have to specify a fallback value. If a feature isn't available to that environment, it just returns the fallback value. So if that's roles and permissions, you probably are going to say, do I have this permission? False is the fallback. And then if I've turned that off in prod, it will be off for all. If I turn it on, I'll actually get the configured audience targeting.
00:21:42 - Christopher Burns
It makes total sense to me. I would love to give it a go. I've been reading through the documentation myself. I currently notice you have three SDKs: JavaScript, Node, and React. I would love to know if you're going to be looking at supporting more in the near future.
00:21:59 - Anthony Campolo
Yes. Curious. Also, what exactly is the context in which you would use the React one versus the Node one versus the JavaScript one? Would you use React and Node together? If you want to do a full stack one, or would you just use one or the other? Like, what are the different SDKs really for?
00:22:15 - Jake Ginnivan
It's a great question, and I'd love to make it simpler, but essentially the Node one is for server. So if you're talking about a Next.js application, you would want to initialize the Node SDK. And the way it works is you initialize it, it connects to the Feature Board service and gets the set of toggles. There's a couple of ways it can update, like via WebSockets or polling, or you can specify a few different approaches. It can also just update it inline for something like Lambda that can't have a background process. And then at the beginning of the request pipeline, you say SDK request and give it the audience set. The audience set doesn't need to talk to Feature Board. It just does the calculations for that audience set. Here are the values inline, and it gives you a client SDK. So everything is TypeScript. So I've got a client SDK interface, and that allows you to get a feature value.
Now that interface is the one that is on the client side SDK. So if you're doing server side rendering and you can have the same code within your React, or if you're kind of stepping out of React land into something else that's just using the SDK, not the React part of it. It's the same interface that runs on the client and the server. It's just kind of the way those two are bootstrapped that are different, and the React one just sits on top of the browser, gives you hooks and a few nice things.
00:23:44 - Christopher Burns
I've currently been writing a JavaScript SDK for Everfund. It is such a gray area in how to do it properly. And also, don't forget you need to write your SDK in just pure vanilla JavaScript. No frameworks. Vanilla JavaScript. If you need to bind a button, you're using the classic way. I started out with, I'll just make a JavaScript one, and then I did it. I integrated it into Vue, Svelte, and everything. I was like, this is easy. And then I got to React and I was like, this is not easy. And that's when I had to abstract it into a component and a hook to make it easy for React. And I think that's half the thing that everybody says about the ecosystem, is React is this whole different beast compared to Svelte and Vue. Because with Vue and Svelte, you can just use the JavaScript one and it just works. But React abstracts everything into a virtual DOM, so it makes it so much harder to do those things. TypeScript is fully baked into Feature Board, from what I've seen.
[00:24:42] The libraries are built in TypeScript. What's your opinion on TypeScript? Do you like it? Do you hate it, or is it just a necessity?
00:24:48 - Jake Ginnivan
I'm all in on TypeScript, actually. Quite a few years ago, our team wrote the initial types for Glamorous, the CSS-in-JS library, and recently I rewrote the types for Glamorous 11 to drop the compile time. So it dropped our TypeScript compile time by about half with the release of Motion 11. Yeah, all in.
The biggest problem at the moment is the ecosystem with esbuild and all of these really fast tools that don't do type checking. So you've got to figure out where does the compiler fit in. Previously you'd kind of use ts-loader and Webpack or something like that. So where I've kind of settled is your TypeScript compiler needs to be running in watch mode outside the rest of your tool chain. Don't have the TypeScript compiler anywhere near anything else so it doesn't touch your tests, it doesn't touch your linting, it doesn't touch your build and local dev experience. The two things kind of have opposing forces, I suppose, because all of these ESM style things like Vite, you request a file and it can do a single file transformation through its pipeline super, super quick.
[00:25:59] That doesn't work with type checking, because you can change a file and break another one. That single file module, all of these really quick things and pipelines and parallelizing, that's really, really hard to do with a type checker. So that's why I kind of separate the two. I've got a blog post about how to do that.
00:26:15 - Anthony Campolo
This has been something that's kept me away from TypeScript. Getting it configured and correct seems like more work than it's worth because you're getting safety, but at the same time, you're introducing fragility because of the tool chain.
00:26:27 - Jake Ginnivan
And the new breed of tools, they just know how to read TypeScript. They just essentially strip off all the type information and ignore it. I think that approach is going to be where we're moving. I suppose there's other things like Lambda which look really cool, or elements. Some of the older episodes you talked about really, really cool approaches that are trying to solve the whole problem. But for the moment, it's just that all of this stuff that is kind of required for your fast dev cycle. Just don't use the TypeScript compiler and then have the TypeScript compiler running in watch mode in VS Code, and that's just surfacing the type check errors to your IDE. And it's kind of like best of both worlds.
00:27:05 - Christopher Burns
I just want to pull up something you said earlier, that you're a type author. So you have committed to the unseen heroes of the TypeScript community, the people that wrote the types for X, Y, Z packages. I think it's a really interesting question. Should the author write their own types, or should they just say if the library is popular enough, someone else will write them for me and just add it to the DefinitelyTyped monorepo?
00:27:34 - Jake Ginnivan
Either is fine. If the author or maintainer isn't all in on the TypeScript ecosystem, then it's super hard for them to review a pull request. So DefinitelyTyped is probably the better choice there because if I've contributed to that particular type package, it's DefinitelyTyped and someone puts up a pull request, it'll automatically ping me to say, hey, go review this pull request. They've got all the infrastructure in place to go, if you touch this file, you're on the hook to review it. Whereas once you commit it to the main repo, the maintainer is kind of responsible for that. So if they use TypeScript a lot, then sure, they can take on that responsibility, but I don't think it should be a requirement. It does bring its own challenges where things get out of sync. But as long as you're not changing your API surface area too much, it's probably okay, isn't it?
00:28:25 - Christopher Burns
Also, pnpm automatically installs the typed file if there is one. The only caveat with typed files is like you downloaded a TypeScript project. Oh, it's not got the imports. Okay, now let's do the typed npm file. Oh, it's not got it. You know what I mean? And then you're figuring out, okay, now I need to put that in there. But to be fair, that's happening less and less as we're seeing wider adoption of TypeScript. There is always an option out there.
00:28:53 - Jake Ginnivan
Yeah, I think eventually all the libraries will just be written in TypeScript and it won't be a problem.
00:28:58 - Christopher Burns
I would love to get TypeScript enthusiasts versus just Rob Cameron. That would be my favorite episode because Rob Cameron is a very anti TypeScript person.
00:29:08 - Jake Ginnivan
That would be entertaining.
00:29:09 - Anthony Campolo
Yeah, he's fiercely anti type, which makes sense because he's a Ruby developer and there's no types in Ruby either.
00:29:16 - Jake Ginnivan
And then he'd be a testing evangelist as well, which I think we do particularly poorly in the JavaScript ecosystem. So we're the worst of both worlds. No tests and no type checking. At least now we've got one.
00:29:27 - Christopher Burns
Yeah, exactly. And by the next ten years, we may have both of them and be a fully typed, checked, and tested language. But they'll still be people that are like, I just like it pure. None of that, push it to production.
00:29:43 - Jake Ginnivan
Yeah, I think that's why things like Redwood and these full stack Jamstack frameworks are great because they actually bring testing out of the box and you're set up and ready to go. It just reduces that barrier, especially when using tools like TypeScript. Previously it was just how do I get all of these things working together without just wanting to top myself? It's pretty challenging.
00:30:03 - Christopher Burns
RedwoodJS recently changed their tagline to the JavaScript framework for apps, isn't it?
00:30:10 - Anthony Campolo
JavaScript app framework is what it is, the JS app framework.
00:30:14 - Christopher Burns
I put on my cynical glasses and said it should be the TS framework because it's all TypeScript. Yeah, I didn't think that went down too well in certain eyes. And we talk about TypeScript tools. I think one of the best tools that I've used for TypeScript is TSX. It's one of those really odd tools that are out there for a very specific purpose. But man, that gets TypeScript right.
00:30:39 - Jake Ginnivan
Yeah. Another one in that same vein I've used is tsup. There's a few others that are coming out, depending on whether you're on esbuild or Webpack, or which part of the ecosystem you happen to be on. But yeah, they're all copying that TSX approach of just being able to build a package and it gets all the targets right. And you don't have to worry about the transition between CommonJS and ESM. Someone else has figured that out and I'm just publishing my thing.
00:31:07 - Christopher Burns
Oh yeah, it gets confusing really, really fast, as you and I know because we both wrote a library for our companies.
00:31:16 - Jake Ginnivan
SDKs are hard, but hopefully it's getting easier.
00:31:18 - Christopher Burns
That's a story for another day.
00:31:20 - Jake Ginnivan
Definitely.
00:31:21 - Christopher Burns
My last big question is where do you see the next six months? Because obviously this is an early product. You're currently in beta, if I'm right. Where do you see your next six months? What are you looking for? Are you looking for early customers? Are you looking for potential employees? I'd love to give you the space to tell people what you want.
00:31:43 - Jake Ginnivan
At the moment, I'm really looking for a few people that are interested in the space to become customers or try it. I'm really looking for feedback. It's quite a different approach to many of the other products out there, based on pain points that I've had with many, many of the commercial products, and just been looking for something that's a lot simpler. So I worked on the UX and tried to simplify the problem space. So it's a lot more accessible to everyone, really. Anyone that's interested in giving this approach a go, more than happy to invite. I'm kind of looking for a dozen or so people to get on board from this point, again, to expand the feedback pool a little bit more than what I've had so far.