Eric Meyer: Hello and welcome to Igalia Chats. I'm Eric Meyer, a developer advocate at Igalia.
Brian Kardell: And I am Brian Kardell, also developer advocate at Igalia. And on today's show we have a repeat guest, Dan Applequist, also Torgo online. And we have Dan on. Dan wrote a piece recently. Well, do you want to introduce yourself, Dan, just for anybody who might not know who you are?
Dan Appelquist: Sure. Yeah, I mean, my name's Dan Applequist. Employment wise, I work for Samsung Open Source Group and I'm active in a whole bunch of different activities on the web and open source ecosystem. One of those that's probably most relevant to the conversation is that I am currently co-chair of the W3C advisory board, which is one of the three elected governance bodies within W3C, the Worldwide Web Consortium. And I've also been involved in W3C for a long time and I was previously co-chair of the technical architecture group. And I think one of the other things that I want to enter into evidence in this discussion is the ethical web principles, which is something I helped to write. And yeah, I'm active in those types of things. We can get into a little bit more detail later if you want.
Brian Kardell: Yeah. So Dan wrote a blog post recently pondering some things and I have also been thinking about some of those things for reasons that we'll get into in a minute. But I don't know, Dan, do you want to talk about your post a little bit and what you were mulling? And I think especially whether that is a purely philosophical question or whether there's a reason you're thinking about it.
Dan Appelquist: Right, absolutely. And so the post was called Yes, But is it the Web? Kind of referencing I forget where it comes from, but a quote, 'Yes, but is it art?' It's a little bit intended to provoke discussion. It's not trying to answer any questions. In fact, it's maybe trying to ask more questions and trying to poke holes in some orthodoxy maybe that we have. As I mentioned in the post, I've been working on the web since the beginning of the web. I mean, I feel like I witnessed the birth of the web. I've been working on websites since the beginning of the whole thing and I've co-chaired the technical architecture group in the W3C. So you might think that I have an answer to this question, but depending on who you talk to, different people have a different view about what is the web. And there is no strict definition of the web, and you can't go online and you can't go to... I mean, there's a Wikipedia page I'm sure for the web, but I would really challenge you to find a real strict, succinct definition of what is the web. As I mentioned in the post, some people think that anything you can do in the browser is the web and anything that happens outside the browser such as a native app isn't the web. And we've spent a lot of mileage and a lot of time adjudicating this apps versus web debate, which I find to be... And I was there. I worked on the Firefox OS project in the front lines. Not in the front lines maybe, but in a support capacity. And I helped in some way to start that debate and I'm tired of it. As of 10 years ago, I tired of it and I started to think about, wait a second, we really need to stop having this debate about apps versus web. But that's only one axis under which we can think about the question, what is the web? So like I mentioned, you can have very non-webby experiences in the browser and likewise sometimes in apps you can be doing something that's very webby. Some of my questions are like, if I'm using Mastodon, which is my primary social network these days, but I'm using it on a native app on my phone, am I using the web? I think I am, because this is a web technology, this is something that's of the web. It matches a lot of the characteristics. It's linkable, it's open, it's federated, porous, it doesn't lock you into any particular thing. It's often used to disseminate links to other websites, but in that case, it's not a browser, but it can be accessed in a browser app. If I'm using an airline native application and I check in for my flight, suddenly I'm in a web view and I'm doing something that could be done on the web, but in this case, it's being executed inside a very web-like environment, basically a web view within an application. That's one example, but like there are many, many examples of where web views come up within native applications, and is that the web. So what are some of the aspects that make things the web... Why does it matter? We can talk about some of these things a little bit more, but like why is this not just a philosophical question like how many browsers can dance on the head of a pin? And the fact is it does matter because we are often asking this question when it comes to deciding the priority of work that we do and whether or not something belongs in a certain place like, should we do this work in W3C or should we not do this work in W3C? And the question comes up then, well, is it webby? Is it of the web? And if we are using very subjective terms to think about the web and everybody's got their own idea of what the web is, then sometimes it starts to become a situation where the web is anything that I care about and anything that's not the web is what you care about. I've seen that dynamic in play, right? Or when it comes to things like, 'Oh, that breaks the web.' Well, it only breaks the web if it's breaking something that I care about. So it may be worthwhile to have a little bit more of an open conversation, a discussion about this topic so that we can reason more effectively about the work that we do when we do work on the web and that's kind of what led me to the discussion.
Eric Meyer: Yeah. I used to say that the web was anything over HTTP that had like a URL, right?
Dan Appelquist: It's a fair definition.
Eric Meyer: Yeah. Yeah. But I'm not sure that I'm even that restrictive anymore because like you were talking about in a web view of in an app, you're doing a thing that could be on a publicly addressable URL, but maybe it's not.
Dan Appelquist: Yeah. Well, the other really good example that I've been using a lot recently is the NHS app. We have a national health service in the UK, NHS has their app. It's basically a web view wrapped in a native application that gives you biometric login, but then everything you're doing in that app is in a web view and it's also something that you could be doing on the web in a web browser if you know the URL to it then you can... I can go online and I can do all the things I can do in the native app, but the native app gives me the biometric login, the notifications and a few other bells and whistles, right? So definitely that is the web.
Dan Appelquist: And well, I think it also matters. Another reason it matters, I think, is because quite often when we're talking about the web, we're talking about the benefits of the web to the end user, right? Is it private? Is it secure? Is it internationalized? Does it have accessibility? Those are all features that we come to expect from the web. And if we're suddenly saying, 'Well, those things aren't the web actually,' then they don't need to benefit from all of those things. It's okay if your check-in experience isn't accessible. It's okay if your NHS app isn't internationalized. It's like, actually, no, I want my NHS data to be subject to the same privacy restrictions. I want everything that goes on in there to be subject to the same privacy regime or security regime as anything else. Anyway, yeah.
Brian Kardell: So you're hitting on a distinction that I think I would like to try to make as a hypothetical, but before we get there, I just wanted to say that many episodes ago now we did a show or maybe even two that were talking about XSLT and the effort that a lot of people saw as being driven by Google, but it wasn't to remove XSLT from browsers. So there was a request to obsolete XSLT and remove it from W3C's catalog and say, 'We don't recommend you use it.' And part of this debate came up because there's a question about like, 'Well, hey, if it's not in the browsers, then is it the web?' And why would we be recommending it and why would you do that work in a place called the Worldwide Web Consortium? And I mean, I think these are good questions because the W3C has a huge, huge catalog of a wide gambit of things that it covers. There are 317 standards that have reached rec and only like 23% of them are something that's implemented in browsers. Over 75% of them are not that and many don't even particularly care that they're not. They're not trying to be implemented by web browsers like the social web protocols, for example, I don't think have aspirations to be implemented by the browser directly.
Dan Appelquist: Exactly.
Brian Kardell: So there are ones that cover data formats like XML. In fact, there are 15 different working groups that have been closed at W3C over time that start with the letter X, which is a great-
Dan Appelquist: But there are more recent good examples of data formats. I mean, WebVT is another example, right? Where it's something that is from a format that is currently being updated, which has to do with accessible captions that go alongside of video or media and is that important for the web? Yeah, absolutely. And is it something that needs to run in the browser? Maybe, I don't know, but it might not be seen as like a core browser technology. I mean, there are certain things like that that are.
Brian Kardell: There are other even updated work on some of those older things like JSON LD is a newer semantic web idea that some people actually use and it's-
Dan Appelquist: It's used in a lot of places. It's used extensively. And I mean ActivityPub uses it, for instance, which we've just been talking about, right?
Brian Kardell: Right. So it's a way to annotate data. It's data about data and it's not used by the browser. Maybe browser might find uses for it, maybe it won't, but it's okay. It's still clearly part of the web or it could be part of the web, right?
Dan Appelquist: Yeah.
Brian Kardell: So I was thinking, came out of that, somebody requested that maybe the tag could help define some of these differences in a way that is not combative but is helpful. So not to say those things aren't the web, but a way to get a little bit more specific with the terms. And one of the things that I like about having you on here is that you also were in the tag when I believe we really began framing things in a kind of a, not specifically extensible web, but like the idea of the extensible web that sort of the inside the browser is a platform and like many platforms, you can draw kind of a diagram of the strata of it and it would be great if we could explain that stratas. Anyway, I think we started using the word web platform a lot and it was suggested in the issue that maybe the web platform, even though it has this big sounding word, is actually more narrow than the web. Maybe the web platform is sort of the colloquial word that we've come up with to describe the stuff that is in at least browser engines, maybe browsers even is too narrow, but it's that specific thing that implies, again, we say web APIs, but maybe what we really mean is like the web platform APIs or the web browser engine APIs and we talk about things in terms of the web security model, but well, it really is sort of like the web platform or the web browser security model because the security model that you would have on a server for doing internal work or processing for publishing might be actually pretty different. So I don't know, what do you think about that?
Dan Appelquist: A number of things come to mind. First of all, so I mentioned the ethical web principles, that's something that I helped to write, which is not trying to define the web, but it is trying to draw a boundary around the types of things that we work on in W3C. It's trying to say like when we work on something, we will make sure that it does not cause harm to society, for instance, or that more concretely that it's transparent so that it can be inspected easily, that it's multi-browser, multi-OS, multi-device, that it can be consumed in the way people choose. Those are different ways that we can think about the web. We also can go back to the priority of constituencies that the end user is more important that things should be built according to user needs and then after that the needs of the web developer and after that, the needs of the browser developer and after that, the way back at the least priority is a theoretical purity. I think it's also worth noting that there's a W3C tag finding that is winning its way through the process called the web user agent finding, which is about what is a web user agent, right? So that's another way that we can classify things is what is a user agent? Well, a browser is a user agent, but the browser isn't the only kind of user agent, right? Because the curl is also a user agent. And a lot of the thinking that started off the discussion about we should have a user agent finding is that in some ways autonomous agents or LM agents are starting to become user agents because they're driving web usage or you might have an agent in the sense of the AI agent that actually goes out and uses the web on your behalf, right? So we need to think about that as well. And I think the stuff that's in that document is good in terms of how do we reason about what a user agent is, what are the duties of a user agent, like the duty of protection and the duty of honesty? And these sound like fluffy words, but it's very well written, actually, this stuff, and it makes it clear that the whole point of a user agent is to act on the user's behalf on the web. Coming back to your thing about web platform, I do think that web platform is more narrow than the web. The web is always going to be an extremely amorphous thing and maybe that's good, right? I think that if we can button down or nail down or better define things like web platform or user agent, then that helps us to reason about things. I think one of the other things that we haven't talked about is baseline. So that's something that the WebDx community group is working on this baseline thing. I'm starting to hear this talked about at conferences where I go to and people talk about, 'Hey, there's this new API. By the way, it's in baseline so you can expect to be able to use it.' That's important. When you think about web users or sorry, web developers, people who are actually building websites either commercially or elsewise, they care about what's in baseline. So to some degree, that also has to play a role here, but again, coming back to web platform, the web term web platform has also been divisive because some people seem to really not like it. And I'm not sure. I kind of like the idea of talking about the web platform and having that be a kind of more narrow subset of what we're talking about when we talk about the web, but somehow it rubs some people the wrong way somehow, I think. Yeah.
Brian Kardell: I don't want to put him on the spot, but actually I think it was during the first or the second Extensible Web Summit, the one we did in the O'Reilly conference. Do you remember? Eric was a keynote there and he said that the web isn't a platform.
Eric Meyer: That was what, 11 years ago?
Brian Kardell: Something like that. Yeah.
Dan Appelquist: Defend your statement.
Brian Kardell: No, no, it was a good talk actually. Yeah, go ahead, Eric.
Eric Meyer: Well, from what I remember of that talk, which as you say was like 11 years ago, one of the points I made was that this was the beginning of React and well, React like frameworks. I do remember one example, it was sort of a news/social site as I recall. Anyway, this was a site that if JavaScript failed, there was nothing rendered, like there was no content. And I said on stage, 'This is not of the web.' If it absolutely requires 100% JavaScript in order to render anything, it is not a thing of the web. It is an application that is served across the web and I was trying to, this was at... What was it? Was it Fluent? Was that the name of the conference?
Brian Kardell: Yeah.
Eric Meyer: It was an O'Reilly conference. It was one of the big O'Reilly conferences. It was very JavaScript heavy. And in part I had been asked to come and present an alternate view so I was being a little bit provocative, but I think I'm still kind of sincere in that in that if you make something that requires a very narrow set of technologies and things, everything to work exactly correctly in order to get any content, if it's otherwise literally inaccessible, not in the screen readers can't read it way, but in the nobody can access it if they don't meet all of these criteria very exactly, then it's not of the web. It's just something that's served over the web.
Brian Kardell: But if you host a MP4 on a web, it doesn't render in your browser, it downloads, but it's still of the web. I also want to note really quickly, that's actually when I met Eric for the first time in real life. We had known each other online and stuff.
Eric Meyer: And like I say, I was being a little bit provocative, especially because I literally had people come up to me after the talk as I had expected to say, 'You are wrong.' Or there was one guy who said something like, 'Let's make a bet and let's see where we are in 10 years if I'm right or you're right.'
Brian Kardell: I see.
Eric Meyer: I think the bet he was offering was in 10 years the web will be like if you don't have JavaScript, basically it would be like an all flash web except it would be an all JavaScript web.
Dan Appelquist: And I don't think that's the case. I mean, at least-
Eric Meyer: Which is why I say I think I would argue that I am closer to having won that bet than he was. But if you were to interpret the flip side of that as JavaScript will not be used to serve any content, then I also lost that.
Brian Kardell: I think that this is part of the interesting question because certainly there is a very common understanding of the web in which I would totally agree with what Eric is saying. I do think that those are the things that the web should do for the normal experience of HTML over HTP in your web browser. I totally agree and I agree with what he was saying in that it's a continuum and that you'll have a continuum of clients and I think over the years we have done things like baseline, which is to try to tell you what that continuum reasonably looks like because do you need to be writing for IE3? No, that's not reasonable. It's not reasonable that you should write your thing for IE3 probably. Anyway, I think it's also when we talk about this web platform and this sort of stack of technologies, the stuff in the web browser is also separable. The web engine itself is separable. Like you say, you can make a web view and it's not the same as being in the browser. It's a little bit different. You can add things, you can add native protocol handlers, you can add like where you can read from the file system, you can add stuff for reading your fingerprint, your biometrics.
Dan Appelquist: Electron apps are a good example of that.
Brian Kardell: Electron. Yeah, that's what I'm saying. You could separate JavaScript engines and have things like Bun or NodeJS, and I think I used this analogy the other day when I was talking to Eric and I kind of like it. A JavaScript engine is part of the web platform in the same way that a car's tires are part of a car. They're not a car, they're tires. General principles or regulations that you might talk about with cars don't apply to a tire swing. And that's where it gets tricky because when we go through security review, privacy review, all these things, it helps to know what are you trying to do. Some of the things had issues if you're using them in the browser. And part of that is just because we didn't have the same rigors when we were making them in the first place. We didn't have some of the understanding, some of the rules that we do now, but if you are making a data format, like say JSON LD and you're like, this is going through reviews, how you review that is a little bit potentially different depending on whether you think it's going to be implemented in the browser or it's just a data format.
Dan Appelquist: We haven't even talked about identity, but identity is another thing that W3C is doing a lot of work on, verifiable credentials. And some of that stuff touches the browser, like you have the digital credentials API. Some of it is intended as just raw data formats that enable credentials to be moved around. And again, I think that... Yeah.
Brian Kardell: Payments is another one, right?
Dan Appelquist: Yeah, payments. Yeah.
Brian Kardell: Yeah. And then we had like the automotive groups who are using more like a web view. We have like the mini app stuff that's trying to do-
Dan Appelquist: Those are both worth talking about in more detail, actually. I remember that Hadley and I, and Hadley is currently one of the co-chairs of the TAG and we were both in the tag at the time went to... I remember us walking into a web automotive meeting in one of the TPAC, this was years ago, and asking some questions like, 'Okay, so now can I write my own dashboard using HTML and install it into my own car?' 'Oh no, no, no, no, no, you can't do that.' 'Is this going to be subject to the same security rules as something that runs in another web environment as in the browser?' So it came to our view at the time, I don't mean to put words in Hadley's mouth, but I think this was our shared view, was that this didn't seem like it was very webby, what was going on in the web automotive group. It was basically like using HTML and JavaScript to write a effectively packaged and somewhat proprietary way to do infotainment systems in cars. So that left us scratching our heads. Now on the other hand, more recently we've been looking at mini apps. Mini apps are widely used across China in particular and by billions of people. I had the opportunity to visit China recently and I was using mini apps. I have to say I was running my Alipay application, which is the main application and then these mini apps kind of pop up within Alipay or within whatever super app that you're running. And again, this came to my mind as I was thinking about how do we define the web. If we exclude mini apps, then to a certain extent we're excluding them from the benefits that the web brings. So one of the things that the tag has pushed on a number of occasions to the mini app community is please use the mechanisms that we already have in the web, use the manifest file instead of building your own manifest, make sure that mini apps implement the web security model instead of having a different security model. And I think all of that, if we can get over those humps and some of those things are happening, that community has been receptive to those comments. Then does it matter that I cannot bring up my mini app super app and enter in a URL, but in fact I'm only allowed to go to the curated set of mini apps that my super app provider has chosen for me? I mean, it's not the world that I want to live in. I prefer the open world, but I can see the benefits of such a world being implemented using web technologies and therefore benefiting from the good things that we put into the web, if you see what I mean.
Brian Kardell: Totally. Yeah. Last year at TPAC and the conversation has continued a lot, I'm hoping that by the next TPAC, we actually get to the thing that we talked about last TPAC, which is there was a joint session that was the WebViews community group and the mini apps working group and people from isolated web apps, which is another community group, and people who are interested in electron... And you work for Samsung. Samsung has some TVs, I believe.
Dan Appelquist: Oh yeah. We haven't even talked about TVs, but that's a whole nother mess. But yeah.
Brian Kardell: Yeah. No, but TVs, I say this all the time, depending on where you are in the world, it's almost impossible for you to get away from the web, right? I mean, the web isn't everything.
Dan Appelquist: If you're watching Netflix, you're using HTML and JavaScript. All that stuff is built in. I mean, part of the challenge there, just to divert for one second, is that those environments don't... They have a lot of proprietary APIs. They're not built to some degree using the same security model and they don't update nearly as often. So if you have your phone and you've got your browser on your phone, that updates very often because that's how browsers have come to update, because they need to do that in order to introduce new features and introduce security fixes and stuff like that. The web runtime environments that are baked into TVs update much more slowly. And you'll see if you look into it, you'll see that you're running a version of Chromium there that's much, much older.
Brian Kardell: But also maybe it doesn't matter as much in a lot of ways. There are lots of places where-
Dan Appelquist: You can train the environment, but yeah.
Brian Kardell: There are lots of places where you use the web that you're not even realizing a point of sale system in a store when you're at the gas station, those interfaces, driving down the street, digital signage, all the infotainment systems, like wherever you are, even lots and lots of smart appliances and thermostats. We worked with people who make speakers that have a web interface in them. Even medical devices and things use it. I think it was one of the NASA things, right, Eric? We have JavaScript in space.
Eric Meyer: Yeah. The James Webb Space Telescope runs on a 20-year-old version of JavaScript.
Dan Appelquist: I didn't know that.
Eric Meyer: It's a very specific version of JavaScript, but it's like a 2005 era JavaScript that I think was not forked exactly, but it was adapted in some minor way for use in things like space probes. Daniel Stenberg talks about how Curl is running on Mars.
Dan Appelquist: Oh yeah. Well, curl is everywhere. Yeah.
Eric Meyer: And so is JavaScript. And you could argue therefore the web, although to go back to my 2015 talk, maybe just JavaScript isn't enough or maybe it is. Actually, while we were talking, I dug up the slides. The title of the talk was This Web App Best Viewed by Somebody Else.
Brian Kardell: All those things use web technologies, that's inarguable. And they all benefit from them. There's this societal benefit in a lot of ways. They're the infrastructure of the modern world. That's nothing to sneeze at. We're happy about that, but is it the web?
Eric Meyer: Yeah.
Brian Kardell: Yes. Is it the web platform? Kind of. I feel like we do need some more words here. So in that TPAC session last year, there was discussion that the mini app working group was, their charter was set to expire. And they had had some successes, some frustrations. They were looking at where to go next and we thought all of these groups are trying to do something really, really similar. I don't know, we call it the embedded web or something like that. And maybe we can, rather than everybody swim in vaguely similar directions but not to the same place, we can all get in the same boat and paddle to the same place and more likely actually arrive. So I don't know. I'm hoping that we can work together to figure that out and probably it means some distinctions and new terminology because you're right in a lot of ways that I don't know how much of a problem it is that like my digital signage can't use has as a CSS selector if it doesn't use has. You know what I mean? It doesn't matter. Are there critical security updates? That's a different story. But most of them nowadays, more recently they do send security patches at least. I know we maintain WPE, the webkit port for embedded engines and yet we work with lots of companies to do those. We release security patches pretty regularly.
Dan Appelquist: I mean, the other thing that I'm covering right now is a lot of work having to do with the CRA, the Cyber Resilience Act in Europe, which we've been talking a lot about how does this impact web developers. And again, it also touches on the question of what is the web, right?
Brian Kardell: And what is a user agent?
Dan Appelquist: And what is a website versus what is a web application? So it turns out the regulation has a specific carve out for websites where websites aren't really covered under the CRA. So therefore they don't... As a web developer, as a 'normal web developer,' you don't have to worry about CRA obligations with regards to software supply chain security and stuff like that. But if your web application happens to be in a native application, you're writing the web app that allows somebody to check in for their flight, or you're writing the NHS web app that I was talking about before that's packaged up in a native application. Or if you're writing a web app that plays a part in another product with a digital element, and my example that I have trotted out at a couple of talks is I have a home thermostat system called Hive, which is a UK based company that does home automation and they have an app that allows me to control my home heating and whatever, my valves on my radiators, but I can also log into that system using a web app. So in that case, there's a risk there. There's an inherent... If somebody exploited a flaw in that application, they might be able to do damage to my house. Real world consequences are happening because of security issues. And so coming back to the point about, is it the web, the question of whether or not somebody needs to pay attention to some regulation is based on the answer to that question. Am I building something for the web or not? And so again, it would be good to have some better guidance out there. I don't know. I really like the idea of the folks from the web view group, from the mini app group and from the isolated web app group communities coming together and having a bit of a discussion and moving forward. That's called standardization And that's ideally what it is that what the value of something like W3C brings is to bring those conversations together. Often that happens in like a workshop where you bring disparate voices together and then it turns out that, 'Hey, we agree on like 70% of this.' So then you end up with something that satisfies many of the concerns and some people have to climb down from some of their positions, but basically you end up with a good thing that satisfies many people and you've taken advantage of a kind of good economy there of having multiple implementations that implement all the same thing. So yes, that would be a really good thing. It's been difficult to get those people to talk to each other in my-
Brian Kardell: Yeah, totally.
Dan Appelquist: But sometimes they say that the definition of insanity is something doesn't work again and again, and so you try it one more time. But in my experience, sometimes that is what you need to do. You need to keep asking and you need to keep prompting and you need to keep prodding and eventually people do start talking to each other and sometimes you need to ask multiple times.
Brian Kardell: Yeah. It can take years, right?
Eric Meyer: Yeah. Doing the same thing over and over expecting a different result may be the definition of insanity, but it's also the definition of practice and persistence. Yeah. Sometimes you need that. I mean, the web platform is nothing, if not persistent, right? It's been much more persistent and much more resilient than I initially gave it credit for being possible or being capable of. There are at least two distinct times in the last 30 years where I was sure that the web had only a few years left to live because technology blah, different technologies each time were just completely going to replace the web because for whatever reasons, and I'm not going to go into this. But I've come to appreciate a quote that I saw somewhere, I cannot find it, but someone said something like, 'It's very hard to figure out what the right winning bets are in technology, but the one sure losing bet in technology is to bet against the web.' And they said this like 15, 20 years ago and I wish I could track it down so I could get proper attribution.
Dan Appelquist: And I echo that. I absolutely echo that. There have been so many, and I'm going back to the '90s here, so many examples of people coming out with a new technology and saying, 'This kills the web because many people want to... They are threatened by the web and it's lack of a single control point.' I remember people wanted to replace the URL with something else that would be so much easier for people to understand. Of course, with one single control point where you have to register them with one, you have to register these things with one place. And the example of technologies, again, that comes back to the definition of the web. We know we can look at something like that and we can say, 'Okay, well, that is not the web, clearly.'
Brian Kardell: Supreme Court definition.
Dan Appelquist: So it's worth having these discussions so that we can make sure that as the web continues to evolve, that it evolves along a positive and a beneficial track.
Brian Kardell: Yeah.
Eric Meyer: I would also say that probably some of the people who came out with, 'This will kill the web,' maybe some did it, not because they were threatened by the web so much as they wanted something very different. They wanted a different environment than the web provides for development. I mean, Douglas Crockford has a famous comment about the web is the most hostile and software engineering environment known demand.
Brian Kardell: Certainly was very true when he said it.
Eric Meyer: Well, but if you come... We know people, all of us know people who vastly prefer the backend because it's a very structured and predictable and sort of instant feedback on errors environment as opposed to the web, which is designed intentionally to be very resilient, very fault-tolerant, and does not instantly throw an error to say, 'Well, here's where you messed up your CSS.' It just ignores the bit of CSS that it doesn't understand. That is very hostile if you're used to, 'Well, if I make a mistake, the compiler will catch it.' And so my take on what he said is that it's the most hostile environment to developer assumptions known to man. And if you make certain assumptions, you are likely to end up hoist on your own trap basically, not even meaning to. So there have been people who have proposed replacements for CSS, because CSS is to whatever it is that they don't like about it's too much that it's too... There have been proposals to replace HTML because it should throw air. I mean, very strict error handling and if you got your markup wrong, it would literally just throw an error message instead of trying to run to the page that didn't really go anywhere. And those of us who sort of grew up or developed in the web environment came up in that. And so we absorbed those principles of ubiquity over consistency, and ideally accessibility over gatekeeping and resilience and fault tolerance over very sort of fragile, strict things. I think one of the reasons that they're defended so fiercely is that they are very human. They're not mechanical. A mechanical environment is one where it throws an error the instant, it detects a problem and doesn't try to go any further. A human environment is one where, okay, well, there was a mistake here. We're just going to skip past that and do the best that we can with the rest.
Dan Appelquist: Right, right, because it benefits the end user, right?
Eric Meyer: Yeah.
Dan Appelquist: The worst thing is that the user gets an abstract error message and then can't check their bank balance or register their car or the types of things that people use the web for, which are like, it's so important to them.
Brian Kardell: Everything, I mean, to get their medicine, right? There's a lot of really catastrophic people can't get access to critical services and stuff like that.
Dan Appelquist: But there's another, and I know that we're getting low on time, but I mean, there's another axis of the web versus not the web, which is more of like a business thing. So in the mid '90s, I worked for AOL and that was at a time when people at AOL viewed their model as being the future of digital services that would be brought to the end user. And their model was very much, if you want to have your newspaper or your service or your pizza delivery shop on AOL, then you do a deal with AOL and that therefore AOL brings it to you. It's much more like a cable TV model. And the dynamic that we've seen since then is very much like this thing where companies grow up on the web and then they sort of forget what helped them grow and what made them successful in the first place, and they start to turn inward and exhibit some of those same properties of trying to control everything and trying to be the single conduit. And luckily the web is, I would say, and maybe this is one important aspect of the web, the web is resistant. The web has a healthy immune system that is able to resist that kind of centralization and allows alternatives to be developed. One social network becomes too powerful, well, people can develop their own open source alternatives, right right now we have two examples of that actually in terms of two different ecosystems.
Eric Meyer: You could argue that the web interprets insularity as damage and routes around it.
Dan Appelquist: It does. Yeah. I think it doesn't do it by itself. It requires people because it's of people. The web is for people, it's a people based system.
Eric Meyer: This is for everyone projected onto the, was it the 2012 Olympics?
Dan Appelquist: So we all need to pay attention to this and help us and it requires constant support, but it's worth supporting.
Brian Kardell: Going back to your kind of like business thing, it's a little bit different aspect of that point, but when you do break these things down into their component parts, more and more people are interested in the component parts because you don't have to buy into the whole thing. And so when you take it that way and you look at like V8, how many people are interested in V8 in the browser, it's a really huge number, but then how many people are interested in it because of Node? How many people are interested in Node because of the ability to make packages with electron? And the nice thing about that is that all of those people are not just interested in their little bit, they inevitably find reasons to commit upstream. And so I think we're helping build the open source commons by increasing the number of people who are interested in different parts of it. Having some definition that helps everybody be included in that is actually really important for the long-term sustainability of the web because I mean, I have said a number of times that someday Google won't be Google. Google is not the company that it was 15 years ago, but it's still Google and someday somebody, I don't know, going to knock them off their pedestal and they will go the way of Wang Computers of-
Eric Meyer: Alta Vista.
Brian Kardell: Yeah, of Alta Vista or like AOL. I mean, these were giant, giant industry leaders.
Dan Appelquist: There are many of those. Yeah. Yeah. I mean, one of the things that comes to mind, coming back to the thing about what is the web, right? And is it possible and you talked about the web being a continuum, Brian, and I think that's true.
Brian Kardell: I was quoting Eric actually.
Dan Appelquist: Oh, right. Okay.
Brian Kardell: Yeah.
Dan Appelquist: Do we need a webiness quotient, right? Like a set of tests that we could apply to any given thing and say, is it the web or not? Well, we're not going to give you a yes or no answer, but we'll give you like a... Yeah, it's 70% fresh web. No, this is 30% so we're really thinking it's more, I don't know, I'm thinking of like the Rotten Tomatoes score.
Brian Kardell: Right, right. I like it.
Dan Appelquist: That might be more apt.
Brian Kardell: We can make an app for that.
Dan Appelquist: Okay.
Brian Kardell: It's true. Okay. Thanks, Dan. I don't know if the tag will ultimately produce a finding on this like we were asked to. I certainly think it's worth continuing to talk about and think about and yeah, hopefully if we do, you'll weigh in on that.
Eric Meyer
Brian Kardell
Dan Appelquist