Transcription

All right. Let's do this then. So I know people will keep walking in. That's totally fine. Well done to those of you who have made it here at the appointed moment on this day after the party last night. It's impressive to see you here, and I'm very glad to do so. So my name is Steve. I know some of you, not all of you. I work at Microsoft. I work on the .NET team. And I particularly work on stuff to do with the web. So that's ASP.NET, Blazor, other front-end web stuff. And I've worked with the web, I think, for my whole professional career, which is quite a while. And I really like it. I think it's a great area of technology to specialize in. It's clearly very, very important. You know, there's pretty much every developer in the world has to do some stuff with web technology from time to time. So it's nice to be in that. But it does keep changing, right? Let's be clear, we're constantly inventing new ways of doing stuff over and over again. And probably you would agree that, on average, over time, things get more complex rather than less complex. And I sometimes wonder, well, why is that? How did we get to this? Who decided to make up all these things, and why did they do it? And could they have done it differently? Was it all a big mistake? So that's kind of what this talk is designed to look into. We're going to go back through some of the major events through web's history and see what happened and who the characters were, what they decided to do, and what they were offering. Now, obviously, this is just one person's subjective telling of the story. It's not an absolute truth. It's a mixture of some research and some first-hand experiences from certain parts of it that I was there for. But I can't cover everything. And inevitably, I will miss out whichever is your personal favorite thing. So let's just accept that limitation. The goal will be that, at the end of this, when you go back into your web development jobs, you will be able to see so many things that are there and think, oh, yeah, I see that came from that technology, and oh, that reminds me of how this person was trying to solve a problem in a certain way. And maybe that will put into perspective a little bit of where the web is and where it even might go in the future. We'll talk a little bit about that right at the end. So if we're going to talk about where the web came from, we should obviously start right at the beginning. And the easiest place to do that is with someone that I'm sure you've heard of, Tim Berners-Lee, who was working at CERN in Switzerland at the end of the 80s, early 90s. And you know he invented the web, right? But do you know why? Do you know what he was trying to achieve at the time? Well, apparently, CERN was quite a complicated place to work. You know, they had a lot of big projects going. They were building particle accelerators and such like. And Berners-Lee kept track of all his work in a piece of software that he wrote called Enquire. It was kind of like a notes management thing that he made. And he had a kind of primitive hypertext thing going on, because he was able to link from one note to another note. And he really liked this system, and he thought everybody should use it. He really wanted everyone in CERN to standardize on this. And in fact, he even wanted to go further and network everyone's notebooks together. So you can see where this is going, right? So he wrote this proposal, and he submitted it. Information management, a proposal. And there's loads of stuff in that that you would not recognize today, because it's all specific to CERN. It's quite hard to make sense of. But there's some parts in there that you would recognize. For example, this picture here, a picture in which he depicts the idea of a client browser, which runs on many platforms and connects to a hypertext server. You would probably also recognize this. This is the idea of a server which takes existing database content and makes it look like hypertext. In other words, he was inventing server-side rendering there in his very first document. The reason why he was concerned with database content was he knew that there was a good chance that if he submits this proposal, everyone will go, oh, that's a good proposal, and then just completely ignore it. How many of you have done that in your work? Yeah, it's a common thing. He knew that would happen. So his hack to make people use this was to take some information that they actually needed, basically the CERN phone book, and automatically generate the hypertext for that from a database. Now, he didn't just write these documents. He also prototyped some implementations of a web server and a web browser. And we've got the source code for those two things right here today. So I'm going to show you the very first web server that there ever was. And it's this file called TCP server.c. And it's 700-something lines of C code. And the code quality is, well, it's clearly a prototype. And I think we've all done some pretty bad things in our prototypes. But the great thing about this is that it actually worked. And in fact, we can still compile and run it today. I had to make about three very small tweaks to the code to deal with some compiler errors. And then it built in a modern GCC. So to do that, let's run GCC to compile that web server there. And we've just built a 22-kilobyte binary HTTP daemon. And that is the original web server. So let's run it. Okay. And that's running now. And you can see that it's listening on port 2784. That's a bit weird, right? Why is it that? Why isn't it port 80? Well, we'll come to that in a second. Now, I can't connect a modern web browser to this, because this only speaks a very ancient dialect of HTTP, which has been lost in time. And now the only way we can really talk to it is to connect to it from Telnet. So I'm going to do that. So let's go Telnet and connect to that. Now, if you know anything about HTTP, you would think that probably the way to get it to do something would be to do something like this, to get the home page. That's how a modern browser would do something. But if we try that, it just goes unrecognized command get. And that's a bit strange, because if you read the source code, you see that it does have stuff to do with get requests. But if you reverse engineer it a little bit more, what you'll find is that if you say get and then the name of a file that's actually in that directory, then it will serve that file to you. So the very first web server was a static files web server, which is the sort of thing we still do today. So that makes sense. Now, it's not just that. It's also got a bunch of other things that we wouldn't recognize now. Like it's got this find feature that's built into the web server. And it also is a place where Tim establishes a beautiful tradition for web servers, which continues to this day, which is having terrible security vulnerabilities. And we can see one quite easily right here. The one that really stands out most, I think, is on line 286 here. This system call here, that's going to execute some code by calling out to the shell to run a native program. And what is this system command? Well, it's whatever we get when we concatenate a bunch of user input together. So you can just run arbitrary stuff on the server, which is very friendly and community minded. You also might wonder about this weird port number that they were using. Well, that port number changed a little bit later. If we look at the version 3 of this technology, you'll see this is where they switched from the old port to the new port. This old port number, apparently those are the last four digits of Berners-Lee's parents' phone number, supposedly. But then in 1992, they were allocated port 80. And that's when they said that they felt that they'd really made it, when they got this nice round port number. So that's the original web server. But there's also an original web browser. We can have a look at that as well. And that's actually quite a much more sophisticated piece of code. And I'm going to show you that inside Next Step. Now, how many of you have ever used Next Step? Zero. Okay. So this was an operating system created by a company called Next, which was run by Steve Jobs after he was forced out of Apple, before he went back to Apple. And you can recognize a lot of stuff in this in modern MacOS. For example, it has the spinning beach ball whenever it's busy. It also has this kind of three column file browser, which you might recognize today. And inside this here, I've got the source code for World Wide Web.app, which Berners-Lee wrote. And that can still be compiled and run. So let's have a go at running that browser. I've got it installed here. If I double click on this. And what you'll see is it's quite different from anything that you would recognize as a modern browser today. So one thing is that every page you open comes up in a separate window, which is just kind of like floating around independently. And then the controls are all in this other floating window. And we've got this back and next and previous and stuff. And you probably think you know what that means, but I'm afraid you're wrong. Because next and previous do not mean what they mean in a modern web browser. It's something to do with going through a list of links incrementally. It's kind of hard to make sense of. We've got other stuff in here. For example, we've got this about screen that Berners-Lee put in. Let's see what that says. It says it's an exercise in global information availability. So I'd say it's pretty successful as an exercise as things go. We've also got... What else have we got in there? We've got some weird stuff that you wouldn't expect. Check spelling. So you can do spell checking of the page that you're visiting. Now, you might think, why on earth would you want to do that? Well, there's a good reason, okay? Because this is not just a web browser. Any page you go to, you can just start changing it, right? You can just edit anything that you see. And it's even got this surprisingly sophisticated style editor where I can go and choose different styles that are kind of hard to see. We've got all this configuration stuff that shows up. And we've even got various diagnostics where we can do showing the HTML sources and seeing other things about what's going on. So we've kind of got early browser dev tools in there right at the very beginning. Now, in terms of the ability to edit sites, well, it makes sense, right? Because Berners-Lee's idea was that this was a big, globally shared networked notebook, which people should be able to edit. So kind of like early echoes of Wikipedia in there. But of course, it was always designed to be distributed, not just a single server. So that's the original web browser. It did have a bit of a critical flaw as a plan, though. So let's just get out of there, and we'll talk about that. So the big problem here was that Berners-Lee has made this lovely web browser prototype, which runs on Next. But no one apart from Tim has a Next computer in CERN. So this project is at serious risk of just dying, like, in its first week. But thankfully, it was rescued. Now, there was an intern at CERN at that time called Nicola Pella. And she could see what Berners-Lee was doing and what the potential was in that. And she could also see that it was immediately just going to fail, because no one else can run this browser. And thankfully, she invented a way of rendering the hypertext as plain text that would be possible to use on the computers that other people had actually got. So I think we can be very glad for that, because we would not be here talking about the web if that hadn't happened. But that's just text mode, and that's not really what people wanted. People wanted a graphical browser. That was kind of obvious. As soon as this was made public, people started creating their own browsers. And the first one that is perhaps recognizable to modern eyes is this one, Viola. You can see it's got the address bar at the top. It's got back and forward, and it more or less does what you think it's going to do. And it looks nice. But it's also really innovative in other ways. Pei Wei, who created this, also added style sheets. Now it's not CSS. Obviously, that hadn't been invented yet, but it was a thing like that that he came up with and put in there, and you can kind of see how that would work from the syntax. But even more impressively than that, it had built-in scripting. Again, not JavaScript. That hadn't been invented. But the whole browser was built in this kind of scripting language, and he allowed you to embed the same scripting language in your pages to dynamically change the content. So that really set some direction for what a web page could do. Now people didn't really use this at scale, either, because this was a Unix-only thing. The first browser that was cross-platform enough and friendly enough for lots of people to use is this thing, NCSA Mosaic, and I'm just going to show you that before we get on to talking a little bit about how programming worked for the web. So I'm going to show you that inside Windows 3.1. So let's bring that up now. Now it might be a bit before the time of most of you. I don't know why that's just gone black. What's going on here? My screen has just gone black mysteriously. I don't know why. Yeah, that's because I'm doing a live demo, obviously. That's the primary reason. Okay. Well, here it is. Nope. It does not like that. All right. Well, I think we might do without seeing Mosaic, then, because I don't know what's going on with that. As soon as I can get back. Yeah, let's just kill that. So Mosaic was an early browser that looks familiar to modern people, and let's get back to it. There we go. The main innovation that happened with Mosaic was that it looked a lot like what you would see today. It had all the kind of HTML rendering that you would expect, like things are in paragraphs. They've got lists. They've got links. You can hover a link, and your cursor goes blue, all of that kind of traditional stuff. But the main thing that was the really big, surprising innovation was inline images. Now up until that point, browsers did not render images inside pages. You had to open them in a separate window. So you might be thinking, well, how did this new standard come to be? What did the standardization process look like at that time? Was there a standardization process? So let's get a little snapshot of what that was like for the people at the time. So there was no standards bodies. At this time, there was just a mailing list, and one day, the person who was building this web browser, Mark Andreessen, who we're going to hear more about in a minute, he sent a message to this mailing list saying, hey, I'd like to present a new HTML tag called img, and I want it to have an attribute called circ, and then he gives an example of that at the bottom, and the reply comes back almost straightaway saying, oh, yeah, I've already invented that exact thing, except my invention is totally different, and why don't you call it image, and why isn't the attribute source? Oh, that's a very reasonable question, I think. We can all agree that's a good question. However, nobody addressed that point whatsoever. It was totally ignored, because Berners-Lee then came in, and he said, no, no, no, hang on a minute, it should not be called img, or even image, it should be an a tag, and it should be rel equals embed comma present, because clearly that's much more intuitive, and developers are going to like that a lot better. So then they had a little bit of a heated debate for a few days where they were pitching their counterproposals, and Berners-Lee was really sticking to the idea that, no, it really, would be more appropriate for it to be an a tag, but then he makes a bit of a tactical error, because he says, oh, we can't change HTML now anyway, because it's being standardised. We just have to leave it as it is. Now, unfortunately, having made that blunder, that gave the opportunity for Andreessen to come back and say, well, Tim, I absolutely agree with you in all cases, which is why I'm going to completely ignore you and do what I said originally, even if your standards, say otherwise, browsers have just got to innovate. So he went ahead and did that, and he came back a couple of weeks later to confirm, yes, we're definitely going with img and circ, like I said in the first place, I wasn't really asking your permission. This is just what I'm going to do. So I don't know if Berners-Lee felt at all burned by this exchange, but it just so happens that the following year, he set up the W3C, a body whose role is to have a sort of moral authority about what browser makers should do, and give them a nice shiny badge that they can put on their product if they are compliant. And at this time, the web was growing rapidly. There were probably hundreds if not thousands of web pages by now, and it was growing so fast, it was literally going up by a factor of ten every year. It did that every year between about 92 and 97, a whole order of magnitude growth. It was incredibly fast. And one of the high points of this comes in 94, 95, when two big corporations show up. Well, Netscape was not a big corporation originally. They were a start-up. So Andreessen, who had worked on Mosaic, he left and he went to work for a start-up, and they weren't going to make a web browser. They actually wanted to make an online gaming network for the Nintendo 64. But Nintendo were just taking too long to release that console, and so they said, well, what should we do instead? I don't know. Should we just make another browser, maybe? So they did that, and that's how Netscape Navigator was born. They went on to IPO the next year for an incredible amount of money which started the whole .com boom. And then another company you might have heard of decided to get into the game, Microsoft. So Microsoft licensed the NCSA Mosaic code. They took that code, they wrapped it in some nice Windows-y stuff, and they shipped that as Internet Explorer 1. This started the first browser wars between Netscape and Internet Explorer, which as you might know, Internet Explorer went on to win very conclusively, getting up to 96 per cent market share by 2001, which also caused a few legal troubles for the company, but it was a resounding win for the browser. Anyway, that's enough about browsers. Let's talk a little bit about how web programming actually worked, and we will look at some of the frameworks that people would use around that time. So up until now, people who wanted to create web pages, they would either just write HTML by hand, or if they wanted to do it dynamically, they would use something like Perl scripts or other executables which they would connect to their server through something called CGI. But someone called Rasmus Lerdoff came along with the idea of wouldn't it be nice if there was a dedicated scripting system that was designed for creating web pages? And so, in 1995, he released the personal home page tools 1.0, and this is the original syntax. This is an early sample. You can see it was done with HTML comments for generating HTML. It had some cool powerful features, like can you see it does SQL queries there on line six or seven or something like that, and, of course, it has a SQL injection vulnerability. They always do. It just wouldn't be fun if they didn't. That was how it was meant to be in 1995. And I don't think, to be honest, that Rasmus was entirely confident in what he was doing. When he was asked about it later, he was just like, what is this thing? But we need to give credit to the fact that this was one of the most successful web technologies there has ever been. Much of the early web was built with this, and, famously, Facebook was built with PHP, and they still use it at scale, so very successful, actually. But now let's think a little bit about front-end development. 1996 was the year that we could say that front-end was born because it's where JavaScript appeared, it's where CSS, and also two of the big consumer-facing web page creation tools. Now, there had been many HTML editors created over the last couple of years, things like Hot Metal and stuff like that, but Microsoft licensed this product called FrontPage. They rebranded it and shipped it as a Microsoft thing. This kind of took over the market because it was so powerful. It was ridiculously, excessively powerful. Let's have a quick look about how that looked at the time, shall we? So I'm going to go and go into, what are we in here? Windows 95. So, imagine it's 1996 or so, and you want to create yourself a new corporate website because you've heard that .coms are all the rage, so you would have installed FrontPage, and then you go in there, and you start that up. Let's see what it takes to create ourselves a website. When that shows up, we're going to create a page from a wizard, all right, and what we're going to do, well, I'm going to create a corporate presence, because you know my goal is to get rich from .com stuff, and I'm going to call it, I don't know, UltraCorp. Sounds like a good name. And then it's going to ask me a few questions about the site that I want to create. Apparently, I've already done that, so let's call it UltraCorp 2, because that's probably even better still. All right, so it's going to ask me some questions now about the site that I want to create. So it's going to start with, let's see, what pages do you want to have in there? What do you want to have on your pages? And then it just goes on and on and on, asking so many questions about your website, and then finally, it's going to go and actually create it for us, all right? So when that comes up, one of the interesting things about this that we'll see is that Microsoft knew that people didn't really know how to create a website at this time. So one of the things that FrontPage does is it kind of teaches you. It's got this whole to-do list system where it tells you all the different tasks that you have to do. It's got this nice, like, graphical overview of your site with all the links in it, and then you can double-click on a page to open up the actual editor. When I do that, that pops up, and then we can start actually working on our site. Now in terms of the graphic design, it's kind of astonishing, really, that this is the corporate website template. I do not know what the designers were thinking, but of course we can go in and we can start editing stuff, you know, let's just say my site, I don't know. As well as just creating the HTML, it also had some disturbingly powerful features. For example, we can go to insert script, and if we choose to add some VBScript, we can also make it run on the server, which is a very worrying thing indeed. So this was an early way that people could use VBScript, which is the same thing that would automate Office, to automate their web servers, and people did, and they ran into some trouble with that sort of thing. We'll talk about a little bit how that was resolved shortly, so let's just get back out of here. No, I do not wish to save that. That can all shut down. All right. A bit of nostalgia there. Right. So JavaScript and CSS, they were also coming out at the same time. Maybe you've heard the story about JavaScript, about how it was created in ten days. Well, it's true, apparently. So Brendan Eich was hired to work at Netscape, and when he started, they said to him, hey, in ten days, we're going to have an all-hands meeting, do you think it might be possible for you to whip up some kind of demo of a scripting language that could go inside the Netscape browser? It doesn't have to be any good. No one is going to use it or anything, so he did it. He worked hard. He spent ten days, and he created this scripting thing that would go inside the page, and some of the design guidance that he was given by Andreessen at the start has really shaped the course of JavaScript all the way up to almost the present day. For example, Andreessen said this can't be a compiled language, because I want people to be able to just type the code straight into their HTML pages, and that is a design decision that's gone with us all the way up until WebAssembly was eventually created. And then there's CSS. So you know that CSS was not really a new concept. Viola had a concept of style sheets, and many people have proposed different style sheet designs over the years. This was a real community effort. There was a bit of a design competition going on, and it was won by a proposal by Haakon Wiem Lee, and it doesn't look like modern CSS. It doesn't have curly braces. It does have some features that we don't have today. But then Haakon continued working with a community group, and they eventually shaped that into what we have as CSS today, although browsers were very slow to adopt it in any kind of sensible manner. All right, then. So what about accessibility? That has to come in somewhere along the line. It's obviously very important to us as web developers today, something we have to know and think about, but it's kind of surprising how early it was that accessibility became a thing for the web, and it's a good job that it did. So here in Australia, you've got the Disability Discrimination Act of 92, and it does not talk about the web, because obviously the web was too new for it to talk about that, but it doesn't exclude the web either, and this act says, by default, everything has to have reasonable adaptations for disability, and so that automatically applied to the web at the very moment it was first invented, and other countries had similar rules. So Berners-Lee knew they were going to have to do something about this. He sent out a message to a newsletter in 96 saying, hey, what are the best practices? What are people doing? How are we going to make this work well? And the following year, this led to having a big meeting at the US White House with a US senator, and they founded the Web Accessibility Initiative, and that gave some confidence to the US government to update their Section 508 rules the following year to clarify that electronic services would be protected by that legislation. So it was really obviously a legal requirement at that point. And to help web developers actually do this, and produce something that actually worked, web content accessibility guidelines were formed by this group the following year. That was updated again a little while later, and then the version 2 of that actually became part of EU law officially, so the EU law basically just says you need to follow these guidelines version 2. It was updated again a little bit later. Now I think that, as web developers, the main thing to observe is that we should be grateful that these guidelines existed so early, and the fact that they were written by people who understood the web. Because if they were not, then today you would have to know about the accessibility rules of like 100 different countries and try and comply with all this stuff. But thankfully, because these guidelines existed early enough, the countries that have implemented legislation have largely just said, you know, do what the guidelines say. So it's reasonably sensible for us to know what to do. Okay. Now let's get back to a little bit more programming, shall we? There was a bit of a problem that Microsoft had identified around then. So they've got this ASP programming thing. I showed you that you could do that from front page, you could do it from other tools like visual interdev as well, but it had a bit of a problem. The main problem was it was not object-oriented, and in 2000, everything had to be object-oriented. That was the one true way that all software must be written. And the other problem was there's this very successful UI technology called Windows Forms that allows people to use a visual designer to put their application together and put some logic into it. And you can't do anything like that on the web. You certainly can't do anything like use JavaScript for interactive UIs at this time, because that's just a ridiculous toy language that nobody could use in any sensible way. So what is Microsoft going to do? Well, a guy you might have heard of, Scott Guthrie, and his manager, Mark Anders, they were set the task of working on this. And this is apparently the original notebook that they came up with a design in. So let's have a look at the design that they came up with. Okay, so we're now in about 2002, and you're a web developer, and you are going to make a website with this new technology. So you're going to be using Windows XP probably, and you've just installed Microsoft Visual Studio.net. It's just been released. So we'll start that up, and we'll see that, wow, it's really fast to start up, firstly. That's quite impressive. Now, obviously, I'm cheating slightly, because I'm using hardware from 20 years in the future, which is also what we recommend for modern Visual Studio. Anyway, I'm going to create a new project, and I'm going to give it the very delightful name of Web Application 11, because I'm not feeling too inventive today. And when that comes up, you'll see, here's the visual designer that people wanted, just like in Windows forms, and I can start adding some UI to that, like I'm going to add a label, and I'm going to just say, hey, there, okay, and I'm going to add a button, and let's move that along, and I'm going to do some really high-quality graphic design here, where I'll make that have an orange background. Looks nice, yeah? Okay. Now, what is the HTML that's coming out of there? We can switch over onto the HTML view, and we can see it's not too bad, actually. It kind of looks all right, with some exceptions, like what on earth is that? I don't know what that is. I don't want to know. It obviously shouldn't exist. But let's just run it anyway and see what comes up. All right, so control F5, I'm in my browser, and we've got our button, okay? Now, it won't do anything if I click it. Let's add some interactive behaviors to this, and it was really nice, okay? We could go and we can double-click on that button, and we get into our code editor, and we can use the brand-new C sharp programming language. So I'm going to say that when we click on this button, I'm going to change the text on it to say, you clicked at, and then date time dot now, okay? Run that again. And then when I click my button, you'll see I get the time to appear. That's pretty nice. And I can click it again, and each time I click it, the time is going to update. So how is this working? How is it being interactive even though we've got no JavaScript in the page? Well, one clue that we can get is if we use the back and forwards buttons. So watch as I press back and I forwards, I'm going backwards and forwards in time. So what is going on there? That's a bit advanced, isn't it? We can't even do that with modern tech. How are they doing that? Well, the trick is how it's implemented. So if we go into view source here, we can see this giant blob of base 64 encoded stuff. It's a bit hard to read, I know. Can we change the font? I'll just leave it. Okay. So we've got a massive base 64 blob, and this represents the UI state. So there's an object-oriented representation of the UI, which is serialized into that blob. And when I click a button, it sends that to the server. It decodes it. It builds the UI state. It runs the action that I've just put some logic for and re-renders the new HTML and also re-emits that base 64 blob so it can update again. And as a consequence, each version of that ends up in the browser's history. That's a pretty clever solution to doing interactivity. But it does some other quite nice solutions to certain problems as well. For example, back at this time, CSS was really weak, and if you wanted to do something like horizontal and vertical centerings of something, well, you could probably just forget it unless you had like a PhD in browser quirks or something like that. But if you were an ASP.NET developer, you could do it quite well. You could just go like this. There we go. That's probably about the middle, isn't it? And then I just save that, go back into my browser, reload, and there we go. I can go home. That's nice. Now, of course, that works just by disgustingly like putting the absolute pixel positions into the page there, and this whole idea started to fall apart a few years later for reasons that we'll talk about. All right. So this was the hottest way of doing web development at that time, and it seemed like it would always be like that until a couple of years later, something new came which absolutely shook things up. We have to talk about Ruby on Rails. So David Heinemeier Hansen, DHH, he's a bit of a controversial figure these days, but back in 2004, he was just a humble hipster programmer who decided that none of the existing mainstream languages were good enough for what he was doing, so he had to go out and find an artisanal handcrafted scripting language from Japan that no one else had heard about, and he built a web application with it called Basecamp, and he had a lot of really interesting new ideas. He made this into an open source framework, and when that landed, people were pretty amazed about what they saw. So let's have a quick look at what that was like. I've got right here Rails version 1.0, not the absolute first version, but the oldest version that I can run, and I'm going to use that to generate a site called my blog, because everyone wants blogs back in 2004, and that's going to create the initial source code for me. So here's a new idea. I wasn't using an IDE. I wasn't using a wizard. I just created stuff on the command line. That was pretty nice. Okay. Let's see if we can start this up, shall we? So I'm going to go into the scripts directory, and I'm going to start up now, let's go, scripts server. All right. So that's going to start up the built-in web server there, Web Brick. I'll open that in my browser, and you will see we are now riding the rails. So exciting. And it gives us some tips, like start by defining your database config. So I'll go in here, and I'll go and I will set a database config, and I'm going to use SQLite 3. Now this is also YAML, which would have been new to web developers at that time, and have a look at the architecture here. Can you see that we've got models, controllers, views? Well, DHH didn't invent MVC, but this was pretty new to web developers at that time. It's applying this pattern in a whole new way. That was quite a big surprise to people. And to understand what that does, let's create a controller, so I'm going to generate a controller called blog with an action called index on it, and then I'll start my server back up. So I've now got this controller here. And if I want to navigate to that, I don't have to set up any routing config. I can just go to this page, and it shows up. So there's another new idea, this convention over configuration and file-based routing is just built in, nice and easy. But if I wanted to do something useful, I'm going to have to also generate a model. So I'll create a model for post for my blog posts, like that. And it's also generated some automated tests for me, which is pretty clever. Web developers were not really expecting to do automated tests at that time. And then finally, if I want to have an actual UI for that, I'm going to scaffold a UI for the post model. Let's see if this works. So if I go in there, and I go back now, you'll see it's trying to generate a UI, but it can't because there's no posts in our table, sorry, no posts table in our database. So let's do yet another new thing. We'll generate a migration, and I'll call that posts, and that is defining in code how to update the state of our database schema. So where is that? That is DB. That's in there, but why is it not showing up? It is. Okay. Right. So I'm going to put in a bit of logic to create a table with a title and a body. And then when I run that migration, rake migrate, it will update the state of my database, and then finally I can run the server one more time, and we've actually got a working blog application. Hi, everyone. This is so quick. Okay. Then I'll hit that create on that, and it's done it. So you can see what an incredibly different programming experience this was from ASP.NET at that time. There were so many new ideas going on all at once. This really shocked the web development world and led to a whole slew of copycat frameworks that you might have heard about later, like Grails and ASP.NET MVC, which came along a few years after that. So that's server-side programming as it was at that time. What about client-side? Well, I think the JavaScript was kind of reborn around 2005 to 2008 sort of time frame. And one of the things that triggered that was this Web 2.0 wave and the commercial pressures around that. So Web 2.0 was when companies realized that they could extract a lot of commercial value from user-generated content. And if you're a user, which sites will you spend your time generating content on? Well, probably the ones that make it fun for you. And I better plug in my laptop. Probably the ones that have a nice user interface. So there was a lot of pressure on developers at that time to create the best user interfaces they could so that developers would actually spend their time working on them. And some of the best work in this area was done by Google. The thing that I remember from that time as a new developer was absolutely shocking and mind-blowing was Google Maps. When this first came out and you could just drag the map and zoom in and out without even having to reload the page, it was just mind-blowing. Everyone was astonished, and they wanted to create stuff like that themselves. But they didn't know how. Everyone tried to invent their own techniques. But then this very influential blog post came along by Jesse James Garrett, who said, look at what Google's doing. We can extract some common patterns from this. And he even gave it a name, Ajax Asynchronous JavaScript and XML. And he tried to give some technical details about how it works. A lot of the stuff that he wrote didn't really stand the test of time. Like he talks about engines, and he talks about using XML a lot, which obviously we don't do now. But the core idea of doing requests in the background and updating the page dynamically, that really has stood with us all this way. And there was one of the major enabling technology of the time, which I'm sure many of you have used and probably still do use in certain ways, jQuery, which allowed us to simplify the horrible mess of very inelegant DOM APIs of the past and compress it all down to a really elegant way of describing what you were trying to do that would also work consistently across browsers. And this was amazingly successful. At one point, it was used by nearly 70% of the top million sites. And the amazing thing for me is, look at the peak of that graph. That only peaked just over a year ago. It's been going up the whole time, and it's only just started to come back down. Okay. So at this time, people were writing a lot of JavaScript. And if you write a lot of JavaScript, you need some way of debugging it. So what are the state of browser DevTools at that time? Well, let's have a look. We'll go back into this browser, and we'll look for the DevTools window. There isn't one. Okay? So the closest that you get to any browser DevTools is viewing the source in Notepad, which is great. And this guy, Joe Hewitt, he had been working at Mozilla, he's one of the founding engineers for Firefox, but then he left, and he started building actual web applications, and he realized that it was a massive pain, because you couldn't debug anything. So he created a browser plugin called Firebug, and I can show it to you. Here I've got Firefox, and I've installed the plugin. So when I right-click on this, I can inspect element, and you'll see a lot of stuff in there that's familiar. We've got a console, HTML view, we can see the CSS, we've got a script debugger, we've got a network tracers, and this design has largely stuck with us all the way through, and that was Joe Hewitt and a community working together on that. It was even pretty much just copied by Google as soon as they released their Chrome browser. So this is Chrome version 1.0. Let's see if I can get to a real web page. Okay. So Google still works in Chrome 1.0, and if I right-click on this and inspect, you can see their early DevTools right there. It doesn't have as much stuff in as Firebug, but they were copying some of the core ideas. So that was a great thing that Joe Hewitt did for us there. Okay. Now, what about design? What about responsive design? Well, at this time, let's think about how mobile web users actually consume the web. Well, they had very primitive web browsers, and you had to create these special mobile-specific sites that would work with these basic web browsers, but that all changed in 2008 for reasons that I'm sure you can all guess. This little thing came along, which changed the course of human history in many ways, but it certainly changed things for web development, and this was Jobs showing off the original version of Safari for the new iPhone, and he was very proud about the fact that it wasn't using mobile sites, it was using the real desktop sites. So web developers quickly realized two things. One, they could not expect people to use these cut-down mobile sites any more, because people will use your desktop site whether or not you want them to, and two, that this experience that Jobs is showing, I mean, it's all right, but it's not that great, because all this zooming in and zooming out is pretty annoying, and wouldn't it be better if the page was designed for this little screen in the first place? So this gave rise to the idea of mobile-first design, responsive design, media queries, and that was standardized a couple of years later in 2010. Okay, so let's get back to JavaScript a bit. JavaScript was now winning on the client, and it was about time for it to move to the server as well. Ryan Dahl was an independent developer. He had been working on some Ruby on Rails applications, and he was very influenced by these Web 2.0 UIs. He wanted to be able to process lots of stuff concurrently in the background, and he couldn't do it with Rails, because it was not multi-threaded, and he wanted to do it with other scripting languages and they weren't multi-threaded either, and he thought it would be impossible, but then he came up with the idea, just in the same way that JavaScript has an event loop in the browser, it could have an event loop on the server as well, and that could give him the concurrency that he wanted, and, fortunately, Google's V8 engine had just been released as well, so he considered it to be obvious that he should create a web server with this. He quit his job. He spent six months working on this, and then he brought it out in this conference in 2009. Okay. So JavaScript is everywhere by now, and this leads us to the next big step in client-side JavaScript as well. People were really pushing past the limits of what you could do with jQuery by now. They were building big applications, and they were becoming a mess, and we needed some discipline, some way of structuring things, and a whole bunch of things came out at the same time. People had really started to believe in JavaScript because of this book. You've seen memes about it. I'm not going to repeat all that, but you know people were starting to respect this as a language, and people wanted to use it. This slide here, this represents the inspirations and relationships between different SPA frameworks. I didn't make this slide. I just stole it completely from Sarah Drasner. She is a director of engineering at Google, and probably one of the most authoritative people in the world on this subject, because not only does she own the team that runs Angular, she's also been on the, or she still is, in fact, on the Vue core team, and she's also a keynote speaker at ReactConf, so really knows how this stuff goes together. I certainly can relate to how all these arrows, it makes sense to me. I want to talk about this first wave, because this is what was going on in 2010. A whole bunch of people had roughly the same idea at the same time. We've got this disciplined way of writing programming from Rails and other patterns like model-view-controller and things like that. Could we do it in the browser? The first one to go public with this was Backbone. That did a Hacker News post on October 13th of that year. And then exactly one week later, Knockout was announced on Hacker News. And another thing happened on that very same day was the first public release of AngularJS. Now Angular had existed in Google for a few years, but this was the first time it had a public release on GitHub. None of these things were done in coordination with each other. It was just an idea that was ready for the world. It had to come out, and a whole bunch of people did it at the same time. So in honor of the fact that Backbone was the first one, I'm going to show you how things looked inside Backbone right now. So I've got a Backbone sample application right here. We'll look at the code in a sec, but let's just start that running. So this is a to-do example. I bet some of you have seen this before. I've taken the code and simplified it a bit there. So I can add stuff to this list, I can mark them as done, and so on. And the architecture of this application is pretty familiar. So we've got a model here, we've got a view, and we've got a sort of controller-ish kind of thing. It's always a bit ambiguous in MVC, like, what is the controller, is it a view model? No one really cares. The point is that we've got model-view separation, that's the key thing. And in this case, we've got a model for to-dos, we've got a model for to-do lists, it's got the ability to calculate things based on what's in the model, such as how many tasks are remaining. And to render that in the UI, it's using underscore templating. Underscore is a JavaScript library created by Jeremy Ashkenas, who also created Backbone, which we're looking at right now. He also went on to create CoffeeScript, which I'll mention in a minute. So he was very influential. And this underscore templating system was rendering this model into HTML, and then wiring up various things to it. And then finally, we've got this controller, and that is a nice, clean way of defining all the different events that can occur, and how that's going to affect your model, and update the UI. So that was pretty nice. And people adopted this sort of approach very rapidly. These frameworks gained traction very quickly, and of course, they're still with us today, or at least newer versions of them are. Okay. So that brings us to a period of very rapid complexity growth for web developers. People were writing a lot of JavaScript by now, and it went beyond the point where even just a nice framework could help them. People by now needed a new language to try and allow them to do this at a higher scale. TypeScript is the one that's ultimately won. The idea of compiling stuff to JavaScript wasn't new with TypeScript. So I just mentioned Ashkenas and his CoffeeScript language. That was probably the first one that really got a lot of attention. And TypeScript followed on by that by adding a full proper type system. Obviously you will know about this, because TypeScript is now I think maybe the second most popular programming language in the world. It's been an unbelievable success story there, really, really effective way of solving real problems for developers. And going with the fact that this is compiled, and people are doing so much of this, we now need compilation and bundling systems, so Webpack came along to fill that need. And I've even thrown in Kubernetes here. Now I know that's not really specific to front-end web development, but it just gives you a hint of how much stuff web developers were being expected to know about by now. It's not just front-end dev and back-end and styling and build systems and stuff. It's also now cloud orchestration. It's becoming a very, very sophisticated era. And it's starting to get to the point where people are going to need to push back against this a little bit. But one other thing came out around this time, which has been pretty important, and that is WebAssembly. So this is the thing that finally separates us from that design directive that Andreessen gave in the beginning, saying you have to be able to just type the script in. So the idea at this point is there are lots of other great programming languages out there. We want to run them in a browser, too. So this wasn't just Mozilla. I know people often say it was Mozilla that did this, but it was a collaboration that started in 2015 between Mozilla, Google, Microsoft, and the WebKit team working on some of the Safari stuff, and they came up with this design, and I've put it down for 2017 because that's when it actually shipped in all your browsers. So would anyone like to know what my absolute favourite thing you can do with WebAssembly is? Well, I will show you. It's running .NET in a browser. So just purely as an illustration of WebAssembly, and for no other reason, I'm going to show you the original Blazor prototype here. So this was created for an NDC conference demo, actually, and if you've done any Blazor programming, you probably might recognize this project template because, bizarrely, we've never changed it over the years. But the thing that's really worth looking at here is what this is doing inside the browser. So I need to be on the home page to load that. So this is, if we look in this network trace, yes, it's getting .NET DLLs and it's running them, but it's doing it using WebAssembly, and before we had the modern .NET for WebAssembly runtime, this prototype was created with something called .NET Anywhere, which is a .NET runtime made by one person called Chris Bacon, and that compiled to WebAssembly very easily, and the cool thing about it is, look how small it is, 52 kilobytes. With the .NET runtimes, we're probably going to be tens or hundreds of megabytes, but WebAssembly allowed us to get this into browsers in just 50 kilobytes, which is pretty extraordinary. It didn't have that much functionality, you know, there's a lot of .NET stuff it couldn't run, which is partly why it was so small, but it was enabled by this new technology that came out in 2017. Okay. So that almost brings us to the current day, and I'm not going to try and interpret what's happened for the last couple of years, because I think, like, the dust hasn't really settled on history yet. We don't know what's going to be important in the long run, but we can start to think a little bit about where we might be heading in the future. What are some of the big trends that we see going on? One of them, I think, is a bit of a pushback against the sophistication and the number of things that web developers are expected to know. Maybe we're hitting some kind of limiting point. And some of the technologies that are emerging might start to help us reduce that a little bit. So one of them is, at the moment, we have to do so much stuff to prepare our content for browsers. Wouldn't it be simpler if the browsers could just work with the stuff that we gave them without us having to build it all? HTTP 2 and 3, for example, mean that you don't really have to bundle content anymore. It's just as efficient to serve lots of small files as it is to serve one big file. And then the type erasure proposal would be a way of running languages like TypeScript directly inside a browser without having to compile them, simply by teaching the browser to ignore the type annotations and other things that the browser doesn't understand. And then this CSS nesting, which is not just a proposal, that is happening, I think, this allows us to get much of the benefits that you have with things like Less and Sass just by baking more and more of those features inside the browser. One of the big features of Less and Sass is just the ability to nest selectors, and so if we can simply make that a native feature of the browser, then, in a lot of cases, we might not need any other thing. Okay? Another big trend that started to emerge in the last year or two is the rise of the meta-frameworks. I don't know if you're familiar with that, but the basic idea now is, especially in JavaScript world, people are using so many frameworks that they kind of need a framework to manage their frameworks, and that's what a meta-framework is. I'm going to show you one of those in a minute. It's various things like SvelteKit and Astro and so on, and they are bringing some really new interesting ideas. The core thing is that, by having a single framework that knows about server-side, client-side, build system, and IDE, you can put that all together, and then you can build new kinds of features that span all of those things, which wouldn't be possible if you just had frameworks in their own little silos, so we will check that in a minute. Finally, there's a little bit of a movement, I would say, towards delivering your web applications not just on a couple of servers in certain places in the world, but in thousands or tens of thousands of locations all around the world. I hear a lot of web developers now getting very interested in trying to ship their stuff all over so that you get these single-digit millisecond response times for your users, and you pretty much can never be down, because, like, it would take, you know, you would have to bring down the entire global infrastructure to take down your website at that point. So, let's have a look at these meta-frameworks, okay? I'm going to show you an example of SvelteKit just because it's got a bunch of interesting new ideas that I think are worth looking at. So, over here, I've got a new SvelteKit application that I've created from its template, and if I go in my browser, then we will see, okay, it's just like a static message, not much to see there. If we look in the source code, it doesn't have much either, but it does allow us to use Svelte, the client-side Spark framework to build an interactive UI. We can see the initial source code is just some static content. And if I start editing that, let's see how the hot reload stuff works, so I can just start typing and I'm not pressing save right now. I did not press save. I just stopped typing, and you see it updated in the browser because it knows about my IDE, and I could even do things like put some style in, and, again, I did not save, I just put some code in, and it knows how to bundle all the different types of content that I provide and get it into the browser, and I, as a developer, don't need to think about how that stuff works. So that's nice. All right. Now let's add a little bit of functionality here. And everyone loves counters, don't they? So I'm going to create a counter, okay? And then I'm going to create a page in there, and I'm going to give it the rather strange but important name of plus page.svelte, which follows the framework's naming convention, and I'll just put some content in there. And if I want to get to that page, I don't have to configure my routing system, I'm just going to go to counter. So taking a bit of inspiration from Rails there, we've got this convention-based routing system, and I could put in the actual logic for a counter. Now you can see it supports TypeScript as well. I don't have to configure how that works. It just knows how to build this stuff for me. We've got a count. We'll display the count. We've got a button. When you click it, it increments the count. Pretty basic stuff. So when I go back over here, it increments the count. Okay? Cool. Nothing special yet. Now let me show you a bit of the meta framework coming through. So I'm going to go back to this home page here, and I'm going to add a link to my counter. Just a normal HTML link. Then go back to the home page, and you can see the link is there. I can click it. It works. Nothing surprising. But the cool thing is what happens on the network when I do that. So when I'm here right now, it has not loaded any of the code for the counter at all. It's just loaded the code needed for the home page. When I go to the counter, you can see it fills in just the little bit of extra code that's needed for that other page. So it's incrementally delivering the different parts of my application as I navigate around. That's called code splitting, so that's pretty good. But what about doing some slightly more sophisticated stuff still? Let's say that I want to have some server-side state. At the moment, everyone who comes here gets a different counter. What if I want them to share a counter? Well, I'm going to start by factoring out what might seem to be something like a code-behind file. So I'm going to have a page called page.ts here, where I can put some TypeScript in. And this, you know, code-behind, it feels a little bit like ASP.NET web forms coming back again there. And the logic that I'll put in here is we'll have an initial count value of 1, 2, 3, just so we can see it's different, and we use this special load method to say this is the data that we want to transfer into our page. And then to actually use it in the page, I'm going to go back to here, and I'm going to put in the actual imports here that will load that data from my code-behind there. So now I come back, you can see that the count is 1, 2, 3, which is this initial value I'm setting, and I can still increment it. But it's still all working completely client-side here. And so if I reload, obviously I'm going to lose the state, and it's all evaluating this stuff in the browser. If I want to run some stuff on the server, I can simply go to this file and rename it to page.server.ts. And just by doing that, it is now going to run that bit of the logic server-side and deal with serializing that state into my client-side page whenever I go there. So that's pretty good. But when I make changes to this counter, you'll see there's still only changes in the browser's memory. It's not changing the server-side count. If I want to do that, I'm going to need to add some sort of JSON endpoint that I can call from the client, and I can do that by adding an action. Pretty simple stuff. It's just a method with a name, and it's going to increment the count. And then to actually hit this action, instead of having a button, I'm going to have a traditional HTML form. Doesn't even use JavaScript in this case. Just a post to that endpoint on the server. So now when I reload, you see when I click this, it's updating the count. And when I reload, it does not lose it. And in fact, this whole thing now is purely server-side application. It's all server rendered. Every time I click this, it's pushing, it's reloading the page completely from the server. So in effect, we've kind of just reinvented ASP.NET web forms right now with server-side rendering. That's pretty good. It can work without script. But you know, this browser does in fact support JavaScript. So could we perhaps even have some kind of hybrid where it would support server-side execution or client-side execution and dynamically use both, depending on what's best? Well, we can. So I can go to this form here, and I can add this magic little use enhanced thing on it, which needs to import a certain thing. Why can't I quick fix that? Okay. I can now. Good. And now that has been enhanced, when I'm back in my browser, when I click this, you'll see it's not reloading the page anymore. It's now still updating the state on the server through an HTTP post, but it's getting the result back and doing client-side rendering because this browser supports it. But if I was a crawler, it would be doing server-side rendering. So that is a pretty nice way of getting the benefits of both. So the point I'm making here is that by having this meta-framework, we can have new types of features. Now, I know if you're a .NET developer, you might think, hang on, I think I've already got a meta-framework. I've already got this one thing that does server and client and IDE and build and stuff. That's kind of true. But the fact that these ideas are coming into JavaScript now is inspiring a lot of new innovation in terms of those features which the whole web community can benefit from. So I think that's pretty exciting stuff. So there we go. That's all we've got time to talk about this morning. I think we can agree that the web has come a long way since Berners-Lee's information management proposal. I don't know if he really knew what he was unleashing on the world when he did that. But the overall thing that I think we should take away from this is that we can change the course of the web. The people who make these decisions, in some cases, they're big corporations, but a lot of the decisions along the way were made by individual engineers. So think about people like Nicola Pello who basically rescued the web from oblivion right at the beginning by coming up with this way of rendering web content as text. Think about Joe Hewitt who decided it wasn't good enough to just view source in Notepad. He came up with a way of having modern browser dev tooling. Think about Ryan Dahl who saw the connections between multithreading and JavaScript and the VA engine and created a new way of doing server-side programming with JavaScript. These were just individual engineers. And so you are those engineers. You're here at this conference. You can chat to each other and come up with some of these ideas about where we're going to go next. And I'm very excited to see it and hopefully be part of what you create. So have a really good rest of the day. I hope you have a wonderful rest of conference. And I'll see you all around. Bye. Bye. Bye.