Pika Pkg

You're listening to syntax, the podcast with its tastiest web development treats out there. Just grab yourself in and get ready. Here's Scott Zelensky and West Boss. Welcome to syntax, the podcast with the tastiest web development treats.

Today we've got a really good one for you. We've got Fred Shot on the podcast to talk about Pika package, which I've been following for I don't know how many months now and I'm really interested to figure out what it is and how it fits into your workflow and what it replaces and all that stuff. So we'll have him on in just a second. We've got two awesome sponsors today, Sanity, which is a structured content CMS.

They've got some new pretty cool. We've been rolling out some features like crazy lately. We've been talking about their preview feature and FreshBooks, which is cloud accounting software with me as always is Mr. Scott Zelensky.

How are you doing today, Scott? I'm doing good. I don't have really a whole lot to say, but this is a third podcast we recorded today. So he's out of things to talk about.

Yeah, the pleasantries. Although we can only talk about the weather so much. Yeah, I like talking about the weather. Yeah, something to loud.

Yeah. So Fred, welcome. Thank you for coming on the podcast. Hey, thanks a lot for having me.

So you've built this thing called Pika package and it's as far as I can tell, it's a whole bunch of stuff. And really why I've been paying attention is you have a bit of a background both working in node land as well as you worked out some large companies. So do you want to give us a rundown of who you are and whatnot and then we'll dive into what is Pika package? Yeah, sure.

I'd be happy to. If you want to ask me about the weather here too, I'm free to talk about that as well. So where you're from? I'm in San Francisco right now.

It is sunny for the first time at all. Oh, nice. Beautiful. Yeah, I've been working on Pika for about a year now.

This might even be like right around the time where I launched the first website one year ago. It comes out of work. I did kind of starting at Google. So trying to take a look at this space where we have this new sort of module system for JavaScript coming in, yes, that right.

Yes, modules, which was kind of ratified in 2015, but took a while to get into all the browsers. And now four years later, we are essentially here where it's supported by a lot of modern browsers. So it's this kind of new chance to take a step back and take a look at all these different preconceived notions, best practices that have built up for maybe a different world that doesn't make sense anymore. So it's really just a, it started at least as a project to experiment with different things in that area.

And it's started to coalesce around a few different ideas that have taken off as experiments on their own right. Okay. So 20 minutes ago, we just finished right doing an episode about modules in node. And it's hard.

It's like not totally there yet. It's obviously still in development, but like there's like no named imports from common JS. And we have this whole like history of like NPM is full of all these packages. And it would be nice if node and NPM and everything just started today.

And it was all ESM. Yeah, not with a million other packages. Yeah, yeah, exactly. So like what, like, what is big a package then?

Like if someone were to ask you, what is it? I know there's a couple of different pieces to it, but want to give that a shot. Yeah, definitely. It definitely is a few different things right now.

But I'd say what it is conceptually is it's asking this question of how would you do web development if you didn't need a bumbler? I'd say that's the biggest kind of thing that we've kind of watched on to as a question to ask now that we have modules that run on the web. So the question is why do we use a bumbler today? Yep.

You might think we use it for production, which is nice. There are definitely some production reasons to use it. You might think because it's a really nice development flow. There are all these things that have been built up in that world.

But the big reason we all needed like that need to use a bumbler. There isn't really much web development today without one. And that would be webpack or parcel create react. That's like that bundle layer level tool.

The reason we all use that really is because of MPM. As you said, all these old packages on MPM millions of like a million packages are all written for common JS, which is that node syntax that was really champion by them. No champion that MPM was built for node originally. So that was kind of the lingua fresca, the standard module system.

But the one downside was that it didn't run on the web natively. So it let us all come into this one single JavaScript ecosystem node web. It brought us all together, which was awesome. But the downside was that web developers had to pull a tool that had previously really only been for production bundling.

You basically used to back in the day, you can cat me all your JavaScript files into one for production reasons. But in development, you would still, yeah. That's the one thing where it's like I'm not saying we go back to like concatenating files together ourselves, like the tooling that's come out of the last decade is awesome. But the downside has been that it's put a lot more strain on the development process.

So bundling is now a development concern. And when you make changes locally, you have to rerun your bundler. Waiting for a compile step that we see on create react app and other tools. And on some projects that worked on over the last few years, that's been a few seconds.

It's been up to 10 seconds online. That's every change you're just kind of stuck there waiting. As a developer, that's kind of a pain. That's something that I don't like.

There's a lot of you can start to re-look at there. Yeah. Just being able to reload. So when I just launched a big beginner JavaScript course and when I got to the module section, I was like, look, you can do almost all of this just with a script type module and then start importing and exporting down the chain as far as you can go.

And then we got to the part where we wanted to use some NPM package and it got a lot messier. And at that point, I say, this is where you need a tool, unfortunately. And I showed them some options and things like that. We ended up using partial in there.

But so you're saying like, this Pika is going to solve that. I'll be able to use just regular script type equals module. And then I can use Pika as a registry on that. Kind of.

So before we get to the registry part, before we ever got to that, it was really just taking a look at exactly what you said, which is that it all works great. This whole new tech, this new language, it's fantastic. And then you have to talk to MPM because no one's really doing web development without it today. What we started with was this project called Pika Web, which we're renaming to Snowpack just to give it its own identity.

Snowpack. That's a nice name. Yeah. That is a good name.

You have to whisper it. Snowpack. Yeah. What Snowpack lets you do is it's a simple.

You're really good at naming things. I'm just going to say that out of the gate. I'm just going to throw that at you. Thank you.

That's a year in the making. So that was a group effort to other people to jump into that issue. But yeah, what it essentially does is it looks at that as the problem. So instead of saying you need to bundle your whole app, it really says, okay, actually you can get really far.

It's just NPM you need to worry about. So why not build a bundle or just for NPM? So what Snowpack does is it adds in all time versus that development time. And this is where the naming is, you can call it what you want.

You can say that it bundles your dependencies. You can say it's a post install script. But it essentially takes your dependencies and turns them into these single file ESM JavaScript modules. So React, React, any dependency you want, you can essentially just pull into a single JavaScript file that can then be imported by your project, by your app.

Okay. So you run it once, you run it when you invest with your installs, maybe you add a new package, maybe you just run NPM install for the first time. And then now you're able to do development locally. You're not running a tool every time you make a change.

You're not recompiling bundles every time you make a change. You're building your app locally without a ton of tooling. And then now all you need to do is run that bundleer once with install. Oh, that's really a really great, I don't know, just exciting use case for this.

The fact that it's not just going to replace something that you're using, but it's going to take something that every single developer who's used a modern bundling solution knows this pain point of sitting and waiting when inevitably, like you said, you shouldn't really have to unless you're installing something new. Right? So I think that right there clears up a lot of the why for me. This is the, that's a nice little, nice little value add.

Does this mean like, so I'm just looking at the docs here and you import a module and instead of importing it from an example, you have preact, instead of importing from preact, you import it from like local directory, web modules, it makes a new folder called web modules, and then it puts the entire package into a single JavaScript file in that folder for you. Yeah, so it does what a bundle does right now for your whole app, just on dependency. So any transitive files that it would be loading, even if those are common JS, it goes all into one JavaScript file that is the SM. Oh, so you get one preact.js file, even if react had dependencies, which I don't think it does, but it has local files, it has, you know, it's not a single file package, but it essentially installs it as one, even if it has dependencies itself.

And what if something like shares peer dependencies? Yeah, like three modules has a peer dependency. Does there something for that yet? So I lean on roll up a lot.

It's essentially a special roll up config column. Oh, okay. So you didn't build your own. So whatever roll up can do, it can handle its peer dependencies, it can handle, you know, it does all that pretty smartly because it's the same problem we've been having to handle four apps, right?

Co-splitting and chunky and all that. Just move down a level. And does that mean I'm not going to have a 40 gig node modules folder then? Well, you still will.

We still fill off of that node module. So we essentially create a web modules alongside it. Oh, okay. Yeah.

So it really is post install. So it installs it and then pulls it out of there. Yeah. Okay.

Okay. Wow. Yeah, exactly. So you should have gotten the two terabyte MacBook Pro is what you're saying.

Yeah. It would be interesting to pull from package or from our CDN, but essentially right now it's on top of no modules. It's on top of your MPM. And that just allows you to use just regular HTML imports.

That's not called HTML imports. That's not what it is. It's no, just DSM ports or JavaScript imports. Yeah.

It's an interesting thing. We're now you kind of get into, okay, so now what's possible that you have this? You can technically run basically build a whole modern web app using modern MPM dependencies without any other build tools. So you're literally a static asset server and you make a change and then you refresh your browser and without any build tooling.

It's all just there. The changes there. But people like to use Babel, people like to use TypeScript. So there's this other side of it where you can still use build tools.

We're not saying, okay, that's all build tools. That's all tooling at all. All we're saying is that you don't need this whole bundle where you can just use the tools you're wanting to use. And TypeScript and Babel, they're still really fast at per file compilation.

So you can still set up basically Babel on your source directory. You make a change and now Babel just has to recompile that one file. So you get TypeScript watch, you get Babel watch, you get these things that are actually very good at single file changes. Okay.

Wow. That's really interesting. Yeah. So no more 10 second wait times for a bundle or five second wait times.

You essentially it's as fast as Babel and TypeScript can recompile a single file, which is milliseconds or maybe hundreds of milliseconds of the works, but certainly not seconds. And I remember that with back in the day, we had like a SAS app that would take like 32 seconds to recompile. Oh, awful. Right.

Even like, I'm just thinking about how awful that used to be. I got a new MacBook and just my node app restarts so much quicker on my new laptop. I was like, oh, that's such an improvement. Yeah.

It's all these languages that we use like SAS and using a bundle. It's like we're writing a language that runs in the browser. Like if we're compiling and getting all these compiler benefits, that would be one thing, but we're essentially doing all this build time to still just ship the exact same language we're writing. Yeah.

Yeah. So shame. So hopefully this is at least a start in that direction. It's been around for about a year.

It's got some good. We're hitting V1 soon. It's got some cool production things we can still do with it. Really exciting direction.

I'm really excited that you you've clearly thought about aspects of like the barriers to entry of this, like specifically people not wanting to ditch their already established build process. I think to me that was like one of the biggest unclear points of this whole thing was like, can you use this with whatever you're using right now and how much buy and do you have to get? Because a lot of times people will hit, you know, they'll have this major project. They've built it with one thing.

They want to try this new thing, but it's too much of a hassle. So if you were having like a project that already existed, could you maybe step through what the refactor process would look like to maybe even just attempt to have this for not the entire thing, but for maybe a small subsection, like what would the migration to this look like? Yeah, certainly. Yeah, that's definitely the interesting part of this is it all depends on how far into the bumbler ecosystem you've built yourself.

So the more you can consider some things that we do, like let's just call them their like Webpack things, like importing a CSS file right now that's not really a defined thing. Webpack, certainly they just, they describe it really is whatever plug in you're using just defines that behavior. What an importing a CSS file importing JSON, importing things without a file extension. These are all sugar, essentially on top of something more complex that Webpack lets you do.

So depending on how many of those Webpack specific or bumbler specific things you're doing, you do need to start to rethink what do those look like in an actual browser native way in a way that actually is defined in the spec and would run. CSS is a good example of that, or let's say you actually do lean heavily on importing CSS as if it were a JavaScript module. So you do that import keyword and then the string is a local path through your CSS file. That's not importing JavaScript, that's importing CSS that would never run in the browser.

Webpack handles that for you using this magic bundling. Instead, you have to think about what that looks like either by using a specific library. So there's a few out there that exist on CSZ is a really cool one where it lets you do something very similar where you can either import a CSS file, essentially it's exactly a workflow, but instead of using a ESM import that is a browser specific thing, you use this library, you say CSC and then you put the string of the file you want to load, and then at runtime it'll instead import that directly. Things like that are the interesting thing to tackle here.

It depends how far into Webpack you've gone. Interesting. CSZ is the Canadian Society for Zoology. That's not what I want.

They had an amazing open source program. Oh, so CSZ is a runtime for CSS modules with SAS like pre-processing. Interesting. I've never heard of this.

Yeah, it really is this whole other world you step into. That works. Yeah, I would say the whole caveat to this stuff is don't take whatever you're using at your company that's working great and feel like you have to rewrite it today or anything like that. This really shines as if you're building a new app and you haven't gone far down a path that's hard to walk back, then this is a great way to start and get your feedback.

And then it just becomes, OK, how important is it maybe if you have a really painful dev process that is taking 10 seconds? It really depends on what is your pain and then how hard is the solution based on what you've done. I'd say if you're looking to eject from Webpack, or something similar where you've been using this fully featured environment, this fully featured dev environment that they've set up for you, you go to eject and all of a sudden you're dumped with a 400 or 500 line Webpack in fake that you have no idea what it's doing, right? Create React App is great because it takes care of it all for you, but only to an extent, right?

As soon as something breaks, you're stuck digging through that or as soon as you want to customize it, unless you want to use maybe an add-on tool. But anyway, that's a really good chance to take a look at this as well. If what I'm using isn't working for me anymore, if I'm feeling these pains of build time week time, how can I maybe take another look at a different solution? That's really cool.

I also think this is just awesome for beginners as well because there's not a, you know, there's not a huge hurdle to getting something up and running or even just like for me, like I've got an hour or two to work on a little idea that I have. I don't necessarily want to spend that time fighting some sort of config and whatnot. I just want it to work and I just want it to work in the browser. And I think we're like, I kind of feel like with this kind of stuff and also other stuff in the entry, we're getting more back to the olden days where like, I would just, it used to be already just download a jQuery plug and then drag and drop it.

You just include it with the script tag and obviously that's a little different now that we have NPM, it's much better. But I feel like it's getting easier and obviously these tools are making easier. Yeah, there's definitely this like nostalgic feel to it. Where you still have all the same power that you have and you can use this NPM packages, maybe you have to import CSS differently and whether that's a better way or worse way, I think is up to interpretation.

But yeah, I mean, you open up all these really cool and very nostalgic feeling things like, do you sort of suddenly become the default again? Right? If I'm deploying my whole site as I've written it, then every file is as written. And maybe that's enough for you.

So you're getting the GSEP compression and you're saying that's enough, uh, modification for me or maybe you pretend, you know, another minification step, maybe you add a bundle for production. Like it starts with a much simpler default case for exactly that hello world, you know, simple example you're talking about. And then if you're a Facebook or you're something company where you can afford a production team, you know, a web hacking, um, if you can afford to invest in that, then certainly you can get all the same benefits that exist today, but just with a much lower barrier denture. Yeah, this, we'll get into this a little bit more.

I think after we do an ad reader stuff, but this CDN thing is totally making me reminiscent of the times when you could let go to add jQuery or something and whoever would just be like, Oh yeah, you just copy the script and place that at the top. And then next thing, you know, you got, you know, 20 HTTP requests for different plugins or whatever all hosted on some mystery CDN that you've, you know, different CDNs and who knows where they are at. But I think what we want to do real quick here is take a quick break and talk about one of our sponsors today, which is sanity. And sanity is located at sanity.io.

Now, sanity is the, it's the back in CMS to build a structured content in it is really exceedingly modern and they are rapidly growing and adding new features. So what's the talk about one new feature, which is previews. So sanity just rolled out this like really cool thing where you can I frame in your content, most likely that would be your website. And as you are typing in your editor, you can preview that as it will look on your actual website.

So they built this amazing thing where you can just type in, you can preview it. And it looks like the code to hook it up is pretty simple because the way that you can figure sanity is not through like a GUI or something like that, the way that you can figure it is by writing these config files that are written in JavaScript. And you can just hook up a preview I frame and it's up and running. And then the video that they launched to show this preview is pretty neat because obviously you can preview a website, but then they also show you can preview like social cards.

So like as you are editing the metadata of a post or something or the title, you can like pipe that into like what would it look like as a Twitter card or Facebook share or they also showed you could preview it as color blind users or you could just like apply color blind filters with I'm assuming CSS over top of it. So it'll show you what it looks like from a color blind, color blind. You can preview as printable PDFs. I don't know.

It's just such a cool way to think about previews. I would assume most people would use it to preview what it looks like on their website, but they've sort of taken a step back and allowed you to control it a little bit more however you want. So check it out sanity.io forward slash syntax. And that's going to get you double what the free plan does.

Thanks so much to sanity for sponsoring. So if you had to peek a dot dev, you'll see a search bar in the very first link you'll see really is the registry tab. I'm really interested in what exactly the registry is and how it relates to everything we've talked about so far. Yeah, definitely.

That would be our next kind of big bat. So we started with all this open source tooling and now we're starting to experiment with some more CDN registry kind of taking a look at the whole ecosystem itself. The registry is essentially looking at that problem from the other end of it. So we can keep using tooling to make development easier.

But at the end of the day, what the tooling is trying to solve is the fact that most of MPM isn't written for the web. It's written in common JS or maybe it's written for a yes, but it was built assuming a bundle would consume it. It could still be doing these things that were never really tested or ever meant to run the browser. Yeah, like React is probably written with ESM, but then they bundle it and ship it as a common JS so that your web pack can then eat that and then turn it back into ESM to use it.

And then eventually you bundle it again and it'll ship it back out. It's turtles all the way down there. Yeah, right. A lot of web code is just built assuming that there would be a bundle because again, that was the only way to use most anything on MPM.

It was the deal that we made to have everyone join MPM was that the language that we would all use was this common language that had already been chosen which was common JS, never meant to run in the browser without doing. So what the registry is is it's a chance to start again and start building packages that run anywhere and run in the web natively. I would say right off of that again going back to how does this play with the current ecosystem is essentially a, I think it was like a garden within MPM. So every package in our registry is published to MPM.

So you're not having to leave that place where all your users are today. But what it is is it's a way to build packages where you can guarantee that every package in that registry in that collection is ESM, it is built for the web, it's tested on the web and we're doing a lot of cool things in that space where we see a bit of a fracturing of what it means to do JavaScript. So before everything was Webpack or No, right? Those are the two let's say, you know, parcel and maybe other things.

But you were essentially as a package creator targeting those two things. Today you have Dino, you have these other registries coming up, you have GitHub package registry on the scene, you have the GM still, you have no DSM, you have no common JS. As the world kind of fractures for whatever reason that is, you see that the burden is really being placed on package creators to create the perfect package that would somehow run in all these environments. But how many times do you get a GitHub issue that this doesn't work in my environment for these reasons?

Now, you as a package manager, you're now having to troubleshoot some environment that you're probably not even used to using just because of different requirements, you have different build tools, different build processes, all that stuff. Yeah, exactly right. And what that looks like is, okay, I need to go and research what that field of the package JSON might be doing for that bundler, but I can't have it affect the bundlers that are, you know, right? Yeah, exactly.

No one really owns it. And so you just get everyone over ready in each other. And we saw that a lot with people trying to build universal packages where essentially everyone assumed that module was there. So module was this field within a package JSON that you could say, this is ESM.

But Webpack would be like, oh, great. You know, module code, I'll use that on node. I'll use that in the browser. So all of a sudden you had this one where you actually couldn't describe what you wanted to do in a way that every tool would really follow and what you wanted.

So having a target that some bundlers meant for the browser to consume, some bundlers meant for node to consume, yeah, it's a bit of a mess. That's a bit of a mess. I think that is like the tech line for what we're going to do. It's certainly for Beka.

So Beka is the registry. So like is it its own registry? Does it sit on top of NPM? Is it both?

I know that the idea is that nothing gets into the registry unless it's ESM, which is great. But like where does it sit in relation to something like NPM and where does it sit in relation to something like an unpackaged? Yeah, we're still trying to figure that out. Right now it's basically in this closed beta.

We have a few head over to our Patreon. You can sign up for that closed beta. So it's a pretty limited set of users right now as we try and figure this out. I did it today.

It is a little bit of everything. So it's, imagine if your registry just was kind of by definition or like unpackaged. It was, I think that you could hit in any environment. So the browser can hit our registry and just like an unpackaged works today, it basically loads that module.

You can technically do MPM install and then put the URL of our registry and it will install the package. Dino can import from our registry. So it's almost just like Amorphous kind of vlog up in the cloud. Whatever environment you're in, you can hit it and it will get you the package unique.

And that pulls from the same CDM logic that we built out originally for MPM where if you're hitting it with a modern browser and you want to load it directly on your site, so I basically have the user instead of installing it as a developer and bundling or anything like that, you can essentially send that import directly to our CDM to our registry to your user and your built production app. If you do that, then if they're on a modern browser, they'll get the latest ES 2019. If they're on a legacy browser, they'll get that ES 2017. So we do this really cool differential server by default where every environment gets the perfect JavaScript for them.

That's really cool. I was thinking that I was just thinking like, man, it's so cool that just like regular JavaScript imports, no bundle or nothing, you can import from a URL, right? Like you can import react from the registry dot whatever and it's slash react. But then that doesn't take care of like older browsers, right?

But you're saying that it will detect the user agent and then serve up the appropriate one? Yeah, that's neat. Yeah. And this applies back to what we were talking about even earlier.

But every browser except for really IE 11 and then you see browser in China supports this. They're obviously the minor ones that don't. But those are really the only two major browsers that don't support this. So if you're building a website that isn't targeting enterprise IE 11 or maybe isn't targeting China today, that's certainly a pretty good option for even for production.

Very interesting. Yeah. Oh, that's really neat. Yeah.

Yeah. I really like that. Like you clearly have taken a step back at all of this and like, huh, like there's probably something we could do here. Like I always appreciate people like that in the community because like I'm just a kind of guy that I just use it because that's what we use and we keep going, right?

And there's like these visionaries that take a step back and say like, this is weird that we do this and it's only because of all of the steps that led up until today. That's why we do it that way. But like what if we were to think about it in a different way? So this is very enlightening.

Yeah. It's that a react gave that original presentation where they announced it or maybe it was one of those announcements where it just comes. I was there. Yeah.

What was the title of that? It was like rethinking best practices. I think that was. No, that was Ben Allman who was like the jQuery plug-in cowboy.

Yeah. He he's we were all sending snarky tweets at the release of reaction. Oh, yeah. And he said, he said, react rethinking best practices and he tweeted it out and they took that tweet and go, we are rethinking best practices.

Thank you. I remember sitting at my desk and one of my coworkers was like, they just just had this awesome talk on this thing called react. I looked over at his screen. I was like, oh, yeah, this feels a lot like that where it's like, why are you messing with this?

It's like, no, that's exactly the point is like, if you never ask these questions, we'll just keep doing the same thing forever. But the world has changed and what is possible has changed. And at a certain point, you know, we got to explore that at the very least. So totally a big part of this has been saying, you know, this is enforcing.

I'm not putting a stick in the ground. It says, you know, you have to do it any one way. It's way more about just like these things are possible now. And if you want to, for the first time, you don't need to use a bundle.

You don't need to do all this doing. So if you love webpack, by all means, keep using it. If you want to try something simpler, then this is certainly an exciting time. Yeah, very cool.

This seems like the kind of thing that I bet like a group of passionate people will start using it. And if it catches on, if it starts to make sense for them, they will not stop talking about it. It's like TypeScript right now, right? Yeah.

Everybody will not stop talking about TypeScript. It's because it solves all of the problems that they've had with JavaScript up until now. I can certainly see this happening with something like this in the next couple of years. Yeah.

That would be great. That would be cool. Web Components under that community has been interested in this. In the registry, specifically, I know Dino.

They're still working on their MPM compatibility story. So how do they get a set of packages that work on Node and in Dino? We need to do a show on Dino. So Dino is Node.js, but run on TypeScript.

It's written by Ryan Ryan, the guy who made Node. He did this awesome talk a couple, probably over a year ago. It was really good talk. Everything is a great thing.

I'm making a great note. I've always pronounced this. This pronounce says Dino. I'm really happy now that I've learned that it's Dino in a logo makes so much more sense.

I was not to say, oh, no, no, I'm worried. I've been mispronounced. No, there's a dinosaur here. I mean, yeah, that makes way more sense.

Maybe it's Dino. We don't know. Yeah. No death.

No, Dino. Dino. Yeah. It's probably Dino.

If there's anything we know from the podcast, is that I'll say it wrong? Yeah, likewise. Yeah. That's really interesting.

I had no idea that this Dino is getting such steam. I'm just looking up on the other GitHub. I heard about it for a while, but that's a demon. Yeah.

That's, I mean, TypeScript is another one of those things where if you're a package creator, you're getting those issues with people saying, oh, please, you know, we're the TypeScript types. And then as an author, it's like, okay, don't use TypeScript. Yeah, do I care? I don't need this myself.

Exactly. That's a nice thing about, and I can talk about the code editor, which is a bit of the other side of this registry where we handle that as well for you. So TypeScript types are generated and hooked up for you by default. Essentially the registry is just a place to put your source code and then we will create the package for you almost as just a, like, not a side effect, but as a just a effective you doing development.

So every time you push a change, it gets a new release. So it's using that semantic versioning, not semantic release process. Yeah, it's really cool. It's essentially just like we have your source code so we can build these really high fidelity projects, connect all the entry points in a way that you can't really do today where instead MPM has the tar bolt, right?

It just has this kind of processed zip file is essentially what they get as a registry. So what you can do with that level is it's really, really exciting. So let's, before we get into the editor, and because I think this is a really interesting subject, I think we should probably take a break to talk about one of our other sponsors, which is FreshBooks. After you've written your application with Pika and it has just been so fast and easy that you are bringing in the cash, left and right, you're going to want to head over to a freshbooks.com and sign up because you're going to need to have a system to keep track of your books.

Now, FreshBooks is one of the very first sponsors over here at Syntex and we really believe in making this kind of thing easier. If you've ever used, I want to say like QuickBooks or any of these other book softwares, bookkeeping software, you'll know that it couldn't be. It feels like it's going backwards in time and FreshBooks feels like it's going forwards in time or into the future because it really, it takes the modern approach to all of these things we know and love, puts it in the cloud and it puts the features that you actually will use in front of you. My personal favorite feature is really honestly, it's just how easy it is to get around and explore and navigate this thing.

No more questioning and being confused about what the heck everything is and where to go. I always felt like I was messing up my books. So FreshBooks is definitely the cloud accounting software that you'll want to check out if you are needing to keep track of your books. What you're going to want to do is head on over to FreshBooks.com forward slash Syntex.

But Syntex and how did you hear about this section and let them know that you heard about FreshBooks from Syntex. You'll get a 30 day free trial. All right. So the editor, I think you just launched this what, like a week or two ago as of as of recording?

Is that true? A few weeks ago, maybe now? If I put my email in this early access, can I get it early access? Let's talk.

No, it's still close to open, open invite at this point. We're open to get it publicly available by January. We have people using it so you can hit our Patreon and get really access to that. Oh, cool.

Yeah. Which essentially just to figure both people beta testing and begging out the last few issues and bugs before we go to public launch. And if you support $10, you get stickers? Is that?

Oh, yeah. Stickers. Hey, I'm into that. So I don't know that Patreon.

Yeah, featuring the news, no back sticker. Oh. That's a great addition. Or first edition, I guess.

Oh, two get tethered to my computer. That's going to be... That's going to be... My credit card.

That would be worth. Millions. You get it folks. You never know.

That's cool. So like what is the editor? I'm just looking at it here. It looks like you write your code in this thing.

Does it replace your VIM or VS code? I mean, is that just for writing packages? Maybe explain that. Yeah, definitely.

Yeah, it's funny enough, which maybe I should have anticipated. But this is probably the most controversial part of the project where I was essentially worried that everyone would be like, oh no, new registry. Oh, that's going to be terrible. That's what you're writing.

Everyone's like, yeah, the registry is fine. What is this editor? I'm not leaving VS code. No way.

It's so funny. So we'll see how far this gets us. We might ship a local development tool that can run somehow locally as a user-native editor. But what this is, is it's a way to build packages.

So it's a code editor. You think of it as a code editor for packages. Instead of having to set up your project structure and your folder layouts and all that, everything is really conceptually about the package. So instead of having a what do I call my source directory?

You just have source files. Where do I call my test? How do I do that? You just have test files.

The navigation is really about the package and the different things that would be a part of it. It's powered by Monica, which is the engine that VS code uses. So it'll feel really familiar if you are using VS code. It runs in the browser.

So it runs all your tests in the browser. So again, going back to most people when they say a package is ready for the browser, really they're just testing it through some sort of node, bundler, hybrid. Very few packages actually have a browser testing setup. Yeah.

We do all this for you automatically in the editor itself. So we make a change. It runs in the editor. We have benchmarks that run.

There's all I can go on for hours about the features. Yeah. The one thing that was really interesting to me is the preview changes live in app. And it just gives you a live URL that you can import from directly.

I think that's fantastic. Yeah. So you can actually put it together in a kind of, I don't know if anyone's done it this way, but essentially what you're describing is that in the editor, there's a little button to a live preview. So whatever package you're working on, you can get a live preview URL and you can replace your import in your app to this live preview package URL of the package as you're developing.

Oh. Instead of messing it with, yeah. It would replace the need for like an npm link, which is like a giant pain in the rear. Yeah, which never works the way I expected it from.

Never. I always just go into the node modules folder, a hack at myself. I don't feel like figuring out this link right now. So this will give you a URL that you could locally dev on.

Yeah. So you can develop it in the editor and then in your application, just replace the import to that URL and then you get that, you see those changes instantly. So make the changes in the editor, refresh your app and you should just pull in those changes. Oh, that's neat.

Yeah. It's a, again, it's just like we're exploring with possible now that that whole native import system works across URLs, across local projects. Yeah, it's exciting idea. Yeah.

I can't tell you how many times I've like not created a pull request for something because I didn't want to go through. I was like, oh man, I could fix this really quickly. And then I look into it and then there's like like a 3000 line contributing to MD file and all these like, yeah, you got to test it in your local environment somehow. Yeah, you got to all the tests and I was like, oh, yeah, yeah, I can just fix this and do a pull request.

But then all the GitHub bots are going to get mad at me for not doing everything, right? So that would be cool to see like even like how it works with like forking a package and that's using that's the gift and the curse of this, which is that we enforce that you're using this editor for any contribution of the package. So what you lose is that choice. I mean, that's, you know, that's where we're definitely not hiding away from that package is that you're using this editor for package is on registry.

But what you're doing is exactly, we describe where you're guaranteed that every user is seeing the exact same editing experience. They're getting the exact same tools running per change. They're getting formatting per change. So there's no like, LinkedIn errors that would ever sneak into a pull request.

Yeah, like that, LinkedIn error back and forth is the worst dance, the worst part of open source where it's like, yeah, here's my contribution. Oh, great. Can you change this one thing? And it's like, and maybe that person never comes back.

Huh, that's, yeah, that, at first I was like, I don't get why this is its own editor and not like a plugin. But I also never shy away from things that tell me how to do it. Like I almost always prefer like, it's like with Webpack, I'm like, don't give me this thing to work on. Like don't give me homework.

Just tell me how to do it and I'll do it. Just just force it on me, a set of configs and give me a little bit of customization. But, and that's what this seems like to me where you use this editor and it will work. To be totally fair, I've done a terrible, there's just so much to explain at this point that like, I need the time to, or I guess the project needs some time to take a bit to talk about these to post, like those to post documentation.

So we'll see. I think I love this well, but I understand that maybe some people just really love their local development experience. And that's fine too. Yeah.

Cool. So a question I have is like, there's a lot of heat around NPM right now. Just because like, they're a private company that owns all of the code, literally for absolutely everybody's application. And like obviously it ships, like it was started as a thing, but it was, it is a separate company.

And this company controls all of the code to all of your JavaScript applications. And I don't know, people seem to be getting a little bit sore from that right now. So like what does, also from like a security point of view too, right? You just have this random company, like obviously I trust them, but they're still there, that kind of huh.

So like what does that look like on your end? Is this an open source thing? Is this a company thing? Yeah.

Yeah. There's a few different things after I think it will be the most one thing we're trying to spread a lot, where a lot of the power that we see coming from this is that it is a, what's right, we're not closed, but a kind of controlled environment where again, we say that you use this editor and you get all these benefits. It's connected to the registry. So you get all these benefits from that.

That is all by connecting the open source registry to our CDNs that we just by definition operate. But at the same time, we're not at all. That's not like really the project is all about exploring the CSM space and building that new ecosystem. So it's not really about like, and we control it.

Yeah. So one thing that we've been playing around with is that idea that we published anywhere, like a demo and a place for demo and a place for GitHub, but also, and Tropic is the new package manager. We're really excited to get this posted somewhere that that can read from. So that's the more distributed kind of open package registry.

Oh, I've never heard of this. I've not heard of this either. Yeah. This is by and I'm blanking on their names with old people from NPM, split off to start working on this.

It's essentially a decentralized NPM or federated data is the better way. But everyone hosts their own namespace and then you publish packages to there. Oh, very interesting. We should have them on here.

Yeah. This gets back to this, like the fracturing, right? It's everyone's exploring these different parts of it now and managing that is going to be the challenge. It's just given us like three new show topics that we need to cover.

Yeah. What else do you have? Yeah. You said that you like these innovative things, but really it's just like once you take a peek in this world, it's a rabbit hole to fall down.

It's just so much exciting stuff going on. Oh, yeah. Yeah. I'd also say the registry itself right now is partially as an implementation deal but detail, but partially just because it's trying to solve this problem, the registry is a GitHub right now.

So you can actually go to pico package slash registry and essentially we mirror the registry itself into this Git repo. We'll see how long that scales for. You'll get a phone call from GitHub at some point. But yeah, we'll see how long that scales for.

But you know, get the homebrew, I believe is still powered by GitHub. So if they can do that, we can, I'm sure get pretty far. Oh, is it really? I did not know that.

The formulas are. So I don't think the code is hosted in the registry. No, no, the formulas are interesting. Wow.

So we definitely don't want to be this close environment and we're trying not to be at every chance. So anytime a decentralized solution comes up where we're full on supporting that. Yeah. I think it's a great time to rethink all of this stuff because we are in the next couple of years or maybe in the next year, node will be moving over to imports.

And as people do that, it's a good time to maybe rethink some of those tooling and see, is there a better way we could be doing it? And it's really neat to see people putting their time into it. Yeah. Node.

Node. Node. Node. Node.

Yeah. So I don't think they get enough credit for how can't you and that challenge was. Yes. Essentially.

We just talked about that. Yeah. Yeah. Yeah.

They, plus one to whatever you guys talk about. It's because it is so impressive that they found a way to do this, at least to start the process, hopefully it goes well. Yeah. That will be very interesting.

But if you can run an import and buy spec, you can import from URL. Node has never really done that before. Curious if that'll work. You get the same flows, the same import from URL interesting flows in Node for the first time.

And it looks, that's something that Denno or Dino has as one of their features, right? Or you're importing from, are they from URLs? I guess they are from URLs. Yeah.

I think that's, they are very excited about that part of it. So I think that's very much the blessed importing that depends on the URL. Nice. It looks like they do plan on implementing importing from a URL because that is spec, right?

Like that's ESM says you should be able to import whatever from HTTPS dogs.com. As far as I know, Node is trying to one to one support ESM spec. Yeah. So that's going to be, I mean, that's, that, what does that do for, I know that NPM team or X contributors on the MPM team are working on something called Tink, which is a new version of Node that like basically you don't run MPM installed.

It just like installs as you run Node. Oh. I think cats working on that. Okay.

Another guest. Another guest for you. There you go. Wow.

This is a whole world. What does a world of importing by your own mean for MPM install, right? If you even need MPM install anymore? Yeah.

I've seen some people do this where like as you type things, it would just NPM install in the background for you. But some people said that's a huge security issue because someone could like jump on the package of REAC and if you're like import star from REAC and then it quickly installs this malicious React package. Oh, no. Oh my God.

Yeah. Any sort of typo to package? Yeah. So there's like a, there's some weirdness around that, but I don't know, maybe it can be solved.

Yeah. React. Not to jump around, but you mentioned that earlier where it's like one nice thing that we're trying to solve as well is the idea that the registry gets the source code, right? So instead of this idea of, oh, no, the package has been hacked and no one noticed because the Git repo looked fine.

So the developers had no idea that the published tarball was minified. Also just had this little base 16 for encoded virus that just, you know, basically stole all your Bitcoin. That's, that's what we're going to know. The nice thing about having the registry be the repo, which to their credit GitHub is exploring with their package registry as well.

What you get is essentially you lose that decoupling where things can sneak in between the cracks. There's no way that in this world a package that was distributed doesn't match the code that was worked on by the developers. Oh, yeah. Wow.

What an interesting problem. These are all above my pay grade problems. Very, very interesting stuff. Yeah, it's an exciting time for sure.

Wow. Cool. Well, is there anything else you'd like to tell us about Pika or is that? No, this has been a great overview.

So thanks for letting me come on and just spread the good word. Oh, no problem. Thank you for coming on. I benefit of having the podcast is if I have questions about something, just making it do a show.

Yeah, that's a classic. If you have a question, 10 other people are wondering it. They're longer, I guess. Exactly.

Yeah, totally. So where can people go to get Pika to support you? Obviously things like that you can just plug all those URLs. Pika.dev is a website.

So learn more there. Pika package on Twitter. So let's pick up PKG on Twitter and on our website and on our Twitter, there's plenty of links to the Patreon. If you want to get early access to all this and plenty of links to explore.

Oh, and Snowpack. Snowpack has its own name now. So I got to play that separately. Oh, yeah.

Snowpack. Snowpack. That's so cool. Snowpack forms layers of snow that accumulated in geographic regions and high altitudes.

Do you know who that includes? Cool weather. Do you know who that? Cool.

Colorado. Come on, man. We talk about Snowpack all the time. How's the snowpack out there?

Really? Well, we talk about the mountains in the context of snowboarding. Yeah. You should grab the package.

Yeah. Wow. All right. So we do now we do things that are called sick picks where it's just pick an item that is sick.

So sometimes it's a software, sometimes it's an app, sometimes it's a piece of hardware. I forgot to tell you ahead of time. So no sweat if you don't have anything. I'll take it something.

Okay. Every single guest we've ever had includes the statement. I forgot to tell you ahead of time. Just to make you feel better, but it is a trap.

It is. Yeah. My sick pick for today is something I mentioned in our gift guide. I've been spending some time with my Thera gun, which is basically just this percussive massage device that hits you really, really hard, like really hard.

And one tiny little spot just really cranks you. And I've been using this thing on my back because my back and all sorts of muscular issues on my back. And it is the best thing in the entire world. I just leave it on my back and it just cranks into it.