🏗 What Launched Today at Platform Week?

All right. Hey, folks, welcome to Cloudflare TV. And of course, welcomed to Platform Week. Today has been a crazy big day and I'm super excited to have all of you on the call talking to us about the announcements that happened today. The first that we're going to kick off with is James. I'm going to pass it to you to talk through winter CG. Tell us what it's about. Thanks. Thanks, Ali. Yeah, super excited to be here and it's definitely been a crazy, exciting day. Winter, what is it? So winter is short for web interoperable runtimes, so you need to unpack that one a little bit more too. So W3C, what we got is working groups that have been out there producing these Web platform API standards, so things like Fetch and the Streams API, Web crypto, all these kind of things. For years, they're primarily focused on just what web browsers need to implement these things, and they really don't focus on the needs of things like Node or Deno or Cloudflare Workers or these other runtimes that exist out there in the web ecosystem. So what this new community group, web interoperable community runtimes, is focusing on the needs of all of those other non web browser platforms. So it's really going to give us a venue for bringing Node and Deno and Workers and all these other runtimes together to talk about what standard APIs are important to them, what things should just work across all these environments, and also to give us a way of providing feedback into the W3C and the WG and the processes that they're following. So that's the short version of what we're doing. Awesome, awesome. How is this different than other like interests or groups that exist already today? Some of the other groups that exist. So we take what is kind of the canonical example. They're a venue for actually creating these standards right there. They're actually publishing, they do the DOM standard, the HTML standard, those kind of things. And those standards are owned by that by that group. With this community group, we're not looking to create a venue for publishing new specs. We're looking for a venue for discussing and providing feedback into those other organizations. So one of the things we really want to do is liaison closely with what WG to say. Okay? Anything that any new API or any changes to existing API. You know, here's the point of view of these non browser platforms. Here's what we think is important, here's our use cases and that kind of thing. So the key differentiator is we're really an advocacy group for these other runtimes rather than going off publishing our own specifications. That makes sense. And who is in the group? Who are the interested parties here? Oh, that list is growing massively right now. So you know, obviously Cloudflare and we have a contributors from Node, including folks from NearForm and Microsoft and a few others. There's VSL and Shopify are there. We have Deno there significantly. We've got Bloomberg there, we got we're getting more. And just from the announced today, we've already had quite a few more people jump in. So yeah, it's growing. Thanks. I'm curious. You're a longtime node contributor, so I'm sure you've been thinking about a lot of this stuff for a really long time. Why do you think that this kind of group hasn't really existed until now? That's a really good question. I think it's just a matter of it took a lot of building momentum to get. You know, to really recognize these other APIs, these Web platform APIs. There was this long, long standing thing that node is not a browser and so it shouldn't act like a browser. Well, you know, we finally it took us years to get past that. And it wasn't really until Deno came in, came in into the picture and said, No, we're going to go all in on standards and this is important to us. We really started to build up some momentum in that non browser space and workers right from the very start it was no Workers is going to conform to the standards and look at these things. And so it's like the presence of these, these additional runtimes that said no standards are important. It's kind of putting a stake in the ground is really what I think started the ball rolling here. And then. Oh, sorry. Can I ask one more question? You work on a lot implementing a lot of these runtimes, right. And have been for a while. I'm curious, are there any that stand out to you that would have ended up being different had this group existed on either the browser side? Oh, if we were thinking about this from the server and browser side, then this API would have been designed differently or from the node side. Like Hey, if yeah, if we knew that this is the direction that we're going, probably this would look differently. Yeah, I would actually say quite a few of them. So the Stream's API and the Fetch API, those two in particular I think would have not necessarily looked different but would've been defined likely would have been defined differently to allow them to be more modular or easier to optimize these other platforms. For instance, there's a lot that's in the specification that is only relevant to browsers, you know, the core support and the cookie support and that kind of thing. It's, it's in there. It's just not relevant when you're talking about doing fetch on the server. So, you know, had these runtimes been part of that process earlier than those specs would have been, I think would have looked a whole lot different to what they do now. We're not looking at changing them those specs now. We don't want to introduce any kind of anything that breaks or forks or that kind of stuff. But we just want at least want to make sure that going forward these other runtimes are considered. Awesome. Let's talk about xrays and manage components. All right. Why don't you kick us off with by talking about the announcement and what is exciting about it today? Sure. So for us, for quite a long time, we were building integrations with different third party tools into the runs and we were doing it and not the vendors. So we were doing actually a lot of well, we were just looking at their code of their client side implementations and then trying to figure out how to write it, server side or Cloudflare Workers. And this worked great for a while, but now we're like on thousands of websites and one of the biggest concerns that we're hearing all the time is command support for this tool. And for that tool. It's becoming really a nightmare to support. And we want to allow everybody to take part in it and to encourage vendors to write third party tools in a way that makes sense, because we feel like vendors were never bad. They just never had the right tools. So they could only just give you a script to put in your site, but they couldn't do anything that was better with it. And yeah, for in order to allow vendors to write great tools, we came up with this new API called Manage Components that allows vendors to use also website capabilities. So it's essentially kind of like if you would think about letting a third party write a safe Worker to run your website through. And so we wrapped a few of these capabilities. We connected it also with client side capabilities. So it's not gone, it still is there. And if your tool really needs to do things client side, you can do it. And we added to this a permission system that's very similarly to how you install an app on your phone. It asks for permissions, also requires permissions to do different things. So if the tool didn't get permissions to run JavaScript inside and do a lot of things, have a side, but you can trust that it can run anything client side and so it can really all the risks of like a third party tool getting hacked or a third party doing anything malicious for whatever reason. These are now gone with management points. Yeah. So at the same time as we're releasing this new API, we're releasing also well a manager, the manager is the part that runs those components. And we're also going to release basically all of our library, which currently consists of 30 different tools as open source manage components. So you'll soon be able to take all these manage components, take the manager and run them together on your site, even if you're not running on Cloudflare. With this, we're trying to encourage vendors to write, manage components so that well, basically the whole web will benefit and definitely users of cloud resource will be able to use this things, these components with all the benefits of running it on the edge. So which vendors are you guys working with and what have you heard from them so far related to this launch? So we're working with quite a few working with Drift, and we're working with Crazy Egg and a couple of others too. But basically I think everybody are quite excited about the possibility to run tools that yeah, I mean the don't hurt the performance of the site and that are safe because vendors are hearing from their customers that they want to sell foster things don't want requests to go to a different domain they don't want well the risks of it like they're getting a lot of backlash from C so for like adding tons of scripts into the pages and for yeah, for the first time they're getting an opportunity to write it in a way that is secure. So they've been pretty excited about it. It definitely requires some rewrite of the code base, but this was one of the main reasons that we open source this thing, so they'll know that they'll do it. It's not that they'll have to maintain a Cloudflare service version and their old version. We believe that sooner rather than later they'll only need to run, all need to have this manage component, version, and that's all. Like this will be how it is used inside us or elsewhere. That's great. That's really great to hear. I'm glad that we're we believe so much in our model that we're like open sourcing it and just pushing it out there regardless of whether that's on Cloudflare or not. And that's where I feel like a theme of this day, which has been really great. Speaking of which, read out Walk us through open sourcing the Workers runtime. Sure. So I've been working on Workers for the past four or five years and so it's been really exciting to see the platform really grow and we're getting so many more developers in our platform every day. There are 450,000 developers that are building on Workers now, which is was definitely unimaginable when we first started. But one question that I think we received quite a bit over the years was whether or not Cloudflare was going to open source the runtime. And we ourselves build so much of what we built is built on open source, right, including Workers, which is built on V8, which is one of the biggest open source projects out there. And so it was never our intention to keep things from people, but it was something that if we ever did it, we wanted to do it right. And thinking back to five years ago, the team was me and Kenta and three other engineers. I don't think we could have built any of this stuff if we kind of done it in the first place. But the reason I'm really, really excited about this, well, two reasons. One is the ability for developers to develop locally. So actually, I like the are we going to open the runtime hasn't been the most asked question can I develop locally has been maybe the most asked question because that's the first thing that people do when they think up a project. They're like, Oh, let me start trying things out and write a couple of lines of code and kind of understand, kind of like when you're checking out a new game and you're like, Okay, how do I go left out or go right? And so I think it's going to help developers massively with that. And I also think that as a result of that, we'll see a really big ecosystem of cool libraries and tools get built up around it. And then the other thing too, is, like I said earlier, we never intended to lock anyone in. And I think that this kind of goes to show I mean, realistically, it's rare that people switch providers. Like that's always a big effort in and of itself. But this kind of demonstrates our commitment that we want to win because you think that our product is really good and there's so much that we are able to offer by running on our network of 250 data centers, all of the performance and scalability and security and all of the other cool products that you get to use out of the box of Workers object. And yeah, that I'm excited. I think we'll see more and more developers building because they're not locked in rather than the other way around. Right? Like them being locked in. Yeah, I think that's a really good point. And the developer experience of running locally and getting that quick iteration I think is going to be amazing for developers using our platform and also relates to the other two announcements this day so beautifully. Well. Do you want to talk to us about Wrangler too? I know that you came to Cloudflare to help developers move quicker, faster, like make their lives better. Now we have Wrangler to walk us through how we got there. Even so, a quick correction. I didn't come here to help make developers lives better. I just came here to fix it for myself. I was not happy with it when I joined. So for context, I used to work in a bank and that was draining my soul on a daily basis. And for fun I used to hack like I learned about Workers and I was hacking on it. And at one point I was like, I should just get Cloudflare to pay me to do some of this work. But no. So we announced the beta in November and the context for the beta was that JavaScript developers are an incredibly entitled bunch. We get the best looking, best working tools in the world. They might not be the fastest, but actually, no, no. Even though they're quite fast, in fact, and mostly for free and which is great as a forcing function for someone building products for JavaScript developers because you realize there's a high level of there's a high standard for them. And that was the context for why we announced it, not just that we wanted a superior development experience, but we wanted our own developers to understand how the tool was built, which is why we needed to do a full rewrite from Rust to TypeScript, which is very diff, a completely different angle than the other entire industries going right now from TypeScript to Rust. And we went the other way. But I when we announced it, I don't think I was very certain how much work it would take and it took a lot of work to get here and it's really good now. Like, I mean, I'm clearly a biased source, but like it's become really good to use. It's become so much fun. We, we went, for example, I wrote a whole blog post today about ten things that I actually like about Wrangler too. I mean, as a user and most of them have to do with how little work a developer has to do to get working on their own things. Like because otherwise there's boilerplate, there's configuration, and when you're using the Workers platform, you have to log in and all of these things just become side notes. The delta from thinking of an idea to getting to actually working on it is now measured in seconds, which is really nice and I like using it now, so I've been using it to build Workers and it's really fun because now it comes with in-built dev tools, which is again just something the entire ecosystem uses of. There's just zero configuration required when you start, which is awesome because I hate writing configuration myself, especially when a computer can do it for me. You can use libraries from the NPM registry, which is just where half the software of the world exists now, which is just great. Like, in fact, a lot of we used a lot of those libraries just for you building Wrangler I think is one of the now that it's out there, I think it's one of the more popular terminal applications that's actually written and react like this is a whole thing that's written using a front end framework, which is quite fun to do. So that is why I'm so happy about this, because just using Wrangler by myself, I can I can feel how little time I spent thinking about the Workers platform and Wrangler and APIs, and I'm just more interested in working on my fun little apps and making a little websites for my friends. So that's where it is now, and that's why I'm so happy that this is finally out there, because now we can actually work on the things beyond it. But yeah, we kind of fixed Wrangler Yes. Reader Can I say what my favorite thing is about it? The errors are just beautiful. They're immaculate. You get an error for every single thing. You know exactly what you're doing wrong, which I think is so cool. And I feel like kind of going through the migration process from the first one to the second one, we just tightened up the developer experience so much and really put it under scrutiny to our yeah, you just get not just the errors but you get so many helpful hints and things like that too. Now. Yeah, it's just very, very polished experience. Are you telling me that errors make you feel good? They make me feel so good. I'm just referencing readers. Twitter bio. Of course, one of the design principles we actually did was not only should we have an error which tells you what's wrong, but can we have something that you can copy paste into your code or configuration to fix it? And Oh my God, people just love that because it's very much muscle memory. They're like, Wrangler will just tell me what's wrong and I'll just copy, paste, whatever it tells me and it'll just work like I can. Just. So that's been such a good. Rinse and repeat. So the work on making it look good and actually feel nice was actually Pete. Pete spent so much time on. Nobody does design systems for clothes, but we took a crack at it and made it so much nicer to use and read. So that's that's been really good. It's been good. How did you get confidence in the Polish? So did you guys watch people use the clip or how did that work? What was that process like? So we did we did a bunch of feedback sessions with the community champs. Such a good source of feedback, by the way, the Discord Community and the Discord Community Champs, which is like a smaller group of people where we keep showing early stuff for weeks, for months and weeks they've been having a look at it and they've been talking about why does this not work? Well, they were so worried about will our older projects still work with Wrangler to what does this error message mean? I don't know what to do here and just by so a by looking to our community, but B also but just by using it ourselves and being brutally honest about this is kind of shit you guys like we kind of need to make it better. I think that's what it is like by trying to build something that we and the people and our community would actually like and enjoy using. That was a great thing to keep talking about while we were building the thing. I think that's that's why it's I think that's why it's turned out to be so nice. And if it's not, then we're pretty sure we'll get feedback and we'll fix it immediately. The other thing we have done is that iterating on this code base is also really nice. Like we can run the entire 500 plus unit tests in under something like 7 seconds right now as opposed to like minutes in the previous code base. So we have also made the code base itself really fun to write in and implement features. So every time we get feedback, we're like, Yeah, let's fix that in 5 minutes, put out a release and have people using it. And that's been incredible to iterate at it. I think we have done. I want to say at least 500 bills in the last five months. Yeah, I think we've done 300. 500? Yeah, it's been pretty great. Yeah, that's amazing. Quick iteration. That's awesome. Going into the last developer experience announcement, today was our project with Stack Blitz. Do you want to talk us through what we did there? Absolutely. So this announcement actually builds really, really well on the Wrangler two announcement and that it wouldn't have been possible without Wrangler two. So one thing that we actually didn't talk about was that Wrangler two was a rewrite of Wrangler one, which was written in Frost, and Wrangler two is fully written in JavaScript. And so the really cool folks at Stack Blitz, what they've done is they've built basically an idea, full scope experience that runs entirely in your browser, and they have this technology called web containers. Or basically they can, they can take Node and run it directly. And this is a crazy thing. Like it doesn't run on like some server somewhere, it runs all directly in your browser and so it can literally take Wrangler to and spin it up in your browser. And so if you go now and type in Workers New or Workers Unbound slash one of the startup projects that we have, like Workers Unbound slash typescript. If you want to start a TypeScript project or I think like Workers Unbound slash router, you're within just seconds. Given a brand new development environment with everything already booted up, everything configured can just start. Yeah, you can just start writing code and using Wrangler and you can use Wrangler dev to test things out and you can publish it just like a really, really neat end to end experience. Yeah. How did that conversation with Stack? Let's start. How did we come up with this idea to work together? We first talked to them, I think a few years ago, and it's always felt like there was a lot of synergy between the products. But as these things go, I think you kind of chat and then everyone has their own roadmaps to execute on. And so that's where I think these innovation weeks are really cool. So I know Eric knows a few folks on our team like myself and Dean Igor, because the stock folks and the Angular folks I think have worked together quite a bit in the past. And yeah, where these innovation leaks are really great is that they kind of create this forcing function of like, okay, we're getting closer, we're making some announcements, you want in on this, and they happily oblige. And so, yeah, both teams on both sides and a lot of this was really great work. Yeah, like I said, on their side by Dominic and Eric and also on our side, Adam Giannis who I'm representing today, did a really, really great job kind of making it happen. So yeah, that's, that's kind of how it came together. It just seemed very mutually, very mutually exciting for Stack lets users get a really easy deployment target to deploy to and our users get a really fun, friendly interface to try out Workers without having to download a single thing. That's awesome. And then question to anybody, having us put out these blog posts is really great. Obviously we get a lot of response and traction. What responses from today have either been really, really great, cool or surprised you in any way? Like what? What has the response been like to the announcements we put forward today? I've just been enjoying seeing how positively the community has reacted to the news about open sourcing thing, saying, you know, yeah, there's, there's folks that are out there just like, okay, well, can I, can I look at the code? Yeah, we have a little bit more work to do before the code is actually out there. So, I mean, so it's, you know, we're getting there. I can't wait to get that out there. And I know folks are going to be super excited once they actually have it in hand to play with. Yeah, that's going to be really cool to see and I can't wait to see what people do with it. I think, ah, there's going to be a lot of fun projects that come out of it. Definitely. For the Wrangler announcement. I got a couple of things, which is a very specific type of feedback that a user interface developer like me gets that makes me very happy, which is, Oh, it felt so magical where it realized it didn't find my API token popped up or login and it just worked. Thank you for doing this with Wrangler. I was like, yes, that's the thing. Actually, I'm also supremely excited about what Wrangler and stuck with snow means because it means very fundamental things. The first one that I noticed is if you have a bug, you can say, Hey, I made a reproduction, just do git clone and npm install and npm dev and you'll see. So this used to be very hard in Wrangler one day, but now it gets even weirder because now you can say here's a link to a stack bootstrap, which is and it doesn't have to be just for a bug. It can be for every PR that you send to a Worker project abort drops a comment which is here's a link to a running version of this of this PR, etc. And I already got that's the backchannels that I'm involved in. They're like, When is that going to happen? When can I write a GitHub action that merges this? And I'm like, Give us like 20 minutes to just sit and enjoy the fact that we just released this. We'll get to doing that tomorrow. So I think I'm really excited about the fact that people feel a lot of their problems are solved now, but they're already starting to think of, well, what can we do with all these fun things in the future? That's been wonderful actually, to listen to. That's a good point with each of these announcements. It really is just the beginning, right? Like it really is just the beginning. And there's continued investment, continued pushing on each and every one of these, which is pretty fun, actually. That means we're talking about big stuff, which is great. It's also just the beginning of the week somehow. I think that's the thing that keeps surprising me. I'm like, Wait. So it's day one. It's day one. That's right. But don't get smaller in case anyone is watching. It's going to be a fun week for sure. Reed any any traction or reaction. That's been interesting for from your perspective. I think I'm very much with James in terms of, you know, we usually announce. New features or new products. So this is a different type of announcement for us. And yeah, you never know how these things are going to be received. And especially, you know, open source audience can be a particular type of cranky as well. So I was like, oh no, you know, am I going to get in trouble today? But now everyone just can see what a big deal it is for the Web and how much it's just going to move everything forward. And so, yeah, I think the reaction has been overwhelming. And people, yeah, most mostly seem excited that we're going to release the code, not the. Yeah, I know like questioned why we're doing this or anything like that. And I don't know, I'm really impressed with how much the all of these flow with each other like you could announce open source without announcing winter. And also, I'm excited about what the open source runtime means in terms of local development and Wrangler. Like I cannot wait to get the two integrated so that Wrangler dev instead of calling into mini player which has always had a few discrepancies, can just spin up a runtime locally and like just get like one for one experience right there. That's great. Any closing comments? Thoughts from folks on this call? No. I'm just looking forward to the rest of the week here to see what else, see what else comes out and how the community reacts to it. So it'll be fun. Yeah. Yeah. I feel like by Wednesday it's going to feel like they were two weeks in, but. Yeah. Awesome. Well, thank you guys so much for your time today. I'm going to end this meeting now. All right. Bye, guys. 80.