Since 2016, the Norwegian Developers Conference has been holding a companion conference in Sydney, Australia. Last month, one of its presentations was a whirlwind tour through the history of the web and its development tools — bringing a detailed and thoughtful perspective on what led to our modern web development landscape.

Along the way, the audience got a demo of the world’s first web server, compiled from its original 1989 source code, and other web development tools from over the last three decades to explain how we got to where we are.

But at the end of the talk, the audience also heard some informed speculation about where it all might ultimately be heading.

In short, the talk offered its audience a glimpse at the way we were — and at what we might become.

Birth of the Browser

The talk was delivered by Steve Sanderson, the original creator of the web app framework Blazor. (A bio on Steve’s website notes that he’s worked on everything from JavaScript libraries to the new Azure management portal.) Sanderson recently rejoined Microsoft’s core team for its web application framework ASP.NET “with a goal to make the platform a sheer joy and delight for JavaScript developers.”

But the title of his talk promised to tell web developers “Why web tech is like this.”

Before running the world’s first web browser, Sanderson began by compiling the code for the world’s first web server — the 700 lines of C code that powered Tim Berners-Lee’s TCPServer.c back in 1989. It created a 22-kilobyte binary named httpd that, instead of port 80, listens on port 2784. “Apparently those are the last four digits of Berners-Lee’s parents’ phone number,” said Sanderson.

Also included were diagnostics like console traces for viewing the HTML file’s source code in various formats. “So we’ve kind of got early browser dev tools in there, right at the beginning,” said Sanderson.

It’s not the only early software with built-in development tools. Pei Wei’s 1991 Unix-only browser ViolaWWW even had 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,” Sanderson said.

“But even more impressively than that,” continued Sanderson, “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.”

These are not just historical curiosities, but examples of a larger point Sanderson makes: 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,” he said.

Developing Dev Tools

For better or worse, these individual decisions can echo through the decades. For example, when Brendan Eich created JavaScript in 10 days in 1995, Marc Andreessen had specified that he’d wanted a noncompiled language so that people could input the code directly into their HTML. “That is a design decision that’s gone with us all the way up until WebAssembly was eventually created,” Sanderson said.

Yet as recently as 2006, “the closest thing you get to any browser dev tools is viewing the source in Notepad,” he said.

Improvements came with Joe Hewitt’s browser plugin Firebug in 2007 — complete with a Console, HTML view, CSS, script debugger and network tracers. “This design has largely stuck with us all the way through,” said Sanderson. “It was even pretty much just copied by Google as soon as they released their Chrome browser.”

Sanderson’s talk whizzes through the rise of mobile-first design, with the 2007 release of the iPhone, until it reaches a kind of inflection point. Sanderson argues that JavaScript was “reborn” between 2005 and 2008 in a quest for appealing interfaces to attract user-generated content. The release of Google Maps demonstrated the potential of asynchronous JavaScript for doing requests in the background and updating pages dynamically — and “that really has stood with us all this way.” And Sanderson highlights one other “major enabling technology of the time”: jQuery in 2006.

But in Sanderson’s telling, the real turning point seems to be around 2010, a time when JavaScript was everywhere — albeit still in those massive and messy jQuery applications. Along with Ryan Dahl’s release of Node.js in 2009, Sanderson credits the O’Reilly book “JavaScript: the Good Parts” as triggering a newfound respect for JavaScript, leading to a remarkable confluence of framework releases:

“A whole bunch of people had roughly the same idea at the same time” — the idea of bringing disciplined development models (like Model-View-Controller or other patterns) into web development.

“None of these things were done in coordination with each other,” said Sanderson. “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.”

It’s interesting to see how he summarized our modern era of web development as “a period of very rapid complexity growth for web developers.” He even pulled up a slide with the logos for TypeScript, webpack… and Kubernetes.

CoffeeScript (first released in 2009) more popular the idea of compiled JavaScript. Building on that, TypeScript added a type system, and became “an unbelievable success story” and an “effective way of solving real problems for developers.” But with the proliferation of compiled JavaScript, “we now need compilation and bundling systems, so webpack came along to fill that need.”

Sanderson said that he included Kubernetes (2014) because “it just gives you a hint of how much stuff web developers were being expected to know about by now. It’s not just frontend dev and backend dev 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.”

Facing the Future

At the end of his talk, Sanderson pulled up a slide entitled “the present and future,” giving him a chance to pontificate. Looking ahead, Sanderson predicted “a pushback against the sophistication and the number of things 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.”

Sanderson applauded browsers that can handle more content with less pre-preparation from web developers, citing specifically native CSS nesting, which “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.” And he’s also seen proposals for type erasure: “a way of running languages like TypeScript directly inside a browser without having to compile them, simply by teaching the browser to ignore type annotations and other things that the browser doesn’t understand.”

But our world is evolving in other ways. Sanderson noted a new movement toward cloud-edge content delivery — “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.” The advantage? “You get these single-digit millisecond response times for your users, and you pretty much can never be down, because you’d have to bring down the entire global infrastructure to take down your website at that point.”

Sanderson mentioned the lower latency made possible by the HTTP/3 protocol and the WebTransport API. “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.”

Another big trend is the rise of meta frameworks like Sveltekit, Astro and NextJS. “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… 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.”

Meta frameworks bring new types of features. While .NET developers might already have experience with a combined server/client/IDE build solution, “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…”

At the end of the talk, Sanderson emphasized that individual engineers can make decisions that influence the future of web development. “You are those engineers. You’re here at this conference, you can chat with 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.”