(bright music) (audience applauding) - Hey, everyone.
It's really cool to speak in Melbourne.
That's how I was going to start my speech, 'cause I finally get a chance to bike and cycle into a conference.
Yeah, remind me again why I moved to this place? But yeah, so evolution of web, as John said, we're gonna start at the evolution of the web. So where it came from, where does it come from. ("Praise You" by Fatboy Slim) And before that, what I really wanna do is celebrate. So do I.
And there's obviously no better way to start than to pay homage to the patron saint of programming, Ada Lovelace.
Who in 1842, not 1942, we'll get to that in a minute. 1842, so basically pioneered this whole notion of programming and what we're doing.
And then we have to fast forward a long long time, pretty much exactly 100 years.
When we get to the 1942.
We have the first digital computer, one of the first, the ENIAC.
This is only a part of just how massive that thing was. Tens of thousands of switches.
And the problem was, they have the men that had built this thing that were then shipped off to the front. And there were these six women.
They were basically told, well, this is really big computer. And we needed to figure out how to use this thing. No one knew.
So the six of them had to figure out how to use this computer.
They did some tremendous work.
One of the amazing stories about this though is that they were completely forgotten about three years later. It wasn't until decades later when someone ran into the photos, what's with, what are these women doing there? Well, they invented computer programming.
That's all they really did.
Fast forward, one of the other big patron saints of computer programming, Grace Hopper came around. And she basically went like, this whole machine language thing, binary thing is probably a little bit too hard.
We can write in higher order languages and have that compile.
People thought she was absolutely batshit crazy for suggesting the idea of a compiler, but I'm very glad she did, very very glad she did. Going on quite a bit further until we get to Arpanet. Bob Taylor is one of the people that had this vision of this computer network that could span the globe.
He's the person that got the funding and got this started, really really cool, visionary person, driving the vision forward of this Internet.
Ward Christensen, 1978, massive blizzard in Chicago. Basically, everyone's stuck in their house. No one can move.
What Ward was stuck with though was this really novel, really new invention called a modem.
Who's old enough to remember modems? There's a bunch of people old enough to remember modems, cool.
So you had this modem, and what Ward set them up to do was how do we get these two talk to computers directly? He builds the first BBS, Bulletin Board Systems. And they were amazing pieces of technology. You could call, from your computer, you could call another computer.
And then see the stuff that was on there, and you can, you could look at information, you could play games. But there was this really, really, really new and novel and weird.
I remember having arguments with my mom, because I wanted to use the Internet and she wanted to use the phone.
Remember those days? Those were the days.
And it wasn't any different on the other side, because the other side had a fixed number of phone lines. So you're calling into the BBS, and it was busy. The website was busy, there were already three people on it, then there were three phone lines.
Well, I'll try again later.
Mom, you can use the phone now.
Yeah.
But it's always been very intriguing to me. And then another unsung hero of the Internet is Radia Perlman.
She invented this very little known protocol called the Spanning Tree Protocol.
And basically, what she allowed to do with that Spanning Tree Protocol is connect different networks together.
Before that, we had ethernet in one place, there were these really long distance thing, but she made it basically possible to do bridging and to connect not just a couple hundred computers together, but infinite amounts of computers.
Hard to overstate the impact she's had on this little thing we now call the Interwebs. Fast forward just one year.
I was doing some research.
The history of the Interwebs.
And came across this browser that I've never heard of called Intermedia.
But it's Nicole and her just partner Karen. And they invented anchor links, and they get the hypertext that was already present and made it more and more useful. You could now link to parts of a document.
And the thing that struck me is that Tim hadn't invented his browser yet.
We already had many many browsers before this guy showed up. By the way, this is like the most deflated job title ever. (audience laughing) The next time you're gonna go like oh, I'm a senior principal leads developer fellow thing, yeah. Apparently, Tim's job description is web developer. Yeah, puts your job description into a whole new light, doesn't it? Yeah, even to this little thing called HTTP. HTML, 89.
And when I was slowly getting into this Interweb that we know and love.
So yeah, fast forward another couple years, and we have this amazing invention called Mosaic. People used Mosaic in Angular? Yeah? A few.
I haven't put up a picture of Marc Andreessen, because I wanted to show you just how novel this thing was. You see, it has text and an image.
(audience laughing) Text and an image.
Before, we had browsers, and whenever there was an image, it was a link to the image and you can download the image. No, not Mosaic.
Mosaic had text and images.
And that was basically all we needed for people to go, this is cool.
We need more of these images, we need more of this content. And then there is this guy called Rob McCool, of which exists no decent pictures on the Interwebs. I'm sorry.
But now we went, he did this other really cool thing and he found, and he described this thing called CGI-BIN. The Common Gateway Interface to your binary. And this is one of those other crucial inventions of the Interwebs.
Before, we were just serving these HTML files to our browsers and they were displaying them and life was good.
But this changed everything again.
'Cause what the CGI-BIN does is it, the server kicks off this programme, and what it does is it says generate the HTML.
CGI-BIN allowed us to generate HTML on the fly. Changed everything.
Yeah, once again.
Because then this guy came along, Rasmus Lerdorf. And he described, he, for his personal home page, he had this form interpreter.
Does anyone know what this is called now? PHP.
PHP.
It doesn't stand for Personal Home Page anymore, but I just love the abbreviation.
And PHP, another game changer.
CGI-BIN allowed you to basically fork off a C programme. Which was cool, but way too hard for random people. PHP made that CGI-BIN accessible to infinitely more people. Infinitely easier to write.
So yeah, then our good friend Hakon came long and went like, this is where we're going to need, we're gonna run into this issue with HTML and styling. And this is when the, there was a lot of, they were playing with this for a while, but this is the CSS one.
CSS released.
Yeah.
We can now stop using spacer GIFs.
Although for the record, I didn't for years to come, I'll admit to that.
Table layouts and spacer GIFs were what I was good at, okay. So yeah.
And this other tiny thing, JavaScript.
95, it's been a while.
Still going strong.
And again, these massive, massive changes.
We now have proper layouting and we now have proper, well, we have a programming language in the browser. It's so cool.
And that goes well for a long time, and we're iterating on and we're going on and on and on and on, and we're incrementally changing.
And then there's this one guy, Matt, that goes like, oh, the blogging software that I'm using is not really, they're going to stop support for it and I don't know.
And Mike is the author of the comment that changed the Internet.
'Cause he basically goes like, well, Matt, if you're serious about forking B2, I would be interested in contributing.
I'm sure there might be others.
Anyone here has to guess what these two gentlemen ended up building? - [Male Speaker] WordPress.
- WordPress, yes.
Powers, a significant portion of the Interweb runs on WordPress.
Whatever you think about PHP, whatever you think about WordPress, most of the Interweb runs on it. Yeah, definitely, big sweeping changes.
Anne van Kesteren.
XMLHttpRequest, the Microsoft version of it was released in 99 or 2000 and there were a whole bunch of proprietary implementations. But 2005, the working group standardised XMLHttpRequest. And again, this big, massive change.
We could now make HTTP requests from JavaScript in our browsers or whatever you wanna use.
But this, again, made it now possible to get stuff and work with it in your JavaScript, generate stuff on your client.
2006, John released jQuery.
And this is one of those other inventions that changed the trajectory of the Internet as we know it. Using that XMLHttpRequest, it was very easy to manipulate the DOM to do your logic, to do stuff. It became easier and easier to change the HTML on the fly in your browser.
Much much easier.
And then 2011.
Sophie and her team at Facebook released this little known framework called React.
Now, there have been other frameworks before, React definitely wasn't the first.
The mid-2000s, we had Backbase, we had Google Web Tools, we had a massive amount, XJS, even Angular. But React did what none of them, the others ones, were able to do, and that is get that massive wide share adoption.
And that's, React changed the way everyone thinks about programming for the web.
Before that, it was just stuff people did.
React changed the narrative of developing for the web. And that's definitely part of Sophie's legacy. So what we are seeing over the course of these five-six decades is that we've moved, we went from the static documents, instead of documents where we had just a little bit of data on the server and the browser had some layouting logic, and that was it. Where we went to these traditional applications driven by that CGI-BIN, that PHP, and that WordPress. And what we were doing is, and Rails is in this camp as well, where we have all of the stuff on the server and we still ship HTML, to the stuff that's driven by jQuery and perfected, well, they're still working on React, obviously.
But this is now the new model, where we have, our data's still in the server, our business logic is still on the server, but all of this application logic, this presentational logic, is now running inside your browser.
We fundamentally changed the model in which we develop applications.
Now, I'm old and grey enough to go like (groans), we've seen this before.
Wait a minute.
This keeps happening in IT.
They're doing the same thing over and over again. 'Cause if we rewind the clock and go back to 1943, we had mainframes.
And there's this amazing quote that goes, I think there is a world market for maybe five computers. Thomas actually didn't say that, but it's a good story. It's a good story.
But we had these big massive mainframes.
77, Ken Olsen, the founder of DEC goes like, well, there is no reason anyone would want a computer in their home.
At this point in time, computers were about the size of a fridge, why would you want one of those in your home, makes no sense.
And then Mark came along.
Mark and his team at IBM released the personal computer. You may have heard of it.
And they were already getting smaller, but now they were getting properly small.
And then we have this other amazing quote, where we now went from server back to clients, and Bill Gates going, 600K should be enough for everyone. He didn't actually say that, but it's a great story, it's a great story.
Yeah.
79, Adele Goldberg and Alan Kay, the PARC, Palo Alto PARC research centre, were working on this little known language called Smalltalk. And basically, what they were working on at PARC at the time was this really amazing new hardware and a language to work with that.
So this amazing new hardware was a graphical display, a mouse, and laser printers.
Now, Adele is the one that, when Jobs demanded, Steve Jobs demanded a visit to Palo Alto, she went like, no way.
No way I'm showing that guy around.
'Cause he's just gonna steal everything.
And she was overruled by her superiors.
Which is why we have this now.
So what, we went from mainframes, the wrecking ball is very appropriately chosen, to PCs, and then to the web servers, and now front-end applications.
And it seems like this pendulum swimming left and right all the time.
But that's just the grumpy old man in me.
'Cause in reality, what has happened is it's not this simple.
What we are talking about is two different axes we've been optimising and trade offs for.
The one axis is how cool things is.
Response times and the capacity at the other end. How many cool things can we build with this stuff? And the other one is ease, represented by the amount of martinis you have time and money for when you're done doing this thing.
So mainframes are here.
Mainframes are not very cool and they're also not very easy. What we did, we went to client/server.
Client/server, the application was running on our own computers using all of the hardware available on our own computers.
And we could build really cool stuff with this. The problem was it's impossible to manage.
There's no martinis for you.
Rolling out an update could take years before you had some kind of uptake, and there were still people using the version from six years ago and you had to support them. Impossible to manage, impossible to manage. But then traditional web applications came along. They are, we've got quite a few martinis left. But the stuff you can do with it is, it's okay. It's HTML and it's doing okay.
Mobile, nice.
Much better.
Again, on our device.
This is getting much better.
We have much richer applications, we have much more access to the hardware.
We can do cool stuff with mobile applications, they're pretty cool.
The problem is that they're very hard to, they're still relatively hard to manage.
There's the stores.
But the other thing is, we still need to do stuff for everything that isn't a mobile app.
So good, but not all the martinis just yet. And then front-end applications came along, these applications that render inside your browser. They are really easy to manage, there's lots of room for martinis, but again, we're still back to the browsers and the capabilities that we have there. So yeah.
So this is where we are right now.
We've got mobile apps, front-end applications, and we're doing pretty okay, we're doing pretty okay. But what's that path forward, where do we go from here, where do we go now? Where are we doing? If you ever happen to find yourself in Las Vegas, I know just, if you wake up and you're like, I'm in Las Vegas, go rent a car and drive over here. Angels Landing in Zion National Park.
This is the most un-American walk in America. 'Cause it's a strenuous walk.
All right, how hard can a strenuous walk in America be? About five hours.
And then this is the end of it.
Now, if you can see there's this rail.
But yeah, drops off a couple hundred metres on either side. The least American walk in America.
But the view on top there is amazing.
But yeah, what's the path forward, where do we go from here? Here's where we are.
How do we get there? I want all the cool shit.
But also all my martinis.
How do we get there? How are we going to get from here to there? And there's two things that we, that luckily, a lot of people are working on right now. The first thing that we do is we need to continue pimping the browser.
Yup, make the browser better.
And there's a lot of work happening in this space, a lot of work happening in this space.
One of the ones that I'm extremely excited about is WebAssembly.
JavaScript is cool and I love JavaScript, it's easy to make fun of JavaScript.
But if you see the impact it has and the speed at which we can develop stuff, it's an amazing language, but it's not the fastest. It's not the fastest language around.
And WebAssembly allows us to, well, certainly, that interoperability, that becoming more and more and easier and easier to do with WebAssembly and JavaScript allows us to optimise parts of that experience.
I doubt we'll ever write entire applications in WebAssembly, maybe we will, maybe we don't.
But the point is we can write most of our stuff in JavaScript, and write the stuff that we really care, the stuff that should really be performant, we can write that in WebAssembly.
So we can speed things up quite tremendously. Really excited to see where that's going.
And when you browse through the programme, it turns out that Aaron is talking about WebAssembly today, if I'm not mistaken.
But yeah.
Variable fonts.
Up until now, we could do stuff with fonts. We could load all the fonts, and it was pretty cool. But the stuff you can do with this is really cool. Around animation changing.
This is going to make it much easier to get stuff done. Friend of Web Directions, Mandy Kerr, has a really cool resource, variablefonts.dev, that I encourage you to check out.
She's got some really cool stuff on there.
Let me see Mandy.
She's not here to share.
Another one, Web Speech API.
When we're talking about accessibility and that conversational interfaces, it's going to be really interesting, Web Speech. It's one of those things where you just go like, I don't know what I would use it for, but I'm pretty sure it's going to be big going forward a couple of years.
I saw Mr. Nash sneak in earlier.
And he'll be taking us through that today as well. One that isn't all that well known, but I am also really excited about is Web USB. And reading about Web USB is also the moment I realised that what the browser is becoming is a operating system.
Yup, the browser is our new operating system. And basically, what we're talking about here is device drivers that we're building.
They're called web APIs, but they're not, they're device drivers to our device.
The browser is the new operating system.
And that's where we're at.
And what I think Web USB is going to do is allow us to interact with all the peripherals that we have. And that's going to be really exciting, all right. I think this is gonna push the web even further into point of sales instead of systems, for example, as the first example to come up with.
But everything that controls a device, you can now slap a web browser on it and control it from JavaScript from a server. It's some really cool stuff that I think is gonna happen with this.
Media recorder.
Again, part of that conversational style, recording stuff in your browser.
Stuff we can do here.
This is gonna be really interesting to see where this takes us.
Jessica is going to talk about this.
A lot of stuff is going on in this space.
Progressive web apps.
It's an interesting space, is how do we get stuff from, on mobile, how do we get that mobile experience? And that's where we're going with breakneck speed now. There's stuff in here, the easy stuff, manifests allow you to instal a web application as if it is a mobile native application.
It's wrapped in a browser installed on your device. There's technology wrapped in here for service workers. We can now design offline first experiences. Service workers are basically a proxy inside the browser. It's a programmable proxy inside your browser. It can intercept any of the network requests and do with it as it pleases.
It can respond straight away with something that's cached on the device.
It can go out, just do a simple HTTP request, it can do multiple HTTP requests and collate the responses. There's a lot of powerful stuff in service workers that basically allows us to replicate that native experience.
And that's, and push notifications is the last thing that are working towards that truly progressive web apps. Having that mobile experience inside a browser. If you look at the hundreds of thousands, millions of mobile applications that are out there, I reckon that we can port a good 80-90% of those to progressive web apps in the next couple years. There will always be, there could always be a need for this native experience when you're doing really fancy stuff.
But most of the stuff we're doing in these mobile applications is relatively trivial stuff. So yeah, this is the one I forgot to put on there. WebGL.
Proper 3D accelerated graphics inside your browser. There's some really cool stuff happening there. We can now play first person shooters in a browser. They're not as good as a native application just yet, but give it time.
We're definitely going to get there.
So one part of this how do we get stuff to be extremely cool and extremely, extreme martinis for me is that levelling up the browser, and that's happening.
Every single time, did I mention I wasn't, web monetization that Yuriy is gonna talk about. You're right, Yuriy, I'm gonna try to pronounce your last name.
But it's another really cool, how do we monetize web? How do we distribute content on it? So the browser is definitely going on the right trajectory to give us a whole bunch of this cool capability that we're going to need moving forward.
The other thing I wanna talk about is we need to level up our servers.
There's a lot of stuff happening in that space as well. A tonne of space happening in there.
And I wanna start at the backend.
'Cause here's the answer to the backend, GraphQL. GraphQL is going to change pretty much everything. I remember having this conversation with a friend of mine, Dave Thomas, who runs a bunch of different companies and is rather smart. What Dave Thomas and I, this was 10 years ago. And Dave said to me, Erwin, this whole REST stuff is bullshit.
All right.
We're going to go to a model where the client sends queries to the servers and the server will handle the query and the client will just. I'm like, you're bonkers.
And I should've known better, 'cause I've had many of these conversations with Dave.
Years later, I'm going to GraphQL and I'm typing my first query and I love it, until the moment I realise that Dave was right. 'Cause what GraphQL lets you do, it's like well, server, I would like to have all of this information, please. And the server will send to you back exactly that information that you need.
Which is so much better than REST.
REST was great.
GraphQL is better.
So this is going to change the way we're gonna think about backends.
GraphQL.
And this is where we're on this big massive fork in the road between front-end and back-end.
'Cause what we're now seeing is our back-ends becoming much more stable.
Back-ends we're now talking about just business logic only. We're talking about there's only business logic in there, some GraphQL-y stuff.
But other than that, this is the query stuff and there's the business logic stuff, and that's all tied up, which is relatively stable. Which is great, 'cause it's also really hard to change this stuff.
Changing your back-end is really really hard. So what we're gonna be seeing is this massive divergence in pace of innovation.
Where we're gonna slow down the pace of innovation on our back-ends.
'Cause that's our business logic, that's our business processes, those are, and those are hard to change, there's data involved and data migrations.
Who here likes data migrations? No one does, they suck.
They're terrible.
And that's fine, so we're gonna slow down that rate of innovation, rate of change in our back-ends. But our front-ends change faster than we've ever wanted to change them before. So what we're seeing, what we're gonna be seeing in the near future is that massive divergence in rate of pace between our back-ends and our front-ends. Your front-ends you wanna change every couple minutes. That back-end is hard, but also doesn't need to change as much.
So that's that first big massive divergence. But the other thing that we're seeing now more and more of is, with our backend becoming that data business process layer is our backends become, instead of the, when we're testing them, we have these really nice simple yes or no answers. Is this response correct? And you could say yes or no.
I got back a six.
Should we get back a six? No.
Cool, there's a bug.
So we go and find it and we go like ah, it now returns an eight.
Is an eight okay? Yes, it's okay, right, cool, check.
Passed the check, passed the test.
So this backend's very binary, yes or no, is it correct or not? We can, front-end, not so much.
Front-ends are used by these bags of mostly water called humans.
Front-ends are messy and they're hard.
Is this usable? I guess, maybe.
I can understand it, no, I don't.
Is this accessible? People, we have all these tests, the Lighthouse, those are the accessibility tests.
What those tests show you is that you're, they will tell you if you're not accessible. They can never tell you that you have an accessible website.
As an experiment, this guy wrote, did a test on how to write the least accessible website that still passes 100% all the tests that you throw at it. And he managed to get it down to a blank page that passed every single test.
The only thing you would ever see in any browser whatsoever, whether it's a browser or a screen reader or any, you would see a blank page. And he passed all the accessibility tests.
Humans can look at stuff.
Is this usable via screen reader? Well, use it.
And it's the same for all of those tests, front-ends are messy, and we should test them very differently. We need humans to look at it.
So we need to change the way we think about releasing front-ends very differently than we should think about releasing back-ends. It's okay to slow down your back-ends.
We should definitely speed up the way we do front-end testing, 'cause that's where we wanna have all our innovation.
So let's talk about the front-end for a bit. At first glance, we have two ways to host our front-ends. Two big ways, we've got static hosting and we've got server hosting.
We have an Nginx or an Apache or whatever we have on the server that does the stuff.
And this, at first glance, is what it looked like, static hosting, I have lots of martinis, server hosting, I can do lots of cool stuff. But that's not really true.
'Cause if you start digging down, this is what we find. At static hosting, we have scalable.
When was the last time you thought about all the scaling groups for your S3 buckets or your Netlify or, no.
This is not my problem.
It's infinitely scalable without any effort on your part. It's simple.
I put my stuff there, all my customers see it. Done.
And it's damn cheap.
So there's a lot to say for martinis on this side. Lots of good things to say about martinis on this side. But it turns out there's a bunch of martinis on the other side as well.
If you're doing your server side hosting, it's very easy to add caching headers, add, do a lot of infrastructure stuff for you. And this is a thing that we don't nearly talk about in the industry, is the way we deploy our frontend applications and test them.
I've been on the back-end side of things for a couple of decades.
And when I got into front-end development, I was looking at how do you do this.
Well, we create the test bundle.
And okay.
Test bundle, then we deploy it on the test server and then we test it.
And if it's okay, well, then we throw it away and we grab our staging bundle.
And I went like, just, so you deploy our staging bundle to the staging environment? And so how do you know that's the same code? You're gonna like oh, only the configuration is different. Let's go and check.
Div one and two, and turns out there's a change on line one. Which is the only line.
(audience laughing) Great.
And now we, but now we've done the staging environment and we tested staging, staging is great.
What do we do with the thing? We throw it away.
Here's our production bundle that we've tested. And the thing is, if you're doing server side hosting, there's a lot of stuff you can do where that's not necessarily the case, where you can do a lot of that injection of these variables from a server side that you can't do, it's one of the limitations of static hosting, is that you have to do it that way.
In server side, you could do things very differently. And then we start thinking about some of the cool stuff. There's this thing you may have heard of, SEO, Search Engine Optimization.
One of the problems with that static hosting of that one site, one file, is that SEO is almost impossible to do well.
Your meta tags, the content of your site, Google does your index, your JavaScript mostly, sort of. It does the right thing most of the time.
But yeah, HTML is better.
Good old proper HTML.
Other stuff that we're talking about, performance. When you're talking about your time to first byte, static is really good.
But when you're talking about performance metrics that matter, there's a lot more stuff you can do in the server.
The time to that first meaningful render, you can speed that up on your server way better. But figuring out what resources are going to be loaded and preload those, HTTP to push them.
There's a lot of stuff you can tweak and tune when you have that server component. One of the fun things is when you're doing server side rendering, rendering the entire HTML on the server and sending that down, one of the most fun things I love doing on some of those sites is just turn off JavaScript.
And you go like well, just turn off JavaScript. And if you've done it well, your application's still usable. And people are like wow, why would you turn off JavaScript? Who doesn't have JavaScript enabled? Oh, you mean beside all the crawlers? The next billion people coming online are coming online on shitty Android phones. 'Cause that's what they have.
If you're looking at the stuff happening now in the likes of India, Indonesia, massive, massive countries, people have terrible Android phones. How can we get a better experience for them, by going ooh, that's not a very new phone, is it? How about we just sent you HTML, forget about the JavaScript.
Not only do we save you a whole bunch of money downloading this JavaScript, but it's actually a better experience for you.
How do we personalization, we can now do a whole bunch of stuff on the server around personalization and localization.
Ah, you're in Melbourne today.
Let me give you the Melbourne news.
That's all stuff that we can very easily do when we're having these server side components. So what do we do, what do we do? Serverless.
Magic.
Magic.
But I'm actually dead serious.
Serverless is the way to go.
Serverless is how we're going to get to that stuff. And what I wanna talk quickly about is the thing that Glen Maddern, also a friend, where's Glen? He's out there.
And I have been working on for the past couple of months to help us make that last transition.
And introducing a set of FABs.
FABs are front-end application bundles, FABs. Basically, what the point of a FAB is is creating this portable spec.
It's the spec to create these portable deployment artefacts. We've got GitHub is there.
Fab.dev is the URL.
Basically, what we're trying to do is create Docker for front-end.
Docker for front-end, now, Docker, when they came out years ago, didn't invent anything new. People think that Docker invented containers, and they didn't.
What Docker was is basically the one ring.
The nine rings already existed.
What Docker did is create the one ring to rule them all. And in darkness, bind them.
And that's what Docker did, Docker took these existing specifications around C names and name spaces and all of these technologies, and they build a little spec and a little bit of a runtime around it.
And that's what exploded this entire ecosystem of tooling, hosting, spawn out of taking these existing specification and creating that one space that everyone could deploy to, bundle to and then deploy to.
And that's what we're doing with FABs.
The whole point of front-end application bundles is to be 100% portable.
I can run this thing, I've tested it here, I'm not gonna run it over there when it does exactly the same thing.
They're tiny.
One other problem with Docker containers is they very quickly balloon to a couple hundred megs. Self-contained, everything you need is in this little bundle.
And more importantly, it is specifically tailored for front-end applications.
We treat your static assets very differently than your server side component.
And this is what we can now do, is we can take all of these different frameworks, all of these different languages and boilerplates and starter kits, and we can compile all of those down to FABs.
And what we can then do is we can take that one FAB and deploy that to anything that runs JavaScript. We already do lambdas, CloudFlare workers, Now, Heroku. And if you wanna package them up in a Docker container and run them on your Kubernetes cluster because you're hip and trendy, you can do that too. And that's what we're trying to do, is how do we get to this? 'Cause if we can get to this, we get the best of both worlds.
Serverless gives us that powerful server side framework and the ease and cheapness of static hosting. And we can get magic.
We can go, ooh, aah.
No.
We can get to that point where we have really cool stuff. The browser is pimping itself along really nicely. The servers allow us to have that really cool stuff we can do, really powerful stuff with the ease of static hosting.
♪ Everything is awesome ♪ And that's where we'll leave.
♪ Everything is cool when you're part of a team ♪ Thank you very much.
(audience applauding) ♪ Everything is awesome ♪ ♪ Living out a dream ♪ (bright music)
