Brian Kardell: All right. So, hi, I'm Brian Kardell. I'm a developer advocate at Igalia.
Eric Meyer: I'm Eric Meyer. I'm the same.
Brian Kardell: Now we're going to do something a little different today. So Eric, do you want to explain what's different about today's show?
Eric Meyer: Yeah, I mean, today, instead of talking about a new advancement in the web or a technology or even a thing that Igalia does, we're going to talk about a set of conversations that's happening in the community right now and sort of a branching tree of takes, hot takes and spicy takes, and maybe some lukewarm takes, but, well, we're not going to get into all of those, but where people are putting up posts and replying to posts and posting about posts.And we also want to talk about this as something that happens a lot. It's kind of a recurring cycle in our industry, maybe in all industries, but certainly in the industry that we are in, where suddenly there's a topic of conversation. It's the big story. And everyone's focused on it and saying, 'Oh, my gosh, I feel the same way,' or, 'What are you talking about? That's completely wrong,' or sometimes replying to a different argument than the one that was initially made or one of the rebuttals, and sometimes splitting off into making tangentially related points.But yeah, and the current topic is frameworks and are they good or bad, or have we been sold a bill of goods, as some might put it, or not? Which, I mean, when you get down to it, really, it's talking about how we build websites and maybe about the complexity and how much complexity is appropriate for the task of building websites and where that complexity should lie. But I mean, that's really being talked about.
Brian Kardell: Yeah, so it kind of starts with Alex Russell's post The Market for Lemons.
Eric Meyer: Yeah.
Brian Kardell: If you don't know Alex, he is @slightlylate or @slightlyoff, depending on where you are. He's always slightly something.
Eric Meyer: To be clear, those are his social media handles, not ways we're describing him. He describes himself as either slightly late or slightly off in his handles.
Brian Kardell: So he is currently from Microsoft, formerly from Google, also, interestingly, formerly from Dojo. So Dojo. I think that there's-
Eric Meyer: Dojo?
Brian Kardell: Dojo. Do you know the... Dojo is the JavaScript library, early JavaScript library.
Eric Meyer: Yeah. I actually, I know that, but I wasn't sure how many listeners would remember Dojo.
Brian Kardell: Yeah, right. So that's an interesting thing because it was kind of a JavaScript framework or was it a library? We'll get into that I guess later. Yeah. Or was it a toolkit? And it's none of those things. Anyway, his post, The Market for Lemons, kind of launched the discussion, and we'll talk a little bit about what was in that, but almost immediately it spawned a reply from Laurie Voss.
Eric Meyer: Right. Laurie, currently at Netlify, but who previously was a co-founder at npm, and was there a long time before leaving, and I guess before that was at Yahoo.
Brian Kardell: Yeah. Yeah. For a number of years at Yahoo. Right.
Eric Meyer: And they're both people who've been doing this web thing for a while, almost as long as you and I have been doing it, I think, in at least one case. And they get a lot of people who follow them on social media.
Brian Kardell: I think we could say both of them have some degree of bona fides when it comes to JavaScript...
Eric Meyer: Yeah. They definitely both know whereof they speak, even though they publicly disagree pretty significantly in this particular area, which is always interesting because it's not one of them is coming from a position of ignorance. Not at all, completely the opposite. They both have been in the weeds and have been working in and around JavaScript for a long time, but they very much disagree on-
Brian Kardell: Well, it's interesting. I'd like to come back to that because I wonder if they do disagree as much as they appear to. But let's finish the premise here just to continue setting it up. As soon as both of them had published something, now everybody's going to write something to their... Sides are drawn. So there have to be the people offering some nuance and the people saying, 'Alex is absolutely right,' or, 'Laurie is absolutely right.' And so some other interesting posts that we picked out of this is one called The Great Gaslighting of the JavaScript Era by Jared White.
Eric Meyer: On his post, The Spicy Web. So you can guess that it might be a hot take.
Brian Kardell: Yes. Yes. And Brian Rinaldi is remotesynthesis.com. So let's get into The Market for Lemons, the thing that kicked it all off. So the Market for Lemons by Alex Russell, basically the premise here is talking about single page applications. So it's not really about frameworks. It winds up being about frameworks because to build single page applications, it's really handy to have a framework, right?
Eric Meyer: Any framework in particular?
Brian Kardell: Because one of these frameworks, I think it would be fair to say, sort of dominates the discussion. It is also taking the brunt of Alex's post. Although what I'll say is Alex's writing style is a little bit, he includes a lot of footnotes and not short footnotes, with some of the nuance you might feel is missing elsewhere in the post. And it is not exclusively talking about React, but React is the one that takes the brunt of it. And the premise of his post, if we could just boil it down, is we've all been hoodwinked, bamboozled, taken, and not sort of naively where the makers of the frameworks really just misunderstood or believed that... They were consciously, knowingly misleading us.
Eric Meyer: Is what Alex is saying.
Brian Kardell: Yeah. Is kind of Alex's premise. Right? So it's interesting, the evidence that he provides, and the particular read, is interesting. I think we can not take a very hard read on that either way. But this leads to Laurie's reply, which maybe you could introduce.
Eric Meyer: So Laurie responded with a post called The Case for Frameworks, which Laurie says right up front, is a direct response to The Market for Lemons, where Laurie basically says, 'Hey, frameworks are good, and they exist for reasons, good reasons, and people use them for good reasons.' I don't think Laurie is trying to say that all developments should be done with frameworks. That's not the point that Laurie's making. There's no gate keeping in that sense. But it's just basically saying, 'You haven't been hoodwinked. You haven't been bamboozled. You haven't been taken. You've been given a tool that was promoted by the people who created it because they felt that it solved problems and people used the tool because it solved problems. They maybe are not the problems that everyone has, but it was a good solution for those problems,' and provides a lot of evidence. And as we set up at the top of the show, I mean Laurie co-founded npm, so has a lot of familiarity with frameworks, package managers, tools that assist, things that make it easier for users, in this case developers, to manage the things that they need to manage. So is definitely coming from that perspective and has seen lots of people installing libraries or frameworks or whatever, and the reasons why they do that, and makes a strong case as Alex made a strong case.
Brian Kardell: What's interesting here is, as Laurie says, Laurie actually agrees with Alex on a number... Basically the reason for this topic has to do with performance. The performance of single page applications is supposed to be better going all the way back to the Ajax era. That's why we did Ajax in the first place, right? Because it felt better, it felt faster. Even in cases where you could measure and it was the same, there was this premise that somehow it still felt faster because the whole page didn't disappear in between. But as we build these large single page applications, I guess, that becomes untrue. You spend a really long time waiting for anything.
Eric Meyer: You have to wait for the markup to hydrate. Is that what the kids say something about page hydration?
Brian Kardell: Yeah. I mean there are a lot of aspects to this.
Eric Meyer: But that thing about how frameworks are supposed to make your pages faster. Actually, that puts me in mind of a post that you mentioned by Dave Rubert that predates this whole conversation by a few weeks at least, called So You Want to Make a New JS Framework. And it's tongue in cheek. It's funny because Dave's funny. But also, there's a lot of truth to it. But one of the top things of that he lists in the things you need if you're going to make a new JavaScript framework, is you have to say that it's fast. And he very intentionally, and I think this is an interesting commentary, doesn't say what fast means because nobody actually knows what fast means.
Brian Kardell: And the thing that I love about that is he also says, you need 10 influencers to get excited about how fast it is. Right?
Eric Meyer: Exactly.
Brian Kardell: And what's interesting here is I think, Dave was on our show just last time, I think. Was it literally the last episode?
Eric Meyer: I think so, yeah. Last show or the one before.
Brian Kardell: With Chris Coyier, who they do the ShopTalk show together, which we love. And a number of recent episodes of the ShopTalk show have circled back on this. What do you mean fast? Yeah, there are a lot of things that Fast could mean, and it also intertwines with Alex's points and with Laurie's points, which have to do with developer experience, developer experience being how you feel writing the code and how easy it is for you to build and manage. And one way you could be fast is rapid prototyping. You can build things really fast with this, but the page itself might be really slow from the user's perspective.
Eric Meyer: Or one could write a framework that was the other way around.
Brian Kardell: Absolutely.
Eric Meyer: Although, I'm not sure how much adoption that would get because developers would complain that it was difficult in some way even though it was really fast for users. But yeah, you could. Frameworks usually don't do that, though. I mean, frameworks, from my perception of them, are usually created to make life easier for the developer. And whether or not they make life easier for the user is usually, at best, a second thought, I suppose not in every single case. I don't want to damn all frameworks, cast them all in the same light. But things like accessibility and speed of page rendering and stuff like that, particularly on low power devices, is generally not a consideration in frameworks that I have seen or doesn't seem to have been. And sometimes that stuff gets added later, but it's always added later. The same way that happened with Flash, where Flash was had this beautiful authoring environment. Flash, for those of you who don't remember, was a mid 1990s to early 2000s technology that had this great authoring environment. I knew people who loved working in Flash because they could just create animations on a timeline. They didn't have to try to figure out how to do it themselves. They could just point and click basically, which nothing wrong with that. And I get it. They could draw interfaces and things were consistent in terms of rendering. It was very binary rendering experience. You either got the experience that the designer/developer had created it for you, or you got nothing. That was it. It was only available to those who had the Flash plugin, which for a while was most everybody on the web. Not exactly everybody, but very close. Anyway, and then it was only years after Flash had become really popular that people started to say, 'Okay, but what about people who have vision impairment and can't read the nine point text that the Flash developer created? What can they do?' And Adobe did eventually start adding in accessibility features or hooks or whatever you want to call it, to Flash. That came rather late in Flash's Lifecycle.
Brian Kardell: I wrote a series called History of the Web, and in that, I only did five parts. I wanted to do sort of early part, and really the reason that I wanted to write it had something to do with I wanted to show the origin of where Flash came from, because it predates the web and its purpose to be Flash. It was actually for something else. But anyway, as I finished writing, it turned out that Rick Waldron had written a really good piece on the whole history of Flash. But yeah, it's phenomenally interesting, it's origins and how it came about. You mentioned Adobe, but it didn't start at Adobe. It was acquired.
Eric Meyer: That's true.
Brian Kardell: And like you say, they did begin to address accessibility. Another complaint about it was that it was proprietary.
Eric Meyer: Right.
Brian Kardell: But there was an open implementation of it, and there was an effort to standardize it, actually. But it came really late after it was probably too late.
Eric Meyer: Yeah. Right.
Brian Kardell: But anyway, yeah, if you have a chance to go find Rick's thing or go read mine there, I think there's a fantastically interesting history there. But yeah, you mentioned this, and this is part of the subject of The Price Developers Pay for Loving Their Tools Too Much. That other post that we were talking about by Brian Rinaldi, right?
Eric Meyer: Right.
Brian Kardell: Yeah. And he says, 'I learned this lesson in my career to not love your tools too much, because I thought Flash was fantastic, and I loved using it, and I threw myself into it.' HTML5 didn't exist at the time. And HTML was not very good. It lacked a lot of capabilities. CSS3 didn't exist. It was a really basic medium, and it seemed like Flash let you do good things, and it worked in every browser. So it was really, really interesting. And you could do lots of creative things with it. And so I think he said more than a decade of his life, that's what he did. He was the expert in Flash stuff, and he made a career out of that. And then Steve Jobs said, 'Nah.'
Eric Meyer: Yeah, no Flash on iPhone.
Brian Kardell: Great. He said, no, Flash for you. And that was it. Within less than a year, his decade or more of Flash reflex experience was over literally from one day to the next. Yeah. So he had to retool. I think the interesting thing about this article that goes into, though, is thing that I think we innately know, but don't think about this way, in this terms of detail. I really like this thing that he added here, which is, we talk about eras and we talk about, or we like to talk about decades, the 2010s, the 1980s, the 1990s. But those are just arbitrary dates that end in a zero, and we like that. They have nothing to do with a connection to reality. Somebody born in 1990, do they have more in common with somebody born in 1989 or 1991? Neither. It's the same, more or less.But here, he gets into, if you look at because the trend of people writing software and the things that we do keeps increasing, more people are being taught, more people are entering the workforce. We do over time wind up with a curve in which a lot of people are predisposed to generally the same background and outlook. Do you know what I mean? There's a narrative that comes. And so he is saying that, right now, there are plenty of people who have not known a world without React.
Eric Meyer: Yeah.
Brian Kardell: And we sell them React as the interesting thing that they need to learn, and we have boot camps and...
Eric Meyer: Yeah.
Brian Kardell: Anyway, his point is, don't pin your career on a single framework. Understand that things change and it's difficult, but try to not be so narrow in the thing that you throw all of your insight behind. Right?
Eric Meyer: Right. Yeah. And I liked also what he said about how, just because a tool loses favor the way that past tools have, doesn't mean that you are completely done with the things that you learned in using that tool. Many of those skills will be transferrable. The exact syntax might change, but the general principles and those sorts of skills that you learned using React, for example, once React becomes passe and there's a new round of people saying, 'Oh, nobody uses React anymore. We use other thing. We use Asteroid now.' Just made up a framework name. There's probably a framework called Asteroid. And if there is, I don't know what it does. But anyway, yeah, because I think it was in Brian's post where he was saying, 'Once upon a time, you couldn't get hired unless you knew jQuery.' And there was a time where for a lot of jobs you couldn't get hired unless you knew Flash. But jQuery was absolutely essential for developer resumes for a while, and then it became not essential. And Angular became essential for a while. You had to know Angular, and then that became not essential. And recently it's been you have to know React. If React isn't on your resume, you're going to have a hard time getting a job, but its time too is likely to fade. But the people who learned jQuery or the people who learned Angular were able to learn React if they wanted to. They had had some experience working in a framework style environment, and they had experience working with JavaScript and working with the web. And so a lot of those skills were transferrable.
Brian Kardell: Almost nothing is just a complete reboot of every idea. Almost everything is iterations on ideas that came before.
Eric Meyer: Yep, yeah, absolutely.
Brian Kardell: If you learned C, it's a lot easier to learn Java, JavaScript. All the C family languages have similar ideas. And even the ones that aren't C family languages have an awful lot of similarities. So learning the first thing is harder, and then after that, a lot of those concepts just slightly reshape or get a little nicer in some areas or something, but do largely portable in my experience. If you use one templating language, you can figure out any templating language, for example. Right?
Eric Meyer: Yeah, generally speaking, or figure out that, 'Oh, I guess this templating language doesn't do that thing that my past templating language did, but it does all these other things that the other one didn't.'
Brian Kardell: Yeah, sure.
Eric Meyer: If you are so motivated, you can always make the step. Plenty of people started out learning PHP and now would not touch PHP with a 10-foot cattle prod. But the things that they learned in learning PHP helped them learn whatever it was that they learned next, whether it was JavaScript or Python or whatever. And programming languages, to a large extent, are programming languages. And you have to look to the novelty languages like Ook! before you really start to break things down.
Brian Kardell: Like Whitespace.
Eric Meyer: Yeah.
Brian Kardell: Yeah. So I think this is a good place to transition to Jared White, the spicy web, because I wonder if you didn't mix those two in your mind a little bit.
Eric Meyer: It's possible.
Brian Kardell: A lot of things that you're talking about are from the Great Gaslighting of the JavaScript Era, or at least they hit similar notes. So yeah, I mean, if there's any question about why this one is being written, it also literally says, 'Hey, Alex Russell wrote this, Laurie Voss wrote this, and I agree with Alex.' Basically-
Eric Meyer: Jared does, yeah.
Brian Kardell: Yeah, yeah. So his thing is coming from a completely different angle, and it's like he's saying he's mad. He's mad actually. He was a Ruby on Rails developer, and when Angular came along, people told him, 'Angular is the future. Your skills are no longer required. You need to retool.' And why? The message was, 'Join the Angular movement or become a dinosaur.' And he said, do you know what I find highly ironic? These many years later, my skills as a Ruby on Rails developer today are by far more valuable than the skills I would've gained pivoting to full-time Angular JavaScript development in 2014, because the future was not, in fact, Angular. And it was maybe React, but here are all these problems with React.' So it says we were fed a line. It was a lie. It was all lies, basically. There's a lot here.
Eric Meyer: Yeah. I can understand where that feeling would come from, I guess, to some extent.
Brian Kardell: Yeah. All right. So, This is really about something rather specific that, it started out as, which is a particular kind of JavaScript framework around creating SPAs...
Eric Meyer: And by SPA, single page application. Is that it?
Brian Kardell: Yeah. Right.
Eric Meyer: Okay. Sorry. There's too many three letter acronyms in my life. That's why I always have to...
Brian Kardell: There are way too many TLAs. So the reason that I'm making this point is I would like to also note that we have a lot of data from things that look at millions and millions and millions, hundreds of millions of websites, billions of websites.
Eric Meyer: You mean, are you talking browser stats?
Brian Kardell: Yeah, yeah, I'm talking about the internet archive.
Eric Meyer: Oh, okay. Yeah.
Brian Kardell: And React is very little of it.
Eric Meyer: Of the Web?
Brian Kardell: Yeah. But of the thing that is the public web - they're dominated by more traditional technologies, or basically they're not dominated by React specifically. Let's just say that.
Eric Meyer: Okay.
Brian Kardell: Not even a little bit. And I think that Alex is most cross about people who use it for that, and I think rightly so. But that web is actually comparatively small compared to the web where you have to log in and maybe is even behind corporate internet. So companies that I have worked for in the past have had one, two, maybe three or four regular web websites, but a couple of hundred internal intranet websites. And those are different. I mean, we think about them different, we optimize them different, because in many ways we are the clients. So like here at Igalia, we have internal tools, which are delivered primarily via the web. And if we're building one of them, and it took a second, we're not real stressed out about that, right? Because we're like, 'I'll just wait another second. It's okay.' We don't stress about like SEO because well, I mean, you have to log in anyway. And well, they're not to be indexed by a public crawler, right?So yeah, they're just very, very different concerns. And I have a sense from my involvement that really, really, really a lot of the use of React and Angular and Ember and all the big framework-y things that you can use to build a single page app, they're for not the public web. I think there are a lot of those and so there are a lot of developers, and maybe that's kind of okay. And I think you can see some of Laurie's points when it comes to those things because you don't want to spend a lot of money on those. You want to be able to hire people and have them know what is the technology behind this. Maybe you do in many of those cases, want it to be install-able where it wants to feel like an app in all the ways and go offline, for example. And I just think that in many ways it is a very different problem. And I wonder how much people really are making React sites on the public web and why they're doing that, too. I wonder if it's spillover, because you have people who just happen to have a lot of React experience now, and maybe some of them don't even know another way, and they get tasked with making a public site, and there you go.
Eric Meyer: Yeah. I mean, it wouldn't be surprising. And I went out and looked at the HTTP Archive's, Web Almanac, since you mentioned the usage of these various frameworks. And yeah, I hadn't looked at this year's, and I'm actually a little shocked. React is 8%, jQuery is 81%. Yeah.
Brian Kardell: I think that's a big uptake for React though, actually.
Eric Meyer: But I think they said something about possibly it plateaued. I don't know. I'm just looking at the chart here. Yeah, you're probably right. There probably are internal developers or internet developers who then get told, 'Hey, those web stuff. You put stuff in browsers. We need to put stuff in other people's browsers. Go do the thing.' And they use React because that's what they know. That's what they learned in bootcamp, and that's what they've been working on. And it's real fast to knock that out and it makes sense to them. So yeah, developing internally, I get that there are shop standards, for lack of a better term. This is what we use in this shop. If you know it, great, and then we can hire you. Or if you don't know it, then we need to build in training time or whatever. But anyway, there's a place like Facebook, has very specific performance and realtime refresh and other concerns that most sites don't have. Igalia.com does not need the same kind of timeline or refresh that facebook.com does. And it doesn't-
Brian Kardell: Here's a hot take. I don't think Facebook needs it, either.
Eric Meyer: Well, okay, but that Facebook felt that they needed.
Brian Kardell: Yeah. That's reasonable.
Eric Meyer: We don't need to be able to have a social sharing in the same way, cnn.com, wikipedia.com, just or my personal website or your personal website, don't need what React was invented to solve. Yeah.
Brian Kardell: It's not everything.
Eric Meyer: No.
Brian Kardell: And I would love to see more of who's using it for what. It would be nice if it were easy to go look at that and look at some of the things that Alex is looking at stack traces on. I actually have seen a couple of them, and they're pretty bad, actually.
Eric Meyer: Yeah.
Brian Kardell: But yeah, I think that that's an interesting thing that there are actually very kind of appropriate uses of React. And I think that the arguments that Laurie makes are more appropriate for those use cases than they are for the public websites, the sort of public pages of public websites that are indexed by these things. I think 8% is just too high for that. Anyway, we were talking about how this is a phenomenon that something captures our attention. And frequently it's not just a spicy post. It's a spicy post, and then a reply to a spicy post. And some core there is resonating. So I don't want to get into a whole nother one, but I know I noted to you that it reminded me of a different one in the past. And I have written this post called The Glory Days of the Web. My post was in reply to a post by Dion Almaer, which was-
Eric Meyer: Back in 2016.
Brian Kardell: Back in 2016, which was in reply to another post, which was in reply to another post. And where I think it begins is this post called It's The Future by Paul Biggar. And it's kind of interesting. It's mostly about not the web, but containerization and things like that. But that spawned this other post by Jose Aguinaga that I will encourage you all to go read. It's called How It Feels to Learn JavaScript in 2016.
Eric Meyer: Yeah. A classic.
Brian Kardell: And it even has a thing where you can click it and it'll read it to you and it's great. But what's interesting about this, this is very early in React days, and I know this resonated with everybody. Everybody was all over this. And when I go back and look at this now, though, the thing that's interesting to me, the premise is it's just too complicated. We have built way too much complexity. This is impossible. It's really impossible to learn. But when you go back and look at that article, it has React and JSX. But then the other things that is added to, like oh, my God, that's too complicated, is ES2016, npm, Promises, Fetch, async/await, Babel, the term functional programming, and type script. And I don't think any of those are scary to many people anymore. I mean, it's great because almost all of those are standards. And when you can get everything baked down to standards, well, that's pretty nice because Fetch is going to be around a long, long, long time. The concepts that are baked into Promises and async/await, they're going to be there for your whole career. They're simple premises that you can learn and build on and apply, and every framework or library or anything that you want to do on the web is going to deploy those things.So I don't know. It's just interesting to look back and think about, even though it seemed very overwhelming, it's because the bleeding edge of things is kind of overwhelming, right?
Eric Meyer: Yeah. It usually is.
Brian Kardell: Yeah. So I think that's part of it, is that most people were trying to get on the bleeding edge too early maybe. We were bearing a big adjustment there.But the other thing is my piece and Dionne's piece both talk about... A lot of people are feeling this is newly complex, but it's not newly complex. We've just moved the complexity, right?
Eric Meyer: Mm-hmm.
Brian Kardell: Ruby on Rails is not not complex.
Eric Meyer: Yeah.
Brian Kardell: It is very complex. PHP is very complex. JSP, ASP, all of these are things upon which there are many additional frameworks and tools and libraries and UI toolkits built with their own philosophies. And that's not new. I mean, that goes all the way back to the first, the CERN phonebook was a very complicated program. It was written in C. It was query databases. And it was not like Tim and the folks at CERN sat down and wrote a lot of HTML. Tim didn't even like writing HTML. His browser didn't even let you. You could author pages, but you couldn't see the HTML. Yeah. Anyway, that's all I have to offer on the subject. How about you?
Eric Meyer: Yeah, I mean, I think what this is not our first rodeo. I think we've made clear during this, we've seen these cycles come and go. There were these arguments or discussions or debates, whatever you want to call it, about jQuery, about Angular, about stuff I've probably forgotten about Flash going back beyond the sort of realm of JavaScript itself. And I think the field is so new in a historical sense that I think this is inevitable, and I think this is going to keep happening in the same way that when electrification happened or started happening, there were a lot of debates about what kind of current should be used and how should the wires be strong and what kinds of sockets should be used. And there were a lot of different approaches to that. This is a similar process where we're still figuring out what should this system do. And the difference here, I think, is that we have the ability to write in the things that aren't there that we think should be there. So jQuery had a bunch of stuff that made selecting elements easier, and some of them are now becoming, stuff like that :has() pseudo class selector that we helped to land in browsers just recently. jQuery had that a decade, decade and a half before because people wanted it, and it wasn't there in CSS. And it took a really long time to figure out how to get it into CSS, but it got there. That's why people use Less and Sass, because they can nest CSS selectors before there were CSS custom properties. They could have variables, and they can still have variables, and they could have mix-ins to tint colors. And those sorts of things are slowly making their way into native CSS. But we're able to craft advancements to the field using things like frameworks or libraries or pre-processors or whatever. So this is going to continue for a while. I mean, it may not ever stop, basically, because this is such a new frontier. Sometimes we feel like, oh, web development is settled. We know how it works. We really don't. We just don't. We haven't even figured it out yet. People are still keep coming up with CSS, HTML, and JavaScript doesn't have these things built in, but I can use JavaScript or some language on the server side where necessary, that could be JavaScript or it could be something else, to make this thing happen that the base technology doesn't do yet. And I think we're just going to keep seeing this. And we'll see these cycles. React, like I think we said earlier, React will eventually fall from favor, fall 'from favor,' but it's not going to go away. It's not like a React will suddenly cease to work one day. People still use jQuery. Right? jQuery never went away. It just became not the hot topic. And it became sort of a, we've moved on to a new thing. But the old thing's still there. And you can still use the old thing, sort of like HTML, right? You could still use HTML. It's still there. Yeah. So I think this will continue. And some of the points that Brian made, Brian Rinaldi made about don't fall so in love with a tool that you can't let go of it. Those are well taken. And always, if you come to a moment, if you come to an inflection point where it feels like, oh, my God, everything that I have learned is now passe in the past, I'm going to have to learn a whole new way of doing things. It's not a whole new way of doing things. There will be some differences, but the things that you've already learned will carry you forward. And yeah, we'll continue to have this discussion.
Brian Kardell: That's not to say it's not stressful even for people who go through it many times.
Eric Meyer: Oh, sure. Absolutely. Absolutely, it's stressful.
Brian Kardell: I'm constantly feeling like, oh, my God, I cannot. There's so many things that are new. How can I keep up? Yeah.
Eric Meyer: Right. Yep. That's all true. But I think to some extent, we should welcome these sorts of debates and these sorts of changes, as stressful as they may be, because they do indicate that we're learning. As a field, as an industry, we're learning what's needed and what's not needed in some cases, and the things that are needed and that are proven out to be widely wanted, because lots of people use them, make their way into the standard technologies. And so experimenting and having debates about is this a good thing? Is this a bad thing? What are the implications of new thing X being baked into the sort of foundational layer? Those are all really good.
Brian Kardell: Yeah, I agree. I think that's a good place to wrap up.
Eric Meyer: Yeah.
Brian Kardell: So thanks for joining us on this meandering set of topics. I hope that is at least pretty interesting. Anything you want to say?
Brian Kardell
Eric Meyer