Brian Kardell: Okay, so hi. I am Brian Kardell, I'm Developer Advocate at Igalia, and I am joined by a special guest today. Do you want to introduce yourself?
Robin Berjon: Yeah. Hi, I am Robin Berjon, I'm a freelance technologist working primarily on problems of governance. It's a pleasure to be here.
Brian Kardell: Back here, you were on, I think nine or 10 episodes ago to talk about your rewilding the internet piece, which I thought was great, and somehow it stumbled me into some old blog posts and I wanted to figure out how quickly we could get back to here because you wrote this piece in 2014 that was called Web 2024. Do you remember?
Robin Berjon: I do remember.
Brian Kardell: I feel like maybe you could give some context about why you wrote that piece when you wrote it.
Robin Berjon: I think where it was coming from is we were about to ship HTML 5 if memory serves, we were wrapping up the recommendation for that. It was also a time where I think it was the web's 25th anniversary, the working group's 10th's anniversary, the W3C's 20th anniversary. These things line up with neat numbers, and so it felt like a time for reflection and rather than thinking about how the web had evolved from 2004 to 2014 I thought that going forward might be interesting.
Brian Kardell: Yeah, I thought that was a great idea and I seem to remember that other people also thought that was a neat idea and wrote some similar posts, but I couldn't actually find any very easily. So if y'all know of some that are out there, share them. But we'll talk about this one because it's fun, because it is a time of reflection and some of them will be pretty good guesses and other ones not so much the way that prognostication goes, right? I have shared a bunch of times that Amazon and Google both when they came out, I thought, 'That is never going anywhere. You're never going to make money that way,' but two of the most fantastically successful companies in the ever. Yeah, so some of them will be bad, right? I mean, there are some famously bad predictions that I also stumbled across that were about this reflection in 2014. So people were like, 'Hey, let's reflect on some things about the web that people made since we're talking about this anniversary of the web.' And one was Bill Gates said that spam will be gone within two years in 1994. And also somebody said nobody will ever make any money on the internet, also clearly very wrong. As we just said, those two companies are two of the most profitable, lucrative companies ever. So yeah, anyway, I thought it would be fun. So you wrote this piece that was predictions.
Robin Berjon: Yeah. And you're right, that piece was surprisingly popular at the time. I think it was and might still be one of the blog posts I've written that was read the most, at least in a short period of time. I don't keep stats, so I don't remember the details, but it was in the hundreds of thousands of hits within a few days and it was picked up by Smashing and a whole bunch of venues with lots of developer outreach. And indeed, a lot of people did write about how they agreed with maybe one thing and disagreed with nine others and had different reflection, so it was quite fun. Actually I had a notification in my calendar, which I set back then for this year, this July, to get back to Simon St. Laurent about those predictions because I remember he disagreed with me quite strongly, I completely forget what about, and we were supposed to get a beer, talk about it 10 years later. So I got the calendar notification, I sent him an email. I failed to reach him, unfortunately. But yeah, it was fun, it was a fun day. And interestingly, that blog post actually landed me a job because in there, there's a paragraph somewhere towards the end where I talk about how in this wonderful world of 2024, the scientific community has realized that using PDF is the dumbest thing ever and has finally switched to some decent formats involving HTML and semantics and stuff like that. And because of that, the CEO of a small startup called Science.ai that was working on Scholarly tooling reached out and offered me a job, which I took and moved to New York for at the time. So it was a pretty big deal, even though as you might notice, we are in 2024 and PDF is still a pretty big thing in scholarly publishing. So I don't think we've reached that, I don't think that prediction has come to fruition yet.
Brian Kardell: There are some aspects of that that are interesting though. That same paragraph you say, 'Linked with better support for MathML specialized dialect of HTML eventually surfaced for scientific publishing and was recently made the default format of the archive.' This is just quoting you, that's not a thing that actually happened, but it's not far though, it's not far. They have a HTML format in archive this year, and it is in no small part because of greater support for MathML. I guess you could also say that a lot of PDF viewing is actually via PDF.js so it is still somehow in the browser in a weird way. But yeah, anyway, it's an interesting prediction that maybe is closer than you think.
Robin Berjon: We're definitely closer than we were 10 years ago. MathML support has massively improved, that's certainly true, and that's a great part thanks to Igalia, I believe, if I'm correct on that one. It's certainly true that the archive now supports HTML outputs. It is promising. When it comes to rendering PDF in the browser, I think that's a tribute to how powerful browser-based rendering has become. It's still somewhat sad because PDF as a document format is not very accessible, has very poor semantics and is terrible for anything from mobile rendering to cutting and pasting. So even though we're rendering it in the browser, I wouldn't count that one as a success just yet.
Brian Kardell: Yeah, I think it's better than the situation was in 2014, but I still don't think it's good. Here's when I want a PDF, never.
Robin Berjon: Same, but if you want something that's downloadable, I do most of my scholarly reading on my remarkable, you need a package format that's support a number of features, and EPUB never broke into that world, right?
Brian Kardell: Yeah. Let's go back to talking about it, because I think we'll come to some of that in the predictions. So one that you predicted was that there would be a rise in single-page apps and you are right. Nobody can see you laughing hysterically, but I can share that Robin is falling off his chair with laughter. Do you want to talk about what you said in the prediction or do you want me to?
Robin Berjon: I did say that SPAs would become big, and indeed they have, so that certainly matters. I did say that service workers and frameworks built on top of them would become big, and I think that has been correct. However, I did imagine that as part of a world in which we would see a lot more JSON based backends that could be interoperable between websites, that has not happened. So the idea being that you have an SPA that's basically just the shell for your website and sort of the back end has some rich semantics that are not RDF but can be interchanged across websites, that hasn't happened at all. And also this idea that in the blog I talk about the fact that there's basically no such thing as native, it's blurred completely between web and native. I don't think we're there either at this point.
Brian Kardell: Yeah, yeah, definitely not. But you made this observation that, yeah, actually everybody thinks of SPAs as great match for applications, but they're actually a pretty good choice for content in a way because on my blog, I write the content, the content is its own piece, and then it's just the shell around it, and why do I have to send the shell down the wire every time?
Robin Berjon: Yeah.
Brian Kardell: I wonder why we haven't really addressed that. I mean, we have a few times opened issues about it, but we just seem to not.
Robin Berjon: I mean, I think essentially you could today build a website that way. If you leaned really hard into custom elements, it could work that way. People haven't built things that way quite yet. I'm not sure why, but it's feasible. I say that, I haven't built my own blog that way.
Brian Kardell: I think it's interesting to think about because it feels very natural to think that way but then as you start thinking about it, we always run into these difficulties and it's like, 'Well, you get this flash fund style content, and then what happens if somebody pulls up?' Do you need some way to have a self-hosted version in the sense that if somebody requests a fragment, should the page be smart enough to go, 'Well, you don't have the outer shell yet, so I need to also give you that'? I think it just gets complicated and we've not tackled it that way. But I don't know.,It was an interesting prediction, and part of the reason why I bring it up is because you do say people wound up with APIs around JSON that would be interoperable and because of that also then wound up with a real web of data. And I thought it was a nice touch that you said that virtually none of this data relied on the RDF data model or even JSON-LD as publishers were, for the most part, unaware that such options even available to them, let alone understood how they might help or work.
Robin Berjon: I mean, I think I wrote it again, I'm sort of guessing at what I was thinking back then, but I think, at least definitely in 2014, the moment you would start talking about web of data and how everyone could publish data and inter-operate people's minds at least in the standard space, would go straight to RDF, right?
Brian Kardell: Mine did.
Robin Berjon: Right, yes. And the problem with RDF, and I would put it in the same bag as other technologies like SOAP for instance, is that they are so general purpose and so lacking in an opinionated approach to the problem that they're trying to solve, that you end up basically having to bring your own opinions and then when you bring your own opinions, you no longer inter-operate well with others, or you have to do extra work that the format itself doesn't provide you with. And so you're paying a lot of extra tax upfront for features that you don't need or don't need yet or might never need. And if instead you're doing some really basic JSON and you haven't thought about how virgin.com might inter-operate with cardale.org, then you can write a very simple transformation if your data is not stupid to go from one to the other and eventually maybe align on something that makes transformation easier or removes the need for it. And that's likely a much more organic, much more opinionated and based on experience way of reaching a solution than these sort of general purpose toolkits.
Brian Kardell: Yeah, it's difficult too because you're a step away from the real world for sure. I mean, no matter how much we try, there are only so many people who can afford to participate in standards, do you know what I mean? It takes time. So you only get so many use cases, so many voices, so many opinions, and there's a lot of curveballs out there, I mean, I think as everybody knows. And we have some people at least who are very, very good at predicting those and helping us avoid the pitfalls, but it's hard to impossible to make stuff preemptively like that. And so I remember reading this and thinking, 'Yes, I love it,' because this is what I was advocating we should focus on, we should refocus standards on figuring this out. How do we let things organically bloom and then recognize when there are opportunities to align the stuff that already exists, the 27 different approaches that are very, very close but different to talk to one and make agreements to become interoperable? I thought custom elements would give us this.
Robin Berjon: It might, it still might.
Brian Kardell: Yeah. But it's relevant because actually in 2014, you and I both gave a talk with Marcos Caceres... Not a talk, we led a session, a breakout session at TPAC that was called After 5, remember that?
Robin Berjon: Yeah.
Brian Kardell: And then I was given the sort of AC badge for jQuery, and I made a plea to W3C start thinking about this, how do we be monitoring the situation and as it develops and help it toward agreement and then write it down, make it official? It is actually in a lot of cases the way that W3C worked historically, nobody just admitted it because the early HTMLs, there was a lot of effort to standardize stuff, but in the end, a lot of it was ultimately writing down what-
Robin Berjon: Was there, yeah, yeah. And I think your efforts and the efforts of a few others were quite successful in bringing the jQuery kind of feature set to the DOM. People who use the DOM today might not realize just how junky it used to be to get anything done in the vanilla of vanilla DOM, it used to be extremely painful. Nowadays, I haven't even thought of using a library on top of the DOM when I need to manipulate the DOM, right? There's still other things like having a virtual DOM and having an update lifecycle that makes sense for customer elements where you want use a library. So I tend to use Lit HTML, for instance, quite a fair bit because it fills in those gaps nicely, and I really wish we standardized some of that stuff. But if I want to manipulate the DOM, I just hit the DOM and it's really easy. And that's because it basically did what you just said and stole features from jQuery left right and center, just the basics, not even a crazy amount, but just the thinking and the approach of like, 'Hey, maybe methods can have an arbitrary number of arguments, and it doesn't matter if you want to append multiple elements, just put those three elements in there and it'll append them.' And that was moving away from the idea of a DOM that had to work for Java and C# and whatever else to a DOM that was an browser thing where we could actually use JavaScript. So I thought that was very successful.
Brian Kardell: Yeah, I just want to point out that that is also in one of your predictions. At some point, someone underwent the epiphany that enabling developers to produce high performance content is at least as important as the raw of the runtime itself. This finally led to Dom to catch up to jQuery in terms of usability and making it possible to live without it and thereby remove its loading impact. So A+ on that one.
Robin Berjon: I mean the jQuery part, yes, but the part where people don't no longer load a framework maybe less so.
Brian Kardell: Yeah, true, fair, fair. But to be fair too, though, you do, even if you rewind this podcast, unless we cut it, you did talk about how you predicted that frameworks would spring up around SPAs and things, and so I don't think the problem is loading a framework because I do think that the web itself has to be generic in a little bit the way that you were saying, where if it's too generic, you have to solve too many things, I think that inevitably some kind of frameworks are probably inevitable.
Robin Berjon: Yeah, yeah I do think it makes sense to need frameworks because frameworks bring something that you wouldn't want a browser to do in the sense that a good framework will be opinionated about things like your life cycle along the such. That being said, I think we could lighten up some frameworks. I think-
Brian Kardell: Definitely.
Robin Berjon: Supporting some VDOM directly in the browser could help there, some very basic forms of templating, the kind like that Lit has, for instance, would also be pretty useful. But yeah, no, you're right, frameworks I think are unavoidable, I think the question is how do we make them as lightweight as possible?
Brian Kardell: You had another one in here that I feel like might be related to that, which is the same ability to pre-process arbitrary content before it is loaded applies to audio and video, which given the performance now available has become essentially JS self-decodable formats, putting an end to the seemingly endless stranglehold of the codec IP mafia. So is this web codecs that you're talking about?
Robin Berjon: Yeah, no, I mean we're headed there and you could also think of just pure WASM as a way of implementing that. So I think we're essentially largely there. The situation 10 years ago was really like everything's like flash and real video. I mean, flash had already started dying in earnest, but it was still controversial to talk about native video in part because that led to the entire EME and DRM discussions. So a lot of content out there was not native HTML video and so the codecs issue was really key. I think you are right that this is smooth over in the intervening years. I don't hear people complain about video and audio codecs as much today.
Brian Kardell: Definitely, definitely. Are we a place where you could use WASM and web codecs to make it popular in the first place, or is that...?
Robin Berjon: I mean, it would probably still be quite rough. One way to think about it is, because you were involved in that, if you had to do responsive images today, what would you need from the browser in order to get that kind of rendering done right? If we're talking image formats, pre-loading in WASM, using that to decode a format and somehow converting that format to pixels seems feasible. It might be clunky, but it might have some rough edges. If you want to support any kind of image format, you might need something nasty like having your image decoder be able to talk back to the network layer, for instance, if you want to support Wavelet images that have multiple built-in resolutions and you wanted to rent them yourself, you do need to require more bytes, right? But yeah, I don't know, it could be interesting. It would be fun to try and to see what works and what's rough about it.
Brian Kardell: It's a tricky one, right? Because I think that people would make a lot of arguments, there were arguments made by HICSI even like, 'If the web natively supported audio and video, it would be such this huge boom and you can have this streaming and this is very efficient,' and blah, blah, blah. But in practice, a lot of the industry chunks the video themselves, and they use this complicated JavaScript to manage that and it's not just HTTP range requests and all that native stuff. I think that they do that for performance?
Robin Berjon: Probably yes.
Brian Kardell: We actually should have some people on from Igalia's multimedia team to talk about that, because that's an interesting thing. Let's go back to predictions, so you also made a prediction that was related to DRM?
Robin Berjon: Yeah, I mean, that was completely wrong. We still have DRM, we just don't fight as much about it anymore, right?
Brian Kardell: It was a hot topic in 2014.
Robin Berjon: It was really hot in 2014. I really wish we'd figured out a better way of managing that. I think it's interesting because in parallel at the time you had a DRM push for audio/video in the browser, and you had the DRM push for EPUB. And the audio/video one really fully succeeded, and the EPUB one, DRM got blocked and the working group refused to support DRM DPUB. The difference between those two is quite interesting. In the EPUB one, there was zero civil society involvement. We didn't have a bunch of EFF people protesting it, it was just managed internally but we managed to very effectively get enough implementers against it and enough publishers against it as well that it was blocked. In the main one, the one that was highly debated, we had this crazy set up where the people I would agree with like EFF and all those folks were mad at W3C, even though W3C cannot make those decisions, right? It doesn't matter. They were fighting completely moral but ineffectual battles because the people to push back against would've been Google and Apple and Microsoft and Netflix and whoever was pushing it. Every time I brought that up, the answer was like, 'Oh, but those are too big, we can't fight them.' And so you ended up with people pushing against W3C, which was not the fulcrum of power and going to MIT and taking protest selfies in front of the W3C office, which is just about as useless as it gets. And then unsurprisingly, the mobilization failed because it was pushing back on the wrong thing.
Brian Kardell: Yeah, I think 2015, I guess, we were in Portugal for TPAC, does that sound right?
Robin Berjon: It is probably right. I was no longer involved in W3C at that point.
Brian Kardell: That was still going on then, and I remember there were literally worldwide protests at this point about this. But like you say, they were protesting W3C events. And I went and talked to people who were protesting, I went and talked to them because I was like, 'Why does it bother you that W3C wrote it down? Because they're just saying it exists. It is already mostly interoperable. We should acknowledge that and formalize it and write it down and make it as maybe unfortunately good as we can.' And then also, it's good that it brings in a lot of players who would ultimately otherwise be just competitors with the web, they would be pushing to be complete competitors with the web
Robin Berjon: And also make it royalty free so that open source implementations can support it.
Brian Kardell: Exactly.
Robin Berjon: And also bring accessibility requirements to the center. I mean, yeah, I very much sympathize with people being angry about this. I mean, DRM really sucks. I recently moved from the US to Europe, and I lost a bunch of things that I thought I'd bought because they were DRM, then DRM for a region. That kind of thing should be illegal, like the people who do that kind of stuff, and I'm looking at you, Spotify, should go to jail for that kind of stuff. But it's legal and it's how the world works. And the W3C's current setup, as you said, it's largely voluntary. It's not entirely voluntary, but it's largely voluntary and it certainly doesn't have the kind of power to prevent DRM, unfortunately, as that might be. So yeah, I was hoping that people would catch that, I was hoping that those people would use the patent process to block deployment because that would've been a very interesting use of IP. I was hoping that they would protest the people actually making it happen. But no, this sort of misunderstanding of how power works in the digital space was, I think, unfortunate and also very revealing of the lack of understanding of how internet governance and digital governance works in general.
Brian Kardell: You predicted that in the late 2010s someone would implement a complete XSL FO processor in pure CSS and that the publishing industry switched to full web standards and drank champagne?
Robin Berjon: I don't think that has happened, but I think you could, I think you actually could.
Brian Kardell: I think that you could, especially now that we have has, there's pretty close parity with maybe not everything, because there are still a few things selector wise that you just can't do with CSS. But I think for 90% of existing code, it probably wouldn't matter.
Robin Berjon: And XSL FO doesn't require a lot of very complex selector processing, I think, because it really is a representation of a render entry, right? And so not that I would spend time on it, but I think it's entirely possible. You could get very close, I'm convinced you could get very close to that close. No one's done it because no one cares, but you could get very close. It would be a fun project.
Brian Kardell: You had a whole industry of applications built atop network service discovery to make it possible to control how your camera can tell your car to produce the best amount of color lighting for a dusk shot and host of other vital internet-device interactions.
Robin Berjon: Yeah, none of that's happened at all.
Brian Kardell: I don't think that happened. But you did have this thing about the TV industry, and I don't know, how do you feel about this? Because honestly, a lot of the TV industry is at least using embedded browsers, and I can't tell from reading your thing if it has become an example of what you said was the bad thing, or if it's kind of moved forward, like we're in a better place now?
Robin Berjon: Yeah, I think things have largely not changed that much. I mean, what I was probably thinking of at the time was much more to do with proper web apps on TV surfaces. But I don't think apps on TVs have taken off at all. I mean, you could see that Netflix has its own app and Disney Plus is its own app and all that, but those are not very interesting apps, they're just like a million different bad renditions of access to a catalog and a video player on top. So I think this hasn't happened because actually no one wants an app on their TV, and they're probably right about that.
Brian Kardell: Okay. So yeah, what other predictions did you make? Do you remember?
Robin Berjon: I mean, I think we've covered most of them apart from a completely gratuitous jab at PHP dying. I think PHP, I mean, it's probably still huge in some places, but I don't think it has much growth.
Brian Kardell: No, the one that we totally missed was the very first one says, 'Not only do all browsers have large chunks of themselves implemented in JavaScript, but at some point someone started a pure JS browser from scratch. It was initially made as a joke, but this inception browser caught the fancy of ever resourceful JS community and quickly grew in usability. The sheer inventiveness of its interface and flexibility of its feature set conspired to make it one of the top dogs in today's browser market.' I guess we should mention that, you wrote this as if you were writing it in 2024, although you were writing it in 2014. So do we have that? I don't know.
Robin Berjon: I don't think we have that. I think a couple of people started. I know there have been projects.
Brian Kardell: In a weird way, it is kind of true, but not in probably the way that you meant, because parts of most of the browsers are totally implemented in JavaScript, the setting screens and all of those things.
Robin Berjon: Most of the UI a lot of the times.
Brian Kardell: Yeah, that's what I mean, most of the UI things like your bookmarks bar and all that kind of stuff. But I think that was partially true in 2014 as well. I mean, the Firefox is all Zool, right? But yeah, I don't think we got that. Although we did get, I don't know if you listened to our episode a while recently, but it was on the Por4 engine. Do you know about that?
Robin Berjon: I did not, no, I did not.
Brian Kardell: So it is a JavaScript engine written in JavaScript, so maybe it's going to be a thing. And there are a lot of browsers that are kind of electron app browsers, and you could make the case that parts of them are.
Robin Berjon: I think the fun thing to try, I think it should be possible, would be to transpile SOVO to JavaScript, because I think Rust to JavaScript is quite feasible.
Brian Kardell: Interesting.
Robin Berjon: And then see what kind of performance you get and see if that leads to anything. Obviously that prediction was wrong, but I think I was right on something, which is that if it were to happen, it would start off as kind of a joke or at least a dare or it's like, 'Yeah, screw you, I'm going to do JavaScript in JavaScript,' kind of thing. And then if it succeeds, it'll be because it took off from the joke thing. So I think if someone has nothing to do over the weekend and they could try transpiling SOVO, I don't think it would work from a C++ codebase, I think that would be ambitious, but transpiling from Rust to JavaScript is probably feasible, and you might get something that actually works, surprisingly enough.
Brian Kardell: Yeah. I also had a prediction here that there would be some kind of merging of JSON and the web form model that would then lead to kind of a web schema. I don't know if that has happened in the wild, but it sounds pretty good to me actually.
Robin Berjon: It's funny because I wrote a thing called web schema, something like ten-ish years ago, I forget if it was before that blog post or after. And I did work on it as something that was designed to have a complete loop. My theory, and I still believe that, is that if you have a validation system that only does validation, then no one's going to use it. It also has to do UI generation and other things so that it is in the usage loop and people notice when things go wrong. And so I do think that's something that ties together forms and validation and content generation and all that. There's a usability sweet spot in there that should be possible to hit. I also think that that was hard to implement in a flexible, interesting way 10 years ago because custom elements weren't quite there yet. I think with today's much more HTML-centric systems, we could do something much more powerful and much more flexible. So I think this could be done, and I think it's worth doing. There is some of it in that, for instance, a lot of people use VS code and in VS code, if you have a JSON file with a JSON schema linked from it, you will get all the hinting in the editing. It's still very developer-oriented, but it's better than nothing. And the next layer up is, of course, making that available to people more generally. But yeah, I think that hasn't happened, but I think it's feasible. And it's funny, I get questions about these things once a year or so, so people are thinking about it at a slow drip essentially.
Brian Kardell: So I think that we have gone through all the predictions, but it's a fun article, we'll link it and if people want to read it, you're a good writer and you like to read a similar kind of sense of tone and humor as I do so you tend to write that way. So I always enjoy it. I think there's a bit of Douglas Adams-y the humor in your writing.
Robin Berjon: Very high praise, thank you.
Brian Kardell: I really appreciate it. Thanks for coming on, Robin. It's always fun.
Robin Berjon: Thanks for having me. It's always a pleasure. Yeah, great conversation. Thank you, Brian.
Brian Kardell
Robin Berjon