Ep. #55, Smaller Builds, Less Tooling with Fred Schott of Pika

Brian Douglas: Welcome to another installment of JAMstack Radio, on the line we've got Fred Schott. Hey Fred, you want to say hi?

Fred Schott: Hey everyone, hey Brian. Thanks for having me.

Brian: Yeah, yeah. You're coming all the way like, I guess what is it, seven, eight miles away in San Francisco from me?

Fred: Yep. Yeah. It's a radical technology here to connect two people from such a far distance.

Brian: Yeah. Yeah. So Fred, I've been noticing this GitHub repo that I've seen people tweet about and people have been using it, it's the Pika package? Did I get that name correct?

Fred: Yeah, that's our org, then we have a few different projects within that.

Brian: Okay. Could you just explain what you do, sort of how you got into this space and then we can sort of talk about the org and then the projects inside of it?

Fred: Yeah, I'd love to. Yeah. This is essentially my full time, kind of a focus right now, so it's a project that's near and dear to my heart.

Essentially what we're doing is we're taking a look at all the tooling that's been built up for web developers over the last 10 years and questioning it, and where we can, pulling it apart, ripping it out, and pretty radically simplifying it.

Brian: Wow. And you said full time, so are you taking like sponsorship dollars, or are you like self-funding your lifestyle while you're doing this open source work?

Fred: A little bit of everything right now. We have a Patreon community of people essentially supporting the project, supporting the work.

I've done consulting work, just things to kind of pay the bills.

I only really started this full time, I'd say back in June of last year, so fairly recent still, although I guess that's coming up on a year.

Brian: Awesome. We can shift gears and talk about the Pika org and why it's an Oregon.

Like how big is the team? Is it just you working on it? You're taking a bunch of open source contributions, like how's this working for you?

Fred: Yeah, so I can give the history of how it all started, which I think kind of just paints the picture of where we are today.

Brian: Yeah, that'd be great.

Fred: This really started by looking at one technology, specifically called ESM.

So if you're familiar with that, that's like in JavaScript, it's the import statement or the export statement.

Five years ago it was fairly new, I think it was finally spec'ed out in the browsers, and the first browser is essentially shipping support for this back in 2015, 2016.

But today it's a pretty common part of JavaScript development where you import a dependency or important another file using this statement in JavaScript. Actually that one word, really solves a ton of huge problems up to this point, we've essentially used tooling to solve for us.

So this idea of importing code in the browser, this was something that really we'd always gone to build time tools to solve.

So if you're familiar with Webpack Parcel, Rollup, Next JS, all these different tooling frameworks.

At their core, what they're doing is letting you build an application, and then they can essentially kind of bundle it all together and ship to a browser that up until 2015, 2016 had no way to load code on its own as a JavaScript application.

So this is a really kind of fundamental technology, that to us as developers is just this kind of one line word that you ended up importing your code with.

But at its core it's really unlocking the browser to do some really powerful stuff.

Brian: Yeah. Like I'm familiar with the, ES modules and then all the other tools like to do that.

I did not start my career in JavaScript, I started my career in a service sign language Ruby, and so everything just sort of like just worked, but when I got to JavaScript and got to node, and thinking that I could just like work, at the time it was like require this and require that.

And then the import statements started coming in and like how you bundled your JavaScript was like different in different situations.

I don't understand those like, I still to this day don't understand when I would choose one or the other, other than like bundle size.

So am I understanding correctly that you saw that, the import statement, and you have a project like within the Pika org, that solves that problem?

Fred: Yeah. So I'd say that was really how we came really to the core of what we're doing, is exploring that technology and then building different tools or different features around how you can leverage that technology today to increase your developer productivity, increase your site speeds, really kind of anything goes.

The background there is just that, on its surface it sounds like one of those things where, what's that famous comic where it's, 15 different standards, we should really create a new one that solves all these problems and now you have 16 competing standards.

A great example of that, is what we're looking at where it sounds like just another standard, but really what it is, it's letting the browser do this work natively.

So unlike every solution that comes before it, it's letting the browser, do what the browser has been doing for, 20, 30 years now, which is loading your dependencies for you, loading files, prioritizing caching, so it really unlocks a lot of cool technology.

And then essentially our projects, Snowpack is a really interesting one that we can talk about.

Essentially lets you replace the bundler in your application and really speed up your dev flow, your dev, iteration speed by not having to do all this work that Webpack is doing today.

Brian: Okay. I know Webpack is, I mean, it's a big project as he says.

I've been using Webpack since almost the beginning, and yeah, it's amazing how many things you can do with it now.

So as an alternative, Snowpack is alternative to Webpack. Am I understanding that correctly?

Fred: Yeah, more or less.

Brian: Okay.

Fred: Yeah, it's funny though, cause it's like we are the anti-bundler that still does some bundling.

So it's like we get to be, kind of playful and that we get to challenge the status quo and say, you don't need a bundler for most of what you're doing.

But if you really peek under the covers, we're powered by Rollup, which is another popular bundler, so--

Brian: Yeah. Which is also super lightweight as well.

Fred: Yeah.

Brian: So I have been doing these live streams on Twitch/Periscope, I've been re-streaming them multiple places, to try to figure out where's the best place to do it.

But regardless, I was doing a live stream earlier today where I was building a good of action.

And the question came to bundling your node modules, cause you're going to have a couple of different modules, to make your action work to get an API.

So you bundle it, and I was using a tool that I put out with NCC, not even sure what that stands for, but is that also similar?

Like do you have a solution that's similar to that, where you bundle the bundled versions of your packages?

Fred: Yeah. So I'd say all of these tools, NCC and there's a few other, are tackling the idea of bundling code, taking a lot of files and bringing them into one.

So Github actions, right? That's to get around their limitation where it kind of needs to all be in one file.

The web is an interesting place for this problem because it's essentially a requirement just like it is for Github actions, that you bundled up until this technology existed.

So I gave a talk, where we kind of explore the history of that.

But really, the story is just that when node and NPM got so popular, if you go back even before that, there wasn't actually that much bundling going on in development.

It was kind of seen as this production time tool. So you would essentially be iterating in development, you'd do make up chain and you'd see if it reflected in the browser. You'd be dealing with individual files and then in production, to get around essentially limitations in the network, you'd run a bundle or you can catenate all your files together. It was this really, naive solution compared to what we have today.

But NPM becoming such a popular network of code, this was a great thing overall, but the one sort of concession, that web developers made when we joined that network of code, is that now you were relying on code that couldn't run without a bundler.

So bundling around that time, shifted from a nice to have production optimization, to a required at every step of development tool.

So the reason, Webpack is so popular, it does a lot of things for you, but it also is a required part of development.

If you make anything required, it's going to be popular and a well supported.

Brian: Yeah. And I'm curious, with your experience on I guess the bundler, not bundler side in the build side, that the way the browser works today--

Was it six months ago, nine months ago Edge, started being built on Chromium, if I understand correctly?

Fred: Right.

Brian: So now you have Edge, and Firefox, all sort of similar, but then you also have Safari doing its own thing.

How do you feel about now, that everybody's now bundling their code and it's working?

Is that just to solve the problem where you don't have to worry about legacy browsers and worry about different flavors or different platforms?

Fred: Yeah, I'd say that's definitely kind of an undercurrent or maybe like a tailwind happening right now, underlying all of this, which is that, every browser now I think is evergreen, where even enterprise customers are upgrading really rapidly.

So Chrome, Edge, they basically tell you, even these large customers we don't support past a few versions.

Compared to the IE model where it's like, "no, as long as you're on windows XP, we'll support this forever".

And then the entire web is stuck supporting your IE six until the end of time.

Thank God those days are behind us. But yeah, that's the interesting thing, is that the web platform itself is becoming more modern.

So features and our new technologies are able to kind of make their way into the mainstream much faster.

That's really what we're taking advantage of right now, what we're exploring, is this idea that you can start to leverage this new technology in production, which again, we all write imports, we write exports, we're doing that at development, but the shift is actually thinking of that as a production level step as well.

I'm shipping that code to the browser now that it can understand it.

Brian: Yeah, that's interesting. And then I'm curious, like I build my functions before I ship them over to AWS or to Lambda itself.

So do you also have a tool or is it Snowpack or is it something similar to compile stuff to be ready for other platforms that aren't web?

Fred: Yeah, so here's the magic of it all, is that by using this technology, you can essentially, so using ESM and using Snowpack to help--

What we do is we really look at this problem, right? We're challenging all the assumptions.

What we see is we say, okay, bundling was taken as this requirement to work with NPM code, it was to get around this limitation where the code on NPM wouldn't run in the browser without a bundler.

It was written for Node, it had all these Node-isms. So bundling became a required step no matter what level of development you are at.

Now that we have ESM, we can start to revisit that question, which is that I actually now have a way to write my application, in a way that doesn't need a bundler.

So again, you're using functions or good of actions, that's the requirement of the platform that you use a bundler.

The web actually doesn't have that requirement, it's just, it's we've had that requirement based on the code we're using, not on the platform, if that makes sense.

So now that we have the ESM imports, the browser doesn't require a bundling anymore and we're kind of free of that requirement, but we still use it anyway.

What's Snowpack lets you do is it says, okay, you have this technology, you can write your application in a certain way that you no longer need the bundle.

You can essentially write your code, deploy it to the web and it'll just run in the browser.

The only problem still is that MTM ecosystem, it's a slower moving animal. It's over a million now? A million packages? It's some huge number of packages.

What Snowpack does, is it takes that bundling solution, but it just applies it to your dependency.

So essentially another way to think about it is it's like an NPM install for web developers.

It takes dependencies and gives them to you in a way they'll run in the browser natively.

So now you have the CSM technology, you use it to write your web application and you just run Snowpack once essentially as your install step to give you dependency.

So now all of a sudden, you don't need a bundler that is running every time, you would say that, that's pulling all this code and re-bundle and reshape it.

You get a much faster development experience and a much simpler one as well.

Brian: Okay. So you're saying that, so like normally I would run, well in my NPM run build, like normally that's running Webpack.

So you're saying just by having an installed in my package at JSON, it's going to have that bundle for me? Or do I explicitly run like a still pack CLI command?

Fred: Yeah. It's even cooler when you build your site you don't need to run a bundler, is what we're saying.

Essentially we moved that tool into the install step, NPM install, run that, and then run Snowpack once and then now you have your dependencies they're ready to go.

So you work on your code, you ship it to the browser, it uses these dependencies that you installed with Snowpack.

Brian: Okay.

Fred: And essentially you're good to go. Every change you make happens on the file system that the browser understands.

Brian: Yeah. That's great.

Fred: So you pull out a whole class of tooling.

Brian: Yeah, I'm a fan because I think some of the things I I'm challenged with is when I approach web development to a newbie or a beginner.

A lot of times you have to skip a bunch of steps.

So like I did a tutorial, a JAMstack tutorial a couple of years ago, like 2017 and I was trying to show one of our event managers who would just wanted to know how to code a couple of weeks ago.

I was like, "Hey, I built the tutorial, see if you go through it, it will work for you. That's three years later."

And he's like, "yeah, I got stuck on this, like I'm getting NPM errors or something."

And I was like, "Oh yeah, you have to NPM install" and he's like "okay that works," but I'm also getting this other thing.

It's like teaching someone who just wants to move JavaScript around or even just HTML around like there's too many steps to get to that point.

So if you're saying, if you just hit the install step or like if you do like a magic button where you clone, install, build into like a code sandbox or whatnot, that's like the best of all worlds and we can just move on and solve other problems.

Fred: Yeah, I think you hit the nail on the head there.

It's this-- We're really failing beginners right now, especially where, the web specifically what I fell in love with was this idea that you could just write some code and deploy it and really visually see the things you were working on.

It was this really nice iteration of this feedback that you got really quickly.

If you read a beginner's tutorial, I mean, tutorial today it says install this, install this, run this, set this up.

Or you then have to find a Create React app or Code Sandbox.

Those are good solutions where they essentially abstract that complexity for you.

But that complexity is still there, you spin up a Create React app and I think you start with 200 megabytes of dependencies.

Essentially 1200 different packages like something's going to go wrong, something's going to get out of date, you're going to get errors and as a beginner, especially you're in the worst position to understand how to solve those on your own.

So we're really setting up people for failure instead of success.

Brian: I guess maybe you laid it out pretty well, like why would you use Snowpack over something else out of the box?

Maybe it's an inertia, but I'm curious like what are the different audiences that you're seeing or users that you're seeing that are attracting themselves to something like a Snowpack?

Like is there a certain thing that I need to be thinking about or some sort of ceiling I'm hitting with something like Webpack?

Fred: Yeah.

I'd start off by saying that we see this as being the way we'll all be doing web development in the next couple of years.

So it's a pretty bold idea, that we see as being, so compelling at its kind of core surface and as an idea, we see this not going away anytime soon. Snowpack then becomes our kind of bridge to get there.

Today I'd say, at beginners, it's a great way to get started, just because you run NPM install and you run Snowpack and now you are essentially editing code and seeing it directly reflect in the browser, no tooling, no belt step required.

From there, it just becomes about what are you interested in?

If you love the idea of just like a huge tool and set up, it's just everything you want to do, a tool is there to help you out. Maybe a bundler actually is exactly what you want.

Really what we're getting at is the requirement to have a bundler. We don't think it should be required for beginners, for anyone.

If you want something that's lower tooling with a faster iteration that's essentially doing less every time you hit "save," then that's the idea that we're building towards and that's what Snowpack helps you do today.

Brian: That's awesome.

Fred: An interesting kind of part is, what does a bundler do today, that is magic, that is more, maybe not allowed by the web platform?

One of those things is, importing CSS or images in your JavaScript itself.

There are some things like that, where that's actually never been a standard thing.

The bundler introduced that idea, not the platform of the browser.

So there's some things that you kind of have to revisit when you're building without a bundler.

When you're building code that actually needs to run on the web directly, you need to start looking at runtime solutions or just different babble, essentially different solutions that aren't just import CSS.

Brian: Yeah, I think the CSS question or conversation has gotten really interesting in the last couple of years as far as web development goes.

And I'm a fan of style components but it's, I'm not even sure if it's just inertia at this point.

I learned it early enough and same thing with Webpack, I learned it early enough, I've benefited from knowing it in my career for the past five years and I'm good.

But if I want to teach my son who maybe want to start programming the next couple of years, like he's sort of out of luck, unless he is ready to like really figure out the stake and why CSS works this way.

And I don't want to talk too negatively about Webpack cause they've come a long way as far as attracting things and making it less hectic and complicated, but also there is a lot of complication when it comes to looking at plugins and stuff like that.

Fred: Yeah. Just to be clear, Webpack is incredibly impressive program, it's the requirement for it that we're really addressing and really tackling that everyone needs to use a tool, that's no longer the case.

It was, and then Webpack served that need beautifully, but we're now in a different era.

The platform has upgraded and we can start to revisit that assumption.

Brian: So you're at this point you're working, I guess you're going to coming up on a year of doing this full time, what's next for the Pika package org and Snowpack?

Fred: Yeah, that's a fun part about getting to do this and really taking a look at a larger technology, is we kind of just get to constantly ask that question and I'll constantly try different directions.

I'd say there's two things we're focused on right now today, one of them is getting our package editor open-sourced.

So back in December, I think it was, we announced it a code editor for packages.

So this idea that NPM makes it really difficult to build a good package.

It's just kind of like open canvas, which is great for flexibility, but what you end up with and as an ecosystem where everyone's doing something in a different way, someone's shipping TypeScript, someone's shipping a Coffee Script, someone's architected their package this way or that way.

It's kind of a mess, once you start to peek under the surface, by I no fault of any developers just because there's so much freedom, you end up with an ecosystem that's very kind of wild West.

One of the things we looked at, was how can you actually build into a code editor itself, this opinionated package structure that does a lot of the work for you.

So TSDX is a great example of an open source project doing this today, but we take that idea a step further where we set up a project for you in an editor itself.

So you can see live demos, you can see your test run, you can see documentation gets generated on the fly as you edit, all tied into the development experience.

Brian: Yeah, that's an interesting problem to solve too as well, and I always have the same issue of updating my Node releases and packaging that and even like the disconnection, I know the announcement of NPM and Github's acquisition was announced a couple of weeks ago, but it's still in progress, so who knows where we'll be in six months.

But just getting a new version or a new semver version of your release, there's all these different steps I know some people are using automations and other tools to basically adding different words to your commit like chore or fix or whatnot, and that sort of like acts with like the CI and makes other stuff work like magically, but there's no consistency.

And I spent a couple years not working on a full time project, so when I go to a project that actually is doing something consistent, I'm completely lost, even though it makes sense to everybody else.

So I've had an opportunity to work in some open source projects, where they're just adding all these prefixes to our commits and I have no idea.

So like when we talk about having structured, like editing with packages and I think that there's a benefit there too as well, when you start thinking about, you had mentioned it testing, where it truly comes to mind.

So if I want to test like 0.1 to 0.10 or 12.1 or whatever all those different versions, at least in my mind, I can know when I'm testing it, there's a consistent way, a way that how it's been packaged as opposed to like, we did stuff way different back then, like there's no consistency or whatnot.

Fred: Yeah, it's a constant struggle of the internet, right?

Where everyone wants the freedom to do whatever they want, but then when you look at that holistically with no guardrails, you end up with, on the surface what looks like a mess.

And if you're trying to move from project to project, it's new standards, new patterns.

So it's where do you draw the line between, everyone wants the freedom to do it, it's open source, we're all doing it for fun.

B ut then yeah, how do you draw that line of adding intentional stability to the platform?

Brian: Yeah, and that's what I like about projects that already adopt things like Prettier and whatever Linters and enforce that at the time of either save or at the time of when you open up the PR like--

Touch the code how you want it, like I'll learn eventually how to make this the proper way but I don't want to constantly hit my head against the ceiling every time I try to ship a small change and then I have like a weird like ESLint thing.

Fred: Every time.

Brian: Do you have a name for that yet?

Fred: I think we just call it code or like editor.

It's kind of like Pika editor so we're still trying to figure out what that gets named.

Snowpack is a great example, we just called it web installer I think at the time, and then we pulled it out from the org, gave it its own name.

We'll probably do something similar with the package editor when we open source it.

Brian: Awesome.

Fred: Yeah, so I'd say that's our kind of focus number one.

Number two is just taking this idea of, Snowpack does a great job of painting this world that you can join when you throw out your tooling.

You get this tooling free, tooling light development workflow, that's just faster for everything, it's a little simpler.

Yeah, we're big fans of it obviously. We're also looking at our CDN as a way to start to bring those advances to traditional bundled sites as well.

So back in August we launched a CDN, essentially every NPM package hosted as an ES module.

So no matter how the package is written, again, you can tell there's some similarities here where every package is written differently, which is essentially what the bundler's doing. It's converting those all into a standard pattern that runs on the web.

Our CDM does something similar, it takes every package and host it in this one unified format.

So you can import any package from our CDN, use that import statement, use that ESM import statement.

We see that actually having a, again it's a simple one line kind of one word solution that actually has a huge impact on how web applications can be architected.

Essentially, what does web development look like when you no longer have to bundle all of your dependencies into your application? When you can just deploy the code that you wrote and then build on top of a CDN like that, where every dependency is hosted, optimized, cashed really well--

We're trying to build out this foundation that you can build on top of.

It's really fast and really stable.

Brian: Awesome. Well I look forward to seeing what you produced and what comes out of the Org and I will definitely give it a follow and actually I'm planning on probably trying Snowpack for some of my smaller projects, I need to get my hands wet on that.

Fred: Oh, definitely.

Brian: I guess my hands cold on that, I'm not sure if I should lean into the naming.

Fred: How long have you been saving that joke up?

Brian: I had to find the right time, and it comes with class and I'm not a dad for no reason.

Fred: Exactly.

Brian: Actually on that note, I was curious about the, logo they had the mascot for the Pika package I'm like staring at it, this entire conversation. What's the story behind that?

Fred: Pika the name just comes from this dumb alliteration of Pika and package. Pika package, Pika package this and that.

The logo is just a, so Pika is a type of mouse. It's small, it's fast, the logo is just a mouse.

It's a playful mouse, it's kind of a fun, open source vibe, that's what we're going for.

Brian: I have got you. And I like, I do like the name Snowpack though.

Fred: Oh, thank you.

Brian: Yeah, so definitely weight into that. If you do any conference talks to expect a full garb as if you were scaling Everest.

Fred: Yeah, that's not a bad idea. Not a bad idea at all.

Brian: All right, well on that note, I do want to transition us to picks, so these are jam picks, things that we're jamming on, it could be music, food related, it could be technology related.

We chatted about this all fair earlier, but if you don't mind, I'll go first and I'll give you some time to prep your thoughts.

My first pick is going to be sourdough brownies.

Podcast listeners know I've been working with bread for the past year now since my daughter was born.

I just had this opportunity and a lot of free time during my paternal leave to learn how to make a sourdough starter.

So I have that and I've been, now since we've been forced quarantine and sheltering in place, I've been making bread a lot and I live walking distance to a Trader Joe's and a Safeway.

So there's like a limit of one bag of flour per visit, and I'm not, like not as bad as toilet paper, I am grabbing my one ration bag of flour every time I go, but now I have like five of them on top of my fridge.

So I'm looking for other ways to make bread in sourdough specifically.

So I'm looking forward to--I've actually got batter going right now, and I'll have sourdough brownies tonight. So, I'll report back on Twitter.

Fred: That sounds fantastic. I had the exact opposite experience where I made bread once, nailed it, and now every time I try it actually is worse and worse and worse.

I don't know if I just got too cocky, too confident. I have no idea what it is but

Brian: Yeah you should just quit while you're ahead

Fred: And do the one and then that's it, I'm never doing it again.

Brian: That's how I feel at CSS animations. My other pick was a one blog.

So I've had Shawn talk about OneGraph, says it's like a, it's like a one stop solution for your Graph QL APIs, just APIs has a general and they just came out with a new tool which is OneBlog.

It's still pretty much alpha they're still working on it, but they gave me early access and told me about it and I've been using it for my streaming site, which is MutualFun.live, essentially what it does is it makes your Github issues into a blog, so every time you have opened up an issue and attached to published a label on there, it actually publish a post to your OneBlog.

So I'm very excited, it's built on top of razzle, that's built on top of create react app, which if you know what react is.

So it's like just a light solution on top of Create React app. Yeah, I'm super pleased with it, I'm looking forward to actually playing with it this weekend.

So that's for me for picks, Fred you got some picks?

Fred: Yeah, I have one. We are throwing a conference. So there are, obviously it's a lot going on right now, not a lot of traveling, not a lot of conferences happening, but we're trying to look at this as a opportunity to explore what a remote conference looks like.

So a couple of weeks ago we launched ES next, which is a fully remote conference. It acts a lot more like a film festival, so we're trying to follow that model where, way fewer talks spread out over more days.

Brian: Oh I like that.

Fred: I think the website URL is esnextconf.com, It's five days, 12 talks.

By the time you're hearing this, I hope we will have lot announced the speaker list and all proceeds go to a Coronavirus research fighting the fight, the WHO has a great fund for that and we are fully supporting that, with all ticket proceeds going towards that.

Brian: I liked that. I liked the idea of actually, since we're already sitting at home, spreading it across five days. And you said, alright was it

Fred: It's like a film festival.

Brian: Like a film festival, yeah.

Fred: Or like a South by Southwest like, I always get so overwhelmed when there's an online conference and it's like back to back to back for like three days.

Brian: Yeah, it's eight hours straight, yeah.

Fred: Yeah, and no one has time for that, I certainly don't.

Brian: Now you ended up just going to one talk and maybe hanging out in the chat, but I think I'll figure out how to do remote conferences now since I'm going to be remote.

Fred: Yeah. Well, Hey, if you're interested in giving a talk, I see you already have the green screen, we are shipping a microphone and a video camera to every speaker and a green screen, so you might not need that, but I'd love if you could give a talk.

Brian: Excellent. I actually, I'm very intrigued, I might actually drop a CFP down there.

Fred: Oh, that'd be awesome.

Brian: I will definitely be attending, I'll find time in one of the five days to catch one of the talks.

We were toying with the idea of doing a conference and feel free anybody to steal this, do a conference, but instead of have like talks back to back, like as we had mentioned, this is not--

Like it's more of like a marathon at that point, but instead have like a live DJ play remotely and then have the chat going so it feels like you're at a party.

So feel free to, if you want to find some of them, cause there's a lot of people out there doing a lot of music, but I would go to that.

Fred: That's really cool.

Brian: And chat with a bunch of devs while music's being played.

Fred: Nice.

Brian: So Fred, thanks for coming onto the podcast, talking about the Pika package, and listeners, keep spreading the jam.